Codex auto-review 설정법: 승인 대기 줄이되 샌드박스 경계는 그대로 이해하기 | DAKER 커뮤니티
Codex를 쓰다 보면 작업 자체보다 승인 팝업을 처리하는 데 더 많은 흐름이 끊길 때가 있습니다. 특히 비슷한 종류의 낮은 위험 요청이 반복되면, 정작 사람이 직접 봐야 할 중요한 승인 포인트를 놓치기 쉬워집니다.
이럴 때 눈에 들어오는 기능이 auto-review입니다. 다만 이 기능은 권한을 더 주는 설정이 아니라, 승인 요청을 누가 검토할지를 바꾸는 설정입니다. 승인 대기를 줄이고 싶다면 속도보다 먼저 경계가 어디까지 유지되는지 이해하는 것이 좋습니다.
Codex auto-review는 무엇을 바꾸고, 무엇은 바꾸지 않을까요?
Codex auto-review 설정은 승인 요청을 사람 대신 reviewer subagent가 검토하게 해 작업 멈춤을 줄이는 방식입니다. 2026년 7월 29일 KST 기준 OpenAI 공식 문서는 auto-review가 승인 경계에서 사람의 수동 검토를 별도 reviewer agent 검토로 바꾸는 방식이라고 설명합니다.
auto-review는 더 많은 일을 허용하는 스위치가 아니라, 허용을 검토하는 사람을 바꾸는 스위치입니다.
중요한 한계도 분명합니다. auto-review는 샌드박스, 네트워크, writable roots, 도구 권한을 넓혀 주는 기능이 아닙니다. 따라서 팀에서는 기능을 켜기 전에 승인 정책과 샌드박스 경계를 먼저 확인하는 편이 안전합니다.
승인 프롬프트가 많아지면 왜 작업이 느려질까요?
코드베이스 탐색, 테스트 실행, 파일 생성, 외부 도구 호출을 섞어 맡기면 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는 반복적인 승인 확인 때문에 작업 흐름이 자주 끊길 때 특히 유용합니다. 다만 모든 승인 요청을 자동화하려는 접근보다는, 반복되는 낮은 위험 요청만 자동 리뷰 대상으로 두는 편이 현실적입니다.
예를 들어 읽기 중심 작업이나 낮은 위험 테스트 실행처럼 되돌릴 수 있는 요청은 auto-review 후보가 될 수 있습니다. 반대로 배포, 삭제, 결제, 외부 메시지 전송처럼 외부 상태를 바꾸거나 되돌리기 어려운 요청은 사람이 직접 보는 기준을 유지하는 것이 좋습니다.
팀 설정은 어떤 순서로 점검하면 좋을까요?
설정값을 먼저 붙여 넣기보다, 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는 검토 주체를 바꾸는 기능일 뿐입니다. approval_policy가 never인 실행에서 추가 안전망처럼 동작한다고 기대해서도 안 됩니다.
또한 삭제, 배포, 결제, 외부 댓글 작성처럼 되돌리기 어려운 요청은 사람이 직접 보는 경로를 남겨 두는 것이 좋습니다. 거절된 요청을 다른 명령으로 우회하게 만드는 방식도 피해야 합니다. 공용 설정에 넣기 전에는 작은 저장소나 읽기 중심 작업에서 먼저 확인하고, 승인 결과와 실패 로그를 마지막 보고에 남겨 이후 기준을 조정하면 됩니다.
자주 묻는 질문
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 도구 사용법으로 읽기·수정·검증 흐름을 잡고, Codex MCP 도구 범위 설정으로 외부 도구 노출을 줄인 뒤, auto-review를 승인 대기 최적화 단계로 붙이는 순서가 잘 맞습니다.
참고 자료
공식 확인은 OpenAI Codex의 Auto-review 설명, Configuration Reference의 approvals_reviewer 항목, Codex changelog의 2026년 7월 관련 변경 기록을 기준으로 했습니다.
여러분의 작업 환경에서는 어떤 승인 요청까지 auto-review 후보로 볼 수 있을까요?