그록 빌드 기획력 논란, 클로드 코드 워커로 쓰는 이유

클코단에서 Grok을 실제로 어디에 쓰냐는 질문이 나왔다. 데스크톱 앱조차 없는 도구를 다른 프로그램에 어떻게 연결하냐는 질문과, Grok Build를 써봤더니 기획력이 얕아서 클로드 코드의 보조 작업자로 돌린다는 경험담이 뒤섞였다. xAI가 5월에 내놓은 터미널 코딩 에이전트 Grok Build는 실제로 어떤 도구일까. 기획은 약하고 실행은 쓸 만하다는 평가가 벤치마크와 외부 리뷰에서도 겹치는지 짚어본다.

데스크톱 앱이 없다는 게 무슨 뜻인가

xAI는 Grok 자체의 공식 데스크톱 앱을 내놓지 않았다. 공식 인터페이스는 grok.com 웹과 iOS·안드로이드 앱, X(트위터) 안의 챗봇이다. 대신 개발자용으로는 5월 14일 베타로 공개한 터미널 상주형 CLI, Grok Build가 있다. macOS·리눅스는 curl 설치 스크립트로, 윈도는 파워셸 스크립트로 깐다. 처음 실행할 때 브라우저 인증을 거치거나 XAI_API_KEY 환경변수를 넣으면 된다.

GUI 없이 로컬 프로세스로 돌아가는 구조라, 방에서 나온 다른 도구와 연결해 쓴다는 접근은 이 CLI를 다른 CLI나 스크립트 파이프라인에 물리는 방식과 정확히 맞아떨어진다. Grok Build는 외부 MCP 서버와 플러그인을 연결해 GitHub·Notion·Linear 같은 서비스를 이용할 수 있다. /mcps 메뉴에서 서버를 골라 인증하면 토큰이 로컬 파일에 저장된다. 데스크톱 앱 없이도 클라우드 서비스 여러 개를 터미널 하나에서 다루는 그림이 된다.

Grok Build가 실제로 하는 일

Grok Build는 계획을 검토한 뒤 작업을 실행할 수 있다. 파일을 건드리기 전에 단계별 계획을 제시하고 사용자가 승인하거나 개별 단계를 고쳐 쓸 수 있는 Plan Mode를 지원한다. 여기에 최대 8개의 서브에이전트를 격리된 깃 워크트리에서 동시에 돌리는 멀티 에이전트 구조를 얹었다. 8월 12일부터는 기본 모델이 Grok 4.6으로 바뀌면서 컨텍스트 창이 50만 토큰까지 늘었다.

Grok Build는 7월 15일 러스트 소스코드를 아파치 2.0 라이선스로 공개했다. 다만 외부 풀리퀘스트는 받지 않고 깃허브 이슈도 막아놓았다. 코드를 읽고 셀프 컴파일할 수는 있어도 커뮤니티가 함께 고쳐나가는 프로젝트는 아니다.

기획력이 얕다는 평가, 벤치마크로 보면

기획력이 부족하다는 방의 경험담은 외부 리뷰에서도 비슷하게 반복된다. Plan Mode 자체는 단계별 승인 구조가 잘 짜였다는 평이 많다. 다만 실제 실행 단계에서 거친 판단이나 컨텍스트 관리 미흡을 지적하는 리뷰가 여럿이다. 계획을 세우는 틀은 갖췄는데, 그 틀 안에서 내리는 판단의 질이 떨어진다는 이야기다.

수치로도 격차가 확인된다. Grok Build의 이전 모델인 grok-code-fast-1은 SWE-bench Verified에서 70.8%를 기록했다. 현재 xAI 문서에서 grok-code-fast-1은 grok-build-0.1의 별칭으로 안내된다. 같은 기준에서 앤스로픽이 공개한 클로드 Opus 4.7 점수는 87.6%다. 세 수치 모두 각 회사가 자체 하니스로 잰 것이어서 그대로 줄 세우긴 어렵다는 단서가 붙는다.

가격 구조도 실행 도구 쪽으로 쓰임이 몰리는 이유 중 하나로 꼽힌다. Grok Build는 무료로 체험할 수 있고 SuperGrok 등 유료 플랜에서는 더 높은 사용량을 제공한다. Grok 4.6은 월 30달러 SuperGrok에 포함되고, 클로드 코드는 월 20달러 클로드 프로에 포함된다. 반면 API로 직접 붙이면 grok-build-0.1은 입력 100만 토큰당 1달러, 출력 100만 토큰당 2달러다.

워커로 돌린다는 접근이 실제로 성립하는가

클로드 코드에서 Grok Build에 작업을 맡기려면 CLI나 플러그인 같은 연결 수단이 필요하다. Grok Build와 클로드 코드, 코덱스 CLI는 모두 SKILL.md 포맷을 그대로 읽는다. 한쪽에서 만든 스킬 패키지를 프로젝트의 .grok/skills나 ~/.grok/skills에 넣으면 다음 세션부터 Grok Build가 그대로 인식한다. 클로드 코드 쪽에서 짠 스킬과 플레이북을 Grok Build로 그대로 옮겨 실행만 맡길 수 있다.

다만 두 도구의 멀티 에이전트 철학은 다르다. Grok Build는 기본값 자체가 최대 8개 에이전트를 동시에 띄우는 구조다. 클로드 코드의 서브에이전트는 오케스트레이터가 작업을 맡기고 결과를 받아 종합하는, 보내고 잊는(fire-and-forget) 방식에 가깝다. 방의 접근처럼 클로드 코드를 지휘자로 두고 Grok Build를 실행 담당으로 붙이는 조합은, 계획은 잘 짜지만 비싼 도구와 실행은 되지만 계획이 얕고 값이 싼 도구를 역할별로 나눠 쓰는 셈이다.

이런 조합에 신중해야 할 이유도 있다. 스탠퍼드대 연구에서는 두 코딩 에이전트가 같은 작업을 함께 처리했을 때, 각자 따로 작업할 때보다 결과가 나빠지는 사례가 확인됐다. 여러 에이전트를 엮어 쓰는 개발자들 사이에서는 에디터용 에이전트 하나와 터미널용 에이전트 하나를 역할이 겹치지 않게 짝짓는다. 결제 전에 한 달씩 따로 써보라는 조언도 흔하다. Grok Build를 워커로 쓰는 접근이 통하려면, 클로드 코드가 계획을 완전히 확정한 뒤 Grok Build에는 이미 정해진 작업만 좁게 맡기는 경계가 필요하다는 뜻이다.

남는 질문은 그 경계를 얼마나 좁게 그을 수 있느냐다. Grok Build에 무엇을 할지까지 맡기면 방에서 나온 얕은 기획력이 그대로 결과물에 묻어난다. 이미 정해진 작업을 어떻게 처리할지만 맡기면, 저렴한 값에 병렬 실행력을 붙이는 조합이 된다.