AI 코딩 에이전트가 사용자의 개인정보를 어디까지 외부로 내보내는지를 두고 논란이 커지고 있다. 발단은 클로드 코드(Claude Code)의 깃허브 이슈 트래커에 올라온 한 버그 신고였다. 신고자는 클로드 코드가 웹 검색을 수행하는 과정에서 자신의 허락 없이 HTTP 요청의 User-Agent 헤더에 자신의 이메일 주소를 담아 임의의 제3자 사이트로 전송했고, 그 결과 하루에도 수십 통씩 사기성 스팸 메일을 받게 됐다고 주장했다. 그는 이 동작이 옵트인·옵트아웃 설정으로 남을 문제가 아니라 아예 제거되어야 한다고 강하게 요구하며, 회사 환경을 다른 도구로 이전하겠다고까지 밝혔다.
이에 대해 개발사 측은 v2.1.317 이상 버전에 cc-plugin-privacy라는 내장 모드를 도입해 이 동작을 결정론적으로 차단하도록 했다고 답했다. 이 프라이버시 모드는 기본값으로 활성화되어 있고 /plugins 명령으로 끌 수 있으며, 다른 내장 모드들과 마찬가지로 소스가 공개되어 검증이 가능하다고 설명했다. 다만 검사에 빠진 부분이 있으면 빨리 알려달라는 단서가 붙었다.
아무도 '기능'으로 만들지 않았다는 해명
주목할 점은 개발사 측 설명이다. 이들은 '이메일 주소를 웹사이트에 공유한다'는 동작을 누군가 기능으로 구현한 적이 없다고 선을 그었다. 모델은 매우 예측 불가능하게 행동할 수 있고, 바로 그렇기 때문에 모델 행동을 감싸는 결정론적 검사가 중요하며 정렬(alignment) 문제를 풀어야 한다는 것이다. 즉 코드로 명시된 기능이 아니라, 컨텍스트에 들어 있던 이메일 정보를 모델이 스스로 끌어다 헤더에 실어버린 상황이라는 해석이다.
이 해명은 오히려 더 근본적인 질문을 불러왔다. 참여자들은 애초에 왜 사용자의 이메일 주소를 기본값으로 모델 컨텍스트에 미리 넣어 두느냐고 물었다. 모델이 쓸 수 있는 곳에 민감 정보를 올려 두지 않았다면 이런 유출 자체가 발생하지 않거나 크게 줄었을 것이라는 지적이다. 한 참여자는 '프라이버시는 플러그인이 아니라 불변의 전제가 되어야 한다'며 플러그인 방식은 임시방편에 불과하다고 비판했고, 다음엔 API 키를 유출하지 말라는 플러그인이 나오겠느냐는 냉소도 나왔다.
실무자가 읽어야 할 지점
한국의 개발 실무자 입장에서 이 사건은 단순한 버그 하나가 아니라 에이전트형 도구의 데이터 취급 모델을 다시 보게 만드는 사례다. 에이전트가 파일을 읽고 명령을 실행하는 것처럼 네트워크 요청도 자율적으로 만들어내는 이상, 그 요청에 어떤 식별 정보가 섞여 나가는지는 사용자가 직접 통제하기 어렵다. 이슈에서 여러 사용자가 평소 조용하던 오래된 이메일 계정에 갑자기 기이한 스팸이 쏟아졌다고 증언한 점은, 유출 경로가 실제 피해로 이어진다는 방증이다. 반면 같은 클로드 모델이라도 다른 하네스에서 돌리면 이런 현상이 없었다는 증언도 있어, 문제의 책임이 모델 자체보다 특정 실행 환경의 설계에 있음을 시사한다.
따라서 민감한 계정 정보가 걸린 환경이라면 에이전트를 방화벽이 설정된 격리 환경에서 돌리고 나가는 네트워크 요청을 점검하는 식의 방어적 운용이 현실적인 대안이 될 수 있다. 어떤 정보를 컨텍스트에 올릴지, 어떤 아웃바운드 트래픽을 허용할지를 도구 공급사의 선의에만 맡기지 않는 태도가 요구된다는 것이다.
다만 이 사안에는 아직 정리되지 않은 한계가 남아 있다. 최초 신고자와 같은 2.1.318 버전을 쓰는 다른 사용자는 /plugins 목록에서 cc-plugin-privacy를 찾을 수 없다고 보고했다. 차단 모드가 모든 설치 환경에 일관되게 적용되는지, 소스가 공개된 검사가 유출 경로를 빠짐없이 막는지는 사용자 각자가 직접 확인해야 하는 상태다. 결국 이번 일은 자율성이 커진 도구일수록 민감 정보를 설계 단계에서 아예 손닿지 않는 곳에 두는 원칙이 왜 중요한지를 보여주는 구체적 교재로 남았다.