OpenAI, Windows용 Codex의 안전한 샌드박스 구축 여정 공개: AppContainer부터 write-restricted Token, Windows Firewall까지

9bow · 5월 17, 2026, 9:30오전

Codex와 샌드박스, 그리고 Windows라는 까다로운 환경

OpenAI Codex는 개발자의 노트북 위에서 동작하는 코딩 에이전트입니다. CLI 형태로 실행되거나 VS Code 확장 또는 데스크톱 앱 안에서 동작하며, 키보드 앞에 앉아 있는 사람과 클라우드에서 실행되는 모델 사이의 대화를 중개하면서 파일 편집, 테스트 실행, Git 브랜치 생성 같은 작업을 자동으로 수행합니다. 즉 Codex는 "사람이 할 수 있는 모든 일을 모델이 대신 해 주는" 도구이며, 동시에 그렇기 때문에 적절히 통제되지 않으면 위험할 수 있는 도구이기도 합니다.

이런 코딩 에이전트가 사용자 시스템 위에서 안전하게 동작하려면 샌드박스(sandbox) 가 필수입니다. 샌드박스란 운영체제가 강제하는 제약된 실행 환경으로, 에이전트가 명령어를 실행할 때 권한이 낮은 상태로 출발하고 그 자식 프로세스 전체에 동일한 경계가 전파되도록 만들어 줍니다. macOS에는 Seatbelt가 있고, Linux에는 seccomp이나 bubblewrap처럼 잘 다듬어진 격리 도구가 있습니다. 그러나 Microsoft Windows는 이러한 기능을 기본적으로 제공하지 않습니다.

OpenAI가 최근 공개한 엔지니어링 블로그 "Building a safe, effective sandbox to enable Codex on Windows"는 바로 이 빈자리를 어떻게 메웠는지를 다룹니다. 2025년 9월에 합류한 Codex 엔지니어가 Windows용 샌드박스를 처음부터 설계하면서 마주친 선택지들, 그리고 그 과정에서 폐기된 첫 번째 프로토타입과 최종적으로 채택된 "elevated sandbox" 아키텍처까지를 솔직하게 풀어 놓은 글입니다. 이번 글에서는 그 내용을 따라가면서, Codex가 AppContainer, Windows Sandbox, Mandatory Integrity Control, SID, write-restricted token, Windows Firewall 등을 어떻게 조합해 안전성과 사용성을 동시에 잡으려 했는지를 살펴봅니다.

Codex 기본 모드와 샌드박스가 필요한 이유

Codex는 기본적으로 현재 로그인된 사용자의 권한으로 실행됩니다. 즉 사용자가 할 수 있는 일은 무엇이든 Codex도 할 수 있다는 뜻인데, 이는 강력하면서도 위험한 특성입니다. 코딩 모델은 하네스(harness)에게 로컬 명령을 실행하도록 지시할 수 있고, 그 명령은 테스트 실행일 수도, 파일 읽기/편집일 수도, Git 브랜치 생성일 수도 있습니다. Codex의 기본 모드는 이런 폭넓은 가능성 안에서 효과성과 안전성 사이의 균형을 잡으려고 합니다.

구체적으로 Codex 기본 모드는 거의 모든 위치의 파일을 읽을 수 있게 허용하되, 쓰기 작업은 워크스페이스(즉 Codex를 실행한 디렉터리) 안으로 제한하고, 별도로 지정하지 않으면 인터넷 접근을 차단합니다. 이런 자동 제약이 효과적으로 강제되려면 운영체제 수준에서 작동하는 진짜 샌드박스가 필요합니다. Codex가 시작될 때 명령이 권한이 줄어든 상태로 실행되고, 그 자식 프로세스 전체에 같은 경계가 전파되며, 어떤 자손 프로세스도 같은 경계 안에 머물러야 합니다.

이러한 구조가 Windows에서 곧바로 구현되지 못한 이유는 단순합니다. 다른 OS에서 표준처럼 쓰이는 격리 도구가 Windows에는 없거나, 있더라도 코딩 에이전트가 요구하는 "넓고 변화무쌍한 작업 부하"와 모양이 맞지 않기 때문입니다.

이런 빈틈을 메우지 못한 채로 출시된 초기 Codex for Windows는 사용자에게 두 가지 모두 만족스럽지 않은 선택지를 강요했습니다. 첫째는 거의 모든 명령(심지어 읽기조차)을 사용자가 일일이 승인하게 하는 것입니다. 둘째는 Full Access 모드처럼 어떤 제약도 없이 Codex가 마음대로 모든 명령을 실행하도록 허용하는 것입니다. 전자는 에이전트의 핵심 가치(귀찮은 일을 대신 해 주는 것)를 무너뜨리고, 후자는 안전성을 통째로 포기합니다. OpenAI가 Windows용 샌드박스를 직접 만들기로 결정한 이유가 바로 여기에 있습니다.

기존 Windows 격리 도구가 부족했던 이유

OpenAI가 처음 검토한 것은 Windows가 이미 제공하는 격리 메커니즘들이었습니다. 결과적으로 이 중 어느 것도 그대로 쓰기에는 부족했지만, 각 도구의 한계를 짚어 보는 과정은 최종 설계가 왜 그런 모양이 되었는지를 이해하는 좋은 출발점입니다.

AppContainer: 강한 격리, 너무 좁은 모양

AppContainer는 Windows가 기본 제공하는 네이티브 샌드박스로, 능력(capability) 기반의 격리 모델입니다. 앱이 미리 자신이 무엇에 접근해야 하는지를 정확히 선언하고, 그 외의 모든 리소스에 대한 접근을 운영체제가 차단하는 방식입니다. 일종의 "최선 노력(best-effort)" 제한이 아닌 진짜 OS 경계를 제공한다는 점에서 매력적이었습니다.

그러나 Codex는 미리 범위를 좁혀 정의할 수 있는 종류의 앱이 아닙니다. 셸, Git, Python, 패키지 관리자, 빌드 도구, 그리고 에이전트가 그때그때 필요로 하는 임의의 바이너리까지 모두 구동하는, 열린 개발자 워크플로 자체를 다루기 때문입니다. AppContainer는 격리가 강하지만 그것은 매우 좁은 종류의 작업 부하에 맞춰진 강함이었고, "에이전트가 개발자처럼 일하도록 허용한다"는 요구와는 결이 맞지 않았습니다.

Windows Sandbox: 일회용 VM, 그러나 워크스페이스가 분리됨

Windows Sandbox는 Microsoft가 제공하는 일회용 경량 VM입니다. 세션이 끝나면 그 안에서 일어난 모든 일이 사라지는, 완전히 신선한 Windows 데스크톱을 강력한 격리 경계와 함께 제공합니다. AppContainer보다 훨씬 광범위한 소프트웨어와 호환되며, 보안 관점에서도 더 단단한 박스입니다.

문제는 Codex가 사용자의 실제 체크아웃, 도구, 환경 위에서 직접 동작해야 한다는 점입니다. 별도의 일회용 데스크톱 안에서 작동시키려면 게스트/호스트 브리지와 별도 셋업이 필요해지고, 무엇보다도 Windows Sandbox는 Windows Home SKU에서는 사용할 수도 없습니다. 제품 관점에서 결정적인 제약입니다.

Mandatory Integrity Control: 우아하지만 시스템 전체에 영향

Mandatory Integrity Control (MIC)은 Windows의 "무결성 수준(integrity level)" 개념을 활용합니다. 시스템은 객체와 프로세스에 low, medium, high 같은 라벨을 부여하고, 낮은 무결성 프로세스가 높은 무결성 객체에 쓰기 작업을 시도하면 ACL이 허용하더라도 차단합니다. 종이 위에서 보면 우아한 해법입니다. Codex를 low integrity로 실행하고, 쓰기 가능한 루트만 low integrity로 재라벨링하면, Windows가 알아서 다른 위치에 대한 쓰기를 차단해 줍니다.

그러나 무결성 라벨은 ACL과 마찬가지로 실제 호스트 파일시스템을 직접 수정하며, 그 변경의 의미가 의외로 넓습니다. 워크스페이스를 low integrity로 표시한다는 것은 "Codex가 여기 쓸 수 있다"가 아니라 "low integrity 프로세스 전반이 여기 쓸 수 있다"가 됩니다. 실제 개발자 머신에서는 사용자의 작업 체크아웃이 호스트 전체의 low-integrity sink가 되어 버리는 셈입니다. 특정 합성 SID에만 ACL을 부여하는 방식보다 훨씬 위험한 신뢰 모델 변경이고, 정당화하기도 어렵습니다.

이 세 가지 모두를 사실상의 비채택 사유로 판단한 뒤, 팀은 자체적으로 샌드박스를 설계하기 시작합니다.

첫 번째 프로토타입: "비승격(unelevated) 샌드박스"

첫 번째 작동하는 프로토타입의 목표 중 하나는 승격(elevation) 없이 동작하는 것이었습니다. 즉 Codex가 샌드박스를 설정하거나 실행하기 위해 사용자에게 관리자 권한을 요구해서는 안 됩니다. 이 제약 아래에서 두 가지를 합리적으로 제한해야 했습니다. 하나는 파일 쓰기, 다른 하나는 네트워크 접근입니다.

SID와 write-restricted token

해법의 출발점은 두 가지 Windows 빌딩 블록이었습니다. 하나는 SID(Security Identifier)로, Windows가 권한과 연결하는 정체성 식별자입니다. 사용자에게도 SID가 있고, 그룹에도 SID가 있으며, 개별 로그인 세션조차 자기 SID를 가집니다. 예를 들어 현재 로그인 세션은 S-1-5-5-X-Y 같은 형태의 SID를 가질 수 있고, 로컬 관리자 그룹은 S-1-5-32-544로 표현됩니다.

Windows는 실제 사용자에 대응되지는 않지만 ACL(Access Control List)에는 등장할 수 있는 합성 SID(synthetic SID) 를 만들 수 있도록 허용합니다. Codex 샌드박스 전용 SID를 만들어서, 머신의 다른 어떤 것에도 영향을 주지 않으면서 권한을 표현할 수 있다는 뜻입니다.

다른 하나는 write-restricted token입니다. Windows의 프로세스 토큰은 실행 중인 프로세스의 정체성과 권한을 정의하는 보안 객체이고, write-restricted token은 그 중에서도 쓰기 작업에 대해 Windows가 추가 접근 검사를 수행하도록 만드는 특수한 토큰입니다. 쓰기가 성공하려면 두 가지 검사를 모두 통과해야 합니다.

토큰의 일반 사용자 정체성(소유자)이 그 작업을 허용받았는가
토큰의 restricted SID 목록 안에 있는 SID 중 적어도 하나도 동일하게 접근을 부여받았는가

즉 ACL을 통해 샌드박스가 파일시스템 어디를 수정할 수 있는지를 매우 세밀하게 정의할 수 있습니다.

파일 쓰기 통제 흐름

이 두 가지 도구를 조합해서 비승격 샌드박스가 만들어 낸 흐름은 다음과 같습니다.

샌드박스 셋업이 sandbox-write라는 합성 SID를 만듭니다.
이 sandbox-write SID에 다음 위치에 대한 쓰기/실행/삭제 권한을 부여합니다.
1. 현재 작업 디렉터리(cwd)
2. config.toml에 지정된 추가 writable_roots
동시에, 같은 SID에 대해 다음과 같은 "쓰기 가능 안에서도 읽기 전용" 위치에 대한 쓰기 권한을 명시적으로 거부합니다.
1. <cwd>/.git
2. <cwd>/.codex
3. <cwd>/.agents
Codex는 자식 명령을 Everyone, 현재 로그인 세션 SID, 그리고 sandbox-write 합성 SID가 포함된 restricted SID 목록을 가진 write-restricted token으로 실행합니다.

이 구조는 파일 쓰기를 제한하는 문제에 대해서는 충분히 동작했습니다. 남은 과제는 네트워크였습니다.

네트워크 제어의 한계: 환경 변수와 PATH 가리기

네트워크 제한은 샌드박스에서 중요합니다. 그 제한이 없으면 악성 코드가 사용자 머신에서 인터넷으로 데이터를 유출(exfiltration)할 수 있기 때문입니다. 그러나 승격을 피하는 한, Windows Firewall처럼 진짜로 강하게 트래픽을 차단할 수 있는 도구는 관리자 권한 없이는 설치/구성할 수 없습니다.

대신 팀은 "개발자들이 실제로 쓰는 네트워크 도구들이 fail-closed로 동작하게 만들기"라는 차선을 시도했습니다. 즉 Git 명령이나 패키지 인스톨러처럼 네트워크를 쓰는 도구들이 샌드박스 안에서는 실패하도록 만들고, 그러면 사용자가 인터넷이 필요한 작업을 명시적으로 승인하게 되는 그림입니다. 구체적으로는 프록시 인식 트래픽을 죽은 엔드포인트로 보내고, Git의 HTTP(S) 전송도 마찬가지로 막고, SSH를 통한 Git을 즉시 실패시키는 식입니다. 추가로 denybin이라는 작은 디렉터리를 PATH 앞에 끼워 넣고 PATHEXT 순서를 조정해, 실제 OpenSSH 바이너리보다 스텁(stub) SSH/SCP 스크립트가 먼저 잡히도록 만들었습니다.

대표적인 환경 변수 오버라이드 예시는 다음과 같습니다.

HTTPS_PROXY=http://127.0.0.1:9
ALL_PROXY=http://127.0.0.1:9
GIT_HTTPS_PROXY=http://127.0.0.1:9
NO_PROXY=localhost,127.0.0.1,::1
GIT_SSH_COMMAND=cmd /c exit 1

이 접근은 도구가 환경 변수를 존중하는 한 작동했지만 어디까지나 권고적(advisory) 인 통제였습니다. 프로세스가 환경 변수를 무시하거나, PATH를 우회하거나, 직접 소켓을 열어 버리면 그만이기 때문입니다. 적대적 코드를 막기에는 너무 약한 보호망이라는 평가가 따라붙었습니다.

비승격 샌드박스의 장단점

첫 번째 프로토타입은 표준 Windows 도구만으로 파일 쓰기에 대한 매우 세밀한 통제를 제공했고, 사용자에게 승격을 강요하지 않았다는 점에서 사용성 측면의 이점이 컸습니다. 그러나 동시에 다음과 같은 한계가 분명했습니다.

셋업 속도: 워크스페이스의 디렉터리 구조에 따라 ACL을 적용하는 비용이 매우 크게 늘어날 수 있습니다.
풋프린트: 비록 합성 SID에만 묶여 있어 침습적이지는 않더라도, 결국 개발자 시스템 위에 실제 ACL을 남기게 됩니다.
의미 변경의 어려움: ACL 기반 통제는 의미를 바꾸기 어렵습니다. macOS에서는 .sbpl 파일을 다시 생성하는 것만으로 Seatbelt 정책을 동적으로 바꿀 수 있지만, Windows의 ACL은 갱신이 느리고 무거운 작업입니다.
약한 네트워크 보호: 이미 살펴본 것처럼, 환경 변수에 의존하는 권고적 차단은 자기만의 네트워크 스택을 가진 프로그램이나 적대적 코드에 의해 쉽게 우회됩니다.

앞의 세 가지는 "유연한 에이전트 워크플로용 커스텀 샌드박스"의 본질적 한계에 가깝지만, 네트워크 통제는 본질적으로 다릅니다. 악의적 에이전트만이 아니라 선의의 도구조차도 환경 변수를 존중하지 않거나 자체 소켓 코드를 갖고 있다면 차단을 우회해 버리기 때문입니다. 팀은 이 지점에서 더 나은 샌드박스 모드에 투자할 가치가 충분하다고 판단했습니다.

Windows Firewall을 쓰려면 무엇이 필요한가

더 강한 네트워크 차단을 위해서는 Windows Firewall이 가장 자연스러운 도구입니다. 사용자나 프로그램 단위로 아웃바운드 트래픽을 차단할 수 있기 때문입니다. 그러나 단순히 "Codex 하네스가 만들어 낸 명령들"에만 적용되는 방화벽 규칙을 만드는 것은 쉽지 않았습니다.

Windows는 restricted token의 비주(non-principal) 정체성에 방화벽 규칙을 매칭시키는 것을 허용하지 않습니다. 즉 "restricted SID 목록에 우리 합성 SID가 포함된 모든 토큰"이라는 형태로 규칙을 적을 수 없습니다.
특정 바이너리에 매칭되는 규칙은 codex.exe 자체에만 적용될 뿐, 에이전트가 사용자 대신 띄우는 Git이나 Python 같은 자식 프로세스에는 적용되지 않습니다.
사용자 단위 규칙은 비승격 설계에서 결국 "실제 Windows 사용자"에 매칭되어 버립니다. 프로그램 경로 단위 규칙은 너무 거칠어서 python.exe 전체를 차단하게 됩니다. 포트/주소 기반 규칙은 정책의 결 자체가 다릅니다. 우리는 443번 포트를 막고 싶은 게 아니라, 이 특정 제한 프로세스 트리 의 임의 아웃바운드 접근을 막고 싶은 것이기 때문입니다.

이 모든 제약이 가리키는 결론은 명확했습니다. 샌드박스 명령을 실제 사용자가 아닌 별도 주체(principal) 로 실행해야 한다는 것입니다. 그리고 이 결론은 자연히 "승격 없이 운영한다"는 초기 제약을 완화하는 방향으로 팀을 이끌었습니다.

재설계: "승격(elevated) 샌드박스"

현재 채택된 두 번째 구현은 셋업 시점에 관리자 권한이 필요합니다. 그래서 이름도 "elevated sandbox"입니다. Codex가 시스템에 명령을 띄우는 경계 자체는 비승격 버전과 비슷합니다. 여전히 자식 프로세스는 [Everyone, Logon, Synthetic]이라는 동일한 restricted SID 목록을 가진 write_restricted 토큰 아래에서 실행됩니다. 그러나 이 토큰의 주체(principal) 가 더 이상 실제 Windows 사용자가 아니라, Codex가 직접 생성한 두 개의 로컬 사용자 중 하나라는 점이 핵심적인 차이입니다.

CodexSandboxOffline: 방화벽 규칙의 대상(블록 대상)
CodexSandboxOnline: 방화벽 규칙의 대상이 아님(네트워크 허용 케이스용)

작은 차이로 보일 수 있지만, 이 변경은 누가 샌드박스를 사용할 수 있는지, 셋업과 런타임 실행이 얼마나 복잡해지는지에 큰 파급 효과를 일으킵니다.

더 길어진 셋업 단계

비승격 샌드박스의 셋업은 단순했습니다. 합성 SID를 만들고, 그 SID에 대한 ACL을 적용하면 끝이었습니다. 승격 샌드박스의 셋업은 그보다 훨씬 많은 일을 합니다.

필요하다면 합성 SID 생성
온라인/오프라인 샌드박스 사용자 생성(이미 있다면 재사용)
생성된 사용자들의 자격 증명을 로컬에 저장하되, 샌드박스 사용자 자신은 읽을 수 없는 위치에 DPAPI(Data Protection API)로 암호화
CodexSandboxOffline 사용자의 모든 아웃바운드 네트워크를 차단하는 방화벽 규칙 생성(또는 기존 규칙 검증)

여기에 추가로 까다로운 부분이 하나 있습니다. Codex의 샌드박스는 실제 Windows 사용자와 동등한 읽기 권한을 가져야 한다는 기대입니다. 비승격 버전에서는 restricted token의 주체 SID가 곧 실제 사용자였기 때문에 이 기대가 저절로 충족되었습니다. 그러나 주체가 새로 만든 CodexSandbox 사용자가 되는 순간, 많은 디렉터리들이 "Authenticated Users"에만 읽기/실행 권한을 부여하기 때문에 단순한 파일 읽기조차 실패할 수 있습니다. 대표적인 예가 사용자의 프로파일 디렉터리입니다. 기본 설정상 Windows 사용자는 다른 Windows 사용자의 프로파일을 읽지 못합니다.

이 문제를 해결하기 위해 팀은 샌드박스 셋업 과정에 읽기 ACL 부여 레이어를 추가했습니다. 다음과 같은 디렉터리들이 그 대상입니다.

C:\Users\<real-user>
C:\Windows\
C:\Program Files\
C:\Program Files (x86)\
C:\ProgramData\

이 목록은 모두 처리하면 좋지만 "best-effort"에 가깝고, 각 디렉터리에 ACL을 적용하는 비용이 만만치 않습니다. 그래서 이 로직은 사용자가 기다리는 동기적 셋업 단계와는 별개로 비동기적으로 진행되도록 분리되었습니다.

셋업을 별도 바이너리로 분리한 이유

이 셋업 로직은 별도의 바이너리(codex-windows-sandbox-setup.exe)로 캡슐화되어 있습니다. 부분적으로는 UAC(User Account Control) 경계를 필요한 시점에만 넘기 위해서지만, 더 근본적으로는 아키텍처적 결정에 가깝습니다. 셋업의 책임은 codex.exe와 본질적으로 다르고, 분리해 두면 다음과 같은 이점들이 있습니다:

codex.exe는 일반적인 비승격 하네스로 단순하게 유지됩니다.
Windows에서만 의미 있는 셋업 머신러닝이 다른 플랫폼의 codex.exe를 부풀리지 않습니다.
오래 걸리는 셋업 작업을 메인 프로세스의 수명에서 분리할 수 있습니다.
샌드박스가 필요로 하는 여러 셋업 경로를 한 곳에서 다룰 수 있습니다.

자식 프로세스를 띄우는 두 단계: `codex-command-runner.exe`

남은 문제는 "샌드박스 사용자로 자식 명령을 실제로 어떻게 띄울 것인가"입니다. 비승격 버전에서는 단순히 CreateRestrictedToken(...)을 호출한 뒤 그 토큰으로 프로세스를 생성하는 직선적인 흐름이 가능했지만, 이제는 토큰의 주체가 다른 Windows 사용자입니다. Windows의 사용자/토큰 로그온 경계 규칙 때문에 같은 방식은 통하지 않습니다.

처음 시도된 흐름은 이랬습니다.

codex.exe가 실제 Windows 사용자로 실행되는 상태에서 순차적으로
- 샌드박스 사용자에 대해 LogonUserW(...) 호출
- 그 결과 토큰에 대해 CreateRestrictedToken(...) 호출
- 그 제한된 토큰으로 CreateProcessAsUserW(...) 호출

실제로는 CreateProcessAsUserW(...) 단계에서 권한 벽에 부딪혔습니다. codex.exe는 샌드박스 사용자용 제한 토큰을 만들 수 있었지만, 실제 사용자 쪽 경계에서 그 토큰을 사용해 자식 프로세스를 안정적으로 띄울 수는 없었습니다. 제한 토큰 생성과 최종 프로세스 생성이 모두 샌드박스 사용자 쪽 경계에서 일어나도록, 이미 샌드박스 사용자로 동작 중인 별도 프로세스가 필요했습니다.

이 요구가 새 바이너리 codex-command-runner.exe를 낳았습니다. 이 바이너리의 유일한 임무는 제한 토큰을 만들고 요청된 명령을 띄우는 것이며, 전체 흐름은 두 부분으로 쪼개집니다.

Part 1

codex.exe가 CreateProcessWithLogonW(...)를 호출해 codex-command-runner.exe를 샌드박스 사용자로 띄웁니다. 이 단계에서는 아직 restricted token을 사용하지 않습니다.

Part 2

러너 내부에서 OpenProcessToken(GetCurrentProcess(), ...)으로 자기 자신의 토큰을 엽니다. 이 토큰은 이미 샌드박스 사용자에 속해 있습니다.
GetTokenInformation(...)으로 샌드박스 로그온 SID를 추출하고, CreateRestrictedToken(...)으로 최종 제한 토큰을 만듭니다.
여전히 러너 안에서, 이 제한 토큰으로 CreateProcessAsUserW(...)를 호출해 진짜 자식 프로세스를 띄웁니다.

최종 아키텍처의 네 레이어

알베르트 아인슈타인의 "Everything should be made as simple as possible, but no simpler" 라는 격언이 어울리는 지점입니다. 단순하게 끝낼 수 없는 문제를, 필요한 만큼만 복잡하게 풀어 놓은 결과가 다음의 네 레이어입니다.

codex.exe 자체(일반 비승격 하네스)
codex-windows-sandbox-setup.exe(승격 셋업 작업 일체)
codex-command-runner.exe(제한 토큰을 만들고 명령을 실행)
최종 자식 프로세스(에이전트가 실제로 띄우는 명령)

다른 OS와 비교했을 때 절대 단순한 시스템은 아니지만, 각 복잡성 조각은 모두 필요에 의해 추가된 것들입니다.

비승격 vs 승격 샌드박스 비교

두 설계의 차이를 한눈에 정리하면 다음과 같습니다.

항목	비승격 샌드박스 (1차 프로토타입)	승격 샌드박스 (현재 구현)
셋업 시 관리자 권한	불필요	필요
자식 프로세스 주체	실제 Windows 사용자	`CodexSandboxOnline` / `CodexSandboxOffline`
파일 쓰기 통제	합성 SID + ACL + write-restricted token	동일하되 주체가 샌드박스 사용자
네트워크 통제	환경 변수/`denybin` 기반의 권고적 차단	Windows Firewall이 강제하는 사용자 단위 아웃바운드 차단
워크스페이스 외 읽기	실제 사용자 권한 그대로 상속	별도 read-ACL 부여 단계 필요(비동기)
자격 증명 보호	해당 없음	DPAPI로 암호화 저장
설치된 바이너리	`codex.exe`	`codex.exe` + 셋업 바이너리 + 커맨드 러너
의미 변경 비용	ACL 재설정이 비싸고 느림	여전히 ACL 의존, 대신 네트워크 통제는 방화벽 규칙으로 단순화

승격 샌드박스는 셋업 복잡도와 권한 요구가 분명 늘어났지만, 그 비용을 치러야만 진짜 OS 수준의 네트워크 격리를 얻을 수 있다는 것이 OpenAI가 내린 결론입니다.

안전성과 사용성의 균형이라는 핵심 교훈

OpenAI가 이 글에서 강조하는 결론은 두 가지입니다. 첫째, Windows는 "안전한 자율 코딩 에이전트"라는 문제에 깔끔하게 대응되는 단일 원시 도구를 제공하지 않습니다. 결국 여러 도구와 개념을 조합해야 일관된 시스템이 만들어집니다. AppContainer, Windows Sandbox, MIC처럼 초기에 검토했던 후보들은 대부분 부분적 해법이었고, 최종 설계는 그 부분 해법들의 하이브리드에 가깝습니다.

둘째, 코딩 에이전트의 보안은 전통적인 애플리케이션 보안과 결이 다릅니다. Codex는 실제 개발자 워크플로 위에서 동작해야 하기 때문에, 엔지니어링 작업은 결국 에이전틱 작업과의 호환성과 실제 보안 강제 사이의 균형을 맞추는 일이었습니다. 어떤 명령은 항상 인터넷이 필요하고, 어떤 명령은 절대 인터넷이 필요 없어야 하며, 어떤 파일은 항상 쓰기 가능해야 하고 어떤 파일은 절대 그러지 말아야 합니다. 이 모든 결정이 모여 지금의 네 레이어 아키텍처를 만들어 냈습니다.

이 균형감은 Codex 사용자 입장에서 보면 매우 실질적인 차이로 다가옵니다. Windows 사용자가 더 이상 "거의 모든 명령을 직접 승인하기"와 "전부 다 허용하기"라는 양극단 사이에서 선택할 필요가 없어졌기 때문입니다. 기본 모드에서 Codex는 워크스페이스 안에서는 자유롭게 일하지만, 그 바깥으로 나가는 쓰기나 인터넷 접근은 OS가 직접 차단합니다.

OpenAI Codex 공식 페이지

https://openai.com/codex/

Building a safe, effective sandbox to enable Codex on Windows 블로그

https://openai.com/index/building-codex-windows-sandbox/

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~