Claude Compliance API local sessions: 로컬 Claude Code 감사 로그가 필요한 이유

Anthropic이 Claude Compliance API에 로컬 세션 조회 기능을 추가했습니다. 이제 Enterprise 조직은 사용자의 머신에서 실행된 Cowork와 Claude Code 세션 목록, 세션 메타데이터, 메시지 transcript를 API로 가져올 수 있습니다. 동시에 API 응답에 anthropic-workspace-id 헤더도 추가됐습니다.

검색 의도: Claude Compliance API, Claude Code audit log, enterprise AI governance를 검색하는 보안 담당자와 플랫폼 개발자. 이 글은 기능 소개보다 운영자가 무엇을 바꿔야 하는지에 초점을 맞춥니다. 발표 문서의 표현을 그대로 반복하지 않고, 개발팀이 이번 주에 점검할 항목으로 분해했습니다.

지금 개발팀이 봐야 하는 변화

이 업데이트는 단순한 관리자 편의 기능이 아닙니다. AI 코딩 도구가 로컬 파일을 읽고, 테스트를 실행하고, 패치를 만들고, 내부 시스템에 접근하는 순간 감사 범위가 IDE 바깥으로 넓어집니다. 기존 SaaS 감사 로그는 웹 콘솔 사용 이력을 중심으로 설계됐습니다. 하지만 Claude Code 같은 로컬 에이전트는 사용자의 터미널과 워크스페이스에서 움직입니다. 어떤 프롬프트가 들어갔고, 어떤 파일 컨텍스트를 사용했고, 어떤 답변이 나왔는지 추적할 수 없으면 보안팀은 사고 조사에서 빈칸을 만나게 됩니다.

릴리스 노트에서 확인한 핵심 근거는 Anthropic Claude Platform 2026년 8월 11일 릴리스 노트입니다. Enterprise 조직에서 Cowork와 Claude Code가 사용자 머신에서 실행한 세션의 목록, 메타데이터, 메시지 transcript를 Compliance API beta로 조회할 수 있고, anthropic-workspace-id 응답 헤더가 추가됐다고 설명합니다입니다. 특히 실무 관점에서는 "쓸 수 있다"보다 "관측하고, 제한하고, 실패했을 때 복구할 수 있다"가 중요합니다. AI 기능은 데모에서는 잘 보이지만 운영에서는 비용, 지연 시간, 권한, 감사 로그, 장애 전파가 같이 움직입니다. 이번 업데이트도 결국 그 다섯 가지 중 어디를 줄여주는지로 판단해야 합니다.

기존 운영 방식에서 막히던 지점

AI 에이전트나 LLM 기능을 제품에 붙이면 초반에는 프롬프트 품질에만 관심이 쏠립니다. 하지만 트래픽이 붙는 순간 병목은 다른 곳에서 나옵니다. 첫째, 어떤 요청이 정책상 허용됐고 어떤 요청이 거절됐는지 추적하기 어렵습니다. 둘째, 모델 호출 비용이 기능 단위로 분리되지 않습니다. 셋째, 운영자가 장애를 발견했을 때 원인이 프롬프트인지 정책 엔진인지 외부 도구인지 구분하기 어렵습니다.

많은 팀이 이 문제를 로그 한 줄과 대시보드 스크린샷으로 때웁니다. 그 방식은 PoC에서는 충분하지만, 고객 데이터가 들어오는 순간 부족합니다. 예를 들어 상담 에이전트가 내부 문서를 검색하고, 결제 정책을 확인하고, 사용자에게 답변하는 흐름을 생각해보면 한 요청 안에 최소 3개의 판단 지점이 생깁니다. 어느 지점에서 차단됐는지, 차단이 정상인지, 차단 때문에 사용자 경험이 깨졌는지까지 봐야 합니다.

설계할 때 분리해야 할 4가지 계층

1계층은 조직·워크스페이스 식별입니다. anthropic-workspace-id를 저장하면 어떤 API key가 어느 workspace로 해석됐는지 나중에 맞출 수 있습니다. 2계층은 세션 식별입니다. 로컬 세션 ID, 사용자, 시작/종료 시각, 클라이언트 종류를 남깁니다. 3계층은 메시지 transcript입니다. 모든 내용을 장기 보관할 필요는 없지만 사고 조사와 컴플라이언스 요구에 맞춰 보존 기간을 정해야 합니다. 4계층은 코드 변경 결과입니다. transcript만으로는 부족하므로 Git commit, PR, CI 로그와 연결해야 합니다.

계층을 나누면 좋은 점은 책임 소재가 명확해진다는 것입니다. 모델 품질 문제를 정책 문제로 오해하지 않고, 비용 폭증을 사용자 증가로만 해석하지 않습니다. 지연 시간이 늘었을 때도 모델 응답이 느린지, 정책 평가가 느린지, 외부 도구 호출이 느린지 따로 볼 수 있습니다.

적용 순서: 크게 바꾸지 말고 한 경로부터 고정하기

먼저 감사 목적을 명확히 정합니다. 직원 감시가 아니라 사고 재현, 데이터 유출 조사, 규제 대응, 비용 분쟁 해결이 목적이어야 합니다. 그 다음 보존 범위를 줄입니다. 모든 프롬프트를 무기한 저장하면 법무 리스크가 커집니다. 최소한 세션 메타데이터는 구조화해서 보관하고, transcript는 민감도 높은 프로젝트나 사고 발생 시점 중심으로 접근하도록 설계하는 편이 현실적입니다. 마지막으로 개발자에게 수집 사실과 보존 기준을 문서로 공개해야 합니다.

처음부터 전 요청에 적용하면 팀이 원인 분석을 못 합니다. 가장 위험도가 높은 기능 하나를 정하고, 그 경로의 입력·정책·모델·도구·응답을 끝까지 이어서 봐야 합니다. 추천 순서는 관리자 기능, 고객 데이터 조회, 결제/권한 변경, 외부 발송 기능입니다. 단순 요약이나 내부 검색보다 실패 비용이 큰 곳부터 붙이는 편이 낫습니다.

흔한 실수와 피하는 법

첫 번째 실수는 정책을 프롬프트로만 해결하려는 것입니다. "민감 정보는 말하지 마" 같은 지시문은 필요하지만 충분하지 않습니다. 정책은 코드, 설정, 로그, 알림으로 남아야 합니다. 두 번째 실수는 성공 응답만 샘플링하는 것입니다. 운영에서는 거절, 타임아웃, 재시도, 사용자가 중간에 나간 케이스가 더 중요합니다. 세 번째 실수는 비용을 월말 청구서에서만 확인하는 것입니다. AI 비용은 기능 릴리스 직후 24시간 안에 봐야 합니다.

네 번째 실수는 권한을 넓게 열어두는 것입니다. 에이전트가 파일을 읽거나 명령을 실행하거나 외부 API를 호출할 수 있다면 기본값은 차단이어야 합니다. 필요한 도구만 허용하고, 허용 사유를 남기고, 위험 도구는 별도 승인 경로를 둬야 합니다. 마지막 실수는 검증 없이 모델만 교체하는 것입니다. 같은 프롬프트라도 모델이 바뀌면 거절률, 응답 길이, 도구 호출 횟수, 비용이 모두 달라질 수 있습니다.

팀 안에서 합의해야 할 운영 기준

운영 기준은 추상적인 원칙보다 숫자로 정하는 편이 낫습니다. 예를 들어 정책 평가 p95 지연 시간은 300ms 이하, 차단율은 정상 트래픽 기준 1~3% 범위, 실패한 모델 호출의 자동 재시도는 1회까지만 허용하는 식입니다. 숫자는 서비스마다 다르지만, 숫자가 없으면 회고가 감으로 흐릅니다.

또한 배포 전 체크와 배포 후 체크를 나눠야 합니다. 배포 전에는 테스트셋, 권한 설정, 롤백 경로를 봅니다. 배포 후에는 실제 사용자 로그, 비용, 오류율, 차단율을 봅니다. 이 둘을 섞으면 "테스트는 통과했는데 왜 장애가 났는지"를 설명하기 어려워집니다.

오늘 바로 할 수 있는 체크리스트

• anthropic-workspace-id를 API gateway 로그나 애플리케이션 로그에 함께 저장한다.
• 로컬 Claude Code 세션 ID와 Git branch, commit, PR 번호를 연결한다.
• transcript 보존 기간을 프로젝트 민감도별로 다르게 둔다.
• Compliance Access Key 권한을 read:compliance_user_data처럼 필요한 scope로 제한한다.
• 감사 로그 조회 자체도 별도 로그로 남긴다.
• 사고 대응 runbook에 "AI 로컬 세션 조회" 단계를 추가한다.

정리하면, 이번 변화의 핵심은 AI 기능을 더 많이 쓰는 것이 아니라 더 안전하게 운영하는 것입니다. 기능을 켜기 전에 관측 기준을 먼저 만들고, 위험한 요청부터 좁게 적용하고, 비용과 거절률을 함께 봐야 합니다. 이 순서만 지켜도 AI 기능이 데모에서 운영으로 넘어갈 때 생기는 사고를 꽤 줄일 수 있습니다.