저장소 전체가 갔다는 말이 왜 바로 퍼졌나
이번 일은 단순한 감정 싸움으로 끝나지 않았다. LocalLLaMA에 올라온 분석 글은 Grok Build CLI가 작업에 필요한 파일 몇 개만 보내는 게 아니라, 추적 중인 Git 저장소 전체와 히스토리를 묶어 올린다고 주장했다. 그 글이 퍼진 뒤 개발자들 사이에서는 읽지 말라고 한 파일까지 같이 가는 것 아니냐, 비밀키를 예전에 지웠어도 히스토리에 남아 있으면 위험한 것 아니냐는 반응이 이어졌다. LocalLLaMA 제보 글 (영어주의) Hacker News 토론 (영어주의)
핵심부터 말하면, 그런 의심이 괜한 소동만은 아니었다 쪽에 더 가깝다. The Register와 The Hacker News는 2026년 7월 14일 보도에서, 독립 연구자가 Grok Build가 전체 Git 저장소와 커밋 히스토리를 xAI 쪽 클라우드 저장소로 보낸 정황을 확인했다고 전했다. 보도 기준으로는 privacy나 Improve the model 같은 일반적인 인상이 바로 로컬에서만 돈다는 뜻은 아니었다. The Register 보도, 2026년 7월 14일 (영어주의) The Hacker News 보도, 2026년 7월 14일 (영어주의)
왜 이런 오해가 아니라 실제 문제로 봐야 했나
Grok Build는 처음부터 로컬 전용 편집기가 아니었다. xAI의 개요 문서는 이 도구를 터미널 기반 코딩 에이전트라고 설명하고, 인터랙티브 TUI뿐 아니라 스크립트, 봇, ACP 연동까지 지원한다고 적고 있다. 기업 배포 문서를 보면 핵심 연결 경로로 cli-chat-proxy.grok.com과 auth.x.ai가 먼저 나온다. 다시 말해 설계 자체가 네트워크를 쓰는 에이전트다. 여기서 많은 사람이 기대한 건 필요한 파일만 최소한으로 보낸다는 쪽이었고, 논란은 실제 동작이 그 기대보다 훨씬 넓어 보였기 때문에 커졌다. Grok Build 개요 문서 (영어주의) Enterprise Deployments 문서 (영어주의)
같은 문서에서 더 중요하게 봐야 할 부분이 있다. 기업 배포 문서는 ZDR, 즉 Zero Data Retention을 팀 단위로 켤 수 있다고 적고, ZDR 조직에서는 추론 계층에 프롬프트, 코드, 응답이 남지 않는다고 설명한다. 이 말은 뒤집어 보면 모든 사용자가 처음부터 그 상태였다고 보기는 어렵다는 뜻이기도 하다. 실제로 ZDR이 별도 정책으로 존재한다는 사실 자체가, 기본 사용 환경과 기업용 보안 환경을 나눠서 봐야 한다는 단서가 된다. Enterprise Deployments 문서, Privacy & data lifecycle / Zero Data Retention 항목 (영어주의)
또 하나 눈에 띄는 건 명령 문서다. xAI는 /privacy를 privacy and data-retention status를 보여주거나 토글하는 명령으로 설명한다. 이 표현만 보면 많은 사용자는 데이터 보관을 끄면 전송도 안 된다고 받아들이기 쉽다. 그런데 보도와 연구자 분석은 그 해석이 맞지 않았을 수 있다고 지적했다. 그래서 이번 이슈는 단순히 설정 하나가 안 먹었다보다, 프라이버시 토글이 정확히 무엇을 통제하는지 사용자가 더 분명하게 이해할 수 있게 써 두지 않았던 문제에도 가깝다. Modes and Commands 문서 (영어주의) The Register 보도 (영어주의)
실제로 확인된 사실은 여기까지다
지금 시점에 비교적 단단하게 말할 수 있는 건 네 가지다.
첫째, 논란은 Grok Build가 원래 네트워크를 쓰는 도구냐 아니냐의 문제가 아니다. 그건 공식 문서만 봐도 이미 네트워크 기반이다. 진짜 쟁점은 작업에 꼭 필요한 범위를 넘겨 저장소 전체와 히스토리까지 묶었는지다. Grok Build 개요 문서 (영어주의) Enterprise Deployments 문서 (영어주의)
둘째, xAI는 대응에 나섰다. Simon Willison이 정리한 2026년 7월 15일 메모를 보면, xAI는 기본 retention을 2026년 7월 12일부터 껐고 이전에 보관된 코딩 데이터도 삭제하겠다고 밝혔다고 전한다. 이 대목은 xAI 쪽 스레드 인용을 바탕으로 한 2차 정리라서, 공식 제품 문서만큼 직접적이진 않다. 그래도 아무 일 없었다고 밀어붙이는 대응은 아니었다는 점은 분명하다. Simon Willison 메모, 2026년 7월 15일 (영어주의)
셋째, xAI는 같은 시점에 Grok Build를 오픈소스로 공개했다. 2026년 7월 15일자 발표는 코드 공개와 함께 local-first로 직접 빌드해 자체 추론 환경에 붙여 쓸 수 있다고 적는다. 이미 생긴 불안을 줄이려는 조치로 읽는 쪽이 자연스럽다. 오픈소스가 됐다고 과거 전송 논란이 사라지는 건 아니지만, 적어도 지금부터는 동작을 더 구체적으로 들여다볼 수 있게 됐다. Grok Build is Now Open Source (영어주의) GitHub 저장소 (영어주의)
넷째, 기업용 통제 수단은 생각보다 강하다. requirements.toml로 보안 정책을 고정하고, ZDR을 팀 단위로 켜고, always-approve를 조직 차원에서 막는 식이다. 그래서 이번 이슈를 볼 때 Grok Build는 무조건 위험하다고 뭉뚱그리기보다, 개인이 기본 상태로 돌린 경우와 기업이 관리형 설정으로 붙인 경우를 나눠서 보는 편이 맞다. Enterprise Deployments 문서 (영어주의)
지금 써야 한다면 먼저 볼 것
- 예전에 잠깐이라도 Grok Build를 private repo에 붙였다면 현재 파일뿐 아니라 Git 히스토리에 남은 비밀키까지 같이 점검하는 편이 낫다.
privacy토글은 이름만 보고 믿지 말고, 현재 버전 문서에서 실제로 무엇을 끄는지 다시 보는 게 좋겠다. Modes and Commands 문서 (영어주의)- 팀에서 쓰는 경우라면 개인 설정에 맡기기보다 ZDR과
requirements.toml같은 관리형 정책부터 확인하는 쪽이 안전하다. Enterprise Deployments 문서 (영어주의) - 로컬에서만 돌려야 하는 저장소라면, 공개된 코드를 직접 빌드해 자체 추론 환경에 붙이는 선택지도 이제는 있다. 다만 이건 일반 사용자보다 엔지니어링 여력이 있는 팀 쪽에 가깝다. Grok Build is Now Open Source (영어주의)
내 생각
이번 건 AI 코딩 도구는 원래 클라우드 쓰잖아라고 가볍게 넘길 일은 아니었다. 사람들이 불편해한 이유는 네트워크 사용 자체보다, 내가 연 파일 몇 개만 가는 줄 알았는데 저장소와 히스토리까지 더 넓게 다뤄졌을 수 있다는 데 있었다. 그 감각은 충분히 타당했다.
xAI가 보관 기본값을 끄고 코드를 공개한 대응은 나쁘지 않았다. 다만 이 대응이 좋아 보인다는 말과, 초반 기본 동작이 과했다는 말은 같이 성립한다. 지금 더 정확한 정리는 이 정도다. Grok Build를 완전히 허풍이라고 볼 일도 아니고, 프라이버시 설정 있으니 괜찮다고 쉽게 넘길 일도 아니다. private repo에 붙는 코딩 에이전트라면 성능보다 먼저 데이터 경로를 보는 쪽이 맞아 보인다.
참고 링크
관련 글
같은 맥락에서 이어서 읽기 좋은 글들입니다.