Codex로 PR 댓글 고치기 전, 우선순위표부터 요청하는 프롬프트

PR 댓글이 다섯 개만 넘어가도 "Codex야 전부 고쳐줘"라는 요청은 빨라 보입니다. 하지만 그 안에는 오타 수정, 타입 오류, API 설계 질문, 테스트 추가, 리뷰어 의도 확인이 필요한 댓글이 섞여 있을 수 있습니다. 한 번에 맡기면 diff는 커지고, 어떤 댓글 때문에 어떤 파일이 바뀌었는지 다시 따라가야 합니다.

먼저 할 일은 패치가 아닙니다. 댓글을 수정 묶음과 질문 묶음으로 나누는 우선순위표를 받는 것입니다. OpenAI Codex Best practices는 좋은 요청에 목표, 맥락, 제약, 완료 조건을 넣으라고 안내합니다. PR 댓글 처리도 같습니다. 목표는 "댓글 해결"이 아니라 "어떤 댓글을 어떤 순서로, 어떤 검증까지 끝낼지 정하기"입니다.

Tap to zoom

바로 고치기 전에 댓글별 영향도를 표로 받습니다

처음에는 아래 프롬프트만 붙여 넣습니다. 아직 코드를 고치지 말라고 못 박는 것이 핵심입니다.

아래 PR 댓글과 현재 변경 범위를 보고, 아직 코드는 수정하지 말고 우선순위표만 만들어 주세요.

목표:
- 댓글을 바로 고치는 대신 영향도와 검증 범위를 먼저 나눕니다.
- 같은 파일과 같은 원인의 댓글은 하나의 수정 묶음으로 합칩니다.
- 정보가 부족하거나 리뷰어 의도 확인이 필요한 댓글은 질문 묶음으로 분리합니다.
- 위험도가 높은 댓글은 작은 패치로 따로 처리합니다.

입력:
1. PR 댓글:
{댓글 목록 붙여 넣기}

2. 변경 파일:
{변경 파일 또는 diff 요약 붙여 넣기}

3. 현재 실패 또는 확인된 테스트:
{테스트 결과가 있으면 붙여 넣기}

출력 형식:
| 우선순위 | 댓글 요약 | 관련 파일 | 처리 방식 | 위험도 | 필요한 검증 | Codex가 바로 고쳐도 되는지 |
|---|---|---|---|---|---|---|

처리 방식은 아래 중 하나로만 적어 주세요.
- 바로 수정
- 테스트 먼저
- 설계 확인 필요
- 리뷰어 질문 필요
- 보류

규칙:
- 코드를 수정하지 마세요.
- 위험도는 낮음, 중간, 높음 중 하나로 적어 주세요.
- 같은 원인의 댓글은 묶고, 서로 충돌하는 댓글은 따로 표시해 주세요.
- 마지막에 "첫 번째로 처리할 수정 묶음"만 1개 추천해 주세요.

이 표가 있으면 Codex의 작업 범위가 좁아집니다. 예를 들어 버튼 라벨 오타와 테스트 실패는 같은 "수정"처럼 보여도 검증 방식이 다릅니다. 오타는 화면 확인이면 충분할 수 있지만, 테스트 실패는 실패 재현 조건을 먼저 확인하는 흐름이 필요합니다. 우선순위표는 이런 차이를 한눈에 드러냅니다.

첫 번째 묶음만 고치게 해야 diff가 작아집니다

우선순위표를 받았으면 바로 전체 표를 처리시키지 않습니다. 첫 번째 묶음만 고치게 합니다. Codex Best practices는 변경 뒤 테스트, 체크, 리뷰까지 요청하라고 안내합니다. 그래서 패치 요청에도 완료 조건을 넣어야 합니다.

위 우선순위표에서 "첫 번째로 처리할 수정 묶음"만 반영해 주세요.

범위:
- 우선순위 {번호}에 해당하는 댓글만 처리합니다.
- 관련 파일은 {파일명}으로 제한합니다.
- 다른 댓글을 해결하려고 추가 리팩터링하지 않습니다.
- 정보가 부족하면 코드를 추측해서 바꾸지 말고 질문을 남깁니다.

완료 조건:
- 변경한 파일과 이유를 표로 요약합니다.
- 실행한 테스트 또는 실행하지 못한 테스트를 적습니다.
- 남은 PR 댓글을 "완료, 남음, 질문 필요"로 다시 분류합니다.
- diff에서 리뷰어가 다시 확인해야 할 지점을 3줄 이내로 적습니다.

여기서 중요한 문장은 첫 번째 묶음만 반영입니다. Codex가 좋은 방향으로 넓혀 고치더라도, PR 리뷰에서는 넓은 diff가 새 검토 비용이 됩니다. 작은 묶음으로 나누면 리뷰어도 "이 커밋은 댓글 2개를 해결한다"는 식으로 확인할 수 있습니다.

Tap to zoom

질문 묶음은 코드보다 먼저 문장으로 정리합니다

리뷰어 댓글 중에는 바로 고치면 안 되는 것도 있습니다. "이 구조가 맞나요?", "이 훅을 분리하는 게 낫지 않나요?", "이 API 이름이 어색합니다" 같은 댓글은 팀 기준이나 제품 의도가 필요할 수 있습니다. 이런 댓글을 코드로 먼저 해석하면, 맞을 수도 있지만 되돌릴 가능성도 큽니다.

그럴 때는 아래처럼 질문만 만들게 합니다.

우선순위표에서 "리뷰어 질문 필요" 또는 "설계 확인 필요"로 분류한 댓글만 모아 주세요.

출력:
| 댓글 요약 | 내가 이해한 선택지 | 바로 고치면 생길 위험 | 리뷰어에게 물어볼 질문 |
|---|---|---|---|

규칙:
- 코드 수정안은 만들지 마세요.
- 질문은 리뷰어가 A/B 중 하나를 고를 수 있게 짧게 씁니다.
- 이미 코드로 확인 가능한 내용과 사람 판단이 필요한 내용을 분리해 주세요.

OpenAI Codex Review 안내는 review pane이 Git 저장소 변경 상태와 PR 피드백 맥락을 보여 주고, 줄별 피드백이 Codex의 다음 작업 맥락이 된다고 설명합니다. 그래서 댓글을 그대로 "수정 지시"로 쓰기보다, 줄별 의도와 검증 조건을 짧게 정리해 넘기는 편이 낫습니다.

위험한 댓글은 별도 작업으로 떼어 둡니다

파일 여러 개를 건드리는 리팩터링, 공개 API 이름 변경, 데이터 구조 변경, 인증·결제·권한 관련 코드는 한 묶음에 섞지 않습니다. 이런 댓글은 "바로 수정"이 아니라 "별도 작업"으로 보냅니다. Codex app의 Worktrees 안내는 독립 작업을 서로 방해하지 않게 진행할 때 worktree가 도움이 된다고 설명합니다. 실제 운영에서도 큰 수정은 작은 댓글 처리와 분리하는 편이 검토가 쉽습니다.

다음 기준 중 하나라도 맞으면 이번 패치 묶음에서 빼세요.

• 관련 파일이 4개 이상입니다.
• 테스트가 없거나 실패 재현이 불명확합니다.
• 리뷰어 댓글끼리 서로 다른 설계를 요구합니다.
• public API, 데이터 스키마, 인증, 결제, 권한 흐름을 건드립니다.
• "하면 좋겠다" 수준의 개선과 버그 수정이 같은 묶음에 들어 있습니다.

코드가 바뀐 뒤에는 AI 코드 diff를 그대로 믿기 전 검수하는 프롬프트로 한 번 더 확인하면 됩니다. PR 댓글 처리는 "고치기"보다 "고친 범위가 댓글과 맞는지 확인하기"가 더 중요할 때가 많습니다.

마지막으로 Codex에게 보내는 한 줄을 남깁니다.

지금은 전체 PR 댓글을 고치지 말고, 댓글별 우선순위표와 첫 번째 수정 묶음의 검증 조건만 먼저 만들어 주세요.

이 한 줄이 있으면 Codex는 바로 손을 대기보다 작업을 나눕니다. 그리고 사용자는 큰 diff를 받은 뒤 되돌리는 대신, 작고 검증 가능한 수정부터 받아볼 수 있습니다.