Codex auto-review 설정법: 승인 대기 줄이고 샌드박스 지키기 | DAKER 커뮤니티
Codex auto-review 설정은 승인 요청을 사람 대신 reviewer subagent가 검토하게 해 작업 멈춤을 줄이는 설정입니다. Auto-review란 샌드박스나 권한 경계를 없애는 기능이 아니라, 승인 검토자를 사용자에서 자동 리뷰 에이전트로 바꾸는 방식을 의미합니다. 오늘 승인 대기 때문에 작업이 자주 끊긴다면, 먼저 언제 켜도 되는지와 어디까지 믿으면 안 되는지를 확인해 보세요.
Codex auto-review 설정은 언제 도움이 될까요?
Codex auto-review 설정은 반복적인 승인 확인 때문에 작업 흐름이 자주 끊길 때 도움이 됩니다. 2026년 7월 29일 KST 기준 OpenAI 공식 문서는 auto-review가 승인 경계에서 사람의 수동 검토를 별도 reviewer agent 검토로 바꾸는 방식이라고 설명합니다. 중요한 한계는 분명합니다. auto-review는 샌드박스, 네트워크, writable roots, 도구 권한을 넓혀 주는 기능이 아닙니다.
한 줄 요약은 이렇습니다. auto-review는 “더 많은 일을 허용하는 스위치”가 아니라 “허용을 검토하는 사람을 바꾸는 스위치”입니다. 따라서 팀에서는 속도 개선보다 먼저 승인 정책과 샌드박스 경계를 확인해야 합니다.
문제 상황: 승인 프롬프트가 많으면 무엇이 느려질까요?
코드베이스 탐색, 테스트 실행, 파일 생성, 외부 도구 호출을 섞어 맡기면 Codex는 경계 밖 행동을 시도할 때 멈춰 승인 요청을 띄울 수 있습니다. 이 멈춤 자체는 나쁜 신호가 아닙니다. 작업이 어느 경계를 넘으려는지 사용자에게 보여 주는 안전 장치입니다.
하지만 같은 종류의 낮은 위험 요청이 계속 반복되면 사용자는 승인 팝업만 처리하다가 실제 검토 포인트를 놓치기 쉽습니다. 이때 auto-review를 좁은 조건에서 쓰면 반복 중단은 줄이고, 위험한 요청은 reviewer가 거절하도록 만들 수 있습니다.
핵심 개념: auto-review와 일반 승인은 무엇이 다를까요?
일반 승인은 사용자가 승인 요청을 직접 봅니다. auto-review는 적격 승인 요청을 reviewer subagent가 먼저 판단합니다. 다만 설정을 켜도 이미 허용된 작업은 그대로 실행되고, 애초에 approval_policy가 never라면 검토할 승인 요청이 없으므로 auto-review가 개입할 대상도 없습니다.
| 구분 | 무엇이 바뀌나요? | 무엇은 그대로인가요? |
|---|---|---|
| 일반 승인 | 사용자가 승인 요청을 직접 판단합니다. | 샌드박스와 권한 경계는 설정값을 따릅니다. |
| auto-review | reviewer subagent가 적격 승인 요청을 검토합니다. | 권한, writable roots, 네트워크 허용 범위는 넓어지지 않습니다. |
| approval_policy never | 승인 프롬프트가 뜨지 않습니다. | auto-review가 검토할 요청도 없습니다. |
| 거절된 요청 | Codex가 더 안전한 경로를 찾거나 중단해야 합니다. | 우회 실행으로 같은 결과를 만들면 안 됩니다. |
단계별 사용법: 팀 설정은 어떤 순서로 점검할까요?
설정값을 먼저 붙여 넣기보다, auto-review가 검토할 요청과 사람이 직접 볼 요청을 나누는 것이 좋습니다. 아래 순서로 시작하면 기능을 켜기 전에 실패 지점을 줄일 수 있습니다.
- 현재 작업의 sandbox_mode와 approval_policy를 확인합니다. auto-review는 승인 요청이 발생하는 정책에서만 의미가 있습니다.
- 반복적으로 뜨는 승인 요청을 읽기, 테스트 실행, 외부 쓰기, 파괴적 명령으로 분류합니다.
- 낮은 위험 반복 요청만 auto-review 후보로 두고, 배포, 삭제, 결제, 외부 메시지 전송은 사람이 직접 보는 기준을 유지합니다.
- config.toml에서 approvals_reviewer 값을 auto_review로 둘 범위를 사용자 전역인지 프로젝트 범위인지 정합니다.
- 작은 테스트 작업으로 승인, 거절, 로그 기록이 기대대로 남는지 확인합니다.
- 거절된 요청이 나오면 우회시키지 말고 더 좁은 명령이나 읽기 전용 대안으로 다시 요청합니다.
짧은 예시: config.toml에는 무엇을 적는다고 이해하면 될까요?
공개 본문에서는 실행용 코드 대신 의미만 정리하겠습니다. 핵심은 approvals_reviewer를 auto_review로 두면, on-request 또는 granular 승인 정책 아래의 적격 승인 요청을 reviewer subagent가 검토한다는 점입니다. 앱 도구에도 기본 reviewer를 정하거나 앱별 reviewer를 따로 지정할 수 있습니다.
실무에서는 “모든 승인을 자동화한다”보다 “반복되는 낮은 위험 승인만 자동 리뷰로 보내고, 외부 상태를 바꾸는 요청은 사람이 본다”가 더 안전합니다. 이 기준은 Codex MCP 도구 범위 설정처럼 도구 노출 범위를 먼저 줄인 뒤에 적용하면 헷갈림이 줄어듭니다.
실수 방지 체크리스트: auto-review를 켜기 전에 무엇을 막아야 할까요?
- auto-review가 sandbox_mode나 네트워크 권한을 넓힌다고 가정하지 않습니다.
- approval_policy가 never인 실행에서 auto-review가 추가 안전망처럼 동작한다고 기대하지 않습니다.
- 삭제, 배포, 결제, 외부 댓글 작성처럼 되돌리기 어려운 요청은 사람이 직접 보는 경로를 남깁니다.
- 거절된 요청을 다른 명령으로 우회하라고 지시하지 않습니다.
- 프로젝트 공용 설정에 넣기 전 작은 저장소나 읽기 중심 작업에서 먼저 확인합니다.
- 승인 결과와 실패 로그를 마지막 보고에 남기게 해 이후 반복 기준을 조정합니다.
공식 출처와 함께 볼 DAKER 글은 무엇인가요?
공식 확인은 OpenAI Codex의 Auto-review 설명, Configuration Reference의 approvals_reviewer 항목, Codex changelog의 2026년 7월 관련 변경 기록을 기준으로 했습니다. DAKER 공개 본문 정책상 외부 공식 문서 주소는 본문 링크로 넣지 않고, 이어서 볼 내부 링크만 남깁니다.
자주 묻는 질문
Codex auto-review를 켜면 사람이 승인을 전혀 보지 않아도 되나요?
아닙니다. auto-review는 적격 승인 요청의 검토자를 바꾸는 기능입니다. 팀이 사람이 직접 봐야 한다고 정한 고위험 요청은 별도 기준으로 남겨야 합니다.
approval_policy가 never이면 auto-review가 더 안전하게 막아 주나요?
그렇게 보면 안 됩니다. 공식 설명 기준으로 approval_policy가 never이면 검토할 승인 요청이 없으므로 auto-review가 개입할 대상도 없습니다.
reviewer subagent가 승인하면 샌드박스가 넓어지나요?
아닙니다. auto-review는 권한을 넓히지 않습니다. 승인된 요청도 기존 sandbox_mode, writable roots, 네트워크 정책 안에서만 의미가 있습니다.
처음 켤 때 가장 좋은 테스트는 무엇인가요?
읽기 중심 작업과 낮은 위험 테스트 실행처럼 되돌릴 수 있는 작업이 좋습니다. 그다음 외부 쓰기 요청이 실제로 사람 검토 경로에 남는지 확인하세요.
DAKER 코덱스 글을 같이 보면 어떤 순서가 좋나요?
먼저 Codex 도구 사용법으로 읽기·수정·검증 루프를 잡고, MCP 도구 범위 설정으로 외부 도구 노출을 줄인 뒤, auto-review를 승인 대기 최적화 단계로 붙이는 순서가 좋습니다.
오늘 Codex 작업이 승인 팝업에서 자주 멈춘다면, 먼저 반복 승인 요청 5개를 모아 “자동 리뷰 후보”와 “사람이 봐야 할 요청”으로 나눠 보세요.