당신의 노트북에서 돌아가는 AI 프로그래밍 도구가 갑자기 회사 기밀 폴더를 열거나 인터넷으로 데이터를 보낸다면? 이건 SF 시나리오가 아니다. AI 코딩 도구는 기본적으로 당신이 할 수 있는 모든 것을 할 수 있는 권한으로 실행된다. 파일 읽기, 폴더 삭제, 네트워크 연결까지. 그리고 Windows를 쓰고 있다면, 이 접근을 자동으로 막아주는 OS 수준의 보호 장치가 기본으로 없다. macOS나 Linux 사용자와는 출발점이 다르다.
---
AI 도구는 왜 당신의 파일 전체에 손을 뻗을 수 있는가
OpenAI의 코딩 에이전트 Codex는 개발자 노트북에서 직접 실행된다. CLI(명령줄 인터페이스), IDE 확장, 데스크톱 앱 어떤 형태로든 마찬가지다. Codex는 클라우드에서 추론(inference, AI가 판단을 내리는 과정)을 처리하지만, 실제로 파일을 읽고 쓰고 명령어를 실행하는 행위는 당신의 컴퓨터에서 일어난다.
OpenAI가 2026년 5월 공식 발표한 엔지니어링 문서에 따르면, Codex는 기본적으로 "실제 사용자의 권한(permissions of a real user)"으로 실행된다. 권한이란 프로그램이 파일을 읽고 쓰거나 네트워크에 접근할 수 있는 권리를 말한다. 즉 Codex는 당신이 로그인한 계정으로 할 수 있는 모든 작업을 이론적으로 수행할 수 있다. 테스트를 돌리고, 파일을 수정하고, Git 브랜치를 만들고, 인터넷에 연결하는 것까지.
이것이 나쁜 설계라서가 아니다. 코딩 도구가 쓸모 있으려면 파일에 접근하고 명령어를 실행할 수 있어야 한다. 문제는 그 접근이 어디까지 허용되는지를 누가, 어떻게 강제하느냐다.
Codex의 기본 동작 방식은 이렇다. 작업 디렉터리(당신이 Codex를 실행한 폴더) 안에서는 파일을 읽고 쓸 수 있다. 그 바깥의 파일은 읽기만 가능하다. 네트워크 접근은 명시적으로 허용하지 않으면 차단된다. 이 규칙 자체는 합리적이다. 하지만 규칙을 적어두는 것과, 컴퓨터가 그 규칙을 물리적으로 강제하는 것은 전혀 다른 문제다.
---
macOS와 Linux는 울타리를 기본으로 제공하고, Windows는 그렇지 않다
샌드박스(sandbox)란 프로그램이 컴퓨터 전체가 아닌 정해진 영역, 놀이터 울타리처럼, 에서만 움직일 수 있도록 OS가 강제하는 기술이다. 규칙을 '선언'하는 것이 아니라 OS가 직접 차단하는 방식이다. 프로그램이 울타리 밖으로 손을 뻗으면 OS가 물리적으로 막는다.
macOS에는 Seatbelt라는 Apple이 내장한 샌드박싱 시스템이 있다. Linux에는 seccomp(시스템 콜을 제한하는 커널 기능)와 bubblewrap(프로세스를 격리된 환경에서 실행하는 도구)이 있다. 이 도구들은 OS 핵심부에 내장되어 있어서, 개발자가 "이 프로그램은 이 폴더와 이 네트워크 주소만 쓸 수 있다"고 선언하면 OS가 그것을 강제로 집행한다.
Windows는 이런 종류의 기능을 기본으로 제공하지 않는다. OpenAI 엔지니어링 팀이 공식 문서에서 직접 밝힌 내용이다: "Windows doesn't currently provide this type of capability out of the box." Codex 팀이 Windows 지원을 추가하려 했을 때, macOS나 Linux처럼 "OS가 알아서 막아주는" 도구가 없었다.
이 차이가 어디서 왔는지를 이해하면 문제의 구조가 보인다. macOS는 iOS 앱 생태계를 관리하면서 샌드박싱을 기본 아키텍처로 채택했다. Linux는 서버와 컨테이너 환경에서 프로세스 격리가 필수였기 때문에 커널 수준의 도구가 발전했다. Windows는 역사적으로 호환성과 편의를 우선시하며 프로그램이 시스템에 광범위하게 접근하는 방식으로 발전해왔다. 선택의 역사가 다르다.
결과적으로 Windows에서 AI 도구를 안전하게 쓰려면, 개발자나 기업이 직접 보호 장치를 만들어야 한다. Codex 팀이 2025년 9월부터 수개월을 들여 Windows 전용 샌드박스를 별도로 구현한 이유가 바로 이것이다.
---
샌드박스로 AI의 '손'을 묶는다는 것이 실제로 무엇을 의미하는가
샌드박스가 동작하는 방식을 생활 언어로 설명하면 이렇다. AI 도구를 실행할 때 OS가 그 도구에게 "너는 이 폴더까지만, 이 네트워크 주소까지만 닿을 수 있다"는 제한을 부여한다. 이후 그 도구가 만들어내는 모든 하위 프로세스, 즉 Codex가 실행하는 명령어들도 같은 울타리 안에 머문다. AI가 "저 폴더 좀 열어봐"라고 시도하면 OS가 차단한다. 요청이 승인된 범위 밖이기 때문이다.
여기서 중요한 구분이 있다. 비밀번호 창을 띄워 "허용하시겠습니까?"를 묻는 방식은 샌드박스가 아니다. 사용자가 실수로 또는 귀찮아서 허용을 누르면 아무 의미가 없다. 진짜 샌드박스는 사용자의 판단과 무관하게 OS가 기술적으로 막는다.
OpenAI 문서에 따르면 Codex의 기본 모드는 이런 보호를 전제로 설계되어 있다. 작업 폴더 외부 쓰기 차단, 네트워크 접근 차단이 소프트웨어 규칙이 아니라 OS가 집행하는 제약으로 작동해야 한다는 것이다. 그런데 Windows에서는 이 집행자 역할을 OS가 맡아주지 않으니, Codex 팀이 직접 그 역할을 하는 구조를 만들어야 했다.
이 문제는 Codex만의 이야기가 아니다. GitHub Copilot, Cursor, 그 외 로컬에서 실행되는 모든 AI 코딩 도구가 동일한 구조적 문제에 직면한다. 로컬에서 높은 위험도 작업을 수행하는 코딩 에이전트에게는 OS가 강제하는 샌드박스 경계가 필요하다. 각 도구 제공업체가 개별적으로 Windows 보호 장치를 구현하지 않는다면, Windows 사용자는 항상 더 취약한 환경에 있게 된다.
한 가지 더 짚어야 할 점이 있다. AI 에이전트가 한 번의 지시로 긴 작업을 수행하는 방식이 일반화되고 있다. 코드 작성부터 테스트, 파일 수정, 커밋까지 한 번에 처리하는 식이다. 작업이 길어질수록 중간에 사람이 개입하지 않으면 잘못된 방향으로 진행될 가능성이 높아진다. 장시간 실행되는 에이전트 작업에는 인간의 승인 체크포인트가 필요하다. 샌드박스가 파일과 네트워크 접근을 물리적으로 막는다면, 승인 체크포인트는 작업의 방향 자체를 사람이 확인하는 안전장치다. 두 가지는 층위가 다른 보호다.
---
완벽한 샌드박스가 없으면 AI 도구를 쓰지 말아야 하는가
이 질문에 대한 답은 "그렇지 않다"이지만, 이유를 정확히 이해해야 한다.
샌드박스가 완벽하지 않아도 제한된 권한으로 실행하는 것만으로도 위험의 대부분을 줄일 수 있다. Codex의 기본 설계처럼, AI 도구가 작업 디렉터리 밖에 쓰지 못하게 하고 네트워크 접근을 기본 차단하는 것은 실질적인 보호다. 이 수준에서도 회사 기밀 폴더를 건드리거나 데이터를 외부로 보내는 사고를 막을 수 있다.
문제는 이 보호가 OS의 강제 집행 없이 소프트웨어 규칙만으로 구현될 때다. 버그가 있거나, 악의적인 프롬프트 주입(모델이 의도치 않은 명령을 따르게 만드는 공격)이 발생하거나, 설정 실수가 있으면 규칙이 우회될 수 있다. OS 수준의 샌드박스는 이런 우회 경로 자체를 차단한다.
현실적인 판단 기준은 이렇다. 작업 내용이 공개해도 무방한 코드라면 현재 수준의 보호도 충분할 수 있다. 하지만 회사 내부 시스템, 고객 정보, 미공개 코드베이스를 다루는 환경에서는 OS 강제 샌드박스가 구현된 도구인지 확인하는 것이 필수 요건이 된다.
---
직장에서 AI 코딩 도구를 도입할 때 확인해야 할 것들
AI 코딩 도구를 실제 업무에 쓰기 전, 다음 세 가지를 순서대로 확인하라.
첫째, 그 도구가 Windows 샌드박싱을 실제로 구현했는지 명시적으로 확인한다. 도구 문서나 공식 발표에서 "Windows 샌드박스" 또는 "OS-level isolation"이라는 언급이 있는지 찾는다. 없다면 소프트웨어 규칙만 있는 것이고, 그 도구는 더 취약한 환경에서 실행된다.
둘째, 도구가 접근하는 범위를 직접 좁혀라. AI 도구를 실행할 때 프로젝트 루트 디렉터리를 명시적으로 지정하고, 그 폴더 밖에는 작업 관련 파일이 없도록 구조를 정리한다. OS 강제 샌드박스가 없더라도, AI 도구가 "볼 수 있는" 파일 자체를 줄이면 노출 범위가 줄어든다. 회사 전체 드라이브를 마운트한 채로 AI 도구를 실행하는 것과, 해당 프로젝트 폴더만 열어둔 채로 실행하는 것은 전혀 다른 위험 수준이다.
셋째, 장시간 자율 작업을 허용하기 전에 체크포인트를 설정한다. AI 에이전트가 "이 기능 전체를 구현해줘"처럼 광범위한 작업을 자율로 수행하도록 두기 전에, 중간 결과를 확인하는 단계를 설계에 넣는다. 코드 리뷰 단계, 파일 변경 목록 확인, 커밋 전 검토가 이에 해당한다. 샌드박스가 물리적 범위를 제한한다면, 체크포인트는 그 범위 안에서 일어나는 일의 방향을 사람이 통제하는 수단이다.
이 세 가지는 특정 도구에만 해당하는 이야기가 아니다. Codex든 Copilot이든 Cursor든, Windows에서 로컬로 실행되는 AI 코딩 도구라면 동일하게 적용된다. OpenAI가 Codex의 Windows 샌드박스를 별도로 구현하는 데 수개월을 투자했다는 사실은, 이 문제가 단순한 설정 하나로 해결되는 수준이 아님을 보여준다. Windows 사용자라면 자신이 쓰는 도구가 그 작업을 얼마나 진지하게 했는지를 확인하는 것이 출발점이다.