빠른 흐름

검증 루프
1. 재현 절차를 먼저 준다.
2. 최소 수정으로 고치게 한다.
3. 가장 작은 관련 테스트를 다시 돌리게 한다.
4. git diff를 검토한다.
5. 필요하면 /review로 한 번 더 점검한다.

검증 흐름

Codex가 자기 작업을 검증할 수 있어야 품질이 높아진다

Codex는 자기 작업을 검증할 수 있을 때 품질이 높아집니다. 검증 가능성은 프롬프트 설계에서 결정됩니다. 재현 절차 없이 증상만 설명하면 Codex는 무엇이 실패인지 확인할 방법이 없고, 수정 후 재검증도 불가능합니다. "이 재현 절차를 따라 실패를 확인하고, 최소 수정 후 관련 테스트를 다시 돌려라"처럼 검증 루프 전체를 프롬프트에 포함하는 것이 안정적인 결과의 출발점입니다.

수정 요청 예시
- 먼저 버그를 재현해라.
- 수정은 최소화해라.
- 수정 후 npm test -- auth 관련 테스트만 다시 돌려라.
- 마지막에 실행한 명령, 결과, git diff에서 핵심 변경을 요약해라.

테스트 범위를 가능한 한 좁게 시작해야 하는 이유

검증은 가능한 한 작은 범위부터 시작하는 것이 좋습니다. 전체 테스트보다 관련 테스트, 최소 린트, 직접 재현 확인이 먼저입니다. 전체 테스트 스위트를 돌리면 시간이 오래 걸리고, 수정과 무관한 기존 실패가 섞여 어디가 진짜 문제인지 파악하기 어렵습니다. 관련 테스트만 먼저 통과시키고, 마지막에 전체 테스트로 회귀 여부를 확인하는 순서가 효율적입니다.

좋은 순서
  -> 재현
  -> 관련 테스트
  -> diff 확인
  -> 필요하면 전체 테스트

diff 검토가 테스트 통과와 별도로 필요한 이유

수정 후에는 명령 결과뿐 아니라 git diff도 같이 읽어야, 테스트는 통과하지만 설계상 어색한 변경을 걸러낼 수 있습니다. 테스트 통과만으로 끝내면, 우연히 통과한 수정이나 과도한 변경을 놓치기 쉽습니다. 수정 이유와 실제 변경 범위가 일치하는지, 의도치 않게 건드린 파일은 없는지를 diff에서 직접 확인하는 습관이 중요합니다.

/review로 작업 트리 전체를 한 번 더 점검하는 시점

로컬 작업이 끝나면 /review로 working tree를 다시 훑게 하여 빠진 예외 처리나 테스트 누락을 한 번 더 점검할 수 있습니다. 개별 수정 단계에서는 보이지 않던 패턴이나 누락이 전체를 훑어볼 때 드러나는 경우가 있습니다. /review는 "내가 한 수정 전체를 다시 보면 무엇이 빠졌는가"를 확인하는 용도이므로, 개별 검증 루프가 끝난 뒤 마지막 단계로 활용하는 것이 자연스럽습니다.

무엇부터 확인할까

주의할 점

❌ "고치고 테스트 돌려"
❌ 어떤 테스트인지 지정 없음
❌ diff 검토 단계 없음

이런 요청은 전체 테스트를 불필요하게 오래 돌리거나, 우연히 통과한 과도한 수정까지 놓치기 쉽습니다.