Claude Code 워크스페이스 인스턴스 또는 소비자 계정 간 잠재적 세션/캐시 누수

버그 설명

Enterprise Zero Data Retention(ZDR) 워크스페이스에 인증된 상태였는데도 세션이 누수된 것처럼 보입니다. 에이전트가 갑자기 제게 Minecraft 사원에 어떤 벽돌을 쓰고 싶은지 묻기 시작했고, 요약에서도 자신 있게 Minecraft 사원을 만들고 있다고 말했습니다. 캐시는 워크스페이스별로 격리되는 줄 알았는데요? 어쩌면 제 동료 중 한 명이 Minecraft 사원을 만들고 있는 걸지도 모르겠습니다. 토큰 한도를 쓰는 방법도 참 다양하네요. 아니면 소비자 플랜에서 누수된 것일 수도 있는데, 그렇다면 Enterprise ZDR과 저희의 민감한 채팅 세션 일부가 어디로 가고 있는지에 대해 매우 심각한 의문이 생깁니다.

환경 정보

• Platform: darwin

• Terminal: Apple_Terminal

• Version: 2.1.199

• Feedback ID: f336f5d2-3992-4a04-9e1f-ec30f006f75e

오류

관련이 있을지도 모르겠습니다. 제가 조금 특이한 방식으로 쓰고 있기는 합니다. 필요한 컨텍스트가 들어 있는 a.claude 디렉터리가 있어서, 작업과 무관한 작업 디렉터리에서 이 세션을 시작했습니다. 하지만 실제 작업은 다른 디렉터리에서 모두 진행하고 있습니다. 에이전트가 언급한 “earlier pollution”은, 어느 순간 대화가 compact된 뒤 제가 에이전트를 실행한 디렉터리에서 프로젝트 작업을 시작했기 때문입니다. 제가 그 디렉터리는 건드리지 말라고 한 지시를 잊어버린 거죠. 그건 덜 놀라웠고, 제 설정 때문에 생긴 일임이 분명했습니다. 하지만 제 세션에 Minecraft 관련 프롬프트가 섞여 들어온 것과는 완전히 다른 문제입니다.

^{source https://github.com/anthropics/claude-code/issues/74066}

HN에서는 이 사례를 곧바로 기업용 계정 간 데이터 유출로 단정하기보다, 환각과 로컬 컨텍스트 오염, 캐시·라우팅 계층의 결함을 밖에서 구분하기 어렵다는 점에 주목했다. Claude Code 팀 관계자는 환각 가능성이 높다고 답했고, 여러 사용자는 실제 컨텍스트 안에 minecraft.py라는 경로 문자열이 있었으며 세션이 길고 작업 디렉터리 설정도 특이했다는 점을 근거로 들었다. 긴 컨텍스트에서 모델이 특정 단어에 끌려 엉뚱한 목표를 만들어내는 일은 실사용자에게 낯선 실패 모드가 아니라는 설명도 이어졌다.

그렇다고 의심이 완전히 사라진 것은 아니다. 과거 대형 업체의 중간 인프라에서 응답이 서로 뒤바뀐 사례를 겪었다는 경험담이 나왔고, 이런 경우 저장 데이터가 남지 않아도 요청 처리 중 다른 사용자에게 응답이 전달될 수 있다는 지적이 있었다. HTTP 게이트웨이, 요청 다중화, 캐시 키 계산, 버퍼 재사용 같은 계층에서 작은 결함이 생기면 겉으로는 남의 세션이 섞인 것처럼 보일 수 있다. 특히 ZDR을 전제로 쓰는 기업 환경에서는 데이터를 저장했는지뿐 아니라 응답이 어느 경로로 나갔는지도 중요한 신뢰 조건이 된다.

캐시 논의는 더 실무적이었다. 공유 프리픽스 캐시는 비용과 성능 면에서 강한 유인이 있지만, 그만큼 격리 책임이 소프트웨어에 집중된다. 반대로 캐시는 입력 토큰을 기준으로 동작하므로 보고자가 추정한 형태의 누수와는 맞지 않는다는 반론도 있었다. 첫 응답이 5분 이상 지난 뒤, 즉 캐시 미스 상황에서 나왔다는 조건은 오히려 단순한 캐시 누수 가능성을 낮춘다는 해석으로 이어졌다.

결국 이 사례는 LLM 에이전트 장애를 판단할 때 확인해야 할 기준을 보여준다. 사용자는 현재 컨텍스트, 도구 출력, 작업 디렉터리, 압축된 대화 내용을 먼저 따져봐야 한다. 동시에 공급자는 환각이라는 설명만으로 끝내기 어렵다. 기업 고객이 안심하려면 캐시와 라우팅, 중간 인프라에서 어떤 격리 보장을 제공하는지 검증 가능한 방식으로 설명해야 한다.