Moat에는 모델이 필요하다: Applied Compute

Applied Compute 엔지니어 Sahar Zadeh는 AI 제품의 moat가 이제 모델 단독이나 wrapper 단독이 아니라, 모델과 제품이 같이 좋아지는 feedback loop에서 나온다고 주장
앱은 모델에게 어떤 작업을 보여주고, verifier는 무엇이 좋은 결과인지 정하고, 사용자 행동은 다음 학습 데이터가 됨. 그래서 model, interface, workflow, data, eval이 분리된 층이 아니라 서로 영향을 주는 하나의 시스템이 됨
외부 frontier API만 쓰면 빠르게 시작할 수 있지만, 가격, 접근권, data retention, 공급자와의 경쟁 위험을 계속 안게 됨
핵심 주장은 “지능을 빌리지 말고 소유하라”임. 자기 데이터로 post-training한 custom model, 자기 workflow, 자기 평가 기준을 함께 가져야 오래 남는 moat가 생긴다는 얘기
Applied Compute에서 leading enterprise의 custom model 훈련, serving, 개선을 하며 얻은 관찰을 정리한 X 글

왜 wrapper만으로는 부족해지나?

지난 2년 동안 많은 AI 제품은 frontier API 위에 좋은 하네스와 UX를 얹는 방식으로 만들어짐. 모델은 빌리고, 제품은 그 위에 만든다는 사고방식
초기에는 이 방식이 맞음. 가장 강한 모델을 쓰면 demo가 빨리 나오고, 고객 반응도 빨리 볼 수 있음
하지만 마지막 10%에서 자주 막힘. 범용 모델은 똑똑하지만, 특정 회사의 업무 방식, 예외 상황, 품질 기준, 사용자 행동을 기본적으로 모름
더 큰 문제는 차별화임. 같은 API, 같은 base intelligence를 경쟁사도 쓸 수 있다면, 지능 자체는 오래 가는 moat가 되기 어려움
Applied Compute의 관점에서는 제품이 커질수록 모델과 하네스를 따로 볼 수 없음. 하네스가 모델이 보는 작업을 정하고, 모델의 실패가 다시 제품 설계를 바꾸기 때문

custom model은 무엇을 바꾸나?

custom model은 모든 회사를 foundation model lab으로 만들자는 말이 아님. 이미 강한 open-weight base model이나 일반 모델을 출발점으로 삼고, 특정 workflow에 맞게 post-training하는 전략에 가까움
목표는 cost, latency, quality의 고정된 선택지를 벗어나는 것임. 큰 frontier model은 좋지만 비싸고 느릴 수 있고, 작은 모델은 싸지만 품질이 부족할 수 있음
자기 데이터와 평가 기준으로 훈련하면, 경쟁사가 바로 살 수 없는 지점을 만들 수 있음. 같은 비용으로 더 빠르거나, 같은 속도로 더 정확하거나, 특정 업무에서는 generalist보다 더 잘하는 모델이 가능해짐
글에서 든 사례는 Cognition, DoorDash, Mercor임. 공통점은 범용 지능을 그대로 쓰는 대신, 자기 업무의 품질 기준을 모델에 직접 먹였다는 점

사례	문제	custom model 효과
Cognition, Windsurf	실시간 bug detection에 frontier model은 너무 느리고 비쌈	frontier 수준 탐지를 약 10배 빠르게 구현
DoorDash	메뉴 오류를 줄이려면 DoorDash식 정답 기준이 필요	critical menu error를 baseline 대비 30% 감소
Mercor	좁은 전문 task에서 일반 모델이 과함	적은 expert-labeled task로 작은 모델을 높은 품질까지 끌어올림

왜 모두가 직접 훈련하지는 못하나?

AI 시스템에는 세 가지 레버가 있음. 하네스, context, model weight임
대부분 팀은 하네스와 context를 먼저 만짐. 프롬프트, retrieval, tool calling, workflow 설계는 상대적으로 접근하기 쉬움
하지만 model weight를 움직이는 훈련은 훨씬 어려움. Applied Compute는 여기서 두 장벽을 말함. 하나는 infrastructure, 하나는 eval임
infrastructure는 단순히 GPU를 빌리는 문제가 아님. 훈련 엔진, sandbox 환경, 채점 pipeline, rollout scheduler, reward gaming을 잡는 observability, production serving이 모두 필요함
특히 long-horizon agent는 작업마다 끝나는 시간이 다름. GPU를 놀리지 않으려면 sampling, grading, learning이 동시에 돌아가는 비동기 훈련 시스템이 필요함
eval은 더 어렵게 과소평가됨. “좋은 결과”라는 감각을 self-consistent reward로 바꾸지 못하면, 모델은 틀린 지름길을 아주 효율적으로 배움

rented intelligence와 owned intelligence는 어떻게 다른가?

구분	rented intelligence	owned intelligence
시작 속도	빠름	느림
비용 구조	사용량이 커질수록 API 비용이 누적	초기 구축비가 크지만 반복 업무에서 단가를 낮출 수 있음
차별화	경쟁사도 같은 모델을 빌릴 수 있음	데이터, eval, workflow가 쌓일수록 복제하기 어려움
통제권	가격, 정책, data retention이 공급자에 좌우됨	무엇을 학습하고 어디에 배포할지 직접 결정
적합한 단계	초기 검증, broad reasoning, 어려운 판단	반복 workflow, 핵심 제품 기능, margin을 좌우하는 작업

결론은 frontier model을 쓰지 말자는 것이 아님. 대부분의 AI 시스템은 앞으로도 일반 모델, retrieval, tool, context를 많이 쓸 것임
다만 제품의 핵심 workflow, gross margin, 장기 moat를 좌우하는 부분은 “경쟁사도 같은 계약으로 빌릴 수 있는 지능”인지 확인해야 한다는 얘기
Applied Compute는 이 지점을 model-harness co-design이라고 부름. 모델을 제품에 맞추고, 제품도 모델이 배우기 좋은 방식으로 바꾸는 설계임

custom model은 언제 필요할까요?

반복되는 workflow가 있고, 그 workflow의 성공 여부를 비교적 명확히 평가할 수 있을 때 필요해짐. 특히 API 비용이 margin을 압박하거나, 일반 모델이 회사 내부 기준을 안정적으로 못 맞출 때 검토할 만함.

작은 회사도 custom model을 훈련할 수 있나요?

처음부터 큰 모델을 pretraining하는 것은 어렵지만, open-weight base model 위에 좁은 task를 post-training하는 방식은 점점 현실적이 되고 있음. 다만 데이터보다 eval과 verifier를 먼저 정리해야 함.

model-harness co-design이란 무엇인가요?

모델과 제품 하네스를 따로 최적화하지 않고 같이 설계하는 접근임. 제품은 모델이 어떤 작업을 보고 어떤 피드백을 받는지 정하고, 모델의 성능 변화는 다시 제품의 workflow와 UX를 바꿈.

1인기업 관점

1인기업은 처음부터 custom model을 붙잡으면 느려질 가능성이 큰 듯함. 다만 usedesktop처럼 반복 workflow와 검증 가능한 trajectory가 쌓이는 제품이라면, 어느 순간 frontier API 호출을 줄이고 자기 verifier와 post-training loop로 옮겨야 할 듯. 결국 moat는 “내가 만든 앱”이 아니라, 그 앱 안에서만 생기는 실패와 수정 기록을 모델이 계속 먹는 구조일 수 있음.

Moat에는 모델이 필요하다: Applied Compute (x.com) ↗