🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenAI는 Windows에서 Codex가 개발자 생산성을 유지하면서도 파일 쓰기와 네트워크 접근을 안전하게 제한할 수 있도록 자체 샌드박스 설계를 모색했고, 기존 Windows 격리 도구와 첫 비상승권한 프로토타입의 한계를 분석했다.

📌 핵심 요약

• Codex for Windows에는 당시 샌드박스 구현이 없어 사용자가 거의 모든 명령을 승인하거나, 반대로 Full Access 모드로 모든 명령을 제한 없이 허용하는 두 가지 불완전한 선택지 사이에 놓여 있었다.
• Codex는 개발자 노트북에서 실제 사용자 권한으로 실행되며 테스트 실행, 파일 읽기·수정, 브랜치 생성 같은 로컬 명령을 수행할 수 있기 때문에, 기본 모드는 생산성과 안전 사이의 균형을 위해 운영체제가 강제하는 샌드박스를 필요로 했다.
• OpenAI는 AppContainer, Windows Sandbox, Mandatory Integrity Control을 검토했지만, Codex의 개방형 개발 워크플로, 실제 체크아웃과 도구 사용 요구, 호스트 파일시스템 의미 변경 위험 때문에 최종 요구사항에 맞지 않는다고 판단했다.
• 첫 프로토타입은 관리자 권한 상승 없이 동작하는 것을 목표로, synthetic SID와 write-restricted token, ACL을 조합해 현재 작업 디렉터리와 설정된 writable_roots에는 쓰기를 허용하고 .git, .codex, .agents 같은 위치는 쓰기 금지로 다뤘다.
• 네트워크 제한은 Windows Firewall 같은 강한 메커니즘을 관리자 권한 없이 쓰기 어려워 프록시 환경변수, Git 설정, SSH 차단 명령, PATH 앞단의 denybin 방식으로 시도했지만, 프로세스가 이를 우회할 수 있어 최종 설계로 삼기에는 약했다.

🧩 주요 포인트

1. Codex for Windows에는 당시 샌드박스 구현이 없어 사용자가 거의 모든 명령을 승인하거나, 반대로 Full Access 모드로 모든 명령을 제한 없이 허용하는 두 가지 불완전한 선택지 사이에 놓여 있었다.
2. Codex는 개발자 노트북에서 실제 사용자 권한으로 실행되며 테스트 실행, 파일 읽기·수정, 브랜치 생성 같은 로컬 명령을 수행할 수 있기 때문에, 기본 모드는 생산성과 안전 사이의 균형을 위해 운영체제가 강제하는 샌드박스를 필요로 했다.
3. OpenAI는 AppContainer, Windows Sandbox, Mandatory Integrity Control을 검토했지만, Codex의 개방형 개발 워크플로, 실제 체크아웃과 도구 사용 요구, 호스트 파일시스템 의미 변경 위험 때문에 최종 요구사항에 맞지 않는다고 판단했다.
4. 첫 프로토타입은 관리자 권한 상승 없이 동작하는 것을 목표로, synthetic SID와 write-restricted token, ACL을 조합해 현재 작업 디렉터리와 설정된 writable_roots에는 쓰기를 허용하고 .git, .codex, .agents 같은 위치는 쓰기 금지로 다뤘다.
5. 네트워크 제한은 Windows Firewall 같은 강한 메커니즘을 관리자 권한 없이 쓰기 어려워 프록시 환경변수, Git 설정, SSH 차단 명령, PATH 앞단의 denybin 방식으로 시도했지만, 프로세스가 이를 우회할 수 있어 최종 설계로 삼기에는 약했다.

🧠 상세 정리

1. Windows용 Codex가 직면한 초기 문제

원문은 2025년 9월 작성자가 Codex 엔지니어링 팀에 합류했을 때 Windows용 Codex에 샌드박스 구현이 없었다는 문제에서 출발한다. 그 결과 Windows 사용자는 코딩 에이전트가 실행하려는 거의 모든 명령을 승인해야 하는 번거로운 방식과, 모든 명령을 승인 없이 실행하게 하는 Full Access 모드 사이에서 선택해야 했다. 전자는 Codex가 반복적이고 지루한 작업을 대신해 준다는 장점을 크게 줄였고, 후자는 마찰을 줄이는 대신 사용자의 감독과 제한을 약화시켰다. 따라서 Windows에서도 다른 환경처럼 안전하면서도 자연스러운 Codex 사용 경험을 제공하려면 별도의 샌드박스가 필요했다.

2. Codex 실행 모델과 샌드박스의 필요성

Codex는 CLI, IDE 확장, 데스크톱 앱을 통해 개발자 노트북에서 실행되며, 키보드 앞의 인간 사용자와 클라우드에서 추론을 수행하는 모델 사이의 대화를 관리한다. 기본적으로 Codex는 실제 사용자 권한으로 실행되므로 사용자가 할 수 있는 일을 그대로 할 수 있다. 모델은 테스트 실행, 파일 읽기와 편집, Git 브랜치 생성 같은 로컬 명령을 harness에 요청할 수 있으며, 이는 강력하지만 잠재적으로 위험하다. 원문이 설명하는 기본 모드는 파일 읽기는 넓게 허용하되 쓰기는 작업공간 내부로 제한하고, 사용자가 명시하지 않는 한 인터넷 접근을 막는 균형점을 목표로 한다.

3. 운영체제 수준 격리가 필요한 이유

원문에서 샌드박스는 제약된 실행 환경으로 정의된다. 개발자가 Codex를 사용할 때 운영체제는 낮아진 권한으로 명령을 시작하고, 그 제약은 프로세스 트리 아래로 전파되어 모든 하위 프로세스가 같은 경계 안에 머문다. 이런 방식이 효과적이려면 단순한 애플리케이션 약속이 아니라 운영체제가 강제하는 격리 기능이 필요하다. macOS에는 Seatbelt가 있고 Linux에는 seccomp나 bubblewrap 같은 수단이 있지만, Windows에는 Codex 요구사항을 바로 충족하는 동일한 형태의 기본 기능이 없다고 원문은 설명한다.

4. 기존 Windows 격리 도구 검토

OpenAI는 Windows가 제공하는 여러 격리 도구와 기본 요소를 검토했다. AppContainer는 앱이 필요한 접근 권한을 사전에 정확히 아는 경우에 맞는 capability 기반 격리 모델로, 실제 운영체제 경계를 제공한다는 점은 매력적이었다. 그러나 Codex는 하나의 좁게 정의된 앱이 아니라 셸, Git, Python, 패키지 관리자, 빌드 도구와 그 밖의 임의 바이너리를 다루는 개방형 개발 워크플로를 실행한다. 따라서 AppContainer는 격리는 강하지만 ‘에이전트가 개발자처럼 작동하게 한다’는 문제에는 형태가 맞지 않는 선택지로 평가됐다.

5. Windows Sandbox와 MIC가 맞지 않았던 이유

Windows Sandbox는 일회용 경량 가상 머신으로 강한 격리 경계를 제공하고 임의 소프트웨어와의 호환성도 AppContainer보다 높아 보였다. 하지만 Codex는 별도 폐기형 데스크톱이 아니라 사용자의 실제 체크아웃, 도구, 환경에서 직접 작업해야 하며, Windows Sandbox가 Windows Home SKU에서 제공되지 않는다는 제품적 문제도 있었다. Mandatory Integrity Control은 낮은 integrity 프로세스가 높은 integrity 객체에 쓰지 못하게 하는 모델이어서 이론상 매력적이었다. 그러나 작업공간을 low integrity로 표시하면 Codex만이 아니라 low-integrity 프로세스 일반에 쓰기 가능한 공간이 되어 실제 개발자 체크아웃의 신뢰 모델을 넓고 위험하게 바꾸는 문제가 있었다.

6. 첫 프로토타입: 비상승권한 샌드박스

기존 선택지가 요구사항을 충족하지 못하자 팀은 자체 솔루션을 설계하기 시작했다. 첫 작동 프로토타입의 중요한 목표는 관리자 권한 상승 없이 샌드박스를 설정하고 실행하는 것이었다. 사용자가 단지 Codex를 쓰기 위해 관리자 권한 프롬프트를 계속 승인하거나 로컬 머신의 관리자여야 하는 상황을 피하려 한 것이다. 이 비상승권한 설계는 크게 파일 쓰기 제한과 네트워크 접근 제한이라는 두 문제를 다뤘다. 파일 쓰기를 전혀 제한하지 않으면 안전 문제가 생기고, 지나치게 제한하면 사용자 생산성이 떨어져 계속 승인 요청이 발생하기 때문에 정밀한 제어가 필요했다.

7. SID, write-restricted token, ACL을 통한 파일 쓰기 제어

파일 쓰기 제한에는 Windows의 SID와 write-restricted token이 핵심 요소로 쓰였다. SID는 Windows가 권한에 연결하는 식별자로, 사용자와 그룹뿐 아니라 단일 로그인 세션에도 부여될 수 있으며, 실제 사용자와 대응하지 않는 synthetic SID도 ACL에 사용할 수 있다. 프로토타입은 sandbox-write라는 synthetic SID를 만들고, 현재 작업 디렉터리와 config.toml에 설정된 추가 writable_roots에 쓰기, 실행, 삭제 권한을 부여했다. 동시에 .git, .codex, .agents처럼 writable 영역 안에 있지만 읽기 전용으로 취급해야 하는 위치에는 같은 SID의 쓰기 접근을 명시적으로 거부했다. Codex 명령은 Everyone, 현재 로그인 세션 SID, sandbox-write SID를 restricted SID 목록에 포함한 write-restricted token 아래에서 실행됐다.

8. 네트워크 제한 시도와 프로토타입의 한계

네트워크 접근 제한은 악성 코드가 머신의 데이터를 인터넷으로 유출하지 못하게 하기 위해 중요했다. 그러나 관리자 권한 상승을 피하려는 조건 때문에 Windows Firewall 같은 강한 네트워크 차단 수단을 쓰기 어려웠다. 팀은 HTTPS_PROXY, ALL_PROXY, GIT_HTTPS_PROXY를 죽은 로컬 엔드포인트로 보내고, NO_PROXY를 localhost 계열로 제한하며, GIT_SSH_COMMAND를 즉시 실패시키는 식으로 일반 개발 도구의 네트워크 경로가 실패하도록 만들었다. 또한 denybin 디렉터리를 PATH 앞에 두고 PATHEXT 순서를 조정해 SSH와 SCP stub이 실제 바이너리보다 먼저 잡히게 했다. 하지만 이런 방식은 환경변수나 PATH를 무시하거나 직접 소켓을 여는 프로그램에는 우회될 수 있어 권고적 보호에 그쳤고, 원문은 이를 최종 설계의 결격 사유 중 하나로 제시한다.

🧾 핵심 주장 / 시사점

• 코딩 에이전트의 샌드박스는 단순히 명령 승인 횟수를 줄이는 기능이 아니라, 실제 사용자 권한으로 움직이는 자동화 도구의 위험 경계를 운영체제 수준에서 다시 그리는 문제로 다뤄진다.
• Windows의 기존 격리 기능들은 각각 강점이 있었지만, Codex처럼 실제 개발 환경에서 다양한 도구를 유연하게 호출해야 하는 에이전트형 워크플로에는 지나치게 좁거나, 별도 환경을 요구하거나, 호스트 파일시스템의 신뢰 의미를 바꾸는 문제가 있었다.
• 첫 프로토타입은 파일 쓰기 제어에서는 세밀한 가능성을 보여줬지만, 관리자 권한 없이 강한 네트워크 차단을 구현하기 어렵다는 점 때문에 환경변수와 PATH 기반 우회 방지 정도로는 안전한 최종 샌드박스가 되기 어렵다는 한계를 드러냈다.

✅ 액션 아이템

• Codex for Windows의 기본 모드는 사용자 승인 과 전면 허용 사이에서 이탈하지 않도록, 운영체제 강제 샌드박스 경계를 우선 설계한다.
• AppContainer·Windows Sandbox·Mandatory Integrity Control 미적합 항목을 정리한 뒤, 오픈형 개발 워크플로를 보존하는 샌드박스 요구조건을 좁힌다.
• 첫 프로토타입 원칙에 따라 작업 디렉터리와 writable_roots만 쓰기 허용하고 .git·.codex·.agents는 금지하는 토큰·ACL 규칙을 재점검한다.

❓ 열린 질문

• 관리자 권한 없이 신뢰할 수 있는 네트워크 제한은 어떤 조합으로 구성하는 것이 가장 현실적인가?
• 프록시 환경변수·Git 설정·SSH 차단·PATH denybin 우회는 어떤 실행 경로에서 발생해 정책이 깨지는가?
• 테스트 실행·브랜치 생성 같은 로컬 작업을 유지하면서 writable_roots 범위를 더 세분화할 적절한 기준은 무엇인가?