본문 바로가기

AI UPDATES

GitHub Copilot enterprise-managed plugins VS Code public preview: 사내 AI 플러그인과 MCP 설정 표준화하는 법

 

GitHub Copilot enterprise-managed plugins: VS Code에서 사내 AI 플러그인과 MCP 설정을 표준화하는 법

Copilot Business/Enterprise 조직이 VS Code 1.122 이후 먼저 확인할 설정 파일, MCP 정책, 도입 리스크

 

VS Code public preview에서 먼저 봐야 할 점

 

2026년 6월 5일 GitHub는 VS Code에서 enterprise-managed plugins를 public preview로 지원한다고 발표했습니다. Copilot Business/Enterprise 조직은 사내 플러그인, custom agents, skills, hooks, MCP configurations를 누가 표준으로 배포할지 먼저 정해야 합니다.

GitHub Copilot enterprise-managed plugins VS Code public preview는 VS Code 안의 AI 코딩 도구 배포 기준을 조직 단위로 맞추는 업데이트입니다. 팀원이 각자 붙이던 플러그인이나 MCP 서버 구성이 엔터프라이즈 저장소의 설정 파일로 들어옵니다.

제가 담당자라면 Copilot Business/Enterprise seat가 엔터프라이즈 계정에서 나온 것인지부터 확인하겠습니다. 그다음 `.github-private/.github/copilot/settings.json` 리뷰 책임자와 MCP allowlist, hooks를 어느 수준의 보안 통제로 볼지 정하겠습니다.

운영에서 달라지는 부분은 배포 기록입니다. 플러그인과 MCP 구성을 개인 노트북의 선택 목록에 남겨 두는 대신 조직 저장소의 변경 이력과 승인 절차에 태우게 됩니다.

 
사무실 책상 위 노트북 화면에 코드 편집기, 플러그인 카탈로그, MCP 서버 연결도, 승인 체크리스트가 함께 열린 장면. GitHub 또는 VS Code 로고는 넣지 않음.
 

타임라인: CLI에서 VS Code로 확장된 관리형 플러그인

 

관련 공지는 2026년 4월 MCP allowlist, 5월 Copilot CLI enterprise-managed plugins, 2026년 5월 28일 VS Code 1.122, 2026년 6월 5일 VS Code public preview 순서로 이어졌습니다.

2026년 4월 16일, GitHub는 Copilot CLI에서 custom registry 기반 MCP allowlist public preview를 공지했습니다. 2026년 5월 6일에는 Copilot CLI용 enterprise-managed plugins가 public preview로 먼저 나왔습니다.

VS Code 1.122는 2026년 5월 28일 공개됐습니다. GitHub는 2026년 6월 5일 Changelog에서 이 버전이 엔터프라이즈 관리 기능을 지원한다고 설명했습니다.

사내 안내문을 만든다면 두 날짜를 따로 적는 편이 낫습니다. VS Code 1.122 릴리스일은 2026년 5월 28일이고, enterprise-managed plugins의 VS Code public preview 공지일은 2026년 6월 5일입니다. 둘을 한 문장에 뭉개면 적용 버전과 기능 공지 시점을 헷갈리기 쉽습니다.

 

무엇을 중앙 관리하나: marketplace, enabledPlugins, hooks, MCP configurations

 

관리자는 `.github-private/.github/copilot/settings.json`에서 사내 플러그인 마켓플레이스와 자동 설치 플러그인을 지정합니다. hooks와 MCP configurations도 조직 표준 배포 대상에 들어갑니다.

관리자가 먼저 열어볼 파일은 `.github-private/.github/copilot/settings.json`입니다. GitHub Docs는 이 설정 안에서 `extraKnownMarketplaces`와 `enabledPlugins`를 top-level property로 문서화합니다.

`extraKnownMarketplaces`에는 GitHub 저장소 기반 마켓플레이스를 `OWNER/REPO` 형식으로 등록합니다. `enabledPlugins`는 `PLUGIN-NAME@MARKETPLACE-NAME` 형태의 키를 `true`로 둬 자동 설치 대상을 정합니다.

플러그인 저장소에서는 `plugin.json`이 기준점입니다. 공식 참조에 따르면 `plugin.json`은 최소 `name` 필드를 요구하고, 필요하면 `agents`, `skills`, `commands`, `hooks`, `mcpServers`, `lspServers` 같은 정의나 경로를 담습니다. 마켓플레이스는 `marketplace.json` 파일로 만들며, 문서 예시는 `.github/plugin/marketplace.json` 경로를 제시합니다.

두 설정은 맡는 일이 다릅니다. `settings.json`은 플러그인을 발견하고 설치 대상으로 올립니다. MCP registry와 allowlist는 어떤 MCP 서버를 발견하고 허용할지 다룹니다. 보안 판단은 플러그인 권한, MCP 서버 접근 범위, hooks 실행 조건까지 이어져야 합니다.

 
엔터프라이즈 `.github-private` 저장소의 settings.json에서 plugin marketplace, enabled plugins, hooks, MCP configurations가 VS Code와 Copilot CLI 클라이언트로 내려가는 흐름도.
 

도입 시뮬레이션: 전사 적용 전에 가장 작은 테스트부터

 

전사 자동 설치 전에 작은 파일럿으로 검증하는 편이 낫습니다. 테스트 사용자, enterprise owner 권한, `.github-private` 저장소, VS Code 1.122 이상 또는 Copilot CLI 검증 환경을 준비한 뒤 `settings.json`과 플러그인 구조를 확인합니다.

전사 적용부터 켜면 실패 원인을 찾기 어렵습니다. 클라이언트 버전, Copilot seat 출처, 저장소 경로, JSON 구조, 플러그인 마켓플레이스 접근권을 한 번에 의심하게 됩니다.

Copilot Business 또는 Copilot Enterprise seat를 엔터프라이즈 계정에서 받은 테스트 사용자를 정합니다. 관리자는 엔터프라이즈의 `.github-private` 저장소 접근권을 확인하고, 테스트 사용자는 VS Code 1.122 이상 또는 Copilot CLI 검증 환경에서 인증 상태를 봅니다.

첫 파일럿에서는 자동 설치 대상을 하나로 줄이는 게 좋습니다.

  • `.github-private/.github/copilot/settings.json`을 만들고 `extraKnownMarketplaces`에 테스트용 `OWNER/REPO` 마켓플레이스를 등록합니다.
  • `enabledPlugins`에는 검증용 `PLUGIN-NAME@MARKETPLACE-NAME` 하나만 `true`로 둡니다.
  • 플러그인 저장소에서 `plugin.json`의 `name`, 필요 시 `hooks`와 MCP 설정 파일 경로를 확인합니다.
  • Copilot CLI에서는 `copilot plugin marketplace list`, `copilot plugin marketplace browse NAME`, `copilot plugin list` 같은 명령으로 구조 인식을 봅니다.
  • VS Code에서는 버전 1.122 이상, Copilot 인증, 해당 엔터프라이즈 billing context가 맞는지 확인한 뒤 자동 설치 반영 여부를 봅니다.

자동 설치가 보이지 않을 때는 기능 결함으로 단정하지 말고 운영 조건부터 좁힙니다. `.github-private` 경로 오타, default branch 반영 누락, `marketplace.json`의 플러그인 경로 오류, 사용자의 Copilot seat source 불일치를 먼저 봅니다.

 

어떤 팀에 맞나: 온보딩, 보안 리뷰, 내부 문서 MCP

 

반복되는 개발 워크플로우를 같은 기준으로 배포해야 하는 팀에 맞습니다. 신입 온보딩용 agents와 skills, 보안 리뷰 자동화, 테스트 생성, 코드 스타일 점검, 내부 문서 검색 MCP 서버부터 검토할 만합니다.

개인 개발자 한 명이 쓰는 환경에서는 이 설정이 과합니다. Copilot Business/Enterprise를 이미 쓰는 팀은 새로 합류한 개발자에게 같은 agent, 같은 skill, 같은 MCP 서버 구성을 맞추는 일이 반복됩니다.

첫 적용 후보는 반복 배포되는 개발 워크플로우입니다.

적용 후보 맞는 이유 먼저 확인할 것
신입 온보딩용 custom agents와 skills 팀 규칙, 리뷰 기준, 내부 명령을 같은 방식으로 배포하기 쉽습니다. agent/skill 정의 위치와 변경 승인자
보안 리뷰와 테스트 생성 플러그인 반복 체크를 Copilot 환경 안에 넣습니다. hooks 실행 범위와 실패 시 영향
내부 문서 검색 MCP 서버 팀별 개인 MCP 설정을 줄이고 승인된 서버 catalog로 묶기 좋습니다. 토큰 저장 위치, read/write 권한, 로그 범위
VS Code와 Copilot CLI 병행 조직 편집기와 CLI의 정책 경험을 비슷하게 맞춥니다. VS Code 버전, Copilot CLI 검증 명령, billing context

GitHub MCP registry와 allowlist policies도 같은 검토 묶음에 들어갑니다. 관리형 플러그인은 MCP configurations를 배포하는 통로이고, MCP registry와 allowlist는 어떤 MCP 서버를 발견하고 허용할지 정하는 쪽입니다. 사내 승인 MCP catalog를 직접 운영하려는 팀은 `modelcontextprotocol/registry`나 Azure API Center MCP registry를 놓고 운영 부담을 비교하면 됩니다.

 
 
 

한국 개발팀에는 어떤 의미인가

 

한국 개발팀이 볼 지점은 온보딩, 권한, 감사, 표준 워크플로우가 Git 기반 운영 체계 안으로 들어온다는 점입니다.

많은 팀에서 AI 코딩 도구는 아직 개인 생산성 도구처럼 관리됩니다. 누가 어떤 MCP 서버를 붙였는지, 어떤 hook이 실행되는지, 어떤 agent가 내부 문서에 접근하는지 팀 단위 인벤토리가 비어 있는 경우가 있습니다.

GitHub Copilot enterprise-managed plugins VS Code public preview는 그 관리 지점을 Git 저장소 운영 방식으로 옮깁니다. 설정 파일이 저장소에 있으면 PR, CODEOWNERS, branch protection, 승인 이력 같은 기존 개발 거버넌스를 붙이기 쉽습니다.

다만 이 기능이 감사 체계를 대신 만들어 주지는 않습니다. 한국 사용자 입장에서는 "AI 도구를 쓸 수 있느냐"보다 "누가 어떤 도구를 기본값으로 배포했고, 변경 근거가 남느냐"가 더 실무적인 질문입니다. 금융, 헬스케어, B2B SaaS처럼 데이터 경계와 권한 설명이 필요한 조직에서는 개발 편의 기능만으로 보기 어렵습니다.

 

주의할 점: public preview와 MCP enforcement 제한

 

관리형 플러그인을 켜도 보안 검토 항목은 그대로 남습니다. MCP allowlist enforcement에는 현재 제한이 있고, hooks와 mcpServers는 코드 실행, 외부 연결, 토큰 처리 범위를 따로 봐야 합니다.

아직 public preview입니다. 설정 스키마나 지원 범위가 바뀔 수 있으니 운영 문서에는 장기 사양처럼 적지 않는 편이 좋습니다.

MCP allowlist를 강한 보안 경계로 두면 위험합니다. GitHub Docs는 현재 allowlist enforcement가 server name/ID matching 중심이며, 설정 파일 수정으로 우회될 수 있고 non-registry 서버 설치를 엄격히 막는 enforcement는 아직 제공되지 않는다고 설명합니다.

hooks와 `mcpServers`를 포함하는 플러그인은 리뷰 범위가 넓어집니다. hook script 위치, 실행 조건, 실패 시 영향, 로그에 남는 데이터, 외부 API 호출, PAT나 OAuth token 저장 위치, 사내 문서 검색 권한이 위험 지점입니다.

전사 적용 전에는 플러그인 저장소 접근권, `plugin.json`과 `marketplace.json` 구조, hooks 실행 범위, MCP 서버 read/write 권한, 비밀값 처리 규칙, rollback PR 절차를 문서화해야 합니다. 이 항목이 비어 있으면 자동 설치를 보류하는 쪽이 맞습니다.

 
 
 

도입을 미뤄도 되는 경우

 

Copilot Business/Enterprise를 쓰지 않거나, VS Code/Copilot CLI가 주 개발 환경에서 빠져 있거나, 사내 플러그인과 MCP 서버 보안 리뷰가 끝나지 않았다면 전사 자동 설치를 서두를 이유가 없습니다.

이 VS Code public preview는 Copilot Business/Enterprise와 엔터프라이즈 계정 운영을 전제로 합니다. 개인 Copilot 사용자나 다른 IDE 중심 팀에는 우선순위가 낮습니다.

개발팀별 워크플로우가 크게 다르면 단일 `enabledPlugins` 정책이 오히려 혼란을 만들 수 있습니다. 그런 조직은 전체 배포보다 조직별 정책, 파일럿 그룹, read-only MCP 서버부터 잡는 편이 현실적입니다.

API keys, PAT, OAuth token, 사내 문서 검색 권한처럼 민감한 값을 다루는 규칙이 없다면 MCP configurations 자동 배포는 늦추는 편이 맞습니다. 배포 절차는 줄어들 수 있지만, 어떤 플러그인을 믿을지는 팀이 직접 판단해야 합니다.

 

자주 묻는 질문

 

Q. GitHub Copilot enterprise-managed plugins는 VS Code에서 무엇을 중앙 관리하나?
엔터프라이즈 관리자가 사내 플러그인 마켓플레이스, 자동 설치 플러그인, hooks, MCP configurations를 조직 표준으로 배포합니다. GitHub는 2026년 6월 5일 VS Code 1.122 지원을 public preview로 공지했습니다.

Q. Copilot Business와 Copilot Enterprise 사용자만 이 기능을 쓸 수 있나?
공식 공지는 엔터프라이즈 계정에서 Copilot Business 또는 Copilot Enterprise 라이선스를 받은 사용자에게 설정이 적용된다고 설명합니다. 개인 Copilot 사용자나 엔터프라이즈 seat가 없는 사용자까지 포함한다고 쓰면 범위가 넓어집니다.

Q. `.github-private/.github/copilot/settings.json`에는 무엇을 넣어야 하나?
공식 문서 기준으로 `extraKnownMarketplaces`에는 GitHub 저장소 기반 마켓플레이스를 등록하고, `enabledPlugins`에는 `PLUGIN-NAME@MARKETPLACE-NAME` 형태의 자동 설치 플러그인을 지정합니다. 첫 검증에서는 테스트용 마켓플레이스와 플러그인 하나만 두고 반영 여부를 보는 편이 좋습니다.

Q. VS Code와 Copilot CLI에서 같은 정책이 적용되나?
GitHub Changelog는 VS Code와 Copilot CLI가 엔터프라이즈 설정을 자동으로 가져와 적용한다고 설명합니다. CLI 명령은 마켓플레이스와 플러그인 구조 검증에 맞고, VS Code에서는 버전 1.122 이상, Copilot 인증, enterprise billing context를 함께 봐야 합니다.

Q. MCP allowlist와 enterprise-managed plugins는 대체 관계인가?
관리형 플러그인은 플러그인과 MCP configurations를 배포하는 경로입니다. MCP registry와 allowlist는 어떤 MCP 서버를 발견하고 허용할지 정하는 정책 레이어에 가깝습니다.

Q. 전사 자동 설치를 피해야 하는 경우는 언제인가?
hooks 실행 범위, `mcpServers` 권한, 토큰 저장 위치, 로그 수집 범위, rollback PR 절차가 정리되지 않았다면 파일럿으로 제한해야 합니다. GitHub Docs가 MCP allowlist enforcement 제한을 명시하므로, 민감 데이터 접근은 별도 보안 검토를 거쳐야 합니다.

함께 읽으면 좋은 글

 

참조 링크