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

AI 요약

• 무슨 일: OpenAI가 Codex를 Windows에서 안전하게 실행하기 위한 샌드박스 설계를 공개했습니다.
  • 2026년 5월 13일 엔지니어링 포스트에서 restricted token, ACL, 별도 로컬 사용자, Windows Firewall을 조합한 구조를 설명했습니다.
• 핵심 변화: 네트워크 차단이 환경변수 프록시 수준에서 OS principal과 방화벽 규칙 기반으로 이동했습니다.
• 개발자 영향: 로컬 코딩 에이전트는 이제 모델 성능보다 명령 실행 경계와 승인 UX가 제품 품질을 가릅니다.
• 주의점: 강한 격리와 실제 개발 환경 호환성은 여전히 긴장 관계에 있습니다.

OpenAI가 Codex의 Windows 샌드박스 설계를 공개했습니다. 겉으로 보면 "Codex가 Windows에서도 더 안전하게 돈다"는 제품 업데이트처럼 보입니다. 하지만 실제 내용은 그보다 더 중요합니다. 로컬 코딩 에이전트가 개발자 PC에서 명령을 실행할 때, 운영체제는 어떤 경계를 제공해야 하는가. 앱 샌드박스, VM, 컨테이너, 프록시 환경변수 중 무엇이 충분하고 무엇이 부족한가. 이번 글은 이 질문에 대한 OpenAI의 실전 답안입니다.

OpenAI의 2026년 5월 13일 엔지니어링 포스트는 Codex for Windows가 왜 단순한 포팅 작업이 아니었는지 설명합니다. Codex는 CLI, IDE 확장, 데스크톱 앱에서 개발자 대신 명령을 실행합니다. 테스트를 돌리고, 파일을 읽고, 코드를 고치고, Git 브랜치를 만들고, 때로는 패키지 매니저나 Python 스크립트도 호출합니다. 이런 작업은 "앱 하나를 제한된 권한으로 실행한다"는 전통적 샌드박스 모델과 맞지 않습니다. 코딩 에이전트는 하나의 앱이 아니라 개발자 워크플로 전체를 대신 움직이는 실행 주체에 가깝습니다.

이 차이가 중요합니다. 지금까지 많은 팀은 AI 코딩 에이전트의 안전성을 모델의 정렬 문제로만 보거나, Docker 같은 컨테이너 안에서 돌리면 해결된다고 생각했습니다. 하지만 로컬 개발 환경에서는 이야기가 더 복잡합니다. 에이전트가 실제 checkout을 고치고, 로컬 도구를 쓰고, 테스트와 빌드를 실행해야 한다면 완전히 격리된 VM 안에 가두기도 어렵습니다. 반대로 실제 사용자 권한을 그대로 주면 한 번의 잘못된 명령이 홈 디렉터리, 자격증명, 네트워크, 회사 소스코드까지 건드릴 수 있습니다.

Windows에는 딱 맞는 버튼이 없었습니다

OpenAI가 먼저 검토한 선택지는 세 가지였습니다. AppContainer, Windows Sandbox, Mandatory Integrity Control입니다. 세 기술 모두 Windows 안에서 격리를 제공하지만, Codex가 원하는 모양과는 조금씩 어긋났습니다.

AppContainer는 Windows의 네이티브 샌드박스입니다. 미리 필요한 권한을 알고 있는 앱을 제한된 capability 안에서 실행하는 데 적합합니다. 문제는 Codex가 그런 앱이 아니라는 점입니다. Codex는 사용자의 저장소마다 다른 명령을 실행하고, Git, Python, Node, PowerShell, 빌드 도구, 테스트 러너처럼 예측하기 어려운 하위 프로세스를 호출합니다. 강한 경계는 있지만, "개발자처럼 열려 있는 작업을 수행하는 에이전트"에는 너무 좁은 형태였습니다.

Windows Sandbox는 훨씬 강한 경계를 제공합니다. disposable lightweight VM이므로 보안 관점에서는 매력적입니다. 그러나 Codex는 사용자의 실제 checkout, 실제 도구, 실제 인증 상태와 맞물려야 합니다. 매번 새로운 데스크톱 VM 안에서 환경을 준비하고 host와 guest 사이를 연결하는 방식은 제품 경험을 크게 해칩니다. 게다가 Windows Sandbox는 Windows Home SKU에서 사용할 수 없습니다. 개발자 도구가 특정 에디션에서만 제대로 동작한다면 기본 선택지가 되기 어렵습니다.

Mandatory Integrity Control은 더 미묘합니다. 낮은 integrity level로 프로세스를 실행하고, writable root만 낮은 integrity로 다시 라벨링하면 파일 쓰기를 제한할 수 있습니다. 그러나 이 방식은 실제 host 파일시스템의 의미를 바꿉니다. workspace를 low integrity로 표시하면 "Codex만 쓸 수 있다"가 아니라 low integrity 프로세스 일반이 쓸 수 있는 공간이 됩니다. OpenAI는 이 모델이 실제 개발자 PC의 신뢰 경계를 너무 넓게 바꾼다고 판단했습니다.

이 판단은 AI 에이전트 보안에서 자주 반복될 패턴을 보여줍니다. 가장 강한 격리가 항상 가장 좋은 제품은 아닙니다. 가장 편한 실행도 항상 받아들일 수 있는 위험은 아닙니다. 코딩 에이전트는 그 사이에서 "실제 일을 할 수 있을 만큼 열려 있고, 사고를 막을 만큼 닫힌" 경계를 찾아야 합니다.

첫 프로토타입은 파일에는 괜찮았지만 네트워크가 약했습니다

OpenAI의 첫 working prototype은 관리자 권한 없이 작동하는 unelevated sandbox였습니다. 핵심은 Windows의 SID와 write-restricted token입니다. SID는 Windows가 권한을 연결하는 identity이고, synthetic SID는 실제 사용자나 그룹이 아니지만 ACL에 등장할 수 있는 가짜 식별자입니다. OpenAI는 Codex 샌드박스만을 위한 synthetic SID를 만들고, writable path에만 ACL을 부여하는 방식으로 파일 쓰기를 제한했습니다.

write-restricted token은 여기서 중요한 역할을 합니다. 일반 토큰이 "사용자가 이 파일에 쓸 수 있는가"를 본다면, write-restricted token은 추가 확인을 거칩니다. 특정 restricted SID에도 쓰기 권한이 있어야 실제 쓰기가 성공합니다. 그래서 Codex가 읽기는 넓게 하되 쓰기는 workspace와 허용된 경로로 제한하는 모델을 만들 수 있습니다.

문제는 네트워크였습니다. 첫 프로토타입은 network suppression을 환경변수 기반 프록시 override로 처리했습니다. 많은 개발 도구는 HTTP_PROXY, HTTPS_PROXY 같은 환경변수를 따릅니다. 하지만 모든 도구가 그렇지는 않습니다. 악의적인 명령은 쉽게 우회할 수 있고, 선의의 바이너리도 자체 socket 코드를 쓰면 프록시를 무시할 수 있습니다. OpenAI는 이 지점이 투자할 만큼 중요하다고 판단했습니다.

이 대목이 이번 뉴스의 핵심입니다. 로컬 코딩 에이전트에서 네트워크 차단은 "편의 기능"이 아닙니다. 에이전트가 소스코드, 환경변수, 로그, credentials를 읽을 수 있다면, outbound 네트워크는 곧 유출 경로가 됩니다. 사용자가 명시적으로 인터넷을 열어 준 세션과 기본 차단 세션을 OS가 구분해 강제하지 못하면, 승인 UX는 겉모습만 남습니다.

Elevated sandbox는 principal을 바꿉니다

현재 구현은 elevated sandbox입니다. setup 단계에서 관리자 권한을 요구하고, 그 뒤에는 codex.exe가 일반 사용자 프로세스로 남습니다. OpenAI가 추가한 핵심은 두 개의 로컬 사용자입니다. CodexSandboxOffline과 CodexSandboxOnline입니다. 오프라인 사용자는 Windows Firewall 규칙의 대상이 되어 모든 outbound 네트워크가 차단됩니다. 온라인 사용자는 네트워크가 필요한 모드에서 쓰입니다.

왜 별도 사용자가 필요했을까요. Windows Firewall이 restricted token 안의 synthetic SID만을 대상으로 규칙을 걸 수 없었기 때문입니다. 특정 바이너리 경로에 규칙을 걸면 codex.exe만 막을 뿐, Codex가 호출한 python.exe나 git.exe에는 정확히 적용되지 않습니다. 포트나 주소 기반 규칙도 원하는 정책이 아닙니다. OpenAI가 막고 싶었던 것은 "443 포트"가 아니라 "이 specific restricted process tree의 arbitrary outbound access"였습니다.

그래서 principal 자체를 바꿨습니다. Codex가 실제 사용자로 명령을 실행하는 대신, 샌드박스용 로컬 사용자로 command runner를 실행하고, 그 내부에서 다시 restricted token을 만들어 실제 child process를 띄웁니다. 이렇게 하면 Windows Firewall은 오프라인 샌드박스 사용자에게 규칙을 적용할 수 있고, 그 사용자가 띄운 하위 명령 전체가 같은 정책 안에 들어옵니다.

OpenAI가 설명한 최종 구조는 네 계층입니다. 첫째, codex.exe는 실제 사용자로 실행되는 하네스입니다. 둘째, codex-windows-sandbox-setup.exe는 elevated setup을 맡습니다. 셋째, codex-command-runner.exe는 샌드박스 사용자로 실행되어 restricted token을 만들고 실제 명령을 띄웁니다. 넷째, child process가 개발자가 기대하는 Git, Python, 빌드 도구, 테스트 명령입니다.

이 구조는 단순하지 않습니다. setup은 synthetic SID를 만들고, 온라인/오프라인 샌드박스 사용자를 만들고, credentials를 Windows Data Protection API로 암호화해 저장하고, firewall rule을 만들거나 검증합니다. 또 샌드박스 사용자가 실제 사용자 프로필과 개발 도구를 읽을 수 있도록 일부 경로에 read ACL을 부여해야 합니다. OpenAI는 이 작업 일부를 비동기로 처리해 사용자가 setup을 기다리는 시간을 줄였다고 설명합니다.

"안전한 앱"이 아니라 "안전한 개발자 대리인" 문제입니다

이번 설계가 흥미로운 이유는 보안 대상을 새롭게 정의하기 때문입니다. 전통적인 앱 보안은 보통 특정 애플리케이션의 권한을 제한합니다. 브라우저 탭, 모바일 앱, 샌드박스된 데스크톱 앱처럼 말입니다. 하지만 코딩 에이전트는 하나의 앱이 아니라 작업 수행자입니다. 사용자가 할 법한 명령을 대신 실행하되, 사용자가 해서는 안 된다고 명시한 작업은 하지 않아야 합니다.

이 차이는 정책 언어를 바꿉니다. "이 앱은 네트워크를 쓸 수 있는가"보다 "이 세션에서 에이전트가 네트워크를 쓸 수 있는가"가 중요해집니다. "이 프로세스는 파일을 쓸 수 있는가"보다 "이 에이전트가 지금 맡은 workspace 바깥을 수정할 수 있는가"가 중요합니다. "관리자 권한이 있는가"보다 "setup 때 필요한 권한과 평상시 명령 실행 권한이 분리되어 있는가"가 중요합니다.

이는 AI 제품의 경쟁축도 바꿉니다. 모델이 더 좋은 코드를 쓰는 것은 여전히 중요합니다. 그러나 사용자가 매번 y를 눌러야 하거나, 반대로 Full Access를 켜야만 일이 진행된다면 제품은 장기 작업을 맡기기 어렵습니다. 승인 UX와 OS 경계가 모델 능력의 일부처럼 작동합니다. 에이전트가 오래 일할수록, 중간에 질문하고, 방향을 바꾸고, 권한을 요청하고, 실패를 보고하고, 위험한 명령을 멈추는 능력이 더 중요해집니다.

OpenAI가 바로 다음 날인 2026년 5월 14일 Codex를 ChatGPT 모바일 앱에서 조작할 수 있게 한 것도 이 맥락에서 읽을 수 있습니다. 모바일에서 thread를 이어가고, approval을 처리하고, 원격 SSH 환경을 연결한다는 발표는 사용자가 항상 터미널 앞에 앉아 있지 않아도 장기 실행 에이전트를 조종하게 하려는 움직임입니다. 그런데 장기 실행 에이전트가 유용해질수록 로컬 실행 경계는 더 중요해집니다. 작은 화면에서 승인하는 UX는 편리하지만, 그만큼 기본 정책이 더 엄격해야 합니다.

Windows 지원은 시장 확장보다 보안 실험입니다

Windows 개발자를 1급 시민으로 만든다는 의미도 큽니다. 많은 AI 코딩 도구가 macOS와 Linux 중심으로 먼저 설계됩니다. 그 배경에는 개발자 문화도 있지만, 샌드박스 프리미티브의 차이도 있습니다. macOS에는 Seatbelt가 있고, Linux에는 seccomp, namespaces, bubblewrap 같은 선택지가 있습니다. Windows에서 같은 경험을 만들려면 ACL, token, local user, firewall, UAC 같은 조각을 직접 맞춰야 합니다.

이 작업은 단순한 플랫폼 지원이 아니라 에이전트 런타임의 확장성 실험입니다. AI 코딩 에이전트가 기업 환경으로 들어가려면, macOS를 쓰는 스타트업 개발자만 대상으로 할 수 없습니다. Windows 노트북, managed endpoint, 제한된 권한, 보안 정책, proxy, EDR, 사내 인증이 뒤섞인 환경에서 돌아야 합니다. 이때 "샌드박스가 있습니다"라는 문구만으로는 부족합니다. 어떤 principal로 실행되는지, 어떤 하위 프로세스까지 정책이 전파되는지, 네트워크가 실제로 막히는지, setup 권한이 어디까지 필요한지 설명할 수 있어야 합니다.

커뮤니티 반응도 이 지점을 건드립니다. Reddit의 OpenAI와 Codex 관련 스레드에서는 Windows + WSL을 선호한다는 의견, 샌드박스를 꺼야 했다는 경험, OpenAI가 마침내 Windows를 진지하게 다룬다는 긍정 반응이 함께 나왔습니다. 특히 모바일 Codex 발표와 맞물려 Windows 지원이 아직 일부 흐름에서는 따라와야 한다는 지적도 있었습니다. 이는 자연스러운 긴장입니다. 보안 경계가 강해질수록 호환성 문제는 드러나고, 호환성을 높일수록 경계는 느슨해지기 쉽습니다.

개발팀이 봐야 할 실무 포인트

첫째, 로컬 에이전트 도입 시 "Full Access를 켜면 편하다"는 운영 방식을 기본값으로 두면 안 됩니다. Full Access는 디버깅이나 임시 우회에는 필요할 수 있지만, 장기적으로는 에이전트가 잘못된 명령을 실행했을 때 blast radius를 설명할 수 없습니다. 기본 모드는 쓰기 범위와 네트워크를 제한하고, 예외만 승인하는 방향이 되어야 합니다.

둘째, 네트워크 차단은 환경변수만으로 충분하지 않습니다. 프록시 환경변수는 많은 도구가 따르지만, 보안 경계로 보기에는 약합니다. 자체 socket을 쓰는 바이너리, 프록시를 무시하는 라이브러리, 악성 명령은 쉽게 우회할 수 있습니다. 에이전트가 읽을 수 있는 정보가 많을수록 outbound 네트워크는 OS나 네트워크 계층에서 통제해야 합니다.

셋째, workspace 경계는 생각보다 복잡합니다. 개발자는 저장소 안에서만 작업한다고 말하지만, 실제 빌드는 global cache, package manager cache, temp directory, credential helper, language server, IDE 설정을 건드립니다. 쓰기를 너무 좁히면 작업이 계속 실패하고, 너무 넓히면 샌드박스 의미가 사라집니다. OpenAI가 ACL 부여와 비동기 setup을 별도 계층으로 뺀 것도 이 현실 때문입니다.

넷째, 감사 가능성이 필요합니다. 에이전트가 어떤 명령을 어떤 principal로 실행했고, 어떤 권한 요청을 했고, 어떤 파일을 수정했는지 남지 않으면 기업 환경에서 신뢰하기 어렵습니다. 이번 OpenAI 포스트는 감사 로그 제품을 발표한 글은 아니지만, principal 분리와 runner 구조는 이후 관찰 가능성과 정책 적용의 기반이 될 수 있습니다.

앞으로의 기준선

Codex Windows 샌드박스는 완성된 정답이라기보다 기준선에 가깝습니다. 앞으로 코딩 에이전트가 경쟁할 영역은 모델, IDE 통합, 가격만이 아닙니다. 로컬 명령 실행을 어떻게 제한하는지, 네트워크 권한을 세션 단위로 어떻게 열고 닫는지, 모바일 승인과 원격 devbox를 어떻게 연결하는지, 그리고 이 모든 것을 사용자가 이해할 수 있는 방식으로 어떻게 보여주는지가 중요해집니다.

이 기준선은 다른 에이전트 제품에도 압력을 줍니다. "에이전트가 코드를 고칩니다"라는 말은 이제 충분하지 않습니다. 어디서 실행됩니까. 어떤 사용자로 실행됩니까. 자식 프로세스에도 제한이 전파됩니까. 네트워크는 정말 막힙니까. workspace 밖의 파일을 어떻게 다룹니까. 권한 상승은 setup에만 필요한가요, 매 명령마다 필요한가요. 이런 질문에 답하지 못하는 도구는 기업과 보안 민감 조직에서 오래 버티기 어렵습니다.

흥미로운 점은 이 모든 복잡성이 결국 더 자연스러운 UX를 만들기 위한 비용이라는 것입니다. 사용자는 에이전트에게 오래 걸리는 일을 맡기고 싶습니다. 테스트를 돌리고, 실패 원인을 찾고, 수정하고, 다시 검증하게 하고 싶습니다. 그러나 그러려면 에이전트가 마음대로 움직일 수 있어야 하고, 동시에 마음대로 움직이면 안 됩니다. Codex의 Windows 샌드박스는 그 모순을 운영체제 경계 위에서 풀려는 시도입니다.

이번 발표를 제품 기능 하나로만 보면 작은 뉴스입니다. 하지만 AI driven 개발의 인프라 관점에서는 꽤 큰 신호입니다. 코딩 에이전트의 다음 병목은 "코드를 생성할 수 있는가"에서 "실제 컴퓨터에서 안전하게 일하게 할 수 있는가"로 이동하고 있습니다. Windows 샌드박스는 그 전환이 더 이상 이론이 아니라 제품 엔지니어링의 중심 문제가 되었음을 보여줍니다.