모델과 하네스를 같이 소유해야 한다

AI 앱의 다음 분기점은 모델만 잘 쓰는 것이 아니라, 모델과 하네스를 같이 설계하는 쪽으로 가는 것 같음
Cursor와 Composer 2, Claude Code와 Anthropic models, Codex와 GPT, Gemini와 Antigravity는 모두 같은 방향을 보여줌. 좋은 모델은 좋은 실행 환경 안에서 더 강해지고, 좋은 실행 환경은 특정 모델에 맞춰 더 날카로워짐
초기에는 frontier API로 빠르게 제품을 만들 수 있음. 하지만 사용량이 커지면 API cost가 gross margin을 갉아먹고, 모델 제공자가 앱 레이어로 내려오는 위험도 커짐
그래서 규모 있는 AI 앱 회사는 결국 open weights model을 직접 운영하고, 자기 domain data로 SFT와 RL을 하고, 자체 benchmark와 eval process를 만들 가능성이 큼
핵심은 “모델을 직접 pretraining하라”가 아님. 내 제품의 workflow, tool calling, 평가 기준, 실제 KPI를 올리는 피드백 루프를 소유하라는 뜻에 가까움

왜 모델만으로는 부족한가?

모델은 혼자 일하지 않음. 실제 제품에서는 파일을 읽고, 코드를 고치고, 브라우저를 조작하고, API를 호출하고, 결과를 다시 검증함
이 실행 환경 전체가 하네스임. tool calling, context 구성, 권한, retry, memory, sandbox, verifier, UI가 모두 여기에 들어감
같은 모델도 하네스가 다르면 성능이 달라짐. 코딩 모델이 CLI에서는 잘하지만 IDE 안에서는 더 잘할 수 있고, 브라우저 agent가 일반 chat보다 실제 화면 안에서 훨씬 많은 신호를 받을 수 있는 것과 비슷함
반대로 하네스만 좋아도 한계가 있음. 모델이 그 환경에서 어떤 도구를 언제 써야 하는지 못 배우면, 하네스는 복잡한 wrapper로 남음
그래서 앞으로의 AI 제품은 “모델 vs 앱”이 아니라 “모델과 하네스가 같이 학습되는 시스템”에 가까워질 것 같음

왜 각 도메인마다 RL이 필요한가?

SFT는 좋은 예시를 보고 따라 하게 만드는 단계임. 예를 들어 좋은 고객 응대문, 좋은 코드 수정, 좋은 리서치 보고서를 보여주는 것
RL은 실제 환경에서 여러 번 시도하게 하고, 결과가 좋았는지 나빴는지 보상으로 배우게 하는 단계임
도메인이 달라지면 좋은 행동도 달라짐. 코딩 agent의 좋은 행동, 법률 agent의 좋은 행동, 재무 분석 agent의 좋은 행동, 브라우저 조작 agent의 좋은 행동은 서로 다름
그래서 범용 benchmark만으로는 부족함. 중요한 건 실제 고객 KPI를 올리는지임. 버그를 줄였는지, 처리 시간을 줄였는지, 매출 전환을 올렸는지, 사람이 다시 고친 비율이 줄었는지를 봐야 함
이때 자체 benchmark와 eval process가 핵심 자산이 됨. 모델을 바꿔도 품질을 비교할 수 있고, RL을 해도 엉뚱한 shortcut을 배우는지 잡을 수 있기 때문

층	예시	소유해야 하는 이유
Model	open weights model, 작은 specialized model	API 비용과 공급자 의존도를 낮춤
Harness	IDE, CLI, browser, tool calling, sandbox	모델이 실제 일을 하는 환경이 됨
Data	사용자 edit, accept, retry, 실패 기록	경쟁사가 바로 살 수 없는 학습 재료
Eval	자체 benchmark, verifier, KPI 측정	좋은 결과의 정의를 고정함
RL loop	rollout, reward, 재훈련, 배포	제품을 쓸수록 모델이 좋아지는 구조

open weights 운영은 왜 커질까?

frontier API는 초기 속도 면에서 압도적으로 좋음. 작은 팀은 일단 가장 강한 모델로 제품이 되는지 확인하는 게 맞음
하지만 앱이 커지면 토큰 사용량이 매출원가가 됨. 고객이 많이 쓸수록 API 비용이 같이 늘면, gross margin이 얇아짐
게다가 모델 회사가 같은 앱 영역으로 내려오면, 앱 회사는 공급자와 경쟁자가 같은 상태가 됨. 가격, rate limit, data retention, 모델 정책을 직접 통제하기 어려움
open weights model을 직접 운영하면 처음에는 어렵지만, 반복 업무에서는 비용과 지연 시간을 줄일 수 있음
더 중요한 건 학습 루프임. 자기 domain data로 SFT하고, 자체 환경에서 RL하고, 자체 eval로 배포 여부를 판단하면 제품과 모델이 같이 쌓임

AI 앱 회사의 최종 형태는 무엇인가?

초기는 frontier model + prompt + thin wrapper일 수 있음. 이 단계에서는 속도가 가장 중요함
다음 단계는 routing임. 쉬운 작업은 싼 모델, 어려운 planning은 frontier model, 민감한 작업은 통제된 모델로 나눔
그다음은 owned stack임. 핵심 workflow는 open weights model 위에 자기 데이터, 하네스, eval, RL loop를 붙임
Cursor가 Composer 2를 만든 이유도 여기에 있음. Cursor 안에서 코딩을 잘하는 모델은 범용 코딩 모델과 다른 최적점을 가질 수 있음
Anthropic, OpenAI, Google도 각자 Claude Code, Codex, Antigravity 같은 하네스를 모델과 함께 밀고 있음. 결국 모델 회사도 하네스를 먹고, 앱 회사도 모델을 먹는 방향으로 움직임

모든 AI 앱이 자체 모델을 운영해야 하나요?

아님. 초기 제품 검증 단계에서는 frontier API가 가장 빠르고 안전함. 다만 사용량이 크고, 반복 workflow가 뚜렷하고, 비용이 margin을 압박하기 시작하면 자체 모델 운영을 검토해야 함.

SFT와 RL은 어떻게 다른가요?

SFT는 좋은 예시를 보고 따라 하는 학습에 가까움. RL은 실제 환경에서 여러 번 시도하고 결과 점수로 배우는 방식임. agent가 도구를 쓰고 긴 작업을 끝내야 한다면 RL의 중요성이 커짐.

자체 benchmark는 왜 필요한가요?

모델이 실제 KPI를 올리는지 확인하려면 회사마다 다른 평가 기준이 필요함. 일반 benchmark 점수가 높아도 내 고객의 작업 시간이 줄지 않으면 의미가 약함.

1인기업 관점

1인기업은 처음부터 open weights model 운영까지 가면 너무 무거울 가능성이 큼. 하지만 usedesktop처럼 하네스와 trajectory가 쌓이는 제품이라면, 지금부터 어떤 행동이 좋은 결과인지 eval로 남기는 습관은 필요할 듯. 결국 나중에 모델을 바꾸거나 직접 post-training할 때, 진짜 자산은 코드보다 “검증된 작업 기록”일 수 있음.

Essay 모델과 하네스를 같이 소유해야 한다