LangChain CEO가 본 에이전트와 추론 시장의 미래

URL: https://www.youtube.com/watch?v=1jDCPEHwQfI
날짜: 2026-10-17
채널: 20VC with Harry Stebbings
발표자: Harrison Chase, LangChain 공동창업자 겸 CEO

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

에이전트 시장에서 지속적인 경쟁우위를 만드는 것은 단일 모델의 성능이 아니라 ==도메인 지식과 사용자 상태를 담은 컨텍스트·하네스·모델을 평가하고 반복 개선하는 시스템==이다. 추론 수요는 예상보다 훨씬 크며, 모델 라우팅·메모리·수직형 에이전트와 인프라의 가치는 각 업무의 맥락을 얼마나 깊게 이해하느냐에 따라 달라진다.

• 모델은 좋아지고 있지만 비결정성과 다단계 도구 호출 때문에 에이전트를 안정적으로 만드는 일은 여전히 어렵다.
• 모델 안에 흡수될 임시 해법과 모델 밖에 계속 남을 데이터·API·검증·상태 관리를 구분해야 한다.
• 범용 모델만으로는 해결하기 어려운 도메인별 평가와 메모리 학습이 수직형 에이전트의 진입점이 된다.
• 추론 단가는 낮아지는 한편 토큰 사용량과 에이전트 호출량이 급증해 비용 관리와 인프라 투자가 중요해진다.

에이전트의 핵심 루프는 계속 모델이 도구를 호출하는 형태일 수 있지만, 그 바깥에는 사용 흔적을 읽고 컨텍스트·하네스·모델을 개선하는 학습 루프가 더해진다. 시장의 승자는 최신 모델에만 기대는 회사가 아니라, 특정 도메인에서 무엇이 좋은 결과인지 정의하고 그 지식을 제품에 축적하는 회사가 될 가능성이 높다.

---

1. LangChain의 역할과 에이전트 구축의 난점

LangChain은 모델과 도구·데이터·계산 자원을 연결하는 개발자 프레임워크를 만들고, LangSmith로 실행 추적과 관측성(observability), 평가(evals)를 제공한다. Harrison Chase는 에이전트 구축의 핵심 난관을 모델의 비결정성과 이를 둘러싼 시스템의 복잡성에서 찾는다.

1.1. 모델과 도구를 잇는 개발자 도구

1. LangChain은 에이전트의 연결·실행 틀을 제공한다

   1. 오픈소스 프레임워크: 모델을 도구, 데이터, 계산(computation) 등 유용한 에이전트 구성요소와 연결한다.
   2. 모델 외부의 실행 환경: 모델 자체가 API를 실행하거나 사내 데이터를 저절로 아는 것은 아니므로, 실제 시스템에서 필요한 호출과 결과 전달을 중개한다.

2. LangSmith는 에이전트의 실패를 관측하고 성능을 평가한다

   1. 실행 추적: 에이전트는 자주 잘못된 경로로 가므로 어떤 입력·호출·결과에서 문제가 났는지 알아야 한다.
   2. 평가와 반복 개선: 실패 원인을 측정해 다음 버전의 성능을 높이는 도구가 LangSmith의 역할이다.

1.2. 비결정적 모델과 연쇄 오류

1. 자연어 입출력은 사실상 매우 큰 입력 공간을 만든다

   1. 예측하기 어려운 사용자 입력: 챗봇 앞의 사용자는 무엇이든 입력할 수 있어 가능한 입력 범위를 미리 고정하기 어렵다.
   2. 작은 차이가 다른 결과를 만든다: 비슷한 질문에도 모델이 전혀 다른 답을 내놓을 수 있고, 프롬프트의 작은 변화가 출력에 영향을 준다.

2. 에이전트는 여러 모델 호출과 도구가 연결된 시스템이다

   1. 단일 호출이 아님: 에이전트는 모델 호출을 연속해서 수행하고 여러 외부 도구와 상호작용한다.
   2. 오류가 전파됨: 각 단계가 작은 블랙박스인 상태에서 하나의 큰 시스템을 이루므로, 한 단계의 오류가 다음 호출과 도구 사용으로 번지는 연쇄 오류(cascading errors)가 발생한다.

3. 성능 향상은 모델 발전과 하네스 개선이 함께 만든다

   1. 모델 역량의 발전: 3~4년 전보다 모델 자체가 좋아졌다.
   2. 모델을 다루는 방법의 발전: 모델을 더 잘 활용하도록 시스템을 구성하는 하네스(harness)도 개선됐다. LangChain은 이 하네스 영역에 집중한다.

1.3. 모델이 좋아질수록 제품을 지우는 역설

1. 모델 개선은 기존 제품 기능을 무용하게 만들 수 있다

   1. 제품 삭제 원칙: Cursor가 이야기한 “제품을 지우거나 삭제하라”는 원칙처럼, 모델이 발전하면 6개월 전에 필요했던 기능이 더 이상 필요하지 않을 수 있다.
   2. 오픈소스의 빠른 변화: 모델을 활용하는 올바른 프레임워크 방식은 한 달, 3개월, 6개월 단위로 바뀐다.

2. 창업자는 불확실성을 이유로 개발을 멈추기보다 판단해야 한다

   1. 대안은 ‘아무것도 만들지 않기’가 아니다: 지금 만든 제품이 6개월 뒤 사라질 수 있다는 우려가 있어도 계속 만들고, 어떤 요소가 남을지 교육된 추측(educated guess)을 해야 한다.
   2. 임시 해법과 지속 요소를 구분한다: LangChain은 초기 도구 호출을 위해 모델이 JSON DSL을 생성하게 한 뒤 파싱했다. 당시에도 임시방편임을 알았지만 가능한 유일한 방식이었다.

3. 모델 안으로 흡수될 기능과 외부 시스템에 남을 기능은 다르다

   1. 해법이 바뀐 도구 호출: OpenAI가 API에 직접 통합된 네이티브 도구 호출을 제공하자 LangChain은 JSON 파싱에서 빠르게 전환했다.
   2. 모델 밖에 남는 연결 작업: 모델은 기업의 독점 데이터나 실제 API 응답을 저절로 얻지 못한다. API 호출을 전달하고 결과를 받아 다시 모델 루프에 넣는 외부 시스템은 계속 필요하다.
   3. 모델이 흡수할 수 있는 해킹: 연쇄적 사고(chain of thought), 계획(planning), 도구 호출처럼 모델 또는 API에 더 밀접하게 통합될 수 있는 기능은 별도 하네스 구현이 사라질 수 있다.

---

2. 에이전트의 소유권과 수직형 에이전트의 경제성

에이전트의 장기적 경쟁력은 모델 하나보다 모델·하네스·컨텍스트를 누가 제어하고, 도메인별 성공을 누가 정의하느냐에 달려 있다. Chase는 특히 도메인 전문가가 평가 기준을 만들고 수직형 에이전트로 연결할 기회에 강한 확신을 보인다.

2.1. 컨텍스트와 메모리를 포함한 ‘지능의 소유’

1. 에이전트 실행 과정에서 모델 밖의 상태가 축적된다

   1. 여러 형태의 메모리: 단기·장기 메모리뿐 아니라 에이전트와 대화하며 쌓이는 기억, 환경과 상호작용하며 학습하는 정보가 상태(state)를 이룬다.
   2. 반복 사용의 학습 효과: 에이전트는 밖으로 나가 작업하고 대화하면서 다음 실행을 더 잘하기 위한 맥락을 축적한다. 이 학습의 일부는 가중치에 들어가지만 많은 부분은 컨텍스트에 남는다.

2. 모델 제공자 중립성은 이동성과 협상력을 준다

   1. 공격적 이점: 어떤 회사가 더 좋은 모델을 내놓든 가장 유능한 모델을 빠르게 선택할 수 있다.
   2. 방어적 이점: 단일 제공자에 종속되지 않아 가격 인상이나 불리한 조건을 견제할 수 있다.
   3. 하네스와 메모리의 결합 위험: 메모리가 특정 하네스의 형식에, 하네스가 특정 모델의 동작에 묶이면 데이터와 컨텍스트를 다른 모델로 옮기기 어려워진다.

3. 열린 에이전트 아키텍처는 세 층을 조정할 수 있어야 한다

   1. 모델: 작업에 맞는 모델을 바꾸고 통제한다.
   2. 하네스: 모델이 어떤 순서와 도구로 작업할지를 조정한다.
   3. 컨텍스트: 사용자·업무·환경에서 축적된 상태를 소유하고 이식 가능하게 관리한다.

4. 범용 모델 랩이 잘하는 업무와 각 도메인의 업무는 다르다

   1. 학습 데이터의 분포: 모델 회사는 코딩처럼 데이터가 많고 평가가 쉬운 작업에 맞춘 하네스를 잘 만들 수 있다.
   2. 업무별 통제 필요성: 영업, 연구, 법률 등은 코드를 일부 사용하더라도 고유한 도메인 지식과 실행 방식을 요구하므로, 모델 외부의 하네스와 컨텍스트를 통제할 여지가 크다.

2.2. 검증과 도메인 전문성이 수직형 에이전트를 만든다

1. 자동화에 앞서 성공 여부를 검증할 수 있어야 한다

   1. 가치의 선행 조건: 에이전트가 일을 잘했는지 확인하는 검증(verification)이 이뤄져야 다음 단계의 자동화를 맡길 수 있다.
   2. 도메인별 성공 정의: 무엇이 좋은 결과인지 정량화하는 일은 어렵고, 이를 평가식(evals)과 검증기로 만드는 데 도메인 지식이 필요하다.

2. 도메인 전문가가 평가 체계와 제품 경험을 설계한다

   1. 전문 지식의 제품화: 결과를 판별할 수 있는 전문가가 검증기를 만들면 해당 도메인의 업무에 맞는 하네스와 모델을 구성할 수 있다.
   2. 수직형 에이전트에 대한 확신: 가치는 하네스나 모델 한쪽에만 있지 않고, 도메인 지식을 반영한 조합에서 나온다. 따라서 Chase는 여러 산업의 수직형(vertical) 에이전트에 매우 낙관적이다.

3. 초기에는 하네스와 컨텍스트부터 최적화한다

   1. 첫 단계는 컨텍스트 엔지니어링: 모델을 추가 학습하기 전에 업무 지침, 도구, 데이터와 상태를 잘 구성한다.
   2. 사용자가 생긴 뒤 모델을 조정한다: 실제 사용 데이터와 실패 사례를 확보한 다음 모델 후속 학습(post-training)을 검토하는 편이 투자 대비 효과가 높다.

2.3. 모델을 통제하는 단계와 후속 학습의 현실

1. ‘지능 소유’에는 비용이 다른 여러 단계가 있다

   1. 컨텍스트 제어: 외부 하네스와 기성 모델은 그대로 쓰면서 컨텍스트만 통제하는 가장 저렴한 단계다.
   2. 하네스 제어: 에이전트의 실행·도구·메모리 흐름을 직접 바꾸며 더 많은 통제권을 얻는다.
   3. 오픈 가중치 모델의 후속 학습: 특정 도메인에 맞춰 공개 가중치 모델을 추가 학습한다. Harvey와 Ramp처럼 풍부한 인재·데이터·사용량을 가진 회사들이 이 단계에 도달할 수 있다.
   4. 처음부터 모델을 학습: 가장 많은 자원이 드는 단계다. Chase는 Neolab 같은 소수의 기업을 제외하면 대부분이 기초 모델을 처음부터 훈련하는 것은 아니며, 공개 모델을 후속 학습한다고 본다.

2. 후속 학습은 에이전트 주변의 단순 작업에서 먼저 효율을 낸다

   1. 잘 맞는 작업: 분류(classification), 정보 추출(extraction), 요약(summarization), 가드레일, 라우팅처럼 더 큰 하네스가 호출하는 작은 작업은 특화 모델로 효율화하기 쉽다.
   2. 핵심 루프는 아직 열린 문제: 도구를 계속 호출하며 작업을 이끄는 중심 모델은 프런티어 모델이 더 나은지, 특화 후속 학습 모델이 더 나은지 결론이 나지 않았다.
   3. 실험은 이미 시작됐다: Harvey가 핵심 에이전트 루프에 후속 학습 모델을 적용하는 방향을 공개하는 등 여러 기업이 실험하고 있지만, 시작부터 자체 모델을 만드는 것은 권하지 않는다.

---

3. 모델 라우팅, 평가와 지속 학습

모델 라우팅은 API 하나로 모든 업무를 해결하는 범용 상품이 아니라, 작업 상태와 하네스의 맥락을 읽어야 하는 도메인별 기능이다. 라우팅과 평가의 결과는 실행 기록을 실제 개선으로 연결할 때만 사업적 가치가 생긴다.

3.1. 게이트웨이 라우팅과 하네스 라우팅의 차이

1. 게이트웨이는 이식성이 높지만 업무 맥락이 제한된다

   1. 기존 하네스에 쉽게 연결: 라우팅을 게이트웨이 API에 두면 Claude Code 같은 외부 하네스를 바꾸지 않고도 여러 모델을 연결할 수 있다.
   2. 접근성 자체의 가치: OpenRouter나 Vercel 같은 게이트웨이는 여러 모델에 단일 API와 키로 접근하게 해준다. Chase는 이들 사용의 상당 부분이 지능형 라우팅보다 모델 접근성을 위한 것이라고 추정한다.
   3. 입력 상태의 한계: 일반적인 API는 프롬프트 등 제한된 입력만 볼 수 있어, 하네스 안에 있는 실행 상태를 충분히 알기 어렵다.

2. 하네스는 라우팅에 필요한 상태를 더 많이 안다

   1. 프롬프트 캐시 관리: 어떤 접두부를 유지해야 캐시를 따뜻하게(warm) 보존하는지 하네스가 더 잘 안다.
   2. 모델별 프롬프트 전략: 모델마다 다른 프롬프트 방식을 사용하므로, 하네스에서 모델에 맞춰 프롬프트를 더 쉽게 조정할 수 있다.
   3. 실행 중 도구·상태 변화: 작업 도중 도구가 바뀌는 상황도 하네스가 관찰하고 처리할 수 있다.

3. 라우팅 위치는 업무 범위에 따라 달라진다

   1. 수직형 에이전트: 법률·금융처럼 특정 업무를 깊이 수행한다면 해당 도메인과 하네스를 아는 라우팅이 필요하므로 하네스에 두는 편이 낫다.
   2. 수평형 업무: 일반 대화나 범용 코딩에서는 업무 분류만으로 저렴한 모델과 고성능 모델을 나누는 게이트웨이 라우팅이 가능할 수 있다.
   3. 모델 우위의 빠른 변화: 특정 모델이 어떤 작업에서 낫다는 판단은 새 모델 출시로 금세 달라진다. 최신 모델이 여러 작업에서 동시에 우위를 보이면 라우팅의 차별화 가치는 줄어들 수 있다.

4. 스마트 라우팅은 단순한 가격표 비교가 아니다

   1. 태스크 인식이 필요하다: 같은 모델 선택 규칙을 법률·금융·코딩에 공통 적용하기 어렵다.
   2. 범용 라우터의 적용 한계: 범용 대화와 코딩의 일부를 제외하면, 수직 업무 라우팅은 특정 도메인의 평가 기준과 실행 상태에 맞게 만들어야 한다.
   3. 상품화 여부: 많은 회사가 라우팅을 직접 만들겠지만, 모델이 빠르게 바뀌고 맥락 의존성이 커서 쉽게 상품화(commodity)되지는 않을 것이라는 전망이다.

3.2. 평가 지표와 추적 데이터의 사용

1. 공개 벤치마크만으로 모델 품질을 판단하기 어렵다

   1. 벤치마크 최적화: 모델이 공개 학술 평가에 맞춰 최적화되면, 점수 상승만으로 실제 업무 역량을 알기 어렵다.
   2. 내부 도메인 평가의 필요: 실제 업무에 맞춘 사내 평가와 검증기는 여전히 쓸모 있으며, 수직형 에이전트 개발의 핵심 기반이다.

2. 하나의 숫자보다 실행 데이터와 트레이스를 봐야 한다

   1. 행동 방식의 변화: 점수가 올라도 모델이 이전과 다른 방식으로 문제를 풀 수 있으므로 결과 숫자 하나에만 의존하면 안 된다.
   2. 추적 기록으로 원인 파악: 프롬프트, 모델 호출, 도구 결과가 담긴 트레이스(trace)를 읽어 어떤 변화가 있었는지 확인한다.
   3. 평가도 갱신해야 한다: 모델이 새로운 능력을 보이거나 다른 실패를 만들면 내부 평가 기준을 계속 바꿔야 한다.

3. 트레이스의 가치는 개선된 구성요소로 되돌아갈 때 생긴다

   1. 컨텍스트·메모리 개선: 트레이스를 다른 에이전트가 읽고 유용한 사실을 정리해 메모리로 보낼 수 있다.
   2. 하네스 개선: 트레이스에서 발견한 문제를 바탕으로 실행 코드를 수정할 수 있다. LangSmith의 Engine은 트레이스를 읽고 코드를 고치려는 에이전트다.
   3. 모델 개선: 후속 학습은 트레이스에서 얻은 사례와 교훈을 가중치로 반영하는 한 가지 방식이다.
   4. 변경 검증: 어느 층을 바꿨든 더 나아졌는지 다시 평가해야 한다.

4. 지속 학습은 기존 루프 바깥의 개선 루프다

   1. 핵심 작업 루프: 에이전트 내부에서는 LLM이 도구를 부르며 환경과 상호작용하는 기본 구조가 유지된다.
   2. 외부 학습 루프: 실행 흔적을 모으고, 교훈을 뽑고, 컨텍스트·하네스·가중치를 수정한 다음 평가하고 반복한다.
   3. 학습 방식은 서로 다르다: 메모리 파일 갱신과 모델 가중치 업데이트는 구현이 매우 다르지만, 흔적에서 배우고 실제 개선 여부를 확인한다는 바깥 루프는 비슷하다.

3.3. 데이터베이스보다 어려운 메모리의 정보 선별

1. 에이전트 컨텍스트 계층은 데이터베이스만으로 완성되지 않는다

   1. 기존 데이터베이스의 역할: ClickHouse나 Elasticsearch 같은 시스템은 기존 소프트웨어가 만든 데이터를 저장하고 질의하는 데 강하다.
   2. 에이전트 주변의 지능: 관측을 무엇으로 요약하고 어떻게 다음 작업의 맥락으로 만들지 결정하는 지능형 시스템이 데이터베이스 위에 필요하다.

2. 메모리의 어려움은 저장보다 기억할 사실을 고르는 데 있다

   1. 간단한 저장 방식도 가능: 일부 회사는 메모리를 단일 파일에 저장하는 간단한 방법을 사용한다.
   2. 관측의 정제: 사용자가 SaaS를 이용하거나 에이전트와 대화하는 동안 쌓이는 정보 중 다음 실행에 가치가 있는 것만 추려야 한다.
   3. 정보를 과도하게 쌓지 않기: 무엇을 기억하고 어떤 상태를 버릴지 판단하는 과정이 메모리의 핵심 난관이다.

3. 메타 성찰은 모델과 사람 모두에게 어렵다

   1. 자기 개선의 한계: 모델은 프롬프트를 되돌아보고 더 나은 프롬프트를 만들거나 에이전트 구조를 평가해 개선하는 메타 작업에 아직 약하다.
   2. 정답 구조도 불명확하다: 학습 에이전트의 입력·출력, 하네스, 워크플로우를 어떻게 설계해야 하는지 합의된 답이 없다.
   3. 향후 평가 대상: LangSmith Engine과 같은 시스템을 평가할 내부 벤치마크를 만드는 일이 필요한 과제로 언급된다.

---

4. 메모리 중심 제품과 에이전트가 바꿀 서비스 인터페이스

개인화 메모리는 앞으로 많은 제품에 들어갈 가능성이 크지만, 범용 메모리 솔루션의 정답은 아직 없다. 소비자와 기업 모두에서 수평형 에이전트와 앱별 수직형 에이전트가 서로 연결되는 구조가 유력하다.

4.1. 메모리 제품의 현재와 제품-시장 적합성

1. 메모리는 개인화와 능동성을 높인다

   1. 사용자별 경험: Instinct와 Muse는 사용자 말투에 맞추고 이전 상호작용을 기억하며 먼저 후속 행동을 제안하는 면에서 좋은 사례로 언급된다.
   2. 향후 보편화: Chase는 몇 년 안에 대부분 제품에 일정한 형태의 메모리가 포함될 것으로 예상한다.

2. 문제의 중요성과 해결책의 명확성은 별개다

   1. 필요성은 널리 인정된다: 메모리가 사용자 경험을 바꿀 것이라는 점 자체는 사람들이 관심을 갖는 이유다.
   2. 정답은 여전히 비자명하다: 메모리가 어떻게 작동해야 하는지 아무도 확실히 모른다. 관심이 크다는 사실이 구현 방법을 알려주지는 않는다.

3. LangChain의 범용 메모리 상품은 PMF를 찾지 못해 중단됐다

   1. 상용 솔루션 종료: 오픈소스 알파를 내놓은 뒤 상업용 메모리 솔루션을 만들었지만 제품-시장 적합성(product-market fit)을 찾지 못해 중단했다.
   2. 너무 일반적이었던 접근: 메모리 문제는 도메인별·에이전트별로 달라 범용 제품을 만들려 한 것이 맞지 않았다고 회고한다.

4. 기억하는 에이전트는 특정 업무에 맞춰야 한다

   1. 도메인별 기억 기준: 무엇을 중요한 사실로 보느냐는 Instinct나 Muse, 기업 업무, 법률, 금융에서 모두 다르다.
   2. 학습 전담 에이전트: 기존 메모리 구조를 탐색하거나 사실을 정제하는 하위 에이전트와 특화 도구를 두는 구성이 가능하다.
   3. 하네스의 형태: LangChain의 Deep Agents처럼 모델이 루프를 돌면서 구체적 지침·도구·하위 에이전트를 쓰는 방식이 될 수 있다.

4.2. 소비자 서비스의 수직형 에이전트와 수평형 에이전트

1. 수평형 에이전트는 앱별 에이전트와 협력할 수 있다

   1. 두 유형의 공존: 소비자 시장에는 여러 서비스를 넘나드는 수평형 에이전트와 각 앱에 속한 수직형 에이전트가 함께 존재할 수 있다.
   2. 앱은 사용자를 더 잘 안다: Spotify는 사용자의 음악 취향과 이용 방식을 Strava보다 잘 알고, Strava는 운동 습관을 더 잘 안다.

2. 앱별 지식과 API는 수직형 에이전트의 자산이다

   1. 도메인별 개인화: 앱은 사용자와의 상호작용을 통해 범용 에이전트보다 그 앱 안의 선호를 잘 학습할 수 있다.
   2. 여러 API를 자연어로 감싼다: 앱이 API만 노출하는 것보다, 앱의 에이전트가 API를 묶어 수평형 에이전트가 쓸 자연어 인터페이스를 제공하면 사용 경험이 나아질 수 있다.

3. 광고와 추가 구매도 에이전트 경험에 포함될 수 있다

   1. 기존 수익 모델의 우려: 에이전트가 앱의 화면을 대신하면 광고 노출과 “함께 살 만한 상품” 추천, 장바구니 규모가 줄 수 있다는 질문이 제기된다.
   2. 대화형 제안: 에이전트 응답 안에 관련 상품이나 광고성 제안을 자연스럽게 넣을 수 있다. 예를 들어 Resy나 Etsy가 선택지 세 개와 함께 다른 추천을 제안할 수 있다.

4. 서비스 제공자는 자체 에이전트를 외부에 내놓을 가능성이 크다

   1. 수평형과 수직형의 연결: 사용자의 주 에이전트가 예약·쇼핑 서비스가 운영하는 에이전트에 요청을 맡기는 구도다.
   2. 호출 효율: 서비스에 특화된 에이전트가 원래 시스템을 더 효율적으로 다룰 수 있어, 제3자 에이전트가 무수한 API를 직접 찌르는 방식보다 낫다.

4.3. 에이전트 트래픽이 만드는 인프라 변화

1. 자동화는 사람보다 훨씬 많은 요청을 만들 수 있다

   1. 티켓 구매 사례: 특정 공연의 좌석이 나오면 사도록 3일 동안 5분마다 확인시키는 요청은 사람이 한 번씩 확인할 때보다 호출량을 약 1,000배 늘릴 수 있다는 예가 제시된다.
   2. 실제 서비스 차단 사례: Resy가 Instinct를 이용해 자주 호출한 사용자를 막았다는 사례가 언급되며, 에이전트 사용이 기존 서비스 제한과 충돌할 수 있음을 보여준다.

2. 서비스 인프라는 더 큰 순간 부하를 견뎌야 한다

   1. 요청량의 증가: 에이전트가 사이트와 API를 지속적으로 확인하면 전체 호출량이 급증한다.
   2. 버스트 대응: 서비스는 더 크게 확장되고 갑작스러운 요청 폭증을 감당하는 구조가 필요하다. 구체적으로 어떤 하위 인프라가 바뀔지는 아직 불분명하다고 선을 긋는다.

---

5. 추론 비용, 개발 조직과 기업의 지출

모델 단가는 내려가도 멀티 에이전트와 에이전트 간 호출로 토큰 사용량이 늘면 총비용은 오를 수 있다. LangChain은 비용을 투명하게 보고, 예산을 제어하고, 하네스 자체를 효율화하는 세 단계로 대응한다.

5.1. 단가 하락과 총사용량 증가의 동시 진행

1. 프런티어 추론의 가격 대비 성능은 개선되고 있다

   1. 모델 단가의 하락: 프런티어 모델은 1년 전보다 가격 대비 성능이 좋아지는 흐름이다.
   2. 수요 측면의 반대 압력: 에이전트가 다른 에이전트와 상호작용하거나 여러 모델을 부르면 토큰 소비가 크게 늘어난다.

2. 코딩 에이전트 사용량과 비용은 빠르게 커졌다

   1. 전체 비용의 상승: 코딩 에이전트 사용이 늘면서 회사의 코딩 비용이 크게 증가해 조직들이 지출을 관리하기 시작했다.
   2. 성능만큼 효율도 중요해짐: 초기 하네스 개발은 정확도와 기능 개선에 집중했지만, 비용 부담이 커지면서 캐싱과 라우팅 등 비용 효율화가 중요해졌다.

5.2. 지출을 통제하는 세 단계

1. 첫째, 사용량을 보이게 만든다

   1. 관리자 가시성: 누가 얼마를 쓰고 어떤 작업에 쓰는지 기록하고 분석한다.
   2. LangSmith 추적: LangChain은 코딩 에이전트 사용을 LangSmith에 기록해 사용자별·작업별 지출을 확인했다.

2. 둘째, 기본적인 예산과 안전장치를 둔다

   1. 상한선 설정: “예약을 찾아오되 수행 비용은 5달러를 넘지 말라”처럼 작업별 예산을 줄 수 있다.
   2. 예외와 오용 감지: 예산을 넘으면 엔지니어링 부사장과 상의해 거의 늘 한도를 올리지만, 잘못된 설정이나 루프가 비용을 폭발시키는 일을 막는 안전장치로 기능한다.

3. 셋째, 하네스와 모델 API를 바꿔 비용을 줄인다

   1. 프롬프트 캐시와 모델 라우팅: 반복되는 맥락은 캐시에 남기고 작업에 맞는 모델을 선택한다.
   2. 실행 도중 도구 추가: 예전에는 에이전트 실행 중 도구 목록을 바꾸면 캐시가 무효화되어 비용이 크게 늘었다. API가 도구를 동적으로 추가할 수 있게 되면서 캐시를 유지하기 쉬워졌다.
   3. 자체 클라우드 코딩 에이전트: LangChain은 IDE나 터미널을 대체하는 대신 OpenSuite라는 사내 클라우드 코딩 에이전트를 만들었다. Harrison Chase는 Slack에서 메시지를 보내 작업을 시작하는 이 도구가 자신이 사용하는 유일한 코딩 방식이라고 설명한다.

5.3. 지출 데이터가 보여준 비용 폭증과 조직 설계

1. 많이 쓰는 사람이 항상 비효율적인 것은 아니다

   1. 고효율 사용자의 큰 지출: 일부 시니어 엔지니어는 많이 쓰더라도 가치 있는 작업을 수행하므로 신뢰할 수 있다.
   2. 잘못된 설정의 폭증: 반면 의도하지 않은 플러그인 동작이나 루프는 비용을 만들 수 있어 사용량을 살펴야 한다.

2. DOM 스크린샷 루프는 일주일에 4만 달러를 썼다

   1. 프런트엔드 작업 플러그인: 웹페이지의 DOM을 캡처하고 에이전트의 매 호출마다 스크린샷을 다시 보내는 플러그인이 있었다.
   2. 의도하지 않은 반복: 에이전트가 대규모 루프를 돌며 캡처 데이터를 계속 전송했고, 단일 작업에 일주일 약 4만 달러가 들었다. 악의적 사용이 아니라 설정 실수였기에 가시성과 한도 설정이 필요했다.

3. 에이전트 지출 비중은 조직 형태에 따라 크게 달라진다

   1. 현재 추정치: LangChain은 엔지니어링 급여의 약 30%를 코딩 도구에 지출한다고 추산한다. 최근 두 달 동안 토큰 사용량은 증가했지만 이 비율은 낮아졌다.
   2. 소규모 팀의 가능성: 장기적으로 소수 인원이 다수의 에이전트를 이끌며 훨씬 적은 인력으로 제품을 만들 수 있다는 매력적인 전망이 있다.
   3. 사람의 역할은 남는다: 현재는 서로 다른 전문성, 커뮤니케이션, 협업, 검토가 여전히 필요하다. 에이전트를 잘 운용하는 엔지니어가 더 높은 보수를 받으면 인원은 줄어도 에이전트 비용과 인건비의 합계는 비슷할 수 있다.
   4. 예측의 불확실성: 에이전트 비용이 급여와 같거나 그보다 한 자릿수 배 더 커지는 조직도 가능하지만, 도입 수준과 조직 구조가 빠르게 변해 2년 뒤 수치를 단정하기 어렵다.

4. 기업이 보는 우선순위는 정확도·비용·지연·보안이다

   1. 개발자 조사: 최근 2년간 개발자들이 가장 중요하게 꼽은 항목은 정확도였고, 다음 두 항목보다 약 두 배 많은 응답을 받았다.
   2. 대기업의 관심 변화: 정확도가 여전히 최우선이고, 비용은 최근 더 중요해져 지연보다 우선할 수 있다. 대기업에서는 보안의 중요성도 높지만 정확도와 비용보다 뒤에 놓인다고 설명한다.

5. 에이전트 지출은 모델 기업의 성장 논리를 뒷받침한다

   1. 호스트의 시나리오: 기업의 엔지니어링 급여 대비 에이전트 지출이 5%에 머물면 높은 기업가치를 정당화하기 어렵지만, 300%까지 확대되면 모델 기업 가치가 크게 높아질 수 있다는 예가 나온다.
   2. 아직은 코딩 중심: 에이전트의 뚜렷한 기업 효과는 아직 소프트웨어 엔지니어링에 집중되어 있다.
   3. 다른 업무의 잠재력: 영업·법률·금융 등 다른 부문은 본격적인 영향을 받기 전이라, 더 큰 사용량이 추가로 생길 수 있다는 점에서 모델 제공자에게 낙관적이다.

---

6. 오픈 모델과 추론 인프라 시장

오픈 모델은 모든 에이전트의 중심 모델을 대체하기보다, 반복량이 많고 작업 정의가 쉬운 구성요소에서 먼저 높은 투자 대비 효과를 낸다. 추론 수요는 예상을 크게 웃돌아 한 회사만 살아남는 시장이라기보다 여러 인프라 사업자가 함께 성장할 정도로 크다는 시각이다.

6.1. 오픈 가중치 모델에 대한 현실적인 판단

1. 중국 오픈 모델에 대한 우려는 사용 방식에 따라 다르다

   1. 데이터가 해외 연구소로 전송될 우려: Fireworks에서 호스팅하거나 기업이 직접 운영한다면 데이터가 중국 연구소로 돌아간다는 우려는 맞지 않는다고 본다.
   2. 응답 성향과 기업 가치: 모델 학습 방식이 기업의 가치와 맞지 않는 답변을 만들 수 있다는 걱정은 일부 도메인에서 평가가 필요하지만, 대체로 과장됐을 가능성이 있다고 말한다.

2. 미국 오픈 모델의 경쟁력은 높아질 것으로 본다

   1. 12개월 전망: NVIDIA가 생태계에 투자하고 있으며 Reflection 등 신규 출시도 있어, 미국 오픈 모델이 12개월 내 경쟁 가능한 수준에 도달할 것으로 예상한다.
   2. 당시 벤치마크 격차: Reflection 모델은 일부 벤치마크에서 중국 모델보다 뒤처졌지만 관심과 개발 역량이 빠르게 집중되고 있다.

3. 오픈 모델은 보조 작업에서 먼저 확산된다

   1. 이미 늘어난 사용량: 오픈소스와 후속 학습 모델 사용은 1~1.5년 전 예상보다 많다.
   2. 주요 용도: 라우팅, 가드레일, 추출, 요약 같은 단순 작업이 중심이며, 주요 에이전트를 움직이는 핵심 루프는 대체로 프런티어 모델이 담당한다.
   3. 중간 지점의 관점: 오픈 모델이 모든 작업에 충분하다는 주장과 프런티어 모델만 계속 쓰면 된다는 주장 사이에서, 높은 호출량의 단순 작업에 특화 모델을 적용하는 것이 현실적인 절충안이다.

6.2. 추론 시장의 예상 밖 규모

1. 추론과 코딩 에이전트의 수요를 과소평가했다

   1. 두 가지 오판: LangChain을 시작한 뒤 현재까지 Chase가 크게 과소평가했다고 꼽은 시장은 추론과 코딩 에이전트다.
   2. 수요가 공급을 끌어간다: 모델 호출 시장은 너무 커서 특정 사업자 하나만 승자가 될 필요가 없고, 인프라가 “그냥 작동하기만 하면” 여러 공급자가 수요를 받을 수 있다는 관점을 인용한다.

2. 추론 공급자마다 함께 성장할 여지가 있다

   1. 다양한 사업자: Fireworks, AWS, Crusoe를 각각 추론 시장의 참여자로 들며, 시장이 당분간 줄어들지 않을 만큼 수요가 크다고 본다.
   2. 자체 전체 스택이 필수는 아니다: 모든 기업이 데이터센터부터 모델 서빙까지 전부 직접 소유해야 한다는 뜻은 아니다. 시장의 여러 계층에서 전문 공급자가 성장할 수 있다.

---

7. 투자 관점과 AI 기업의 승리 조건

가장 매력적인 기회는 유행하는 분야 자체보다, AI 침투율은 낮고 현장 지식은 축적된 산업을 깊이 파고드는 수직형 소프트웨어다. 기술 인재, 빠른 실행, 브랜드가 중요하며, 선점은 강력하지만 실행을 대신하지 않는다.

7.1. 투자할 분야와 피하고 싶은 분야

1. 추론과 개발 인프라는 직접적인 수혜 영역이다

   1. 추론: 예상보다 큰 토큰 수요를 받아낼 추론 인프라를 긍정적으로 본다.
   2. 저층 인프라: Modal의 샌드박스, Temporal의 워크플로우, Supabase와 Convex 같은 기반 도구를 거론한다. 모델을 실제 제품에 적용하는 코딩·실행 인프라의 필요가 커질 수 있다.

2. 도메인 지식이 깊은 수직형 에이전트에 기회가 있다

   1. 특정 업종을 미리 고르기보다 깊이를 본다: 특정 수직 분야 하나에 과도하게 베팅하기보다, AI 활용이 낮고 전문가 지식은 많이 쌓인 분야를 찾는 것이 중요하다.
   2. 전문 지식의 표현: 업무 지식을 데이터나 하네스 로직으로 담아 실제 작업에 연결해야 한다. 초기부터 모델 가중치에 넣는 데 집중할 필요는 없다.

3. 로보틱스는 장기 기회지만 기대가 역량보다 앞섰다

   1. 휴머노이드의 한계: 휴머노이드 로봇은 아직 ChatGPT 순간에 이르지 못했고, 형태와 실제 수행 능력에 큰 제약이 있다.
   2. 자금과 기술 사이의 격차: 로보틱스에 들어가는 투자금과 열광이 기술의 현재 성숙도보다 훨씬 앞서 있다는 것이 Chase의 조심스러운 견해다. 그는 AI의 변혁적 잠재력 자체는 낙관한다.

7.2. 빠르게 움직이는 시장에서 회사를 키우는 조건

1. 깊은 기술을 만들 인재가 필요하다

   1. 기술 역량의 희소성: Modal의 기술팀, Fireworks 창업팀의 PyTorch 작업 경험 등을 예로 들며 저층 인프라를 만들 수 있는 기술 인재가 드물다고 말한다.
   2. 인재 밀도가 차이를 만든다: 매우 강한 팀은 복잡한 인프라와 빠른 제품 개선을 동시에 해낼 수 있다.

2. 실행 속도가 변화를 따라잡는다

   1. 빠른 통합: LangChain은 새 도구와 모델을 빠르게 통합하는 능력을 경쟁우위로 본다.
   2. 시장 변화에 대한 대응: 모델과 개발 방식이 빠르게 바뀌므로, 아이디어를 검증하고 제품에 반영하는 속도가 중요하다.

3. 브랜드는 초기 유행을 지속적인 이점으로 바꾼다

   1. 초기 바이럴 이후의 실행: LangChain, Cursor, Jev, Claude Code 등의 사례를 들며 초기 화제성을 시장 인지도와 사용자 기반으로 전환하는 능력이 중요하다고 본다.
   2. 높은 기업가치도 예외가 될 수 있다: 강한 기술팀과 실행력이 이미 입증된 돌파 기업이라면 높은 가격을 따지기 전에 투자할 수 있다는 견해를 밝힌다.

4. 선점은 강력하지만 자동 성공을 보장하지 않는다

   1. 초기 진입의 이점: LangChain과 Claude Code처럼 먼저 자리 잡은 브랜드가 시장에서 큰 이점을 누릴 수 있다.
   2. AutoGPT의 반례: AutoGPT는 LangChain 이후 등장해 역사상 가장 빠른 GitHub 프로젝트 성장 기록을 세웠지만, 빠른 시작만으로 계속 성공이 보장되지는 않았다.
   3. 결국 후속 실행이 필요하다: 선점 뒤에도 제품을 발전시키고 시장을 붙잡아야 한다.

7.3. 특정 투자 사례와 VC의 기여

1. Jev의 대규모 투자 라운드에 대한 강세 논리

   1. 새로운 모델 범주: Jev는 새로운 추론·모델 유형을 만들었고 그 범주가 회사 이름과 연결됐다는 점이 강세 논리다.
   2. 팀의 실행 역량이 전제다: 90억 달러 라운드를 정당화하려면 그 범주를 만든 팀이 높은 실행력을 보여줄 것이라는 가정이 필요하다고 말한다.

2. Benchmark는 공동창업자처럼 회사 성장에 관여했다

   1. 초기 투자 시점: LangChain이 Harrison Chase와 Ankush 두 명뿐일 때 Benchmark가 투자했고, 회사는 이후 약 400명 규모로 성장했다.
   2. 핵심 사업의 사운딩 보드: Benchmark는 회사의 핵심 정체성, 포지셔닝, 회사 만들기 관련 조언에 특히 강점을 보였다고 설명한다.

3. Sequoia는 운영과 인재 영입을 넓게 지원했다

   1. 투자 시점과 파트너: Benchmark 라운드 약 2~3개월 뒤 Sequoia가 합류했고 Sonia가 주요 파트너였다.
   2. 지원 범위: Sequoia는 실무자와 임원 채용, 마케팅, 출시 등을 체계적으로 지원했으며 추천을 통해 강한 후보자를 많이 만났다.
   3. 상위 VC의 할인 가치: 창업자가 Benchmark나 Sequoia 같은 최상위 VC에 더 낮은 가격을 제시하는 것도 가치가 있을 수 있다고 답한다.

4. 장기 관계가 펀드레이징의 불필요한 게임을 줄인다

   1. 신호 경쟁의 구조: 한 곳에서 받은 텀시트를 다른 투자자에게 알려 협상력을 만드는 등, 펀드레이징에는 일종의 게임이 있다.
   2. 창업자의 선호: Harrison Chase는 매출 그래프를 소셜미디어에 올리거나 텀시트로 서로를 압박하는 자세를 싫어하며, 함께 좋은 회사를 만들고 싶은 사람과 일하고 싶다고 말한다.
   3. IVP와의 관계: Series B에서 Tom과 투자 이야기가 본격화되기 전부터 약 2년 반 동안 관계를 쌓아왔고, 그 덕에 게임이 적었다고 느꼈다.

---

8. 빠른 질의응답과 5년 전망

마지막 문답은 에이전트 구축의 난이도와 추론 시장의 크기를 다시 확인하고, LangChain의 기술적 과제·투자 선택·창업 회고와 창의적 AI에 대한 기대를 짚는다.

8.1. 회고와 즉답

1. 에이전트에 대한 가장 중요한 믿음

   1. 여전히 어렵다: 생태계가 에이전트를 실제로 만드는 일을 얼마나 어려워하는지 과소평가한다고 답한다.
   2. 겉보기 데모와 제품 신뢰성의 차이: 모델 호출이 성공하는 것과 제품 환경에서 안정적으로 동작하는 것은 다른 문제다.

2. 지난 12개월간 가장 크게 바뀐 생각

   1. 추론 시장은 거대하다: 1년 반 전 OpenRouter 같은 회사보다 더할 가치가 있는지 확신하지 못해 게이트웨이를 만들지 않기로 했던 판단은 완전히 틀렸다고 회고한다.
   2. 수요를 다시 평가해야 한다: 당시보다 훨씬 큰 추론 수요와 코딩 에이전트 사용량을 뒤늦게 확인했다.

3. 가장 어려웠던 기술 구축

   1. Smith DB: 에이전트 트레이스를 저장하는 자체 데이터베이스를 구축한 일이 가장 어려웠다고 답한다.
   2. 협력과 경쟁의 공존: ClickHouse와는 고객이면서 경쟁 관계인 경우를 포함해 약 500개 회사와 친구이자 경쟁자(frenemies)로 지낸다고 농담한다.

4. IPO 선택과 창업 초기에 대한 회고

   1. OpenAI 선택: OpenAI를 1조 5천억 달러, Anthropic을 2조 달러로 가정한 즉답 질문에서 OpenAI를 택한다. 크게 성장할 수 있는 경로가 더 다양하다고 본다.
   2. 2022년에 알았으면 한 것: 현재의 하네스가 어떤 모습일지 알았다면 더 일찍 만들었을 것이라고 말한다.

5. VC와의 개인적 순간

   1. 가장 좋아한 미팅: 첫 Benchmark 투자 미팅을 꼽으며 방 안에 전설적인 인물들이 많았다고 회상한다.
   2. Bill Gurley: 함께 어울리기 가장 멋진 투자자로 Bill Gurley를 꼽는다. 당시에는 너무 순진해서 위축될 겨를이 없었지만, 큰 체격 때문에 위압감이 있었다는 진행자의 농담이 이어진다.

8.2. 앞으로의 기대: 생산성에서 창의성으로

1. 기업 효율화만으로 AI의 가능성을 좁히지 않는다
   1. 현재의 초점: LangChain이 주로 다루는 것은 기업의 효율성과 결과물 개선이다.
   2. 창의적 제품에 대한 기대: 5년 뒤에는 Suno 같은 생성형 창작 도구처럼 사람들이 새롭고 창의적인 일을 할 수 있게 하는 AI 제품이 더 많이 나오는 것을 기대한다.

---

주요 발언 모음

“I really underestimated the demand for inference. Everything just works. This market is so big. There's just so much demand for it.”
“추론 수요를 정말 과소평가했다. 모든 것이 작동한다. 시장은 너무 크고 수요도 정말 많다.”

“The hardest part of memory is actually not the database at all.”
“메모리에서 가장 어려운 부분은 데이터베이스가 전혀 아니다.”

“It's still really hard to build them like really really hard.”
“에이전트를 만드는 일은 지금도 정말 어렵다. 정말, 정말 어렵다.”

“I wish I knew what harnesses today looked like so we could have built them earlier.”
“오늘날의 하네스가 어떤 모습인지 알았더라면 더 일찍 만들 수 있었을 텐데.”

“I'm really excited for what creative things we can do with AI.”
“AI로 어떤 창의적인 일을 할 수 있을지 정말 기대된다.”

핵심 데이터 & 수치

• 엔지니어링 급여의 약 30%: LangChain이 코딩 도구에 쓰는 비용의 대략적인 추정치이며, 최근 두 달간 토큰은 늘었지만 비율은 낮아졌다.
• 일주일 약 4만 달러: DOM 스크린샷을 에이전트 매 턴마다 전송한 플러그인 루프에서 발생한 의도하지 않은 비용이다.
• 약 1,000배 호출량: 티켓을 3일 동안 5분마다 확인시키는 에이전트 요청은 사람의 확인보다 호출량이 크게 늘 수 있다는 예시다.
• 개발자 우선순위: 최근 2년 설문에서 정확도가 1위였고, 다음 두 항목보다 약 두 배 많이 선택됐다. 대기업은 비용을 지연보다 더 우려하는 흐름을 보인다.
• 약 400명: 두 명이던 LangChain이 Benchmark 투자 이후 성장한 인원 규모로 언급됐다.
• 약 2~3개월: Benchmark 투자 뒤 Sequoia가 합류하기까지의 간격이다.
• 약 2년 반: Series B를 이끈 IVP의 Tom과 펀드레이징 전부터 관계를 쌓은 기간이다.
• 90억 달러 Jev 라운드: 새로운 모델 범주와 팀의 실행력을 근거로 제시한 강세 논리의 맥락이다.
• 1조 5천억 달러 대 2조 달러: OpenAI와 Anthropic의 가상 IPO 가격을 놓고 OpenAI를 선택한 즉답 문답의 가정이다.
• 12개월: 미국 오픈 모델이 중국 모델과 경쟁 가능한 수준에 도달할 것으로 본 전망의 기간이다.

결론 및 시사점

1. 에이전트 제품의 핵심은 모델 성능만이 아니다. 모델이 바뀌어도 살아남는 외부 데이터·API 연결, 작업 상태, 평가 체계와 도메인 지식에 투자해야 한다.
2. 초기에는 컨텍스트와 하네스를 최적화한다. 사용자가 생기기 전에 자체 모델을 학습하기보다, 어떤 결과가 좋은지 측정하고 도구와 실행 흐름을 먼저 다듬는다.
3. 라우팅은 맥락을 알아야 가치가 있다. 범용 대화와 코딩은 게이트웨이 라우팅이 가능하지만, 수직형 제품은 도메인·하네스·캐시 상태를 아는 내부 라우팅이 필요하다.
4. 평가 점수와 트레이스를 함께 본다. 공개 벤치마크에 과적합하지 말고 실제 업무 데이터를 살펴 평가 기준을 계속 갱신하며, 개선된 변경을 다시 검증한다.
5. 메모리는 데이터베이스가 아니라 정보 선별 문제다. 사용 기록에서 다음 작업에 도움이 될 사실을 골라내고, 이를 도메인에 맞는 컨텍스트로 만드는 학습 루프가 필요하다.
6. 총비용은 단가와 별개로 증가할 수 있다. 사용량을 추적하고 예산을 설정한 뒤 프롬프트 캐시·모델 선택·하네스를 개선하는 단계적 비용 관리가 필요하다.
7. AI 침투가 낮고 전문 지식이 축적된 업종을 찾는다. 현장의 지식을 데이터와 하네스에 담아 수직형 에이전트를 만들면 범용 모델만 쓰는 제품과 차별화할 수 있다.
8. 추론 수요는 여러 공급자에게 기회를 준다. 에이전트 호출과 코딩 작업이 늘어나는 만큼 특정 모델 회사나 인프라 사업자 하나만 승리하는 시장이라고 단정하지 않는다.
9. 선점은 브랜드를 만들지만 실행이 지속성을 만든다. 빠른 기술 통합, 강한 인재, 제품 개선으로 초기 관심을 반복 사용과 신뢰로 바꿔야 한다.
10. AI의 장기 가치는 생산성 향상과 창의성 확장 모두에 있다. 기업 효율화뿐 아니라 새로운 창작 경험을 만드는 제품도 중요한 기회가 된다.

---

20줄 핵심 요약

LangChain은 모델·도구·데이터를 잇는 프레임워크와 에이전트 관측·평가 도구 LangSmith를 만든다.

에이전트는 비결정적인 모델 호출과 외부 도구가 연결되어 작은 오류가 연쇄적으로 커질 수 있다.

모델이 좋아지면 기존 기능이 사라지므로 창업자는 임시 해법과 계속 필요한 시스템을 구분해야 한다.

JSON 파싱 기반 도구 호출은 OpenAI의 네이티브 도구 호출이 나오자 빠르게 대체된 임시 해법이었다.

기업 데이터와 실제 API 응답을 연결하는 시스템은 모델이 발전해도 모델 바깥에 남는다.

모델·하네스·컨텍스트를 직접 통제하면 모델 이동성과 도메인별 제품 개선 능력을 확보할 수 있다.

특정 업무의 성공을 정의하고 검증기를 만드는 도메인 전문가가 수직형 에이전트의 핵심 자산이다.

초기에는 컨텍스트와 하네스를 개선하고 실제 사용 데이터가 생긴 뒤 모델 후속 학습을 검토하는 편이 효율적이다.

후속 학습 모델은 분류·추출·요약 같은 단순 작업에서 먼저 높은 투자 대비 효과를 낼 수 있다.

수직형 에이전트의 모델 라우팅은 업무 상태와 프롬프트 캐시를 아는 하네스 내부에 두는 편이 유리하다.

공개 벤치마크 점수보다 실제 업무의 내부 평가와 트레이스를 함께 살펴야 한다.

지속 학습은 에이전트 실행 기록에서 배운 내용을 컨텍스트·하네스·모델에 반영하고 다시 평가하는 외부 루프다.

메모리의 어려움은 저장소보다 사용 기록에서 앞으로 유용할 사실을 선별하는 데 있다.

범용 메모리 솔루션은 제품-시장 적합성을 찾지 못했고, 도메인별 학습 에이전트가 더 적합할 수 있다.

소비자 서비스에서는 사용자 앱의 수직형 에이전트와 여러 앱을 넘나드는 수평형 에이전트가 협력할 수 있다.

에이전트는 사람보다 훨씬 자주 서비스를 호출할 수 있으므로 인프라는 갑작스러운 요청 폭증을 견뎌야 한다.

LangChain은 엔지니어링 급여의 약 30%를 코딩 도구에 썼고, DOM 캡처 반복 작업은 일주일에 약 4만 달러를 소모했다.

에이전트 비용은 사용량 추적, 예산 제어, 캐시·라우팅을 포함한 하네스 개선의 세 단계로 관리할 수 있다.

오픈 모델은 핵심 에이전트 루프보다 가드레일·라우팅·요약처럼 호출량이 많은 단순 작업에서 먼저 확산된다.

추론 수요는 예상보다 훨씬 크며, AI 침투율이 낮고 도메인 지식이 풍부한 분야와 창의적 AI 제품에 기회가 있다.