Copilot 로컬 샌드박스 GA: 설정 저장보다 실제 거부 결과를 확인하기
에이전트에게 테스트를 맡겼는데 의도와 다른 경로를 읽으려 한다면, 좋은 프롬프트만으로 실행 범위를 설명하기 어렵습니다. 10월 7일 GitHub는 Copilot 로컬 샌드박스의 정식 제공을 발표했습니다. 지금 팀이 할 일은 자율 실행량을 늘리는 것보다, 사용하는 실행 화면에서 제한이 실제로 작동하는지 확인하는 것입니다.
GA와 현재 세션의 활성화는 다른 확인입니다
공식 문서는 로컬 샌드박스가 기본적으로 꺼져 있고, Copilot CLI와 앱 설정도 별개라고 설명합니다. CLI의 설정을 바꿨다고 앱의 새 작업이 같은 정책을 쓰는 것으로 판단하면 안 됩니다. 로컬 실행과 클라우드 실행도 구분해야 합니다. 이 글은 제품 설정을 대신 바꾸는 설명이 아니라, 적용 결과를 기록하는 팀 운영 제안입니다.
비밀 대신 가짜 파일로 경계를 시험하기
팀 전용 시험 폴더에 내용이 무해한 파일 세 개를 준비해 보세요. 허용된 읽기 경로, 허용된 쓰기 경로, 접근을 제한할 경로를 따로 두고 해당 세션에서 읽기·쓰기가 기대대로 되는지 확인합니다. 실제 운영 비밀번호나 고객 데이터를 시험 재료로 넣지 않습니다. 테스트 로그에는 파일명과 허용·거부 결과만 남기고, 성공한 쓰기는 시험 파일의 변경 내용까지 대조합니다.
네트워크와 도구는 각각 결과를 남기기
같은 방식으로 팀이 소유한 시험 주소에 대한 접근을 확인하고, 사용하는 로컬 MCP 도구도 별도로 점검합니다. 파일 시험이 통과했다고 모든 외부 연결과 도구가 같은 경계 안에 있다고 가정하지 마세요. GitHub는 모델 실행과 도구 격리가 별개라고 설명합니다. 모델 이름을 바꾸거나 프롬프트에 경고를 붙였다는 사실은 이 실행 증거를 대신하지 못합니다.
거부를 만났을 때 승인 범위를 작게 유지하기
작업이 막히면 먼저 필요한 경로·목적지·동작을 적고 해당 세션의 실제 오류와 비교합니다. 전체 머신 접근을 넓히는 대신 필요한 작업만 검토 대상으로 남기는 것이 이 글의 제안입니다. 반대로 정당한 빌드 출력과 패키지 접근까지 모두 막으면 팀은 반복 예외에 익숙해질 수 있습니다. 좁은 시험 작업을 먼저 통과시키고 정책 변경 전후의 결과, 실행 화면, 확인 시각과 담당자를 함께 보관하세요.
실무에서 먼저 던질 질문은 ‘설정이 있는가’가 아니라 ‘어느 세션에서 어떤 동작이 거부됐는가’입니다. 이 시험은 모든 운영체제와 도구의 완전한 격리를 증명하지 않습니다. 설치 환경과 실행 화면을 바꾸면 다시 확인하고, 로컬 샌드박스를 별도의 가상 머신으로 설명하지 마세요.
공식 근거와 적용 시점
2026년 10월 11일 공식 발표와 문서를 확인했습니다. 위 시험 절차와 기록 방식은 필자의 운영 제안이며 제품의 자동 보증이나 검증된 성능 수치가 아닙니다.