에이전트에게 터미널을 내주는 순간부터 질문이 바뀝니다. "코드를 잘 짜나?"에서 "무엇까지 할 수 있게 둘 것인가?"로요.
바이브 코딩이 편한 이유는 사람이 일일이 확인하지 않아도 일이 진행되기 때문입니다. 그 편함이 그대로 위험이 됩니다. 확인하지 않는 동안 에이전트가 무엇을 지우고, 어디에 접속하고, 무엇을 밖으로 보낼 수 있는지가 정해져 있어야 합니다.
OpenAI의 Codex 문서는 이 문제를 두 개의 손잡이로 나눠 설명합니다.
두 개의 손잡이
첫째는 샌드박스입니다. 에이전트가 기술적으로 무엇을 할 수 있는지, 즉 어느 파일을 고칠 수 있고 명령이 네트워크를 쓸 수 있는지를 정합니다.
둘째는 승인 정책입니다. 그 경계를 넘어야 할 때 언제 사람에게 물어볼지를 정합니다.
문서의 한 문장이 둘의 관계를 정리합니다. 샌드박스는 기술적 한계를 정하고, 승인 정책은 그 한계를 넘기 전에 에이전트가 언제 물어야 하는지를 정한다.
울타리의 세 단계
샌드박스 모드는 세 가지입니다.
read-only: 파일을 볼 수는 있지만, 승인 없이는 고치거나 명령을 실행할 수 없습니다.workspace-write: 작업 공간 안에서 수정하고 일상적인 로컬 명령을 실행할 수 있습니다. 로컬 작업의 기본값입니다.danger-full-access: 샌드박스 제한 없이 돌아갑니다. 파일 시스템과 네트워크의 경계가 사라집니다.
울타리는 운영체제의 기능으로 칩니다. macOS는 내장 Seatbelt, Linux와 WSL2는 bubblewrap, Windows는 PowerShell의 네이티브 샌드박스를 쓴다고 적혀 있습니다.
시작할 때의 기본값도 정해져 있습니다. 버전 관리가 되는 폴더는 Auto(작업 공간 쓰기 + 필요할 때 묻기)로, 버전 관리가 안 되는 폴더는 read-only로 시작합니다. 그리고 기본으로 에이전트의 네트워크 접근은 꺼져 있습니다.
버전 관리 여부로 기본값을 가르는 이유는 짐작이 갑니다. git이 있으면 잘못된 수정을 되돌릴 수 있지만, 없으면 되돌릴 길이 없습니다.
조합표
문서는 의도별 권장 조합을 표로 줍니다. 그대로 옮기면 이렇습니다.
| 의도 | 설정 | 효과 |
|---|---|---|
| Auto(기본 묶음) | --sandbox workspace-write --ask-for-approval on-request |
작업 공간 안에서 수정·실행, 밖으로 나갈 때는 승인 |
| 안전한 읽기 | --sandbox read-only --ask-for-approval on-request |
읽기 전용 샌드박스에서 읽고 실행 |
| 읽기 전용 CI | --sandbox read-only --ask-for-approval never |
읽기만 하고 묻지 않음 |
| 위험한 전체 접근 | --dangerously-bypass-approvals-and-sandbox (--yolo) |
샌드박스도 승인도 없음, 문서는 권장하지 않음 |
CI 줄이 눈여겨볼 만합니다. 사람이 없는 환경에서는 물어볼 상대가 없으니 never가 자연스럽습니다. 대신 울타리를 read-only로 가장 좁게 잡습니다. 묻지 않을 거라면 울타리를 줄인다는 원칙입니다.
넓힐 때는 좁게
작업하다 보면 울타리를 넓혀야 할 때가 옵니다. 문서의 권고는 일관됩니다.
- 승인할 때는 작업이 이어질 수 있는 가장 좁은 범위를 고릅니다.
- 쓰기 경로가 더 필요하면 샌드박스를 풀지 말고
sandbox_workspace_write.writable_roots로 쓸 수 있는 디렉터리만 늘립니다. - 서로 상관없는 저장소까지 접근을 넓히는 대신 별도 프로젝트나 워크트리를 씁니다.
- 특정 예외는 접근을 통째로 넓히기보다 규칙으로 처리합니다.
네트워크도 같습니다. 도메인을 하나씩 allow·deny로 적을 수 있고, *.example.com은 하위 도메인만, **.example.com은 최상위와 하위 모두를 뜻합니다. 전체를 뜻하는 * 허용은 넓은 접근으로 취급하라고 적혀 있습니다.
클라우드에서는 단계를 나눈다
클라우드 작업은 구조가 조금 다릅니다. 문서의 이전 버전 Codex Cloud 설명에 따르면 작업은 OpenAI가 관리하는 격리된 컨테이너에서 두 단계로 돕니다.
설정 단계에서는 의존성을 설치하려고 네트워크에 접근할 수 있습니다. 그다음 에이전트 단계는 인터넷 접근을 켜지 않는 한 오프라인으로 돕니다. 그리고 클라우드 환경에 설정한 비밀값은 설정 단계에서만 쓸 수 있고, 에이전트 단계가 시작되기 전에 제거된다고 적혀 있습니다.
이 설계가 노리는 것은 분명합니다. 모델이 코드를 읽고 명령을 실행하는 시간에는 훔쳐 갈 비밀값도, 보낼 곳도 없게 만드는 것입니다.
왜 이렇게까지 하나
문서는 인터넷 접근을 켤 때의 위험을 직접 적습니다. 프롬프트 인젝션이 에이전트로 하여금 신뢰할 수 없는 지시를 가져와 따르게 만들 수 있다고요. 그래서 웹 결과는 신뢰하지 않는 입력으로 다루라고 합니다. 웹 검색은 기본으로 캐시된 색인을 써서 실시간 콘텐츠 노출을 줄인다는 설명도 붙어 있습니다.
전체 접근의 위험도 구체적입니다. 악의적인 프로젝트를 전체 접근으로 열면 개발 컨테이너 안에 있는 모든 것, Codex 자격 증명까지 밖으로 빼낼 수 있다고 경고합니다.
바이브 코딩을 하다 보면 승인 창이 귀찮아지는 순간이 반드시 옵니다. 그때 --yolo를 누르기 전에 떠올릴 질문은 하나입니다. 지금 이 에이전트가 읽고 있는 것 중에 내가 쓰지 않은 텍스트가 있는가. 있다면 그 텍스트도 에이전트에게 지시를 내릴 수 있습니다.
