AI로 개발을 시작하면서 편리하다고 느꼈던 점은, 작업을 맡겨 두고 나중에 결과를 확인할 수 있다는 것이었습니다. 기능을 설명하면 Codex가 코드를 수정하고 테스트를 실행합니다. 특히 Codex Remote를 사용하면 PC 앞에 앉아 있지 않아도 휴대전화에서 작업을 이어갈 수 있었습니다.
그런데 실제로 여러 프로젝트를 개발하다 보니 뜻밖의 불편함이 생겼습니다.
작업을 맡겨 놓았는데, Codex가 승인 요청에서 멈춰 있는 경우가 반복된 것입니다.
자동화했는데, 승인 버튼에서 멈췄다
처음에는 파일을 수정하거나 명령을 실행할 때마다 승인을 확인했습니다. AI 개발 도구가 사용자 컴퓨터에서 작업하는 만큼 권한을 제한하는 절차는 당연히 필요하다고 생각했습니다.
문제는 비슷한 작업이 반복될 때였습니다. 코드를 수정하고 테스트하는 과정에서 승인 창이 나타나고, 제가 응답하지 않으면 다음 단계로 진행하지 못했습니다. 외부에서 Codex Remote로 작업할 때는 나중에 완료 결과를 확인할 생각으로 맡긴 일이 중간에 멈춰 있어 더 아쉬웠습니다.
지금까지 대부분의 요청은 제가 승인할 작업이었습니다. 그래서 한 가지 질문이 생겼습니다.
안전을 위한 제한은 유지하면서, 반복적인 승인 대기만 줄일 수는 없을까?
샌드박스와 승인 정책은 서로 다르다
처음 ONSEMO 개발 환경을 구성할 때부터 Windows 전체에 AI 도구의 권한을 넓게 주고 싶지는 않았습니다. 그래서 프로젝트 파일을 WSL2 Ubuntu에서 관리하고, Codex에도 작업 범위를 제한하는 방식을 선택했습니다.
여기서 구분해야 할 개념이 두 가지 있습니다.
| 구분 | 무엇을 제어하나? | 예시 |
|---|---|---|
| 샌드박스(Sandbox) | 파일·프로세스·네트워크 등 실행 가능한 작업 범위 | workspace-write |
| 승인 정책(Approval) | 특정 요청이 발생했을 때 누가 검토할지 | on-request, auto_review |
승인 요청을 줄인다고 반드시 샌드박스를 해제해야 하는 것은 아닙니다. 반대로 자동 검토가 켜져 있다고 해서 제한된 경로에 자동으로 접근할 수 있게 되는 것도 아닙니다.
WSL2 자체도 Windows와 완전히 분리된 보안 경계는 아닙니다. 운영체제의 경계, Codex 샌드박스, 승인 절차를 각각 확인해야 합니다.
Auto-review를 적용해 보았다
Codex의 사용자 설정 파일은 일반적으로 ~/.codex/config.toml입니다. 현재 사용 중인 버전에서 지원 여부를 확인한 뒤 아래 설정을 적용했습니다.
approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"핵심은 approval_policy = "never"로 바꾸지 않았다는 점입니다. 필요한 승인 요청은 계속 발생할 수 있지만, 대상 요청을 자동 검토자가 판단하도록 한 것입니다.
이것은 '모두 자동 승인'이 아닙니다. 자동 검토가 샌드박스의 권한 경계를 바꾸거나 모든 요청을 안전하게 처리한다고 보장하지도 않습니다. 코드 실행의 실제 범위와 사람이 지켜야 할 운영 원칙은 그대로 남습니다.
설정을 적용할 때는 기존 파일을 백업하고, 네트워크·SSH·원격 접속에 필요한 값을 임의로 초기화하지 않았습니다. 적용 후 실제 설정값도 다시 점검했습니다.
실제 사용에서 체감한 변화
설정 이후 개발 작업을 이어가 보니 승인 요청 때문에 멈추는 빈도가 확실히 줄었습니다. 원격에서 작업을 맡겨 두고 결과를 확인하는 과정도 이전보다 편해졌습니다.
다만 전후 요청 건수를 정량적으로 기록한 것은 아닙니다. 여기서 말하는 개선은 실제 사용 중 체감한 결과입니다. 또한 모든 작업이 무조건 자동 진행되지는 않았습니다.
특히 Android 프로젝트의 Gradle 테스트와 Debug APK 빌드에서는 여전히 승인 창이 나타났습니다. 이 문제는 단순히 Auto-review의 검토 기준을 더 느슨하게 바꾸면 해결되는 걸까요?
뒤이어 확인한 답은 조금 달랐습니다.
여전히 승인받아야 하는 작업이 있다
저는 평소 파일 읽기·수정·로컬 검증과 인증정보 접근·Release 서명·운영 배포를 같은 수준으로 취급하지 않으려고 합니다.
- 프로젝트 내부의 일반적인 검사와 테스트는 가능한 한 기존 샌드박스 안에서 실행합니다.
- 인증정보, 개인 파일, 외부 경로 쓰기, 파괴적인 Git 작업은 별도로 검토합니다.
- 운영 배포는 로컬 직접 배포 대신 검증된 커밋을 GitHub에 push하고 Cloudflare Git 연동으로 진행합니다.
Auto-review는 이런 운영 기준을 대신해 주는 만능 보안 장치가 아닙니다. 사람이 의도한 권한 범위를 먼저 정해 두고, 그 범위 안에서 불필요한 대기를 줄이는 도구에 가깝습니다.
여러 프로젝트에 적용할 때 주의할 점
~/.codex/config.toml은 동일한 사용자 계정의 Codex CLI가 공통으로 참고하는 설정입니다. 같은 WSL2 Ubuntu 환경에서 여러 저장소를 작업할 때 일관된 기본 정책을 사용하는 데 도움이 됩니다.
다만 별도 PC나 원격 실행 환경에는 자동으로 복제되지 않습니다. 세션 실행 옵션이나 프로젝트별 설정이 공통 값을 덮어쓸 수도 있으므로 실제 적용 설정을 확인하는 것이 좋습니다.
마무리: 승인 알림을 없애는 것이 목표는 아니다
이번 1차 개선으로 반복적인 승인 대기는 확실히 줄었습니다. 하지만 몇몇 개발 검증에서는 여전히 중단이 발생했습니다.
그때 제가 처음 생각한 방법은 자동 승인 범위를 더 넓히는 것이었습니다. 그런데 원인을 자세히 분석해 보니 문제는 다른 곳에 있었습니다.
권한을 더 주기 전에, 현재 허용된 범위에서 실행하는 방법부터 찾아보는 것.
다음 글에서는 Android 테스트가 왜 추가 승인을 요구했는지 분석하고, '항상 승인'을 누르지 않은 채 재사용 가능한 검증 절차를 만든 과정을 정리했습니다.
2편: Codex '항상 승인' 없이 반복적인 개발 작업을 자동화할 수 있을까?
참고 문서
실제 사용 경험을 바탕으로 AI의 작성 보조를 받아 정리했습니다. 승인 정책과 기능은 Codex 버전 및 실행 환경에 따라 달라질 수 있습니다.