GitHub이 10월 12일 Copilot의 OpenTelemetry 설정을 손봤습니다. 한 줄 요약은 이렇습니다.

전부 켜기 / 전부 끄기 → 항목별로 따로 켜기

예전에는 콘텐츠를 수집하면 통째로 들어왔는데, 이제는 사용자 식별과 다섯 가지 콘텐츠 등급을 독립적으로 고를 수 있습니다. 기업에서 Copilot을 운영한다면 꼭 알아야 할 변경입니다.

6개 수집 등급을 표 하나로 이해하기

공식 문서 기준으로 정리하면 이렇습니다.

Identity (사용자 식별)
  → Copilot 계정명 + OS 계정 + 머신명
  → 대화 내용 없이 “누가”만 본다

Prompts (프롬프트)
  → 사용자·시스템·개발자 프롬프트와 모델 입력

Responses (응답)
  → 어시스턴트 응답 + 지원하는 추론 내용

Tool arguments (도구 인자)
  → 명령어·인자 원문, 도구 스키마, MCP 서버·플러그인·훅 식별자

Tool output (도구 결과)
  → 도구 실행 결과와 에러 상세

Policy detail (정책 상세)
  → 샌드박스 경로 같은 unbounded 정책 정보
  → 꺼도 bounded 정책 상태·결과는 계속 볼 수 있음

가장 중요한 사실은 기본값입니다. 전부 기본 비활성화입니다. 켜지 않으면 프롬프트·응답·도구 인자 같은 민감 정보는 나가지 않습니다. 모델명·토큰 수·소요 시간 같은 메타데이터만 보는 상태가 시작점입니다.

지원 범위도 갈립니다.

Copilot CLI · Copilot app · VS Code Agent Host
  → 6개 등급 독립 제어 가능

VS Code 로컬 하네스
  → 사용자 식별 + 기존 통짜 콘텐츠 설정만 가능
  → 5개 콘텐츠 등급 세분화는 아직 미적용

왜 이게 중요한가: 관측과 노출의 트레이드오프

에이전트가 한 일을 모르면 운영이 안 됩니다. 누가, 어떤 세션에서, 어떤 모델로, 토큰을 얼마나 쓰고, 도구를 얼마나 실패했는지 알아야 병목을 잡습니다.

trace  → 에이전트 세션의 흐름 (모델 호출 + 도구 사용 연결)
metric → 시간에 따른 패턴 (토큰 사용량, 도구 성공률)
event  → accept/reject 같은 개별 행동 기록

반대로 내용을 다 모으면 위험합니다. 프롬프트·응답·도구 결과에는 소스코드와 파일 내용, 명령어, 워크스페이스 경로가 그대로 들어 있습니다. 전부 수집은 디버깅에는 편하지만 보안팀 입장에서는 악몽입니다.

이번 세분화는 그 중간을 고르게 해줍니다. 예를 들어 이렇게요.

1단계: Identity만 켜기
  → 누가 Copilot을 얼마나 쓰는지 파악, 내용은 안 모음

2단계: + Tool output의 에러만 보기
  → 실패 패턴 분석, 소스코드 노출은 최소

3단계: 특정 팀·기간에만 Prompts/Responses 켜기
  → 품질 이슈 조사용으로 한시 수집 후 즉시 끄기

실무 설정 예시: managed-settings로 강제하기

엔터프라이즈에서는 로컬 설정을 믿지 말고 관리 설정으로 강제하는 편이 안전합니다. 개념 예시는 이렇습니다.

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.internal",
    "captureIdentity": true,
    "capturePrompts": false,
    "captureResponses": false,
    "captureToolArguments": false,
    "captureToolResults": true,
    "capturePolicyDetail": false
  }
}

위 설정의 의도를 말로 풀면 다음과 같습니다.

- 전송은 켜되 목적지는 우리 수집기로만
- 누구인지는 식별, 대화 내용은 수집 안 함
- 도구 실패 원인 파악용으로 결과만 수집
- 샌드박스 경로 같은 정책 상세는 수집 안 함

VS Code 로컬에서 시험할 때 쓰는 키 이름도 알아두면 편합니다.

github.copilot.chat.otel.enabled          → OTel 켜기 (기본 false)
github.copilot.chat.otel.captureContent   → 콘텐츠 통짜 수집 (기본 false)
github.copilot.chat.otel.captureIdentity  → 신원 수집 (기본 false)
COPILOT_OTEL_ENABLED / OTEL_EXPORTER_OTLP_ENDPOINT → 환경변수 방식

수집한 데이터는 OTLP를 받는 백엔드로 보냅니다. 직접 받는 곳도 있고, OpenTelemetry Collector를 앞에 두는 구성도 있습니다. GenAI 시맨틱 컨벤션(gen_ai.*)을 따르기 때문에 Jaeger·Grafana·Datadog 같은 OTel 호환 도구와 바로 붙습니다.

CodeBridge Mini Lab: 우리 팀 수집 정책 30분 점검

오늘 30분만 내서 다음을 확인해 보세요.

[ ] 수집 목적지가 우리 통제 안에 있는가 (OTLP endpoint·인증)
[ ] 필요한 등급만 켜져 있는가 (일단 Identity부터)
[ ] 수집 데이터의 저장 위치·보존 기간·접근 권한이 문서화됐는가
[ ] 민감 repo를 다루는 팀은 콘텐츠 수집을 끄거나 한시로만 켜는가
[ ] accept율·도구 성공률 대시보드가 메타데이터만으로 그려지는가

여기서 자주 놓치는 게 저장 위치입니다. 수집 설정만 보고 끝내는데, 실제로는 백엔드 보존 기간과 접근 권한이 더 중요합니다. 누가 raw 프롬프트를 볼 수 있는지가 정해지지 않았다면, 그 등급은 아직 켜면 안 됩니다.

결론: 관측은 넓게, 내용은 좁게

이번 변경이 주는 원칙은 한 문장입니다.

메타데이터는 넓게 보고, 콘텐츠는 필요할 때만 좁게 본다.

AI 코딩 도구 운영의 관측 가능성은 로그를 많이 모으는 게 아니라 무엇을 모으지 않을지 정하는 능력에 달려 있습니다. 기본 비활성화를 출발점으로, 필요한 항목만 켜는 습관이 소스코드와 민감정보를 지킵니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

Agent와 Plan 모드를 실제 프로젝트에 붙여보면서, 관측이 필요한 지점이 어디인지 감을 잡아보세요. 수집 정책을 정하는 눈이 생깁니다.