이 조합은 단순한 관리 편의 기능이 아닙니다. AI 개발 도구가 IDE와 CLI 안에서 코드를 바꾸고, 브라우저를 열고, PR을 만들고, 장기 실행 작업을 수행하는 순간 관측성과 정책은 서버 대시보드만으로 부족해집니다. 개발자 장비의 확장, CLI, agent host, local config가 모두 실행 표면이 됩니다. 저는 이 흐름을 Managed Dev-Tool Telemetry Plane으로 보는 편이 맞다고 봅니다.

이 글은 AI Agent Observability Evidence Contract, Agent Session Ledger, IDE Browser Agent Permission Plane, OpenTelemetry Native Data Plane과 이어집니다. 기존 글들이 세션과 실행 증거를 다뤘다면, 이번 글은 그 증거가 어디서 강제되고 어디로 흘러가야 하는지를 다룹니다.

이 글에서 얻는 것

• AI 개발 도구 관측성이 usage metrics에서 IDE·CLI OTel export로 확장되는 이유를 이해할 수 있습니다.
• server-managed settings와 MDM/file-based managed settings가 왜 같이 필요한지 판단할 수 있습니다.
• telemetry endpoint, model, plugin, marketplace, bypass permission 같은 설정을 조직 정책으로 고정하는 기준을 잡을 수 있습니다.
• 민감정보와 개발자 프라이버시를 해치지 않으면서 에이전트 실행 증거를 수집하는 체크리스트를 얻을 수 있습니다.

핵심 개념/이슈

1) AI 개발 도구는 이제 서버 서비스가 아니라 엔드포인트 실행 표면이다

예전 개발 도구 관리는 비교적 단순했습니다. SaaS 계정 권한, repository permission, CI secret, IDE extension allowlist 정도를 관리하면 됐습니다. 하지만 AI 코딩 에이전트는 더 많은 경로에서 실행됩니다. VS Code extension, CLI agent host, GitHub web, mobile notification, PR review bot, Actions runner가 서로 이어집니다. 같은 사용자가 같은 조직 정책 아래 있어도 실행 위치가 다르면 남는 로그와 적용되는 설정이 달라질 수 있습니다.

문제는 이 drift입니다.

• 웹에서는 정책이 적용되지만 로컬 CLI는 다른 model setting을 쓴다.
• VS Code는 telemetry export가 켜졌지만 agent host process는 빠져 있다.
• 개발자가 OTEL_* 환경변수를 직접 설정해야 해서 collector가 제각각이다.
• server-managed 설정은 로그인 계정에 따라 적용되지만 공유 장비나 로컬 파일이 우회 경로가 된다.
• plugin marketplace allowlist가 IDE와 CLI에서 다르게 동작한다.

GitHub의 7월 8일 발표는 이 문제를 직접 겨냥합니다. OTel export 설정을 enterprise-managed settings의 telemetry block으로 전달하고, VS Code Copilot Chat extension과 Copilot CLI agent host process에 적용한다고 설명합니다. 또 MDM과 file-based configuration으로 device-level managed settings를 배포해, 개발자가 어떻게 로그인하든 VS Code와 CLI에서 정책이 일관되게 적용되도록 하는 방향을 제시합니다.

2) OTel export는 “모든 것을 기록"이 아니라 승인된 collector로 경로를 고정하는 문제다

OpenTelemetry export가 가능해지면 팀은 곧바로 많은 것을 보고 싶어 합니다. 모델 호출, tool execution, token, latency, error, retry, agent step 같은 데이터는 운영에 유용합니다. 하지만 개발 도구 telemetry는 코드, 파일 경로, prompt, tool result, repository context, 사용자 행동이 섞일 수 있습니다. 그래서 첫 질문은 “무엇을 더 볼까"가 아니라 어디로, 어떤 형태로, 얼마나 오래 보낼까여야 합니다.

실무 기준은 아래처럼 잡을 수 있습니다.

이 기준은 OpenTelemetry Native Data Plane에서 다룬 관측 데이터 플레인 기준과 같습니다. 차이는 데이터 생산자가 서버 애플리케이션이 아니라 개발자 도구라는 점입니다.

3) Managed settings는 모델 선택보다 실행 경계 정책이다

관리형 설정을 단순히 “기본 모델을 무엇으로 할까"로 보면 너무 좁습니다. GitHub 발표의 supported settings 예시는 permissions.disableBypassPermissionsMode, model, enabledPlugins, extraKnownMarketplaces, strictKnownMarketplaces, telemetry.* 같은 키를 포함합니다. 이 목록은 모델 품질보다 실행 경계를 먼저 떠올리게 합니다.

운영 관점에서 중요한 설정은 아래 네 그룹입니다.

• 모델: 기본 모델, auto model selection 허용 여부, 고비용 모델 사용 제한
• 권한: bypass permission mode 차단, 외부 쓰기 승인, 브라우저 권한
• 공급망: enabled plugins, known marketplaces, custom registry allowlist
• 관측성: OTel endpoint, sampling, trace/export enablement, session data policy

즉 managed settings는 생산성 설정이 아니라 개발자 도구 control plane입니다. 어떤 모델을 쓰는지보다, 에이전트가 어떤 도구를 호출할 수 있고 어떤 플러그인을 설치할 수 있으며 어떤 collector로 증거를 보낼지가 더 중요해집니다.

4) Endpoint policy와 server policy는 서로 대체재가 아니다

server-managed 설정은 조직 계정과 repository 정책을 묶는 데 강합니다. 반면 MDM/file-based 설정은 장비와 로컬 실행 표면을 잡습니다. 둘은 경쟁 관계가 아니라 보완 관계입니다.

기업 환경에서는 서버 정책과 endpoint 정책을 함께 둬야 합니다. 예를 들어 server-managed 설정으로 조직의 allowed model을 정하고, MDM으로 VS Code와 CLI가 같은 설정을 읽게 하며, OTel collector는 네트워크 egress policy로 한 번 더 제한하는 식입니다. 한 계층만 믿으면 우회가 아니라 “구성 불일치"만으로도 빈틈이 생깁니다.

5) 관측성은 개발자 감시가 아니라 실행 책임 분리여야 한다

개발자 도구 telemetry는 민감합니다. 잘못 설계하면 감시 도구처럼 받아들여지고, 실제로 개인정보나 코드 조각을 과하게 모을 수 있습니다. 그래서 수집 목적을 명확히 해야 합니다.

좋은 목적:

• 고위험 tool call과 권한 사용의 audit trail 확보
• agent failure와 token/cost spike 분석
• plugin/marketplace 정책 drift 감지
• 상태 변경 action의 evidence 보존
• security incident 때 영향 경로 복원

나쁜 목적:

• 개인별 생산성 순위화
• raw prompt와 파일 내용을 무기한 저장
• 모든 키 입력과 브라우저 행동을 수집
• 정책 목적 없이 “나중에 쓸 수도 있으니” 전량 저장

이 경계가 없으면 Managed Dev-Tool Telemetry Plane은 신뢰를 잃습니다. 최소 수집, 목적 제한, retention, 접근 권한, 감사 로그를 같이 설계해야 합니다.

실무 적용

1) AI 개발 도구 설정 inventory를 만든다

먼저 현재 팀의 실행 표면을 적습니다.

dev_tool_surface:
  ide:
    - vscode_copilot
    - jetbrains_plugin
  cli:
    - copilot_cli
    - codex_cli
  web:
    - github_copilot_agent
  automation:
    - github_actions_agent_runner
policy_sources:
  server_managed: true
  mdm: partial
  file_based_config: false
  env_vars_allowed: experimental_only
telemetry:
  approved_collector: "otel-collector.devtools.internal:4318"
  raw_prompt_storage: false

이 inventory에서 가장 먼저 볼 것은 “도구 수"가 아니라 정책 출처의 불일치입니다. IDE는 관리되는데 CLI는 자유롭거나, CLI는 OTel을 내보내는데 extension은 빠져 있으면 운영 증거가 끊깁니다.

2) telemetry policy를 collector 중심으로 고정한다

개발자가 각자 OTEL_EXPORTER_OTLP_ENDPOINT를 설정하는 방식은 실험에는 괜찮지만 운영 표준으로는 약합니다. 팀 기준은 아래처럼 둡니다.

• approved collector는 1~2개로 제한
• collector는 development, staging, production repo context를 분리 수집
• raw prompt/content는 기본 비수집
• tool call name, schema version, status, duration, error code는 수집
• state-changing action은 approval_id, repo, commit_sha, tool_call_id를 포함
• 외부 전송, 파일 삭제, 배포, 권한 변경은 100% evidence 보존 후보

초기 sampling은 과하게 복잡할 필요가 없습니다. 실패와 상태 변경은 전량, 단순 Q&A와 코드 설명은 샘플링으로 시작하면 됩니다.

3) managed settings rollout은 3단계로 나눈다

1단계는 관측 전용입니다. telemetry endpoint와 raw content 비수집, retention, redaction을 고정합니다.

2단계는 공급망입니다. enabled plugins, known marketplaces, strict marketplace policy를 정하고, custom marketplace는 owner review를 거치게 합니다.

3단계는 실행 권한입니다. bypass permission mode 차단, 고위험 tool 승인, production domain deny, model/cost limit을 붙입니다.

각 단계마다 canary 그룹을 둡니다. 예를 들어 개발자 10명 또는 repo 3개에서 1주일 운영하고, false block, missing telemetry, latency, complaint, policy drift를 봅니다. 조직 전체 강제는 drift가 보이지 않는다는 증거가 아니라 canary에서 문제가 낮다는 증거가 있을 때 진행합니다.

4) drift 감지를 운영 지표로 둔다

정책은 설정했다고 끝이 아닙니다. 로컬 파일, extension version, CLI version, MDM 적용 실패, 네트워크 우회, 개인 장비 때문에 drift가 생깁니다.

초기 지표:

• managed settings applied rate: 95% 이상
• telemetry export success rate: 99% 이상
• unknown collector endpoint: 0건 목표
• unapproved plugin enabled: 0건 목표
• bypass permission mode attempted: 주간 추세 확인
• missing session evidence for state-changing action: 0건 목표
• policy version lag: 7일 초과 장비 5% 미만

이 지표는 사람을 혼내기 위한 것이 아니라 blind spot을 찾기 위한 것입니다. 특히 unknown collector와 missing evidence는 보안 이슈로 분류하는 편이 좋습니다.

트레이드오프/주의점

첫째, telemetry를 많이 모을수록 비용과 민감정보 위험이 커집니다. AI 개발 도구는 코드와 업무 맥락을 많이 다루므로 서버 metric보다 더 보수적으로 수집해야 합니다. 원문 저장은 기본값이 아니라 예외여야 합니다.

둘째, MDM과 managed settings를 강하게 걸면 개발자 경험이 나빠질 수 있습니다. 특히 실험 도구를 자주 바꾸는 플랫폼 팀은 별도 sandbox policy가 필요합니다. 다만 sandbox도 approved collector와 secret scanning은 예외로 빼지 않는 편이 안전합니다.

셋째, endpoint 정책만으로는 계정 권한을 대체할 수 없습니다. 장비가 관리돼도 GitHub org 권한, repository ruleset, CODEOWNERS, secret scope가 느슨하면 실행 경계는 여전히 약합니다. 반대로 서버 정책만 강해도 로컬 CLI drift가 남습니다.

넷째, 관측성 데이터를 개인 평가에 쓰기 시작하면 팀은 우회 경로를 찾습니다. 정책의 목적은 생산성 감시가 아니라 고위험 실행 증거와 비용·보안 통제라는 점을 명확히 해야 합니다.

의사결정 우선순위는 민감정보 최소화 > 승인된 collector 고정 > 실행 경계 강제 > drift 감지 > 사용량 최적화입니다. 더 많은 그래프보다 먼저 안전한 수집 경로가 필요합니다.

체크리스트 또는 연습

체크리스트

• IDE, CLI, web agent, CI agent의 실행 표면 inventory가 있다.
• server-managed, MDM, file-based config, env var 중 정책 출처가 정리돼 있다.
• OTel export endpoint가 승인된 collector로 고정돼 있다.
• raw prompt, file content, token, email, path 같은 민감 데이터 redaction 정책이 있다.
• model, plugin, marketplace, bypass permission, telemetry 설정 drift를 볼 수 있다.
• state-changing action에는 tool_call_id, approval_id, repo, commit_sha가 남는다.
• unknown collector와 unapproved plugin은 알람으로 올라온다.
• 개발자 개인 생산성 감시 목적으로 telemetry를 쓰지 않는다는 정책이 명시돼 있다.

연습

1. 현재 팀에서 쓰는 AI 개발 도구 3개를 골라 server policy와 endpoint policy가 각각 어디서 적용되는지 표로 정리해 보세요.
2. Copilot CLI나 유사 CLI 에이전트가 파일 수정과 PR 생성을 수행한다고 가정하고, 반드시 남겨야 할 OTel attribute 10개를 적어 보세요.
3. approved collector가 아닌 endpoint로 telemetry가 나가는 상황을 가정하고, 탐지·차단·예외 승인 절차를 5단계로 나눠 보세요.
4. raw prompt를 저장하지 않으면서도 사고 재현에 필요한 evidence를 남기려면 어떤 hash, schema version, tool result summary가 필요한지 설계해 보세요.

참고한 흐름

• GitHub Changelog: Enterprise-managed OpenTelemetry export for VS Code and CLI - https://github.blog/changelog/2026-07-08-enterprise-managed-opentelemetry-export-for-vs-code-and-cli/
• GitHub Changelog: Deploy managed Copilot settings via MDM in VS Code and CLI - https://github.blog/changelog/2026-07-08-deploy-managed-copilot-settings-via-mdm-in-vs-code-and-cli/
• Visual Studio Code Docs: Monitor agent usage with OpenTelemetry - https://code.visualstudio.com/docs/agents/guides/monitoring-agents