권한, 샌드박스, 승인 모드 안전하게 다루기

Codex에게 열쇠를 맡기기 전에 알아야 할 것

지난 장에서 우리는 좋은 프롬프트의 기본 구조를 배웠습니다. 목표를 말하고, 맥락을 주고, 제약 조건을 걸고, 완료 기준을 정하면 Codex의 결과가 훨씬 좋아진다는 내용이었습니다. 그런데 한 가지가 더 남아 있습니다. 아무리 프롬프트를 잘 써도 Codex가 내 컴퓨터에서 어디까지 할 수 있는지를 모르면 불안합니다.

Codex는 단순히 답변만 하는 챗봇이 아닙니다. 프로젝트 파일을 읽고, 코드를 수정하고, 테스트 명령을 실행하고, 때로는 패키지를 설치하거나 네트워크에 접근하려고 합니다. 이 능력은 앱 개발을 빠르게 만들어 주지만, 동시에 위험도 함께 가져옵니다. 실수로 엉뚱한 폴더를 수정하거나, 원치 않는 패키지를 설치하거나, 민감한 파일을 읽게 할 수도 있기 때문입니다.

그래서 이 장의 핵심 문장은 이것입니다.

AI 에이전트에게 일을 많이 맡길수록 권한 관리는 선택이 아니라 필수다.

Codex를 안전하게 쓰려면 "믿을 만한 AI인가?"보다 먼저 "지금 이 AI가 내 컴퓨터에서 무엇을 할 수 있는가?"를 확인해야 합니다.

안전장치는 두 층으로 작동한다

Codex의 권한 관리는 크게 두 층으로 나눠 이해하면 쉽습니다. 첫 번째는 샌드박스 모드이고, 두 번째는 승인 정책입니다. 둘은 비슷해 보이지만 역할이 다릅니다.

샌드박스는 Codex가 기술적으로 할 수 있는 일을 제한합니다. 예를 들어 현재 프로젝트 폴더 안에만 파일을 쓸 수 있게 하거나, 네트워크 접근을 막거나, 작업 폴더 밖의 파일을 수정하지 못하게 막습니다. OpenAI의 Codex 문서에서도 샌드박스를 "Codex가 자율적으로 행동하더라도 내 컴퓨터 전체 권한을 넘겨주지 않게 해 주는 경계"로 설명합니다.¹

승인 정책은 Codex가 언제 멈추고 사용자에게 물어봐야 하는지를 정합니다. 예를 들어 Codex가 작업 폴더 밖의 파일을 수정하려고 할 때, 네트워크를 쓰려고 할 때, 위험한 명령을 실행하려고 할 때 "진행해도 될까요?"라고 묻게 만드는 규칙입니다. 공식 보안 문서에서도 Codex의 안전 제어는 샌드박스와 승인 정책이 함께 동작하는 구조라고 설명합니다.²

초보자에게는 이렇게 기억하면 충분합니다.

• 샌드박스는 "Codex가 실제로 어디까지 할 수 있는가"를 정한다.

• 승인 정책은 "그 일을 하기 전에 나에게 물어보는가"를 정한다.

• 안전한 설정은 이 둘을 함께 조합해서 만든다.

예를 들어 Codex에게 "테스트 실패를 고쳐줘"라고 요청했다고 해 봅시다. 샌드박스가 workspace-write라면 Codex는 현재 프로젝트 안의 파일을 수정하고 npm test 같은 로컬 명령을 실행할 수 있습니다. 하지만 네트워크가 막혀 있다면 npm install로 새 패키지를 내려받는 일은 자동으로 하지 못합니다. 이때 승인 정책이 on-request라면 Codex는 "패키지 설치를 위해 네트워크 접근이 필요합니다. 승인하시겠습니까?"처럼 멈춰서 물어봅니다.

이 조합이 중요한 이유는 간단합니다. Codex가 빠르게 일하도록 허용하되, 피해가 커질 수 있는 순간에는 사람이 다시 운전대를 잡을 수 있기 때문입니다.

세 가지 샌드박스 모드: 읽기 전용, 작업 폴더 쓰기, 완전 접근

Codex CLI와 IDE 확장에서는 대표적으로 read-only, workspace-write, danger-full-access 같은 샌드박스 모드를 사용합니다. 이름이 조금 무섭게 느껴질 수 있지만, 실제 작업 기준으로 구분하면 어렵지 않습니다.

read-only는 읽기 전용 모드입니다. Codex가 코드를 읽고 구조를 설명하거나, 변경 계획을 세우거나, 리뷰 의견을 제안하는 데 적합합니다. 초보자가 처음 보는 프로젝트를 열었을 때 가장 안전한 모드입니다. "이 프로젝트 구조를 설명해줘", "로그인 기능이 어디에 있는지 찾아줘", "수정 계획만 세워줘" 같은 요청에는 읽기 전용으로도 충분합니다.

workspace-write는 현재 작업 폴더 안에서 읽고 쓰는 모드입니다. 일상적인 앱 개발의 기본값으로 생각하면 됩니다. Codex는 현재 프로젝트 안의 파일을 수정하고, 테스트나 빌드 같은 로컬 명령을 실행할 수 있습니다. 다만 기본적으로 네트워크 접근은 꺼져 있으며, 작업 폴더 밖의 파일을 수정하려는 경우에는 승인이 필요합니다. Codex CLI/IDE의 기본 가드레일도 네트워크를 차단하고 쓰기 권한을 활성 작업 영역으로 제한하는 방향입니다.²

danger-full-access는 이름 그대로 위험한 완전 접근 모드입니다. 이 모드에서는 파일 시스템과 네트워크 제한이 크게 풀릴 수 있습니다. 즉, Codex가 프로젝트 바깥의 폴더, 개인 홈 디렉터리, 민감한 설정 파일, 시스템 명령에 더 넓게 접근할 위험이 생깁니다. 격리된 컨테이너나 VM, 버려도 되는 실험용 저장소처럼 피해 범위가 제한된 곳이 아니라면 기본값으로 두면 안 됩니다.

실전 감각으로 정리하면 다음과 같습니다.

중요한 점은 workspace-write가 "아무거나 다 해도 된다"는 뜻이 아니라는 것입니다. Codex에게 필요한 작업 공간만 열어 주고, 나머지는 닫아 두는 균형점입니다.

초보자의 권장 기본값

처음 Codex로 앱을 만들 때는 다음 조합을 기본으로 삼는 것이 좋습니다.

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

이 설정은 Codex가 현재 프로젝트 안에서 파일을 읽고 수정하고 테스트를 실행하는 정도는 자연스럽게 진행하게 해 줍니다. 하지만 작업 폴더 밖으로 나가거나, 네트워크가 필요하거나, 예측하기 어려운 명령을 실행하려고 하면 사용자의 승인을 받게 됩니다. 공식 문서에서도 버전 관리되는 폴더에서는 workspace-write와 요청 기반 승인 조합을 권장 기본 흐름으로 안내합니다.³

더 안전하게 탐색만 하고 싶다면 이렇게 시작할 수 있습니다.

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

이 모드는 "아직 고치지는 말고 먼저 설명해줘"에 잘 맞습니다. 새로운 오픈소스 프로젝트를 분석하거나, 회사 코드베이스를 처음 열어 볼 때 유용합니다.

설정을 매번 입력하기 귀찮다면 ~/.codex/config.toml에 기본값을 넣을 수 있습니다.

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[sandbox_workspace_write]
network_access = false

이 설정의 의미는 분명합니다. Codex는 프로젝트 안에서 일할 수 있습니다. 하지만 네트워크는 기본 차단입니다. 더 큰 권한이 필요하면 그때 승인 요청을 받습니다.

Codex를 실행한 뒤 현재 상태가 헷갈린다면 세션 안에서 /status를 확인하세요. 어떤 작업 디렉터리에서 실행 중인지, 현재 권한과 설정이 무엇인지 점검하는 습관은 초보자에게 특히 중요합니다. Codex CLI에는 /permissions, /status, /diff처럼 권한과 변경 사항을 확인하는 명령이 제공됩니다.⁴

네트워크 접근은 왜 따로 조심해야 할까

앱 개발을 하다 보면 네트워크 접근이 필요할 때가 많습니다. 패키지를 설치해야 하고, API 문서를 확인해야 하고, 외부 서비스를 호출해야 할 수도 있습니다. 하지만 Codex에게 네트워크를 열어 주는 일은 단순한 편의 기능이 아닙니다. 보안과 재현성에 영향을 주는 결정입니다.

네트워크가 열리면 Codex는 외부 패키지 저장소, 문서 사이트, API 서버, 원격 스크립트와 만날 수 있습니다. 이 과정에서 공급망 위험이 생길 수 있습니다. 공급망 위험이란 내가 직접 작성하지 않은 외부 패키지, 설치 스크립트, 원격 리소스가 내 프로젝트에 영향을 주는 위험을 말합니다. 예를 들어 악성 패키지를 설치하거나, 필요 이상의 의존성이 추가되거나, lock 파일이 크게 바뀌는 일이 생길 수 있습니다.

따라서 네트워크 접근은 "필요할 때만 잠깐 열기"가 기본입니다. 다음과 같은 상황에서는 Codex가 요청하는 명령을 확인한 뒤 승인하는 방식이 안전합니다.

• npm install, pnpm add, pip install처럼 의존성을 설치할 때

• curl, wget처럼 외부 주소에서 내용을 가져올 때

• 외부 API, 데이터베이스, 클라우드 서비스에 접속할 때

• 원격 스크립트를 내려받아 실행하려고 할 때

예를 들어 Codex가 다음 명령을 실행하려고 한다고 해 봅시다.

npm install date-fns

이 정도는 비교적 이해하기 쉬운 패키지 설치입니다. 그래도 바로 승인하기 전에 "왜 이 패키지가 필요한가?", "이미 프로젝트에 비슷한 라이브러리가 있는가?", "package.json과 lock 파일이 어떻게 바뀌는가?"를 확인해야 합니다.

반대로 다음과 같은 명령은 훨씬 더 조심해야 합니다.

curl https://example.com/install.sh | bash

이 명령은 인터넷에서 스크립트를 받아 곧바로 실행합니다. 스크립트 내용을 보지 않고 실행하면 Codex에게 내 터미널을 그대로 맡기는 것과 비슷합니다. 이런 경우에는 Codex에게 먼저 스크립트 내용을 저장하고 설명하게 한 뒤, 내가 직접 검토한 다음 실행 여부를 결정해야 합니다.

실전 프롬프트는 이렇게 쓸 수 있습니다.

패키지 설치가 필요하면 바로 실행하지 말고 먼저 알려줘.
설치하려는 패키지 이름, 필요한 이유, package.json과 lock 파일에 생길 변경을 설명해줘.
내가 승인한 뒤에만 설치 명령을 실행해줘.

이 한 문장만 넣어도 Codex가 네트워크를 훨씬 조심스럽게 다루게 됩니다.

Full Access와 승인 생략은 언제 써도 될까

Codex에는 승인 요청을 줄이거나 아예 생략하는 설정도 있습니다. 예를 들어 --ask-for-approval never는 Codex가 승인 요청을 하지 않도록 만듭니다. 또한 --dangerously-bypass-approvals-and-sandbox 또는 --yolo처럼 샌드박스와 승인을 크게 우회하는 위험한 옵션도 있습니다. 문서에서도 이런 완전 우회 방식은 주의해서 사용해야 하는 것으로 안내됩니다.³

이런 기능이 존재하는 이유는 분명합니다. 반복 자동화나 CI 환경에서는 사람이 매번 "예"를 누를 수 없습니다. 격리된 컨테이너 안에서 테스트를 고치고 다시 실행하는 작업처럼, 실패해도 버리면 되는 환경에서는 자동화가 생산성을 크게 높입니다.

하지만 초보자가 개인 노트북의 홈 폴더나 실제 서비스 코드 저장소에서 이 모드를 기본으로 쓰는 것은 좋지 않습니다. 이유는 간단합니다. 실수의 반경이 너무 넓어지기 때문입니다. Codex가 악의적이어서가 아니라, 명령 하나가 예상보다 많은 일을 할 수 있기 때문입니다. 경로 하나를 잘못 해석한 삭제 명령, 잘못된 환경 변수, 엉뚱한 배포 대상, 오래된 스크립트 하나만으로도 문제가 생길 수 있습니다.

Full Access나 승인 생략 설정은 다음 조건이 맞을 때만 고려하세요.

• 컨테이너, VM, 임시 개발 환경처럼 망가져도 쉽게 버릴 수 있다.

• Git 커밋, 브랜치, 백업이 준비되어 있어 되돌릴 수 있다.

• 실행할 작업이 반복적으로 검증된 자동화 작업이다.

• 민감한 비밀값, 실제 고객 데이터, 운영 서버 접근 권한이 없다.

반대로 다음 상황에서는 쓰지 않는 편이 안전합니다.

• 개인 홈 폴더 전체가 보이는 상태

• 운영 서비스 코드와 비밀키가 함께 있는 저장소

• 데이터베이스 마이그레이션이나 배포 명령이 연결된 프로젝트

• 아직 Codex의 작업 스타일을 충분히 모르는 초보 단계

한마디로 Full Access는 "더 빠른 기본 모드"가 아니라 "격리된 곳에서 쓰는 특수 도구"입니다.

위험한 작업 전에는 계획부터 받아라

Codex가 할 수 있는 작업 중에는 특히 조심해야 하는 것들이 있습니다. 파일 삭제, 데이터베이스 마이그레이션, 대량 리팩토링, 파일 이동, 포맷터 일괄 적용, 의존성 대규모 업데이트가 대표적입니다. 이런 작업은 한 번 실행하면 변경 범위가 넓고, diff를 읽기도 어려워집니다.

초보자가 가장 쉽게 실수하는 흐름은 이렇습니다.

전체 프로젝트 리팩토링해줘.

이 요청은 너무 넓습니다. Codex는 최선을 다해 작업하겠지만, 어떤 파일을 바꿀지, 어떤 기준으로 리팩토링할지, 테스트는 어디까지 할지 애매합니다. 권한까지 넓게 열려 있다면 위험은 더 커집니다.

더 안전한 요청은 다음과 같습니다.

아직 파일을 수정하지 마.
먼저 리팩토링 계획만 작성해줘.

다음을 포함해줘.
1. 수정할 파일 목록
2. 각 파일에서 바꿀 내용
3. 예상되는 부작용
4. 실행할 테스트 명령
5. 되돌리는 방법

내가 승인하기 전에는 실제 변경을 하지 마.

이 프롬프트는 Codex를 멈춰 세우는 브레이크 역할을 합니다. 먼저 생각하게 하고, 영향 범위를 드러내게 하고, 사용자가 판단할 시간을 줍니다.

데이터베이스 마이그레이션이라면 더 엄격해야 합니다.

마이그레이션 파일을 만들기 전에 먼저 계획을 설명해줘.
스키마 변경 내용, 기존 데이터에 미치는 영향, 롤백 전략, 로컬에서 검증할 명령을 알려줘.
실제 마이그레이션 실행은 내가 승인하기 전까지 하지 마.
운영 데이터베이스에는 절대 접속하지 마.

파일 삭제 작업도 마찬가지입니다.

사용하지 않는 파일을 찾아줘.
바로 삭제하지 말고 삭제 후보 목록과 근거를 먼저 보여줘.
각 파일이 import되거나 참조되는 위치를 확인해줘.
내가 승인한 파일만 삭제해줘.

이런 프롬프트는 조금 길어 보이지만, 실제로는 시간을 아껴 줍니다. Codex가 한 번에 크게 잘못 바꾸는 일을 줄이고, 변경 후 diff 검토도 쉬워집니다.

Git은 권한 관리의 안전벨트다

샌드박스와 승인 정책이 Codex의 행동을 제한하는 장치라면, Git은 문제가 생겼을 때 되돌아갈 수 있게 해 주는 안전벨트입니다. Codex에게 파일 수정을 맡기기 전에는 가능한 한 git status가 깨끗한 상태여야 합니다. 이미 내 손으로 수정한 파일과 Codex가 바꾼 파일이 섞이면 무엇이 문제였는지 구분하기 어렵습니다.

안전한 기본 흐름은 다음과 같습니다.

git status
git checkout -b feature/codex-safe-test

그다음 Codex에게 작은 작업을 맡깁니다.

Button 컴포넌트에 loading 상태를 추가해줘.
수정 범위는 src/components/Button.tsx와 관련 테스트 파일로 제한해줘.
완료 후 변경 요약과 실행한 테스트를 알려줘.

작업이 끝나면 바로 확인합니다.

git diff
npm test

Codex 세션 안에서는 /diff로 변경 내용을 볼 수도 있습니다. 변경 범위가 예상보다 넓다면 바로 멈추고 이유를 물어보세요.

예상보다 많은 파일이 변경됐어.
각 파일이 왜 변경됐는지 설명하고, 꼭 필요하지 않은 변경은 되돌려줘.

여기서 중요한 습관은 "Codex가 끝났다고 말해도 곧바로 커밋하지 않는 것"입니다. 사람이 diff를 읽고, 테스트를 실행하고, 변경 의도를 이해한 뒤 커밋해야 합니다. AI가 작성한 코드는 동료 개발자의 PR처럼 검토해야 합니다.

작업별 권한 선택 예제

이제 실제 상황별로 어떤 권한을 선택하면 좋은지 살펴보겠습니다.

새 프로젝트를 처음 열어 구조를 이해하고 싶다면 read-only로 시작하세요.

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

프롬프트는 이렇게 씁니다.

이 프로젝트의 폴더 구조를 초보자도 이해할 수 있게 설명해줘.
주요 진입점, 라우팅, 상태 관리, 테스트 위치를 찾아줘.
아직 파일은 수정하지 마.

버그를 하나 고치는 일반적인 작업이라면 workspace-write가 적합합니다.

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

로그인 버튼을 눌렀을 때 로딩 표시가 사라지지 않는 버그를 고쳐줘.
수정 범위는 로그인 관련 컴포넌트와 테스트로 제한해줘.
먼저 원인을 설명하고, 그다음 최소 변경으로 수정해줘.
완료 후 실행한 테스트와 변경 파일 목록을 알려줘.

의존성을 설치해야 하는 작업이라면 네트워크 승인을 별도로 다룹니다.

날짜 포맷 처리를 개선해야 해.
새 패키지가 필요하다고 판단되면 바로 설치하지 말고 먼저 후보 패키지와 이유를 설명해줘.
기존 의존성으로 해결할 수 있으면 새 패키지를 추가하지 마.
내가 승인한 뒤에만 설치해줘.

대량 포맷팅이나 리팩토링은 바로 실행하지 말고 계획을 먼저 받습니다.

전체 코드 포맷터 적용을 검토해줘.
바로 실행하지 말고 변경될 파일 수, 예상 diff 규모, 위험한 파일 목록을 먼저 알려줘.
작은 범위로 나누어 실행하는 방법을 제안해줘.

이런 방식으로 권한과 프롬프트를 함께 설계하면 Codex는 훨씬 안전한 협업자가 됩니다.

Codex App, CLI, IDE에서 같은 원칙이 적용된다

앞으로 우리는 Codex App, CLI, IDE 확장, Cloud 흐름을 차례로 다룰 것입니다. 화면과 명령은 조금씩 다르지만 권한 관리의 원칙은 같습니다. 현재 프로젝트를 작업 공간으로 삼고, 그 안에서 필요한 일만 허용하고, 작업 공간 밖으로 나가거나 네트워크가 필요하면 사용자 승인을 받는 흐름입니다.

Codex Cloud는 로컬 컴퓨터와는 다르게 OpenAI가 관리하는 격리된 환경에서 실행됩니다. Cloud 환경에서는 설정 단계에서 의존성을 설치하기 위해 네트워크를 사용할 수 있고, 이후 에이전트 작업 단계는 기본적으로 더 제한된 방식으로 운영될 수 있습니다.² 이 내용은 뒤에서 GitHub와 PR 흐름을 다룰 때 다시 자세히 보겠습니다.

지금 단계에서 기억할 것은 하나입니다. 어떤 인터페이스를 쓰든 Codex에게 주는 권한은 "작업을 빨리 끝내기 위한 편의 설정"이 아니라 "피해 범위를 정하는 안전 설계"입니다.

초보자를 위한 안전 체크리스트

Codex에게 실제 작업을 맡기기 전에 아래 질문을 빠르게 확인하세요. 모두 완벽하게 외울 필요는 없습니다. 몇 번만 반복하면 자연스럽게 습관이 됩니다.

• 지금 Codex가 열린 폴더가 내가 의도한 프로젝트가 맞는가?

• git status가 깨끗하거나, 현재 변경 사항을 따로 저장해 두었는가?

• 현재 모드가 read-only, workspace-write, danger-full-access 중 무엇인가?

• 네트워크 접근이 꼭 필요한 작업인가?

• 패키지 설치나 원격 스크립트 실행이 포함되어 있지는 않은가?

• 삭제, 이동, 대량 변경, 마이그레이션 전 계획을 먼저 받았는가?

• 작업 후 /diff 또는 git diff로 사람이 변경 내용을 읽었는가?

• 테스트, 빌드, 린트 같은 검증 명령을 실행했는가?

이 체크리스트는 Codex를 느리게 쓰기 위한 것이 아닙니다. 오히려 반대입니다. 작은 안전장치를 습관화하면 큰 사고를 피할 수 있고, 결과적으로 더 빠르게 개발할 수 있습니다.

이 장의 결론

Codex는 강력한 개발 파트너입니다. 하지만 강력하다는 말은 곧 권한 관리가 중요하다는 뜻입니다. 초보자는 일단 workspace-write와 요청 기반 승인, 네트워크 차단을 기본값으로 삼으면 됩니다. 탐색할 때는 read-only, 일반 개발에는 workspace-write, 완전 접근은 격리된 환경에서만 사용하세요.

특히 네트워크 접근, 패키지 설치, 파일 삭제, 데이터베이스 마이그레이션, 대량 리팩토링은 "바로 실행"이 아니라 "계획 → 승인 → 실행 → diff 검토" 순서로 다뤄야 합니다.

다음 장에서는 Codex App으로 프로젝트와 작업을 관리하는 방법을 살펴봅니다. 이제 우리는 Codex에게 일을 맡기기 전에 작업장의 울타리를 세우는 법을 배웠습니다. 다음 단계는 그 울타리 안에서 여러 작업을 어떻게 정리하고 진행할지 배우는 것입니다.

참고

¹Sandbox - Codex | OpenAI Developers

²Agent approvals & security - Codex | OpenAI Developers

³Sandbox & approvals · Codex Docs

⁴OpenAI Codex CLI Cheat Sheet – Commands, Shortcuts, Tips