JetBrains를 정책 밖에 두지 마세요 — Copilot 엔터프라이즈 managed settings

2026년 8월 18일, GitHub은 JetBrains용 Copilot에도 엔터프라이즈 managed settings가 적용된다고 발표했습니다. 플러그인·마켓플레이스, MCP 서버 허용/거부, OpenTelemetry, Bypass Approvals·Autopilot 제한이 한 제어면으로 들어옵니다.

핵심 한 줄: VS Code·CLI만 잠가 두고 IntelliJ 플릿을 “개발자 취향”으로 남겨 두면, MCP·에이전트 정책은 이미 구멍입니다. 이제 JetBrains도 그 구멍에 덮개를 씌울 수 있습니다.

왜 중요한가

지난 몇 주, Copilot 쪽은 에이전트 표면이 늘어나는 속도가 정책 표면을 앞질렀습니다. Agent Plugins 1.0으로 플러그인이 이식 가능해졌고, Slack·Teams에서는 @GitHub이 대화 안에서 쓰기 권한까지 건드립니다. 그 와중에 많은 조직은 VS Code 기준으로 managed-settings.json을 다듬어 두고, JetBrains는 “아직 문서에 JetBrains가 없어서” 뒤로 미뤘습니다.

문제는 단순합니다. 같은 GitHub 계정, 같은 Copilot 시트를 쓰면서 IDE만 바꾸면 정책이 달라지는 상태는, 보안 팀 입장에서 “예외”가 아니라 기본 공격면입니다. 개발자가 IntelliJ에서 MCP를 붙이거나 Autopilot으로 승인 우회를 켜는 순간, VS Code에서 막아 둔 가드레일은 의미가 반감됩니다.

이번 변경은 그 비대칭을 줄입니다. 플러그인 소스(extraKnownMarketplaces / strictKnownMarketplaces), MCP(allowedMcpServers / deniedMcpServers), 텔레메트리 라우팅, 권한 모드(permissions.disableBypassPermissionsMode)를 JetBrains에서도 중앙에서 걸 수 있습니다.

이전 방식과 비교하면

Cursor 쪽과 나란히 보면 교훈이 같습니다. MCP allowlist·Run Mode·인증(예: AIUC-1)은 잔여 위험을 줄일 뿐, “쓰는 모든 클라이언트”를 목록에 넣지 않으면 구멍은 남습니다. Claude Code의 폴더 trust·credentials 제거(런타임 경계)와도 결이 다릅니다 — 이쪽은 관리자가 배포하는 설정 경계입니다. 둘 다 필요합니다.

처음에는 “changelog에 JetBrains가 붙었으니 끝난 거 아닌가?” 싶었습니다. 막상 플릿을 세어 보니 IntelliJ·WebStorm 사용자가 전체 Copilot 시트의 꽤 큰 비율이었고, VS Code용 managed-settings.json만 밀어 넣던 파일에는 JetBrains 검증 항목이 없었습니다. 그때부터 체크리스트에 IDE 열을 추가했습니다.

설정 예시

엔터프라이즈 기본 파일(보통 .github-private의 copilot/managed-settings.json)에 넣을 최소 골격 예입니다. 실제 matcher·URL은 조직 표준에 맞게 바꿔야 합니다.

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "allowedMcpServers": [
    { "serverUrl": "https://api.githubcopilot.com/*" },
    { "serverCommand": ["npx", "@playwright/mcp@latest"] }
  ],
  "deniedMcpServers": [
    {
      "serverCommand": [
        "npx",
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/"
      ]
    }
  ],
  "enabledPlugins": {},
  "extraKnownMarketplaces": {},
  "strictKnownMarketplaces": true
}

포인트:

• 허용목록이 있으면 매칭되지 않은 MCP는 차단됩니다.
• 거부 항목은 무조건입니다. 허용목록에 있어도 deny가 이기도록 문서화되어 있습니다.
• JSON이 깨지면 클라이언트가 빈 allowedMcpServers로 취급해, 기본 내장 서버를 제외하고 전부 막히는 fail-closed에 가깝습니다. “살짝 고치다 전체 마비”를 각오해야 합니다.
• enabledPlugins / extraKnownMarketplaces는 팀 파일에서 가산(additive) 될 수 있고, MCP·Bypass 키는 { "overridable": ... }로 팀별 예외를 열 수 있습니다.

배포 채널은 대략 MDM > 서버 관리 > 파일 기반 > 사용자 설정 우선순위입니다. 서버 관리형은 감사·리뷰에 강하고 cloud agent까지 포함하는 편이고, MDM/파일은 로그인 전·계정 전환에도 디바이스 정책을 유지할 때 유리합니다.

실무에서 쓰는 순서

1. 플릿 인벤토리: Copilot 시트 중 JetBrains 플러그인 활성 비율을 먼저 셉니다. 0이 아니면 “나중”이 아닙니다.
2. MCP 허용목록을 한 장으로: VS Code에 이미 있는 allow/deny를 JetBrains에 그대로 복제할 수 있는지부터 확인합니다. matcher 문법이 같다면 복사가 기본값입니다.
3. Bypass/Autopilot부터 잠금: permissions.disableBypassPermissionsMode: disable는 “어떤 도구를 승인할지”의 세부가 아니라, 전부 통과 모드를 끄는 스위치입니다. 세부는 별도 권한 규칙이 필요합니다.
4. OTel 목적지 고정: managed OpenTelemetry가 개발자 설정을 덮어씁니다. 개발자는 Settings > Tools > GitHub Copilot > Chat > OpenTelemetry에서 적용값을 확인할 수 있어야 합니다.
5. 파일 배포 파일럿: 컨테이너·Codespaces처럼 서버 round-trip이 애매한 환경은 파일 기반(/etc/github-copilot/managed-settings.json 등, root 소유·world-writable 금지)으로 먼저 검증합니다.
6. 깨진 JSON 리허설: 스테이징에서 일부러 invalid JSON을 넣어 “전부 차단” 동작을 한 번 보고, 롤백 경로를 적어둡니다.

시니어 엔지니어 관점

에이전트 거버넌스에서 반복되는 실패 모드는 “가장 시끄러운 IDE만 잠그는 것”입니다. VS Code 정책 문서가 길고, JetBrains 절은 짧아서 뒤로 밀립니다. 그런데 인시던트는 짧은 절에서 납니다.

또 하나: disableBypassPermissionsMode를 켠 것을 “에이전트 보안 완료”로 적으면 안 됩니다. 그건 YOLO 스위치를 끈 것이고, MCP 서버가 무엇을 읽고 쓰는지·플러그인이 어디서 오는지·텔레메트리에 프롬프트 본문이 실리는지는 각각 다른 키입니다. 체크리스트를 네 칸으로 나누세요 — 플러그인 / MCP / OTel / 권한 모드.

팀 오버라이드는 양날입니다. 플랫폼 팀이 overridable을 너무 넓게 열면 JetBrains “예외 팀”이 다시 정책 밖이 됩니다. 기본은 잠그고, 예외는 티켓·만료일과 함께.

Cursor에서 같이 보기

Cursor만 쓰는 팀이라도 이 발표는 참고 가치가 있습니다.

• Cursor 워크스페이스의 MCP allowlist·Run Mode를 문서화·버전 관리하고 있는지, GitHub managed-settings.json과 같은 엄밀함인지 비교해 보세요.
• 한 조직이 Cursor + Copilot(JetBrains) 이중 스택이면, MCP 허용 목록의 교집합을 먼저 정하고 각자 문법으로 배포하는 편이 안전합니다. “Cursor에서만 막힘”은 공격면 이전일 뿐입니다.
• Cursor 에이전트에게 정책 초안을 맡길 때는 “JetBrains 플러그인 최신 + managed settings 적용 여부 확인”을 Acceptance에 넣으세요. changelog 요약만으로는 플릿이 안 바뀝니다.

FAQ

Q. VS Code용 managed settings를 그대로 쓰면 되나요?
A. MCP·Bypass 등 공유 키는 같은 논리 스키마를 쓰는 쪽입니다. 다만 JetBrains changelog에 명시된 범위(플러그인·MCP·OTel·권한 모드)부터 검증하고, 플러그인 버전을 최신으로 맞춘 뒤 IDE에서 적용값을 확인하세요.

Q. allowedMcpServers만 두면 되나요?
A. 허용목록은 “목록 밖 차단”입니다. 위험한 조합(예: 루트 파일시스템 MCP)은 deniedMcpServers로 명시하는 편이 안전합니다. deny는 허용과 겹쳐도 이깁니다.

Q. Bypass를 끄면 Autopilot만 막히나요?
A. 문서상 Bypass Approvals 또는 Autopilot 사용을 막습니다. 개별 도구 승인 정책 전체를 대체하지는 않습니다.

Q. 서버 관리형과 MDM 중 무엇을 고르나요?
A. 감사·리뷰·cloud agent까지 한 줄기로 가져가려면 서버 관리형이 기본입니다. 디바이스 그룹·로그인 전 강제가 필요하면 MDM, 컨테이너 등은 파일 기반을 병행하세요.

소스

• Enterprise managed settings in GitHub Copilot for JetBrains — GitHub Changelog (2026-08-18)
• Configure enterprise managed settings — GitHub Docs
• Configure enterprise MCP allowlist — GitHub Docs
• Enterprise managed settings reference — GitHub Docs
• Deploy managed Copilot settings via MDM (VS Code/CLI) — GitHub Changelog

마무리

에이전트 시대의 IDE 정책은 “주력 에디터 하나”가 아니라 시트가 돌아가는 모든 클라이언트입니다. 8월 18일 변경으로 JetBrains가 그 목록에 공식으로 들어왔습니다. 다음에 할 일은 블로그를 읽는 게 아니라, IntelliJ 한 대에서 managed settings가 실제로 붙는지 확인하는 것입니다.

앞으로 이식형 플러그인과 채팅 속 에이전트가 늘수록, “정책 밖 IDE”는 더 비싸집니다. JetBrains를 예외로 남기지 마세요.