오픈 모델이 AI의 경제학을 바꾸는 방식

URL: https://www.youtube.com/watch?v=rY0wnfFHYbs 원문 제목: Open Models Change The Economics of AI 날짜: 2026-09-05 채널: ycombinator (Y Combinator) 출연: Jeffrey Morgan — Ollama 공동창업자·CEO

---

📌 핵심 질문 / 핵심 논점

==오픈 모델(Open Model)은 토큰 비용을 급격히 낮추고, 모델 선택·호스팅·오케스트레이션의 통제권을 사용자에게 돌려주면서 AI 사용량의 경제학을 바꾼다.== 기업의 대부분의 토큰은 오픈 모델로 이동하지만, 가장 어려운 문제에는 프런티어 폐쇄 모델이 남고, 두 세계를 잇는 라우터·하네스·보안·인프라·큐레이션이 새로운 핵심 사업이 된다.

• 코딩 에이전트(Coding Agent)와 OpenClaw·Hermes 같은 업무 자동화가 오픈 모델 사용량을 폭발시켰다.
• 오픈 모델은 미국·유럽·중국 모델을 가리지 않고 기업에 도입되며, 실제 소비 토큰 기준으로는 중국계 모델의 클라우드 사용이 압도적이다.
• 80~90%의 기업 토큰이 오픈 모델로 흐를 수 있지만, 비용 지출 비중은 10~20%에 그칠 수 있다.
• 로컬 모델과 클라우드 모델을 난이도별로 라우팅하면 쉬운 업무는 하드웨어에서 거의 무료로 처리하고 어려운 업무만 고가 모델에 보낼 수 있다.
• 모델·추론 엔진·클라우드·하드웨어·하네스가 파편화될수록 개발자가 실제로 원하는 것은 더 많은 모델이 아니라 모든 조합을 일관되게 작동시키는 통합이다.

AI의 경제적 병목은 단순한 모델 지능에서 토큰 가격, 실행 위치, 상태·메모리, 보안, 도구 호출, 운영 안정성으로 이동했다. 값싸고 충분히 똑똑한 플래시 모델을 여러 개 묶는 작업 구성(Task Composition)은 하나의 ‘신 모델’보다 반복 가능하고 신뢰할 수 있는 시스템을 만들 수 있으며, 그 위의 통합 계층이 오픈 모델 생태계의 가장 큰 기회가 된다.

1. 기업 AI 수요가 오픈 모델로 이동하는 이유

1.1. 비용 절감에서 통제권·맞춤화로

1. 토큰 비용은 오픈 모델이 가장 먼저 해결할 기업 고충이다

   1. 기업은 우선 토큰 비용을 낮추기 위해 오픈 모델을 검토한다. 비용은 단기간에 바로 개선할 수 있는 문제다.
   2. 비용 절감은 최종 목적이 아니라 더 많은 실험과 사용량을 가능하게 하는 전제다. 기업은 절약한 여력으로 모델을 자기 업무에 맞게 커스터마이즈한다.
   3. 기업의 장기적인 북극성(North Star)은 AI를 더 잘 통제하고 자기 사업에 맞게 조정하는 것이다. 오픈 모델은 모델을 직접 선택·호스팅·파인튜닝할 수 있게 한다.

2. 파인튜닝에 대한 관심은 모델 출시 주기와 함께 되살아났다

   1. 2024년 초에는 자체 커스텀 모델을 파인튜닝하려는 관심이 컸다.
   2. 곧 새 모델이 나오면 기존 파인튜닝 결과가 쓸모없어지고 다음 모델 출시가 기존 작업을 짓밟을 것이라는 우려가 커지면서 관심이 사라졌다.
   3. 오픈 모델 출시 주기가 다시 빨라지고 모델 성능·툴링(Tooling)이 개선되면서 파인튜닝 수요가 돌아오고 있다.

1.2. 기업 도입을 견인하는 사용 사례

1. 코딩 에이전트가 오픈 모델 토큰 소비의 중심이다

   1. 개발자별 토큰 사용량의 급증은 코딩 에이전트가 주도했다.
   2. Kimi, GLM, MiniMax 계열 모델이 코딩 에이전트를 실제로 구동할 수 있는 수준에 도달하면서 오픈 모델의 초기 상승세가 시작됐다.
   3. AT&T는 이미 전체 토큰 소비의 40%를 오픈 모델로 전환했다. 현재 전환분은 주로 미국·유럽 모델이며, 중국 모델도 평가하고 있다.

2. 에이전트가 비개발자에게도 장시간 업무 자동화를 열었다

   1. OpenClaw는 3~4월에 급성장했고 이후 Hermes 에이전트 프로젝트도 성장했다.
   2. 사용자는 어려운 문제를 오픈 모델에 맡기고 오랜 시간 작업을 계속 수행하게 할 수 있다. 에이전트는 도구 선택, 데이터 조회, 단계별 추론을 반복하기 때문에 일반적인 단일 질의보다 훨씬 많은 토큰을 소비한다.
   3. 금융·고객지원·마케팅·영업 팀처럼 전통적으로 개발자가 아니었던 사용자도 이 방식으로 업무를 자동화한다.

3. 보안 테스트는 폐쇄 모델보다 오픈 모델의 장점이 분명한 영역이다

   1. 오픈 모델을 사용하면 자기 소프트웨어를 직접 테스트하고 침투 테스트(Penetration Test)할 수 있다.
   2. OpenClaw 같은 기본 에이전트는 제품을 해킹하라는 요청을 안전 정책 때문에 거부할 수 있다.
   3. Hugging Face에는 보안 연구자를 위해 훈련됐거나 공격 문제에 더 자유롭게 대응하도록 조정된 모델이 있다. 선의의 보안 테스트를 악의적 공격과 구분하는 모델도 있다.
   4. Hugging Face가 프런티어 모델의 해킹을 탐지하는 데 오픈웨이트(Open-Weight) 모델을 사용한 사례는 이 역설을 보여준다. 최첨단 모델의 약점을 같은 종류의 폐쇄 모델만으로 검사할 필요가 없어진다.

2. Ollama 클라우드의 토큰 데이터가 보여주는 성장 곡선

2.1. 개발자 한 명당 사용량이 급증한 두 번의 변곡점

1. 그래프는 Ollama 전체가 아니라 개인별 주간 토큰 사용량을 보여준다

   1. Ollama Cloud의 그래프는 모든 사용자의 토큰을 합친 총량이 아니라 개발자 한 명이 일주일에 사용하는 평균 토큰 수다.
   2. 그래프가 회사 전체 성장처럼 보이지만 실제로는 개인 사용량이므로 OpenClaw 이후의 사용 행태 변화를 더 선명하게 보여준다.

2. 첫 번째 변곡점은 코딩 에이전트였다

   1. 연초의 첫 상승은 Kimi, GLM, MiniMax 모델 출시와 함께 시작됐다.
   2. 초기에는 개발자들이 모델을 사용해 코딩 문제를 해결했고, 오픈 모델이 코딩 에이전트를 구동할 수 있다는 사실이 수요를 만들었다.
   3. OpenClaw 도약 전 개인별 사용량은 대략 1,500만 토큰 이하였고, OpenClaw가 이 수치를 대략 5배 끌어올렸다.

3. 두 번째 변곡점은 OpenClaw가 비개발자에게 장시간 작업을 제공한 순간이었다

   1. 4월 OpenClaw 성장으로 개인별 토큰 사용량이 다시 폭발했다.
   2. OpenClaw는 단순 답변이 아니라 도구·데이터·하위 작업을 계속 호출하므로 하나의 과제를 완료하는 동안 엄청난 토큰을 사용한다.
   3. 오픈 모델의 컨텍스트 윈도우(Context Window)는 128K에서 100만 토큰 이상으로 확장됐다. 긴 작업을 이어갈 수 있는 컨텍스트와 도구 사용이 폭발적 사용량을 가능하게 했다.
   4. 전체 Ollama Cloud 기준 성장은 연초 이후 150배에 달했고, OpenClaw 도약만으로도 10~20배 이상 증가한 것으로 추정된다.

2.2. 커스텀 모델에서 즉시 사용 가능한 오픈 모델로

1. 2024~2025년의 주류는 오픈 모델을 파인튜닝해 제공하는 방식이었다

   1. 기업은 DeepSeek나 Kimi 같은 기성 모델을 가져와 자기 사용 사례에 맞게 파인튜닝했다.
   2. Cursor가 오픈 모델을 커스텀해 대규모로 서비스한 사례가 대표적이다.
   3. 이 방식은 모델 자체보다 특정 제품의 사용 사례·데이터·운영 노하우가 중요했다.

2. 2026년 초부터는 기본 상태의 오픈 모델을 그대로 제공하는 수요가 폭발했다

   1. 개발자는 모델을 다시 훈련하지 않아도 새 모델을 바로 애플리케이션에 연결할 수 있게 됐다.
   2. 출시 주기가 짧아져 최신 모델을 시험하고 교체하는 속도가 빨라졌다.
   3. 파인튜닝이 사라진 것이 아니라, 빠른 모델 교체와 더 나은 툴링으로 인해 커스텀 모델을 계속 최신 상태로 유지할 수 있는 조건이 만들어졌다.

3. 빠른 출시 주기와 Day-Zero 통합의 운영 문제

3.1. 오픈 모델·프런티어 모델의 출시 속도

1. 모델 출시 주기는 계속 짧아지고 있다

   1. 폐쇄형 프런티어 모델도 이전보다 빠르게 출시된다.
   2. 오픈 모델 쪽에서는 한여름에 DeepSeek Flash가 이미 세 번 반복 출시됐다. 과거의 6개월 주기가 훨씬 짧아진 셈이다.
   3. 프런티어 모델이 안전성·정렬(Alignment)·통제(Containment)를 해결하기 위해 속도를 늦출 가능성이 있는 반면, 오픈웨이트 모델은 계속 성능을 높일 수 있다.

2. 새 모델 출시 속도와 기업의 파인튜닝 유지 비용은 서로 충돌한다

   1. 출시가 빨라질수록 특정 버전에 맞춘 커스텀 모델이 빠르게 낡는다.
   2. 반대로 파인튜닝 툴링과 평가 자동화가 좋아지면 팀은 변화하는 모델 위에서 커스텀 모델을 계속 유지할 수 있다.
   3. 오픈 모델과 프런티어 모델의 성능 격차가 좁아질수록 기업은 새 모델을 기다리지 않고 직접 실험·선택하려 한다.

3.2. 성공적인 Day-Zero 모델 출시 플레이북

1. 추론 엔진에 모델을 먼저 올려야 한다

   1. 새 모델이 선호하는 추론 엔진(Inference Engine)에서 지원되는지 확인한다.
   2. 모델을 빠르게 실행하고, 정확도를 확보하고, 연구팀이 공개한 레퍼런스 스펙과 일치시키는 과정은 때로 몇 주가 걸린다.
   3. 모델 가중치를 내려받는 것만으로는 출시가 끝나지 않는다. 실제 서비스에서의 속도·정확도·호환성이 필요하다.

2. 새 기능에 맞는 하네스와 사용 사례를 준비해야 한다

   1. 모델이 새로운 기능을 제공하면 개발자가 이를 활용할 수 있는 하네스(Harness)와 애플리케이션 연결을 찾아야 한다.
   2. DeepSeek는 대형 LLM 관점에서 첫 멀티모달(Multimodal) 모델을 출시했다. 기존에는 더 작은 OCR 모델이 중심이었지만, 대형 멀티모달 모델은 훨씬 많은 사용 사례를 열었다.
   3. DeepSeek 하네스도 이 멀티모달 기능을 지원하도록 바뀌었다. 모델뿐 아니라 모델을 실제로 구동하는 하네스까지 함께 준비해야 한다.

3. 모델·하네스·하드웨어·프로바이더를 한 묶음으로 제공해야 한다

   1. 첫 번째 요소는 모델을 쉽게 쓰게 하는 하네스 또는 SDK다. OpenAI Codex 하네스와 OpenCode는 대표적인 오픈소스 하네스이며 Ollama 사용자 사이에서 OpenCode의 인기가 높다.
   2. 두 번째 요소는 모델을 패키징하고, 안정적으로 접근하게 하고, 클라우드라면 Day Zero의 폭증을 감당할 용량을 확보하는 일이다. 새 모델은 출시 당일 가장 큰 성장세를 보이는 경우가 많다.
   3. 세 번째 요소는 하드웨어와 추론 프로바이더다. Nvidia와 협력해 모델을 최적화하거나 Apple Silicon 스택에서 빠르게 실행해야 한다.
   4. 모델이 아무리 유능해도 너무 느리면 사용 경험은 나쁘다. 세 요소가 모두 갖춰져야 ‘모델을 출시했다’고 할 수 있다.

4. 실제 출시 직전에는 화재 훈련 같은 통합 작업이 벌어진다

   1. 모델을 몇 주 일찍 받을 수 있으면 다행이지만, 많은 부분은 출시 24시간 전에야 맞춰진다.
   2. 각 모델의 아키텍처 변경, 도구 호출 방식, 컨텍스트 규칙이 모두 달라 조합별 테스트가 어렵다.
   3. 최종 출시 전에 연구팀이 제시한 기준과 동일하게 동작하는지 벤치마크해야 한다. 이 검증이 Day-Zero 신뢰도를 만든다.

4. 오픈 모델 스택과 ‘레이어 케이크’의 재구성

4.1. Ollama의 역할은 모델 운영체제에 가깝다

1. 운영체제 비유는 하드웨어부터 애플리케이션까지 연결하는 일을 설명한다

   1. 전통적인 운영체제는 하드웨어 드라이버, 애플리케이션 런타임, 각 앱의 호환성을 연결한다.
   2. Ollama는 하드웨어·프로바이더·추론 계층과 애플리케이션·하네스를 연결해 오픈 모델에서도 비슷한 경험을 재현하려 한다.
   3. 오픈 모델 생태계는 모델, 드라이버, 칩, 에너지, 클라우드, 앱을 서로 다른 회사가 제공하므로 조합 수가 조합적으로 폭발한다. 이를 공통 런타임으로 묶어 어떤 하네스든 어떤 모델과 연결하게 하는 것이 핵심이다.

2. 모델 계층에는 가중치 이상의 구성 요소가 숨어 있다

   1. 모델 계층에는 모델 가중치뿐 아니라 각 모델이 잘하는 오케스트레이션(Orchestration) 구성 요소가 있다.
   2. 개발자 API 계층도 모델과 애플리케이션 사이에 존재한다.
   3. 실제 오픈 모델 스택은 Jensen Huang이 말한 앱·모델·인프라·칩·에너지의 5층 케이크보다 더 많은 숨은 층을 가진다.
   4. “레이어를 레이어링한다(layer the layers)”는 표현이 오픈 모델 스택의 중첩을 농담처럼 압축한다.

4.2. 지식·조정·실행이라는 세 가지 숨은 문제

1. 지식(Knowledge)은 회사 데이터와 컨텍스트를 모델에 연결한다

   1. 기업은 자기 문서·데이터·업무 맥락을 모델에 공급해야 한다.
   2. 모델 가중치에 모든 회사 데이터를 넣는 방식보다 외부 지식 계층과 검색·메모리 계층을 연결하는 방식이 유연하다.

2. 조정(Coordination)은 에이전트와 하위 에이전트를 관리한다

   1. 클라우드 앱이나 Codex에 요청하면 여러 하위 에이전트가 생성될 수 있다.
   2. 일부 하위 에이전트는 클라우드에서, 일부는 로컬에서 실행된다. 작업을 어느 에이전트에 보낼지, 결과를 어떻게 합칠지, 순서를 어떻게 정할지가 조정 문제다.

3. 실행(Execution)은 샌드박스와 클라우드 컴퓨팅을 요구한다

   1. 에이전트가 코드를 실행하고 파일을 다루려면 샌드박스(Sandbox)가 필요하다.
   2. 점점 더 많은 에이전트가 클라우드로 이동하면서 에이전트 실행을 위한 대규모 컴퓨트가 새로운 인프라 문제가 된다.

4. 숨은 계층은 독립 회사나 프로바이더로 분리될 수 있다

   1. 초기 클라우드에서는 Heroku와 Google App Engine처럼 많은 기능을 묶은 제품이 주류였다.
   2. 시간이 지나면서 개발자는 각 문제에 가장 잘 맞는 Best-of-Breed 제품을 조합하는 방식을 선호했다.
   3. 지식·조정·실행·메모리·보안·자격 증명 계층도 같은 방식으로 분리돼 전문 회사가 될 가능성이 있다.

4.3. 번들링과 언번들링, 그리고 잠금 효과

1. 프런티어 랩은 통합된 월드 가든을 선호한다

   1. 프런티어 모델 회사는 관리형 에이전트, 컨텍스트, 메모리 계층을 모두 자기 플랫폼에 묶으려 한다.
   2. 고객 입장에서는 한 업체의 모델·메모리·에이전트에 모두 의존하는 대신 여러 모델을 비교하고 자기 데이터를 통제하고 싶어 한다.
   3. 오픈소스 개발자와 창업자는 특정 플랫폼에 갇히는 것을 피하기 위해 각 계층을 분리해 구축한다.

2. 오픈 모델은 잠금 효과를 약화시킨다

   1. 모델이 좋아질수록 애플리케이션을 특정 제공자의 메모리나 에이전트에 묶을 이유가 줄어든다.
   2. 예를 들어 어느 날 OpenAI 메모리 시스템을 사용하다가 자기 메모리 시스템과 계속 동기화하는 에이전트를 만들 수 있다.
   3. MCP(Model Context Protocol)와 런타임 테스트를 이용하면 메모리 구현을 바꿔도 애플리케이션은 계속 작동할 수 있다.
   4. 한 개발자가 cron이 Markdown 파일과 TypeScript를 실행하는 구조만으로 에이전트를 만들면, 모델 제공자를 바꿔도 핵심 워크플로는 남는다.

3. 상태가 있는 문제는 모델 내부에 완전히 넣기 어렵다

   1. 저장소·사용자 기록처럼 상태(State)가 필요한 문제는 외부 계층에 남는다.
   2. 모델은 학습이 끝난 고정된 산출물이고, 최신 데이터와 지속적으로 변하는 사용자 상태를 스스로 보관하지 않는다.
   3. 모델 학습이 월 단위로 이뤄져도 최신 데이터와 완전히 일치하지 않는다. 따라서 저장·메모리·자격 증명·보안은 모델 계층 바깥에 남을 가능성이 크다.

4. 개방성은 보안 계층을 자동으로 제공하지 않는다

   1. 폐쇄 모델 프로바이더는 안전 정책·모니터링·권한 관리를 기본 제공하지만 오픈 모델은 이를 별도로 구축해야 한다.
   2. 기업 도입의 가장 큰 장애물은 오픈 모델의 지능보다 보안·안전·거버넌스다.
   3. 안전한 실행 환경, 모델 스크리닝, 권한 제한, 감사 로그를 제공하는 회사가 오픈 모델 확산을 가속할 수 있다.

5. 폐쇄 모델과 오픈 모델의 정상 상태

5.1. 토큰 비중과 예산 비중은 달라진다

1. 기업 토큰의 80~90%가 오픈 모델로 이동할 수 있다

   1. 대부분의 기업 토큰이 오픈 모델을 통과할 것이라는 전망이 제시됐다.
   2. 이 수치는 오픈 모델에 기업 예산의 80~90%를 쓴다는 뜻이 아니다.
   3. 오픈 모델 커뮤니티가 비용을 낮추면 기업은 전체 지출의 10~20%만 오픈 모델에 써도 대부분의 토큰을 처리할 수 있다.

2. 비용이 낮아지면 사용량 제한이 사라진다

   1. 기업은 팀에게 토큰을 아껴 쓰라고 말하는 대신, 더 많은 실험·자동화·반복 실행을 허용할 수 있다.
   2. 토큰이 풍부해지면 에이전트가 여러 단계를 시도하고 실패를 복구하는 방식이 경제적으로 가능해진다.
   3. 값싼 토큰은 새로운 애플리케이션을 만드는 것뿐 아니라 기존 업무를 더 깊게 자동화하는 경제성을 만든다.

5.2. 어려운 문제는 프런티어 모델, 중간 문제는 조합형 시스템

1. 최고 난도의 업무는 계속 프런티어 모델이 맡는다

   1. 가장 뛰어난 연구자와 가장 큰 컴퓨트가 있는 프런티어 랩은 어려운 문제에서 우위를 유지한다.
   2. 에이전트는 작업 난이도를 판단해 가장 어려운 문제에만 프런티어 모델을 호출할 수 있다.
   3. 라우터가 프런티어 모델로 스케줄링·고난도 오케스트레이션을 수행하고, 반복적인 한 줄 작업은 오픈 모델에 맡기는 구조가 가능하다.

2. 오픈 모델과 폐쇄 모델은 파트너·어소시에이트 조직처럼 협업할 수 있다

   1. 로펌의 파트너가 판단·지시를 하고 여러 어소시에이트가 세부 작업을 수행하는 구조와 비슷하다.
   2. 프런티어 모델이 작업을 쪼개고 오픈 모델이 각각의 세부 작업을 수행하면 비용과 품질을 함께 최적화할 수 있다.
   3. Sakana AI와 OpenRouter가 두 종류의 모델을 결합한 프로젝트에서 좋은 결과를 보여줬다.

3. 클라우드 컴퓨팅도 같은 혼합 패턴을 거쳤다

   1. AWS DynamoDB 같은 클라우드 제공자의 독점 서비스와 PostgreSQL 같은 오픈·표준 데이터베이스를 함께 사용하는 고객이 많다.
   2. 한쪽이 모든 기능을 독점하는 것보다 작업별로 적절한 도구를 선택하는 편이 유리하다.
   3. Apple Silicon이 이미지·오디오 등 작업별 특수 가속기를 제공하는 것도 같은 설계 원리다. 과거 PC에서 별도 오디오 카드와 그래픽 카드를 쓰던 방식이 칩 안으로 통합된 셈이다.

6. 로컬·클라우드 하이브리드 실행과 하드웨어 르네상스

6.1. 난이도에 따른 로컬·클라우드 라우팅

1. 쉬운 업무는 로컬에서 더 빠르고 싸게 처리할 수 있다

   1. 문서 분류·추출처럼 종단 간 문제가 상대적으로 단순한 업무는 노트북이나 사내 하드웨어에서 실행할 수 있다.
   2. 로컬 실행은 네트워크 지연이 없고 토큰당 비용이 거의 없으며 데이터가 기기 밖으로 나가지 않는다.
   3. 어려운 코딩 에이전트 업무는 대형 클라우드 모델이 더 효과적이다. 복잡한 코드·테스트·도구 호출을 처리하려면 큰 모델이 필요하다.

2. 라우터가 쉬운 업무와 어려운 업무를 나눈다

   1. 로컬 모델이 먼저 간단한 작업을 처리한다.
   2. 라우터는 복잡도·컨텍스트·도구 요구사항을 판단해 필요한 경우 대형 클라우드 모델로 넘긴다.
   3. 기업은 이미 구매한 노트북·워크스테이션에서 로컬 모델을 거의 무료로 돌리고, 일부 작업만 클라우드 비용으로 지불한다.

3. 로컬과 클라우드 모델의 사용 조합은 지역·출신에 따라 다르다

   1. 로컬 모델에서는 미국과 중국 학습 모델이 강하게 경쟁하며, 유럽 모델까지 포함해 균형 잡힌 조합이 나타난다.
   2. Llama 계열 모델과 Google DeepMind의 Gemma 모델은 로컬 실행에 좋은 선택지다.
   3. 클라우드 코딩 에이전트에서는 중국계 모델 소비가 현재 압도적이다.
   4. 그래프상 로컬 모델의 미국·중국 비중은 거의 동률인 반면, 클라우드 호스팅 모델은 중국 모델이 사실상 100%에 가깝다. 미국 쪽 막대가 x축을 다시 칠하는 것처럼 보일 정도로 중국 모델이 클라우드 사용을 차지한다.

6.2. 개인 데스크톱에서 20B~400B 모델을 실행하는 시대

1. 소비자용 하드웨어가 실행 가능한 모델 크기를 빠르게 늘린다

   1. 차세대 하드웨어는 20B~40B 파라미터 모델을 매우 잘 실행하고, 경우에 따라 128B 모델까지 다룬다.
   2. Qwen 3.8 38B는 코딩 벤치마크에서 Opus 4.6과 비슷한 성능을 보인다.
   3. 이 모델은 매장에서 살 수 있는 최저 메모리 MacBook보다 한 단계 높은 메모리의 MacBook에서도 실행할 수 있다.

2. Nvidia와 Apple이 개인용 AI 컴퓨팅을 만든다

   1. Nvidia는 오픈소스 모델과 생태계를 지원하면서 하드웨어 우위를 유지하는 전략을 취한다.
   2. Nvidia의 DGX Station에는 GB300이 탑재된다. “어떻게 하면 귀를 먹먹하게 시끄럽지 않은 제품을 받을 명단에 오르나?”라는 농담은 장비 소음과 희소성을 함께 드러낸다.
   3. DGX Station은 프런티어 모델을 느리게 실행할 수 있는 20만~30만 달러대 장비로 소개됐고, 실제 가격은 그보다 더 경쟁력 있을 수 있다.
   4. 고속으로 프런티어 모델 이상을 실행하면서도 전통적인 워크스테이션 가격과 크게 다르지 않은 지점까지 내려오고 있다.

3. 기업 워크스테이션과 DGX Spark가 로컬 모델을 현실화한다

   1. 은행·산업 기업은 엔지니어의 책상마다 Nvidia 워크스테이션 GPU를 이미 설치하고 있다. 어떤 고객은 RTX A6000 계열 GPU를 수만 대 보유한다.
   2. DGX Spark는 GTC에서 공개됐고, Ollama 팀은 Elon Musk 등과 함께 초기 수령자에 포함됐다.
   3. DGX Spark는 128GB 통합 메모리를 제공해 20B~120B 모델을 책상 위에서 실행한다.
   4. 빠른 네트워크 링크로 여러 대를 연결하면 책상 위 미니 데이터센터 랙처럼 구성해 400B 모델도 실행할 수 있다. Mac mini 여러 대를 쌓아 쓰는 관행의 생산 버전과 같은 발상이다.
   5. Apple Mac Studio와 소형 Mac은 MLX 프로젝트의 성숙한 스택으로 LLM을 실행한다. DGX Spark와 Apple 플랫폼은 모두 경쟁력 있지만, 무엇을 구할 수 있는지와 원하는 기술 스택에 따라 선택이 달라진다.

4. 로컬→클라우드→로컬의 실행 경로가 다시 바뀐다

   1. Ollama는 처음 로컬 실행에서 출발했다.
   2. 현재 코딩 에이전트 수요는 클라우드에 집중됐지만 하드웨어가 따라잡으면 다시 로컬로 돌아올 수 있다.
   3. 책상 위 GB300 같은 하드웨어가 충분히 빨라지면 코드 테스트나 편집기 변경만큼 빠른 코딩 루프가 가능하다.
   4. GitHub Copilot 자동완성이 수십~100밀리초 안에 나타나던 경험처럼, 대형 모델의 즉각적인 반응도 책상으로 돌아올 수 있다.
   5. 최종 형태는 로컬과 클라우드를 함께 쓰는 하이브리드다.

6.3. GPU 공급과 추론 프로바이더의 경제학

1. B200·B300 GPU 확보는 스타트업에 어렵다

   1. 최신 모델을 실행하려면 B200·B300 같은 GPU가 필요하지만 공급·수요 변동성이 높다.
   2. 가격도 빠르게 변하고, 작은 스타트업이 필요한 수량을 직접 확보하기 어렵다.
   3. Ollama는 여러 추론 프로바이더와 협력해 GPU를 모아 수요를 맞춘다.

2. 모델 배치에는 운영상의 다변수 문제가 있다

   1. 어떤 모델을 어느 리전에 배치할지 정해야 한다.
   2. 각 모델이 얼마나 빨라야 하는지, 고객과의 지연시간이 얼마인지, 어느 프로바이더가 어떤 하드웨어를 갖췄는지 계산해야 한다.
   3. 이런 배치·용량·지연시간 문제는 모델 연구만으로 해결되지 않는 시스템 엔지니어링 문제다.

3. 통합 서비스는 개발자가 GPU 시장을 직접 상대하지 않게 한다

   1. OpenRouter·Ollama·OpenCode를 사용하면 개발자는 B200·B300 가격을 협상하거나 24개월 사용량 예측을 제시하지 않아도 된다.
   2. 개발자는 한 API나 하네스로 여러 모델을 시도하고, 작업에 더 잘 맞는 모델로 바꿀 수 있다.
   3. 인프라의 복잡성을 숨기는 통합 계층이 오픈 모델의 실제 접근성을 만든다.

7. 값싼 Flash 모델과 ‘God Model’ 논쟁

7.1. 무제한 토큰 경제를 여는 Flash 모델

1. 스타트업은 토큰당 비용보다 작업당 비용을 봐야 한다

   1. DeepSeek Flash는 토큰당 비용이 매우 낮고, 한 작업을 완료하는 비용도 낮은 새 모델군의 예다.
   2. 저렴한 토큰만으로는 충분하지 않다. 일정한 작업을 빠르고 안정적으로 완료하는 총비용이 중요하다.
   3. 이런 모델은 제한된 예산의 스타트업이 사용량을 줄이지 않고 제품을 만들게 한다.

2. ‘무제한 토큰’은 다시 현실적인 제품 목표가 된다

   1. ChatGPT가 처음 널리 쓰일 때 사용자는 요청마다 토큰 수를 계산하지 않고 매일 사용했다.
   2. Flash 모델은 충분히 좋은 지능·빠른 속도·초저가를 결합해 그 경험을 기업 업무에도 가져올 수 있다.
   3. 이를 위해 모델 아키텍처 자체가 대량 토큰 사용에 맞게 설계·훈련돼야 한다.
   4. 오픈 모델은 이미 프런티어 지능 격차를 3개월 이내로 줄였고, 다음 과제는 극단적인 효율성이다.
   5. GPT Luna로 불린 가격 효율적인 모델이 팀 단위의 광범위한 도입을 촉진한 사례처럼, 오픈 모델도 같은 확산을 만들 수 있다.

3. Flash 모델은 AI 업무의 워크호스가 된다

   1. Flash 모델은 모든 문제에서 최고는 아니지만 80%의 업무를 충분히 해결한다.
   2. 빠르고 값싸기 때문에 반복적인 초벌 작업과 ‘잡일(grunt work)’에 적합하다.
   3. 사용자는 호출 수나 토큰 수를 매번 걱정하지 않고 더 많은 작업을 맡길 수 있다.
   4. 여러 Flash 모델을 서로 다른 역할로 체인(Chain)하면 단일 대형 모델보다 높은 처리량과 더 나은 결과를 낼 수 있다.
   5. 값싼 모델을 연결·검증·재시도·합성하는 오케스트레이션 계층은 스타트업·추론 프로바이더·업무 플랫폼 모두의 기회다.

7.2. 하나의 신 모델보다 작업 구성(Task Composition)

1. ‘모든 일을 하는 거대한 신 모델’ 가설은 아직 실현되지 않았다

   1. AGI 논의 초기에는 하나의 거대한 모델이 모든 일을 해결할 것이라는 전망이 많았다.
   2. 실제로는 업무별로 적절한 작은 모델을 조합하는 방식이 더 반복 가능하고 신뢰할 수 있으며 비용도 감당할 수 있다.
   3. 미국 국가안보국을 실제로 해킹하는 것처럼 극도로 어려운 문제라면 Mythos로 들리는 최고급 모델이 필요할 수 있지만, 대부분의 기업 업무에는 그 정도가 필요하지 않다.

2. ‘충분히 좋은’ 지점이 많은 기업 업무를 오픈 모델로 이동시킨다

   1. 많은 고객 업무는 특정 수준의 지능에 도달하면 더 이상 최고 성능을 요구하지 않는다.
   2. 그 이후에는 모델이 더 빨라지거나 아키텍처가 좋아지거나 새 기능이 추가되는 편이 중요하다.
   3. 일상적인 기업 업무는 가장 어려운 문제가 아니더라도 오픈 모델이 해결할 만큼 충분히 어렵기 때문에 오픈 모델의 강점이 된다.

3. 오픈 모델도 God-Tier가 될 가능성이 있다

   1. Z.ai와 GLM은 특정 작업에서 프런티어 수준의 성능을 내고 있다.
   2. Kimi는 웹 개발에서 가장 좋은 모델이 된 순간이 있었고, 시장의 경쟁 구도를 단순한 성능 격차에서 정면 경쟁으로 바꿨다.
   3. 오픈 모델이 범용 God-Tier 모델이 될 가능성도 있으며, 이런 head-to-head 경쟁은 모델 생태계 전체를 더 빠르게 발전시킨다.

8. 모델 출신·호스팅 위치·보안에 관한 지정학

8.1. 고객이 구분하는 ‘어디서 만든 모델’과 ‘어디서 실행하는 모델’

1. 모델의 출신 국가보다 실행 환경을 중시하는 고객이 있다

   1. 일부 고객은 미국·중국·유럽 중 어디에서 모델을 훈련했는지보다 데이터가 어느 리전에서 처리되는지를 중요하게 본다.
   2. 미국 기업이 미국 내 보안 환경에서 중국계 모델을 실행하는 경우처럼, 호스팅 위치·접근권·데이터 흐름을 통제하면 도입이 가능하다고 판단한다.

2. 모델의 출신 자체를 중시하는 고객도 있다

   1. 어떤 고객은 모델 훈련 데이터의 출처와 학습 방식까지 확인한다.
   2. 이는 순수한 보안 문제만이 아니다. 모델이 말하는 방식, 문화적 뉘앙스, 로봇처럼 들리는지 친근하게 들리는지까지 모델 출신·훈련에 영향을 받는다.
   3. 미션 크리티컬한 업무에서는 모델이 어떤 데이터로 만들어졌는지 끝까지 추적하고 설명할 수 있어야 한다.

3. Nemotron 계열은 모델 구성과 출처를 들여다볼 수 있는 사례다

   1. Nvidia의 Nemotron 모델은 무엇이 모델을 구성했는지 내부를 조사할 수 있는 방향성을 보여준다.
   2. 사용자는 단순히 모델 이름을 믿는 것이 아니라 데이터·훈련·가중치 계보를 점검해야 한다.

8.2. 미션 크리티컬한 운영과 ‘맨처리언 후보’ 문제

1. 오픈 모델은 이미 핵심 인프라에 사용된다

   1. 핀란드 발전소의 분석 시스템은 Llama를 사용해 전력 급증을 감지하고 불이 계속 켜져 있도록 돕는다.
   2. 오픈 모델은 장난감이나 개인용 실험이 아니라 전력·산업·금융 같은 미션 크리티컬한 시스템에 들어가고 있다.

2. 중국 모델에 숨겨진 악성 동작이 있을 가능성을 점검해야 한다

   1. 중국에서 훈련된 모델을 미국에서 호스팅해도 내부에 문제를 일으키는 동작을 심어둘 수 있지 않느냐는 ‘맨처리언 후보(Manchurian Candidate)’ 질문이 제기됐다.
   2. 알려진 사례가 있느냐는 질문에는 떠오르는 사례가 없고, 있었다면 들었을 것이라는 답이 나왔다.
   3. 단정적인 신뢰보다 모델 스크리닝·안전성 평가·실행 격리가 중요하다.

3. 오픈소스 의존성 보안은 이미 기업이 다루는 문제다

   1. Fortune 500 기업의 애플리케이션은 수천 개의 오픈소스 의존성을 사용한다.
   2. 단 하나의 의존성만 오염돼도 전체 애플리케이션에 큰 보안 문제가 생길 수 있다. 이른바 공급망·의존성 포이즈닝(Dependency Poisoning)은 수십 년 전부터 존재했다.
   3. 모델은 내부를 직접 파고들기 어렵다는 점에서 의존성보다 더 불투명하지만, 모델이 결정론적으로 동작하고 안전성 검사를 통과하면 상당 부분을 관리할 수 있다.
   4. 기업의 강한 IT·보안 팀은 이 문제를 새로 시작하는 것이 아니다. 오픈소스 코드와 패키지를 검증해 온 역량을 모델 검증에도 적용할 수 있다.

9. Ollama의 창업·피벗·제품-시장 적합성

9.1. Docker 경험에서 출발한 개발자 경험

1. 공동창업자는 Docker Desktop을 만들며 개발자 경험을 익혔다

   1. Jeffrey Morgan과 공동창업자 Michael은 Docker에서 Docker Desktop을 구축했다.
   2. 팀은 VMware·Docker·네트워킹 회사 출신의 시스템 엔지니어가 많았다.
   3. AI 연구자 집단은 아니지만, 전통적인 컴퓨트·배포·네트워크 문제가 추론 환경에서 다시 나타난다는 점에 집중했다.

2. Ollama 초기 몇 년은 해결할 고객 문제를 찾는 기간이었다

   1. 팀은 뛰어난 개발자 경험을 만드는 역량을 어떤 문제에 적용할지 찾았다.
   2. YC Winter 2021에 지원할 당시 아이디어는 명확하지 않았다.
   3. 팀은 컨테이너·Kubernetes를 위한 뛰어난 데스크톱 경험으로 돌아가기로 했고, 지원서에는 “Kubernetes를 위한 Kitematic” 또는 “Kubernetes를 위한 Docker Desktop”이라고 적었다.

3. 초기 투자 피치는 현재 사업과 달랐다

   1. Benchmark와 2022년에 파트너십을 맺었고, 이는 ChatGPT 이전 시기였다.
   2. 피치는 개발자 경험과 보안 문제에 집중했고, Kubernetes의 SSO(Single Sign-On) 문제도 실제 해결 과제로 제시했다.
   3. Benchmark의 파트너 Peter는 과거 Docker의 Series A 투자자였기 때문에 팀의 사람·철학·개발자 경험에 대한 믿음을 바탕으로 투자했다.
   4. 팀은 당시의 특정 문제보다 무엇을 만들려는지와 왜 존재하는지를 이해해 준 투자자를 만난 것이 행운이었다.

9.2. 보안에서 로컬 LLM으로 옮겨간 피벗

1. 팀은 보안 문제에서 데스크톱 개발자 보안으로 이동했다

   1. 보안 대상을 Kubernetes에서 데스크톱의 개발자로 좁히는 피벗이 있었다.
   2. 팀은 보안 제품과 개발자 도구가 요구하는 인력·판매 방식이 매우 다르다는 사실을 깨달았다.
   3. 팀의 실제 강점은 시스템과 개발자 경험이었고, 자기 팀의 역량을 더 일찍 들여다봤다면 방향을 빨리 정했을 것이라고 회고했다.

2. Llama를 직접 실행한 경험이 문제를 선명하게 만들었다

   1. 팀이 Llama 모델을 직접 실행하려 하자 과정이 너무 어려웠다.
   2. 어렵지만 작동시키고 나면 매우 인상적인 ‘제로에서 원(Zero-to-One)’ 경험이 됐다.
   3. “모델을 로컬에서 쉽게 돌리고 싶다”는 문제와 “모든 모델을 연결하는 게이트웨이”라는 문제가 동시에 드러났다.

3. 토론토 회의에서 두 주의 실행 계획이 나왔다

   1. 토론토와 Palo Alto로 나뉘어 있던 팀이 한 방에 모여 “처음부터 다시 시작한다면 무엇을 할 것인가?”를 물었다.
   2. 첫 번째 문제는 어떤 모델이든 호스팅하고 쉽게 접근하게 하는 게이트웨이였다. 당시에는 LLM을 위한 Segment라고 생각했고, 나중에는 모델 라우터라는 거대한 기회로 발전했다.
   3. 두 번째 문제는 오픈 모델을 실제로 실행시키는 시스템이었다. VMware·Docker 출신 역량을 활용하기에 적합했다.
   4. 팀은 두 주 안에 첫 Ollama 버전을 출시하기로 했다.

4. Llama 2 출시가 실행을 촉발했다

   1. Llama 2가 두 주 계획의 마지막 시점에 출시됐다.
   2. 팀은 더 고민하지 않고 바로 출시했고, 아이디어에서 배포·사용자 확보까지 두 주 안에 진행했다.
   3. 이전 제품에서 2년 동안 고객·제품을 과하게 고민한 것보다, 두 주 동안 실제로 내놓은 것이 더 많은 사용자를 만들었다.
   4. 이 경험은 행동 편향(Bias to Action)이 긴 전략 논쟁보다 강할 수 있음을 보여줬다.

9.3. Ollama라는 이름과 빠른 제품-시장 적합성

1. Ollama라는 이름은 기존 Llama 모델에서 직접 따온 것이 아니다

   1. Llama라는 단어는 오픈 모델을 뜻하는 커뮤니티의 표현으로 자리 잡고 있었다.
   2. Ollama는 LLM과 동물 캐릭터를 합친 이름에 가깝다.
   3. 팀은 모델에 얼굴과 캐릭터를 부여할 수 있는 이름을 원했다.
   4. Docker 행사에 실제 라마를 데려오자는 농담은 아직 실현되지 않았다.

2. Reddit의 취미 사용자가 제품의 초기 전파자가 됐다

   1. Reddit의 로컬 LLM 커뮤니티에서 Ollama가 처음 확산됐고, 회사가 YC 출신이라는 사실은 사용자들에게 나중에 알려졌다.
   2. 사용자는 집에서 모델을 실행하는 방법을 공유하며 제품을 추천했다.
   3. Jeffrey Morgan은 Jared와 만난 자리에서 새 제품이 생겼다고 알렸고, Ollama 티셔츠나 굿즈를 입은 팀이 행사에 나타나면서 “록스타를 만난 것 같다”는 반응을 만들었다.

3. 100,000 GitHub 스타와 85% Fortune 500 도입은 짧은 시간에 일어났다

   1. Ollama는 Docker와 Kubernetes보다 훨씬 빠르게 GitHub 스타 100,000개에 도달했다.
   2. 2023년 7월 출시 후 약 2년 사이에 Fortune 500의 85%가 Ollama를 사용하게 됐다.
   3. 이는 집에서 장비를 만지던 초기 취미 사용자에서 대기업 개발자 팀으로 확장된 속도다.
   4. PC가 널리 보급되기까지 약 10년 걸린 흐름을 Homebrew Computer Club에서 대중 컴퓨터로 가는 18개월 또는 12개월짜리 속도 질주로 압축한 셈이라는 비유가 나왔다.

4. 무료·무허가·어디서나 실행 가능하다는 속성이 기업 전파를 만들었다

   1. 초기 오픈 모델 사용자는 “정말 이것이 가능하구나”를 확인하려는 취미 사용자였다.
   2. 모델은 무료로 시작할 수 있고 어디서나 실행할 수 있어서 기업 개발자도 IT 승인을 기다리지 않고 써볼 수 있었다.
   3. 취미 사용자에게 좋았던 속성이 Fortune 500의 개발자 팀에도 그대로 통했다.
   4. MongoDB가 개발자 도구에서 기업 데이터베이스로 빠르게 확장한 사례와 비슷하지만, LLM은 상태가 없는(stateless) 실행 구조라 전환이 더 쉬웠다.
   5. 클라우드로 옮기면 비용·보안·실행 위치가 추가되지만, 로컬에서 바로 시작하는 경험은 그대로 남는다.

10. 오픈소스 사용자를 수익 사업으로 전환하는 법

10.1. 수익화 시점을 기다린 이유

1. Ollama는 프라이버시 중심 AI라는 수익화 경로를 처음부터 봤다

   1. 로컬 실행은 데이터를 외부로 보내지 않는 프라이버시 강점을 가진다.
   2. 오픈소스 제품은 회사와 개발자와 고객 모두에게 좋은 방식으로 수익화돼야 한다.
   3. 초기에는 도구 호출 같은 기능을 Llama 모델이 충분히 지원하지 못해 고난도 업무는 프런티어 모델의 영역으로 남았다.

2. 제품-시장 적합성이 생길 때까지 기다렸다

   1. 오픈 모델이 폐쇄 모델만큼 실제 업무에서 사랑받는 제품이 되기 전에는 서둘러 수익 모델을 정하기 어려웠다.
   2. 코딩 에이전트가 가장 큰 AI 소비 영역이 되고 오픈 모델이 그 수요를 처리할 수 있게 된 올해, 오픈 모델의 제품-시장 적합성이 분명해졌다.
   3. Ollama Cloud는 오픈 모델을 프라이빗하고 안전하게 고난도 업무에 접근시키는 사업으로 이어졌다.

3. 로컬 실행만으로는 전체 고객 문제가 해결되지 않는다

   1. 로컬 모델은 중요한 구성 요소지만, 대형 모델을 필요한 속도로 실행하는 문제까지 해결하지는 않는다.
   2. 고객은 가장 어려운 업무를 위해 클라우드 오픈 모델에 접근하고, 쉬운 업무는 로컬에서 처리하기를 원한다.
   3. Ollama는 이 두 영역을 연결하는 클라우드와 라우팅을 제공한다.

10.2. 기다림의 위험과 고객 접점

1. 수익화를 늦추면 회사 문화가 위험해질 수 있다

   1. Docker 시절의 경험은 수익화를 우선순위에서 빼면 팀 문화가 굳어질 수 있음을 알려줬다.
   2. 제품이 무료로 급성장해도 언제 어떤 고객 문제를 유료로 해결할지 계속 생각해야 한다.
   3. 사용자 수가 많다는 사실만으로 고객의 지불 의사나 미래 요구를 알 수 없다.

2. 인터넷의 사용자 덩어리를 실제 고객으로 만나야 한다

   1. 오픈소스 프로젝트의 사용자 기반을 인터넷의 거대한 익명 덩어리로 보면 위험하다.
   2. 고객을 직접 만나 무엇을 하고 있는지, 무엇을 6개월 뒤 하고 싶은지, 어떤 이야기를 가지고 있는지 확인해야 한다.
   3. Ollama 팀은 이 고객 대화를 지난 몇 년보다 지금 훨씬 더 많이 하고 있다.

11. YC와 경험 많은 창업팀의 가치

11.1. YC를 선택한 이유

1. 창업은 공동창업자가 있어도 외롭다

   1. Michael은 첫 회사부터 함께한 공동창업자이며 University of Waterloo 시절 룸메이트였지만, 창업 자체의 외로움은 사라지지 않았다.
   2. 코로나19 시기에 YC를 진행하면서도 Jared와 매주 다섯 팀의 창업자 그룹을 만난 것이 고립감을 줄였다.
   3. 이후 Palo Alto로 이동했을 때 네트워크가 커졌고, 오픈 모델·AI를 만드는 창업자와 바로 연결될 수 있었다.

2. YC 커뮤니티는 반복할 실수를 줄인다

   1. YC 창업자들은 실패와 성공을 서로 투명하게 공유한다.
   2. Docker 창업자는 Ollama의 투자자이기도 해서 이전 세대 회사에서 겪은 문제와 작동했던 방식을 계속 논의할 수 있다.
   3. 반복했을 때 회사를 죽일 수 있는 실수는 경험자의 사례를 통해 피할 수 있다.

11.2. ‘좋은 것이 어떻게 보이는가’를 한 번 경험하기

1. 젊은 창업자에게 실제 제품팀 경험이 큰 배움이 된다

   1. 18~19세 창업자들은 무엇을 해야 하는지 자주 묻는다.
   2. 훌륭한 기술을 많은 사람에게 출시하고 명확한 제품-시장 적합성을 만든 팀에서 한 달이나 세 달만 일해도 더 많이 배울 수 있다.
   3. 실제 팀에서 버그 데이터베이스, 릴리스 절차, 품질 기준, 동료 간의 기준선을 보면 ‘좋은 것’이 어떻게 생겼는지 알게 된다.
   4. 그런 경험이 없으면 YC에서도 성공할 수 있지만 훨씬 어렵고, 이미 작동하는 제품을 본 경험은 성공 확률을 배수로 높인다.

2. 경험은 팀의 가치와 책임성을 만든다

   1. AI가 강력해질수록 사람은 무엇을 만들지, 얼마나 오래 유지할지, 고객에게 어떤 책임을 질지 결정해야 한다.
   2. AI는 일부 작업을 도와주지만 팀을 책임성 있게 만들지는 않는다.
   3. 누군가 제품을 사랑해 2년 동안 계속 사용해도 소프트웨어가 안정적으로 작동할지 점검해야 한다.
   4. VMware·Docker·Nera 등에서 온 선임 엔지니어의 운영 경험은 Ollama에 이런 근육 기억(Muscle Memory)을 제공한다.

12. AI 시대에 깨지는 인프라·DevOps 규칙

12.1. 스택 위에 올라간 스타트업은 더 이상 자동으로 취약하지 않다

1. PaaS의 과거 교훈이 AI에서 뒤집힌다

   1. Heroku 같은 Platform as a Service는 다른 계층 위에 올라간 서비스가 기반 플랫폼에 종속된다는 인상을 줬다.
   2. Docker도 초기에는 PaaS처럼 시작했다.
   3. 전통적인 인프라에서는 다른 계층 위에 있는 스타트업이 취약하다는 통념이 있었다.

2. AI에서는 상위 계층이 고객에 더 가까워서 강해질 수 있다

   1. AI 애플리케이션·하네스·라우팅·메모리·보안 계층은 고객의 실제 문제를 직접 해결한다.
   2. 모델이나 인프라 위에 있다고 해서 자동으로 대체되는 것이 아니다.
   3. 고객과 가까운 상위 계층은 여러 모델·프로바이더의 복잡성을 숨기고, 그 자체로 강한 제품이 될 수 있다.

12.2. 비결정성·적은 인력·불완전한 코드라는 새로운 전제

1. LLM의 비결정성은 결함이 아니라 기능이다

   1. 전통적인 시스템은 설계대로 정확히 동작하고 테스트·검증돼야 한다.
   2. LLM은 본질적으로 완벽하게 검증되지 않으며, 약간의 비결정성(Non-Determinism)이 창의성과 유연성을 만든다.
   3. “그건 버그가 아니라 기능이다”라는 농담처럼, 완전한 결정론을 요구하는 인프라 사고를 그대로 적용할 수 없다.

2. AI는 고객지원·클라우드 운영의 인력 구조를 줄인다

   1. 10년 전에는 고객지원 파이프라인과 클라우드 서비스 운영에 더 많은 인력이 필요했다.
   2. AI가 코드 작성·지원·운영을 돕는 지금은 팀이 과거만큼 무겁게 채용하지 않아도 된다.
   3. 대신 어떤 엔지니어도 코드 전체가 어떻게 작동하는지 정확히 알지 못할 수 있는 서비스 운영 문제가 생긴다.

3. 2000년대 인프라 1.0·2010년대 클라우드·현재 AI는 서로 다른 규칙을 요구한다

   1. 이전 세대의 DevOps와 인프라 경험 중 일부는 AI 시스템에 유효하지 않다.
   2. AI 서비스는 코드가 계속 생성되고 모델 출력이 확률적이며, 사용자별 실행 경로가 다르다.
   3. 릴리스·관찰성·평가·안전성·회귀 테스트의 의미를 새로 정의해야 한다.

13. 최종 병목은 모델 수가 아니라 통합·큐레이션이다

13.1. 개발자는 모델 백 개를 관리하고 싶어 하지 않는다

1. 프로바이더의 파편화는 API 경험을 망친다

   1. 각 추론 프로바이더는 특정 파라미터 형식·JSON 구조·에러 동작을 요구한다.
   2. 어떤 프로바이더는 문서에 없는 입력 조건에서 이상한 오류를 낸다.
   3. 에이전트가 결국 해결하더라도 개발자는 몇 시간 동안 벽에 머리를 찧으며 원인을 찾고, “끔찍한 경험”이라고 느낀다.

2. 표준 계층은 양쪽 생태계의 비용을 낮춘다

   1. 개발자는 합리적이고 일관된 API로 토큰을 받아야 한다.
   2. 프로바이더는 각 모델의 근본 버그와 호환성 문제를 개별 고객에게 떠넘기지 않고 표준 계층과 함께 해결할 수 있다.
   3. 모델이 무엇이든 같은 하네스에서 실행되고, 도구 호출·메모리·보안이 일관되면 애플리케이션 개발 속도가 빨라진다.

13.2. OpenRouter·OpenCode·Ollama가 제공하는 통합

1. OpenRouter는 모델 선택과 결제를 묶는다

   1. 개발자는 수백 개 프로바이더에 각각 가입할 필요가 없다.
   2. 한 서비스에서 여러 모델을 선택하고 한 곳에서 결제할 수 있다.
   3. 모델이 바뀌어도 API 접근·계정·지불 흐름을 유지할 수 있다.

2. OpenCode는 하나의 하네스로 어떤 모델이든 연결한다

   1. 개발자는 새 모델이 자기 사용 사례를 더 잘 해결하는지 바로 시험할 수 있다.
   2. 하네스를 갈아엎지 않고 모델만 바꿀 수 있으므로 전환 비용과 잠금 효과가 줄어든다.
   3. Ollama는 이런 모델·하네스·프로바이더 조합을 로컬과 클라우드에서 작동시키는 역할을 한다.

3. 모델과 프로바이더가 풍부해질수록 통합 계층이 희소해진다

   1. 오픈 모델과 추론 프로바이더의 공급은 풍부해졌다.
   2. 이제 희소한 것은 그 조각을 실제로 함께 작동시키는 큐레이션(Curation)이다.
   3. 개발자는 다음 회사나 애플리케이션을 만들고 싶어 하지, 모델별 오류와 인프라 연결 문제를 직접 디버깅하고 싶어 하지 않는다.
   4. 파편화된 모델·추론 기술·클라우드·하네스를 ‘그냥 작동하는 제품’으로 묶는 일이 오픈 모델 경제의 핵심 가치다.

주요 발언 모음

“비용은 오픈 모델이 뛰어들어 해결할 수 있는 문제 중 단연 가장 큰 고충이다.”

“기업의 북극성은 AI를 더 잘 통제하고 자기 사업에 맞게 커스터마이즈하는 것이다.”

“오픈 모델이 기업 안에서 처리하는 토큰의 압도적 다수는 80~90%가 될 수 있다. 그렇다고 예산의 80~90%를 쓴다는 뜻은 아니다.”

“모델이 충분히 유능해도 매우 느리면 좋은 경험이 아니다.”

“상태가 있고 저장소가 필요한 문제는 결국 모델 안으로 들어갈 수 없다.”

“LLM이 완벽하지 않은 것은 버그가 아니라 기능이다.”

“모델과 프로바이더가 풍부해질수록 그것을 작동하는 무언가로 묶는 일이 희소해진다.”

“개발자는 소프트웨어를 만들고 싶다. 다음 회사와 다음 애플리케이션을 만들고 싶다.”

“좋은 제품이 실제로 작동하는 모습을 한 번 본 경험은 성공 확률을 배수로 높인다.”

핵심 데이터 & 수치

• AT&T: 전체 토큰 소비의 약 40%를 오픈 모델로 전환.
• Ollama 사용 규모: 900만 개발자, GitHub 스타 178,000개, Fortune 500의 85%가 사용한다는 소개 수치.
• OpenClaw 성장: 개인별 토큰 사용량이 초기 수준에서 대략 5배 상승했고, Ollama Cloud 전체로는 연초 이후 약 150배 성장.
• OpenClaw 전후 규모: 초기 개인 사용량은 1,500만 토큰 안팎 이하였고, 전체 클라우드 성장은 10~20배 이상으로 관측.
• 컨텍스트 윈도우: 오픈 모델에서 128K에서 100만 토큰 이상으로 확대.
• 기업 토큰 믹스 전망: 80~90%는 오픈 모델, 그러나 오픈 모델 비용 지출은 10~20% 수준일 수 있음.
• 오픈 모델과 프런티어 격차: 지능 격차가 3개월 이내로 좁혀졌다는 평가.
• Flash 모델 목표: 전체 업무의 약 80%를 충분히 처리하며 빠르고 매우 저렴한 워크호스.
• 로컬 모델 크기: 일반적으로 20B~40B, 차세대 장비에서는 최대 128B 파라미터까지 실행.
• Qwen 3.8 38B: 코딩 벤치마크에서 Opus 4.6과 비슷한 성능을 보임.
• DGX Spark: 128GB 통합 메모리로 20B~120B 모델 실행, 여러 대를 연결하면 400B 모델 실행 가능.
• DGX Station 가격: 프런티어 모델을 느리게 실행하는 장비가 약 20만~30만 달러 수준이며 실제 가격은 더 경쟁력 있을 수 있음.
• GPU: 최신 모델 실행에 B200·B300이 필요하지만 스타트업의 직접 확보는 어려움.
• Ollama 연혁: YC Winter 2021, Llama 2 출시 무렵 2주 실행 계획, Ollama 공개 출시는 2023년 7월, Benchmark 파트너십은 2022년.
• GitHub·기업 전파: GitHub 스타 100,000개 도달 속도가 Docker·Kubernetes보다 빨랐고 약 2년 만에 Fortune 500의 85% 사용.
• PC 보급 비유: PC의 대중화에 약 10년이 걸렸지만 오픈 모델은 12~18개월 수준의 속도 질주로 비유됨.

20줄 핵심 요약

1. 오픈 모델은 높은 토큰 비용을 낮추고 기업이 AI를 직접 통제·맞춤화하게 한다.
2. AT&T는 전체 토큰 소비의 약 40%를 이미 오픈 모델로 전환했다.
3. 코딩 에이전트가 Kimi·GLM·MiniMax 같은 모델의 초기 오픈 모델 수요를 견인했다.
4. OpenClaw와 Hermes는 비개발자도 장시간 업무를 자동화하게 해 토큰 사용량을 폭발시켰다.
5. 개인별 Ollama Cloud 사용량은 OpenClaw 이후 약 5배, 전체 클라우드는 연초 이후 약 150배 성장했다.
6. 오픈 모델의 컨텍스트 윈도우는 128K에서 100만 토큰 이상으로 확장됐다.
7. 모델 출시 주기가 빨라져 파인튜닝은 어려워졌지만 파인튜닝 툴링은 개선되고 있다.
8. Day-Zero 출시는 추론 엔진·하네스·모델 패키징·하드웨어·용량을 동시에 맞춰야 한다.
9. 기업 토큰의 80~90%가 오픈 모델을 사용할 수 있지만 비용 지출은 10~20%일 수 있다.
10. 최난도 문제는 프런티어 모델이, 반복적인 업무는 오픈 모델이 맡는 혼합 구조가 유력하다.
11. 프런티어 모델과 오픈 모델의 협업은 파트너와 어소시에이트가 일하는 로펌 구조와 비슷하다.
12. 로컬 모델은 쉬운 문서 업무를 거의 무료로 처리하고 라우터는 어려운 일을 클라우드로 보낸다.
13. 로컬 모델은 미국·중국·유럽 모델이 경쟁하지만 클라우드 코딩 에이전트는 중국계 모델이 압도한다.
14. 20B~40B, 최대 128B 모델을 개인 하드웨어에서 실행하는 시대가 열리고 있다.
15. DGX Spark는 128GB 통합 메모리를 제공하며 여러 대를 연결하면 400B 모델도 실행할 수 있다.
16. DeepSeek Flash 같은 모델은 80%의 업무를 빠르고 싸게 수행하는 무제한 토큰 경제를 연다.
17. 여러 작은 모델을 체인하는 작업 구성은 하나의 거대한 God Model보다 반복 가능하고 신뢰할 수 있다.
18. 오픈 모델 도입의 핵심 장애물은 지능보다 보안·출처·호스팅 위치·안전성이다.
19. Ollama는 Docker 경험을 바탕으로 모델·하네스·프로바이더·하드웨어를 통합하는 운영체제 역할을 한다.
20. 모델이 풍부해질수록 개발자의 희소 자원은 모델 자체가 아니라 모든 조각을 작동시키는 큐레이션이다.

결론 및 시사점

1. 기업 AI 예산은 토큰 단가가 아니라 총 업무 처리량을 기준으로 재편된다. 오픈 모델의 낮은 비용은 사용량 제한을 풀고 에이전트의 반복·검증·재시도를 경제적으로 만든다.
2. 모델 선택권은 라우터와 하네스의 제품 가치로 이동한다. 기업은 특정 모델에 영구히 베팅하기보다 작업별로 로컬·오픈·폐쇄 모델을 조합하고 언제든 교체할 수 있는 런타임을 원한다.
3. Flash 모델과 작업 구성은 차세대 애플리케이션의 기본 단위가 된다. 80%의 업무를 저가 모델이 처리하고 나머지를 고급 모델에 넘기는 구조는 단일 God Model보다 비용·신뢰성·운영 측면에서 유리하다.
4. 오픈 모델의 상업적 방어력은 모델 가중치보다 통합·보안·관찰성·고객 데이터·개발자 경험에서 생긴다. 상위 계층은 기반 모델이 바뀌어도 고객의 실행 흐름을 보존한다.
5. 로컬 하드웨어의 발전은 AI 실행 위치를 다시 분산시킨다. 기업이 이미 보유한 GPU와 차세대 Mac·DGX 장비가 쉬운 업무를 로컬로 이동시키고, 클라우드는 고난도 작업과 대규모 조정을 맡는다.
6. 출신 국가 논쟁은 데이터 흐름과 검증 가능한 공급망으로 구체화돼야 한다. 모델이 어디서 만들어졌는지뿐 아니라 어디서 실행되고 어떤 데이터로 훈련됐는지, 어떤 안전성 검사를 통과했는지를 확인해야 한다.
7. 창업자는 아이디어를 과도하게 설계하기보다 짧은 실행 주기로 고객 문제를 검증해야 한다. Ollama는 2년간의 탐색보다 Llama 2 출시 시점의 2주 행동 편향에서 더 빠르게 제품-시장 적합성을 발견했다.
8. 오픈 모델 경제의 최종 희소 자원은 큐레이션이다. 수많은 모델·프로바이더·클라우드·하네스를 일관된 API와 안정적인 제품으로 연결하는 계층이 AI 생태계의 다음 핵심 인프라가 된다.