The Future of Inference Market & Model Routing: Commodity or Increasing in Value?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

The Future of Inference Market & Model Routing: Commodity or Increasing in Value를 중심으로, 추론 수요의 확대와 라우팅의 차별화는 별개다. LangChain CEO는 추론 시장을 과소평가했다고 돌아보며 여러 공급자의 성장를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 추론 수요의 확대와 라우팅의 차별화는 별개다. LangChain CEO는 추론 시장을 과소평가했다고 돌아보며 여러 공급자의 성장 가능성을 긍정적으로 본다. 다만 새 모델이 여러 작업에서 모두 우세해지면 모델을 나눠 쓰는 라우팅의 이점은 줄어들 수 있다.
2. 전문 에이전트의 라우팅에는 하네스 내부 정보가 중요하다. 하네스는 실행 상태와 프롬프트 캐시를 파악하고 모델별 프롬프트를 조정하기 쉽다. 게이트웨이는 기존 도구를 수정하기 어려운 환경이나 일반 채팅·코딩 같은 범용 업무에서 장점이 있다.
3. 에이전트의 경쟁력은 컨텍스트·하네스·도메인 평가를 함께 설계하는 데서 나온다. 좋은 결과를 정의하는 전문가의 지식이 중요하며, 모델과 메모리의 이동성을 확보하면 공급업체 종속에도 대응할 수 있다. 모델 발전으로 불필요해진 우회 구현은 제거해야 한다.
4. 후속 학습과 기억은 업무에 맞춰 단계적으로 적용해야 한다. 먼저 컨텍스트와 하네스를 개선하고, 사용량과 데이터가 쌓이면 분류·추출·요약 같은 좁은 작업의 후속 학습을 검토한다. 기억의 핵심 난제는 저장보다 무엇을 추출해 다음 실행에 반영할지 결정하는 일이다.
5. 토큰 사용량과 지출, 생산성은 따로 측정해야 한다. 자사 사례에서는 사용량이 늘어도 지출이 줄었으며, 비용 관측·예산 설정·캐싱·라우팅을 활용했다. 높은 지출에는 생산적인 활용과 설정 실수로 발생한 반복 실행이 함께 섞일 수 있다.

🧩 배경과 문제 정의

• 에이전트는 비결정적인 모델을 여러 차례 호출하고 외부 도구와 상호작용하므로, 작은 입력 차이나 개별 호출의 오류가 전체 시스템의 신뢰성 문제로 이어진다.
• 모델 성능이 빠르게 좋아지면서 기존 프레임워크의 우회 구현이 불필요해진다. 개발사는 당장 필요한 기능을 만들면서도 장기적으로 남을 역할을 구분해야 한다.
• 에이전트의 경쟁력은 모델뿐 아니라 컨텍스트, 실행 구조인 하네스, 도메인별 평가 기준에도 달려 있다. 모델 교체의 자유와 전문 업무에 대한 통제력이 핵심 쟁점이다.
• 도입부에서는 코딩 도구 지출이 엔지니어 급여의 30% 수준이며, 최근 두 달 동안 토큰 사용량이 늘었는데도 지출은 줄었다는 사례가 나온다. 사용량 증가와 비용 변화가 반드시 같은 방향으로 움직이지는 않는다.

🕒 시간순 섹션별 상세정리

1. 에이전트 개발의 핵심 난제는 신뢰성이다

• LangChain의 오픈소스 프레임워크는 모델을 도구·데이터·연산에 연결한다. LangSmith는 관측과 평가를 통해 에이전트가 어디서 실패하는지 파악하고 성능 개선을 측정하도록 돕는다. [01:36]
• 자연어 입력의 범위는 매우 넓고, 모델은 비슷한 입력에도 다른 결과를 낼 수 있다. 여러 모델 호출과 도구 실행이 연결된 에이전트에서는 개별 오류가 연쇄적으로 커질 수 있다. [02:47]

2. 모델이 발전하면 제품의 일부를 지워야 한다

• 모델이 좋아지면 이전에 필요했던 기능이 불필요해지므로 제품의 상당 부분을 제거해야 한다. 특히 모델을 활용하는 오픈소스 프레임워크의 적절한 설계는 빠르게 바뀐다. [04:01]
• 초기 LangChain은 모델이 생성한 JSON 기반 DSL을 파싱해 도구 호출을 구현했다. 이후 OpenAI가 모델과 API에 도구 호출을 직접 통합하자, 이를 장기적인 방향으로 판단하고 구현을 전환했다. [05:12]

3. 중립 하네스는 메모리의 이동성과 통제력을 지킨다

• 에이전트가 사용자나 환경과 상호작용하며 쌓는 학습 결과는 모델 가중치뿐 아니라 외부 메모리와 컨텍스트에도 남는다. 이렇게 축적한 컨텍스트를 특정 모델 제공업체에 묶고 싶지 않은 수요가 있다. [06:52]
• 모델 교체 가능성은 새로운 최상위 모델을 활용하는 수단이자, 공급업체 종속과 가격 인상에 대응하는 수단이다. 메모리가 특정 하네스에 묶이고 그 하네스가 특정 모델에 묶이면 데이터 이동성과 사업상의 선택권이 약해진다. [07:58]

4. 검증 기준을 만드는 도메인 전문가에게 가치가 쌓인다

• 검증에서 가치가 나온다면, 좋은 결과를 정의하고 이를 평가 기준으로 구현할 수 있는 도메인 전문가가 유리하다. 업무 지식을 검증기와 평가에 담는 일이 어렵기 때문에 분야별 전문 에이전트에 큰 가능성이 있다는 판단이다. [09:53]
• 전문 에이전트는 먼저 컨텍스트 엔지니어링과 하네스 조정으로 시작하고, 사용자가 확보된 뒤 모델의 후속 학습을 검토하는 편이 투자 대비 효과가 높다는 권고다. 도메인마다 좋은 결과의 기준뿐 아니라 적절한 사용자 경험도 달라질 수 있다. [10:40]

5. 자체 모델 개발은 대체로 기존 모델의 후속 학습이다

• 기업의 지능 통제 수준은 컨텍스트 조정, 하네스 수정, 공개 가중치 모델의 후속 학습, 처음부터 모델 학습의 순서로 깊어진다. 통제 범위가 넓어질수록 비용도 커지며, 많은 기업은 처음부터 학습하기보다 기존 모델을 후속 학습하는 것으로 본다. [11:52]
• Harvey와 Ramp 같은 기업은 인재·데이터·사용량을 확보한 상태에서 최적화를 추진한다. 컨텍스트와 하네스에서 얻을 수 있는 개선을 충분히 추구한 뒤 모델 후속 학습으로 나아간다는 해석이다. [12:14]

6. 후속 학습은 단순 보조 작업에서 효과가 더 분명하다

• 실제 에이전트에는 핵심 실행 모델 외에도 가드레일·라우팅·하위 에이전트·하위 워크플로를 위한 모델 호출이 존재한다. 현재 후속 학습의 실용성이 두드러지는 곳은 분류·추출·요약처럼 범위가 좁은 작업이다. [13:15]
• 도구를 호출하며 핵심 루프를 이끄는 모델까지 후속 학습 모델로 대체할지는 아직 열린 문제다. 새로운 프런티어 모델이 나올 때마다 실행 능력이 좋아지는 한편, Harvey와 Ramp 등은 이 핵심 역할에도 후속 학습을 실험하고 있다. [13:59]

7. 라우팅의 정밀도는 하네스가 가진 상태 정보에 달려 있다

• 게이트웨이 라우팅은 API 호출 형태여서 하네스 코드를 바꾸지 않고도 적용하기 쉽다. 반면 하네스 내부 라우팅은 실행 상태를 더 많이 파악할 수 있다는 장점이 있다. [15:23]
• 하네스에서는 프롬프트 캐시의 상태를 고려하고, 모델별 특성에 맞춰 프롬프트를 바꾸기도 쉽다. 이런 이유로 LangChain은 하네스 안에서 라우팅하는 방식에 더 무게를 둔다. [15:44]

8. 게이트웨이 라우팅은 기존 도구 유지와 범용 업무에 강점이 있다

• 사용자가 Claude Code 같은 기존 하네스를 계속 쓰면서 다른 모델로 요청을 보내려면, 하네스를 직접 수정할 수 없는 경우 게이트웨이 라우팅이 대안이 된다. 이는 수정 가능한 오픈소스 하네스가 유리한 이유이기도 하다. [18:07]
• 코딩처럼 널리 쓰이는 분야에서는 하네스 전체를 몰라도 용도별 모델 특성을 활용하는 라우터를 만들 수 있다. 범용 사내 챗봇에서도 간단한 인사에는 비싼 모델 대신 저렴한 모델을 선택하는 방식이 가능하다. [19:07]

9. 평가는 필요하지만 단일 점수를 맹신할 수 없다

• 공개 학술 평가에 맞춰 모델이 최적화되면서, 모델 출시 때 제시되는 기존 벤치마크만으로는 새로운 정보를 얻기 어려워졌다는 비판이다. [20:26]
• 자체 도메인에 맞춰 만든 내부 평가는 여전히 유용하다. 전문 에이전트를 개발하려면 결과를 측정할 수단이 필요하며, 이런 평가 기준은 대체로 신뢰할 수 있다는 입장이다. [20:41]

10. 실행 기록은 컨텍스트·하네스·모델 개선으로 연결될 때 가치가 생긴다

• 에이전트의 경쟁력은 해당 도메인에서 좋은 결과를 만드는 독점적인 컨텍스트·하네스·모델에서 나온다. 컨텍스트는 상대적으로 통제하기 쉽고, 모델은 통제가 가장 어렵지만 잠재적인 개선 한계는 가장 높을 수 있다. [22:23]
• 실행 기록의 가치는 그 안에서 얻은 통찰을 실제 구성 요소에 반영할 때 생긴다. 모델에는 후속 학습으로 반영하고, 컨텍스트나 메모리에는 별도 에이전트가 기록을 분석해 추출한 학습 내용을 넣을 수 있다. [22:51]

11. 지속 학습은 핵심 실행 루프 바깥에 개선 루프를 더한다

• 지속 학습이 도입돼도 LLM이 도구를 호출하며 환경과 상호작용하는 내부 루프는 대체로 유지될 것이라는 전망이다. 달라지는 부분은 실행 결과를 살펴보고 개선에 활용하는 외부 루프다. [23:54]
• 지속 학습을 실행할수록 좋아지는 시스템으로 정의하면, 컨텍스트·하네스 코드·모델 가중치 갱신이 모두 포함될 수 있다. 공통 과정은 실행 기록 수집, 학습 내용 추출, 수정, 개선 여부 측정의 반복이지만, 가중치를 바꾸는 일과 메모리 파일을 수정하는 일의 구현은 크게 다르다. [24:35]

12. 컨텍스트 계층의 난제는 저장보다 유용한 기억의 추출이다

• 에이전트의 컨텍스트 계층이라는 관점에서 데이터 시장은 아직 초기라는 판단이다. ClickHouse 같은 기존 데이터베이스는 저장과 질의에 강하지만, 그 기능만으로 에이전트의 컨텍스트 관리가 완성되지는 않는다. [25:29]
• 앞으로의 컨텍스트 계층은 데이터베이스 자체보다 데이터베이스 주변에서 작동하는 에이전트에 가까울 수 있다. 관찰에서 얻은 학습 내용을 적절히 가공해 저장하려면 별도의 지능이 필요하기 때문이다. [26:08]

13. 자기 성찰의 개선 가능성과 모델 발전 속도의 불확실성

• 모델은 프롬프트를 되돌아보고 개선하거나 에이전트 구조를 분석해 고치는 메타 수준의 성찰에 아직 어려움을 겪는다. Engine 관련 내부 평가도 있지만, 이런 작업은 여전히 어렵다는 판단이다. [27:03]
• 학습 과정을 구현하는 시스템의 설계도 확립되지 않았다. 어떤 입력과 출력, 하네스, 워크플로가 적절한지 불분명하며, 모델의 성찰 능력 자체에도 한계가 있다. [27:43]

14. 작업별 성능 포화와 메타러닝의 발전 가능성

• 코딩은 충분한 성능에 가까워지고 있으며 요약·라우팅도 비교적 성숙한 작업에 속한다. 반면 더 어려운 작업이나 아직 모델에 맡길 생각조차 하지 못한 작업은 남아 있다 [28:19]
• 메타러닝은 현재 모델이 잘하지 못하지만 재귀적 자기개선 등을 위해 연구소에 중요할 수 있다. 일부 작업의 성능은 포화되더라도 다른 작업은 이전보다 빠르게 발전할 가능성이 있으며, 연구소 내부 정보 없이 이를 확신하기는 어렵다 [28:34]

15. 기억의 중요성과 범용 메모리 제품의 한계

• 에이전트의 기억 계층은 아직 크게 미해결된 영역이다. Instinct와 Muse의 개인화, 말투 조정, 선제적인 후속 대응은 기억이 사용자 경험을 어떻게 바꿀 수 있는지 보여주며, 향후 몇 년 안에 모든 제품이 어떤 형태로든 기억을 갖출 것이라는 전망이다 [29:12]
• 개인 비서, 기업용 에이전트, 법률·금융 서비스가 필요로 하는 기억은 서로 다르다. 기억의 중요성은 분명하지만 이를 구현할 정답은 아직 알려져 있지 않다 [29:48]

16. 무엇을 기억할지 학습하는 도메인별 에이전트

• 기억의 어려운 부분은 사실을 저장하는 것보다 무엇을 기억해야 하는지 학습하는 과정이다. 특정 분야의 지식을 잘 습득하는 능력은 버티컬 에이전트의 핵심이며, 기억을 담당하는 학습 에이전트도 초기에는 도메인별로 만들어질 가능성이 크다 [31:07]
• 학습 에이전트의 하네스는 기존 구조와 비슷하되, 전용 지침·도구와 기억 구조 탐색이나 사실 추출에 특화된 하위 에이전트를 포함할 수 있다. 다만 일반화된 구조가 무엇인지는 아직 불확실하다 [31:38]

17. 소비자 서비스에서 수평·수직 에이전트가 공존하는 이유

• 소비자 시장에는 범용적인 수평 에이전트와 서비스별 수직 에이전트가 함께 존재하고 서로 상호작용할 것이라는 전망이다. 개별 앱은 범용 에이전트보다 해당 서비스에서의 사용자 행동을 더 잘 학습할 수 있다 [32:23]
• Spotify의 음악 이용과 Strava의 활동 이용은 서로 다른 맥락을 가진다. 앱이 축적한 사용자 이해를 에이전트로 제공하고, 여러 API를 자연어 인터페이스로 감싸면 수평 에이전트와의 연결도 쉬워진다 [32:56]

18. 에이전트 트래픽에 맞춘 인프라와 수익모델

• 콘서트 좌석을 사기 위해 사흘 동안 5분마다 확인한 사례는 사람의 직접 이용보다 요청량이 크게 늘어날 수 있음을 보여준다. 잦은 조회로 계정이 차단된 Resy 사례도 언급되며, 인프라는 더 큰 순간 부하와 확장 요구를 감당해야 한다. 하위 인프라 계층의 구체적인 변화는 아직 불확실하다 [33:45]
• 서비스 제공자가 자체 수직 에이전트를 제공하고 사용자의 수평 에이전트가 여기에 접속하는 구조가 예상된다. 다만 기존 화면에서 발생하던 광고 노출과 추가 구매 유도가 약해질 수 있다는 문제가 있다 [34:45]

19. 모델 효율 개선과 총비용 증가가 동시에 일어나는 이유

• 프런티어 모델의 가격 대비 성능은 개선되고 있지만, 에이전트 간 대화와 다중 에이전트 시스템이 더 많은 토큰을 소비하면서 전체 비용은 증가한다. 특히 코딩 비용이 급증해 지출을 줄이려는 조직이 늘고 있다 [36:07]
• 비용 관리에는 예상·실제 지출의 가시화, 작업별 예산 제한, 하네스 자체의 개선이라는 세 단계가 필요하다. 예약 작업에 5달러 이상 쓰지 못하도록 제한하는 방식이 예산 통제의 예다 [36:43]

20. 기업의 최우선 요구는 정확도이며 비용의 비중이 커진다

• 최근 2년간 개발자 설문에서 정확도는 다음 순위인 지연시간·비용보다 대략 두 배 수준의 응답을 얻은 최우선 항목이었다. 보안은 그 뒤에 비교적 가까이 위치했다 [38:05]
• 최근 대기업 고객과의 대화에서는 비용에 대한 우려가 커졌다. 정확도가 여전히 가장 중요하지만 비용은 지연시간보다 우선하는 것으로 보이며, 보안도 중요도가 높아지지만 정확도와 비용보다는 뒤에 있다는 평가다 [38:24]

21. 코딩 도구 지출을 줄인 관측·예산·하네스 개선

• 자사의 코딩 도구 지출은 엔지니어 급여의 약 30%라는 추정치다. 최근 두 달 동안 토큰 사용량은 늘었는데도 지출은 감소했다 [38:54]
• 모든 코딩 에이전트 사용을 LangSmith로 추적해 사용자별 지출과 용도를 분석하고 예산을 설정했다. 한도에 도달하면 엔지니어링 책임자와 상의해 대부분 증액할 수 있지만, 잘못된 사용이나 반복 실행을 막는 안전장치로 활용한다 [39:06]

22. 높은 사용료와 높은 생산성을 구분해야 하는 이유

• 비용을 많이 쓰는 사람이 항상 가장 효과적인 것은 아니다. 일부 시니어 엔지니어의 높은 지출은 충분한 가치가 있지만, 단순한 설정 실수로 사용량이 급증하는 경우도 있다 [40:25]
• 프런트엔드 작업에서 매 턴 화면 캡처나 웹페이지 DOM 스냅샷을 전달하는 플러그인이 큰 반복 실행을 일으켜, 한 주에 약 4만 달러를 쓴 사례가 있었다. 의도하지 않은 낭비를 발견하는 것만으로도 비용 관측의 가치가 크다 [40:50]

23. 조직 재설계가 에이전트 지출과 모델 기업 가치에 미치는 영향

• 소수 인원이 에이전트를 활용해 빠르게 실행하는 조직에서는 코딩 에이전트 지출이 인건비와 같아지거나 이를 크게 넘어설 가능성이 있다. 그러나 현재는 다양한 전문성을 가진 사람들의 협업·소통·검토가 여전히 필요하다 [41:48]
• 한두 명이 에이전트를 운용하는 팀은 매력적인 구상이지만, 이를 잘하는 엔지니어의 보상도 높아질 수 있다. 따라서 인원이 줄어도 에이전트 비용과 인건비의 비율이 어떻게 변할지는 예측하기 어렵다 [43:04]

24. 중국 공개 모델의 위험 평가와 미국 모델의 추격 전망

• 중국 공개 모델을 우려하는 기업과 개의치 않는 기업이 모두 있다. Fireworks를 이용하거나 직접 호스팅하는 경우에도 데이터가 중국 연구소로 돌아간다는 우려는 타당하지 않다는 입장이다 [45:19]
• 학습 데이터 때문에 기업 가치에 맞지 않는 답변이 나올 가능성은 평가로 확인해야 한다. 이런 우려는 대체로 근거가 약하다고 보지만, 일부 도메인에서는 실제로 고려할 여지가 있음을 인정한다 [45:46]

25. 공개 모델은 핵심 에이전트보다 좁은 작업에서 경제성이 높다

• 공개 모델과 후속 학습 모델의 사용은 예상보다 많지만, 주로 라우팅·가드레일·정보 추출·요약 같은 단순하고 좁은 작업에 집중돼 있다. 주요 에이전트의 핵심 실행 루프를 널리 구동하는 단계는 아니라는 관찰이다 [46:55]
• 공개 모델을 모든 작업에 쓰기에는 아직 부족하지만, 프런티어 모델의 개선만 기다리는 것도 최선은 아니다. 용도가 명확하고 처리량이 많으며 일부 구성 작업이 충분히 단순하다면, 해당 작업에 맞춘 후속 학습은 높은 투자수익을 낼 수 있다 [47:28]

26. 추론 수요의 규모가 여러 공급자의 공존을 뒷받침한다

• 추론과 코딩 에이전트 시장의 수요는 LangChain을 시작할 당시 예상보다 훨씬 커졌다. 시장 규모 자체를 과소평가했다는 판단이다 [48:33]
• 추론 수요가 가까운 시일 안에 줄어들지는 않을 것으로 보며, 그 규모가 Fireworks·AWS·Crusoe 등 여러 사업자의 성공을 뒷받침할 수 있다는 낙관론이다. 특정 사업 구조의 우열보다 풍부한 수요에 무게를 둔다 [48:52]

27. 고객지원과 로보틱스에 대한 투자 과열 우려

• 진행자의 고객지원 분야 투자 회의론은 다수의 대규모 투자 유치 기업과 Salesforce·Atlassian 같은 기존 사업자, Intercom·Talkdesk 등이 동시에 경쟁한다는 데 근거한다 [49:31]
• 로보틱스, 특히 휴머노이드에는 자금과 기대가 실제 역량보다 앞서 있다는 비판이 제기된다. 형태적 제약이 남아 있고 ChatGPT에 비견되는 대중적 전환점까지는 아직 멀다는 진행자의 판단이다 [49:52]

28. 추론·기반 인프라·도메인 전문 에이전트의 투자 기회

• 더 많은 소프트웨어가 만들어질수록 추론뿐 아니라 낮은 계층의 기반 인프라도 필요해진다. Modal·Temporal 등이 투자 기회로 거론되며, Modal의 사업에는 추론과 함께 샌드박스도 포함된다 [50:43]
• 버티컬 에이전트에서는 특정 업종을 일괄적으로 선호하기보다 도메인에 대한 뚜렷한 관점과 깊이가 중요하다. AI 침투율은 낮지만 전문성이 많이 축적된 분야를 변화시키는 접근이 유망하다는 견해다 [51:17]

29. 강한 기술 인재·빠른 실행·브랜드가 만드는 경쟁 우위

• 성공하는 팀의 첫 조건은 강한 인재다. 특히 깊은 기반 인프라를 구축하려면 뛰어난 기술력이 필요하며, 이를 해낼 수 있는 사람은 많지 않다 [52:22]
• 빠르게 바뀌는 시장에서는 반복 개선과 실행 속도가 중요하다. LangChain이 새로운 기능과 기술을 신속하게 통합하는 능력도 경쟁 우위로 평가한다 [53:01]

30. 선점은 강력하지만 후속 실행이 생존을 결정한다

• 먼저 시장을 연 브랜드의 이점은 매우 크지만 추격도 가능하다. OpenAI의 Codex는 추격 사례로, Anthropic의 Claude Code는 선점 이점의 사례로 거론된다 [54:33]
• 먼저 등장했다고 성공이 보장되지는 않는다. AutoGPT는 매우 빠르게 성장한 GitHub 프로젝트였지만 이후 두드러진 소식을 접하지 못했다는 사례를 통해, 초기 관심 이후에도 빠른 실행이 필요하다는 점을 강조한다 [54:57]

31. 새로운 모델 범주를 만든 기업의 고평가 투자 논리

• ‘Jev’의 90억 달러 라운드에 대한 낙관적 투자 논리는 새로운 추론 방식과 모델 범주를 만들고, 그 범주 자체가 회사 이름과 연결된다는 데 있다. 범주의 성장과 함께 브랜드가 수혜를 볼 수 있다는 구상이다 [55:36]
• 이 논리가 성립하려면 뛰어난 팀이 실제로 실행할 수 있어야 한다. 해당 팀을 아주 잘 아는 것은 아니며, 그 가치평가에서는 팀의 역량과 실행력을 전제로 삼아야 한다는 한계를 명시한다 [55:59]

32. Benchmark와 Sequoia의 서로 다른 회사 성장 지원

• Benchmark는 창업자가 두 명이던 시점에 투자했으며, 약 400명 규모로 성장하는 과정에서 세 번째 공동창업자처럼 지속적으로 함께한 파트너로 평가된다. Sequoia도 그로부터 두세 달 뒤 합류해 중요한 지원을 제공했다 [56:22]
• Benchmark는 회사의 핵심 정체성, 조직 구축, 포지셔닝을 깊이 논의하는 조언자에 가깝다. 회사의 중심이 무엇인지 정리하는 문제에 시간을 들이는 방식이다 [57:11]

33. 투자사의 채용 지원과 신뢰 관계가 자금 조달의 가치를 좌우한다

• Sequoia의 추천과 인재 네트워크를 통해 우수한 채용 후보자를 다수 확보했다. 이러한 경험을 바탕으로 Sequoia와 Benchmark 같은 최상위 투자사에는 기업가치를 일부 낮추는 조건을 감수할 가치가 있다고 판단한다. 다른 최상위 투자사도 그럴 수 있지만, 직접 협업한 곳은 두 회사다 [58:25]
• 자금 조달에는 먼저 투자 조건서를 확보한 뒤 다른 투자자에게 알리며 경쟁을 유도하는 일종의 게임이 있다. 이런 과정 자체를 좋아하지는 않지만, 함께 일하고 싶은 사람들과 큰 목표를 실현하려면 투자 유치가 필요하다. Benchmark 역시 서로 함께 일하고 싶은지 확인하는 방식으로 접근했으며, 그 접근도 좋은 협상 전략이었다고 평가한다 [59:49]

34. 에이전트 개발 난도와 추론 시장의 기회를 재평가한다

• 에이전트는 여전히 만들기 매우 어렵다. 생태계의 다른 구성원들도 동의할 수 있는 주장이지만, 실제 개발 난도는 충분히 인식되지 않고 있다고 본다 [1:01:03]
• 추론 시장은 매우 크다는 쪽으로 생각이 바뀌었다. 약 1년 반 전 이사회와 게이트웨이 개발을 검토했을 때는 OpenRouter에 비해 추가할 가치가 보이지 않았지만, 당시 개발하지 않기로 한 결정은 전적으로 잘못이었다고 평가한다 [1:01:21]

35. AI 기업의 성장 경로와 창작 도구의 가능성에 주목한다

• OpenAI가 1.5조, Anthropic이 2조의 기업가치로 상장해 한 곳에만 투자할 수 있다는 가정에서는 OpenAI를 선택한다. 매우 큰 엑시트나 기업가치로 이어질 수 있는 경로가 더 다양하다고 보기 때문이다 [1:02:05]
• 2022년 창업 당시 오늘날의 에이전트 하네스가 어떤 모습일지 알았다면 더 일찍 만들 수 있었을 것이라는 아쉬움이 있다 [1:02:16]

🧾 결론

• 추론 수요가 크다는 전망만으로 개별 공급자나 라우터의 지속적인 수익성을 확정할 수는 없다. 시장 성장과 차별화의 근거를 함께 확인해야 한다.
• 라우팅의 유용성은 작업 특성, 모델 간 성능 차이, 캐시와 실행 상태를 얼마나 활용하는지에 따라 달라진다.
• 실행 기록은 컨텍스트·하네스·모델을 수정하고 실제 개선을 검증하는 데 활용할 때 가치가 생긴다.
• 전문 에이전트는 도메인 지식을 평가와 실행 로직에 담는 데서 출발하고, 후속 학습은 데이터와 경제성이 뒷받침될 때 검토하는 접근이 제시된다.

📈 투자·시사 포인트

• 추론과 기반 인프라에는 수요 확대의 기회가 있다는 견해다. 다만 여러 사업자가 성장할 수 있다는 전망은 특정 사업 구조의 우월성을 입증하지 않는다.
• 라우팅 사업은 단일 API 접근의 편의성과 자동 모델 선택의 성과를 구분해 평가할 필요가 있다. OpenRouter의 이용 동기에 관한 발언도 검증된 사용량 분석이 아닌 추정이다.
• 버티컬 에이전트에서는 업종 이름보다 도메인 이해의 깊이, 독점적인 컨텍스트, 평가 기준과 하네스 구현 능력이 투자 판단의 핵심으로 제시된다.
• 모델의 가격 대비 성능이 개선돼도 다중 에이전트와 반복 실행으로 총지출은 늘 수 있다. 비용 관측과 캐싱, 예산 통제의 수요를 함께 살펴볼 필요가 있다.

⚠️ 불확실하거나 확인이 필요한 부분

• 추론 수요 확대와 여러 공급자의 성공은 인터뷰이의 전망이다. 공급자별 수익성이나 지속 가능한 경쟁 우위는 자료만으로 확인되지 않는다.
• 하네스 라우팅의 우위는 전문 업무에 대한 설계 관점이다. 게이트웨이와의 성능·비용 비교 수치가 제시되지 않아 모든 환경에 일반화하기 어렵다.
• 코딩 도구 지출이 급여의 약 30%라는 수치는 자사 추정이며, 주간 약 4만 달러 낭비 사례도 개별 사례다. 전체 기업의 평균이나 일반적인 절감률로 해석할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 업무의 성공 기준과 실패 유형을 정의하고, 도메인 평가 점수와 실행 기록을 함께 검토한다.
• 모델·사용자·작업별 지출과 반복 실행을 관측하고, 작업별 예산 및 한도 초과 처리 절차를 설정한다.
• 동일한 업무에서 단일 모델, 게이트웨이 라우팅, 하네스 라우팅의 정확도·비용·지연시간·캐시 활용을 비교한다.
• 모델을 교체해도 메모리와 컨텍스트를 옮길 수 있는지 점검하고, 특정 공급업체에 묶이는 지점을 확인한다.

❓ 열린 질문

• 프런티어 모델 하나가 대부분의 작업에서 우세해지면, 라우팅은 어떤 업무와 비용 조건에서 가치를 유지할까?
• 전문 에이전트의 상태 정보와 캐시를 활용하는 하네스 라우팅은 게이트웨이보다 얼마나 큰 개선을 만들 수 있을까?
• 도메인별 기억에서 무엇을 남기고 버릴지 판단하는 학습 과정을 얼마나 일반화할 수 있을까?