Copilot 로컬 샌드박스 GA, 이제 코딩 에이전트는 ‘내 계정 전체’로 뛰면 안 된다

GitHub Copilot 로컬 샌드박스를 오늘 봐야 하는 팀은 “Copilot이 코드를 잘 짜는지”가 궁금한 팀이 아니라 AI 코딩 에이전트에게 터미널·파일·네트워크·자격증명 접근을 맡기기 시작한 팀이다. 확인 기준일은 2026년 10월 10일이다. GitHub는 10월 7일 로컬 샌드박싱이 Copilot CLI, GitHub Copilot app, VS Code의 Agent Host 세션에서 일반 제공된다고 밝혔다. GitHub 변경 공지 결론은 간단하다. 코딩 에이전트의 기본값은 이제 “내 사용자 계정으로 마음껏 실행”이 아니라, 프로젝트별 실행 경계와 예외 승인이어야 한다.

개발자 노트북 위 투명한 샌드박스 큐브 안에서 코딩 에이전트가 파일과 네트워크 권한 게이트를 통과하는 3D 개념 이미지 — Copilot 로컬 샌드박스의 핵심은 모델을 더 믿자는 말이 아니라, 에이전트가 실행하는 도구를 내 계정 전체에서 분리하자는 말이다. GPT 생성 개념 이미지다.

오늘의 독자 질문: 코딩 에이전트에게 터미널을 열어 줄 때, 어디까지가 안전한 기본값인가

최근 seonoh.dev에서는 모델 라우팅, 사용 정책, 브라우저·컴퓨터 도구, 에이전트 권한표를 다뤘다. 오늘의 새 기여는 더 좁다. “정책을 세워야 한다”에서 한 걸음 내려와, 로컬 개발 머신에서 실제로 무엇을 막고 열어야 하는지 보는 글이다. 코딩 에이전트가 테스트를 돌리고, 파일을 고치고, MCP 서버와 언어 서버를 호출하는 순간 위험은 답변 품질이 아니라 실행 권한으로 이동한다.

GitHub 문서는 샌드박싱이 Copilot이 코드를 읽고, 도구를 실행하고, 명령을 실행하고, 파일을 수정할 때 필요한 격리·이식성·정책 제어를 제공한다고 설명한다. GitHub 샌드박스 문서 이 문장의 실무 번역은 “프롬프트로 조심하라고 말하기”가 아니다. 에이전트가 읽을 수 있는 폴더, 쓸 수 있는 폴더, 나갈 수 있는 네트워크, 사용할 수 있는 자격증명을 정책으로 나누는 것이다.

가장 큰 변화는 ‘명령 실행’과 ‘모델 실행’을 분리한 점이다

GitHub 변경 공지에서 가장 중요한 문장은 “Model execution and tool isolation are separate concerns”다. 모델이 무엇이든, 샌드박스 정책은 Copilot이 실행하는 도구와 명령에 적용된다는 뜻이다. 도구 격리 원칙 모델을 바꾸는 일과 실행 경계를 바꾸는 일을 한 덩어리로 보면 운영이 흐려진다.

예를 들어 새 모델이 더 똑똑해졌다고 해서 홈 디렉터리 전체 쓰기 권한을 줄 이유는 없다. 반대로 작은 모델을 쓴다고 해서 네트워크나 Git 자격증명 접근이 자동으로 안전해지는 것도 아니다. 위험은 모델 크기보다 “그 모델이 부른 도구가 실제로 무엇을 할 수 있는가”에서 나온다. 그래서 코딩 에이전트 운영표에는 모델명 옆에 실행 경계가 붙어야 한다.

읽기 전용 폴더와 쓰기 가능한 프로젝트 폴더, 차단된 비밀 폴더가 다른 색 차선으로 분리된 3D 이미지 — 파일 권한은 ‘프로젝트를 볼 수 있다’와 ‘어디든 고칠 수 있다’를 분리해야 한다. GPT 생성 개념 이미지다.

로컬 샌드박스는 꺼져 있을 때가 더 무섭다

GitHub 문서는 로컬 샌드박싱이 기본적으로 꺼져 있으며, 켜기 전에는 Copilot이 실행하는 셸 명령이 사용자 계정과 같은 접근 권한으로 직접 실행된다고 설명한다. 파일을 읽고, 쓰고, 삭제할 수 있고, 기기가 닿는 네트워크에 접근하며, 자격증명도 제한 없이 사용할 수 있다는 의미다. 기본 비활성 설명

이 대목이 오늘 실무자에게 제일 중요하다. 코딩 에이전트가 npm test를 돌리는 데 성공했다고 운영 준비가 끝난 게 아니다. 같은 권한으로 rm, curl, gh, 배포 스크립트, 로컬 데이터베이스, 비밀 파일에 닿을 수 있다면 사고 범위는 프로젝트 폴더가 아니라 내 계정 전체다. “에이전트가 실수하지 않게 프롬프트를 잘 쓰자”는 말은 여기서 너무 약하다.

따라서 첫 설정은 보수적이어야 한다. 프로젝트 루트는 읽기·쓰기 후보가 될 수 있지만, 홈 디렉터리, 인증 파일, 클라우드 키, 개인 문서, 다른 저장소는 기본 차단에 가깝게 둔다. 에이전트가 추가 경로를 요구하면 그때 예외 승인으로 다룬다. 권한을 넓히는 순간은 생산성 기능이 아니라 변경 관리 이벤트다.

파일, 네트워크, 자격증명, MCP를 각각 따로 보자

GitHub 문서는 Copilot CLI에서 파일 시스템, 네트워크, Git·GitHub CLI 자격증명, 로컬 MCP 서버와 언어 서버 같은 subprocess, macOS Keychain, 개별 명령 예외를 제어할 수 있다고 설명한다. GitHub Copilot app에서는 파일 시스템, 네트워크, 자격증명 같은 일부 설정을 프로젝트 설정에서 다룬다. 설정 가능한 경계

이 목록을 보면 권한표가 자연스럽게 나온다.

첫째, 파일 시스템은 읽기, 쓰기, 거부를 나눈다. 문서를 읽는 권한과 코드를 고치는 권한은 다르다. 둘째, 네트워크는 인터넷과 로컬 네트워크를 나눈다. 패키지를 설치해야 하는 작업과 내부 서비스에 닿는 작업은 위험이 다르다. 셋째, 자격증명은 별도 스위치로 둔다. gh가 열려 있으면 이슈 조회만 하는 것이 아니라 PR 생성, 댓글, 레포 접근까지 이어질 수 있다. 넷째, MCP와 언어 서버는 “보조 도구”가 아니라 에이전트가 더 많은 문맥과 행동을 얻는 통로다.

샌드박스 안 AI 프로세스가 인터넷과 로컬 네트워크, Git 자격증명, MCP 도구로 향하는 경로를 방화벽 정책이 제어하는 3D 이미지 — 네트워크·자격증명·MCP 서버는 편의 기능이 아니라 에이전트 사고 범위를 정하는 스위치다. GPT 생성 개념 이미지다.

MXC가 해 주는 일과 해 주지 않는 일을 구분하자

GitHub는 로컬 샌드박싱이 MXC로 구동된다고 설명한다. MXC는 공통 샌드박스 정책을 각 운영체제의 격리 백엔드로 번역한다. GitHub 문서는 macOS가 Seatbelt 백엔드를 쓰고, Linux는 bubblewrap 백엔드를 쓰며, Windows 11에서도 사용할 수 있다고 설명한다. 운영체제별 지원

다만 같은 문서는 로컬 샌드박싱이 현재 격리 스펙트럼의 비교적 가벼운 쪽에 있다고 적는다. 명령을 별도 가상머신이나 컨테이너 안에서 돌리는 것이 아니라, 프로세스가 무엇을 읽고 쓰고 네트워크로 어디에 닿는지를 제한하는 방식이라는 설명이다. 격리 수준 설명

이 한계는 약점이라기보다 설계 입력이다. 로컬 샌드박스는 매일 쓰는 개발 흐름에 붙이기 쉬운 안전벨트에 가깝다. 하지만 강한 격리가 필요한 비밀 프로젝트, 고객 데이터, 악성 코드 분석, 미신뢰 저장소 실행은 별도 VM이나 클라우드 샌드박스, 임시 계정까지 함께 봐야 한다. “샌드박스 켰으니 아무 명령이나 괜찮다”가 아니라 “일상 작업의 기본 사고 범위를 줄였다”가 맞다.

하나의 샌드박스 정책 카드가 macOS와 Linux, Windows 격리 블록으로 번역되는 3D 다이어그램 — MXC는 공통 정책을 운영체제별 격리 메커니즘으로 옮기지만, 모든 보안 요구를 VM처럼 해결한다고 보면 안 된다. GPT 생성 개념 이미지다.

클라우드 샌드박스와 로컬 샌드박스는 비용 구조도 다르다

GitHub 문서는 로컬 샌드박싱이 표준 Copilot 좌석에 추가 비용 없이 포함된다고 설명한다. 반면 클라우드 샌드박싱은 완전히 격리된 임시 Linux 환경에서 세션을 실행하고, 사용량 기반으로 과금된다. 같은 문서의 청구 섹션은 compute second, GiB second, snapshot storage 같은 단위를 제시한다. 청구와 실행 위치

그래서 선택 기준은 단순하지 않다. 로컬 저장소를 빠르게 고치고 테스트하는 일은 로컬 샌드박스가 자연스럽다. 격리가 더 강해야 하거나, 로컬 환경을 더럽히고 싶지 않거나, 장시간 세션 상태를 별도 환경에 보존해야 한다면 클라우드 샌드박스가 후보가 된다. 비용을 아끼겠다고 항상 로컬을 고르는 것도, 보안을 말한다고 항상 클라우드로 보내는 것도 답이 아니다.

작은 팀이라면 첫 정책은 이렇게 둘 수 있다. 기본 개발 저장소는 로컬 샌드박스에서 시작한다. 외부에서 받은 미신뢰 저장소, 고객 데이터가 섞인 작업, 공격성 테스트, 배포 자격증명이 필요한 작업은 별도 환경으로 올린다. 로컬에서 샌드박스 밖 예외가 반복되는 작업은 “예외가 많은 정상 작업”이 아니라 “환경을 잘못 고른 작업”으로 본다.

오늘 바로 바꿀 체크리스트

보호된 코드 저장소 주변에 파일 범위와 네트워크, 자격증명, MCP, 예외 승인 카드가 떠 있는 3D 이미지 — 도입 체크리스트는 모델 이름보다 실행 경계, 예외 승인, 감사 로그를 먼저 묻는다. GPT 생성 개념 이미지다.

오늘 적용할 기준은 다섯 줄이면 충분하다.

에이전트 세션을 시작할 때 프로젝트 루트 외 경로는 기본 차단으로 둔다.
읽기 권한과 쓰기 권한을 나누고, 빌드 산출물·임시 폴더만 넓게 허용한다.
인터넷, 로컬 네트워크, Git·GitHub CLI 자격증명은 각각 별도 스위치로 관리한다.
로컬 MCP와 언어 서버도 샌드박스 안에서 돌릴지 확인한다. 원격 MCP는 로컬 샌드박스로 보호되지 않는다는 점을 따로 본다.
샌드박스 밖 실행 예외는 편의 클릭이 아니라 승인 로그로 남긴다.

실패 조건도 분명하다. 샌드박스를 켜 놓고도 “필요할 때마다 예외 허용”을 누르면 정책은 금방 구멍 난다. 반대로 너무 좁게 막아서 매 작업마다 예외가 필요하면 팀은 우회하는 습관을 배운다. 좋은 기본값은 에이전트가 일상 테스트와 코드 수정은 할 수 있지만, 비밀·배포·외부 발송·다른 저장소에는 쉽게 닿지 못하는 지점이다.

FAQ

로컬 샌드박스만 켜면 코딩 에이전트가 안전해지나

아니다. 로컬 샌드박스는 실행 범위를 줄이는 기본 안전장치다. 미신뢰 코드, 고객 데이터, 배포 자격증명, 악성 코드 분석처럼 격리 요구가 큰 작업은 별도 환경과 계정 분리까지 봐야 한다.

샌드박스 정책은 모델별로 다르게 잡아야 하나

모델별 성능 차이는 있을 수 있지만, 실행 경계는 모델과 분리해서 잡는 편이 낫다. GitHub도 모델 실행과 도구 격리를 별도 관심사로 설명한다. 작은 모델이라도 강한 도구 권한을 갖고 있으면 위험은 커진다.

MCP 서버는 왜 따로 봐야 하나

MCP 서버는 에이전트가 외부 도구와 데이터에 닿는 통로다. 로컬 MCP 서버는 샌드박스 정책 안에 넣을 수 있는지 봐야 하고, 원격 MCP 서버는 로컬 샌드박스로 격리되지 않으므로 서버 쪽 권한·로그·토큰 범위를 따로 검토해야 한다.

개발자가 제일 먼저 바꿀 습관은 무엇인가

에이전트에게 “이 폴더에서 알아서 고쳐 봐”라고 주기 전에, 읽기·쓰기·네트워크·자격증명·예외 승인 범위를 먼저 정하는 습관이다. 코딩 에이전트 운영에서 생산성은 권한표를 만든 뒤에 와야 오래 간다.