xAI Grok Build 등장 — 코딩 에이전트 3파전, 무엇이 실제로 달라지나 (2026)
8, 8, 그리고 2~4. 앞의 두 숫자는 제품 스펙이고 뒤의 하나는 측정 결과입니다.
Grok Build는 최대 8개의 서브에이전트를 동시에 띄웁니다. Cursor도 8개입니다. 그런데 작업 분할의 이득이 통합 비용을 넘어서는 지점을 실제로 측정한 연구에서 나온 숫자는 2~4개였습니다.
이 간극이 2026년 코딩 에이전트 경쟁의 실체를 꽤 정확하게 요약합니다. 병렬 수는 늘어나는데, 늘어난 만큼 빨라지지는 않습니다.
3파전이 된 배경
2026년 5월 14일, xAI가 Grok Build를 얼리 베타로 열었습니다. SuperGrok Heavy 구독자부터 접근할 수 있고, 기반 모델은 Grok 4.3 beta입니다. 앞서 공개한 16-agent Heavy 아키텍처를 터미널 쪽으로 끌고 온 셈입니다.
흥미로운 건 개별 기능보다 합류 방식입니다. Grok Build는 ACP(Agent Client Protocol)를 지원하고, 기존 MCP 서버와 Anthropic 계열 skills 형식까지 받아들입니다. 후발 주자가 자기 규격을 밀지 않고 이미 깔린 생태계에 얹은 것이지요. 2주 남짓한 기간에 코딩 에이전트·스킬 시스템·커넥터 레이어를 한꺼번에 낸 것도 같은 맥락으로 읽힙니다.
| 구분 | Claude Code | Cursor 3.5 | Grok Build |
|---|---|---|---|
| 병렬 단위 | 서브에이전트 + git worktree | 클라우드 VM 격리 | 서브에이전트 8개, 각자 worktree |
| 격리 수준 | 로컬 브랜치·디렉터리 | 원격 샌드박스(터미널·브라우저) | 로컬 브랜치·디렉터리 |
| 계획 단계 | 플랜 모드 승인 | IDE 비동기 리포트 | 실행 계획 사전 승인 |
| 컨텍스트 | 에이전트별 독립 창 | 멀티 레포 동시 | 200만 토큰 |
| 확장 규격 | MCP·skills 원산지 | MCP 지원 | ACP·MCP·skills 호환 |
병렬의 단위가 다르면 쓰는 법도 달라진다
표에서 가장 실질적인 차이는 격리 방식 한 줄입니다.
Claude Code와 Grok Build는 git worktree를 씁니다. 같은 저장소를 여러 디렉터리로 펼쳐 각 에이전트가 자기 브랜치에서 작업하는 구조입니다. 로컬에서 돌아가니 빠르고, 결과물이 곧바로 내 파일 시스템에 있습니다. 대신 내 머신의 CPU와 메모리를 8등분해 쓰게 됩니다. 테스트를 무겁게 도는 프로젝트라면 여기서 먼저 막힙니다.
Cursor Cloud Agents는 격리된 클라우드 VM으로 올렸습니다. 내 노트북이 조용하고, 여러 저장소를 동시에 건드릴 수 있으며, 결과는 IDE로 비동기로 돌아옵니다. 반대급부는 왕복 지연과 환경 재현입니다. 로컬 개발 환경에만 있는 설정·시크릿·DB에 의존하는 작업은 클라우드 쪽에서 재현하는 게 일입니다.
로컬 환경 의존이 크고 반복이 빠른 작업 → worktree 계열(Claude Code·Grok Build)
머신 부하가 크거나 여러 저장소를 동시에 다루는 작업 → 클라우드 계열(Cursor)
8개를 켤 수 있다고 8개를 켜는 건 아니다
여기가 뒤집히는 지점입니다.
에이전트는 병렬로 돌지만, 결과물을 메인 브랜치에 합치고 테스트를 돌리는 과정은 여전히 직렬입니다. 8개가 동시에 끝나도 머지 큐는 하나씩 통과합니다. 그리고 작업을 잘게 쪼갤수록 조각끼리 서로를 참조하는 비율이 올라가, 통합 시점의 충돌이 늘어납니다.
실제 측정에서 스위트 스팟이 2~4개로 나온 이유가 여기 있습니다. 다섯 번째 에이전트부터는 벌어들이는 시간보다 충돌 해소와 리뷰에 들어가는 시간이 더 커지기 시작합니다. AI 에이전트가 만든 풀 리퀘스트의 머지 충돌 빈도를 대규모로 수집한 연구 데이터셋이 최근 공개된 것도, 이 문제가 개인 체감이 아니라는 방증입니다.
그래서 워크플로를 어떻게 짜나
도구를 바꾸는 것보다 분할 기준을 바꾸는 쪽이 효과가 큽니다.
- 파일 경계로 쪼갠다. 기능 단위가 아니라 서로 다른 파일을 건드리는 단위로 나누면 충돌이 구조적으로 줄어듭니다. 같은 모듈을 두 에이전트가 만지게 하지 마세요.
- 2~3개로 시작한다. 상한이 8이어도 기본값은 낮게. 머지 큐가 밀리지 않는 선까지만 올리고, 밀리기 시작하면 그게 그 프로젝트의 상한입니다.
- 리뷰 가능한 크기로 자른다. 에이전트에게 "한 번에 300줄 이하"를 조건으로 주는 편이, 다 만든 뒤 쪼개는 것보다 쌉니다.
- 테스트를 먼저 병렬화한다. 코드 생성보다 검증이 병목이면, 에이전트를 늘려도 체감이 없습니다.
한 가지 더. 세 도구 모두 MCP를 지원하므로 사내 도구 연동은 대체로 재사용됩니다. Grok Build가 ACP와 skills 형식까지 받는다는 건, 도구를 갈아타는 비용이 예전만큼 크지 않다는 뜻이기도 합니다. 락인 걱정으로 결정을 미룰 이유는 줄었습니다.
정리
3파전의 승부처는 병렬 개수가 아니라 통합 비용을 누가 먼저 낮추느냐입니다. 자동 충돌 해소, 리뷰 요약, 머지 큐 최적화 같은 지루한 영역이지요. 스펙 시트에 잘 안 실리는 항목들입니다.
지금 병렬 에이전트를 쓰고 있다면 한 가지를 재보세요. 지난주에 에이전트가 코드를 만든 시간과, 그 결과를 읽고 합치는 데 쓴 시간. 후자가 더 길다면 늘려야 할 건 에이전트 수가 아닙니다.