코딩 에이전트에게 저장소 접근 권한을 내주는 일은 이미 일상이 됐다. 문제는 그 권한이 어디까지 쓰이는지 개발자가 실제로는 잘 모른다는 점이다. xAI가 내놓은 코딩 에이전트 CLI 'Grok Build' 0.2.93 버전이 로컬 저장소 전체와 커밋 히스토리, 그리고 .env 파일 같은 비밀정보를 xAI 소유의 구글클라우드 버킷(grok-code-session-traces)으로 무단 전송했다는 사실이 와이어 레벨 트래픽 분석으로 드러났다. 이 내용은 CyberSecurityNews의 보도와 The Hacker News의 후속 취재를 통해 확인됐다.
192KB면 됐을 응답에 5.1GiB가 새어나갔다
단순 오탐이나 과장이 아니다. The Hacker News가 확인한 사례 중 하나는 모델이 정상적인 응답을 생성하는 데 192KB면 충분했을 데이터가 실제로는 5.1GiB나 전송됐다는 것이다. 텍스트 몇 줄을 처리하는 요청 뒤에서 저장소 통째가 클라우드로 흘러가고 있었다는 뜻이다. 이 정도 규모의 데이터 전송은 우연한 버그로 설명하기 어렵고, 코드베이스를 폭넓게 수집하도록 설계된 동작 방식이 있었다는 정황으로 읽힌다.
더 심각한 건 전송 대상이 소스코드에 그치지 않았다는 점이다. .env 파일에 담긴 API 키, DB 접속 정보, 서비스 토큰 같은 비밀정보와 커밋 히스토리 전체가 함께 올라갔다. TechTimes 보도에 따르면 CLI 안에 사용자가 이 업로드를 막을 수 있다고 알려진 프라이버시 토글이 있었지만, 실제로는 켜져 있어도 전송을 막지 못했다.
Cursor가 3년 쌓은 신뢰, xAI는 토글 탓으로 돌렸다
이 사건이 개발자 커뮤니티에서 특히 크게 번진 건 The Pragmatic Engineer 뉴스레터 운영자 Gergely Orosz(@GergelyOrosz)가 X에 남긴 글 덕분이다. 조회수 20만, 좋아요 2300을 기록한 이 게시물에서 그는 "이 끔찍한 사건을 보고 어떤 제대로 된 회사도 Grok CLI를 쓸 수 있다고 생각 못하겠다. 아마추어이고(코드로 돈을 별로 못 벌고) 보안에 신경 안 쓴다면(.env 유출을 신경 안 쓴다면) 그럼 써도 된다"고 직설적으로 비판했다.
Orosz는 여기서 멈추지 않고 xAI의 대응 방식 자체를 문제 삼았다. 그는 "Cursor는 3년간 개발자들이 쌓아온 신뢰받는 브랜드인데, xAI/Grok은 몰래 .env 파일을 클라우드에 올려놓고는 사용자가 이를 막는 비밀 스위치를 안 켠 탓이라고 떠넘겼다"고 지적했다. 자세한 배경은 그의 The Pulse 뉴스레터 해당 호에 정리돼 있다. 이는 결함을 인정하는 대신 책임을 사용자 설정으로 돌리는 태도가, 문제 자체보다 더 큰 신뢰 손상을 낳는다는 지적이다. 실제로 xAI는 사건이 알려진 뒤 서버 단에서 업로드 기능을 비활성화하고 CLI에 disable_codebase_upload라는 새 설정 옵션을 추가했는데, 이는 기존 토글이 사실상 작동하지 않았음을 스스로 인정한 셈이다.
| 구분 | 사건 이전 | 사건 이후 (xAI 대응) |
|---|---|---|
| 업로드 범위 | 저장소 전체 + 커밋 히스토리 + .env 등 비밀정보 | 서버 단에서 업로드 기능 비활성화 |
| 사용자 제어 | 기존 프라이버시 토글이 있었으나 작동하지 않음 | disable_codebase_upload 신규 옵션 추가 |
| 공개 정도 | 와이어 레벨 분석으로 뒤늦게 발견 | 보도 이후 사후 조치, 사전 고지 없음 |
`.env`부터 돌려 잠그세요
Grok Build를 로컬이나 CI 환경에서 써온 팀이라면 우선순위는 명확하다. 첫째, .env를 포함해 CLI 실행 중 접근 가능했던 모든 비밀정보를 즉시 로테이션한다. 클라우드에 이미 올라간 값은 삭제 요청과 별개로 유출된 것으로 간주하는 게 안전하다. 둘째, CLI 버전을 확인하고 최신 버전으로 업데이트한 뒤 disable_codebase_upload 옵션이 실제로 켜져 있는지 네트워크 트래픽 수준에서 검증한다. 설정 화면의 표시만 믿지 않는 것이 이번 사건의 핵심 교훈이다.
셋째, 조직 차원에서 코딩 에이전트 CLI 도입 기준에 "네트워크 아웃바운드 트래픽을 사용자가 직접 검증할 수 있는가"라는 항목을 추가할 필요가 있다. 벤더가 제공하는 프라이버시 설정 문서가 아니라, 실제 패킷 캡처나 프록시 로그로 확인 가능한지가 기준이 되어야 한다. 넷째, 이미 Grok Build를 통해 커밋한 저장소가 있다면 히스토리에 비밀정보가 남아있는지 별도로 스캔하고, 필요하면 히스토리 재작성(BFG, git-filter-repo 등)까지 검토해야 한다. 단순히 최신 커밋의 .env를 지우는 것으로는 부족하다.
해명했지만 삭제는 미확인
다만 이 사건에서 아직 공식적으로 확인되지 않은 부분도 분명히 있다. xAI가 이번 건에 대해 공개 사과문이나 공식 성명을 발표했는지는 현재 보도들에서 명확히 드러나지 않는다. 서버 단 업로드 비활성화와 disable_codebase_upload 옵션 추가라는 조치는 확인됐지만, 이미 grok-code-session-traces 버킷에 쌓인 기존 데이터를 xAI가 삭제했는지, 삭제했다면 어떤 절차와 기한으로 처리했는지는 공개된 정보로는 확인되지 않는다. 또한 이 업로드가 의도된 텔레메트리 설계였는지 아니면 순수한 구현 결함이었는지에 대한 xAI 측의 기술적 해명도 아직 나오지 않은 상태다.
재발 방지 대책이 이번 CLI에 국한된 것인지, 아니면 xAI의 다른 에이전트 제품군 전반에 적용되는지도 불명확하다. 이런 공백이 남아있는 한, Grok Build를 다시 신뢰하고 쓸지 여부는 벤더의 발표를 기다리기보다 각 팀이 직접 트래픽을 검증하며 판단하는 편이 안전하다.
