바이브코딩 카니 2026.06.02 AI 보조 작성·편집자 검수

카니 · AI 보조 작성, 편집자 검수

Grok도 코딩 에이전트 전쟁에 들어왔다: Composer 2.5가 보여준 진짜 경쟁축

Grok도 코딩 에이전트 전쟁에 들어왔다: Composer 2.5가 보여준 진짜 경쟁축

핵심 요약

2026년 6월 1일, xAI는 Grok Build 안에서 Composer 2.5를 쓸 수 있다고 공지했다. 설치 명령은 기존 Grok Build CLI와 같고, 실행 후 /model 메뉴에서 Composer 2.5를 고르는 방식이다. 접근 조건은 SuperGrok 또는 X Premium+다.

표면적으로는 “새 코딩 모델이 하나 더 들어왔다”는 소식처럼 보인다. 하지만 이번 업데이트의 의미는 모델명보다 제품 배치에 있다. Composer 2.5는 Cursor가 2026년 5월 18일 공식 블로그에서 발표한 장기 작업형 코딩 모델이다. Cursor는 이 모델이 긴 작업을 지속하고 복잡한 지시를 더 안정적으로 따르도록 개선됐다고 설명했다. xAI는 그 모델을 Grok Build라는 터미널 기반 코딩 에이전트의 선택지로 넣었다.

즉 경쟁 구도는 “어느 모델이 한 번에 코드를 더 잘 쓰나”에서 “어느 하네스가 긴 작업을 끝까지 관리하나”로 옮겨가고 있다. Claude Code, OpenAI Codex, Cursor, Google Antigravity에 이어 Grok Build까지 같은 질문을 던지기 시작했다. 개발자는 이제 모델 벤치마크만 볼 수 없다. plan mode, subagent, MCP, 권한 승인, 비용 추적, 실패 복구까지 같이 봐야 한다.

Grok Build 안에서 Composer 2.5를 선택하는 코딩 에이전트 경쟁 구도

이미지: Grok Build의 /model 선택 흐름과 Composer 2.5, Claude Code, Codex, Cursor의 경쟁 구도를 요약한 생성 이미지.

무엇이 새로 나온 건가

xAI의 공식 공지는 매우 짧다. “Composer 2.5 is now available in Grok Build. Try it from the /models menu.”가 핵심이다. 같은 페이지에서 xAI는 Composer 2.5를 “fast, state-of-the-art model”로 소개하고, 긴 작업과 복잡한 지시 수행에 강하다고 설명한다.

Grok Build 자체는 이미 별도 제품 페이지와 문서를 갖고 있다. xAI 문서 기준 Grok Build는 대화형 TUI, headless 실행, Agent Client Protocol, API 모델 사용을 지원하는 코딩 에이전트다. curl -fsSL https://x.ai/cli/install.sh | bash로 설치하고, 프로젝트 폴더에서 grok을 실행하는 구조다. 브라우저 인증이 어려운 환경에서는 XAI_API_KEY로 실행할 수 있고, grok -p "Explain this codebase"처럼 headless 명령도 가능하다.

여기서 Composer 2.5 추가가 중요한 이유는 Grok Build가 단순 “Grok 모델 전용 CLI”가 아니라 모델 선택형 코딩 하네스로 움직이기 시작했다는 점이다. xAI 페이지의 모델 선택 예시에는 Grok Build와 Composer 2.5가 나란히 보인다. 사용자는 같은 터미널 하네스 안에서 다른 코딩 모델을 골라 긴 작업을 맡길 수 있다.

Cursor 쪽 원문을 함께 봐야 맥락이 선명하다. Cursor는 Composer 2.5가 Composer 2보다 지능과 행동 측면에서 개선됐고, 긴 작업 지속성, 복잡한 지시 따르기, 협업 감각이 좋아졌다고 설명했다. 또 Composer 2.5가 Composer 2와 같은 Moonshot Kimi K2.5 오픈소스 체크포인트를 기반으로 하며, Composer 2보다 25배 많은 synthetic task로 훈련됐다고 밝혔다.

중요한 건 xAI가 이 설명을 전부 반복하지 않았다는 점이다. xAI의 새 소식은 Composer 2.5의 연구 발표가 아니라 Grok Build 안의 배포다. 따라서 이 글의 결론도 “xAI가 새 모델을 처음부터 만들었다”가 아니라 “xAI가 Grok Build를 장기 작업형 코딩 에이전트 플랫폼으로 확장하고 있다”에 가깝다.

왜 긴 작업이 경쟁축이 됐나

코딩 에이전트의 초기 경쟁은 자동완성과 짧은 수정이었다. 함수 하나 고치기, 테스트 하나 추가하기, README 정리하기 같은 작업에서는 모델 답변 품질이 전부처럼 보였다. 하지만 실제 개발팀이 에이전트를 쓰기 시작하면 과제는 곧 길어진다.

예를 들어 인증 방식을 세션에서 JWT로 바꾸는 작업을 생각해보자. 모델은 파일을 읽고, 영향 범위를 찾고, 마이그레이션 전략을 짜고, 테스트를 추가하고, 에러를 보고, 다시 수정해야 한다. 이 작업은 한 번의 답변이 아니라 수십 번의 도구 호출과 판단으로 구성된다. 중간에 잘못된 파일을 읽거나, 이미 바뀐 요구사항을 잊거나, 테스트 실패를 대충 넘기면 결과물은 위험해진다.

그래서 장기 작업형 코딩 에이전트에서 중요한 능력은 세 가지다. 첫째, 긴 맥락을 유지하는 능력. 둘째, 도구 호출과 실패를 다루는 하네스 설계. 셋째, 사용자가 중간 승인과 방향 수정을 넣을 수 있는 인터페이스다.

Grok Build 제품 페이지는 이 세 가지를 모두 전면에 둔다. plan mode는 복잡한 작업을 먼저 설계하고, 사용자가 승인하기 전까지 편집을 막는다. subagent는 조사, 테스트, 리뷰 같은 작업을 병렬로 나눠 돌릴 수 있게 한다. skills, plugins, hooks, MCP servers, AGENTS.md는 팀의 작업 규칙과 외부 시스템 연결을 하네스 안으로 끌어온다.

이 흐름은 이미 다른 제품에서도 확인된다. OpenAI는 2026년 Codex 앱을 발표하며 여러 에이전트를 병렬로 관리하고, 긴 작업을 감독하는 앱 경험을 강조했다. Anthropic의 Claude Code도 데스크톱, 터미널, IDE, 모바일 연계를 넓히며 “작업을 맡기고 돌아오면 PR이 준비되는” 흐름을 전면에 세웠다. Google Antigravity 쪽 변화가 궁금하다면 이전 글인 Antigravity 2.0 출시 — 구글 첫 Agent-First IDE 데스크탑, Cursor·Claude Code와 정면 충돌에서 IDE 중심 접근을 함께 보면 이해가 쉽다.

Composer 2.5가 Grok Build에 들어온 의미

이번 조합은 Cursor와 xAI의 관계를 단순 경쟁으로만 보기 어렵게 만든다. Cursor는 Composer 2.5를 자사 제품 안에 넣었고, xAI는 같은 모델을 Grok Build 안의 선택지로 제공한다. 동시에 Cursor 원문은 SpaceXAI와 함께 10배 더 많은 총 compute를 쓰는 더 큰 모델을 처음부터 훈련 중이라고 적었다.

이 말은 세 가지로 읽힌다.

첫째, 코딩 모델과 코딩 제품의 경계가 갈라지고 있다. 예전에는 “Cursor는 Cursor 모델, xAI는 Grok 모델”처럼 제품과 모델이 1:1로 묶일 것 같았다. 그런데 Grok Build가 Composer 2.5를 품으면서, 같은 하네스 안에서 여러 모델을 고르는 구조가 더 자연스러워졌다.

둘째, 모델 회사와 IDE 회사의 협업이 더 중요해졌다. 장기 작업형 코딩 모델은 일반 챗봇 데이터만으로 만들기 어렵다. 실제 코드베이스, 테스트, tool error, reviewer feedback, 실패 사례가 필요하다. Cursor는 Composer 2.5 훈련에서 targeted textual feedback과 synthetic task를 강조했다. 이건 단순 코드 생성보다 “에이전트가 어디서 잘못 행동했는지”를 학습시키는 방향이다.

셋째, xAI는 Grok Build를 Grok 모델 홍보용 CLI로 끝내지 않으려는 것으로 보인다. xAI 문서에는 Grok Build 0.1도 별도 API 모델로 올라와 있다. 가격표 기준 grok-build-0.1은 256k 컨텍스트, 100만 입력 토큰당 1달러, 출력 토큰당 2달러다. 이 모델은 기존 grok-code-fast-1의 권장 대체 모델로도 안내된다. 여기에 Composer 2.5까지 들어오면 Grok Build는 “xAI 모델을 쓰는 터미널”이 아니라 “코딩 에이전트 작업장을 운영하는 터미널”에 가까워진다.

Composer 2.5와 Grok Build 0.1의 역할 분리: 모델 선택과 하네스 경쟁

이미지: Grok Build 0.1, Composer 2.5, Claude Code, Codex, Cursor를 모델, 하네스, 사용 표면, 긴 작업 관리라는 관점으로 요약한 생성 인포그래픽.

Claude Code, Codex, Cursor와 비교하면

현재 개발자가 실제로 비교해야 할 표는 단순 성능표가 아니다. 공식 문서에서 확인되는 제품 축을 기준으로 보면 다음과 같다. 모바일 화면에서는 긴 가격 문장과 주의점이 한 줄에 눌려 보이기 쉬우므로, 도구별로 핵심 표면, 긴 작업 장치, 가격 힌트, 주의할 점을 나눠 읽는 편이 낫다.

Grok Build + Composer 2.5

  • 핵심 표면: 터미널 TUI, headless 실행, API
  • 긴 작업 장치: plan mode, subagents, skills, plugins, MCP, hooks
  • 모델/가격 힌트: Grok Build 0.1 API는 256k 컨텍스트, 입력 100만 토큰당 1달러, 출력 100만 토큰당 2달러다. Composer 2.5는 Cursor 기준 입력 100만 토큰당 0.50달러, 출력 100만 토큰당 2.50달러다.
  • 주의할 점: xAI의 Composer 2.5 공지는 짧고, 독립 벤치마크와 실사용 검증은 아직 부족하다.

Cursor Composer 2.5

  • 핵심 표면: Cursor IDE
  • 긴 작업 장치: Cursor Agent, Composer 모델, 사용량 풀
  • 모델/가격 힌트: Cursor 발표 기준 입력 100만 토큰당 0.50달러, 출력 100만 토큰당 2.50달러다. fast variant는 입력 100만 토큰당 3달러, 출력 100만 토큰당 15달러다.
  • 주의할 점: Cursor 안에서는 가장 자연스럽지만, 외부 하네스 운영은 제한적이다.

Claude Code

  • 핵심 표면: 터미널, IDE, 데스크톱, 모바일 연계
  • 긴 작업 장치: 파일 수정, 테스트 실행, PR 흐름, 병렬 작업 관리
  • 모델/가격 힌트: Pro, Max 5x, Max 20x에 포함된다. API로 사용할 때는 표준 API 과금이 적용된다.
  • 주의할 점: 사용량 한도와 병렬 subagent 비용 체감이 중요하다.

OpenAI Codex

  • 핵심 표면: CLI, IDE, 앱, 클라우드
  • 긴 작업 장치: 여러 에이전트 병렬 관리, long-running task 감독
  • 모델/가격 힌트: ChatGPT 플랜과 Codex surface 전반에 한도가 적용된다.
  • 주의할 점: OpenAI 생태계 안에서는 강하지만, 팀별 권한과 보안 설계가 필요하다.

여기서 Grok Build의 강점은 터미널 중심 개발자에게 익숙한 구조다. CLI에서 바로 설치하고, 프로젝트 폴더에서 실행하고, 필요한 경우 headless로 자동화할 수 있다. MCP와 hooks를 지원한다는 점도 팀 환경에 맞다.

반대로 약점도 분명하다. xAI의 Composer 2.5 공지는 매우 짧고, Grok Build가 실제 대규모 코드베이스에서 Claude Code나 Codex만큼 안정적으로 버티는지에 대한 공개 검증은 아직 많지 않다. Cursor가 공개한 Composer 2.5 훈련 설명과 가격은 풍부하지만, Grok Build 안에서 Composer 2.5를 쓸 때의 정확한 사용량 정책, 실패 복구 경험, 팀 관리 기능은 별도로 확인해야 한다.

최근 Claude Code의 병렬 subagent와 사용량 이슈를 다룬 Claude Code 한도가 빨리 사라진다면: 리밋 리셋보다 먼저 봐야 할 병렬 subagent 비용에서도 봤듯, 긴 작업형 에이전트의 비용은 모델 가격표만으로 계산되지 않는다. 병렬 에이전트가 몇 개 뜨는지, 각 에이전트가 자기 컨텍스트를 얼마나 들고 가는지, 테스트와 검색을 몇 번 반복하는지가 실제 비용을 결정한다.

개발자가 지금 확인할 것

Grok Build를 바로 실험해볼 개발자라면 큰 프로젝트 전체를 맡기기보다 작은 작업부터 보는 편이 낫다. xAI 문서 기준 설치는 간단하다.

curl -fsSL https://x.ai/cli/install.sh | bash
cd your-project
grok

API 키로 실행할 환경이라면 다음처럼 시작할 수 있다.

export XAI_API_KEY="xai-..."
grok

headless로 코드베이스 설명을 시킬 수도 있다.

grok -p "Explain this codebase"
grok -p "Explain the architecture" --output-format streaming-json

테스트 순서는 단순해야 한다. 첫째, 읽기 전용 설명 작업을 맡긴다. 둘째, 작은 버그 수정이나 테스트 추가를 맡긴다. 셋째, plan mode에서 실제로 편집 승인 흐름이 편한지 본다. 넷째, /model 메뉴에서 Composer 2.5와 Grok Build 0.1을 바꿔가며 같은 작업을 시킨다. 다섯째, 토큰/요금/한도 표시가 팀 운영에 충분한지 확인한다.

팀에서 볼 포인트는 더 엄격하다. MCP 서버를 연결할 때 권한 범위가 어디까지 열리는지, hooks가 어떤 시점에 실행되는지, AGENTS.md 규칙이 하위 폴더에서 어떻게 적용되는지, subagent가 별도 worktree를 쓸 때 충돌을 어떻게 막는지 확인해야 한다. 코딩 에이전트는 “잘 고쳐주는 도구”이기도 하지만, 동시에 로컬 파일과 외부 시스템에 접근하는 자동 실행자다.

Grok Build 도입 전 체크리스트: 권한, 비용, 테스트, 하네스 규칙

이미지: 개발팀이 Grok Build를 실험하기 전 확인할 권한, 비용, 테스트, subagents, MCP, hooks 체크리스트를 요약한 생성 이미지.

관전 포인트

이번 발표는 xAI가 Claude Code나 Codex를 단번에 따라잡았다는 증거가 아니다. 그렇게 말하기엔 아직 공개 정보가 부족하다. 하지만 코딩 에이전트 시장이 어디로 가는지는 분명히 보여준다.

첫째, 긴 작업 지속성이 핵심 성능 지표가 된다. 짧은 함수 생성보다 “몇 시간짜리 작업을 중간 승인과 테스트를 거쳐 끝내는 능력”이 더 중요해진다.

둘째, 하네스가 모델만큼 중요해진다. 같은 Composer 2.5라도 Cursor 안에서 쓰는 경험과 Grok Build 안에서 쓰는 경험은 다를 수 있다. 파일 접근, 승인 UX, tool error 처리, diff 검토 방식이 결과 품질을 바꾼다.

셋째, 가격 비교가 더 어려워진다. Composer 2.5의 API 단가, Grok Build 0.1의 API 단가, Claude Max 구독, Codex의 ChatGPT 플랜 포함 구조는 서로 다른 계산법을 쓴다. 실제 비용은 “한 작업을 끝내는 데 몇 번의 도구 호출과 몇 개의 병렬 에이전트가 필요한가”로 다시 계산해야 한다.

넷째, 개발자는 특정 제품에 완전히 묶이기보다 자기 팀의 작업 규칙을 이식 가능한 형태로 정리해야 한다. AGENTS.md, skills, MCP 설정, 테스트 스크립트, 리뷰 기준을 잘 정리해두면 Claude Code, Codex, Grok Build, Cursor 사이를 비교하기 쉬워진다. 반대로 규칙이 구두로만 존재하면 어떤 에이전트를 써도 결과가 흔들린다.

결론은 간단하다. Grok Build에 Composer 2.5가 들어온 일은 모델 하나가 추가된 뉴스가 아니다. 코딩 에이전트 시장이 “똑똑한 답변”에서 “긴 작업을 운영하는 하네스” 경쟁으로 넘어갔다는 신호다. 지금 개발자가 던져야 할 질문은 “어느 모델이 가장 똑똑한가”가 아니라 “우리 코드베이스에서 어느 조합이 가장 오래, 가장 안전하게, 가장 예측 가능한 비용으로 일하는가”다.

출처와 더 읽을 거리

AI 코딩 Claude Code Codex Composer 2.5 Cursor Grok Build xAI 개발자 도구 코딩 에이전트

공유

Threads X