Eugene Yan이 글 첫머리에 인용한 Karpathy의 말이 이 글 전체의 정의다. 자율주행 데모를 한 블록 돌게 만드는 데는 며칠이면 되지만, 제품으로 만드는 데는 10년이 걸린다. LLM도 똑같다. ChatGPT API에 프롬프트 한 줄 던지면 그럴듯한 데모가 나오지만, 그걸 신뢰할 수 있는 제품으로 만들려면 7개의 별도 시스템이 필요하다.
근거
“There is a large class of problems that are easy to imagine and build demos for, but extremely hard to make products out of.” — Karpathy
7가지는: Evals, RAG, Fine-tuning, Caching, Guardrails, Defensive UX, User feedback. Yan은 이 7개를 두 축의 좌표에 배치한다 — (1) 성능 향상 vs 리스크/비용 절감, (2) 데이터 쪽 vs 사용자 쪽. 이 좌표계가 강력한 이유는, 어떤 LLM 제품을 봐도 “지금 어디에 투자가 부족한가”를 즉시 짚을 수 있기 때문이다.
예를 들어 ATLAS 트레이딩 에이전트는 Evals(백테스트 Sharpe)와 Guardrails(포지션 한도, stop loss)는 강하지만 Caching과 Defensive UX는 비어 있다 — 사용자가 나 혼자라 후자는 우선순위가 낮다. 좌표 위에 매핑해보면 어디가 부족한지 한눈에 보인다.
이 글이 2023년에 쓰였는데 2026년 지금도 골격이 안 흔들리는 이유는, 7가지 모두 LLM 자체의 특성이 아니라 LLM과 현실 시스템 사이의 인터페이스에 관한 것이기 때문이다. 모델이 더 똑똑해져도 인터페이스 문제는 그대로 남는다.
연결된 생각
- 20260508-no-evals-no-improvement-direction — 7개 중 가장 먼저 깔아야 할 패턴
- 20260508-guardrails-defensive-ux-for-trust — 성능이 아닌 신뢰를 위한 두 패턴
출처
📎 클리핑 · eugeneyan.com