이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
Grok Build coding CLI가 사용자가 읽도록 허용한 파일만이 아니라 전체 local repository와 git history를 xAI의 Google Cloud Storage로 업로드하고, .env secrets까지 암호화 없이 전송했다는 독립 재현 결과가 공개됐습니다. 12GB repository 실험에서는 5.10GiB가 storage channel로 이동했으며, 에이전트가 파일을 읽지 말라는 지시를 받은 세션에서도 업로드가 발생했습니다. SpaceX는 feature flag로 업로드를 중단하고 기본 retention을 끈 뒤 기존 데이터를 삭제하겠다고 밝혔으며, Elon Musk의 open source 약속에 따라 Grok CLI 저장소도 공개했습니다. 그러나 공개 저장소가 190개가 넘는 기본 컴파일 오류를 냈고 사전 동의와 보안 검토가 부족했다는 정황 때문에, 글은 Grok CLI가 기업 codebase를 맡을 신뢰를 회복하려면 장기간의 보안 검증이 필요하다고 결론짓습니다.
섹션별 상세
Grok 4.5는 Cursor가 개발하고 SpaceX GPU로 학습한 모델로 소개됐으며, 코딩 성능은 Opus 4.8과 GPT 5.5에 근접하면서 비용은 60~70% 낮다고 제시됩니다. 개발자들이 주로 사용한 Grok Build coding CLI에서는 에이전트가 실제로 읽은 파일뿐 아니라 작업 디렉터리의 로컬 파일을 서버로 보내는 동작이 발견됐습니다. 이 구조는 모델의 context window에 필요한 코드만 전달하는 일반적인 coding agent의 흐름과 달리 전체 codebase와 민감한 파일까지 외부 저장소로 전송한다는 점에서 문제가 됐습니다.
Cerblab의 독립 재현에서는 Grok Build가 .env 파일을 마스킹이나 암호화 없이 xAI로 전송하고, /v1/responses와 /v1/storage 두 경로에 저장한 정황이 확인됐습니다. 에이전트에게 어떤 파일도 읽지 말라고 지시한 세션에서도 전체 repository의 tracked files와 git history가 Git Bundle로 업로드됐으며, 12GB 저장소 실험에서는 5.10GiB가 이동해 모델 turn의 192KB보다 약 27,800배 많은 전송량을 기록했습니다. 저장 대상은 AWS S3가 아니라 grok-code-session-traces라는 Google Cloud Storage bucket으로 지목됐고, 이 자료는 xAI가 해당 데이터를 학습에 사용했다는 사실까지 입증하지는 않지만 전송·수락·보관 자체는 입증한다고 구분합니다.
근거
- Grok Build는 에이전트가 읽은 파일에 그치지 않고 전체 repository와 git history를 xAI storage endpoint로 업로드했다. — Cerblab 인용문에서 “reply OK, do not read any files” 조건에도 Git Bundle 업로드가 발생했고, 12GB 저장소에서 5.10GiB가 이동했다는 재현 결과
- 12GB repository 실험에서 storage channel의 전송량은 모델 turn channel보다 약 27,800배 많았다. — Cerblab 인용문 중 5.10 GiB와 192 KB를 비교한 전송량 설명
- Grok Build는 .env 파일의 비밀을 마스킹이나 암호화 없이 전송하고 저장했다. — Cerblab 인용문 첫 번째 항목의 .env secrets file, /v1/responses, /v1/storage 및 grok-code-session-traces bucket 설명
글은 전체 코드베이스를 context window 밖에서 별도 업로드할 기술적 필요가 약하다고 평가합니다. Cursor는 로컬에서 codebase를 인덱싱하고 embeddings만 서버로 전송하는 방식으로 코드 검색을 처리하며, .env에는 service token과 database access token 같은 비밀이 들어갈 수 있으므로 서버 전송이 필요하더라도 최소한 암호화와 명시적 동의가 요구된다는 논리입니다. 특히 git history는 디버깅에 필요한 범위를 넘어설 수 있어 기본값으로 수집하면서 사용자에게 알리지 않은 설계가 기업 환경의 신뢰 기준과 충돌합니다.
논란이 커지자 Grok 팀은 원격 feature flag를 바꿔 파일 업로드를 중단했지만, 관련 전송 코드와 기능은 이후 CLI 업데이트에도 남아 있었다고 전해집니다. SpaceX는 ZDR을 활성화한 enterprise 고객은 영향을 받지 않았고 7월 12일부터 모든 Grok Build 사용자의 기본 보존을 비활성화했으며 기존 coding data도 삭제한다고 밝혔습니다. 그러나 글은 이 대응이 일반 사용자에게 숨겨진 privacy command의 책임을 돌리는 듯한 인상을 주었고, 실제 수집 범위가 디버깅용 일부 trace가 아니라 로컬 폴더의 파일 전체였다는 점을 충분히 해소하지 못했다고 평가합니다.
근거
- SpaceX는 7월 12일부터 Grok Build 사용자의 기본 보존을 비활성화하고 기존 coding data를 삭제한다고 밝혔다. — SpaceX 공식 응답 인용문인 “We disabled default retention for all Grok Build users starting on July 12th” 부분
Elon Musk는 보존된 일부 데이터가 디버깅에 도움이 되며 privacy settings를 존중한다고 썼지만, 글은 .env와 git history 전체 업로드가 단순한 debugging trace의 범위를 훨씬 넘는다고 반박합니다. Sam Altman은 Musk가 자주 쓰는 “concerning”이라는 표현으로 Grok의 동작을 비판하고, Codex harness가 open source라면 이런 비밀스러운 파일 업로드 기능이 소스에서 드러났을 것이라는 대비를 만들었습니다. Musk가 Grok CLI를 open source로 만들겠다고 한 뒤 SpaceX는 다음 날 저장소를 공개했지만, 그 과정 자체가 신뢰 회복을 위한 사후 대응으로 읽혔습니다.
공개된 Grok CLI 저장소는 서둘러 배포된 흔적을 드러냈습니다. Elliot Arledge는 기본 상태에서 cargo test --workspace가 190개가 넘는 오류로 컴파일되지 않았고, 수정 후 24,663개 테스트가 통과했지만 28개는 기존 버그로 실패했으며 실제 ~/.claude/settings.json을 읽는 테스트와 macOS /var symlink 문제도 남았다고 기록했습니다. 글은 이 결과를 즉시 open source 전환하라는 지시가 제품의 기존 구조와 검증 절차를 앞질렀다는 사례로 해석합니다.
근거
- 공개된 Grok CLI 저장소는 기본 cargo test --workspace 실행에서 190개가 넘는 컴파일 오류를 냈다. — Elliot Arledge 인용문에서 190+ errors, 수정 후 24,663 passed와 28 failed를 제시한 부분
글의 결론은 Grok CLI가 기업 codebase를 다룰 보안 기본기를 갖추지 못해 신뢰할 수 없는 coding agent로 비쳤다는 것입니다. Claude Code, Codex, OpenCode, Gemini CLI는 같은 방식으로 사용자 신뢰를 훼손하지 않았다고 대비되며, Grok이 다시 선택받으려면 수년간 보안 사고 없이 운영하고 일반 개발자까지 고려하는 정책을 입증해야 한다고 봅니다. 빠른 출시가 보안 검토와 프로세스를 생략할 때 단기적인 개발 시간 절약이 enterprise 계약 감소와 훨씬 큰 복구 비용으로 돌아올 수 있다는 교훈도 함께 제시됩니다.
용어 해설
- 데이터 무보존(Zero Data Retention)
- — 사용자 데이터와 세션 기록을 서버에 보관하지 않는 정책입니다. 이 글에서는 SpaceX가 ZDR을 활성화한 enterprise 고객은 Grok Build의 기본 파일 업로드 영향을 받지 않았다고 밝혔지만, 일반 사용자는 별도 opt-in 없이 코드와 파일이 전송된 정황이 문제의 핵심으로 다뤄집니다.
- Git Bundle
- — Git 저장소의 파일과 커밋 이력을 하나의 묶음으로 저장하거나 전송하는 형식입니다. Cerblab의 재현에서는 Grok Build가 에이전트가 읽지 않은 파일과 전체 git history까지 포함한 저장소 묶음을 xAI의 storage endpoint로 보낸 근거로 사용됐습니다.
- 코드 인덱싱(Code Indexing)
- — 대규모 코드베이스에서 필요한 파일을 빠르게 찾도록 소스 구조를 벡터나 검색 인덱스로 변환하는 과정입니다. 글은 Cursor가 codebase를 로컬에서 인덱싱하고 embedding만 서버로 보내는 방식과 Grok Build의 전체 원문 업로드를 대비시켜 개인정보 보호 차이를 짚습니다.
- ZDR
- — Zero Data Retention의 약자로, API나 coding agent가 처리한 입력과 추적 데이터를 저장하지 않는 설정입니다. SpaceX는 ZDR을 켠 enterprise 고객은 이번 업로드의 영향을 받지 않았다고 밝혔지만, 일반 고객에게는 기본 보존과 숨겨진 privacy command가 쟁점이 됐습니다.
- Feature Flag
- — 배포된 소프트웨어의 특정 기능을 코드 수정 없이 원격에서 켜거나 끄는 제어 장치입니다. Grok 팀은 논란이 확산된 뒤 feature flag를 바꿔 파일 업로드를 중단했지만, 로컬 파일을 암호화 없이 전송하는 코드 자체는 이후 CLI에도 남아 있었다고 글은 전합니다.
기술
- Grok 4.5
- Grok Build
- Cursor
- SpaceX GPUs
- API
- CLI
- Google Cloud Storage
- GCS
- AWS S3
- embeddings
- Codex
- Claude Code
- OpenCode
- Gemini CLI
- Bazel
- Cargo
활용 사례
- 로컬 repository를 대상으로 코드 검색과 수정 작업을 수행하는 coding agent
- enterprise codebase와 secrets를 외부 AI 서비스에 연결하는 개발 환경
- AI coding CLI의 파일 업로드와 data retention 정책 검증
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 19.수집 2026. 08. 20.출처 타입 RSS
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
