Cursor가 Composer 2를 직접 훈련한 이유: Sequoia

Cursor가 Composer 2를 직접 훈련한 이유는 단순함. 범용 모델보다 “Cursor 안에서 소프트웨어 엔지니어링을 잘하는 모델”이 더 싸고 빠를 수 있기 때문
Federico Cassano(Cursor)는 모델을 저장장치처럼 설명함. 모델 가중치에 담을 수 있는 정보량이 유한하다면, 그 모든 정보를 Cursor 환경 하나에 몰아넣자는 발상
Composer 2는 Kimi 2.5 기반에서 시작해 code mid-training(코드 데이터로 추가 학습)과 RL(강화학습)을 모두 사용
Fireworks는 전 세계 여러 GPU 클러스터를 묶고, 모델 업데이트를 빠르게 동기화하는 인프라를 함께 구축
Sequoia Capital의 Training Data 팟캐스트. Cursor의 Composer 2 리서치 리드 Federico Cassano와 Fireworks의 Dmytro Dzhulgakov가 훈련 과정을 설명한 대담

왜 앱 회사가 자기 모델을 훈련하나?

처음에는 대부분 범용 모델로 시작함. 프롬프트를 다듬고, 도구 호출 방식을 붙이고, 제품이 되는지 확인
그런데 앱이 커질수록 가장 중요한 데이터는 제품 안에서 생김. 사용자가 어떤 도구를 쓰는지, 어디서 실패하는지, 어떤 결과를 좋아하는지 같은 신호
Cursor는 “코딩 전체”보다 좁게 봄. 목표는 프로그래밍 일반이 아니라 Cursor 안에서 돌아가는 소프트웨어 엔지니어링
이렇게 범위를 좁히면 작은 모델도 강해질 수 있음. Composer가 Opus 같은 범용 코딩 모델보다 훨씬 싸게 돌 수 있다는 설명
Fireworks 쪽도 이를 앱의 자연스러운 진화로 봄. 처음엔 범용 모델을 쓰지만, 진짜 차이는 제품 환경에 맞게 모델 행동을 바꾸는 데서 난다는 것

Composer 2는 어떻게 훈련됐나?

시작점은 Kimi 2.5. 1조 파라미터 규모지만 실제 한 번에 활성화되는 부분은 30B인 MoE(여러 전문가 중 일부만 쓰는 구조) 모델
Composer 1이 RL 한 축에 집중했다면, Composer 2는 두 축을 밀었음
첫 번째는 mid-training. 코드 토큰을 대량으로 먹여 라이브러리, 코드 패턴, 일반적인 개발 지식을 넓게 익히게 함
두 번째는 RL. 모델을 Cursor와 비슷한 환경에 넣고 실제 agent session처럼 도구를 부르고, 코드를 쓰고, 결과에 보상을 줌
Federico의 표현으로는 mid-training은 “코드를 쓰는 법”을 넓게 배우는 단계이고, RL은 “올바른 코드를 쓰고 도구를 잘 쓰는 법”을 날카롭게 만드는 단계

단계	배우는 것	핵심 역할
범용 base model	일반 지식과 코드 기초	출발점
mid-training	라이브러리, 코드 패턴, 개발 지식	분포를 넓힘
RL	도구 호출, 환경 탐색, 정답 코드	행동을 날카롭게 만듦
real-time RL	실제 사용자 만족/불만 신호	배포 후 계속 개선

RL 인프라는 왜 이렇게 어려운가?

일반 학습은 다음 토큰을 맞히는 문제에 가까움. RL은 훨씬 복잡함
모델에게 하나의 과제를 주고, 실제 Cursor 세션처럼 여러 턴 동안 도구를 쓰게 함. 이 전체 과정을 rollout이라고 부름
끝나면 “잘했는지” 보상을 줌. 보상은 코드가 컴파일되는지처럼 검증 가능한 신호일 수도 있고, LLM judge(다른 모델이 평가자 역할을 하는 방식)일 수도 있음
문제는 이걸 큰 규모로 돌리려면 훈련용 GPU, 추론용 GPU, 가짜 개발 환경, 보상 시스템이 모두 동시에 움직여야 한다는 점
Cursor와 Fireworks는 trainer와 rollout을 동시에 계속 돌리는 비동기 파이프라인을 사용. 완벽히 깔끔한 수학 업데이트보다 GPU를 쉬지 않게 쓰는 쪽을 택한 것

전 세계 클러스터를 어떻게 묶었나?

Composer 2 훈련에는 여러 지역의 GPU 클러스터가 쓰였고, 일부는 실제 서비스 트래픽이 적은 시간의 production inference GPU도 활용
전체 모델 체크포인트는 약 1TB 규모라 매번 통째로 보내면 너무 느림
Fireworks는 매 단계에서 바뀐 부분만 보내는 delta 방식으로 해결. 전체 모델 대신 훨씬 작은 차이만 보내고, 반대편에서 같은 모델 상태를 복원
MoE 모델은 더 까다로움. 아주 작은 숫자 차이 때문에 다른 expert가 선택되면, 훈련과 추론이 어긋날 수 있음
그래서 어떤 expert가 활성화됐는지 같이 보내는 router replay 같은 기법을 써서 훈련과 추론의 차이를 줄임

모든 AI 앱 회사가 자기 모델을 훈련해야 하나?

대담의 결론은 “큰 AI 제품은 점점 그렇게 갈 가능성이 높다”에 가까움. 처음부터 자체 모델을 만들 필요는 없지만, 사용자가 많이 생기고 제품 환경이 뚜렷해지면 범용 모델만으로는 비용과 품질 한계가 생김. 그때 제품 데이터와 환경에 맞춘 fine-tuning, RL이 강해질 수 있음.

RL은 언제 필요한가?

단순 요약이나 텍스트 생성만 한다면 꼭 RL이 필요하지 않을 수 있음. 하지만 도구를 쓰고, 여러 단계 작업을 하고, 사용자의 실제 환경 안에서 오래 움직이는 agent라면 RL이 중요해짐. 모델이 “무엇을 말할지”보다 “어떻게 행동할지”를 배워야 하기 때문.

Cursor가 실제 사용자 데이터로 바로 RL하지 않는 이유는?

실제 사용자에게 이상한 결과를 보여주면 제품 경험이 망가짐. 그래서 먼저 가짜 환경에서 여러 번 시도하게 하고, 충분히 좋아진 뒤 실제 사용자 신호로 더 다듬는 구조를 씀. 실제 사용자 신호는 모델을 처음부터 만들기보다 이미 좋은 모델을 더 좋게 만드는 데 적합함.

1인기업 관점

예전에 YC batch에서 Nozomio를 만든 Arlan이 X에서 “모든 회사는 lab이 되어야 한다”는 식으로 말한 걸 본 적 있는데, 이 대담 보면서 그 얘기가 생각남. 앱 자체는 진입장벽이 약한 듯함. 잘되면 결국 다 따라잡으니까, 진짜 차이는 제품 안에서 데이터와 평가 기준을 쌓고 계속 실험하는 능력에서 나는 것 같음.

Cursor가 Composer 2를 직접 훈련한 이유: Sequoia (youtube.com) ↗