그록 빌드 해부 — SpaceXAI가 연 코딩 하네스, 도구층은 코덱스·오픈코드 포트 위에 섰다

세 줄 요약

그록 빌드는 러스트로 짠 전체 화면 TUI 코딩 에이전트다. 코드베이스 이해·파일 편집·셸 실행·웹 검색·장기 실행 작업을 대화형, 헤드리스(CI), 에디터 임베드(ACP)의 세 가지 모드로 굴린다. ✔ 원문

first-party 코드는 Apache 2.0이지만 단일 라이선스가 아니다. 도구 구현에 openai/codex와 sst/opencode의 인트리 소스 포트가 들어 있고, README가 이를 명시한다. ✔ 원문

단, 외부 기여는 받지 않고 모델도 함께 열린 게 아니다. "쓰는 도구"보다 하네스 설계를 읽는 교재로 접근할 때 남는 게 많다.

무엇이 열렸나

WHAT SHIPPED

그록 빌드는 SpaceXAI(README·LICENSE의 자기 표기. 저장소 조직명은 xai-org다)의 터미널 기반 AI 코딩 에이전트다. README의 첫 문단이 성격을 압축한다 — 코드베이스를 이해하고, 파일을 편집하고, 셸 명령을 실행하고, 웹을 검색하고, 장기 실행 작업을 관리하는 전체 화면 TUI. 실행 방식은 세 갈래다: 대화형, 스크립팅·CI를 위한 헤드리스, 그리고 에이전트 클라이언트 프로토콜(ACP)을 통한 에디터 임베드. ✔ 원문

공개된 것은 grok CLI/TUI와 그 에이전트 런타임의 러스트 소스다. 이 저장소는 SpaceXAI 모노레포에서 주기적으로 동기화되며, 루트의 SOURCE_REV 파일이 이 트리에 해당하는 모노레포 커밋 SHA를 기록한다. ✔ 원문 즉 이 저장소는 개발이 일어나는 곳이 아니라 내보내진 스냅샷이다. 확보 시점 기준 커밋이 17개뿐인 이유이기도 하다.

용어헤드리스(headless) 모드가 뭔가요?▶

평소 Claude Code를 쓸 때는 터미널 화면에 대화가 흐르고, 중간에 사람이 끼어들어 방향을 바꿉니다. 헤드리스는 그 화면과 사람을 뺀 실행 모드입니다. 명령 한 줄로 작업을 던지면 에이전트가 알아서 끝내고 결과만 돌려줍니다.

왜 필요하냐면, 이래야 에이전트를 다른 프로그램이 부를 수 있기 때문입니다. CI 파이프라인에서 "PR이 올라오면 에이전트가 리뷰하게" 같은 자동화는 전부 헤드리스 모드 위에 올라갑니다. 사람이 봐야 하는 UI가 없으니 스크립트가 곧 사용자입니다.

GUI 프로그램과 CLI의 관계입니다. 포토샵을 손으로 여는 대신 이미지 변환 명령을 스크립트에 넣어 1,000장을 한 번에 처리하는 것 — 같은 기능이지만 부르는 주체가 사람에서 프로그램으로 바뀝니다.

※ 이 카드는 일반 개념 설명이다. 그록 빌드의 구체 구현·옵션은 본문의 소스 등급을 따른다.

계층	구성 (저장소 구조 기준)	등급	실무자 관점 메모
TUI	xai-grok-pager — 스크롤백, 프롬프트, 모달, 렌더링	✔ 원문	바이너리 아티팩트 이름이 xai-grok-pager이고 공식 설치본만 grok으로 배포된다. 내부 명칭이 "페이저"라는 점이 이 도구의 원형을 드러낸다
에이전트 런타임	xai-grok-shell — 런타임 + leader/stdio/헤드리스 진입점	✔ 원문	진입점이 세 갈래로 갈린 구조. 대화형과 헤드리스가 같은 런타임을 공유한다는 뜻 — 자작 에이전트에서도 UI와 루프를 분리해야 CI에 꽂을 수 있다
도구 계층	xai-grok-tools — 터미널, 파일 편집, 검색 등	✔ 원문	이 크레이트가 이 글의 핵심. codex·opencode 포트가 들어 있는 지점이며, 크레이트 로컬 THIRD_PARTY_NOTICES가 별도로 붙어 있다
워크스페이스	xai-grok-workspace — 호스트 파일시스템, VCS, 실행, 체크포인트	✔ 원문	VCS와 체크포인트가 워크스페이스 계층에 함께 있다. 에이전트가 망친 상태를 되감는 장치를 도구가 아니라 기반 계층에 둔 설계
주변부	설정, MCP, 마크다운, 샌드박스 크레이트 클로저 + 벤더링된 Mermaid 스택	✔ 원문	샌드박스가 독립 크레이트로 존재한다는 사실까지는 원문 확인. 다만 실제 격리 강도·정책은 README에 없다 — 검증 노트의 대기 항목

도구층은 코덱스·오픈코드 포트 위에 섰다

THE PORTED TOOL LAYER

이 저장소에서 가장 흥미로운 문장은 기능 소개가 아니라 라이선스 절에 있다. README는 first-party 코드가 Apache 2.0이라고 밝힌 뒤, 제3자·벤더 코드는 원 라이선스를 유지한다며 THIRD-PARTY-NOTICES를 가리킨다. 그 목록에 인트리 소스 포트(in-tree source ports)가 있고, 괄호 안에 이름이 적혀 있다 — openai/codex와 sst/opencode의 도구 구현. ✔ 원문

더 구체적인 물증도 README가 직접 준다. 도구 크레이트에는 크레이트 전용 고지 파일이 따로 붙어 있고, 그 안에 "코덱스 및 오픈코드 포트에 대한 라이선스 전문 + Apache §4(b) 변경 고지"가 들어 있다고 명시한다. ✔ 원문 §4(b)는 아파치 라이선스에서 수정한 파일에는 수정했다는 표시를 남겨야 한다는 조항이다. 즉 가져다 쓴 정도가 아니라 고쳐서 썼고, 고쳤다고 문서로 남긴 상태다.

SpaceXAI는 이 사실을 숨기는 대신 README 최상위 라이선스 절에 적어 뒀다. ✔ 원문

여기서부터는 원문이 말한 사실이 아니라 편집자의 해석이다. 이걸 문제로 읽을 필요는 없다고 본다 — 허용 라이선스 코드를 고지와 함께 이식하는 것은 그 라이선스가 허용하는 행위다. 실무자에게 남는 함의는 도구 계층의 위상 변화라고 본다. 파일 편집·검색·터미널 실행 같은 도구는 각자 처음부터 짜는 영역이라기보다, 잘 만들어진 구현을 가져와 자기 런타임에 맞추는 영역으로 이동하는 중으로 읽힌다. 다만 이는 저장소 한 곳의 라이선스 절에서 끌어낸 추론이며, 업계 전반의 경향으로 확인한 바는 없다.

용어인트리 소스 포트(in-tree source port)가 뭔가요?▶

남의 오픈소스를 쓰는 방법은 크게 둘입니다. 하나는 의존성으로 부르기 — package.json이나 Cargo.toml에 이름을 적고 빌드할 때 내려받는 방식입니다. 다른 하나는 소스를 내 저장소 안으로 복사해 넣기입니다. 후자를 인트리(in-tree, 내 트리 안)라고 부르고, 그러면서 내 코드 스타일·구조에 맞게 고치는 것을 포팅(porting)이라 합니다.

왜 굳이 복사하냐면, 버전이 마음대로 바뀌지 않고 원하는 대로 뜯어고칠 수 있기 때문입니다. 대신 대가가 있습니다 — 원본이 버그를 고쳐도 자동으로 따라오지 않고, 원 라이선스와 고지 의무가 내 저장소 안까지 따라 들어옵니다. 그래서 이런 코드에는 별도 고지 파일이 붙습니다.

번역서와 원서의 관계에 가깝습니다. 원서를 서점에서 사 오는 대신(의존성), 내용을 내 책 안에 옮겨 싣고 문체를 고친 것(포트)입니다. 편해지는 대신 판권 표시를 내 책에 실어야 합니다.

※ 이 카드는 일반 개념 설명이다. 그록 빌드가 실제로 어느 파일을 어디까지 포팅했는지는 저장소의 THIRD-PARTY-NOTICES를 따르며, 본 기사는 그 목록을 대조하지 않았다(검증 노트 대기 항목).

열린 것과 열리지 않은 것

WHAT'S NOT IN THE BOX

오픈소스라는 단어에 기대를 싣기 전에 원문이 그은 선을 먼저 봐야 한다. README는 외부 기여를 받지 않는다고 노트 박스로 못박는다. ✔ 원문 코드는 읽고 고치고 빌드할 수 있지만, 고친 것을 위로 돌려보내는 경로는 닫혀 있다. 저장소가 모노레포에서 주기적으로 동기화되는 단방향 미러라는 구조상 자연스러운 귀결이기도 하다.

빌드 조건도 만만치 않다. 러스트 툴체인은 rust-toolchain.toml로 고정되어 자동 설치되지만, 그 전에 DotSlash를 먼저 깔아야 한다 — bin/ 아래의 밀폐형 도구(특히 protoc)가 내려받아 실행될 수 있게 하는 장치다. 빌드 호스트로 지원되는 것은 macOS와 리눅스이고, 윈도우 빌드는 best-effort이며 이 트리에서 테스트되지 않는다고 README가 밝힌다. ✔ 원문 배포 바이너리는 세 OS 모두 제공되므로, "쓰는 것"과 "소스에서 빌드하는 것"의 지원 범위가 다르다는 점을 구분해야 한다.

그리고 가장 큰 것 — 모델은 열리지 않았다. 이 저장소에 담긴 것은 하네스이지 가중치가 아니며, 첫 실행 시 브라우저가 열려 인증을 거친다. ✔ 원문 클라우드 모델 접근이 여전히 전제라는 서술은 2차 보도에서 일치하나 △ 보도, 대체 추론 백엔드를 어디까지 물릴 수 있는지는 원문에서 확인하지 못했다 — 문서(docs.x.ai)와 설정 크레이트 확인 후 확정한다.

실무 유의점

FIELD NOTES — 자작 에이전트 운영자 기준

CV-01UI와 런타임을 쪼개야 CI에 꽂힌다 ✔ 원문

그록 빌드는 TUI(pager)와 에이전트 런타임(shell)이 별도 크레이트이고, 런타임 쪽에 leader/stdio/헤드리스 세 진입점이 붙어 있다. 대화형 UI와 자동화 실행이 같은 루프를 공유하도록 설계됐다는 뜻이다. 자작 에이전트에서 루프 코드가 화면 출력과 얽혀 있다면, CI·크론에 얹는 순간 전부 다시 짜야 한다. 진입점부터 분리할 것.

CV-02되감기는 도구가 아니라 기반 계층에 둔다 ✔ 원문

체크포인트가 도구 크레이트가 아니라 워크스페이스 크레이트(호스트 파일시스템·VCS·실행과 한 묶음)에 있다. 에이전트가 망친 상태를 되돌리는 능력을 "도구 중 하나"로 두면 에이전트가 그걸 쓸지 말지 선택하게 된다. 기반에 두면 선택의 문제가 아니게 된다. 승인 게이트와 같은 논리다 — 지웠을 때 무엇이 막히는가로 판별하라.

CV-03도구층은 사 오고, 차별화는 런타임에서 낸다 ✔ 원문

SpaceXAI조차 도구 구현을 codex·opencode에서 포팅해 왔다(원문은 "도구 구현"이라고만 적었고 어느 도구인지는 밝히지 않는다 — THIRD-PARTY-NOTICES 대조 전, 검증 노트 대기 항목). 자작 에이전트를 만들며 도구 구현에 몇 주를 쓰고 있다면 우선순위를 의심할 만하다. 남이 만든 도구 구현을 라이선스 고지와 함께 이식하는 것은 정당한 선택지이고, 아낀 시간은 루프 통제·권한·검증처럼 대체 불가능한 곳에 쓰는 편이 낫다. 단, 이식할 땐 고지 의무가 따라온다는 것도 함께 배울 것.

CV-04"오픈소스"의 범위를 계약서처럼 읽어라 ✔ 원문

이 릴리스에서 열린 것은 하네스 소스이고, 닫힌 것은 모델·외부 기여·(사실상) 업스트림 개발 과정이다. 저장소는 모노레포의 주기적 스냅샷이며 SOURCE_REV가 그 시점을 기록한다. 사내 도입을 검토한다면 "오픈소스니까 괜찮다"가 아니라 어느 계층이 어느 라이선스로 열렸는지를 표로 정리해야 한다 — 이 저장소는 단일 라이선스가 아니다.

CV-05수치는 반드시 시점과 함께 ✔ 원문

확보 시점(2026-08-01 09:29 KST) 저장소 배지 기준 별 약 23.7k, 포크 4.5k, 커밋 17개다. 이 값들은 실시간으로 변한다. 이 매거진이 별 개수를 인용할 때 항상 시각을 붙이는 이유는 과거에 2차 소스의 별 개수가 실제와 크게 어긋난 사례를 기록했기 때문이다. 남의 글에서 본 숫자는 숫자가 아니라 소문이다.

검증 노트

LAB LOG — 이 매거진은 돌려본 것만 "검증됨"이라 부른다

loopnote — verify/grok-build STATUS: DOCS-VERIFIED · RUNTIME-PENDING

$ verify log grok-build
[ OK 08-01 ] README 전문 대조 — raw 직접 수집, 전문 완역 → 정본 CANON-002
[ OK 08-01 ] 라이선스 1차 확인 — LICENSE 헤더 Apache 2.0 (Copyright 2023-2026 SpaceXAI)
[ OK 08-01 ] 버전 고정 — SOURCE_REV 8d69c91f02bcacf01e98d5aebbf2f92547c45738
[ OK 08-01 ] 저장소 지표 직접 확인 — Apache-2.0 · Rust · main · 23.7k stars / 4.5k forks / 17 commits
[ PENDING ] 공식 발표문 확보 — x.ai/news HTTP 403, 대체 경로 재시도 (출시 연혁 △→✔ 승급용)
[ PENDING ] THIRD-PARTY-NOTICES 대조 — codex·opencode 포트의 실제 범위·파일 목록 확인
[ PENDING ] 소스 빌드 실측 — DotSlash + protoc 부트스트랩, cargo build 성공 여부·소요
[ PENDING ] 헤드리스 모드 실측 — CI에서 호출 가능한 최소 예제 확인
[ PENDING ] 샌드박스 정책 확인 — sandbox 크레이트의 실제 격리 강도
[ PENDING ] 모델 백엔드 확인 — 자체/로컬 추론 연결 가능 범위 (docs.x.ai + config 크레이트)

[ OK 08-02 ] 표기 정정 — 제목의 "xAI"를 원문 표기 "SpaceXAI"로 통일(데크와 어긋나 있었다. 1차 소스: README 본문·LICENSE 저작권줄·로고 파일명)

$ verify status
docs_verified=4/4 runtime_tested=0/6 corrections=1 # 결과는 이 글에 추기(追記)로 갱신한다

규칙: 배지는 [검증 대기 → 부분 검증 → 검증 완료] 3단계. 부분 검증 = 문서 검증 완료·실측 대기. 실측 없이 "좋다더라"는 쓰지 않는다.

어디에 꽂아 쓸까

WHERE IT FITS

도구로서의 그록 빌드는 이미 붐비는 자리에 들어왔다 — 터미널 코딩 에이전트는 2026년 현재 선택지가 넘친다. 하지만 하네스를 직접 짜는 입장이라면 이 릴리스의 값어치는 다른 데 있다. 상용 코딩 에이전트의 크레이트 경계를 그대로 볼 수 있다는 점이다. TUI와 런타임을 어디서 자를지, 진입점을 몇 개 둘지, 체크포인트를 어느 계층에 놓을지, 도구는 어디까지 남의 것을 가져와도 되는지 — 이 결정들은 블로그 글이 아니라 디렉터리 구조에 박혀 있고, 지금 그 구조가 열려 있다.