승인(Approvals)과 샌드박스(Sandbox): 안전하게 자동화하기

Codex를 빠르게 쓰는 팀과 오래 쓰는 팀의 차이는 "프롬프트 실력"보다 권한 설계를 먼저 했는지에서 갈립니다. 자동화는 속도를 올리지만, 잘못된 한 번의 실행은 레포를 망가뜨리거나(대량 삭제·덮어쓰기), 의도치 않은 외부 통신(패키지 설치·원격 API 호출)으로 이어질 수 있습니다. 그래서 Codex의 생산성을 제대로 얻으려면, 먼저 멈추는 지점(승인)과 닿을 수 있는 범위(샌드박스)를 분리해서 설계해야 합니다.¹

이 장의 목표는 다음 세 가지를 한 번에 붙여 이해하는 것입니다.

• Chat/Agent/Full access라는 자율성(autonomy) 레벨

• approval_policy로 정하는 멈춤(승인) 규칙

• sandbox_mode로 정하는 접근(파일·명령·네트워크) 경계

1) 3단계 권한 모델: Chat → Agent → Full access

이 절의 Chat → Agent → Full access는 Codex에 고정된 '공식 모드 이름'이라기보다, 팀이 권한을 합의할 때 유용한 사고 프레임(자율성 레벨)입니다. 실제로는 --sandbox, --ask-for-approval(또는 설정 파일의 해당 값) 조합으로 이 레벨을 구현한다고 생각하면 됩니다.¹²

Chat(대화 중심)

• 목표: 코드를 읽고 이해·설계한다.

• 권장 감각: 읽기 위주로 시작하고, 실행/편집은 필요할 때만 승인으로 열어준다.

Agent(작업 수행 중심)

• 목표: 워크스페이스 안에서 수정→테스트→diff 루프를 돌린다.

• 권장 감각: "레포 안에서는 자동으로, 바깥/네트워크는 멈춤"을 기본값으로 둔다.

Full access(완전 자동화)

• 목표: CI/격리 환경에서 승인 없이 끝까지 돌린다.

• 권장 감각: 승인 프롬프트를 최소화(또는 제거)하되, 그만큼 격리(컨테이너/일회성 러너), 최소 권한, 로그/감사 가능성을 함께 챙긴다.

정리하면,

• 승인(Approvals)은 "멈출지 말지(누가 결정하는지)"를 정하고

• 샌드박스(Sandbox)는 "닿을 수 있는 범위(피해 반경)"를 정합니다.

둘을 섞어 생각하면 설정이 늘 헷갈립니다. 분리해서 보면 원하는 자동화 수준을 조합으로 설계할 수 있습니다.¹

2) approval_policy: 언제 멈출 것인가

approval_policy는 Codex가 행동(파일 편집/명령 실행/네트워크 접근 등)을 하려 할 때 사용자 승인을 어느 타이밍에 요구할지를 정합니다. 실무에서 중요한 건 "항상 물어보게"가 아니라, 어떤 위험 신호에서 멈추게 할지입니다.

아래는 자주 쓰는 정책들의 성격을 작업 감각으로 풀어쓴 것입니다.

여기서 꼭 기억해야 할 포인트가 하나 있습니다. 승인 프롬프트를 꺼도 샌드박스는 그대로 남을 수 있다는 점입니다. 문서에서도 --ask-for-approval never로 모든 승인 프롬프트를 끌 수 있지만, 그 옵션은 어떤 --sandbox와도 함께 동작해 "자율성"을 단계적으로 고를 수 있다고 설명합니다.¹

즉 approval_policy = "never"는 "무제한 권한"이 아니라, "멈춤이 없다"에 가깝습니다. 무제한에 가까워지는 건 보통 샌드박스까지 풀었을 때입니다.

3) sandbox_mode: 어디까지 만질 것인가

approval_policy가 브레이크라면, sandbox_mode는 울타리입니다. 울타리가 작으면 브레이크가 고장 나도 피해가 제한됩니다. 그래서 자동화를 강하게 쓰려면, 보통 승인 정책보다 샌드박스 경계를 먼저 설계하는 편이 안전합니다.¹

실무에서 자주 쓰는 샌드박스 감각은 보통 아래 세 가지로 정리됩니다(이름/세부 권한은 버전에 따라 달라질 수 있으니 codex --help와 공식 레퍼런스를 우선 확인하세요).²

• read-only: 읽기 중심. 탐색/리뷰/감사에 적합.

• workspace-write: 워크스페이스(레포) 안에서만 쓰기/실행을 허용하는 방향의 기본값.

• danger-full-access: 시스템 전반에 가까운 접근. 격리 환경에서만 고려.

메모: "네트워크는 기본 차단, 필요할 때만 명시적으로 허용"은 안전한 운영의 보편적인 원칙입니다. 다만 네트워크를 켜는 정확한 설정 키/플래그는 릴리스마다 바뀔 수 있으니, 팀 표준은 문서/codex --help로 확정한 뒤 config 프로파일로 고정하는 것을 권합니다.

4) 상황별 조합 레시피: "업무"에 맞춘 가드레일

이제부터는 개념보다 실전이 중요합니다. 같은 팀이라도 "리뷰/탐색/개발/자동화"는 위험도가 다르므로, 업무 단위로 레벨을 바꾸는 것이 가장 현실적인 가드레일입니다.¹

4.1 코드 읽기·보안 점검(가장 안전)

레포를 처음 열었거나, 보안 이슈를 점검하는 날에는 Chat에 가깝게 시작합니다.

codex --sandbox read-only --ask-for-approval on-request

이 조합은 "파일 읽기와 설명"은 빠르게 하되, 편집/명령 실행/네트워크는 승인을 통해서만 진행하게 만듭니다.¹

4.2 신규/미검증 프로젝트에서의 탐색(보수적 시작)

버전 관리가 없거나(다운로드 폴더, 홈 디렉터리), 작업 범위가 불명확한 곳에서는 실수 한 번의 비용이 커집니다. 문서에서도 버전 관리 여부에 따라 권장 모드를 다르게 제시합니다(버전 관리 폴더는 Auto, 비버전 관리 폴더는 Read Only).¹

이때는 read-only + 승인으로 설계를 먼저 끝낸 뒤, "수정은 브랜치를 만든 다음"처럼 절차를 추가하는 게 좋습니다.

4.3 일상 개발(균형형 Agent)

가장 많이 쓰는 조합은 다음입니다.

codex --sandbox workspace-write --ask-for-approval on-request

워크스페이스 안에서는 작업이 매끄럽고, 밖으로 나가거나 네트워크가 필요하면 멈춥니다.¹

4.4 테스트/포맷/리팩터링을 빠르게 반복(속도 우선 Agent)

신뢰하는 레포에서 "샌드박스가 막을 때만 잠깐 확인"하는 흐름은 체감 속도가 확 올라갑니다.

codex --full-auto

문서 기준으로 --full-auto는 --sandbox workspace-write와 --ask-for-approval on-failure의 조합으로 설명됩니다.¹

4.5 의존성 설치·원격 API 테스트(네트워크 필요)

네트워크가 필요해지는 순간 위험도가 올라갑니다. 그래서 네트워크는 "항상 켜두기"보다, 필요한 작업에만 명시적으로 켜는 편이 낫습니다.

중요한 건 '어떤 플래그/설정 키로 켜느냐'보다 원칙입니다.

• 가능한 한 workspace-write 같은 제한된 샌드박스를 유지한다.

• 네트워크를 켠 세션/잡은 결과물을 더 꼼꼼히 리뷰한다.

• 팀에서는 네트워크 허용이 필요한 작업을 프로파일로 분리해(예: profile = "net") 실행 자체가 눈에 띄게 만든다.

네트워크 허용 방법은 버전별로 다를 수 있으니, 이 책의 예시를 그대로 복사하기보다 현재 사용하는 Codex 버전의 공식 레퍼런스를 기준으로 확정하세요.²

4.6 CI/대량 자동화(Full access에 가까운 단계는 격리 환경에서)

승인 프롬프트가 뜨면 CI는 멈춥니다. 그래서 approval_policy = "never"가 필요해지지만, 그럴수록 샌드박스·환경 격리·권한 분리가 필수입니다.¹

가장 위험한 형태는 샌드박스와 승인을 모두 우회하는 조합입니다. 문서에서도 "No sandbox; no prompts"로 표시하며 권장하지 않는다고 못 박습니다.¹

격리된 환경에서 네트워크 포함 전권이 필요하다면 danger-full-access를 사용하라고 안내합니다.²

5) 가드레일 설계 순서: '승인'보다 '경계'를 먼저

현장에서 흔한 실수는 이겁니다.

• "승인만 잘 받으면 안전하겠지"라고 생각하고 샌드박스를 느슨하게 둔다.

• 그러다 승인 프롬프트에 익숙해져 무심코 허용한다.

반대로 잘 되는 팀은 순서가 반대입니다.

1. 샌드박스로 피해 반경을 먼저 줄입니다.

2. 승인 정책을 업무 리듬에 맞춥니다. '항상 승인'은 결국 우회를 부릅니다. "워크스페이스 밖으로 나갈 때", "네트워크가 필요할 때", "실패/에러가 났을 때"처럼 위험 신호에서만 멈추게 하는 게 지속 가능한 운영입니다.¹

3. 권한은 점진적으로 넓힙니다. 보수적으로 시작하고, 익숙해지면 단계적으로 완화합니다.

핵심 메시지는 단순합니다. 에이전트는 확률적으로 행동하고, 프롬프트만으로 통제하는 데에는 한계가 있습니다. 그래서 규칙은 '프롬프트'보다 경계(boundary)에서 더 잘 작동합니다.

6) 팀 운영 체크리스트: 속도와 안전을 같이 얻는 최소 장치

권한 설계를 한 번 해두면, 이후 자동화는 훨씬 빨라집니다. 다음 항목은 "큰 비용 없이" 효과가 큰 것들입니다.

• 업무별 프로파일을 고정한다. read-only(탐색), workspace-write(개발), full-auto(반복 작업)처럼 이름 있는 프리셋으로 합의해두면, 누가 실행해도 위험도가 예측 가능합니다.¹

• 네트워크는 기본 차단, 필요할 때만 열린다. 특히 설치/업데이트/원격 호출이 섞인 작업은 "네트워크를 켠 세션" 자체를 의식적으로 관리해야 합니다.¹

• 감사 가능성을 남긴다. 무엇을 실행했고 무엇이 바뀌었는지 기록이 남아야 사고가 "학습 가능한 사건"이 됩니다. 정책·승인·감사 로그를 함께 다루는 접근이 왜 필요한지는, 도구 호출을 정책으로 감싸고 승인/감사를 남기는 라이브러리들이 반복해서 강조하는 지점이기도 합니다.⁶

권한 설계를 먼저 하면, Codex는 '위험한 자동화'가 아니라 통제 가능한 자동화가 됩니다. 그리고 통제 가능해지는 순간부터 속도는 자연스럽게 따라옵니다.

참고

¹Codex CLI features (approvals, sandbox) — OpenAI Developers

²Codex CLI reference / command line options — OpenAI Developers

³openai/codex (GitHub)

⁴CLI 옵션 치트시트(커뮤니티; codex --help로 반드시 검증)