☰ Categories

Categories

App Feature - Focused Readiness Audit

a senior principal engineer doing a focused readiness audit.

CategoryDevelopment › Coding
TagsAnalyzingReviewingDeveloperCode
Prompt
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.

What this prompt does

Useful for quickly checking whether an app feature is ready to ship. It requires sequential analysis and a 1-10 readiness score, with output limited to a markdown audit document.

Model comparison

Claude offers the best balance of compliance, brevity, and actionability. ChatGPT is the most analytically sound but long, while Gemini is specific yet overstates some risks and breaks format constraints.

ClaudeTop overall
44/ 50

＋ Presents key risks and actions most concisely and practically.

－ A per-attempt idempotency key cannot prevent duplicates after uncertain approval.

ChatGPT
42/ 50

＋ Accurately identifies the design as DB polling, not a true queue.

－ Accurate overall, but repetition likely pushes it beyond the limit.

Gemini
34/ 50

＋ Clearly identifies duplicate-charge paths and operational risks.

－ Exceeds the length limit and violates the integer-score requirement.

CriterionChatGPTClaudeGeminiLeader
Instruction following896Claude +13%
Accuracy987ChatGPT +13%
Specificity999Tie
Structure998Tie
Right length794Claude +29%

Scored 1–10 by gpt-5.6-sol with model names hidden (2026-09-24). This is an AI review, not a measurement.

Read full answers

We gave three models the same input and copied their answers unedited. Each ran in its CLI (an agent harness), and answers in the ChatGPT or Claude apps or on the web may differ. Outputs are in Korean.

Input used
[Pasted material]
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분마다 전체 테이블을 스캔합니다.
gpt-5.6-luna (codex CLI · 에이전트 하네스) · Run on 2026-09-24

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

소량의 일시적 실패를 재처리하는 개념 검증에는 유효하지만, 실제 결제 시스템에 적용하기에는 중복 청구와 상태 불일치 위험이 치명적이다. 현재 구조는 “재시도”는 수행하지만 “안전하고 추적 가능한 결제 복구”를 보장하지 않는다.

다음 단계

  1. idempotency key와 결제 상태 머신을 도입한다.
  2. next_retry_at, processing 상태 및 원자적 claim/락을 추가한다.
  3. 지수 백오프와 오류 유형별 재시도 정책을 적용한다.
  4. 중복 실행 방지, 트랜잭션, 타임아웃, 알림·감사 로그를 구현한다.
  5. 인덱스·배치 처리와 장애 복구 테스트를 완료한 뒤 운영 적용한다.

More in this category

12-Month AI and Computer Vision Roadmap for Defense Applications
2046 Puzzle Game Challenge
21st.dev component prompt
3D FACTORY
3D FPS Game