본문으로 건너뛰기

Grok Build 내부 들여다보기: 오픈 에이전트 하니스 읽기

고급

2026년 7월 14–16일, xAI는 자사 CLI 뒤에 있는 코딩 에이전트인 Grok Build를 xai-org/grok-build에서 공개 Apache 2.0 저장소로 공개했다. 가중치가 아니다. 바로 그 하니스다 — 에이전트 루프, 툴 구현, 터미널 UI, 확장 시스템. 몇 시간 만에 Hacker News 첫 페이지에 올랐다.

이것은 보기 드문 산물이다. 진지한 코딩 에이전트는 거의 전부 — Claude Code, Cursor, Codex — 바이너리나 번들 형태로 배포된다. 여기서는 약 80만 줄의 프로덕션 Rust 코드가 읽을 수 있는 저장소에 놓여 있다. 그것은 제품으로서보다 교과서로서 더 가치가 있다.

이 페이지는 실용적인 읽기다: 실제로 그 안에 무엇이 있는지, 그 구조가 에이전트 구축에 대해 무엇을 가르쳐 주는지, 그리고 대부분의 보도가 거꾸로 짚은 이 공개에 관한 두 가지다.

What you'll learn
  • 무엇이 공개되었고 무엇이 공개되지 않았는지 이해하기 — 하니스는 예, 가중치는 아니오, 개발 이력도 아니오
  • 크레이트 맵을 프로덕션 코딩 에이전트가 실제로 필요로 하는 것의 체크리스트로 읽기
  • 여기서 Apache 2.0이 왜 오픈 개발이 아니라 소스 공개(source-available)를 의미하는지 배우기 — 그리고 그 구분이 왜 결정적인지
  • 공개된 트리에 여전히 존재하는 데이터 수집기 코드를 살펴보고, 그 상수들이 7월 유출 사건에 관해 무엇을 확인해 주는지 알기
  • 이 저장소에서 진짜로 재사용할 수 있는 것과 막다른 길인 것을 알기

실제로 공개된 것​

저장소는 99% 이상이 Rust이고, Apache 2.0으로 라이선스되어 있으며, 스스로를 코딩 에이전트 하니스이자 TUI — 전체 화면, 마우스 상호작용 가능, 확장 가능 — 라고 설명한다. 고정된 Rust 툴체인으로 macOS와 Linux에서 빌드된다.

그것이 아닌 세 가지:

  • 모델이 아니다. Grok 4.5의 가중치는 여기 없고 공개되지도 않았다. 하니스는 호스팅된 엔드포인트와 통신한다. 에이전트가 당신의 코드베이스에 대해 어떻게 생각하는지 모든 줄을 읽을 수 있지만, xAI의 API 없이는 여전히 실행할 수 없다.
  • 개발 이력이 아니다. 저장소에는 커밋이 두 개 있다: Publish harness and TUI open-source, 그다음 Synced from monorepo. 루트에는 내부 리비전 해시 하나가 담긴 SOURCE_REV 파일이 있다. 이것은 비공개 모노레포의 익스포트로, 주기적으로 다시 동기화된다 — 공개적으로 개발된 저장소도 아니고, 설계 결정을 고고학처럼 파헤칠 수 있는 저장소도 아니다.
  • 당신에게 열려 있지 않다. CONTRIBUTING.md는 저장소가 외부 풀 리퀘스트나 원치 않는 패치를 받지 않으며, xAI가 소프트웨어를 내부적으로 개발하고, 트리는 "소스 투명성과 로컬 빌드를 위해" 공개된다고 명확하게 밝히고 있다. GitHub 이슈는 저장소 수준에서 비활성화되어 있다.

★ 중요한 구분: Apache 2.0은 라이선스이며, 당신에게 실질적인 권리를 부여한다 — 읽기, 포크, 수정, 파생물 배포. 그것은 거버넌스에 대해서는 아무 말도 하지 않는다. Grok Build는 **폐쇄적 개발 모델을 가진 오픈 소스 라이선스 하의 소스 공개(source-available)**다. 포크할 수는 있지만, 영향을 줄 수는 없다. 헤드라인의 "오픈 소스"를 "소스를 읽을 수 있다"로 읽어라. 정확히 그리고 오직 그것만이 제공되는 것이기 때문이다.

진짜 교훈은 크레이트 맵이다​

마케팅은 무시하라. crates/codegen/ 아래의 디렉터리 목록이 이 저장소에서 가장 유용한 것인데, 배포되는 코딩 에이전트가 무엇을 필요로 하는지에 대한 정직한 인벤토리이기 때문이다. 일부를 뽑아 보면:

크레이트무엇을 말해 주는가
xai-grok-agent, xai-grok-shell에이전트 런타임과 그 진입점들 — 인터랙티브, stdio, 헤드리스
xai-grok-tools, xai-grok-tools-api툴 구현을 툴 인터페이스에서 분리 — 진짜 경계
xai-grok-workspace, xai-fast-worktree파일시스템, 버전 관리, 실행, 체크포인트 — 그리고 빠른 git worktree
xai-codebase-graph단순한 grep이 아니라 저장소의 구조적 이해
xai-grok-memory메모리는 프롬프트 트릭이 아니라 하나의 서브시스템
xai-grok-mcpMCP는 일급(first-class) 통합 표면
xai-grok-hooks, xai-hooks-plugins-types훅과 플러그인은 자체 타입 레이어를 가진다
xai-grok-subagent-resolution어떤 서브에이전트가 무엇을 처리하는지 결정하는 것은 자체 크레이트가 필요할 만큼 어렵다
xai-token-estimation토큰을 쓰기 전에 세어 보기
xai-hunk-tracker편집 세션 전반에 걸쳐 diff 헝크(hunk) 추적하기
xai-grok-pager, xai-ratatui-inlineTUI — 스크롤백, 프롬프트, 모달, 인라인 렌더링
xai-acp-libAgent Client Protocol — 에디터가 에이전트를 임베드
xai-grok-telemetry, xai-mixpanel텔레메트리와 제품 분석, 일급 크레이트로서
ptyctl, xai-tty-utils, xai-grok-crash-handler터미널은 적대적이고 프로세스는 크래시한다

그 목록을 빌드 계획으로 다시 읽어 보라. 코딩 에이전트에 대한 순진한 멘탈 모델은 "모델을 호출하고 툴을 실행하는 루프"다. 실제 분해는 코드베이스 그래프, 메모리 서브시스템, 체크포인팅, worktree 관리, 헝크 추적, 서브에이전트 결정, 토큰 추정, 크래시 처리, PTY 제어 레이어를 포함한다 — 프롬프트 한 줄을 쓰기도 전에 말이다.

★ 규모 점검. Simon Willison은 트리에서 844,530줄의 Rust를 세었고, 그중 벤더링된 의존성은 ~3%에 불과했으며, OpenAI의 Codex가 대략 950,933줄에 이른다고 언급했다. 두 독립적인 팀이 "LLM 주위의 루프 하나"를 위해 100만 줄 가까이로 수렴한 것이다. 당신의 에이전트 프로젝트가 부풀어 오르는 것처럼 느껴진다면, 이것이 그 보정값이다: 당신 탓이 아니며, 어려운 부분은 애초에 루프가 아니었다.

xai-grok-mermaid 크레이트도 있다 — 유니코드 상자 그리기 문자로 Mermaid 다이어그램을 그리는 터미널 렌더러다. 중요하지는 않다. 배포용 마무리 손질(polish)이 어떤 진짜 에이전트에서든 큰 비중을 차지한다는 것을 상기시켜 주는 좋은 사례다.

데이터 수집기 코드는 여전히 트리에 있다​

여기서 저장소는 교과서이기를 멈추고 증거가 되기 시작한다.

2026년 7월, 한 연구자의 와이어 캡처는 Grok Build가 저장소 전체를 — 전체 git 이력, 한 번도 읽히지 않은 파일, .env 내용을 — 모델이 읽은 것과 무관한 채널을 통해 Google Cloud Storage 버킷으로 업로드하는 것을 보여 주었다. AILmanac은 그 사건과 일반적인 실패 양상을 에이전트가 무엇을 업로드하는가에서 다룬다. xAI는 서버 측에서 이 동작을 비활성화했고 보관된 데이터는 삭제될 것이라고 밝혔다.

공개된 소스에는 그 장치가 담겨 있다. 저장소에서 직접 검증 가능하다:

  • crates/codegen/xai-grok-shell/src/upload/gcs.rs가 존재한다.
  • crates/codegen/xai-file-utils/src/upload_config.rs는 DEDUP_GCS_PREFIX = "repo_changes_dedup"를 정의한다.

그 상수가 흥미로운 것이다. 연구자가 가로챈 업로드는 gs://grok-code-session-traces/repo_changes_dedup/v2/… 형태의 오브젝트 경로로 갔다. 와이어에서 캡처된 경로 접두사가 xAI 자신의 공개된 소스에 이름 붙은 상수로 있는 것이다. 같은 파일은 ARCHIVE_SCHEMA_VERSION(v2)과 ARCHIVE_SCHEMA_VERSION_V3를 모두 정의한다 — 즉 아카이브 포맷이 세 번째 버전까지 반복 개선되었다는 뜻이다. 이것은 떠도는 디버그 경로가 아니라 유지 관리되던 인프라였다.

gcs.rs의 모듈 문서는 어떤 보도자료보다도 더 노골적이다. 업로드 헬퍼들을 **"데이터 수집기 헬퍼(the data-collector helpers)"**라고 지칭하며, 이 파일이 존재하는 이유 전체가 엔지니어링 수정이다: 갱신을 인식하는(refresh-aware) 자격 증명을 엮어 넣어서 만료된 토큰이 POST /v1/storage 401을 일으키지 않도록 하는 것. 누군가가 프로덕션 작업으로 저장소 업로드 경로의 신뢰성을 디버깅하고 있었던 것이다.

Simon Willison은 업로드 경로가 이제 공개된 트리에서 비활성화되어 하드코딩된 에러를 반환한다고 보고한다. 이는 xAI가 밝힌 입장과 일치하며, 우리는 코드 검색으로 그 구체적인 메커니즘을 독립적으로 확인하지 못했다 — 여기서는 검증된 것이 아니라 보고된 것으로 취급하라.

★ 여기서 취할 것. "xAI가 유독 나쁘다"는 것이 아니다 — 보안 페이지의 더 넓은 교훈이 유효하다: 이런 종류의 채널은 어떤 형태로든 많은 에이전트에 존재하며, 소스를 읽는 것만이 알 수 있는 유일한 방법이다. 대신 메타적인 요점을 취하라: 이것이 소스 투명성이 실제로 존재하는 이유다. 바이너리의 데이터 흐름은 하루 오후에 감사할 수 없다. 공개된 트리에서 bucket_url을 grep하는 데는 약 10초면 된다. 이 공개는 정확히 불편한 부분들을 grep 가능하게 만들기 때문에 진정으로 가치 있다.

Check yourself

0/4
  1. xai-org/grok-build는 Apache 2.0으로 라이선스되어 있다. 이것이 상류(upstream)에 수정 사항을 기여하는 것에 대해 무엇을 말해 주는가?
  2. 저장소에는 커밋이 두 개 있고 루트에 해시 하나가 담긴 SOURCE_REV 파일이 있다. 이것은 무엇을 의미하는가?
  3. Grok Build 하니스는 대략 얼마나 크며, OpenAI Codex의 비교 수치는 얼마인가?
  4. upload_config.rs의 DEDUP_GCS_PREFIX 상수는 무엇을 확인해 주는가?

실제로 재사용할 수 있는 것​

포크하기 전에 제약에 대해 솔직해져라:

Guided walkthrough1 of 4
  1. 크레이트 경계는 실제 사용자에게 배포하는 자금이 넉넉한 팀의 산물이다. 그 분해 — tools를 tools-api에서 분리, workspace를 agent에서 분리, 서브에이전트 결정을 자체 관심사로 다룬 것 — 가 이전 가능한 자산이다. 거기서 Rust를 복사해 오는 것은 그 형태를 복사하는 것보다 훨씬 덜 준다.

빌드하지 않고 트리를 탐색하고 싶다면:

크레이트 구조를 클론하고 매핑하기

git clone --depth 1 https://github.com/xai-org/grok-build
cd grok-build

# The inventory of what a production coding agent needs
ls crates/codegen/

# Where does data leave the machine? Start here, not with the README.
grep -rn "bucket_url\|/v1/storage\|upload_bytes" crates/ --include=*.rs | head -30

# Which internal revision was this cut from?
cat SOURCE_REV

당신이 아는 것 옆에 어디에 자리하는가​

당신이 Claude Code를 몰고 다닌다면, Grok Build는 내부가 드러난 같은 범주의 도구다 — 이미 겪고 있는 문제들에 대한 제2의 의견으로 읽어라. 코딩 에이전트 CLI 비교는 이것을 경쟁 진영에 견주어 놓고, Claude 사용자를 위한 Grok은 그 주위의 xAI 생태계를 다룬다.

크레이트 맵이 가리키는 아키텍처 아이디어에 대해서는 장기 실행 에이전트 하니스와 에이전트 메모리 아키텍처를 보라 — xai-grok-memory와 xai-grok-subagent-resolution은 정확히 그 문제들에 대한 한 팀의 답이다.

그리고 에이전트가 무엇을 업로드하는가를 이 페이지와 함께 읽어라. 그쪽은 mitmproxy와 카나리아 저장소로 이런 채널을 와이어에서 잡아내는 방법을 보여 준다. 이쪽은 그것이 소스에서 어떻게 보이는지를 보여 준다. 두 기법을 합치면 감사 전체가 된다.

출처 및 더 읽을거리​