요약: Claude Code 6월 25일 릴리스에는 claude_code.assistant_response OpenTelemetry 로그 이벤트가 추가됐습니다. 모델 응답 텍스트를 관측성 파이프라인으로 보낼 수 있다는 뜻입니다. 디버깅에는 유용하지만, 설정에 따라 프롬프트만 로깅하던 조직이 업그레이드 이후 응답 본문까지 받기 시작할 수 있습니다. 이번 글은 업데이트 전후로 어떤 환경변수를 확인해야 하는지, 로그 보존 정책을 어떻게 바꿔야 하는지 정리합니다.
공식 릴리스 노트는 claude_code.assistant_response OpenTelemetry log event가 추가됐고, 모델의 response text를 포함한다고 설명합니다. 기본적으로는 redacted 상태입니다. 다만 OTEL_LOG_ASSISTANT_RESPONSES=1을 설정하면 응답 본문이 기록됩니다. 중요한 부분은 이 다음입니다. 해당 변수가 설정되지 않은 경우 OTEL_LOG_USER_PROMPTS 설정을 따른다고 되어 있습니다. 그래서 이미 사용자 프롬프트 콘텐츠를 로깅하던 배포 환경은 업그레이드 후 응답 콘텐츠도 받기 시작할 수 있으며, 프롬프트만 유지하려면 OTEL_LOG_ASSISTANT_RESPONSES=0을 명시하라는 안내가 붙었습니다.
이건 단순한 관측성 기능이 아닙니다. 로그 데이터의 성격이 바뀌는 변경입니다. 지금까지 “사용자 입력만 수집한다”고 생각했던 파이프라인에 모델이 작성한 코드, 분석, 에러 원인, 내부 경로, 테스트 데이터, 경우에 따라 비밀값 주변 맥락이 들어갈 수 있습니다.
개발 도구에서 모델 응답은 일반 채팅 답변보다 훨씬 많은 운영 정보를 담습니다. 예를 들어 Claude Code가 에러를 분석하면서 파일 경로, 함수명, API endpoint, 테스트 계정, 로컬 실행 명령, 실패한 배포 로그를 요약할 수 있습니다. 모델이 직접 secret 값을 출력하지 않더라도, secret이 들어 있는 파일명이나 credential loading 경로를 설명할 수 있습니다.
응답 로그는 또 다른 위험도 있습니다. 사용자가 프롬프트에 넣지 않은 내용도 도구 호출 결과를 통해 응답에 섞일 수 있습니다. 에이전트가 파일을 읽고 요약했다면 응답 로그에는 소스 코드 일부가 들어갈 수 있습니다. 에이전트가 CI 로그를 분석했다면 실패한 환경변수 이름, 내부 패키지명, 사설 레지스트리 URL이 들어갈 수 있습니다.
관측성은 필요합니다. 하지만 “모델 응답 텍스트”는 단순 이벤트 메타데이터가 아니라 콘텐츠 데이터입니다. 따라서 trace ID, latency, token usage와 같은 운영 지표와 같은 보존 정책으로 다루면 안 됩니다.
가장 먼저 볼 값은 OTEL_LOG_USER_PROMPTS입니다. 이미 이 값을 켜고 있다면 업그레이드 후 assistant response 로그도 따라 켜질 수 있습니다. 조직이 “프롬프트 로깅은 허용하지만 응답 로깅은 아직 검토 전”이라는 상태라면 OTEL_LOG_ASSISTANT_RESPONSES=0을 명시적으로 넣어야 합니다.
두 번째는 OpenTelemetry exporter 설정입니다. 로컬 파일로만 남기는지, 사내 collector로 보내는지, 외부 SaaS APM으로 전송하는지 확인해야 합니다. 응답 본문이 외부 SaaS로 나간다면 데이터 처리 계약, 리전, 보존 기간, 접근 권한까지 재검토 대상입니다.
세 번째는 redaction 계층입니다. Claude Code 자체에서 redacted 상태로 남는다고 해도, 조직의 로그 파이프라인이 attribute를 복사하거나 raw event payload를 별도로 저장한다면 예상과 다른 데이터가 남을 수 있습니다. collector, processor, sink 각각에서 샘플 이벤트를 확인해야 합니다.
응답 로그를 켜는 것이 유용한 경우도 분명합니다. 예를 들어 에이전트 품질 평가, 회귀 분석, 프롬프트 템플릿 개선, 장기 작업 실패 원인 분석을 해야 한다면 모델 응답 본문이 큰 도움이 됩니다. 특히 “에이전트가 왜 이 결정을 했는지”, “어떤 지시를 오해했는지”, “어느 단계에서 잘못된 가정을 했는지”는 latency와 token usage만으로 알 수 없습니다.
하지만 기본값은 보수적으로 잡는 편이 좋습니다. 제품 소스 코드, 고객 데이터, 내부 운영 로그를 Claude Code가 자주 읽는 팀이라면 응답 로그는 먼저 끄고 샘플링된 테스트 환경에서만 켜세요. 개인 개발자라면 로컬 디버깅 용도로 잠깐 켜는 것은 괜찮지만, 장기간 켜 둔 채 클라우드 로그로 보내는 것은 피하는 것이 안전합니다.
추천 정책은 세 단계입니다. 개발 개인 장비는 기본 off, 필요 시 로컬 collector로만 임시 on. 팀 공유 개발 환경은 보안 리뷰 후 특정 저장소나 특정 작업 유형에만 on. 프로덕션 접근 권한이 있는 에이전트 환경은 기본 off이며, 켜야 한다면 민감정보 제거 processor와 짧은 보존 기간을 필수로 둡니다.
OpenTelemetry 이벤트가 들어오면 이름만 보고 끝내지 마세요. 이벤트 attribute에 실제 응답 텍스트가 어디에 들어가는지 확인해야 합니다. 일부 시스템은 event body, attributes, logs table, trace span event에 각각 다른 방식으로 저장합니다. 검색 인덱스에 들어가면 삭제가 어렵거나 비용이 커질 수 있습니다.
접근 권한도 중요합니다. APM 대시보드는 보통 개발자 다수가 볼 수 있습니다. 여기에 모델 응답 전체가 들어가면 “코드 리뷰 권한은 없지만 로그 권한은 있는 사람”이 소스 코드 조각을 볼 수 있습니다. 특히 에이전트가 private repo를 다루는 조직은 로그 뷰어 권한을 repo 권한과 맞추기 어렵습니다.
마지막으로 보존 기간을 줄이세요. 응답 전문은 장기 보관할 이유가 거의 없습니다. 품질 분석을 위해 필요하다면 7일 또는 14일 같은 짧은 TTL로 충분한 경우가 많습니다. 장기 분석에는 전문 대신 분류 태그, 실패 유형, tool name, token count, approval outcome만 남기는 방식이 낫습니다.
한 팀이 Claude Code를 PR 수정 자동화에 쓰고 있다고 가정해 보겠습니다. 기존에는 OTEL_LOG_USER_PROMPTS=1로 사용자 지시를 수집해 “어떤 요청에서 실패가 많았는지”를 봤습니다. 이번 업데이트 후 OTEL_LOG_ASSISTANT_RESPONSES를 비워 두면 응답도 함께 들어갈 수 있습니다. 이 팀은 업그레이드 PR에서 먼저 OTEL_LOG_ASSISTANT_RESPONSES=0을 추가합니다. 이후 별도 staging 환경에서만 10% 샘플링으로 응답 로그를 켭니다.
샘플링 환경에서는 세 가지를 봅니다. 응답에 소스 코드가 얼마나 포함되는지, 내부 URL이나 secret 이름이 나오는지, 실패 분석에 실제로 도움이 되는지입니다. 도움이 작고 위험이 크면 계속 off로 둡니다. 도움이 크다면 redaction rule을 만들고, 민감 저장소는 제외하고, 7일 보존으로 제한합니다.
이 정도 절차면 관측성을 포기하지 않으면서도 로그 사고 가능성을 줄일 수 있습니다.
OTEL_LOG_USER_PROMPTS 값을 확인합니다.OTEL_LOG_ASSISTANT_RESPONSES=0을 명시합니다.OTEL_LOG_ASSISTANT_RESPONSES=1을 별도 PR과 보안 리뷰로 처리합니다.이번 변경은 좋은 기능입니다. 다만 좋은 관측성 기능일수록 기본 운영 정책이 필요합니다. 업그레이드 후 “어쩌다 응답 전체가 로그에 쌓였다”가 되지 않도록, 환경변수 하나는 오늘 확인하는 편이 낫습니다.