44/ 50
＋ 핵심 위험과 조치를 가장 간결하고 실행 가능하게 정리했다.
－ 시도별 멱등키는 불명확한 승인 후 중복 결제를 막지 못한다.
기능 준비도 감사 프롬프트
기능명과 구현 코드 또는 설명을 넣으면 품질, 의존성, 실제 영향, 위험, 교차 관심사를 검토한 2000자 이하 감사 문서를 만듭니다.
| 분류 | 개발 › 코딩 |
|---|---|
| 태그 | 분석검토개발자코드 |
You are a senior principal engineer doing a focused readiness audit.
Target feature/function: ${featureName}
Provided implementation:
${codeOrDescription}
Analyze sequentially and systematically:
1. Implementation quality & structure
2. Role and dependencies in the broader codebase
3. Expected behavior vs actual impact
4. Edge cases, risks, bottlenecks, and tech debt
5. Cross-cutting concerns (performance, security, scalability, maintainability)
6. Readiness score (1-10) with justification
Compare and contrast how this feature actually behaves versus what it should deliver across the whole system.
Output ONLY a clean, professional "Feature Readiness Audit" document. Use markdown. Keep total response under 2000 characters. Be direct, honest, and actionable. End with clear next-step recommendations.어떤 프롬프트인가
앱 기능의 출시 준비도를 빠르게 점검할 때 쓰기 좋다. 순차 분석과 1~10점 준비도 점수를 요구하며, 결과는 마크다운 감사 문서로 제한한다.
모델 비교
Claude는 형식·간결성·실행성이 가장 균형 잡혔다. ChatGPT는 분석 정확도가 가장 높지만 길고, Gemini는 구체적이나 형식 위반과 과장이 있다.
42/ 50
＋ 실제 큐가 아닌 DB 폴링 구조라는 본질을 정확히 분석했다.
－ 내용은 정확하지만 일부 반복으로 2000자 제한 준수가 아쉽다.
34/ 50
＋ 중복 청구 경로와 운영 위험을 구체적으로 짚었다.
－ 분량을 초과했고 정수 점수 요구에 1.5점으로 답했다.
| 기준 | ChatGPT | Claude | Gemini | 앞선 모델 |
|---|---|---|---|---|
| 지시 준수 | 8 | 9 | 6 | Claude +13% |
| 정확성 | 9 | 8 | 7 | ChatGPT +13% |
| 구체성 | 9 | 9 | 9 | 동점 |
| 구성·가독성 | 9 | 9 | 8 | 동점 |
| 분량 적정성 | 7 | 9 | 4 | Claude +29% |
gpt-5.6-sol가 모델 이름을 가린 채 1~10점으로 채점했습니다 (2026-09-24). 측정값이 아니라 AI 심사 결과입니다.
답 전문 보기
같은 입력을 세 모델에 넣어 받은 답을 그대로 옮겼습니다. 각 CLI(에이전트 하네스)에서 실행했습니다. ChatGPT·Claude 앱이나 웹에서는 답이 다를 수 있습니다.
[붙여 넣은 자료]
featureName: 결제 실패 자동 재시도 큐 (Payment Retry Queue)
codeOrDescription:
```javascript
// paymentRetryQueue.js
async function processRetryQueue() {
const failedPayments = await db.query(
`SELECT * FROM payments WHERE status = 'failed' AND retry_count < 3`
);
for (const payment of failedPayments) {
try {
await pgClient.charge(payment.amount, payment.cardToken);
await db.query(`UPDATE payments SET status = 'success' WHERE id = ?`, [payment.id]);
} catch (err) {
await db.query(
`UPDATE payments SET retry_count = retry_count + 1 WHERE id = ?`,
[payment.id]
);
}
}
}
setInterval(processRetryQueue, 60000);
```
매일 실패 결제가 200~300건 정도 쌓이고, 재시도는 setInterval로 1분마다 전체 테이블을 스캔합니다.Feature Readiness Audit
1. 구현 품질 및 구조
현재 구현은 단순한 폴링 기반 프로토타입 수준이다. setInterval로 1분마다 전체 실패 결제를 조회하고 순차 처리한다. 재시도 횟수 제한은 있으나, 작업 예약·동시성 제어·상태 전이·실패 원인 분류가 구현되어 있지 않다.
또한 결제 성공 처리와 재시도 횟수 갱신이 원자적으로 보장되지 않으며, 프로세스가 여러 개 실행되면 동일 결제가 중복 처리될 수 있다.
2. 코드베이스 내 역할 및 의존성
핵심 의존성은 결제 게이트웨이(pgClient), 결제 DB, 실행 프로세스의 생명주기다. 그러나 큐라는 명칭과 달리 실제 메시지 큐나 작업 저장소가 없고, DB 조회 결과가 곧 작업 목록이다.
애플리케이션 재시작 시 진행 상태가 명확하지 않고, 다중 인스턴스·배포 환경에서는 분산 락 또는 행 잠금이 필요하다.
3. 기대 동작과 실제 영향
기대 동작은 실패 결제를 안전하게 최대 3회 재시도하여 일시적 장애의 성공률을 높이는 것이다. 실제로는 다음 문제가 발생한다.
- 전체 테이블을 반복 스캔한다.
- 동일 결제가 중복 청구될 수 있다.
- 모든 실패를 재시도하여 카드 거절·잔액 부족 같은 영구 실패도 반복한다.
- 재시도 간격이 고정되어 게이트웨이 장애 시 부하가 집중된다.
- 성공 업데이트 실패 시 결제는 실제 성공했지만 다시 청구될 수 있다.
4. 엣지 케이스·위험·기술 부채
processRetryQueue실행이 1분을 초과하면 다음 실행과 겹친다.- 네트워크 타임아웃은 청구 결과가 불명확한 상태를 만든다.
retry_count증가와 상태 변경에 대한 트랜잭션이 없다.- 예외 로깅, 알림, 감사 추적이 없다.
- 인덱스가 없으면 일일 200~300건에서도 데이터 증가에 따라 성능이 악화된다.
cardToken보관·취급 방식에 따라 PCI DSS 및 개인정보 위험이 있다.
5. 교차 관심사
성능 측면에서는 (status, retry_count, next_retry_at) 복합 인덱스와 배치 처리가 필요하다. 보안·정합성 측면에서는 결제 게이트웨이의 idempotency key를 반드시 사용해야 한다. 확장성 측면에서는 DB 기반 작업 큐 또는 외부 큐와 워커 구조가 적합하다. 유지보수를 위해 재시도 정책, 실패 분류, 관측성, 운영 중지 기능을 분리해야 한다.
6. 준비도 점수: 3/10
소량의 일시적 실패를 재처리하는 개념 검증에는 유효하지만, 실제 결제 시스템에 적용하기에는 중복 청구와 상태 불일치 위험이 치명적이다. 현재 구조는 “재시도”는 수행하지만 “안전하고 추적 가능한 결제 복구”를 보장하지 않는다.
다음 단계
- idempotency key와 결제 상태 머신을 도입한다.
next_retry_at,processing상태 및 원자적 claim/락을 추가한다.- 지수 백오프와 오류 유형별 재시도 정책을 적용한다.
- 중복 실행 방지, 트랜잭션, 타임아웃, 알림·감사 로그를 구현한다.
- 인덱스·배치 처리와 장애 복구 테스트를 완료한 뒤 운영 적용한다.
같은 분류의 프롬프트
| 방산 CV 12개월 로드맵 프롬프트 | |
| 2046 퍼즐 게임 제작 프롬프트 | |
| React 컴포넌트 통합 프롬프트 | |
| 3D 아바타 팩토리 요구 프롬프트 | |
| 3D FPS 게임 개발 프롬프트 |