ai research
Harvey와 앱 레이어 AI의 post-training 전환: Sean Cai
- Sean Cai는 Harvey가 Fireworks AI와 open source model을 훈련하려는 움직임을, 앱 레이어 AI 회사들이 frontier model provider 의존을 줄이려는 더 큰 흐름으로 봄
- Harvey뿐 아니라 Ramp, Sierra, Decagon 같은 회사들도 Cursor처럼 자체 small model, post-training, harness 최적화에 점점 더 많은 노력을 쓰고 있다는 주장
- 이유는 단순함. OpenAI, Anthropic, Google 같은 frontier API만 쓰면 성능은 좋지만 inference cost, latency, gross margin, vendor dependency 문제가 생김
- Sean Cai는 다음 frontier model release의 추가 intelligence도 여전히 가치 있지만, 실제 제품에서는 harness, post-training, cost-latency tradeoff가 더 중요해지고 있다고 봄
- 마지막으로, 일부 앱 레이어 AI 회사들이 RL environment 회사에서 RL dataset을 어떻게 조달해야 하는지 Sean에게 묻고 있다는 점을 이 흐름의 증거로 듦
Harvey 소식은 왜 중요한가?
- Harvey는 법률 AI 회사임. 법률 문서 검토, 계약서 분석, legal workflow 같은 고가치 업무를 AI로 처리하려는 vertical AI 회사로 볼 수 있음
- 이런 회사가 Fireworks AI와 open source model을 훈련하려는 건 단순한 모델 실험이 아니라, 앱 레이어 회사가 자기 제품에 맞는 model stack을 직접 만들려는 신호로 해석할 수 있음
- Sean Cai는 Harvey를 Cursor, Ramp, Sierra, Decagon과 같은 목록에 넣음. 공통점은 모두 특정 업무 workflow를 AI 제품으로 바꾸는 앱 레이어 회사라는 점
- 이 회사들은 예전처럼 “GPT나 Claude API를 잘 붙이면 된다”에서 멈추기 어려움
- 고객이 많아지고 사용량이 커질수록, 모델 호출 비용과 지연 시간, 특정 task 성능, 데이터 통제권이 모두 제품 경쟁력에 직접 연결되기 때문
frontier model 의존을 줄인다는 건 무슨 뜻인가?
- 여기서 말하는 decoupling은 frontier model을 완전히 버린다는 뜻이 아님
- 더 현실적인 구조는 frontier model을 위쪽 orchestrator로 쓰고, 반복적이고 domain-specific한 작업은 post-trained small model이 맡는 방식임
- 예를 들어 Harvey라면 frontier model은 전체 legal reasoning이나 어려운 질문 처리에 쓰고, 자체 모델은 clause extraction, document tagging, citation check, 반복 문서 작업에 쓸 수 있음
- Cursor도 비슷한 방향으로 볼 수 있음. 가장 비싼 모델을 모든 token에 쓰기보다, harness, tool use, context management, model routing으로 비용과 성능을 조정함
- 앱 레이어 회사 입장에서는 이 구조가 gross margin을 개선함. 고객에게 받은 돈에서 모델 비용을 빼고도 더 많이 남기려면, 모든 일을 비싼 API로 처리할 수 없기 때문
| 구조 | frontier API 중심 | post-training 중심 |
|---|---|---|
| 모델 사용 | 모든 핵심 task를 GPT, Claude, Gemini에 의존 | frontier model은 planner나 orchestrator로 사용 |
| 실행 비용 | 사용량이 늘수록 API 비용도 커짐 | 반복 task는 small model로 낮은 비용 처리 |
| 제품 차별화 | prompt, UI, workflow 설계 중심 | harness, data, eval, 자체 모델까지 포함 |
| 성능 개선 | 다음 model release를 기다림 | 자체 benchmark와 RL data로 직접 개선 |
| vendor dependency | 모델 제공자 정책과 가격에 강하게 묶임 | 일부 task는 자체 stack으로 통제 가능 |
왜 harness가 base model보다 중요해지나?
- Sean Cai는 다음 model release에서 얻는 추가 intelligence의 가치가 줄어든다기보다, 그 가치가 제품 전체 성능을 결정하는 유일한 요인이 아니게 된다고 봄
- 실제 업무에서는 base model의 평균 지능보다, 모델이 어떤 tool을 쓰고, 어떤 context를 보고, 어떤 retry loop와 verifier를 거치는지가 더 중요할 수 있음
- harness-level difference는 이런 차이를 말함. 같은 모델을 써도 Cursor, Claude Code, Copilot, 사내 agent가 다르게 느껴지는 이유가 여기에 있음
- post-training infra가 좋아지면 회사는 performance-cost-latency Pareto curve를 더 잘 탐색할 수 있음
- 즉 가장 비싼 모델 하나를 무조건 쓰는 게 아니라, 특정 task에서 충분히 잘하고 더 싸고 빠른 모델 조합을 찾을 수 있음
GLM과 MiniMax 얘기는 왜 나오나?
- Sean Cai는 toy benchmark가 아니라 practical benchmark에서 GLM이나 최신 MiniMax 같은 모델이 frontier model과 비슷하거나 더 좋은 성능을 보이는 task가 있다고 말함
- 여기서 practical benchmark는 MMLU 같은 일반 시험형 benchmark보다, 실제 제품에서 돈이 되는 업무 기준에 가까움
- 예를 들어 법률 문서 검토, 고객지원 티켓 처리, CRM 업데이트, invoice 처리, browser workflow, spreadsheet 작업 같은 것들임
- 특정 업무에서는 가장 큰 모델보다, 그 업무에 맞게 post-training된 더 작은 모델이 비용과 속도 면에서 훨씬 좋은 선택일 수 있음
- 그래서 앱 레이어 회사는 “어떤 모델이 전체 benchmark 1등인가”보다, “우리 workflow에서 어떤 조합이 제일 싸고 빠르게 성공하는가”를 보게 됨
Harvey의 RLaaS 실험은 어떻게 봐야 하나?
- Sean Cai는 Harvey가 이미 한동안 RLaaS vendor들을 실험해왔다고 말함
- RLaaS는 Reinforcement Learning as a Service에 가까운 표현임. 회사가 직접 RL infra를 다 만들지 않아도, 특정 task와 data, environment를 기반으로 모델을 post-train할 수 있게 돕는 서비스로 보면 됨
- Sean은 Harvey의 초기 fine-tuning 시도가 큰 RL wave 전에는 별로 좋은 평가를 받지 못했다고도 언급함
- 이건 단순 SFT나 domain fine-tuning만으로는 실제 product 성능 개선이 애매했을 수 있다는 의미로 읽을 수 있음
- 하지만 지금은 RL environment, verifier, on-policy rollout, verified trajectory 같은 post-training 기술과 데이터 시장이 빠르게 발전하고 있어서, 같은 “자체 모델 학습”이라도 과거와는 다르게 볼 수 있음
RL dataset을 산다는 건 실제로 무엇을 사는 것인가?
- 마지막 문장이 가장 직접적인 시장 신호임. Sean Cai는 몇몇 앱 레이어 AI 회사들이 RL environment 회사에서 RL dataset을 어떻게 조달해야 하는지 조언을 구한다고 말함
- 이건 앱 회사들이 단순히 좋은 prompt나 좋은 UI를 넘어서, 자기 모델을 실제 workflow에 맞게 훈련할 수 있는 데이터를 찾고 있다는 뜻
- 여기서 dataset은 단순 화면 녹화나 human demo만을 뜻하지 않을 가능성이 큼
- 더 가치 있는 형태는 task instruction, initial state, action trajectory, observation, success criteria, verifier, reward signal, failure case, retry data까지 포함한 RL-ready data임
- 결국 앱 레이어 AI 회사들이 원하는 건 “데이터 파일”이 아니라, 자기 제품의 small model을 더 싸고 빠르고 정확하게 만드는 post-training fuel임
| 데이터 형태 | 가치 |
|---|---|
| 단순 human demo | 사람이 어떻게 했는지 보여줌 |
| trajectory plus final label | 성공과 실패를 RLVR에 쓸 수 있음 |
| verified trajectory | task 성공 기준이 명확해서 eval과 training에 같이 쓸 수 있음 |
| failure-localized trajectory | 어느 step에서 실패했는지 알 수 있음 |
| environment plus verifier | 모델이 반복 rollout하고 개선할 수 있는 post-training asset이 됨 |
앱 레이어 AI 회사가 왜 자체 small model을 post-train하나요?
고객 사용량이 커질수록 frontier API 비용이 gross margin을 압박하기 때문임. 또 특정 업무에서는 큰 모델의 일반 지능보다, 그 업무에 맞게 학습된 작은 모델과 좋은 harness가 더 싸고 빠르게 충분한 성능을 낼 수 있음.
frontier model을 완전히 버린다는 뜻인가요?
아님. 더 가능성 높은 구조는 frontier model을 planner, supervisor, hard case handler로 쓰고, 반복적이고 구체적인 업무는 post-trained small model이 처리하는 방식임. 이렇게 하면 성능과 비용, 지연 시간을 더 세밀하게 조정할 수 있음.
RL environment 회사는 여기서 무엇을 파나요?
단순 dataset보다, 모델이 실제 업무를 연습하고 평가받고 개선될 수 있는 task, environment, verifier, reward signal, trajectory pipeline을 팜. 앱 회사 입장에서는 이게 자체 small model의 성능을 올리는 직접 재료가 됨.