터미널에서 작동하는 코딩 에이전트(Coding Agent)의 내부를 행수까지 전부 읽을 수 있는 날이 올 줄은 몰랐다. 7월 15일, xAI가 자사의 grok 커맨드의 실체인 Grok Build를 Apache 2.0 라이선스로 GitHub에 통째로 공개했다. Rust로 작성된 코드는 Simon Willison이 직접 만든 SLOCCount로 계산한 결과, 공백과 주석을 제외하고 84만 4,530행에 달하며, 그중 외부 유래(vendored) 코드는 약 3%뿐이라고 한다(simonwillison.net). 비교하자면 그는 OpenAI의 Codex CLI를 약 95만 행으로 추정하고 있다. "터미널 코딩 에이전트는 내가 생각했던 것보다 훨씬 복잡했다"라는 그의 한마디가 이번 공개의 의미를 잘 나타내고 있다.

"코딩 에이전트"라고 한데 묶어 말하기 쉽지만, 그 내부가 단순히 모델로의 API 호출만 있는 것은 아니다. 컨텍스트(Context) 구성, 도구 호출(Tool Call)의 파싱과 실행, 파일 편집의 차분(Diff) 관리, 장시간 태스크의 지속, 그리고 스크롤과 모달을 갖춘 전체 화면 TUI(Text User Interface)까지, 눈에 띄지 않는 방대한 배관(Plumbing) 작업이 필요하다. Grok Build는 이러한 배관 작업을 통째로 읽을 수 있는 최초의 "실제 운영 중인" 에이전트에 가깝다.

리포지토리는 crates/codegen/ 아래에 Rust 크레이트(Crate)로 나누어져 있다. TUI 본체가 xai-grok-pager, 에이전트 실행 시와 헤드리스(Headless) 진입점이 xai-grok-shell, 파일 편집·검색·터미널 실행과 같은 도구군이 xai-grok-tools, 호스트의 파일 시스템이나 버전 관리·체크포인트를 다루는 것이 xai-grok-workspace, 이들을 묶어 바이너리 xai-grok-pager-bin(grok이라는 배포명 사용)을 만드는 것이 xai-grok-pager-bin이라는 구성으로 되어 있다.

작동 방식은 세 가지가 준비되어 있다. 평소 사용하는 전체 화면 대화형 TUI, CI나 스크립트에서 호출하는 헤드리스 모드, 그리고 에디터에 통합하기 위한 Agent Client Protocol(ACP)을 경유하는 방식의 3개 계통이다. ACP는 에디터 측과 에이전트 측을 느슨하게 결합(Loosely coupled)하는 공통 프로토콜로, 이를 지원하면 특정 에디터 확장을 직접 작성하지 않아도 여러 에디터에서 동일한 에이전트를 호출할 수 있다. 확장성도 넓어 MCP 서버, 스킬, 플러그인, 훅(Hook), 서브 에이전트를 삽입할 수 있다.

설치는 원라이너(One-liner)로 끝난다.

curl -fsSL https://x.ai/cli/install.sh | bash

소스에서 빌드하려면, 고정된(Pinned) Rust 툴체인과 protoc를 설치한 후 cargo build -p xai-grok-pager-bin --release를 실행한다.

엔지니어로서 직접 다루는 입장에서 볼 때, 공개 라이선스보다 더 효과적인 것은 설정 파일의 구조다. ~/.grok/config.toml (Windows는 %USERPROFILE%\.grok\config.toml)에서 모델을 정의할 수 있으며, base_url을 자유롭게 지정할 수 있다(docs.x.ai). 즉, Grok에 얽매이지 않고 OpenAI 호환 엔드포인트라면 무엇이든 연결할 수 있다.

[model.local]
model = "your-model-id"
base_url = "http://localhost:8000/v1"
...

base_url을 로컬의 vLLM이나 기타 추론 서버로 향하게 하면, 이 정교하게 다듬어진 TUI와 에이전트 루프를 자체 모델로 실행할 수 있다. 헤드리스 모드도 동일한 설정을 공유한다.

grok -p "이 리포지토리의 테스트를 실행하고 실패 내용을 요약해줘"
grok -p "변경점을 리뷰해줘" --output-format streaming-json
grok -p "..." -m local

대화 중에는 /model <name>으로 모델을 전환할 수 있으며, grok inspect...

를 입력하면 해당 디렉토리에서 감지된 설정(Settings), 지시(Instructions), 스킬(Skills), 플러그인(Plugins), 훅(Hooks), MCP 서버 목록을 확인할 수 있다. 개인적으로 이 공개의 실질적인 이득은 바로 이 지점이라고 생각한다. 에이전트의 UX와 모델 제공처가 분리되어 있기 때문에, "TUI와 도구 실행은 xAI의 완성도를 그대로 빌려 쓰고, 두뇌는 로컬이나 선호하는 API로 교체한다"라는 조합이 성립한다. CLI 에이전트를 밑바닥부터 직접 만들려다 복잡한 배관 작업(Plumbing)의 양에 좌절해 본 경험이 있다면, 이 84만 행의 코드는 그대로 참조 구현(Reference Implementation)이 될 것이다.

다만, 무조건적으로 찬양할 만한 이야기는 아니다. 라이선스는 Apache 2.0으로 이용, 수정, 재배포가 자유롭지만, CONTRIBUTING 규정에 따라 외부에서의 풀 리퀘스트(Pull Request)나 무단 패치는 받지 않는다. xAI는 내부 모노레포(Monorepo)에서 이 공개 트리로 정기적으로 동기화하는 방식으로 운영하며, 실질적으로는 "읽고 포크(Fork)할 수는 있지만, 업스트림(Upstream)에는 합류할 수 없는" 소스 공개에 가깝다. 버그를 수정하더라도 본가에는 되돌릴 수 없으며, 포크하여 유지하는 수밖에 없다.

또 다른 점은 애초에 왜 전면 공개를 결정했는가 하는 배경이다. Willison의 분석에 따르면, Grok Build는 이전에 디렉토리 전체를 명확한 동의 없이 Google Cloud로 업로드하는 동작이 문제시되었으며, xAI는 해당 기능을 무효화한 후 코드를 공개했다. 신뢰를 회복하기 위한 움직임이라는 해석이며, 실제로 공개된 코드에는 GCS 업로드의 잔재가 하드코딩된 에러를 반환하는 형태로 남아 있다고 한다. 투명성이 "보여주고 싶어서 보여주는 것"인지, 아니면 "보여줄 수밖에 없게 된 것"인지에 따라 받아들이는 방식은 달라진다.

코드를 살펴보면, 도구 구현의 일부는 Codex나 OpenCode와 같은 다른 에이전트로부터 가져온 흔적이 있어, 이 분야의 설계가 급격히 수렴하고 있음을 알 수 있다. Mermaid 다이어그램을 유니코드(Unicode) 테두리를 사용하여 터미널 내에 그리는 자체 렌더러(Renderer)와 같은 잔기술도 포함되어 있어, 읽을거리로서도 흥미롭다. 완벽하게 개방된 것은 아니지만, 프로덕션급 에이전트의 내부를 1차 자료로서 얻을 수 있다는 점은 의미가 크다. 적어도 다음에 직접 에이전트를 구축할 때 시행착오를 확실히 줄일 수 있을 것이다.

참조한 1차 소스: