Codex Windows 샌드박스, 로컬 에이전트 보안의 기준선

AI 요약

• 무슨 일: OpenAI가 2026년 5월 13일 Codex의 Windows-native sandbox 설계를 공개했습니다.
  • 핵심은 AppContainer 하나로 끝나는 앱 격리가 아니라, 별도 sandbox user, restricted token, ACL, firewall rule, command runner를 조합한 로컬 실행 경계입니다.
• 의미: 코딩 에이전트 경쟁은 모델 점수에서 개발자 PC의 파일, 네트워크, credential, audit trail을 누가 더 잘 통제하느냐로 이동하고 있습니다.
• 실무 영향: 기업이 Codex, Claude Code, Cursor 같은 에이전트를 배포하려면 Full Access 편의성보다 OS 수준 샌드박스와 로그 정책을 먼저 검토해야 합니다.
• 주의점: Windows 샌드박스는 강한 보안 경계이면서도 설치, ACL, Microsoft Store 패키지 경로 같은 운영 복잡성을 동반합니다.

OpenAI가 2026년 5월 13일 공개한 Codex Windows 샌드박스 설계는 단순한 엔지니어링 회고가 아닙니다. 코딩 에이전트가 “채팅창 안의 도우미”에서 “개발자 머신에서 명령을 실행하는 로컬 행위자”로 바뀌었을 때, 보안 경계가 어디에 있어야 하는지를 보여주는 사건입니다. 모델이 코드를 잘 쓰는지는 이제 첫 번째 질문입니다. 더 어려운 질문은 에이전트가 그 코드를 쓰기 위해 어떤 파일을 읽고, 어디에 쓸 수 있고, 언제 네트워크를 열 수 있으며, 누가 그 행동을 감사할 수 있느냐입니다.

Codex는 이미 CLI, IDE 확장, 데스크톱 앱, 웹 기반 작업 흐름으로 확장됐습니다. GitHub의 openai/codex 저장소는 Codex CLI를 “로컬 컴퓨터에서 실행되는 코딩 에이전트”라고 설명하고, 2026년 5월 기준 8만 개가 넘는 star와 수백 개의 릴리스를 갖고 있습니다. 이 규모에서 로컬 실행은 더 이상 실험 기능이 아닙니다. 개발자가 매일 쓰는 shell, package manager, test runner, Git, IDE, 로컬 credential과 마주치는 배포 표면입니다.

Windows 지원보다 중요한 것은 실행 경계입니다

OpenAI는 2026년 3월 Codex 앱을 Windows로 확장했습니다. 당시 보도와 발표에서 강조된 것은 PowerShell 지원, Visual Studio와 JetBrains 계열 IDE, Git Bash, GitHub Desktop, WSL 같은 Windows 개발 환경과의 통합이었습니다. 하지만 5월의 엔지니어링 포스트가 보여준 진짜 핵심은 “Windows에서도 Codex가 돌아간다”가 아니라 “Windows에서 에이전트가 실제 개발자처럼 움직이면서도 시스템 전체를 건드리지 않게 만들 수 있는가”입니다.

OpenAI 설명에 따르면 Codex는 개발자 노트북에서 실행됩니다. CLI든 IDE 확장이든 데스크톱 앱이든, 로컬 harness가 사람과 클라우드 모델 사이의 대화를 관리하고, 모델이 요청한 명령을 사용자의 컴퓨터에서 실행합니다. 기본적으로 Codex는 실제 사용자 권한으로 동작할 수 있습니다. 이는 강력하지만 위험합니다. 에이전트가 테스트를 실행하고 파일을 수정하고 Git branch를 만들 수 있다면, 같은 통로로 원치 않는 파일 쓰기나 네트워크 접근도 발생할 수 있기 때문입니다.

초기 Windows 사용자는 불편한 선택지에 가까웠습니다. 하나는 거의 모든 명령을 승인하는 방식입니다. 읽기 명령까지 계속 확인해야 하므로 에이전트를 쓰는 생산성 이점이 줄어듭니다. 다른 하나는 Full Access mode입니다. 마찰은 적지만 통제도 줄어듭니다. 에이전트가 개발자 권한으로 너무 넓게 움직이는 순간, 보안팀 입장에서는 일반 앱보다 더 까다로운 행위자가 됩니다. 일반 앱은 기능이 정해져 있지만, 코딩 에이전트는 shell, compiler, package manager, 브라우저 자동화, 외부 도구를 조합할 수 있기 때문입니다.

OpenAI가 문제를 이렇게 정의한 점이 중요합니다. “AI 모델이 안전한가”만 묻지 않고, “모델이 지시한 로컬 프로세스 트리가 OS에서 어떤 권한을 갖는가”를 묻습니다. 이것은 앱 보안이면서 동시에 운영체제 보안, 개발자 경험, 기업 감사의 문제입니다.

Windows에는 에이전트용 단일 primitive가 없었습니다

macOS에는 Seatbelt, Linux에는 seccomp나 bubblewrap 같은 격리 도구가 있습니다. 완벽하다는 뜻은 아니지만, “이 프로세스와 자식 프로세스가 어디까지 읽고 쓰고 네트워크를 열 수 있는가”를 표현할 수 있는 비교적 익숙한 수단이 있습니다. OpenAI 포스트의 핵심 진술은 Windows에는 이 문제에 바로 들어맞는 단일 primitive가 없었다는 것입니다.

OpenAI는 먼저 AppContainer를 검토했습니다. AppContainer는 UWP 앱처럼 필요한 capability를 미리 알고 있는 앱에는 강한 경계가 될 수 있습니다. 그러나 Codex는 정해진 앱 하나가 아닙니다. 에이전트는 shell을 열고, Git을 부르고, Python이나 Node를 실행하고, 프로젝트마다 다른 빌드 도구를 만집니다. OpenAI가 보기에 AppContainer는 강하지만 너무 좁은 모양이었습니다.

Windows Sandbox도 후보였습니다. 가벼운 일회용 VM이므로 보안적으로는 매력적입니다. 하지만 Codex는 사용자의 실제 checkout, 도구, 환경에서 작업해야 합니다. 별도 Windows 데스크톱 안에 프로젝트를 복사하고, host와 guest를 연결하고, 매번 개발 환경을 맞추는 방식은 제품 경험과 맞지 않습니다. 게다가 Windows Sandbox는 모든 Windows SKU에서 쓸 수 있는 기능도 아닙니다.

Mandatory Integrity Control도 검토됐습니다. 낮은 integrity level의 프로세스가 높은 integrity object에 쓰지 못하게 하는 Windows 보안 모델입니다. 종이 위에서는 우아합니다. Codex를 낮은 integrity로 실행하고 workspace만 낮은 integrity로 표시하면 될 것처럼 보입니다. 그러나 OpenAI는 이 방식이 실제 host filesystem의 의미를 바꾼다는 점을 문제로 봤습니다. workspace를 낮은 integrity sink로 만들면 Codex만이 아니라 다른 low-integrity process에도 의미가 생깁니다. 개발자 실제 checkout의 신뢰 모델을 넓게 바꾸는 셈입니다.

이 대목은 다른 코딩 에이전트에도 적용됩니다. 로컬 에이전트는 일반 SaaS보다 훨씬 더 지저분한 환경에서 실행됩니다. 사용자의 home directory, 회사 VPN, 사내 package registry, 오래된 Visual Studio 설치, 개인 SSH key, credential helper, EDR agent, proxy 설정이 모두 섞여 있습니다. 모델 안전성만으로는 이 표면을 줄일 수 없습니다. OS가 enforcement를 해야 합니다.

첫 설계는 파일 쓰기를 잡았지만 네트워크가 약했습니다

OpenAI의 첫 Windows 샌드박스 프로토타입은 관리자 권한 없이 동작하는 방향이었습니다. 핵심은 synthetic SID와 write-restricted token입니다. SID는 Windows가 권한을 표현하는 identity입니다. OpenAI는 sandbox-write라는 synthetic SID를 만들고, 현재 작업 디렉터리와 writable_roots에만 쓰기, 실행, 삭제 권한을 부여했습니다. 반대로 .git, .codex, .agents처럼 writable root 안에 있지만 읽기 전용으로 남겨야 하는 위치는 명시적으로 쓰기를 막았습니다.

이 방식은 파일 쓰기에는 꽤 좋은 답입니다. 프로세스가 쓰기 작업을 하려면 일반 사용자 권한과 restricted SID 권한을 모두 통과해야 합니다. 사용자는 원래 파일을 읽을 수 있고, Codex는 workspace 안의 허용된 경로만 바꿀 수 있습니다. macOS나 Linux의 샌드박스 정책과 모양은 다르지만, 목표는 비슷합니다. 에이전트가 프로젝트 작업은 할 수 있게 하되, 우연히 home directory 전체를 수정하지 못하게 하는 것입니다.

문제는 네트워크였습니다. 관리자 권한 없이 firewall rule을 강제하기 어려웠기 때문에, OpenAI의 초기 설계는 환경 변수와 PATH 조작에 의존했습니다. 예를 들어 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처럼 proxy-aware traffic을 죽은 endpoint로 보내고, GIT_SSH_COMMAND=cmd /c exit 1로 Git over SSH를 실패시키는 방식입니다. 또 denybin 디렉터리를 PATH 앞에 두어 SSH나 SCP 같은 명령이 먼저 막히도록 했습니다.

이것은 실용적인 차단이지만 보안 경계로는 약합니다. 많은 정상 도구도 proxy 환경 변수를 무시할 수 있고, 악성 코드는 더 쉽게 직접 socket을 열 수 있습니다. OpenAI는 이를 advisory 수준으로 봤습니다. 이 판단이 중요합니다. 코딩 에이전트 보안에서 “대부분의 npm install은 막힌다”와 “임의 자식 프로세스의 outbound network가 OS에서 차단된다”는 완전히 다른 주장입니다. 기업 배포에서 필요한 것은 후자입니다.

최종 설계는 별도 사용자와 firewall로 갑니다

OpenAI의 최종 설계는 “elevated sandbox”입니다. 이름 그대로 설치 시점에 관리자 권한이 필요합니다. 대신 네트워크 차단을 OS 수준으로 밀어 넣습니다. 핵심은 Codex가 만든 별도 로컬 사용자입니다. CodexSandboxOffline은 firewall rule이 적용되는 사용자이고, CodexSandboxOnline은 네트워크가 허용되는 사용자입니다. 이렇게 하면 firewall이 “이 sandboxed process tree의 outbound access를 막아라”에 더 가까운 정책을 표현할 수 있습니다.

이 설계에는 여러 부품이 필요합니다. codex-windows-sandbox-setup.exe는 sandbox user를 만들고, credential을 로컬에 저장하되 DPAPI로 암호화하고, offline user의 outbound network를 막는 firewall rule을 만들거나 검증합니다. 동시에 sandbox user가 사용자의 개발 환경을 읽을 수 있게 일부 경로에 read ACL을 부여합니다. C:\Users\<real-user>, C:\Windows\, C:\Program Files\, C:\Program Files (x86)\, C:\ProgramData\ 같은 경로가 예시로 언급됩니다. 이 작업은 비싸질 수 있으므로 OpenAI는 일부를 비동기로 처리한다고 설명합니다.

또 하나의 부품은 codex-command-runner.exe입니다. Codex 본체가 실제 사용자로 실행된 뒤, sandbox user로 명령을 직접 spawn하는 과정에는 Windows 권한 장벽이 있습니다. 그래서 OpenAI는 command runner를 sandbox user로 띄우고, 그 안에서 restricted token을 만들고 최종 child process를 실행하는 구조를 택했습니다. 최종 그림은 네 계층입니다. codex.exe, sandbox setup binary, command runner, 그리고 에이전트가 실행하는 child process입니다.

이 구조는 예쁘지 않습니다. OpenAI도 단순하지 않다고 인정합니다. 하지만 단순하지 않은 이유가 중요합니다. Windows가 코딩 에이전트라는 새로운 workload에 딱 맞는 경계를 제공하지 않기 때문입니다. 에이전트는 일반 앱보다 더 자유롭게 움직여야 하지만, 실제 사용자보다 덜 자유로워야 합니다. 개발 도구와 호환되어야 하지만, 악성 dependency나 잘못된 모델 행동이 네트워크로 빠져나가면 안 됩니다. 이 중간 지대가 바로 로컬 에이전트 플랫폼의 어려움입니다.

보안팀이 봐야 할 것은 sandbox만이 아닙니다

같은 주 OpenAI는 자사 내부에서 Codex를 안전하게 운영하는 방식도 공개했습니다. 여기서 강조점은 endpoint sandbox를 넘어섭니다. CLI와 MCP OAuth credential을 OS keyring에 저장하고, login을 ChatGPT로 강제하며, 특정 Enterprise workspace에 묶습니다. 즉 Codex 사용이 개인 계정이나 임의 API key로 흩어지지 않도록 workspace control plane에 연결합니다.

명령 승인 정책도 분리합니다. 모든 shell command를 같은 위험으로 보지 않고, gh pr view, kubectl get, kubectl logs 같은 읽기 중심 명령은 허용하고, 위험한 명령은 차단하거나 승인을 요구하는 식입니다. 코딩 에이전트가 실제 생산성을 내려면 매번 사람에게 묻는 구조로는 어렵습니다. 그러나 전부 허용하면 보안팀이 받아들이기 어렵습니다. 그래서 정책은 “에이전트가 자주 하는 정상 작업을 빠르게 통과시키되, 위험한 경로는 명시적으로 잡는” 모양이 됩니다.

또 하나는 telemetry입니다. OpenAI는 Codex event를 OpenTelemetry로 내보내고, user prompt, tool approval decision, tool execution result, MCP server usage, network proxy allow/deny event 같은 정보를 로그화한다고 설명합니다. Enterprise와 Edu 고객은 ChatGPT Compliance Logs Platform에서도 Codex activity log를 볼 수 있습니다. 이 말은 코딩 에이전트 운영에서 로그의 의미가 바뀐다는 뜻입니다. EDR이 “프로세스가 실행됐다”를 말해준다면, Codex 로그는 “사용자가 무엇을 요청했고, 에이전트가 왜 그 명령을 선택했는가”를 보완합니다.

기업 입장에서 이 조합이 중요합니다. sandbox는 사고를 줄입니다. 그러나 sandbox만으로는 누가 어떤 의도로 어떤 repo에서 어떤 도구를 실행했는지 설명하지 못합니다. 반대로 audit log만 있고 OS enforcement가 없으면, 로그는 사후 기록일 뿐입니다. 로컬 코딩 에이전트의 신뢰 모델은 두 층이 함께 있어야 합니다. 실행 전에는 권한과 네트워크를 제한하고, 실행 후에는 의도와 결과를 재구성할 수 있어야 합니다.

실제 사용자 환경에서는 마찰이 남습니다

이 설계는 강력하지만, 비용이 없습니다. GitHub issue #17901은 좋은 예입니다. 한 사용자는 Microsoft Store 패키지의 WindowsApps 경로에 read ACL을 부여하는 과정에서 SetNamedSecurityInfoW failed: 5가 발생해 Codex Windows 데스크톱 앱 초기화가 실패한다고 보고했습니다. 이 이슈는 OpenAI 공식 설계의 취약점을 증명한다기보다, Windows host filesystem과 패키지 권한, Store 앱 경로, sandbox user read access가 만나는 지점이 얼마나 까다로운지 보여줍니다.

보안 경계가 실제 개발자 경험과 충돌하는 사례는 앞으로 더 늘어날 수 있습니다. 예를 들어 회사 EDR이 sandbox setup binary를 의심할 수 있고, MDM 정책이 로컬 사용자 생성을 제한할 수 있으며, 기업 proxy가 CodexSandboxOffline과 CodexSandboxOnline의 네트워크 정책을 별도로 다뤄야 할 수 있습니다. package manager cache, private registry credential, Git credential helper, SSH agent, Windows certificate store도 모두 질문이 됩니다. 에이전트가 개발자처럼 행동하려면 접근이 필요하지만, 바로 그 접근 때문에 통제가 필요합니다.

이 지점에서 “로컬 에이전트는 그냥 VM 안에서 돌리면 된다”는 답은 절반만 맞습니다. VM이나 WSL, devcontainer는 강한 격리를 줄 수 있지만, 사용자의 실제 IDE, 파일 watcher, GUI 도구, Windows-native toolchain과 멀어질 수 있습니다. 반대로 host에서 직접 실행하면 호환성은 좋아지지만 경계가 약해집니다. OpenAI의 설계는 이 tradeoff의 중간을 택합니다. host에 가깝게 실행하되, OS 사용자와 firewall, restricted token으로 경계를 세웁니다.

경쟁은 모델에서 harness로 이동합니다

이 뉴스가 중요한 이유는 OpenAI만의 Windows 구현 때문이 아닙니다. 코딩 에이전트 경쟁의 중심이 모델에서 harness로 이동하고 있기 때문입니다. Claude Code, Cursor, GitHub Copilot agent, Devin, Codex는 모두 모델 성능을 말하지만, 실제 기업 채택을 좌우하는 것은 모델 주변의 실행 환경입니다. 어떤 파일을 읽을 수 있는가. 어떤 명령을 승인 없이 실행할 수 있는가. 네트워크는 기본 차단인가. credential은 어디에 저장되는가. 로그는 SIEM으로 갈 수 있는가. PR patch는 어떻게 검토되는가.

OpenAI는 Codex Security에서도 비슷한 방향을 보입니다. Codex Security 문서는 GitHub repository에 연결해 threat model을 만들고, repository history를 스캔하고, isolated environment에서 취약점 재현을 시도한 뒤, 사람이 검토할 patch를 제안한다고 설명합니다. 여기서도 핵심은 모델이 취약점을 “말하는” 것이 아니라, 코드베이스 문맥과 실행 환경, 재현, PR workflow를 묶는 것입니다.

따라서 앞으로의 코딩 에이전트 평가는 SWE-bench 점수만으로 부족합니다. 좋은 질문은 더 운영적입니다. 에이전트가 실패할 때 blast radius는 어디까지인가. 의심스러운 명령은 누가 승인하는가. network allowlist는 어떻게 관리하는가. enterprise workspace와 개인 계정을 어떻게 분리하는가. 로컬 개발 환경에서 만들어진 artifact가 supply chain에 들어가기 전 어떤 검증을 거치는가. Windows 샌드박스 포스트는 이런 질문들이 제품 문서의 주변부가 아니라 본문으로 들어왔다는 신호입니다.

개발팀이 지금 확인할 것

개발팀이 Codex나 다른 로컬 코딩 에이전트를 도입한다면, 첫 체크리스트는 모델 선택이 아닙니다. 로컬 실행 모드를 확인해야 합니다. Full Access를 기본으로 켜야만 일이 되는 환경인지, workspace-write와 network-disabled 모드에서 어느 정도 생산성이 나오는지, private registry 접근은 언제 승인되는지, test runner가 외부 네트워크 없이 동작하는지 봐야 합니다.

두 번째는 repo 경계입니다. 에이전트가 mono-repo 전체를 읽어도 되는지, 민감한 secret, customer fixture, production dump가 workspace에 섞여 있지 않은지, .env, SSH key, cloud credential이 자동으로 노출되지 않는지 확인해야 합니다. 에이전트 샌드박스가 아무리 좋아도, workspace 안에 너무 많은 민감 데이터가 있으면 blast radius는 여전히 큽니다.

세 번째는 감사입니다. 에이전트가 만든 commit이나 PR만 보는 것은 부족합니다. 어떤 prompt로 시작했는지, 어떤 shell command를 실행했는지, 어떤 MCP server와 app connector를 불렀는지, 어떤 command가 차단됐는지를 남겨야 합니다. OpenAI가 OpenTelemetry와 Compliance Logs를 강조한 이유도 여기에 있습니다. 로컬 에이전트는 개발자 생산성 도구이면서 동시에 새로운 privileged automation입니다.

마지막으로, Windows 지원은 단순히 “Mac 사용자만 쓰던 도구가 Windows에도 왔다”가 아닙니다. 많은 기업 개발자는 Windows 노트북, 사내 보안 정책, Microsoft Store 앱 배포, PowerShell, Visual Studio, WSL이 뒤섞인 환경에서 일합니다. 이 표면을 정면으로 다루지 못하면 코딩 에이전트는 개인 생산성 도구에 머뭅니다. OpenAI의 Windows 샌드박스 공개는 로컬 에이전트가 기업 배포 단계로 들어가기 위해 어떤 종류의 낮은 수준의 엔지니어링을 해야 하는지를 보여줍니다.

결론은 다소 건조합니다. 코딩 에이전트의 다음 기준선은 더 똑똑한 답변이 아니라 더 좁고 설명 가능한 실행입니다. 에이전트가 개발자처럼 일하려면, 개발자 권한 전체를 그대로 주는 방식으로는 오래 버티기 어렵습니다. OpenAI가 Windows에서 별도 사용자, firewall, restricted token, command runner를 조합한 이유가 여기에 있습니다. AI가 코드를 쓰는 시대의 보안은 모델 카드만으로 완성되지 않습니다. 로컬 OS가 어디까지 허락하고 어디서 멈추는지가 제품의 신뢰를 결정합니다.