GitHub Copilot 텔레메트리 설정: 사용자 식별과 프롬프트 로그 수집 범위

사용자 식별 정보와 가명 식별자의 차이

identity는 기존 가명 사용자 식별자와 별개입니다. 기본 꺼짐이며 콘텐츠 수집과 독립적으로 제어합니다. 근거: GitHub 공식 발표 identity를 끄는 것을 모든 식별 정보·운영 메타데이터가 사라진다는 뜻으로 해석하지 마세요.

같은 사람이 여러 기기에서 작업하거나 여러 계정으로 전환할 수 있습니다. 활동을 개인에게 귀속할 때에는 계정·OS 사용자·호스트를 구분하고, 기기 이름만으로 동일 사용자를 확정하지 않는 편이 좋습니다.

프롬프트·응답·도구·정책 로그 수집 범위

각 클래스는 기본 꺼짐이며, captureContent는 다섯 콘텐츠 클래스를 묶는 기존 설정입니다. captureContent로 identity가 켜지지는 않습니다. 근거: 수집 클래스·기본값 “프롬프트 수집”을 채팅 문장만 저장하는 기능으로 좁혀 이해하면 실제 문맥 수집 범위를 놓칠 수 있습니다.

클라이언트 지원: VS Code Agent Host와 로컬 에이전트

세부 클래스 제어는 Copilot CLI·Copilot app·VS Code Agent Host 세션에서 지원됩니다. VS Code 로컬 에이전트는 identity와 기존 captureContent를 지원하지만 다섯 클래스를 독립적으로 적용하지 않습니다. 근거: Capture controls

따라서 같은 JSON을 모든 IDE에 배포하고 같은 결과를 기대하면 안 됩니다. 사용할 클라이언트·버전·실행 harness를 기록하고 지원되는 키를 먼저 확인하세요. JetBrains를 포함한 다른 환경에 이번 세부 설정을 자동으로 확대 적용하지 않습니다.

사용자 식별만 켜는 관리 설정 예시

다음은 공식 예시를 참고한 telemetry 설정 조각입니다. endpoint는 설명용 주소이므로 조직이 준비한 OTLP 수집기 URL로 바꾸세요. 기존 managed-settings.json 전체를 덮어쓰지 말고 관리 방식과 우선순위에 맞춰 적용해야 합니다.

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "http/protobuf",
    "capture": {
      "identity": true,
      "prompts": false,
      "responses": false,
      "toolArguments": false,
      "toolOutput": false,
      "policyDetail": false
    },
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "copilot"
  }
}

사용자 식별 중심 설정 JSON 다운로드. 이 예제는 콘텐츠를 명시적으로 false로 두며 exporter를 켭니다. JSON 구문이 맞다는 것과 수집기가 정상 수신하거나 정책이 적용됐다는 것은 다른 검증 단계입니다.

관리 문서는 enabled·endpoint·protocol로 export를 설정하고 명시된 capture가 같은 클래스의 captureContent보다 우선한다고 설명합니다. lockCaptureContent는 로컬의 기존 콘텐츠 활성화를 제한하며 identity에는 적용되지 않습니다. 관리 소스가 여러 개면 가장 높은 우선순위의 telemetry 객체 전체가 사용되고 하위 객체와 합쳐지지 않습니다. 근거: telemetry 참조

팀 설정에서 endpoint만 바꾸려는 경우에도 상위 객체의 capture 값이 그대로 합쳐진다고 가정하면 안 됩니다. 최종 설정 객체에 필요한 값을 함께 확인하세요. exporter 인증이 필요한 수집기는 조직의 인증·전송 설정을 추가로 준비해야 합니다.

설정 적용 후 실제 수집 범위를 검증하는 방법

1. 환경 기록: 클라이언트·버전·harness, 관리 설정 배포 방식과 적용 시점을 적습니다.
2. 무해한 테스트 입력: 실제 비밀값 대신 TEST_PROMPT_ONLY 같은 구분 문자열을 사용합니다.
3. 최종 정책 확인: 로컬 설정이 아니라 적용된 관리 설정과 exporter 상태를 확인합니다.
4. 수집기 관측: 요청과 연결된 OTel 데이터에서 세 identity 속성과 콘텐츠 문자열의 포함 여부를 조사합니다.
5. 도구·오류 별도 시험: 안전한 조회 작업과 모의 오류로 인자·결과·오류 필드의 범위를 확인합니다.
6. 조건별 재검증: 계정 전환·세션 재시작·다른 harness에서도 결과를 기록합니다.

한 건의 로그에서 문자열이 보이지 않는다고 모든 세션에서 수집되지 않는다고 단정하지 마세요. 실제 exporter 신호와 표본 범위를 확인하고, 저장·검색 파이프라인의 변환 때문에 필드가 누락됐는지도 나눠 조사해야 합니다. OTel 관측 방식은 VS Code 에이전트 모니터링 문서를 함께 참고하세요.

목적별 설정 판단과 운영 점검

수집 목적을 정하면 필요하지 않은 클래스를 켜는 일을 줄일 수 있습니다. 운영 문서에는 수집기 담당자, 접근 권한, 보관 기간, 테스트 표본, 재검토 시점을 기록하세요. 설정을 끄는 것과 이미 저장된 로그를 삭제하는 것은 별개 작업입니다.

자주 묻는 질문

identity를 켜면 프롬프트도 수집되나요?

독립된 설정입니다. 그러나 다른 관리·로컬 설정의 콘텐츠 값과 실제 지원 harness를 함께 확인해야 최종 범위를 알 수 있습니다.

로컬 환경변수로 기업 설정을 끌 수 있나요?

명시된 managed 값이 로컬·SDK·환경변수보다 우선합니다. 정책 변경이 필요하면 적용 주체와 최종 관리 설정을 확인하세요.

모든 capture가 false면 텔레메트리가 없나요?

수집 클래스와 export 활성화는 별개입니다. 콘텐츠·신원 수집을 제한해도 사용량·정책 상태 등의 메타데이터까지 모두 없어졌다고 해석하지 마세요.

이 설정으로 모델에 보내는 입력도 차단되나요?

이 글은 OTel 수집·export를 다룹니다. 모델 요청이나 다른 로그 체계의 데이터 처리는 별도로 확인해야 합니다.

관련 Copilot·GitHub 운영 설정

• Copilot 샌드박스와 네트워크 접근 제한
• GitHub 커밋의 인증 pusher 확인