xAI가 자사 코딩 에이전트 Grok Build의 소스를 오픈소스(Apache 2.0)로 공개했다. Rust로 작성된 풀스크린 TUI로, 코드베이스를 이해하고 파일을 편집하고 셸을 실행하고 웹을 검색하고 장기 작업을 관리한다. Claude Code, Codex, OpenCode에 이어 또 하나의 '터미널 코딩 에이전트'다.

그냥 '또 나왔네' 하고 넘길 수도 있다. 그런데 저장소를 열어보면, 요즘 코딩 에이전트 판이 어디로 수렴하는지가 꽤 선명하게 드러난다. 세 가지가 눈에 띈다.

1. '하네스'가 크레이트 단위로 분리돼 있다

지난 글에서 '하네스 = 모델을 감싸 실제 작업을 돌리는 껍데기'라고 했는데, Grok Build는 그 하네스를 역할별 크레이트로 깔끔하게 쪼개 놨다.

모델은 갈아끼우는 부품이고, 진짜 제품은 이 껍데기의 설계라는 관점이 코드 구조에 그대로 박혀 있다. TUI·런타임·툴·워크스페이스를 분리했다는 건, 하네스가 이제 하나의 독립된 엔지니어링 대상이 됐다는 뜻이다.

2. 세 가지 실행 모드, 그리고 ACP

Grok Build는 한 가지 방식으로만 돌지 않는다.

• 인터랙티브(TUI) — 사람이 앞에 앉아 대화하는 기본 모드
• 헤드리스(headless) — 스크립팅·CI 파이프라인에 끼워 넣는 모드
• 에디터 임베드 — Agent Client Protocol(ACP)로 에디터 안에서 구동

특히 헤드리스와 ACP가 중요하다. 헤드리스는 에이전트를 '사람 앞의 챗봇'에서 'CI의 한 단계'로 끌어내리고, ACP는 에디터에 에이전트를 꽂는 표준 인터페이스다. MCP가 툴 연결의 표준이 되어가듯, 에이전트-에디터 연결도 표준으로 수렴하고 있다는 신호다.

3. 가장 솔직한 부분 — Codex와 OpenCode를 이식했다

저장소의 THIRD-PARTY 공지에는 이런 문장이 있다. Grok Build의 툴 구현 일부가 openai/codex와 sst/opencode에서 이식(port) 됐다는 것.

즉 xAI조차 파일 편집·검색·터미널 실행 같은 툴 레이어를 처음부터 만들지 않았다. 경쟁 진영의 오픈소스 구현을 그대로 가져다 썼다. 이게 '하네스 상품화'의 가장 확실한 증거다. 툴은 이제 차별점이 아니라, 남의 걸 이식해도 되는 공용 부품이 됐다.

'오픈소스'라는 단어도 뜯어볼 만하다

다만 이건 커뮤니티가 함께 만드는 오픈소스가 아니다. 외부 기여는 받지 않고(CONTRIBUTING), 내부 모노레포에서 주기적으로 동기화되며, 루트 Cargo.toml은 자동 생성이라 수정 금지다. 라이선스는 열려 있지만, 개발의 방향타는 닫혀 있다.

여기서 '오픈소스'는 협업이 아니라 투명성·신뢰·락인 방지의 언어에 가깝다. 코드를 공개해 채택과 신뢰를 얻되, 키는 쥐고 있는 것. 큰 회사가 오픈소스를 전략적으로 쓰는 전형적인 방식이다.

마무리 — 껍데기가 같아지면, 승부는 그 위와 바깥으로

Grok Build 하나가 특별해서가 아니다. 세 신호 — 하네스의 모듈화, ACP 같은 표준화, 툴 레이어의 상호 이식 — 이 같은 방향을 가리킨다. 코딩 에이전트의 껍데기는 빠르게 공용 부품이 되고 있고, 진짜 승부는 그 **위(모델 품질)**와 그 **바깥(워크플로·CI 통합)**으로 밀려나고 있다.

모두가 비슷한 껍데기를 갖게 되면, 차별점은 껍데기 자체가 아니라 그걸 어디에 어떻게 꽂느냐로 옮겨간다.

설치는 한 줄이다. 직접 열어보면 위 이야기가 더 잘 보인다.

1
2
curl -fsSL https://x.ai/cli/install.sh | bash
grok --version

---

참고 자료

• xai-org/grok-build (GitHub)
• Grok Build 문서 — docs.x.ai/build