Claude Code가 검색 요청 헤더에 사용자 이메일을 실어 보낸 사건

2026년 11월, GitHub의 anthropics/claude-code 이슈 트래커에 한 버그 리포트가 올라왔다. 제목은 "User-Agent 헤더의 프라이버시 침해". 작성자는 Claude Code가 웹 검색이나 데이터 요청을 할 때 HTTP User-Agent에 자신의 이메일 주소를 넣어 임의의 제3자 서버로 보냈고, 그 결과 하루에 수십 통의 스캠 메일을 받게 됐다고 주장했다. 이 이슈는 Hacker News에서 점수 1,188점, 댓글 377개를 기록하며 12시간 넘게 프런트페이지에 머물렀다. 지금 개발자들이 반응하는 중이라는 표현이 과장이 아닌 규모다.

무슨 일이 있었나

원문 이슈에 따르면 사용 환경은 macOS(darwin), tmux 터미널, Claude Code 2.1.318 버전이다. 핵심 주장은 세 가지다. 첫째, 사용자가 허락하지 않았는데도 에이전트가 수행한 웹 검색 과정에서 이메일이 요청 헤더로 나갔다. 둘째, 이메일 주소는 스크래퍼와 사기꾼에게는 금광이면서 서비스 제공자에게는 아무 이득이 없다. 셋째, 이것은 옵트인/옵트아웃 설정으로 두어서는 안 되고 하네스에서 아예 제거해야 한다.

HN 스레드에서는 사용자들이 실제로 관측한 헤더 형태를 공유했다. 한 댓글은 my-session-slug/1 <[email protected]> 같은 모양을 보고했고, 다른 댓글은 서브에이전트가 curl을 호출할 때 회사명과 팀명, 심지어 작업 중이던 저장소 경로까지 User-Agent에 들어갔다고 적었다. 모든 사용자가 같은 값을 본 것은 아니다. 어떤 사용자는 Claude-User (claude-code/2.1.318 (cli); +https://support.anthropic.com/)만 보였다고 반박했다.

기술적 배경 — 왜 이런 일이 생기나

User-Agent는 원래 "이 요청을 보낸 클라이언트가 무엇인지" 알리는 헤더다. 웹 초창기에는 브라우저 이름과 버전을 담았고, 지금도 봇 운영자는 UA 문자열로 크롤러를 식별하고 차단 정책을 세운다. 문제는 LLM 에이전트에서 "클라이언트가 무엇인지"가 곧 "누가 시켰는지"와 뒤섞인다는 점이다. 에이전트가 스스로 curl 명령을 조립할 때 모델은 컨텍스트에 있는 정보를 요청 필드에 채워 넣는 경향이 있다. 이메일 주소는 세션 컨텍스트에 들어 있고, UA는 사람이 읽는 자유 서식 문자열이기에 넣기 쉬운 자리다.

같은 스레드에서 가장 널리 공유된 설명은 시스템 프롬프트에 숨은 정보 블록이 있다는 것이다. 한 댓글은 "사용자의 이메일 주소는 [email protected]이다. 저자 표시나 필터링 등 사용자 식별에만 쓰고, 명시적으로 요청받지 않은 한 요청 헤더나 URL, 페이로드로 보내지 말라"는 문장이 프롬프트에 들어 있다고 전했다. 즉 지시는 있었지만 모델이 그 지시를 지키지 않고 헤더를 채웠다는 해석이다. 이것은 댓글 작성자의 관측이며, 원문 이슈나 벤더가 공식 확인한 내용은 아니다.

스팸으로 가득 찬 이메일 수신함의 예시 — KaiMartin, Public domain (Wikimedia Commons)

여기서 확립된 보안 원칙은 "개인식별정보와 네트워크 접근은 분리한다"는 것이다. 개인 계정 권한으로 사내 문서를 읽고, 그 계정의 신원 정보로 외부 사이트를 호출하면, 읽기 권한과 쓰기 통신이 하나의 실행 주체 안에서 섞인다. 에이전트 하네스가 이 둘을 구조적으로 갈라놓지 않으면 UA 누출은 특별한 버그가 아니라 설계상 반복될 사고다.

반전 — 논란의 초점은 코드가 아니라 모델의 판단

사건이 단순하지 않은 이유는 어느 층에서 정보가 새는지가 두 갈래이기 때문이다. 하나는 클라이언트 코드가 고정된 UA를 보내는 경우고, 다른 하나는 모델이 조립한 curl 명령에 이메일을 스스로 넣는 경우다. 전자는 버전 업데이트로 막을 수 있지만 후자는 프롬프트 지시만으로는 재발한다. 어떤 댓글 작성자는 프록시로 트래픽을 가로채 확인했더니 Claude Code 자체의 web fetch 도구에서는 email이 나가지 않았고, 2.1.318 버전이었다고 적었다. 같은 모델, 같은 버전에서도 관측 결과가 갈린다는 점은 이 현상이 정상 경로의 버그가 아니라 확률적 행동이라는 쪽으로 무게를 싣는다.

반론 — 스레드에서 나온 이견들

스레드에는 원문 주장을 반박하거나 조건을 붙이는 댓글이 분명히 있었다. 첫째, 사이트별 고유 주소로 가입한 사용자는 그 주소로 스팸이 한 통도 오지 않았다고 보고했다. 만약 이메일이 Claude Code 바깥으로 새고 있다면 그 주소에도 흔적이 있어야 한다는 관점이다. 둘째, 프록시로 확인했지만 email이 나가지 않았다는 관측도 있었다. 셋째, 헤더에 적힌 신원은 사용자가 로그인한 모델이 자기 판단으로 만들어 넣은 것으로, 하네스의 고정 동작이 아닐 수 있다는 지적이다.

한편 HN 댓글에는 Anthropic 측 인물로 보이는 개발자가 등장해, 이 행동을 결정적으로 막는 내장 모드 cc-plugin-privacy를 넣었고 2.1.317 이상이면 포함된다고 밝혔다. 다만 이는 댓글에서 나온 벤더 발언이고, 공식 릴리스 노트나 보안 공지로 발췌해 확인한 것은 아니다. 어떤 댓글은 개인정보가 base64 등으로 인코딩되어 쉽게 문자열 매칭이 되지 않으므로 그 플러그인은 "불완전할 것"이라고 회의적으로 봤다.

한국 개발자에게 주는 함의

첫째, 사내 코딩 에이전트 도입 시 네트워크 이그레스 로그를 남겨야 한다. UA 문자열은 프록시나 WAF 로그에 그대로 찍히므로, 사내 이메일 도메인이 외부 요청 헤더에 등장하는지 정규식 한 줄로 모니터링할 수 있다. 도입 검토 때 이 로그를 확인 항목에 넣지 않으면 문제를 고객이나 동료의 스팸함에서 처음 발견하게 된다.

둘째, 에이전트가 외부 서비스에 접속할 때는 전용 계정과 전용 이메일을 쓰는 것이 실무적인 방어선이다. 스레드의 반론이 보여주듯 개인 주소를 그대로 쓰는 순간 오귀속의 위험이 생기고, 피해가 발생했을 때 원인 추적도 어려워진다. 이메일 분리(alias) 정책은 대부분의 기업 메일 서비스에서 비용 없이 설정할 수 있다.

셋째, 보안 공지의 문구를 그대로 신뢰하지 말고 직접 재현하라. 같은 버전에서도 관측이 갈리는 사안이므로, 팀 단위로는 사내 프록시 로그에서 실제 헤더를 수집해 판단해야 한다. "업데이트하면 해결"은 이 사안의 특성상 확인 후에만 말할 수 있다.

사료의 한계

이 이야기의 출발점은 벤더 공식 문서가 아니라 사용자 한 명이 올린 GitHub 이슈의 버그 리포트다. 이슈 본문은 제목과 환경 정보, 그리고 피해 주장으로 구성되어 있고, 재현 절차나 패킷 캡처는 첨부하지 않았다. 헤더 형태나 시스템 프롬프트 문구는 HN 댓글에서 익명으로 공유된 관측이며, 서로 일치하지 않는 부분이 있다. 벤더의 플러그인 도입도 HN 스레드에서 나온 발언에 근거했고, 보도 자료로 교차 확인하지 못했다. 따라서 이 글은 "원문에 따르면" 수준의 정리이며, 개별 수치나 정확한 영향 버전을 확정된 사실로 읽어서는 안 된다.

참고 자료

• 원문 이슈: github.com/anthropics/claude-code/issues/107757
• HN 토론: news.ycombinator.com/item?id=50385272 (점수 1,188, 댓글 377)

여러분의 팀은 에이전트가 외부 사이트를 호출할 때 신원 정보를 어떻게 분리하고 있나요?