Copilot 샌드박스를 켜도 인터넷은 열린다: 로컬 세션의 권한 결정표

작업 트리를 따로 만들었으니 에이전트도 격리됐다고 생각하기 쉽다. 하지만 다른 디렉터리에서 명령을 실행한다는 사실은 그 명령이 홈 폴더, 사내 개발 서버, Git 인증 정보에 접근하지 못한다는 뜻이 아니다. 파일 배치의 분리와 실행 권한의 제한은 별개의 일이다.

GitHub는 2026년 9월 23일 Copilot 앱의 로컬 샌드박싱을 공개 프리뷰로 발표했다. 프로젝트별로 파일·네트워크·인증 정보 정책을 요청하고, 운영체제가 요청한 정책을 강제할 수 없으면 샌드박스 없이 계속 실행하는 대신 셸을 오류로 중단하는 기능이다. 다만 스위치를 켰다고 모든 접근이 차단되는 것은 아니다. 기본 허용 범위, 실행 중인 세션의 상태, 예외 실행을 함께 읽어야 한다.

1. 작업 트리와 샌드박스는 다른 질문에 답한다

작업 트리는 동시 작업의 브랜치와 파일을 분리한다. 반면 로컬 샌드박스는 에이전트가 호출하는 도구를 운영체제의 제한된 실행 환경 안에 넣는다. 공식 문서도 작업 트리만으로는 명령이 컴퓨터의 다른 위치에 접근하는 것을 막지 못한다고 설명한다.

이번 기능은 Copilot 앱의 로컬 저장소·작업 트리 세션에 적용된다. 클라우드 샌드박스 세션이나 원격 호스트에서 실행되는 세션에는 적용되지 않으며, Copilot CLI의 샌드박스 설정과도 별개다. 같은 Copilot이라는 이름 때문에 앱에서 바꾼 정책이 CLI까지 전파된다고 생각하면 안 된다.

작업 트리의 파일 분리와 로컬 샌드박스의 접근 제한을 대비한 도식

작업 트리 자체는 다른 위치의 접근을 제한하지 않는다. 앱의 로컬 세션과 CLI 설정을 구분한다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/configure-local-sandboxing.

이 구분은 Codex worktree의 공유 상태를 살펴본 글과 연결된다. 그 글은 체크아웃을 나눠도 남는 Git 상태의 공유를 다뤘다. 여기서는 Copilot 앱에서 명령의 파일·통신·인증 접근을 어떻게 제한할지를 다룬다.

2. 켜짐과 최소 권한은 같지 않다

로컬 샌드박싱은 기본적으로 꺼져 있다. 앱 설정에서 프로젝트를 고르고 Sandbox의 Sandbox new sessions를 켜면 그 프로젝트의 새 로컬 세션에 적용된다. 이미 실행 중인 세션은 이 스위치만으로 바뀌지 않는다.

샌드박스를 켠 뒤의 기본 정책도 개발 편의를 남겨 둔다. 작업공간과 현재 작업 디렉터리는 읽고 쓸 수 있으며, 인터넷과 로컬 네트워크 연결, 인증된 Git·GitHub CLI 작업이 기본적으로 허용된다. 따라서 “샌드박스 ON”을 “오프라인·자격 증명 없음”으로 번역해서는 안 된다.

정책은 세 축으로 구성된다.

  • 파일: 추가 읽기·쓰기, 추가 읽기 전용, 거부 폴더를 지정한다. 넓은 상위 폴더를 허용해도 더 구체적으로 거부한 하위 폴더는 거부 상태를 유지한다.
  • 네트워크: 외부 인터넷과 로컬 네트워크 접근을 설정한다. 로컬에는 루프백과 개발 서버 연결도 포함된다.
  • 인증 정보: 인증된 HTTPS Git 작업과 GitHub CLI 인증의 사용 여부를 각각 선택한다. 이는 컴퓨터 안의 모든 종류의 비밀을 한 번에 제거한다는 설명이 아니다.
파일 네트워크 인증 정보의 기본 허용 범위를 세 층으로 표시한 도식

인터넷과 인증 정보는 기본 허용이다. ON 표시만으로 최소 권한을 판단하지 않는다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/configure-local-sandboxing.

프로젝트 설정은 앱이 요청하는 정책이다. 기업 관리 정책 때문에 실제 정책은 더 제한적일 수 있다. 설정을 저장했다는 사실과 운영체제가 그 정책을 지원한다는 사실도 다르다. 지원 여부는 첫 샌드박스 셸이 시작할 때 확인한다.

3. 작업 목적부터 정하는 권한 결정표

아래 표는 공식 기본값을 그대로 복사한 설정표가 아니라, 작업 목적에 따라 권한을 좁히기 위한 편집자 결정표다.

맡길 작업 파일 접근 판단 통신·인증 판단 작업을 넓히기 전 확인
이미 받은 코드의 로컬 수정 작업공간 밖 쓰기를 추가하지 않고, 인접한 민감 폴더를 거부 후보로 검토 의존성이 준비돼 있다면 외부·로컬 연결과 Git 인증이 정말 필요한지 검토 테스트가 네트워크나 외부 데이터에 의존하는지
의존성 설치와 로컬 미리보기 필요한 경로만 추가하고 참고 자료는 읽기 전용 우선 패키지 레지스트리용 인터넷과 미리보기용 로컬 연결을 구분 Linux의 하위 프로세스 로컬 네트워크 제한 범위
변경을 push하고 PR 생성 소스 수정 범위는 그대로 유지 HTTPS Git 인증과 GitHub CLI 인증 중 실제 사용하는 경로만 허용 검토 원격 브랜치·저장소와 게시 권한이 작업 범위에 맞는지

여기서 “검토”가 중요한 이유는 샌드박스 옵션만으로 작업 의도를 판별할 수 없기 때문이다. 예를 들어 로컬 수정이라도 테스트가 외부 API를 호출할 수 있다. 이 경우 연결을 모두 허용하는 대신, 어떤 검증이 외부 서비스를 필요로 하는지 먼저 분리하는 편이 낫다. 반대로 PR을 만들지 않는 코드 분석 작업에 GitHub CLI 인증을 남겨 둘 이유는 줄어든다.

이 결정표는 문서에 근거한 운영 판단이며, 실제 Copilot 앱을 실행해 검증한 보안 실험이나 완전한 격리 보장이 아니다.

로컬 수정 설치 미리보기 PR 생성에 필요한 권한을 판단하는 세 갈래 도식

작업 목적에 맞춘 편집자 결정표. 실제 앱 실행이나 완전한 격리를 입증한 결과가 아니다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/configure-local-sandboxing.

4. 정책 변경의 적용 시점까지 설계한다

파일·네트워크·인증 설정 변경은 새 세션 또는 기존 세션이 재시작될 때 적용된다. 현재 실행 중인 세션의 정책을 설정 화면 변경만으로 즉시 바꾸지 않는다. 기록을 유지하며 세션을 재시작하는 공식 명령은 /restart-session이다.

반면 활성 로컬 세션 안에서 /sandbox on 또는 /sandbox off를 사용하면 해당 세션의 지속적인 override를 만들고 즉시 적용한다. 다른 세션의 프로젝트 기본값은 바꾸지 않는다. 아직 세션이 시작되기 전에 같은 명령을 쓰면 새 세션이 물려받을 프로젝트 기본값을 바꾼다는 차이가 있다.

운영 기록에는 그래서 세 항목을 나눠 적는 것이 좋다. 무엇을 프로젝트 기본값으로 저장했는지, 현재 세션에서 어떤 override를 적용했는지, 변경된 파일·통신·인증 정책으로 언제 다시 시작했는지다. 이는 공식 기능을 바탕으로 한 편집자 권고이지 앱이 제공하는 별도 감사 보고서 기능이라는 뜻은 아니다.

프로젝트 정책 변경과 활성 세션 명령의 적용 시점을 비교한 흐름

지원 확인은 첫 샌드박스 셸 시작 때 이뤄진다. 명시적인 외부 실행 승인 경로는 별도다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/configure-local-sandboxing.

지원하지 않는 플랫폼이나 정책 오류를 만나면 문제를 해결하고 Retry sandbox로 다시 확인한다. “작업을 끝내기 위해 일단 샌드박스를 끈다”는 대응은 보호하려던 범위를 바꾸므로 단순 재시도로 취급하면 안 된다.

5. 오류로 중단하는 설계에도 예외 경로는 있다

공식 문서는 요청한 정책을 운영체제가 강제할 수 없으면 셸이 unsupported-platform 또는 unsupported-policy 오류를 내며 샌드박스 없이 실행하지 않는다고 설명한다. Windows에서도 거부 경로를 설정에 저장할 수 있지만, 활성 샌드박스 기능이 그 거부를 보장하지 못하면 명령이 실패한다. 저장 성공은 정책 강제 성공의 증거가 아니다.

동시에 Linux에는 구체적인 범위 제한이 있다. 셸 명령이나 로컬 MCP·LSP 서버처럼 생성된 하위 프로세스에 대해서는 로컬 네트워크 접근을 독립적으로 제어할 수 없다. 설정은 웹 요청이나 원격 MCP 연결처럼 프로세스 내부에서 처리하는 작업에는 계속 적용된다. 따라서 로컬 네트워크 스위치 하나로 모든 실행 경로를 같은 수준으로 통제한다고 일반화하지 않아야 한다.

또한 정책이 허용하지 않는 접근이 필요하면 앱은 Run outside the sandbox? 확인을 표시할 수 있다. 실제 정책에 따라 취소, 한 번만 샌드박스 밖에서 실행, 현재 세션의 남은 동안 샌드박스를 끄고 실행하는 선택지가 있다. 기업 소유자는 이런 외부 실행을 막을 수 있다. 이 명시적인 예외 승인과 “지원 불가 시 자동으로 보호를 풀고 실행하지 않는다”는 원칙은 서로 다른 경로다.

확인 창에서 임시로 끈 샌드박스는 프로젝트 기본값이나 세션 override를 바꾸지 않으며, 세션이 재시작되거나 다시 연결되면 임시 해제가 끝난다. 직접 /sandbox off로 만든 override와 같은 것으로 기록하면 이후 상태를 잘못 해석할 수 있다.

Gemini CLI의 컨테이너 접근 차단을 분석한 글은 파일 밖의 권한 있는 서비스로 가는 경로도 검토해야 하는 이유를 보여준다. 다만 그 글의 구현 세부를 Copilot 앱에 그대로 적용했다는 근거는 없다. 이번 발표 역시 특정 취약점의 수정이나 측정된 보안 성능 향상을 보고한 자료는 아니다.

적용 판단: 스위치보다 세션의 실제 경계를 본다

이 기능의 실용성은 모든 에이전트를 완전히 안전하게 만든다는 약속이 아니라, 프로젝트에 필요한 접근을 명시하고 지원되지 않는 정책을 조용히 무시하지 않는 데 있다. 처음 도입한다면 작업 유형을 정한 뒤 파일·통신·인증을 각각 검토하고, 새 정책으로 시작한 세션인지 확인하자. 예외 실행이 생기면 작업 성공과 별도로 권한 경계가 달라졌음을 기록해야 한다.

공개 프리뷰이므로 동작과 지원 범위는 바뀔 수 있다. 이 글은 2026년 9월 24일 확인한 공식 공지와 문서에 근거하며, 실제 적용 시에는 아래 문서의 최신 플랫폼 제한과 기업 정책을 다시 확인하는 것이 좋다.

출처

댓글

댓글 쓰기

이 블로그의 인기 게시물

체크아웃은 분리됐는데 Git 상태는 공유된다: Codex 0.154 worktree의 세 경계

이미지
1. --worktree 가 해결하는 충돌은 무엇인가 에이전트 두 개가 같은 저장소에서 동시에 파일을 고치면 가장 먼저 부딪히는 것은 모델이 아니다. 한쪽이 바꾼 작업 트리와 인덱스를 다른 쪽이 읽고, 테스트 산출물이 섞이고, 아직 정리하지 않은 변경을 다음 작업이 자기 입력으로 오해한다. OpenAI는 GitHub 기준 2026년 9월 9일 22:35 UTC, 한국 시각 10일 07:35에 공개한 Codex 0.154.0에 실험적 managed worktree 기능을 넣었다. 새 실행이나 기존 세션의 fork를 --worktree 로 시작할 수 있고, TUI에서는 /worktree 로 새 대화 또는 현재 대화의 fork를 별도 체크아웃에 둘 수 있다. 공식 릴리스 설명은 이를 "isolated checkouts"라고 부른다. 다만 이 표현을 저장소 전체와 외부 환경까지 격리한다는 뜻으로 읽으면 곤란하다. Git worktree가 분리하는 것은 체크아웃의 파일과 작업별 관리 상태다. Git 공식 문서에 따르면 연결된 worktree는 HEAD , index 같은 파일을 따로 갖지만 나머지 저장소 데이터는 공유한다. 따라서 같은 소스 파일을 동시에 편집하는 충돌은 줄일 수 있어도, 같은 원격 브랜치에 push하거나 같은 배포·테스트 데이터베이스를 건드리는 충돌까지 사라지지는 않는다. 그림 1. Codex 0.154 managed worktree는 체크아웃 생성과 thread 소유권을 연결한다. binding 전 실패 시 체크아웃을 보존한다. 출처: github.com/openai/codex/releases/tag/rust-v0.154.0 . 2. Codex는 새 체크아웃을 어떻게 만든다 0.154.0 태그가 가리키는 커밋의 codex-rs/worktree/src/lib.rs 를 보면 생성 순서가 꽤 보수적이다. 먼저 현재 HEAD 를 commit SHA로 확정한다. 그 SHA에서 git worktree add --detach --...
자세한 내용 보기

잠근 작업이 커밋 뒤 다시 나온다: PostgreSQL 에이전트 큐의 소유권 설계

이미지
1. 잠금은 작업을 소비했다는 기록이 아니다 에이전트 작업자를 여러 개 띄웠다. 각 작업자는 PostgreSQL에서 FOR UPDATE SKIP LOCKED 로 작업 하나를 가져온다. 다른 작업자가 잡은 행을 기다리지 않으니 병렬 처리도 잘되는 것처럼 보인다. 그런데 커밋한 뒤 같은 작업이 다시 나온다면 무엇이 빠진 걸까? 핵심은 행을 잠갔다는 사실과 작업을 맡았다는 상태가 서로 다르다 는 점이다. PostgreSQL 공식 문서는 행 잠금이 트랜잭션 종료 때 풀린다고 설명한다. SKIP LOCKED 는 지금 즉시 잠글 수 없는 행을 건너뛰는 옵션이지, 그 작업을 영구히 큐에서 제거하는 명령이 아니다. 공식 PostgreSQL 18.0 소스의 회귀 테스트에도 이 차이가 드러난다. 상태를 바꾸지 않고 조회만 하는 순서에서 세션 A가 작업 1을 잠그면 B는 작업 2를 받는다. A가 커밋한 뒤 B가 다시 조회하면 작업 1이 나온다. 프로젝트가 저장한 기대 출력과 별도로, 이번 글에서는 PostgreSQL 16.2의 격리된 로컬 DB 에서도 이 순서를 실제 확인했다. 문서와 고정 소스는 18 계열, 직접 실행한 엔진은 16.2다. 두 버전을 같은 실험으로 섞거나 최신 버전의 성능 측정이라고 부르지 않는다. 그림 1. 잠금이 해제돼도 작업 상태가 그대로면 같은 작업이 다시 선택된다. 공식 18.0 기대 출력과 별도 16.2 로컬 확인에 근거한 자체 도식. 출처: www.postgresql.org/docs/18/sql-select.html . 조회 결과가 0행일 때도 해석에 주의해야 한다. 모든 후보가 다른 작업자에게 잠겨 있으면 SKIP LOCKED 는 아무것도 반환하지 않을 수 있다. 로컬 확인에서는 일반 조회로 보이는 행이 2개인데 잠금 건너뛰기 조회는 0행이었다. 따라서 “지금 가져올 작업이 없다”와 “큐 자체가 비었다”는 같은 말이 아니다. 공식 문서 역시 이 옵션이 일반적인 일관된 조회에는 적합하지 않고, 큐와 비슷한 테이블의 여러 소비자 사이 경합을...
자세한 내용 보기

코딩 에이전트는 API 문서보다 AGENTS.md를 먼저 읽었다

이미지
코딩 에이전트를 위한 문서를 만든다고 하면 보통 API 레퍼런스나 상세한 개발 가이드부터 떠올린다. 그런데 실제 에이전트의 작업 기록을 분석한 연구에서는 다른 문서가 훨씬 자주 등장했다. AGENTS.md , CLAUDE.md 같은 지시 파일과 계획·작업 노트였다. 2026년 8월 공개된 논문 From Agent Behaviour to Agent-Friendly Documentation 은 공개된 코딩 에이전트 세션과 풀 리퀘스트를 이용해 에이전트가 어떤 문서를 읽고 쓰는지 조사했다. 연구진이 분석한 데이터는 다음과 같다. SWE-chat의 파싱 가능한 세션 557개 개발 이벤트 94,813개 문서 관련 이벤트 3,033개 AIDev의 에이전트 풀 리퀘스트 33,097개 파일·커밋 단위 변경 기록 690,260개 에이전트가 가장 자주 만진 문서 문서 상호작용에서 가장 큰 비중을 차지한 것은 에이전트 지시 파일이었다. 문서 유형 이벤트 수 비중 에이전트 지시 파일 1,074 35.4% 계획·작업 노트 760 25.1% 작업 및 요구사항 문서 301 9.9% 설정 문서 205 6.8% README 197 6.5% API 레퍼런스 40 1.3% 지시 파일과 작업 노트를 합하면 전체 문서 상호작용의 60.5%다. API 레퍼런스는 1.3%에 그쳤다. 지시 파일이 API 레퍼런스보다 약 27배 많이 관찰된 셈이다. 코딩 에이전트의 문서 관련 이벤트 분포. 지시 파일과 계획·작업 노트가 전체의 60.5%를 차지했다. 출처: Gao & Chen, arXiv:2608.20195v1 . 이 수치를 "API 문서는 필요 없다"고 해석하면 곤란하다. 연구가 추적한 것은 저장소 안에서 명시적으로 열린 파일이다. 웹 문서, 모델이 이미 학습한 지식, 코드 주석, 런타임이 자동으로 주입한 문맥은 잡히지 않는다. 정확한 결론은 코딩 에이전트가 저장소 안에서 작업할 ...
자세한 내용 보기