Codex로 코드 리뷰 받기: 혼자 개발할 때 리뷰어를 대신하는 활용 패턴

혼자 개발하면 코드가 동작하는 순간과 안전하게 유지되는 순간 사이에 빈틈이 생깁니다. 조코헌트에 출시된 프로덕트 208개를 보면 출시 첫 24시간 안에 업보트나 댓글 같은 반응을 하나라도 받은 경우는 69%지만, 댓글을 받은 프로덕트는 37%입니다. 피드백을 기다릴 수만은 없는 이유입니다. 이때 Codex를 ‘정답을 알려주는 심판’보다 변경분을 다른 각도에서 읽어주는 리뷰 파트너로 쓰면 좋습니다.

1. 리뷰를 시작하기 전에 변경분을 작게 고정하기

리뷰 대상과 기준 남기기

먼저 이번 작업의 목적, 건드린 파일, 기대 동작, 건드리면 안 되는 범위를 짧게 적습니다. 예를 들면 “로그인 실패 시도 제한을 추가했고, 기존 성공 흐름과 데이터 형식은 유지한다”처럼 씁니다. 프로젝트의 규칙은 AGENTS.md 작성법처럼 별도 문서에 모아두면 매번 같은 설명을 반복하지 않아도 됩니다.

Codex에게는 저장소 전체를 막연히 살펴보라고 하기보다 현재 변경분(diff)과 관련 테스트를 우선 보라고 요청하세요. 변경 범위가 커졌다면 기능 단위로 나누어 커밋하거나 임시 diff를 만든 뒤 리뷰하는 편이 결과를 해석하기 쉽습니다.

diff를 읽기 좋은 상태 만들기

리뷰 직전에는 포맷팅만 바뀐 파일, 생성물, 비밀값이 들어간 설정 파일을 구분합니다. 리뷰 요청에 다음 정보를 함께 붙이면 좋습니다.

• 변경 목적과 사용자가 겪는 시나리오
• 관련된 API, 데이터베이스 테이블, 권한 규칙
• 실행한 테스트와 아직 확인하지 못한 항목
• 특히 걱정되는 실패 조건

2. 한 번에 하나의 관점으로 Codex 호출하기

버그·보안·중복을 한 프롬프트에 전부 넣으면 중요한 지적이 섞일 수 있습니다. 같은 diff를 관점별로 여러 번 읽게 하되, 매번 출력 형식을 고정하세요.

버그 리뷰 프롬프트

“이 diff를 기능 버그 관점에서 리뷰해줘. 정상 흐름뿐 아니라 빈 입력, 중복 요청, 권한 없는 사용자, 네트워크 실패, 오래된 데이터가 들어오는 경우를 확인해줘. 각 지적마다 파일과 위치, 재현 조건, 실제 영향, 확신 정도를 적고 문제를 찾지 못한 영역도 밝혀줘”처럼 요청합니다.

핵심은 ‘문제가 있나?’가 아니라 실패 시나리오를 열거하게 하는 것입니다. 리뷰 결과가 나오면 “이 지적을 재현할 최소 테스트를 작성해줘. 테스트가 실패해야 하는 이유도 설명해줘”라고 이어서 물어보세요.

보안 리뷰 프롬프트

보안 리뷰에서는 인증·인가를 혼동하지 않았는지, 사용자가 보낸 값을 신뢰하는지, 로그와 에러 메시지에 민감한 정보가 노출되는지, 외부 요청과 파일 접근 경계가 안전한지 확인하게 합니다. “공격 방법을 과장하지 말고, 현재 코드에서 근거가 보이는 위험만 심각도와 함께 분류해줘”라는 제약도 유용합니다.

Codex의 보안 지적은 참고 목록입니다. 프레임워크 버전이나 배포 환경에 따라 판단이 달라질 수 있으므로 실제 설정과 공식 문서를 함께 확인하세요. 실행 권한과 승인 범위를 고민한다면 Codex 샌드박스와 승인 모드 이해하기도 같이 참고할 수 있습니다.

중복·유지보수 리뷰 프롬프트

“새 코드가 기존 유틸리티나 도메인 규칙을 중복 구현하는지, 이름이 실제 책임과 맞는지, 다음 변경 때 깨질 결합이 있는지 찾아줘. 지금 고칠 가치가 있는 것과 나중에 기록만 할 것을 나눠줘”라고 요청합니다.

이 관점에서는 모든 중복을 제거하려 하지 않는 것이 중요합니다. 아직 요구사항이 흔들리는 MVP라면 작은 중복이 추상화보다 쌀 때도 있습니다. 반대로 결제·권한·데이터 변환처럼 여러 곳에서 같은 규칙을 적용해야 하는 코드는 중복이 사고로 이어지기 쉬우니 우선순위를 높입니다.

3. 결과를 이슈로 바꾸는 후속 질문

심각도와 재현 조건 묻기

리뷰 목록을 받은 뒤 “이 문제는 어떤 사용자에게 언제 발생하나?”, “현재 테스트로 재현 가능한가?”, “수정하지 않고 출시했을 때의 최악의 결과는 무엇인가?”를 차례로 묻습니다. 그 답이 모호하면 경고로만 기록하고, 재현 가능하고 영향이 큰 항목부터 고칩니다.

출시 판단을 함께 점검하고 싶다면 바이브코딩으로 만든 MVP, 출시해도 될까의 기준과 연결해 보세요. 코드 리뷰는 출시 여부를 대신 결정하는 절차가 아니라, 결정에 필요한 불확실성을 줄이는 절차입니다.

수정안은 별도 요청하기

처음부터 “찾고 고치고 테스트까지 전부 해줘”라고 하면 문제 설명과 수정안이 한꺼번에 섞입니다. 먼저 리뷰를 고정한 다음, 선택한 항목만 “가장 작은 수정으로 해결하고 관련 테스트를 추가해줘. 수정 전후의 동작 차이를 요약해줘”라고 요청하세요. 수정 후에는 원래 diff와 새 diff를 다시 비교합니다.

4. 리뷰 결과를 검증하는 마지막 루틴

테스트로 확인하기

최소한 지적된 재현 테스트, 기존 핵심 테스트, 타입 체크와 린트를 실행합니다. 테스트가 없으면 수동 확인 절차를 시나리오로 적고 직접 실행하세요. Codex가 “문제 없음”이라고 말한 경우에도 같은 루틴을 적용해야 합니다. 침묵은 안전의 증거가 아닙니다.

사람이 판단할 경계

AI는 코드에 드러난 규칙은 잘 요약하지만, 실제 사용자의 기대나 운영상의 우선순위까지 자동으로 알지는 못합니다. 따라서 최종 확인은 다음 세 질문으로 마무리합니다.

• 이 변경이 원래 문제를 정말 해결했는가?
• 실패했을 때 복구하거나 되돌릴 방법이 있는가?
• 리뷰에서 다루지 않은 외부 시스템과 정책의 가정은 없는가?

혼자 만드는 제품에서 좋은 리뷰 루틴은 완벽한 검사를 약속하는 방식이 아닙니다. 작은 diff를 만들고, 관점을 나눠 질문하고, 결과를 테스트와 사람의 판단으로 좁혀가는 반복 가능한 안전장치에 가깝습니다.