GitHub이 Copilot 관리 설정에 클라이언트 버전 하한과 강제 새로고침을 넣었다. sandbox 키를 넣으면 VS Code 1.141.0 미만 사용자는 업데이트 전까지 접속이 막힌다. 배포 전에 버전을 묶어 둔 기기 수와 오프라인으로 켜는 사용자를 센다.
Copilot Business·Enterprise를 들인 조직에서 IDE 버전은 대개 IT 운영 쪽 배포 일정이 정한다. 망분리 PC나 VDI 이미지를 쓰는 곳은 VS Code를 승인된 버전에 묶어 두고 정해진 주기에만 올린다. 보안팀이 에이전트 샌드박스를 강제하자고 결정하는 회의에 이 버전표가 올라오는 경우는 드물다.
GitHub 10월 13일 변경 기록 이후로는 두 일정이 서로 걸린다. GitHub은 Copilot 엔터프라이즈 관리 설정에 클라이언트 최소 버전 검사를 붙였고, 시작할 때마다 최신 정책을 받아야 Copilot이 돌게 하는 forceRemoteSettingsRefresh를 넣었다.
sandbox 키를 넣는 순간 범위 안 모든 사용자에게 버전 하한이 걸린다
Copilot 로컬 샌드박스는 10월 7일 정식 출시됐다. Copilot이 실행하는 명령의 파일·네트워크·Git 자격 증명 접근을 제한하고, 관리자는 개발자가 완화할 수 없는 정책을 강제할 수 있다. 9월에 다룬 Copilot 앱 로컬 샌드박스를 켜도 홈 디렉터리는 읽히고 외부 송신은 열려 있다, 보안 검토는 거부 목록에서 시작한다는 꺼진 기본값의 빈틈을 봤다. 이번 변경은 반대편, 강제했을 때 생기는 비용을 드러낸다.
GitHub Docs 관리 설정 레퍼런스는 관리 설정에 sandbox 키를 추가하면 범위 안 모든 사용자에게 로컬 샌드박스를 강제한다고 적었다. 최소 버전에 못 미치는 클라이언트는 업데이트할 때까지 Copilot 연결이 막힌다.
| 클라이언트 | sandbox 키 최소 버전 |
|---|---|
| VS Code | 1.141.0 |
| Copilot CLI | 1.0.93 |
| GitHub Copilot 앱 | 1.1.26 |
VS Code를 1.140대에 묶어 둔 VDI라면, 보안팀이 sandbox 키를 배포한 시점부터 이미지가 갱신될 때까지 그 사용자들의 Copilot이 멈춘다. 변경 기록은 앞으로 다른 거버넌스 키에도 최소 버전을 붙이겠다고 밝혔지만, 어느 키에 언제 붙일지는 적지 않았다. 관리 설정에 키를 하나 더할 때마다 버전표를 다시 맞춰야 한다.
강제 새로고침과 failIfUnavailable은 확인 실패를 사용 중지로 처리한다
기본 동작에서 서버 관리 설정은 1시간 캐시를 쓰고, 짧은 서비스 장애 중에도 캐시된 정책으로 계속 돈다. forceRemoteSettingsRefresh를 true로 두면 Copilot CLI와 Copilot 앱은 이 캐시를 건너뛰고, 새로고침에 실패하면 정책이 미확인 상태로 남아 해당 작업이 제한된다. VS Code는 새로고침이 성공할 때까지 Copilot 기능 전체를 막는다. 문서는 클라이언트를 시작할 때 네트워크 연결이 필요하다고 적었다.
배포 경로도 결과를 바꾼다. 서버 관리 설정으로 내린 값은 클라이언트가 한 번 받은 뒤의 시작부터 적용된다. 첫 시작부터 걸려면 MDM이나 managed-settings.json 파일로 배포해야 하고, 정책 헬퍼 스크립트로는 이 키를 넣지 못한다. Windows 레지스트리와 macOS 관리 환경설정에는 불리언이 아니라 문자열 "true"로 넣는다.
sandbox 안의 failIfUnavailable도 같은 방향이다. enabled와 함께 true로 두면, Copilot이 사용 가능한 샌드박스 백엔드로 정책을 검증·컴파일·적용하지 못할 때 명령을 샌드박스 밖에서 돌리는 대신 모델과 도구 실행을 막는다.
세 설정 모두 '확인하지 못함'을 '쓰지 못함'으로 바꾼다(fail closed).
같은 관리 설정이 수집 범위까지 정한다. GitHub 10월 12일 telemetry 변경 기록에 따르면 telemetry 키의 관리 값은 로컬 설정·SDK 구성·환경 변수를 모두 덮는다. 관리 설정 한 줄을 고치는 사람이 전사 Copilot의 가동 조건과 기록 범위를 함께 고치는 셈이다.
가져갈 것
- sandbox 키를 걸 범위 안에 VS Code 1.141.0·Copilot CLI 1.0.93·Copilot 앱 1.1.26 미만으로 묶인 기기가 몇 대인지 세었는가
- 망분리 PC·VDI 이미지처럼 IDE 업데이트에 별도 승인이 필요한 환경의 다음 반영일이 sandbox 키 배포일보다 앞서는가
- 첫 시작부터 forceRemoteSettingsRefresh를 걸어야 하는 기기에 서버 관리 설정이 아니라 MDM이나 managed-settings.json으로 배포하는가
- Windows 레지스트리·macOS 관리 환경설정에 forceRemoteSettingsRefresh를 DWORD가 아닌 문자열 "true"로 넣었는가
- 출장·현장 노트북처럼 네트워크 없이 VS Code를 켜는 사용자가 Copilot을 못 쓰게 된다는 사실을 해당 팀장이 알고 있는가
- failIfUnavailable을 true로 바꾸기 전에 파일럿 그룹의 OS별 기기에서 샌드박스 정책이 실제로 적용되는지 확인했는가
안 되는 경우
- 엔터프라이즈 관리 설정을 배포하지 않거나 클라이언트 자동 업데이트를 켜 둔 조직에는 버전 하한의 영향이 작다. 변경 기록이 지목한 대상은 구버전에 고정된 사용자다.
- Copilot CLI와 Copilot 앱에서 새로고침이 실패하면 "해당 작업이 제한된다"고만 적혀 있다. 어떤 작업이 막히는지 목록은 공개되지 않았다.
- sandbox 다음에 최소 버전이 붙을 거버넌스 키의 이름과 시점은 변경 기록에 없다.
이번 주에는 보안팀만 보던 managed-settings.json 변경 요청에 IT 운영팀의 클라이언트 업데이트 일정을 붙여, 두 날짜를 한 문서에서 결재한다. Copilot 강제 정책을 어느 범위부터 언제 걸지 순서를 정하는 단계라면 조녁컴퍼니와 그 순서를 같이 따져 볼 수 있다.