로컬 샌드박싱의 정식 출시와 주요 지원 환경
깃허브(GitHub)가 2026년 10월 7일 개발자 PC 환경에서 동작하는 인공지능(AI) 에이전트의 권한을 격리하는 '로컬 샌드박싱(Local Sandboxing)' 기능을 정식 출시(Generally Available)했다고 발표했다. 이번 조치는 지난 2026년 6월 마이크로소프트 빌드(Build 2026)에서 퍼블릭 프리뷰 형태로 공개된 이후 약 4개월 만에 이뤄진 정식 배포다. 앞서 9월 데스크톱 앱에 부분 적용된 데 이어 이번 발표로 주요 개발 환경 전반으로 지원 범위가 확대됐다.
지원 대상 클라이언트는 깃허브 코파일럿 CLI(v1.0.93 이상)와 코파일럿 데스크톱 앱, 그리고 에이전트 호스트(Agent Host) 세션을 사용하는 VS Code 환경이다. 깃허브 측 설명에 따르면 로컬 샌드박스는 개발자 머신 내부에서 코파일럿이 수행하는 자율 에이전트 워크플로에 실행 경계를 부여한다. 이를 통해 에이전트가 실행하는 도구 및 셸 명령어가 파일 시스템, 로컬 및 외부 네트워크, Git 및 깃허브 CLI 인증 자격 증명에 접근하는 범위를 정밀하게 제어할 수 있다.
MXC 아키텍처: 모델과 도구 격리의 분리 구조
로컬 샌드박싱의 핵심 기술 기반은 마이크로소프트의 오픈소스 프로젝트인 MXC(Microsoft eXecution Container)다. MXC는 단일화된 JSON 규격의 샌드박스 정책을 각 운영체제(OS)의 네이티브 보안 제어 계층으로 자동 변환해 주는 프레임워크다. 윈도우 환경에서는 프로세스 컨테이너(ProcessContainer), 리눅스에서는 버블랩(Bubblewrap), macOS에서는 시트벨트(Seatbelt)를 활용해 플랫폼별 맞춤형 실행 격리를 수행한다.
기술적으로 주목할 지점은 모델 연산과 도구 실행의 격리를 철저히 분리했다는 점이다. 코파일럿 에이전트가 배후에서 OpenAI의 GPT 계열 모델을 호출하든 앤스로픽의 클로드(Claude) 계열 모델을 호출하든 상관없이, 로컬 호스트에서 실제 실행되는 도구와 명령어에는 동일한 샌드박스 정책이 일관되게 적용된다. 아울러 지원 환경에서는 모델 컨텍스트 프로토콜(MCP) 로컬 서버와 언어 서버(LSP) 프로세스까지 격리 범위에 포함할 수 있다.
배포 정책과 엔터프라이즈 거버넌스 통제 체계
비용 정책 면에서 로컬 샌드박싱은 사용자 자신의 로컬 연산 자원을 소모하므로 개인(Individual), 비즈니스(Business), 엔터프라이즈(Enterprise) 등 기존 코파일럿 유료 라이선스 보유자에게 추가 과금 없이 기본 제공된다. 이는 깃허브가 인프라를 제공하며 임시 리눅스 컨테이너 환경을 구동하는 대가로 사용량 기반 요금(Usage-based billing)을 부과하는 클라우드 샌드박싱(Cloud Sandboxing)과 구분되는 지점이다.
기업 관리자를 위한 거버넌스 기능도 포함됐다. 엔터프라이즈 조직 관리자는 정책 설정을 통해 조직원들의 코파일럿 환경에서 로컬 샌드박싱을 의무화하도록 강제할 수 있다. 이 설정이 활성화되면 개발자가 임의로 로컬 CLI 옵션에 규제 완화 플래그를 추가하거나 정책을 약화해 우회하는 행위가 원천 차단된다. 이를 통해 기업은 에이전트의 자율성을 허용하면서도 내부 자산에 대한 일관된 통제권을 유지할 수 있다.
기본 허용 정책과 환경 제약에 따른 실무적 한계
깃허브는 로컬 샌드박싱이 안전한 에이전트 실행 경계를 제공한다고 강조하지만, 실무 관점에서는 기능 도입 즉시 완전한 무결성이 보장된다고 단정할 수 없다. 가장 중요한 주의점은 '기본 허용(Default Permissive)' 정책이다. 초기 설정 상태에서는 정상적인 개발 작업을 방해하지 않기 위해 현재 작업 디렉터리와 임시 디렉터리에 대한 쓰기 권한, 아웃바운드 인터넷 접속, Git 자격 증명 사용이 허용된다. 즉, 민감한 리포지토리나 엄격한 오프라인 환경을 원한다면 엔지니어가 직접 정책 파일을 세부 수정해야 한다.
운영체제 호환성 측면에서도 제약이 존재한다. 특히 윈도우 환경의 경우 커널 수준의 프로세스 격리를 온전히 작동시키기 위해 윈도우 11 24H2 이상의 최신 OS 환경이 필수적이다. 레거시 윈도우 환경이나 구형 빌드를 사용하는 개발 조직에서는 로컬 샌드박싱의 보안 혜택을 온전히 누리지 못하거나 도입 과정에서 OS 업그레이드 비용이 수반될 수 있음을 유의해야 한다.
보안 아키텍처 관점의 피해 반경 통제와 도입 권고
로컬 샌드박싱의 성격을 프롬프트 인젝션 차단 솔루션으로 오해해서는 안 된다. 본 기능은 AI 모델의 논리적 착오나 악의적인 프롬프트 조작 자체를 걸러내는 방화벽이 아니다. 대신 악성 명령이 프롬프트나 외부 소스코드를 통해 에이전트로 침투했을 때, 로컬 호스트 시스템에 미칠 수 있는 '피해 반경(Blast Radius)'을 물리적으로 제한하는 실행 계층 격리 기술이다.
따라서 개발 팀은 로컬 샌드박싱을 도입할 때 기본 설정에만 의존하지 말고, 프로젝트 성격에 맞춰 네트워크 차단 및 디렉터리 접근 거부 규칙을 단계적으로 강화하는 전략을 취해야 한다. 엔터프라이즈 환경에서는 관리자 정책을 통해 필수 실행을 잠그고, 빌드 및 의존성 다운로드 등 외부 통신이 필요한 단계와 순수 코드 분석 단계를 분리하는 등 실무적인 정책 튜닝이 병행되어야 에이전트 자동화의 잠재적 위험을 실질적으로 낮출 수 있다.
출처
GitHub Changelog의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
Local sandboxing for GitHub Copilot now generally available (새 창)
