Windows에서 Codex를 쓰고 싶은 개발자가 가장 먼저 부딪히는 질문은 "이 에이전트가 얼마나 똑똑한가"가 아닙니다. 더 현실적인 질문은 "내 프로젝트에서 어디까지 만지게 할 것인가"입니다. 테스트를 돌리고, 패키지를 설치하고, 파일을 고치게 하려면 권한이 필요합니다. 하지만 권한이 넓어지는 순간 샌드박스는 보호막이 아니라 형식이 됩니다.
최근 OpenAI는 Windows에서 Codex를 안전하게 실행하기 위한 샌드박스 설계와 구현 방향을 공개했습니다. 핵심은 Codex가 로컬 파일시스템과 네트워크를 다룰 때, 개발자 계정 전체가 아니라 제한된 경계 안에서 움직이게 만드는 것입니다.1 중요한 변화는 "Windows에서도 Codex가 된다"가 아니라, "Windows 개발자는 이제 AI 에이전트를 기준으로 프로젝트 구조와 승인 방식을 다시 설계해야 한다"는 점입니다.
샌드박스는 벽이 아니라 작업 계약이다
Windows용 Codex의 샌드박스는 에이전트가 작업 폴더 밖을 마음대로 쓰거나, 외부 네트워크에 자유롭게 접근하지 못하게 제한하는 방향으로 설계되어 있습니다. Windows 네이티브 환경에서는 PowerShell 기반으로 실행되며, 전용 샌드박스 사용자 계정, 파일시스템 ACL, 네트워크 제한 같은 장치가 조합됩니다.2
여기서 오해하면 안 되는 점이 있습니다. 샌드박스는 "Codex가 절대 사고를 치지 않는다"는 보증이 아닙니다. 오히려 "Codex가 실패할 수 있는 지점을 의도적으로 만든다"에 가깝습니다. 예를 들어 에이전트가 옆 폴더의 설정 파일을 읽지 못하거나, 외부 API 호출이 막히거나, 패키지 설치 중 네트워크 승인을 요구한다면 그것은 단순 오류가 아닐 수 있습니다. 샌드박스가 경계를 지키고 있다는 신호입니다.
실무적으로는 이 실패를 디버깅 대상으로만 보면 안 됩니다. "왜 못 하지?"보다 "이 작업이 애초에 샌드박스 안에서 끝나도록 설계돼 있었나?"를 먼저 봐야 합니다. Codex에게 맡길 작업은 가능한 한 저장소 내부에서 재현 가능해야 합니다. 로컬 사용자 홈, 임시 다운로드 폴더, 사내 공유 드라이브에 몰래 의존하는 프로젝트일수록 에이전트는 자주 멈추고, 사용자는 승인 버튼을 더 자주 누르게 됩니다.
네이티브 Windows와 WSL, 기준은 '무엇을 만져야 하는가'다
Windows에서 Codex를 쓰는 경로는 크게 두 가지입니다. 하나는 네이티브 Windows 앱이나 CLI를 PowerShell 중심으로 쓰는 방식이고, 다른 하나는 WSL2 안에서 Linux 개발 환경처럼 쓰는 방식입니다. Codex 앱은 Microsoft Store 설치, 병렬 에이전트, worktree 기반 작업, diff 리뷰 같은 흐름을 제공하며 Windows에서는 기본적으로 PowerShell 에이전트를 사용하고 필요하면 WSL로 전환할 수 있습니다.2
네이티브 Windows의 장점은 경계가 Windows 파일 권한과 잘 맞고, 일반적인 Windows 프로젝트를 바로 다룰 수 있다는 점입니다. 반대로 Node, Python, Git, PowerShell 실행 정책, Visual C++ 런타임 같은 로컬 의존성에서 자주 막힐 수 있습니다. 실제로 Windows 환경에서는 npm.ps1 실행 정책, VC 런타임 누락, Git 감지 문제가 반복적으로 보고됩니다.3
WSL은 다른 장점이 있습니다. Linux 서버와 비슷한 셸, 패키지 관리자, 파일 권한 모델을 쓰기 때문에 백엔드·인프라·오픈소스 프로젝트에서는 더 자연스럽습니다. 다만 WSL에서도 프로젝트 위치가 중요합니다. /mnt/c/... 아래 Windows 파일을 WSL에서 다루면 I/O가 느려질 수 있어, 대형 저장소는 ~/code/...처럼 WSL 내부 파일시스템에 두는 편이 낫다는 권고가 많습니다.4
정리하면 이렇습니다. Windows 앱, .NET, PowerShell 스크립트, Windows 경로 의존성이 크다면 네이티브 Codex가 출발점입니다. Linux 배포 환경, Bash 스크립트, 컨테이너, 서버형 프로젝트가 중심이라면 WSL이 더 적합합니다. 보안만 보고 "WSL이 항상 정답" 또는 "네이티브가 항상 안전"이라고 말하기는 어렵습니다. 에이전트가 실제로 만져야 할 파일, 실행해야 할 도구, 팀이 검증할 수 있는 경계가 무엇인지가 기준입니다.
에이전트 친화적인 폴더 구조가 승인 피로를 줄인다
Codex를 잘 쓰는 프로젝트는 사람이 보기 좋은 프로젝트와 조금 다릅니다. 사람은 "내 PC 어딘가에 있는 설정 파일"을 기억할 수 있지만, 샌드박스 안의 에이전트는 그 기억을 권한으로 바꿀 수 없습니다.
가장 좋은 구조는 저장소 안에서 작업이 닫히는 형태입니다. 예를 들어 테스트 픽스처, 샘플 .env, 로컬 실행 문서, 생성물 출력 폴더를 프로젝트 내부에 명확히 둡니다. 실제 비밀값은 넣지 않되, .env.example처럼 에이전트가 구조를 이해할 수 있는 힌트는 제공해야 합니다. 빌드 산출물은 dist, build, coverage처럼 예측 가능한 위치에 모으고, 캐시나 대용량 데이터는 에이전트 작업 대상에서 분리하는 편이 안전합니다.
반대로 피해야 할 구조도 분명합니다. 저장소 밖의 공용 폴더에 테스트 데이터를 두거나, 사용자 홈의 전역 설정에 빌드가 의존하거나, 여러 저장소를 상대 경로로 넘나드는 방식은 Codex에게 계속 추가 권한을 요구하게 만듭니다. 특히 Windows에서 "Everyone" 쓰기 권한이 열려 있는 폴더는 샌드박스 경계가 약해질 수 있다는 제한이 여러 자료에서 지적됩니다.5 편의를 위해 열어둔 공유 폴더가 에이전트에게는 우회로가 될 수 있습니다.
승인 버튼은 신뢰가 아니라 작업 재설계 신호다
Codex가 네트워크 접근, 패키지 설치, 외부 폴더 읽기, 스크립트 실행 승인을 요구할 때 무조건 거절할 필요는 없습니다. 하지만 무조건 허용하는 순간 샌드박스의 가치는 급격히 줄어듭니다.
판단 기준은 단순해야 합니다. 요청 범위가 작업 목적과 정확히 맞으면 승인할 수 있습니다. 테스트 실행을 위해 저장소 내부 스크립트를 돌리는 것, 명시된 패키지를 설치하는 것, 문서화된 API 목업 서버에 접근하는 것은 비교적 좁은 승인입니다. 반대로 "상위 폴더 전체 읽기", "사용자 홈 접근", "광범위한 네트워크 허용"은 작업을 다시 쪼개야 한다는 신호입니다.
더 안전한 대안도 있습니다. 실제 외부 API 대신 녹화된 응답이나 목 서버를 쓰게 하고, 패키지 설치 전 lockfile 변경만 먼저 검토하게 하며, 옆 저장소가 필요하다면 필요한 파일만 현재 작업 폴더로 복사합니다. 승인은 에이전트를 믿는 행위가 아니라, 작업 경계를 명시적으로 갱신하는 행위여야 합니다.
지금 Codex Windows 샌드박스를 신경 써야 할 사람은 "AI 코딩을 한번 써볼까" 수준의 사용자보다, 에이전트에게 실제 저장소를 맡기려는 개발자와 팀입니다. 생산성은 에이전트의 능력에서만 나오지 않습니다. 프로젝트가 샌드박스 안에서 재현 가능하고, 승인 기준이 좁고, 네이티브 Windows와 WSL 중 무엇이 맞는지 판단할 수 있을 때 나옵니다. 앞으로 봐야 할 변화도 기능 추가보다 이 경계가 얼마나 예측 가능해지는가입니다.
참고
1Building a safe, effective sandbox to enable Codex on Windows
2OpenAI Developer Docs -- Codex App Windows
3윈도우 유저 필독: VS Code Codex 익스텐션 무한 로딩 완벽 해결 가이드
4Codex를 Windows에서 제대로 쓰는 법 (WSL, 샌드박스, 성능까지)
5Codex CLI on Windows: Native Sandbox, WSL Integration, and the Elevated Security Model
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.