Copilot 최신 관리 정책의 배포 시점을 점검해보세요

기본 캐시 대신 무엇을 요구하나요?

10월 13일 공지에 따르면 Copilot CLI, VS Code, GitHub Copilot 앱에서 지원해요. 이 설정이 활성화되면 캐시된 응답으로 최신 정책 확인을 대신할 수 없어요. 현재 정책을 확인하지 못하면 오래됐거나 확인되지 않은 정책으로 실행하지 않고 차단하는 fail closed 방식이에요.

설정을 쓰지 않으면 기존 관리 설정 캐시를 사용해 시작 속도를 높이고 일시적인 서비스 장애에 대응해요. 따라서 새 설정을 켜는 결정에는 정책 최신성과 시작 가용성 사이의 선택이 따라요. 최신 정책 확인을 필수로 만드는 만큼 서버에 연결되지 않는 상황도 운영 계획에 넣어야 해요.

서버 배포와 MDM·파일 배포는 언제부터 효력이 있나요?

배포 문서는 서버 관리 값을 클라이언트가 한 번 받은 뒤 subsequent startup, 즉 그다음 시작부터 갱신을 요구한다고 설명해요. 아직 값을 받은 적 없는 클라이언트에 서버 설정만으로 첫 시작 전 강제를 보장할 수는 없어요.

MDM과 파일 배포는 장치에서 설정을 읽으므로 첫 로그인 전에도 요구를 적용할 수 있어요. 로컬 클라이언트에 적용되고 계정을 바꿔도 유지돼요. 서버 배포는 로그인 계정과 연결되고 해당 엔터프라이즈에서 Copilot 라이선스를 받은 사용자에게 적용돼요. 첫 로그인 전 통제가 필요한 장치인지부터 가려보세요.

배포 경로를 고를 때 무엇을 구분하나요?

서버 방식은 .github-private 저장소의 copilot/managed-settings.json으로 관리해요. MDM은 운영체제 관리 값으로 키를 전달하고, 파일 방식은 장치의 지정 위치에 managed-settings.json을 배포해요. 파일을 받지 않은 장치까지 정책이 적용되는 건 아니에요.

배포 문서의 기본 우선순위는 MDM→서버→파일→사용자 설정 순이에요. sandbox와 permissions의 허용·확인·거부 키는 제한이 강한 방향으로 합쳐지는 예외예요.

팀의 준비 방법으로는 배포 대상 장치와 로그인 계정을 따로 목록으로 만드는 걸 제안해요. 장치 관리 대상에서 빠진 개발 환경을 찾고, 여러 경로에 같은 키가 있으면 위 순서와 예외를 대조하세요. 전달 성공과 클라이언트가 실제로 값을 읽었는지는 각각 확인해야 해요.

sandbox 최소 버전 강제에는 어떻게 대비하나요?

이번 공지는 sandbox 키에 최소 지원 클라이언트 버전 강제도 추가했어요. 관리 설정에 이 키가 있으면 오래된 버전에 고정한 사용자는 Copilot을 다시 쓰기 전에 업데이트해야 해요. 공지에 특정 버전 번호는 없으므로 임의의 숫자를 배포 기준으로 적으면 안 돼요.

적용 전 시험 순서로 다음을 제안해요.

1. 지원 클라이언트에서 서버 값을 받은 뒤 재시작해 정책 확인을 살펴보세요.
2. 첫 로그인 전 요구가 필요하면 MDM이나 파일 전달을 별도로 시험해요.
3. 시험 장치에서 정책 서버 확인이 실패할 때 차단과 복구 경로를 확인하세요.
4. 버전 고정 장치의 업데이트 담당자와 갱신 경로를 정해 두세요.

연결 장애 때도 꼭 유지해야 할 제한은 배포 문서의 장치 기반 설정 안내를 함께 검토하세요. 강제 갱신을 켠 장치가 차단됐을 때 누가 연결과 정책 전달을 확인할지 운영 절차에 넣어 두면 좋아요. 공식 자료 확인일은 2026-10-17이에요.