03-리팩터-사례

03. 리팩터 사례

Before — 막연한 한 줄

이 코드 좀 잘 리뷰해 줘.

문제점:

• 명확성(1) ✗ — “잘”의 정의 없음, 출력 형식 없음
• 맥락(2) ✗ — 누가 읽는지, 어떤 기준인지 없음
• 예시(3) ✗ — 합격/불합격 사례 없음
• 구조(4) ✗ — 코드와 지시가 섞임
• 평가 루프(5) ✗ — 좋아졌는지 측정 불가

After — 다섯 원칙 적용

<role>
당신은 보안에 민감한 핀테크 백엔드의 시니어 코드 리뷰어다.
</role>

<context>
이 PR은 결제 콜백 핸들러를 수정한다. 우리 팀 컨벤션:
- 외부 입력은 반드시 zod로 검증
- 금액은 정수 minor unit (KRW = 1)
- 로그에는 PII 금지
</context>

<instructions>
아래 diff를 리뷰하라. 다음 4개 카테고리로 코멘트를 분류해 출력하라.
1. blocker — 머지 금지
2. should — 가능하면 고치기
3. nit — 취향 영역
4. praise — 잘한 점

각 항목은 (파일:라인) 형식으로 위치를 표기한다.
blocker가 0개면 마지막 줄에 "APPROVED"라고만 적는다.
</instructions>

<example>
- blocker (api/pay.ts:42): 외부에서 받은 amount를 zod로 검증하지 않음. 음수/소수 가능.
- should (api/pay.ts:88): logger.info에 user.email 포함. PII 정책 위반 가능성.
- praise (api/pay.ts:15): idempotency key 처리 명시적이라 좋음.
</example>

<diff>
... 실제 diff ...
</diff>

어떻게 좋아졌는가

원칙	변화
명확성	”잘”이 4개 카테고리 + 위치 표기 + APPROVED 토큰으로 측정 가능해짐
맥락	도메인(핀테크), 컨벤션(zod, minor unit, PII)이 명시됨
예시	4개 카테고리 각각의 톤과 형식을 한 블록으로 시연
구조	<role>/<context>/<instructions>/<example>/<diff> 분리
평가 루프	”blocker == 0 ⇒ APPROVED” 라는 회귀 테스트 가능한 출력 시그널

평가 루프를 붙이는 법(미리보기)

이 프롬프트를 10개의 합격 PR과 5개의 의도적으로 망친 PR에 돌려, 다음 두 지표로 측정한다.

• F1(blocker 식별): 사람 리뷰어가 blocker라고 표시한 항목과 일치하는 비율
• APPROVED 정확도: 합격 PR 중 APPROVED를 정확히 출력한 비율

이 두 수치가 회귀(regress)하면 프롬프트 변경을 롤백한다. 자세한 방법은 본 파트 5장 참조.