Code Review

문제

PR 하나에 리뷰어를 여럿 붙이고 라운드를 거듭해도 어떤 결함은 계속 빠져나갑니다.

1. 구현 완료
2. codex exec review --base main
3. 지적과 제안 패치를 따로 검증
4. 인라인 스레드에 수용/기각 답글
5. 기각 사유를 반영 커밋에 남기기

추천

구현과 리뷰에 다른 벤더를 씁니다. 같은 모델의 서브에이전트를 늘리는 대신 리뷰 자체를 다른 벤더의 모델로 바꿉니다.

이유

리뷰어를 여러 명 붙여도 전제가 같으면 같은 곳을 놓칩니다. 리뷰어들이 같은 기준 문서(스펙, 설계 문서, 체크리스트)를 보고 판단하면, 그 문서에 없는 조합의 결함은 리뷰어 수를 늘려도 드러나지 않습니다. 신선한 컨텍스트로 다시 리뷰해도 같은 모델이면 같은 프레임을 다시 불러올 가능성이 높습니다. 다른 벤더의 모델은 그 프레임 자체를 공유하지 않으므로 놓치는 지점이 다릅니다. 다른 벤더는 기준점을 바꿉니다. 리뷰가 더 꼼꼼해지는 것은 아닙니다.

같은 이유로 태스크별(diff별) 리뷰가 구조적으로 못 보는 회귀가 있습니다. 합쳐졌을 때만 보이는 회귀입니다. 새로 추가한 규칙이 브리프대로 정확해도, 그 규칙이 다른 파일의 기존 정의와 만나면서 문제가 생기는 경우가 있습니다. diff 하나만 보는 리뷰는 이 조합을 볼 수 없습니다.

예시

codex exec review --base main은 codex가 git 상태를 직접 읽으므로 diff를 프롬프트에 인라인으로 넣을 필요가 없습니다.

codex exec review --base main

함정이 두 가지 있습니다.

• --base는 커스텀 프롬프트와 병용할 수 없습니다 ('--base <BRANCH>' cannot be used with '[PROMPT]').
• 일반 모드 codex exec "<프롬프트>"는 stdin을 기다리다 멈춥니다. < /dev/null을 붙입니다.

리뷰는 시간이 걸리므로 백그라운드로 돌리고 watchdog을 둡니다. 리뷰 전에 rm -rf .next로 빌드 산출물을 지워 크롤링에 걸리지 않게 합니다. 최종 판정은 출력 끝부분에서 읽습니다.

codex exec review --base main < /dev/null | tail -c 3000

받은 지적은 “지적 자체”와 “제안 패치”를 따로 검증합니다. 지적은 타당한데 제시된 패치가 문제를 고치지 못하는 경우가 있습니다. 제목만 읽지 말고 제안 패치는 경계값을 손으로 계산해 봅니다.

수용/기각과 무관하게 인라인 스레드에 답글을 남깁니다. 기각 근거를 적어야 같은 지적이 반복되지 않습니다. 반영 커밋에는 제안 패치를 쓰지 않은 이유를 남깁니다. 스레드가 접히면 판단 근거가 사라지기 때문입니다.

내부 리뷰 지시문에도 다음 두 항목을 넣습니다.

• 한 함수 안에 같은 조건들을 다루는 우선순위 사슬이 여러 개면, 순서가 일치하는지 대조합니다.
• 상황을 표로 정리했으면 “이 행들이 동시에 참일 수 있는가”를 표 밑에 한 줄로 답해둡니다.

하지 말 것

같은 모델의 리뷰어를 늘려서 안심하기. 리뷰어들이 같은 기준 문서를 보면 다 같은 곳을 놓칩니다. 리뷰어 수를 늘리는 대신 기준점을 바꿉니다.

태스크(diff) 단위로만 리뷰하기. 합쳐졌을 때만 보이는 회귀는 diff 하나만 보는 리뷰로는 구조적으로 안 보입니다.

리뷰 코멘트의 제목만 읽고 수용하거나 기각하기. 제안 패치가 실제로 문제를 고치는지는 따로 확인해야 합니다.