2026년 7월 4일, 한 개발자가 GitHub에 버그 리포트를 올렸다. 그가 사용 중이던 것은 Anthropic의 Claude Code — 전문 프로그래머를 위한 AI 코딩 어시스턴트로, 엔터프라이즈급 보안 작업 공간에서 실행되고 있었다. 개발 업무를 도와달라고 AI에게 맡기려던 순간, AI가 갑자기 엉뚱한 질문을 던졌다. 「마인크래프트 사원을 지을 때 어떤 색 벽돌을 쓸까요?」
▲ Claude Code 세션에서 현재 작업과 전혀 무관한 마인크래프트 콘텐츠가 등장했다. 출처: GitHub Issue #74066
그는 AI와 마인크래프트에 관해 대화한 적이 없었다. 로컬에 저장된 모든 대화 로그를 검색했지만 「사원」이나 「벽돌」이라는 단어는 어디에도 없었다. 더 흥미로운 점은 Claude의 모바일 앱에서도 동일한 기현상이 발생했다는 것이다 — 데이터 테이블을 처리 중이던 그에게 AI가 느닷없이 인테리어와 삼면화 얘기를 꺼냈다.
이것만으로도 충분히 불안한 사건이었다. 하지만 이 이슈가 Hacker News 첫 페이지에 올라 260포인트를 기록하게 된 결정적 이유는, 논의 과정에서 쏟아져 나온 유사한 사례들이 한 회사에 국한되지 않았다는 점이다.
Claude만의 문제가 아니다
널리 인용된 한 댓글은 익명의 사용자가 남긴 것이다. 그는 여러 기업의 AI 서비스를 깊이 있게 사용해 왔으며, 최소 두 차례 「대화 교차」를 직접 목격했다고 주장했다. 한 번은 Claude 모델, 다른 한 번은 GPT 모델이었고, 두 곳 모두 시가총액 조 단위의 테크 대기업이었다.
그중 한 회사는 상세한 사후 조사 보고서를 제공했다. 문제의 원인은 API 게이트웨이(쉽게 말해 AI 서비스의 「교환원」 역할을 하는 시스템)가 HTTP 프로토콜의 「100 상태 코드」라는 메커니즘을 잘못 처리한 데 있었다. 간단히 말해, 게이트웨이가 요청에 번호를 매기는 과정에서 「하나를 잘못 센」 것 — 당신의 질문이 이전 사용자의 응답을 받았고, 당신의 응답은 다음 사용자에게 전달됐다.
다른 회사는 원인 설명을 거부한 채 「우리를 믿어 주세요. 다시는 이런 일이 없을 겁니다」라는 말만 남겼다.
또 다른 사용자들은 서드파티 플랫폼을 통해 AI 모델을 사용할 때 다른 사람이 AI에게 보낸 링크와 파일을 자주 보게 된다고 보고했다. 한 사용자는 Claude가 자신의 친구만 알고 있는 장소 정보를 자발적으로 언급했는데, 그 친구도 같은 사무실에서 Claude를 사용 중이었다고 한다.
도대체 어떻게 이런 일이?
한 문장으로 요약하면: AI를 더 빠르고 저렴하게 만들기 위해 여러 회사가 기반 레이어에 「공유 통로」를 깔아 놓았는데, 이 통로가 가끔 문패를 잘못 단다.
구체적으로는 세 가지 계층으로 이해할 수 있다.
첫 번째 계층: HTTP 요청 스머글링 — 네트워크 세계의 「번호표 붙이기 실수」
인터넷에서 당신이 웹사이트에 요청을 보낼 때, 브라우저와 서버는 HTTP 프로토콜로 소통한다. 이 프로토콜은 겉보기엔 단순하지만 실제로는 매우 복잡하다. 특히 하나의 서버가 수천수만 명의 요청을 동시에 처리할 때는 더 그렇다. 효율을 높이기 위해 서버는 여러 사용자의 요청을 하나의 연결에 「카풀」해서 함께 처리한다.
문제는 이 「카풀」 과정에서 앞 사람의 데이터 패킷과 뒷사람의 데이터 패킷이 서로 붙어 버리는 경우다. 예를 들어 프로토콜 헤더의 길이 표시에 오류가 생기면, 서버는 A의 응답을 B에게 보내게 된다. 네트워크 보안 분야에는 이것을 「HTTP 요청 스머글링(HTTP Request Smuggling)」이라고 부르는 공식 명칭이 있다.
보안 연구원 James Kettle은 DEF CON 해킹 컨퍼런스에서 수년간 이 공격의 변종들을 시연해 왔으며, 최근 발표 제목은 「HTTP/1.1은 반드시 죽어야 한다」였다. 더 엄격한 HTTP/2 프로토콜로 완전히 전환해야만 구조적으로 이 취약점을 근절할 수 있기 때문이다. 하지만 아이러니하게도, 그가 처음 이 공격을 시연한 지 6년이 지난 2026년 현재, 조 단위 시가총액의 기업들이 여전히 이 지점에서 넘어지고 있다.
두 번째 계층: KV 캐시 공유 — 「공유 메모지」의 위험
AI 대형 모델이 대화를 처리할 때, 「KV 캐시」라는 것을 동적으로 유지한다. AI의 「임시 작업 메모지」라고 생각하면 된다. 추론할 때마다 AI는 이미 계산한 내용을 여기에 적어 두고, 다음에 비슷한 시작 부분을 만나면 바로 재사용하여 막대한 연산 자원을 절약한다.
서비스 제공자 입장에서 이 최적화는 대단히 매력적이다. 여러 사용자가 동일한 「시스템 프롬프트」(예: Claude Code가 시작될 때 내장된 범용 지시문)를 사용하고 있다는 것을 식별할 수 있다면, 이 사용자들이 같은 캐시를 공유하게 할 수 있다. 이는 연산 비용을 크게 절감할 수 있다는 뜻이다.
하지만 여기에 문제가 있다. 캐시는 「키」를 기준으로 검색된다. 이 키를 생성하는 함수에 버그가 있거나, 캐시 정리가 제때 이루어지지 않거나, 어떤 이유로 다른 사용자의 데이터가 같은 슬롯에 저장된다면 — A 사용자의 대화 조각이 B 사용자의 캐시로 들어갈 수 있다. HN 사용자들은 「각 사용자 고유의 콘텐츠를 시스템 프롬프트에서 분리하여 첫 번째 사용자 메시지로 옮기는 것」이 흔한 회피 수단이라고 언급했지만, 이는 엔지니어링 프랙티스일 뿐 아키텍처 수준의 보장은 아니다.
세 번째 계층: 속도와 보안의 구조적 딜레마
위 두 문제는 동일한 근본적 갈등을 가리킨다. AI 기업이 응답 속도를 추구하는 것(캐시 추가, 연결 공유)과 사용자 프라이버시(엄격한 격리) 사이의 긴장 관계다.
이것은 도덕적 판단이 아니라 물리 법칙 수준의 트레이드오프다. 캐시를 전혀 공유하지 않는 AI 서비스는 대단히 비싸다 — 모든 메시지를 처음부터 계산해야 하므로 비용이 몇 배로 뛸 수 있다. 반면 모든 단계에서 극단적인 최적화를 한 AI 서비스는 반드시 사용자 간에 일부 인프라를 공유해야만 하고, 이는 「교차 연결」의 가능성을 열어 둔다.
HN의 한 높은 추천을 받은 댓글이 말했듯이: 「여기에는 극한의 최적화를 추구할 엄청난 인센티브가 있습니다. 그래서 그들이 대단히 영리한 기법들을 엄청나게 많이 동원하고 있을 거라 예상합니다 — 그리고 그 기법이 영리할수록 이런 버그가 발생하기 쉽죠.」
단순한 「할루시네이션」이 아니다
일부에서는 이것이 AI의 「할루시네이션」에 불과한 것이 아닌지 — 즉, AI가 마인크래프트 관련 내용을 실제로 지어낸 것이지, 남의 데이터를 유출한 게 아니라는 의문을 제기했다.
합리적인 의문이다. AI는 실제로 콘텐츠를 자주 날조한다. 그러나 이번 사건에서는 「할루시네이션 설명」을 뒷받침하기 어렵게 만드는 몇 가지 세부 사항이 있다.
우선, 리포트 작성자는 로컬의 모든 대화 로그를 검색하여 「temple」이나 「bricks」라는 단어가 없음을 확인했다(Python 문법 하이라이팅 라이브러리 속의 minecraft.py라는 관련 없는 파일 하나만 제외하고). 이는 「AI가 현재 대화 속 특정 단어에서 연상 작용을 일으켰다」는 경로와 맞지 않는다.
둘째, 동일한 사용자가 다른 기기(모바일 앱)에서 유사한 현상을 반복 경험했다 — AI가 현재 작업과 전혀 관계없는 주제(인테리어)를 갑자기 꺼냈고, 그것도 정확히 캐시 미스가 발생하는 임계점(직전 대화로부터 5분 이상 경과)에서였다. 독립적인 할루시네이션으로 설명하기에는 확률적으로 매우 낮다.
무엇보다도, 여러 다른 회사의 사용자들이 HN 토론에서 유사한 경험을 교차 검증했으며, 그중 일부는 공식 사고 보고서를 받기까지 했다. 이 증거들은 우발적인 모델 동작이 아닌 시스템적 문제를 공통적으로 가리킨다.
물론 객관적으로 말해, GitHub Issue의 리포트 작성자는 현재 유출의 실제 출처를 100% 확정할 수 없다 — 동료인지, 낯선 사람인지 모른다. 이것이 바로 이런 버그의 가장 까다로운 지점이다: 감지할 수는 있지만 완벽하게 증명하기는 매우 어렵다.
일반 사용자에게 이것이 의미하는 것
당신이 위챗에서 AI와 채팅하며 요리법이나 카피라이팅을 묻는 정도라면, 이런 종류의 사건이 직접적인 영향은 크지 않을 수 있다 — 대화에 민감한 정보가 포함되지 않으므로 교차 연결이 일어나도 큰 문제가 아니다.
하지만 당신이나 당신의 회사가 영업 기밀, 의료 데이터, 법률 문서, 금융 정보가 포함된 시나리오에 AI를 적용하고 있다면, 이 사건의 시그널은 주목할 가치가 있다. 현재 AI 서비스의 인프라가 「멀티 테넌트 격리」 측면에서 엔터프라이즈 보안 제품이 갖추어야 할 기준에 아직 도달하지 못했음을 보여 준다 — 유료 엔터프라이즈 버전조차도 그렇다.
HN 토론에서 「요청 스머글링」 개념을 제안한 pocksuppet의 댓글은 상당히 솔직했다: 「여러 클라이언트의 요청을 동일한 업스트림 연결에 멀티플렉싱할 때마다, 당신은 공격받을 가능성이 매우 높다.」 문제는 이 특정 버그 하나에 국한되지 않는다 — 현재 인터넷 인프라 전체의 내재적 취약성을 가리킨다. AI 서비스는 그것을 더 민감한 층위에서 노출시켰을 뿐이다.
에필로그
기사 작성 시점까지, Anthropic은 이 사안에 대한 공식 입장을 발표하지 않았다. GitHub의 이슈는 여전히 Open 상태이며, 「bug」 및 「area:security」 라벨이 붙어 있다. HN 토론은 계속 확산 중이며, 유사 경험을 가진 목격자들이 계속 추가되고 있다.
이 사건은 AI 산업의 더 광범위한 맹점을 시사한다. 모든 사람들이 모델 능력을 향상시키고 추론 비용을 낮추는 데 전력 질주하는 동안, 「서로 다른 사용자들이 정말 안전하게 격리되어 있는가」라는 가장 기본적인 질문이 우선순위 목록의 뒤쪽으로 밀려나 버렸다.
HN 댓글란의 한 디테일이 필자에게 강한 인상을 남겼다. 사용자가 조 단위 기업 중 한 곳에 추궁했을 때, 상대방은 그저 「우리를 믿어 주세요」라고만 말했다. 반면 상세 보고서를 제공한 다른 회사의 사고 원인은 단 하나 — 숫자를 하나 잘못 세었을 뿐이었다.
참고 링크: