저장소 몰래 올리다 걸린 xAI, 72시간 만에 Grok Build 공개

xAI가 자사 코딩 에이전트 Grok Build의 소스 코드를 통째로 공개했다. 2026년 7월 15일(미국 시간) GitHub 저장소 xai-org/grok-build에 약 84만 4530줄의 Rust 코드가 Apache 2.0 라이선스로 올라왔다. 코딩 에이전트의 내부 전체, 그러니까 모델을 감싸는 에이전트 루프부터 도구 구현, 전체화면 터미널 UI, 확장 시스템까지가 한 번에 열렸다.

문제는 공개의 배경이다. 이 결정은 기술을 나누려는 자발적 결정이 아니었다. 며칠 앞서 한 사용자가 grok CLI가 로컬 디렉토리를 사용자 동의 없이 xAI의 Google Cloud 저장소로 올리고 있다는 사실을 패킷 캡처 증거와 함께 공개했다. 그 폭로로부터 약 72시간 뒤에 나온 것이 이 오픈소스 공개다.

몰래 올라간 홈 디렉토리, 그리고 72시간

사건의 시작은 코드 공개가 아니라 데이터 유출 정황이었다. X 사용자 @a_green_being이 grok CLI를 실행하면 작업 디렉토리 전체가 xAI가 통제하는 클라우드 버킷으로 전송된다는 것을 네트워크 레벨 증거로 제시했다. 명시적 동의 절차는 없었다.

피해는 코드에 그치지 않았다. 한 개발자는 홈 디렉토리를 대상으로 도구를 실행했다가 SSH 키, 비밀번호 관리자 데이터베이스, 문서, 사진, 영상까지 전부 올라갔다고 보고했다. 코딩 에이전트에 디렉토리 접근 권한을 주는 것은 흔한 일이지만 그 내용이 조용히 외부 서버로 복제된다는 사실은 알려지지 않았다.

xAI의 대응은 세 단계로 이어졌다. 먼저 해당 기능을 비활성화했다. 다음으로 보관된 데이터를 삭제하겠다고 밝혔고 일론 머스크가 직접 X에서 삭제를 공지했다. xAI는 "데이터 저장은 7월 12일부터 기본 off였다"고 해명했다. 그리고 마지막 카드가 오픈소스 공개였다. 명분은 "완전한 투명성"이었다. 코드를 전부 열어 무엇을 하는 도구인지 누구나 확인하고 원한다면 클라우드 없이 로컬에서만 돌릴 수 있게 하겠다는 설명이다.

84만 줄 안에 무엇이 들어 있나

공개된 코드는 코딩 에이전트가 실제로 얼마나 큰 소프트웨어인지 드러낸다. 844,530줄 중 외부 의존성을 벤더링한 코드는 약 3%뿐이다. 나머지는 xAI가 직접 쓴 코드다. 비교 대상으로 자주 언급되는 OpenAI Codex가 약 95만 줄이니 규모가 비슷하다. 터미널에서 명령어 몇 개로 쓰는 도구 뒤에 이 정도 코드가 있다.

코드는 크게 네 개의 Rust crate로 나뉜다. 에이전트 런타임과 진입점, 도구 구현(파일 읽기·편집·검색·셸 실행), 파일시스템 호스팅과 버전 관리·실행·체크포인트, 그리고 TUI 렌더링이다. 핵심인 에이전트 루프는 특별하지 않다. 컨텍스트를 조립하고 모델을 호출하고 응답을 파싱해 도구 호출로 넘긴다. Simon Willison의 표현으로는 "모델을 둘러싼 스캐폴딩"이다.

눈에 띄는 세부는 따로 있다.

• 시스템 프롬프트가 그대로 공개됐다. prompt.md와 subagent_prompt.md 템플릿이 저장소에 들어 있어, Grok Build가 모델에 어떻게 지시하는지 직접 읽을 수 있다.
• 터미널용 Mermaid 렌더러가 포함됐다. 다이어그램을 Unicode 박스 문자로 그려 터미널에 표시한다.
• 확장 시스템은 skills, plugins, hooks, MCP 서버, 서브에이전트를 지원한다. 이 구성은 크롬을 빌리지 않는 격리 샌드박스로 내장 브라우저를 붙인 Claude Code나 다른 에이전트 하네스와 비교해 읽을 만하다.

가장 논쟁적인 대목은 도구의 출처다. Grok Build의 여러 도구는 경쟁사 오픈소스 에이전트에서 이식됐다. Codex의 apply_patch와 grep_files, OpenCode의 bash·edit·glob·read가 그렇다. xAI는 이를 숨기지 않고 THIRD_PARTY_NOTICES.md에 문서화했다. 라이선스상 문제는 없지만 "자체 개발" 이미지와는 거리가 있다.

삭제되지 않은 업로드 코드

투명성을 내세운 공개인데, 정작 문제의 코드가 그대로 남았다. Simon Willison을 비롯한 복수 관측자가 클라우드 업로드 기능의 잔재가 코드베이스에 비활성화 상태로 남아 있다고 지적했다. 기능은 꺼졌지만 코드는 지워지지 않았다. TechTimes는 이 상황을 "저장소를 유출하는 코드는 그대로 남았다"는 제목으로 요약했다.

기술적으로 비활성화된 코드가 곧바로 위험한 것은 아니다. 하지만 신뢰 사고를 수습하려는 공개에서, 그 사고를 일으킨 코드를 제거하지 않고 남겨 둔 선택은 "완전한 투명성"이라는 명분과 어긋난다. 코드가 남아 있으면 설정이나 빌드에 따라 다시 켜질 여지도 검토 대상이 된다.

개발 이력도 보이지 않는다. 공개 시점 저장소는 단일 초기 커밋으로 시작했다. 실제로 이 코드가 어떻게 만들어졌는지, 언제 업로드 기능이 들어갔는지 커밋 기록으로는 추적할 수 없다. 오픈소스라는 형식은 갖췄지만 코드의 과거는 여전히 닫혀 있다.

열었지만 잠갔다

공개의 조건도 일반적인 오픈소스와 다르다. Grok Build 저장소는 포크와 수정을 허용한다. 하지만 커뮤니티가 참여할 통로는 막혀 있다.

버그를 발견해도 신고할 이슈 트래커가 없고 고쳐서 보내도 병합될 PR 통로가 없다. 코드를 읽고 각자 포크해서 쓰라는 구조다. 공개 나흘 만에 저장소는 별 1만 6천 개, 포크 약 3천 개를 넘겼지만 기여자는 1명, 열린 이슈는 0으로 집계됐다. 이미 텔레메트리와 브랜딩을 걷어낸 커뮤니티 포크(thedavidweng/gork-build)도 등장했다. 업스트림이 닫혀 있으니 개선은 포크에서 일어난다.

개발자에게 남는 것

Grok Build 공개는 두 가지로 읽힌다. 하나는 학습 자료로서의 가치다. 상용 코딩 에이전트의 하네스 전체가, 시스템 프롬프트와 도구 구현까지 포함해 통째로 열린 사례는 드물다. 에이전트 루프를 어떻게 짜고 도구를 어떻게 붙이고 승인 흐름과 diff 뷰어를 어떻게 만드는지 실제 코드로 볼 수 있다. 코딩 에이전트를 직접 만들거나 ARC-AGI-3에서 하네스만 바꿔 점수를 끌어올린 사례처럼 하네스 자체를 연구하는 쪽에는 참고 자료가 된다.

다른 하나는 신뢰 문제다. 이 공개는 도구가 사용자 파일을 몰래 올린 사고에서 출발했다. 코드를 열어 확인 가능하게 만든 것은 옳은 방향이지만 문제의 업로드 코드를 지우지 않고 남겨 두고 개발 이력도 감춘 채로 열었다. 코딩 에이전트에 파일시스템과 셸 접근 권한을 통째로 넘기는 것이 기본값이 된 지금, "이 도구가 내 코드로 무엇을 하는가"는 모델 성능만큼 중요한 질문이 됐다. Grok Build 사건은 그 질문을 코드 레벨에서 던지게 만든다. 소스가 공개됐다는 사실보다, 왜 공개해야 했는지가 더 오래 남을 사건이다.