Grok 4.5: 1.5T MoE 모델을 실제 개발자 워크플로우로 학습시키면 어떤 일이 벌어지는가

xAI는 2026년 7월 8일, 자사의 V9 파운데이션 아키텍처(foundation architecture)를 기반으로 구축된 1.5조(trillion) 파라미터 규모의 Mixture-of-Experts (MoE) 모델인 Grok 4.5를 출시했습니다. 주요 수치들도 주목할 만하지만, 더 흥미로운 이야기는 이 모델이 어떻게 학습되었는지에 있습니다. 바로 멀티 파일 디프(multi-file diffs), 디버거 세션(debugger sessions), 사용자 수정 사항을 포함하여 Cursor IDE에서 발생한 수조 개의 실제 개발자 상호작용 토큰을 사용했다는 점입니다. 이러한 설계 선택은 Grok 4.5가 무엇을 잘하는지, 그리고 어디에서 부족한지를 결정짓습니다.

V9 아키텍처와 MoE 설계

Grok 4.5는 Mixture-of-Experts (MoE) 아키텍처를 사용하며, 이는 추론(inference) 패스 중 특정 시점에 1.5조 개의 파라미터 중 일부만 활성화됨을 의미합니다. 이는 Mixtral이나 DeepSeek-V3와 같은 모델에서 사용되는 것과 동일한 일반적인 접근 방식으로, 전체 모델을 실행하는 대신 라우팅 로직(routing logic)이 토큰당

Grok 4.5의 가장 독특한 훈련 방식은 Cursor IDE 세션 데이터를 활용했다는 점입니다. AI 네이티브 코드 에디터인 Cursor는 엔지니어들이 대규모 코드베이스를 탐색하는 방법, 모델 제안에 어떻게 응답하는지, 여러 파일에 걸쳐 디버깅하는 방법, 그리고 모델의 실수를 수정하는 방법에 대한 수조 개의 토큰 분량의 실제 개발자 워크플로우 데이터를 제공했습니다.

이는 정적인 코드 저장소로 훈련하는 것과는 다릅니다. 정적 코드는 올바른 프로그램이 어떤 모습인지를 알려줍니다. 반면, Cursor 세션 데이터는 개발자들이 AI 지원과 어떻게 ‘상호작용’하는지—어떤 제안을 수락하고, 어떤 것을 거부하며, 모델이 잘못했을 때 무엇을 하는지—를 알려줍니다. 이러한 행동 신호(behavioral signal)는 합성하기가 더 어렵고, 에이전트 루프(agentic loops) 내에서 인간과 함께 작동해야 하는 모델을 훈련하는 데 잠재적으로 더 유용합니다.

xAI는 또한 의도적으로 훈련 혼합(training mix) 범위를 순수 코딩을 넘어 확장했습니다. 이 데이터셋에는 고품질의 STEM 과제, 연구 논문 및 기타 지식 노동 도메인이 포함되어 있으며, 이는 Composer 2.5와 같은 이전 모델들의 좁은 코딩 전문화에서 벗어나려는 의도적인 움직임입니다.

주목할 만한 복잡성도 있습니다: Cursor는 자체 코드베이스의 초기 스냅샷이 실수로 훈련 데이터에 포함되었다고 공개했습니다. 이로 인해 Grok 4.5가 CursorBench 기반 평가에서 점수가 부풀려졌습니다. DeepSWE나 SWE-Bench Pro와 같은 서드파티 벤치마크는 독립적인 인프라를 사용했기 때문에 영향을 받지 않았지만, 이는 벤치마크 오염(benchmark contamination)이 모델 평가에서 지속적인 문제로 남아 있음을 상기시켜 줍니다.

대규모 강화학습 (Reinforcement Learning at Scale)

데이터 혼합 외에도, xAI는 '토큰당 지능(per-token intelligence)'이라는 개념에 초점을 맞춰 강화학습을 확장했습니다. 이 RL 과정은 수십만 개의 소프트웨어 엔지니어링 및 기술 과제를 다루었으며, 에이전트 롤아웃(agentic rollouts)은 자동화된 방식과 모델 기반의 채점(model-based grading)을 통해 평가되었습니다.

학습 스택은 비동기적 동작(asynchronous operation)을 위해 구축되었습니다. 즉, 에이전트 롤아웃(agentic rollouts)이 GPU 클러스터 전체의 학습 프로세스를 중단시키지 않고도 몇 시간 동안 실행될 수 있습니다. 이는 의미 있는 엔지니어링 과제입니다. 표준적인 동기식 강화학습 (Synchronous RL)은 모델 가중치(model weights)를 업데이트하기 전에 각 롤아웃이 완료될 때까지 기다려야 하며, 이는 롤아웃이 다단계 도구 사용(multi-step tool use) 및 장기 계획(long-horizon planning)을 포함할 때 병목 현상(bottleneck)이 됩니다.

벤치마크 성능: 제공자 관리형 vs. 중립적 하네스 (Provider vs. Neutral Harnesses)

Grok 4.5의 벤치마크 결과는 엇갈리며, 제공자가 제어하는 평가와 중립적인 평가 사이의 격차를 주의 깊게 살펴볼 가치가 있습니다.

xAI 자체의 DeepSWE 1.0 벤치마크에서 Grok 4.5는 62.0%를 기록하며, 55.75%를 기록한 Claude Opus 4.8을 앞질렀습니다. 하지만 중립적인 DeepSWE 1.1 하네스(harness)에서는 결과가 뒤바뀝니다. Grok 4.5는 53%를 기록하여 Opus 4.8(59%)과 GPT-5.5(67%)에 뒤처졌습니다. SWE-Bench Pro에서는 Grok 4.5가 작업의 64.7%를 해결하여, Fable 5(80.4%)와 Opus 4.8(69.2%)에 뒤처졌습니다. Terminal Bench 2.1에서는 83.3%를 기록하며 더욱 경쟁력 있는 모습을 보였고, 이는 GPT-5.5의 83.4%와 거의 맞먹는 수준입니다.

제공자 제어형 평가에서는 강세를 보이고 중립적 평가에서는 약세를 보이는 이러한 패턴은 Grok 4.5만의 고유한 현상은 아니지만, 모델을 비교할 때 독립적인 벤치마크에 더 높은 가중치를 두어야 한다는 유용한 교훈을 줍니다.

실질적인 이점으로서의 토큰 효율성 (Token Efficiency)

Grok 4.5가 진정한 우위를 점하고 있는 부분은 토큰 효율성(token efficiency)입니다. SWE-Bench Pro에서 xAI는 해결된 작업당 평균 약 15,954개의 출력 토큰(output tokens)을 사용한다고 보고했습니다. Claude Opus 4.8은 동일한 작업에 대해 평균 약 67,020개의 출력 토큰을 사용하며, 이는 약 4.2배 더 많은 양입니다.

에이전트 워크로드(agentic workloads)에서 이는 두 가지 측면에서 중요합니다. 첫째, 비용을 직접적으로 절감합니다. 출력 토큰이 적다는 것은 작업당 가격이 낮아짐을 의미합니다. 둘째, 각 모델 호출이 다음 호출로 이어지는 다단계 파이프라인(multi-step pipelines)에서의 지연 시간(latency)에 영향을 미칩니다. 원시 처리량(raw throughput, 초당 토큰 수)이 비슷하더라도, 더 적은 토큰으로 동일한 정답에 도달하는 모델이 실제 작업 시 더 빠르게 작동합니다.

이러한 효율성이 진정으로 더 간결한 추론 (reasoning)을 반영하는 것인지, 아니면 단순히 더 짧고 (때로는 덜 철저한) 응답을 생성하는 것인지는 벤치마크 수치만으로는 판단하기 어렵습니다. 하지만 비용이 제약 사항인 대규모 에이전트 배포 (agentic deployments) 환경에서는 의미 있는 데이터 포인트입니다.

가용성 및 가격 (Availability and Pricing)

Grok 4.5는 xAI API, Cursor (모든 플랜), 그리고 Microsoft Office 애드인 (add-ins)을 통해 사용할 수 있습니다. 가격은 표준 사용 시 입력 토큰 100만 개당 $2, 출력 토큰 100만 개당 $6이며, Cursor 내에서 제공되는 "fast" 변형 모델은 $4/$18입니다. 200K 토큰 컨텍스트 임계값 (context threshold)을 초과하면 전체 요청에 대해 더 높은 롱 컨텍스트 (long-context) 요율($4/M 입력, $12/M 출력)이 적용됩니다.

EU 지역 가용성은 출시 당시 지연되었으며, xAI는 해당 지역에 대해 2026년 7월 중순을 목표로 하고 있습니다.

실무자에게 주는 의미 (What This Means for Practitioners)

Grok 4.5는 원시 벤치마크 점수보다 토큰 효율성 (token efficiency)과 처리량 (throughput)이 더 중요한 에이전트 기반 코딩 워크플로우 (agentic coding workflows)에서 합리적인 선택입니다. Cursor의 데이터 통합은 개발자가 실제로 작업하는 방식에 대한 실질적인 근거를 제공하며, 이는 표준화된 벤치마크에서 깔끔하게 나타나지 않더라도 실제 코딩 에이전트의 동작 성능 향상으로 이어질 수 있습니다.

컨텍스트 윈도우 (context window)가 500K 토큰으로 축소된 것은 대규모 코드베이스를 컨텍스트에 동시에 유지해야 하는 작업에서 실질적인 제한 사항입니다. 매우 큰 리포지토리 (repositories)를 다루는 팀은 1M 토큰 윈도우를 유지하는 모델과 비교했을 때 이 점이 제약이 될 수 있습니다.

Grok 4.5의 학습 방식이 주는 더 넓은 교훈은, 실제 인간-AI 상호작용에서 발생하는 행동 데이터 (behavioral data)가 코딩 어시스턴트를 학습시키는 데 있어 원시 코드 양만큼이나 가치 있을 수 있다는 점입니다. 더 많은 AI 네이티브 개발 도구들이 이러한 상호작용 데이터를 축적함에 따라, 이를 통해 학습된 모델들은 정적 코퍼스 (static corpora)만으로 학습된 모델들과 의미 있는 차이를 보일 가능성이 높습니다.