저는 지난 몇 주 동안 Claude Code 텔레메트리를 계속 살펴봤는데, 같은 점이 반복해서 보였습니다. 대부분의 팀은 이를 환경에 도입하고 “놀랍다”라고 말하지만, 시스템 수준에서 실제로 무엇을 하는지는 전혀 모릅니다.
개인 개발 도구로는 괜찮습니다. 50명의 엔지니어에게 배포했다면 괜찮지 않습니다.
Claude Code가 실제로 내보내는 것
Claude Code는 기본 OpenTelemetry 지원을 제공합니다. 환경 변수를 두 개만 설정하면, 다음을 내보냅니다.
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_ENDPOINT=https://collectors.sumologic.com/receiver/v1/otlp/<unique-id>
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=x-sumo-token your-token"
엔드포인트 URL은 Sumo Logic에서 Manage Data > Collection > Hosted Collectors 아래에 OTLP/HTTP 소스를 생성해 얻을 수 있습니다. 소스를 생성하면 고유한 수집 URL이 제공됩니다. 해당 URL을 환경 변수에 지정하면 설정이 완료됩니다. 수집기가 필요하지 않습니다. SDK가 필요 없습니다. 래퍼가 필요 없습니다. 흐르기 시작하는 데이터: 메트릭은 60초마다, 이벤트는 5초마다 전송됩니다.
메트릭은 지루한 부분이지만(그래도 필요합니다)
사용자, 모델, 유형(입력/출력/캐시)별 토큰 사용량. 세션당 비용(USD). 시작된 세션 수. 추가되거나 제거된 코드 라인 수. 생성된 커밋 수. 생성된 PR 수. 사용자가 적극적으로 상호 작용한 시간과 Claude가 처리하는 데 소요된 시간.
이것이 바로 ROI 대시보드입니다. 3개월 후 엔지니어링 VP가 이렇게 물을 때 여기에 대한 답이 됩니다. “우리가 이걸 위해 비용을 쓰고 있습니다. 실제로 사용하는 사람이 있나요?”
user.account_uuid 및 organization.id로 세분화합니다. Sumo Logic 대시보드를 구축하세요. 그리고 다음으로 넘어가세요.
이벤트가 흥미로운 부분입니다
여기에 주목할 가치가 있습니다.
Claude가 도구를 실행할 때마다 claude_code.tool_result 이벤트가 생성됩니다. 해당 이벤트에는 도구 이름, 실행 시간, 성공/실패 여부가 포함되며, Bash의 경우 실행된 전체 bash_command가 포함됩니다.
접근된 모든 파일 경로. 모든 git 명령. 호출된 모든 스크립트. 모두 기록되고, 구조화되며, 검색 가능합니다.
사용자가 프롬프트를 제출할 때마다 claude_code.user_prompt 이벤트가 생성됩니다. 기본적으로는 프롬프트 길이가 기록되며, OTEL_LOG_USER_PROMPTS=1로 설정하면 전체 내용이 기록됩니다. 모든 API 호출은 모델, 비용, 지연 시간 및 토큰 수를 포함하는 개별 claude_code.api_request 이벤트로 기록됩니다.
이 모든 것을 하나로 묶는 필드는 prompt.id입니다. 모든 이벤트에는 이를 트리거한 원래 프롬프트로 연결되는 UUID가 있습니다. Sumo Logic Log Search에서 필터 하나만 설정하면 사용자가 무엇을 요청했는지, 어떤 API를 호출했는지, 어떤 도구를 어떤 순서로 실행했는지 등 전체 실행 체인을 재구성할 수 있습니다.
단순한 로그가 아니라, 감사 추적입니다.
아무도 보고 있지 않은 필드
decision_source.
모든 도구 실행에는 권한 결정이 어떻게 이루어졌는지가 기록됩니다. config, hook, user_permanent, user_temporary, user_abort, user_reject.
user_permanent는 사용자가 “항상 허용”을 클릭했다는 의미입니다. 한 번. 해당 도구에 대해. 영원히.
Sumo Logic에서 해당 필드를 가져와 분포를 확인하세요. 대부분의 도구 결정이 user_permanent라면, 엔지니어는 Claude가 어떤 도구를 사용하든 원하는 작업을 수행할 수 있도록 사실상 사전 승인한 것입니다. 그들은 몇 달 전에 한 번 그렇게 해 두고는 잊어버린 것입니다. 그렇다고 보안 위기는 아닙니다. 하지만 알아둘 필요가 있는 사실이고, 지금은 아마도 모르고 계실 수 있습니다.
Sumo Logic에서 실제로 구축해야 할 것들
Sumo Logic에서 구성해 둘 만한 대시보드 세 가지는 다음과 같습니다.
- 사용량 및 비용: 시간 경과에 따른 사용자별·모델별 토큰 사용량. 세션당 비용. 활성 시간 대비 유휴 시간. 이것은 결국 재무팀에서 요청하게 될 항목입니다.
- 도구 실행: 어떤 도구가 얼마나 자주 실행되는지, 성공률과 평균 실행 시간. Bash 도구로 필터링하고 명령 패턴을 살펴보세요. 엔지니어들이 실제로 도구를 어떻게 사용하는지, 그리고 여러분이 예상했던 방식과 어떻게 다른지 알 수 있습니다.
- 세션 재구성:
prompt.id로 필터링된 저장된 검색으로,event.name,event.timestamp,tool_name,bash_command,cost_usd필드를 포함합니다. 잘못된 파일이 삭제되거나, 예기치 않은 API 호출이 발생하거나, 원인을 알 수 없는 커밋이 생기는 등 문제가 발생했을 때, 무슨 일이 있었는지 파악하는 방법이 바로 이것입니다.
전사 확산 전에 반드시 챙겨야 할 한 가지
tool_parameters 필드에는 시크릿이 포함될 수 있습니다. 엔지니어가 토큰, 비밀번호 또는 API 키를 인라인으로 포함한 bash 명령을 실행하면 해당 값이 로그에 남습니다.
해당 사항이 귀하의 환경에서 우려된다면, 수집 이전에 tool_parameters를 마스킹하거나 삭제하도록 Sumo Logic 필드 추출 규칙을 구성하세요. 50명에게 배포한 뒤까지 기다리지 마세요.
마무리 생각
Claude Code는 유용합니다. 그 점은 이미 입증되었습니다. 하지만 유용한 것과 관측 가능하다는 것은 별개의 문제입니다. 그리고 엔지니어링 조직에서 관측 불가능한 도구는 최악의 순간에 예상치 못한 문제를 일으키기 쉽습니다.
연동하세요. 알고 있어서 후회할 일은 거의 없을 것입니다.
