리뷰 코멘트, 바로 고칠지 더 물을지 가르는 Codex 프롬프트

PR에 "이 케이스 깨질 것 같습니다", "테스트가 부족합니다", "범위가 커 보입니다" 같은 리뷰가 달리면 손이 먼저 코드로 갑니다. 그런데 댓글이 짧을수록 위험한 지점은 코드가 아니라 해석입니다. 어느 입력에서 깨지는지, 어떤 파일만 고치면 되는지, 어떤 테스트로 끝났다고 말할 수 있는지가 비어 있으면 수정 범위가 넓어집니다. 이때 필요한 첫 작업은 리뷰 코멘트를 패치 지시가 아니라 진단 재료로 바꾸는 일입니다.

Tap to zoom

developers.openai.com의 Codex GitHub 문서는 Codex가 PR diff를 검토하고 저장소의 AGENTS.md 지침을 따르며, GitHub에 코드 리뷰를 남길 수 있다고 설명합니다. 또 Codex app의 review 문서는 PR 컨텍스트, 리뷰 댓글, 변경 파일을 보면서 특정 댓글을 고치도록 요청하고 diff를 검토하는 흐름을 안내합니다. 이 말은 리뷰 코멘트를 그대로 "고쳐 줘"라고 던지는 것보다, 댓글과 diff를 함께 놓고 수정 범위를 먼저 묻는 방식이 더 잘 맞는다는 뜻입니다.

이미 나온 AI 답변의 근거를 확인해야 한다면 ChatGPT 출처가 불안할 때, 3분 검증표 프롬프트 흐름을 같이 쓰면 됩니다. 리뷰 댓글을 처리한 뒤 회의나 보고로 넘겨야 한다면 회의록 액션아이템이 흐릿할 때, 담당자와 마감부터 뽑는 프롬프트처럼 다음 행동을 분리해 두면 답글이 짧아집니다.

댓글을 바로 수정 지시로 쓰지 말고 네 칸으로 나눕니다

애매한 리뷰 코멘트는 보통 네 가지 정보 중 일부만 담고 있습니다. 댓글이 "이 함수는 빈 배열에서 깨질 수 있음"이라고 말해도 실제로 필요한 정보는 더 많습니다. 어떤 입력이 문제인지, 어느 함수까지 고칠지, 어떤 테스트를 추가할지, 리뷰어에게 무엇을 답할지가 따로 있습니다.

Codex CLI 기능 문서는 /review가 선택한 diff를 읽고 우선순위가 있는 실행 가능한 finding을 보고하되 working tree를 건드리지 않는다고 안내합니다. 이 성격을 생각하면 첫 질문도 패치 생성보다 분류에 가까워야 합니다. 수정 전에는 네 칸 중 비어 있는 칸을 먼저 찾는 것이 안전합니다.

Codex에 붙여 넣을 프롬프트는 이렇게 시작합니다

아래 프롬프트는 사람 리뷰, Codex 리뷰, CI 실패 댓글에 모두 쓸 수 있습니다. 핵심은 댓글을 바로 해결하지 말고 재현 조건과 수정 범위를 분리하라고 지시하는 것입니다.

아래 PR 리뷰 코멘트를 바로 고치지 말고, 먼저 수정 범위를 좁혀 주세요.

리뷰 코멘트:
{리뷰어 또는 Codex가 남긴 댓글 원문}

관련 diff 또는 파일:
{관련 코드, 파일명, 함수명, 변경 요약}

실패 로그나 테스트 결과:
{있으면 붙이고, 없으면 "없음"이라고 적습니다}

내가 원하는 출력:
| 항목 | 판단 | 근거 | 다음 행동 |

규칙:
1. 재현 조건이 없으면 추정하지 말고 "추가 확인 필요"라고 적습니다.
2. 수정 범위는 파일, 함수, 테스트 단위로 좁힙니다.
3. 리뷰 코멘트와 직접 관련 없는 리팩터링은 별도 제안으로 분리합니다.
4. 검증 명령은 실제로 실행할 수 있는 명령이나 수동 확인 절차로 씁니다.
5. 마지막에 리뷰어에게 남길 답글 초안을 세 문장 이하로 씁니다.

OpenAI prompt engineering 문서는 목적, 지침, 예시, 관련 컨텍스트를 나눠 주는 방식을 설명합니다. 코드 작업에서도 역할, 구조화된 도구 사용, 테스트와 검증 지시가 도움이 된다고 안내합니다. 위 프롬프트가 잘 먹히는 이유도 같습니다. 댓글 원문, 관련 diff, 실패 로그, 출력 표, 금지 규칙을 나눠서 주면 모델이 "대충 고치기"보다 작업 경계와 검증 기준을 먼저 세웁니다.

Tap to zoom

첫 답변에서 바로 패치를 만들지 말고 빠진 조건만 다시 묻습니다

프롬프트를 넣으면 Codex나 ChatGPT가 "수정 범위"를 제안할 수 있습니다. 이때 바로 코드를 바꾸기보다 첫 답변에서 빠진 조건을 확인합니다. 특히 재현 조건이 없는데도 파일 여러 개를 바꾸라고 나오면 범위가 넓어진 신호입니다.

다음처럼 한 번 더 좁혀 물어보면 됩니다.

방금 답변에서 재현 조건이 충분한 항목과 부족한 항목을 나눠 주세요.

출력:
| 리뷰 항목 | 지금 고쳐도 되는 이유 | 더 물어봐야 하는 정보 | 고치면 안 되는 범위 |

규칙:
- 테스트나 로그가 없는 추정은 "추정"이라고 표시합니다.
- 지금 고쳐도 되는 항목은 최대 두 개만 고릅니다.
- 관련 없는 리팩터링, 이름 변경, 스타일 수정은 제외합니다.

이 단계의 목적은 속도를 늦추는 것이 아닙니다. 오히려 넓은 수정을 줄여 리뷰 왕복을 줄이는 단계입니다. 재현 조건이 없으면 패치보다 질문이 먼저입니다. "이 입력에서 실패하는 게 맞나요?", "기대 동작은 빈 배열이면 빈 결과를 반환하는 것인가요?", "이 PR에서 테스트 추가까지 포함해도 되나요?" 같은 질문이 나오면 다음 수정이 작아집니다.

실제 수정 요청은 파일과 검증 명령을 붙여서 좁게 냅니다

조건이 모이면 그때 수정 요청을 냅니다. 이 요청은 짧아야 합니다. "전체적으로 개선해 줘"가 아니라 어느 파일을 고치고 무엇을 검증할지 함께 줍니다.

아래 범위만 수정해 주세요.

수정 대상:
- 파일: {예: src/modules/order/calculate-total.ts}
- 함수: {예: calculateTotal}
- 문제 조건: {예: items가 빈 배열일 때 할인 계산에서 NaN 발생}

수정하지 않을 범위:
- 함수명 변경
- 주변 모듈 리팩터링
- UI 문구 변경

검증:
- {예: npm test -- calculate-total}
- {예: npm run typecheck}

완료 후 출력:
1. 바꾼 파일
2. 문제 조건이 어떻게 처리되는지
3. 실행한 검증 명령과 결과
4. 리뷰어에게 남길 답글 초안

Codex GitHub 문서는 리뷰 뒤에 @codex fix the P1 issue처럼 같은 PR 맥락에서 수정을 요청할 수 있다고 안내합니다. 다만 "P1을 고쳐 줘"만으로도 시작은 가능하지만, 실무에서는 위처럼 파일, 함수, 제외 범위, 검증 명령을 붙이면 사람이 검토하기 쉬운 diff가 나옵니다. 작은 패치와 검증 결과가 같이 있어야 리뷰 답글이 짧아집니다.

답글은 변명보다 조건, 변경, 검증만 남깁니다

리뷰어에게 길게 설명할수록 다시 읽을 부담이 생깁니다. 답글은 보통 세 줄이면 충분합니다.

리뷰어 답글 초안으로 줄여 주세요.

포함할 내용:
- 어떤 재현 조건을 기준으로 봤는지
- 어떤 파일 또는 함수만 수정했는지
- 어떤 검증 명령을 실행했는지

금지:
- "전반적으로 개선했습니다" 같은 넓은 표현
- 실행하지 않은 테스트 언급
- 리뷰어 판단을 대신 확정하는 표현

예를 들면 "빈 배열 입력에서 calculateTotal이 0을 반환하도록 src/modules/order/calculate-total.ts만 수정했습니다. npm test -- calculate-total과 npm run typecheck를 통과했습니다. 이 PR 범위 밖의 할인 정책 정리는 별도 이슈로 분리하겠습니다." 정도면 충분합니다.

PR 리뷰 코멘트가 애매할수록 바로 고치지 마세요. 댓글, diff, 로그를 네 칸으로 나누고, 재현 조건이 빈 곳은 먼저 질문으로 바꿉니다. 그다음 파일과 함수, 제외 범위, 검증 명령을 붙여 작은 수정 요청을 냅니다. 오늘 필요한 목표는 리뷰어를 설득하는 긴 답글이 아니라 검증 가능한 작은 패치입니다.

참고 출처

• OpenAI Developers, Codex code review in GitHub
• OpenAI Developers, Codex app Review
• OpenAI Developers, Codex CLI Features
• OpenAI API Docs, Prompt engineering