Codex를 Windows에서 제대로 쓰는 법 (WSL, 샌드박스, 성능까지)

핵심 요약

Windows에서 Codex를 쓸 거라면 WSL2 + VS Code 조합이 가장 안정적이고 성능도 좋습니다.
네이티브 Windows 실행은 샌드박스로 보호되지만 제약과 한계가 있어, 실무 개발 환경은 WSL에 올리는 게 안전합니다.

Codex를 Windows에서 쓰는 두 가지 전략

Windows에서 Codex를 쓰는 방식은 크게 두 가지입니다.
하나는 VS Code/CLI를 그대로 Windows에서 돌리는 방식이고, 다른 하나는 WSL2 안에 "리눅스 개발 환경"을 만들고 그 안에서 Codex를 돌리는 방식입니다.

비즈니스 관점에서 보면, 팀 생산성과 호환성을 고려했을 때 WSL2 방식이 더 유리합니다.
모델이 학습된 환경과 비슷한 리눅스 환경을 쓰게 되므로, 예제 코드·도구·스크립트가 깨질 확률도 줄어듭니다.

WSL2 + VS Code 구성: 실무에 적합한 기본 세팅

먼저 WSL2를 설치합니다.
PowerShell(관리자 권한)에서 한 줄이면 시작할 수 있습니다.

wsl --install

일반적으로 Ubuntu를 선택하면 됩니다.
이후에는 WSL 셸(리눅스 터미널)을 열어, 실제 개발은 이 안에서 진행하는 흐름으로 가져가는 것이 좋습니다.

VS Code에서 WSL 환경을 쓰려면 WSL 확장을 설치한 뒤, WSL 터미널에서 프로젝트 디렉토리로 들어가 다음을 실행합니다.

cd ~/code/your-project
code .

이렇게 실행하면 VS Code가 "WSL 원격 환경"으로 뜨고, 통합 터미널도 리눅스 셸로 동작합니다.
화면 아래 상태바에 WSL: Ubuntu 같은 표시가 보이고, 터미널 경로가 C: 대신 /home/... 형태라면 제대로 연결된 상태입니다.

Codex CLI를 WSL에 설치하는 절차

CLI까지 WSL 안에서 돌려야 Codex가 리눅스 도구 체인과 자연스럽게 연동됩니다.
순서는 "WSL 설치 → Node.js 설치 → Codex 설치"입니다.

먼저 WSL 셸에서 Node.js를 nvm으로 설치합니다.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/master/install.sh | bash
# 새 셸을 열거나 다시 wsl 실행 후
nvm install 22

Node가 준비되면 Codex를 글로벌 설치합니다.

npm i -g @openai/codex
codex

이제 VS Code 통합 터미널(WSL)에서 codex 명령이 그대로 인식됩니다.
만약 VS Code에서 codex를 못 찾는다면, WSL 터미널에서 which codex로 위치를 확인하고, 없으면 위 과정을 다시 수행하면 됩니다.

성능 최적화: 어디에 코드를 둘 것인가

WSL 사용 시 가장 중요한 포인트는 "코드를 어디에 두느냐"입니다.
Windows 디스크를 리눅스에서 마운트한 경로(/mnt/c/...)는 IO가 상대적으로 느려, 대형 레포지토리에서 체감 성능 저하가 크게 나타납니다.

실무에서는 리포지토리를 리눅스 홈 디렉토리 아래로 옮기는 것을 기본 원칙으로 삼는 것이 좋습니다.

mkdir -p ~/code && cd ~/code
git clone https://github.com/your/repo.git
cd repo

이렇게 두면 파일 IO, Git, 빌드 속도가 안정적으로 나오고 권한 문제도 줄어듭니다.
반대로, Windows에서 파일을 보고 싶다면 파일 탐색기에서 \wsl$Ubuntuhome<user> 경로로 접속하면 됩니다.

레포가 커지고 느려진다고 느껴진다면, /mnt/c 아래에서 작업하고 있지 않은지, 그리고 WSL 버전이 최신인지부터 점검해야 합니다.

wsl --update
wsl --shutdown

네이티브 Windows 실행과 실험적 샌드박스

Codex를 Windows에서 직접 실행하면, "에이전트 모드"에서는 실험적인 Windows 샌드박스를 사용합니다.
이는 작업 폴더 밖의 파일 쓰기를 제한하고, 네트워크 사용도 명시적으로 허용하지 않으면 막는 식으로 동작합니다.

구체적으로는 AppContainer 기반 제한 토큰으로 프로세스를 띄우고, 지정한 경로만 파일 쓰기 권한을 주며, 프록시 환경 변수와 네트워크 도구를 가짜로 대체해 외부 통신을 차단합니다.
보안 측면에서는 유용하지만, 완벽하지는 않습니다.

특히 "Everyone"에 쓰기 권한이 열려 있는 폴더(예: 월드 라이트 가능 디렉토리)는 이 샌드박스로도 제어할 수 없습니다.
Codex는 이런 폴더를 찾아 권한을 줄이도록 안내하지만, 사업적으로 중요한 코드·데이터는 이런 경로에 두지 않는 것이 안전합니다.

실무적으로는, 높은 보안이 필요한 자동화 작업에 한해 네이티브 + 샌드박스를 고려하고, 일반 개발 워크플로는 WSL 쪽에 집중하는 구성이 현실적입니다.

설치·속도 문제 트러블슈팅 포인트

VS Code용 Codex 확장을 설치했는데 반응이 없다면, Windows에 C++ 개발 도구가 없어 네이티브 의존성이 깨졌을 가능성이 큽니다.
이 경우 Visual Studio Build Tools(C++ 워크로드)와 VC++ 재배포 패키지를 설치한 뒤 VS Code를 완전히 재시작해야 합니다.

winget install --id Microsoft.VisualStudio.2022.BuildTools -e

속도가 느리게 느껴질 때는, 우선 레포 위치(/mnt/c 여부)와 WSL 리소스 설정, 그리고 최신 업데이트 여부를 점검해야 합니다.
도구 자체 문제로 보기 전에, IO 경로와 환경 설정이 병목인지 확인하는 것이 시간 절약에 도움이 됩니다.

인사이트

스타트업 환경에서는 "개발 속도 + 팀 합류 비용 + 환경 재현성"이 핵심입니다.
Windows를 쓴다면 팀 표준으로 WSL2 + VS Code + Codex CLI를 통일해 두면, 신입/외주/파트너가 들어올 때 환경 설명이 매우 단순해지고, 리눅스 서버와의 차이도 줄어듭니다.

실천 팁을 정리하면,

모든 개발자는 WSL2와 WSL용 VS Code를 기본으로 쓰게 하고,
레포는 무조건 ~/code/... 아래 두며,
Codex는 WSL 안에 설치해 "리눅스 기준 워크플로"를 정착시키는 것이 좋습니다.

이렇게 해 두면, 이후 CI/CD, 서버 배포, 자동화 스크립트까지 같은 감각으로 설계할 수 있어, AI 코딩 도구의 생산성을 팀 전체로 확장하기가 훨씬 수월해집니다.

출처 및 참고 : Windows