AI에게 '이 코드 검토해 줘'라고 말하는 대신 이렇게 하세요.

이미 code review, 디버깅, 테스트에 Claude나 ChatGPT를 사용하고 있을 것입니다. 그리고 솔직히 말해서, 결과물은 보통 평범합니다: 순위가 매겨지지 않은 스타일적 사소한 지적들(style nits)이 실제 버그와 뒤섞여 있거나, 에러가 발생한 라인만 자신감 있게 수정하거나, 아무것도 증명하지 못하는 행복 경로 테스트 세 개 같은 것들이죠.

모델을 탓하기 쉽습니다. 하지만 진짜 문제는 프롬프트입니다. '이 코드 검토해 줘'는 모호한 지시이며, 모호한 지시는 모호한 답변을 가져옵니다. 여기 구체적인 예시와 이를 해결하는 단 하나의 변경 사항을 소개합니다.

실제 버그

def calculate_order_total(items: list[dict]) -> int:
    total = 0
    for item in items:
...

이 코드는 TypeError: unsupported operand type(s) for *: 'NoneType' and 'int' 오류를 발생시키지만, 결제 과정의 약 2%에서만 발생하며 API 마이그레이션 직후에 시작되었습니다.

단순한 프롬프트인

해당 버그는 검증 과정 없이 API 응답에서 가격을 복사하는 build_order에서 발생합니다. 이는 None이 처음으로 사용되는 가격 계산 단계에서 나중에야 표면화됩니다. 크래시(crash)가 발생한 지점은 상류(upstream)에서 유입된 검증되지 않은 데이터의 무고한 희생자일 뿐입니다. 이는 모든 단서를 설명해 줍니다: 오직 약 2%의 장바구니(가격이 책정되지 않은 아이템이 포함된 경우)에서만 발생하며, 마이그레이션 전환 시점에 시작되었고, 로컬 환경에서는 재현되지 않습니다. 실패한 장바구니의 원시 응답(raw response)을 가져와 가격이 null임을 확인하여 재현한 다음, 수정 사항을 신뢰하기 전에 회귀 테스트 (regression test)를 추가하십시오.

이 프롬프트는 상류의 원인을 찾아냈고, 추측하기를 거부했으며, 실제로 문제를 해결했는지 확인하는 방법까지 알려주었습니다.

작동 원리

세 가지 규칙이 핵심적인 역할을 수행합니다:

• 수정 전 원인 파악 (Cause before fix). 모델은 원인을 명시하기 전까지는 수정 방안을 제안하는 것이 금지됩니다. 스택 트레이스 (Stack traces)는 보통 실제 버그의 하류 (downstream)에 있는 크래시 지점을 가리키기 때문입니다.
• 신뢰도와 반증을 포함한 순위가 매겨진 가설 (Ranked hypotheses with confidence and counter-evidence). "가능한 원인 6가지는 다음과 같습니다"라는 식의 접근은 우선순위가 지정된 조사로 이어지며, 반증 (counter-evidence)은 모델이 무엇을 추측하고 있는지에 대해 정직함을 유지하게 합니다.
• 증상만이 아닌 원인을 검증 (Verify the cause, not just the symptom). "에러가 사라졌다"는 것은 "문제를 이해했다"와 동일하지 않습니다.

어디에서나 적용 가능한 동일한 아이디어

이는 디버깅에만 국한된 것이 아닙니다. 모든 취약한 AI 코딩 프롬프트에는 동일한 해결책이 있습니다: 모델에게 좋은 답변이 어떤 모습인지 알려주고, 제약 조건을 거는 것입니다.

• 코드 리뷰 (Code review): 모든 발견 사항에 심각도 라벨 (severity label)과 배포 여부 (ship / don't-ship) 판정을 요구하십시오. 그래야 산문 형태의 글을 읽는 대신 몇 초 만에 우선순위를 분류 (triage)할 수 있습니다.
• 테스트 생성 (Test generation): 세 가지 해피 패스 (happy-path) 단언문 (asserts) 대신, 엣지 케이스 (edge cases)와 에러 케이스 (error cases), 그리고 모든 입력에 대해 유지되는 불변량 (invariants)을 먼저 요청하십시오.
• PR 설명 (PR descriptions): 모든 것을 디프 (diff)에서 도출하고, 테스트를 허위로 작성하는 것을 거부하며, 남아있는 디버그 코드를 표시하도록 하십시오.

모델은 언제나 좋은 답변을 내놓을 능력이 있었습니다. 구조가 그 답변을 끌어내는 것입니다.

나머지 내용을 원하신다면

저는 코드 리뷰 (code review), 디버깅 (debugging), 리팩터링 계획 (refactor planning), 테스트 생성 (test generation), PR 설명 (PR descriptions), 그리고 비난 없는 사후 분석 (blameless postmortems) 등 이 6가지 프롬프트를 각각 실제 테스트를 거친 작동 예제와 함께 패키지로 구성했습니다: Code Review Copilot Prompts. 위에서 소개한 버그 분류 (bug-triage) 프롬프트는 누구에게나 무료로 제공됩니다. 이를 복사하여 다음 버그 수정 시 사용해 보세요.