Hook

사용자의 전체 Git 히스토리(커밋 로그, 비밀 정보 등 포함)를 벤더(Vendor)가 제어하는 버킷(Bucket)으로 업로드하는 AI 코딩 CLI가 있습니다. 심지어 이 과정은 사용자의 개인정보 보호 거부(Privacy opt-out) 설정조차 영향을 미치지 않는 채널을 통해 이루어집니다. 이것은 버그 바운티(Bug bounty)의 각주 수준의 이야기가 아닙니다. 1년 전 모두가 "이론적"이라며 무시했던 바로 그 위협 모델이, 이제 카나리 파일(Canary file)을 통해 확인된 것입니다.

Context

개념적으로 이것이 새로운 영역은 아닙니다. "AI 도구가 지나치게 광범위한 파일 접근 권한을 가진다"는 점은 첫 번째 VS Code 확장 프로그램이 워크스페이스 전체 권한을 요청했을 때부터 알려진 위험이었습니다. 여기서 다른 점은 메커니즘입니다. 이것은 모델이 파일을 컨텍스트(Context)로 읽어 들여 완성(Completion)을 통해 유출할 수도 있는 문제가 아니었습니다. 이것은 에이전트(Agent)가 건드린 파일뿐만 아니라 _전체 저장소(Entire repositories)_를 클라우드 스토리지로 이동시키는 별도의, 조용한 업로드 파이프라인이었습니다. 이는 사용자들에게 데이터 공유를 제어한다고 안내된 "모델 개선(Improve the model)" 토글과는 독립적으로 작동했습니다.

그 차이는 엄청나게 중요합니다. 우리는 지난 2년 동안 개발자들에게 프롬프트 인젝션(Prompt injection), 컨텍스트 유출(Context leakage), 그리고 학습 데이터 오염(Training-data contamination)에 대해 생각하도록 교육해 왔습니다. 이것들은 모델 계층(Model-layer)의 문제이며 모델 계층의 완화 조치(Mitigations)가 필요합니다. 하지만 이것은 인프라 계층(Infrastructure-layer)의 문제입니다. 즉, 모델이 당신의 코드를 가지고 무엇을 "결정"하든 상관없이 존재하는 데이터 유출(Data exfiltration) 경로입니다. 이것은 AI 안전(AI safety) 문제라기보다는 공급망 텔레메트리(Supply-chain telemetry) 스캔들에 더 가깝습니다. 그리고 이것이 에이전트 기반 코딩 도구(Agentic-coding-tool)의 옷을 입고 있다는 사실이 본질을 흐리게 해서는 안 됩니다.

Hype Check

여기서 과소평가되고 있는 부분은 바로 '옵트아웃(opt-out, 거부)'의 실패입니다. 벤더(Vendors)들은 사용자들이 "모델 개선(model improvement)" 또는 "학습 데이터 사용(training data usage)" 설정을 끄는 것만으로도 자신의 기기에서 나가는 데이터를 의미 있게 제한할 수 있다고 믿도록 훈련시켜 왔습니다. 만약 이것이 겉치레에 불과하다면 — 즉, 설정과 관계없이 비식별화되지 않은 비밀 정보(secrets)를 포함한 전체 커밋 히스토리(commit history)를 이동시키는 병렬 채널이 존재한다면 — 모든 AI 코딩 도구의 모든 개인정보 보호 보증은 별도의 증거가 나타날 때까지 검증되지 않은 것으로 간주해야 합니다. 이것은 편집증이 아니라, 감사 추적(audit trail) 없이 "우리는 귀하의 데이터를 저장하지 않습니다"라고 주장하는 그 어떤 벤더에게도 적용할 법한 동일한 회의론을 적용하는 것뿐입니다.

반대로 과장되고 있는 부분은, 적어도 이에 대한 귀를 찢는 듯한 침묵 — HN(Hacker News)에서의 제로 포인트, 제로 코멘트 — 을 통해 볼 때, 현재 사람들이 이 문제를 얼마나 심각하게 받아들이고 있는가 하는 점입니다. 그 침묵 자체가 하나의 신호입니다. 이 발견이 관심을 가질 만한 사람들에게 아직 도달하지 않았거나, 아니면 "AI 도구가 당신의 데이터로 수상한 짓을 한다"는 사실이 너무나 일상적이어서 더 이상 인지조차 되지 않는 상태가 된 것입니다. 어느 쪽의 설명도 위안이 되지 않습니다.

이것이 사소한 버그라는 서사로부터 누가 이득을 얻을까요? 당연히 벤더입니다. 조용한 패치와 변경 로그(changelog) 한 줄을 남기는 것이, 코딩 어시스턴트가 접촉한 모든 프라이빗 레포지토리(private repo)의 그림자 복사본(shadow copy)을 몰래 구축하고 있었다는 사실을 인정하는 것보다 훨씬 저렴하기 때문입니다. 하지만 솔직히 말해서, 더 넓은 AI 툴링 산업 또한 이것이 더 큰 이슈가 되지 않음으로써 이득을 얻습니다. 왜냐하면 만약 하나의 에이전트형 코딩 CLI(agentic coding CLI)가 이런 짓을 한다면, 다른 도구들도 그러한지 확인해 볼 가치가 있다는 가정이 성립되어야 하기 때문입니다.

시사점 (Implications)

개발자들에게 주는 메시지: 만약 당신이 어떤 AI 코딩 에이전트에게 레포지토리에 대한 셸(shell) 또는 파일 시스템(filesystem) 접근 권한을 부여했다면, 더 이상 "이 도구가 내 프롬프트에 답하는 데 필요한 것만 본다"고 가정해서는 안 됩니다. 당신은 이 도구가 해당 레포지토리의 모든 것 — 히스토리 포함 — 을 볼 수 있고, 잠재적으로 전송할 수도 있다고 가정해야 합니다. 이는 비밀 정보 스캐닝(secrets scanning)과 로테이션(rotation)이 더 이상 선택적인 위생 관리가 아니라, 이러한 도구들을 사용하기 위한 기본적인 비용(baseline cost)임을 의미합니다.

보안팀의 경우: 이는 AI 거버넌스 문제인 동시에 네트워크 모니터링 문제입니다. 만약 여러분이 DLP(데이터 손실 방지) 목적으로 모델 API 트래픽만 감시하고 있다면, 잘못된 파이프를 보고 있는 것입니다. 로컬 레포지토리 접근 권한을 가진 모든 에이전트형 도구는 공급업체가 UI에서 노출하는 어떤 '개인 정보 보호 설정'과도 독립적으로 그 외부 전송(egress traffic) 트래픽을 목록화하고 감사해야 합니다.

산업계의 경우: 이는 다음 컴플라이언스 골칫거리의 예고편입니다. SOC 2 및 동등한 감사는