Avoiding Death on the Yellow Brick Road
창업자와 예비 직원들에게 계속 받는 질문이 있다. “AI 애플리케이션 레이어에 아직 만들 게 남아 있나? 아니면 OpenAI와 Anthropic이 전부 죽여버릴까?”
이 질문 뒤에는 특정한 형태의 AI 불안증이 있다. 어떤 사람들은 영구적인 하위 계층이 되지 않으려면 대형 AI 랩 안에 들어가거나, 로보틱스, 하드테크 같은 “랩들이 건드릴 수 없는” 영역으로 가야 한다고 결론 내렸다. 모든 소프트웨어가 Codex나 Claude에 흡수되거나, 미래 모델이 내가 만든 것을 불필요하게 만들 거라면 도망쳐야 한다는 것이다.
나도 거의 누구 못지않은 AI 맥시멀리스트이고, 그들의 말이 반쯤은 맞다고 본다. 랩들은 실제로 애플리케이션 표면의 거대한 영역을 차지하러 오고 있다. 하지만 “애플리케이션 레이어”는 하나의 균질한 기회가 아니다. 올바른 질문은 당신이 노란 벽돌길 위에 있는지, 아니면 오즈의 다른 어딘가에 있는지다.
“노란 벽돌길”은 랩들이 막대한 자원을 투입하며 걸어가는 길을 뜻한다. 코드 생성, 글쓰기, 이미지 생성 같은 문제에서 랩들이 유리한 이유는 이 문제들이 원시 모델 성능이 좋아질수록 곧바로 개선되기 때문이다. 프리트레이닝과 포스트트레이닝에 들어가는 모든 달러가 제품 품질을 높인다.
반면 오즈의 나머지 지역에는 더 복잡하고, 종종 버티컬한 문제들이 있다. 표준 도구와 컴퓨터 사용 권한을 가진 수평적 도구 하나를 비즈니스 사용자에게 주는 것만으로 해결되지 않는 문제들이다. 이 영역의 가치는 기본 모델의 순수 성능보다, 특정 산업 안에서 결과물을 신뢰 가능하고, 규정 준수 가능하며, 실제 운영 가능한 형태로 만드는 주변 구조에서 더 많이 나온다.
OpenAI와 Anthropic이 범용 AI 동료만으로 모든 문제를 풀 수 없다는 사실을 시장에 사실상 말하고 있는 모습이 이미 보인다. 이들은 기업용으로 모델을 설정하고 커스터마이즈하는 회사를 통째로 만들기 위해 대규모 현장 배치형 조인트벤처를 발표했다. 다음 모델 릴리스 하나로 모든 게 해결된다고 생각한다면 그런 프로그램에 수십억 달러를 쏟아붓지 않는다.
그러니 AI 앱을 만들어 부자가 되고 싶다면 노란 벽돌길을 피하고, 오즈의 다른 곳에 지어라. 우리가 배운 것, 그리고 포트폴리오 창업자들이 배운 것은 다음과 같다.
노란 벽돌길 회사를 시작한다면 노란 벽돌길은 가장 obvious한 길이지만, 동시에 가장 위험하다. 성능 좋은 모델 하나를 가져오고, Google Drive, Slack, Salesforce, Notion, GitHub 같은 기성 커넥터를 붙인 뒤, 그 위에 에이전트 오케스트레이션 레이어를 얹는다. 마법처럼 보인다.
문제는 바로 이것을 랩들이 Cowork와 Codex로 하고 있다는 점이다. 그들은 모델을 소유한다. 그래서 더 좋은 마진, 통제력, 그리고 하위 사업자들에게 가격 결정력을 행사할 수 있다. 더 중요한 점은, 자신들의 제품이 어떤 문제를 잘 풀도록 설계되는지를 결정하는 아키텍처 선택권도 그들이 쥐고 있다는 것이다.
지금까지 그들은 “모델 + 툴 호출” 패턴을 의도적으로 밀고 있다. 그리고 이것이 바로 노란 벽돌길 위의 수평적이고 단계 수가 적은 작업에 필요한 방식이다. 설령 스타트업이 Codex나 Claude Code보다 더 잘할 수 있다고 해도, 랩들은 거대한 유통 채널과 AI 분야에서 가장 큰 브랜드 후광을 갖고 있다.
AI 앱 회사가 같은 커넥터, 하위 에이전트나 설정 없이, 유통도 없이 이 플레이북을 따라간다면, 거의 막다른 길을 걷고 있는 것이다.
오즈의 나머지 지역 스타트업에게 모든 것이 암울한 것은 아니다. 노란 벽돌길 밖에는 거대한 기회가 있다. 그곳에서는 스타트업이 고객을 소유하고 복잡한 문제를 해결할 명확한 경로가 있다.
이 회사들은 모델이 복잡한 도구, 자동화, 통합의 웹 안에 녹아 있는 에이전트 경험을 만든다. 쉽게 말해 소프트웨어를 만드는 것이다. 그래서 대부분 기본적으로 버티컬해진다.
이들은 Anthropic과 OpenAI의 수평 플랫폼이 닿기 어려운 다단계, 다자간 작업에 집중할 수 있다. 역할별, 산업별 작업을 위한 하위 에이전트가 있고, 여러 시스템에서 맥락을 수집한 뒤, 서로 다른 단계에서 승인해야 하는 여러 사람에게 라우팅한다. 여기에는 하나 이상의 레거시 시스템이 포함되는 경우가 많고, 모호성이 허용되지 않는 결정론적 결과가 필요하며, 때로는 중요한 비즈니스 성과와 직접 연결된다.
랩들도 이 문제들이 얼마나 가치 있는지 안다. 그래서 자신들만의 아웃소싱 설정 조직을 만들고 있고, 상위 시장을 겨냥한 강화학습 회사들이 생겨나는 것이다.
왜 오즈의 나머지 지역은 마법사가 소유하지 못하는가 여기에 대한 반론은 이렇다. 지금까지 모델과 랩의 개선에 베팅하지 않는 것은 좋지 않은 거래였다. 모델은 계속 좋아질 것이고, 결국 애플리케이션 레이어 회사들이 섬기는 시장까지 잠식할 것이다.
랩들은 분명 개선될 것이다. 하지만 오즈의 나머지 지역이 시간이 지나도 자신을 방어할 수 있는 방법이 몇 가지 있다고 본다.
데이터와 학습 플라이휠 현장에서 내재화되는 많은 것은 어떤 학습 데이터에도 없다. 문서화되지 않은 업계 관행, 비공식 표준, 실무자 머릿속에 있는 암묵지 같은 것들이다. 이것들은 공개 웹에 없다. 아무리 많은 학습 컴퓨팅도 이 지식이 실제로 존재하는 워크플로 안에 들어가는 것을 대체할 수 없다.
여기에는 두 개의 플라이휠이 겹쳐 있다. 하나는 고객 간 플라이휠이다. 같은 문제의 다양한 변형을 많이 볼수록 패턴이 축적된다. 다른 하나는 고객 내부 플라이휠이다. 특정 결정의 이유, 말로 표현되지 않은 예외, 실제 상호작용을 통해서만 드러나는 회사 고유의 경험칙이 축적된다.
고객 데이터를 고객 간에 사용할 수 없더라도, 애플리케이션 회사들은 고객 문제 유형 전반의 패턴 인식을 활용할 수 있고, 이를 바탕으로 미래 문제에 적합한 아키텍처를 설계할 수 있다. 에이전트를 수백 건의 법률 레드라인, 수천 건의 보험 언더라이팅 사이클, 수만 건의 SDR 캠페인에 투입해본 회사는, 새 에이전트를 처음 띄우는 신규 진입자가 복제할 수 없는 방식으로 문제의 형태를 내재화한다.
수평적 에이전트도 이론상 같은 학습 인프라를 만들 수 있다. 하지만 순수한 집중도의 문제를 제외하면, 그들이 그렇게 하지 못하는 이유는 UX다. 이런 지식을 포착하는 것은 전적으로 사용자에게 어떤 워크플로 표면을 제공하느냐에 달려 있다. 버티컬 플레이어는 정확히 그 워크플로가 드러내야 하는 것에 맞춰 표면을 설계할 수 있다. 수평 도구는 그럴 수 없다.
평가 세트, 라벨링된 출력, 엣지 케이스 분류 체계는 버티컬 특화 데이터 플라이휠로 축적될 수 있다. 이는 이후 신규 진입자가 비슷한 프로덕션 노출 없이 만들 수 없는 파인튜닝의 연료가 된다. 물론 이것이 가능한지는 데이터 권리, 축적된 프로덕션 노출량, 고객 계약 구조에 달려 있다. 하지만 패턴 인식 자체는 계속 축적된다.
모델 변동성과 복잡성 관리 랩들은 이미 내부적으로 라우팅을 하고 있다. 요청마다 다른 모델 클래스를 쓰고, 내부적으로 앙상블도 쓴다. 하지만 그들이 할 수 없는 것이 있다. 벤더 간 라우팅, 특정 하위 작업에 대해 경쟁사 모델을 평가하는 것, 또는 특정 좁은 영역에서 실제로 가장 좋은 오픈소스 파인튜닝 모델을 쓰는 것이다.
오즈의 나머지 지역에 있는 회사는 전체 모델 시장에서 각 하위 작업에 맞는 최적 모델을 고른다. 모회사 랩이 출시한 모델에만 갇히지 않는다. 또한 아무도 하고 싶어 하지 않는 일을 한다. 새 모델이 나올 때마다 평가를 다시 돌리고, 고객의 엣지 케이스에 맞게 프롬프트를 재조정하고, 프로덕션을 깨뜨리지 않으면서 배포한다.
랩들은 고객 대신 이 일을 하지 않는다. 그들은 다음 모델을 팔고, 마이그레이션하라고 말한다. 오즈의 나머지 지역 회사는 그 마이그레이션을 흡수한다. 고객이 얻는 것은 전체 시장에서 쓸 수 있는 최고의 지능과, 모든 업그레이드 과정에서의 연속성이다.
비용 최적화 모든 쿼리를 Opus 4.7에 태우는 것은 마이너스 매출총이익률로 가는 가장 빠른 길이다. 최고의 오즈 외곽 회사들은 모델 계층을 나눠 라우팅한다. 가장 어려운 작업에는 프론티어 모델, 대부분의 작업에는 중간급 모델, 자격이 생긴 영역에는 더 작은 커스텀 또는 파인튜닝 모델을 쓴다.
일부는 이제 그 위에서 자체 모델을 포스트트레이닝하고 있다. 고객이 중요하게 여기는 좁은 작업 영역에 맞게 최적화하고, 프론티어 API 호출 비용의 일부만으로 제공한다.
랩들은 바닥 가격을 정한다. “X달러에 사용할 수 있는 최소 수준의 지능”이다. 오즈의 나머지 지역 회사는 그 반대를 판다. “워크플로가 실제로 요구하는 특정 지능 수준을 가장 낮은 비용으로 제공”하는 것이다. 이는 각 하위 작업이 정확히 어느 수준의 지능을 필요로 하는지 알아야만 가능하다. 랩들은 구조적으로 모든 버티컬에 대해 그것을 알 수 없다. 이는 결과적으로 더 낮고 통제 가능한 결과 기반 가격으로 이어진다.
거버넌스 고객이 특정 버티컬에서 AI를 운영하는 방식의 컨트롤 플레인이 되는 것에는 상당한 가치가 있다. 권한, 감사, 에이전트가 해도 되는 일, 에이전트가 실제로 한 일이 모두 모이는 장소다.
이 컨트롤 플레인은 산업과 직무 유형마다 완전히 다르게 생긴 사용 사례별 가드레일로 구축된다. 이 회사들은 에이전트가 건드리는 도구, 워크플로, 데이터를 처음부터 끝까지 소유하기 때문에, 수평 도구가 어려워할 방식으로 결정론적 결과를 제공할 수 있다.
또한 최종 구매자 대신 규제 복잡성을 흡수하는 주체가 된다. 법률에서는 FRCP와 변호사 규칙, 의료에서는 HIPAA, 금융에서는 SEC와 FINRA, 보험에서는 주별 보험 규제 등이 있다. 수평 플레이어가 이것을 신뢰성 있게 하려면 동시에 백 개의 버티컬이 되어야 한다. CIO들은 제공받는 에이전트의 컴플라이언스를 계약상 책임지는 파트너를 원한다.
이 모든 것은 결국 같은 것으로 돌아온다. 집중이다. 그것은 보험, 법률, 회계 같은 버티컬일 수도 있고, 영업, 고객지원, 재무 같은 기능을 깊게 파는 것일 수도 있다.
어느 쪽이든, 이 일에는 하나의 고객군에 몰입한 팀이 필요하다. 그들의 워크플로, 엣지 케이스, 규제를 깊이 이해해야 한다. 랩들은 그렇게 설계되어 있지 않다. 그들은 모두를 위해, 모든 곳에 있어야 한다. 바로 그 방식으로 노란 벽돌길을 만든 것이다. 같은 트레이드오프가 그들을 오즈의 나머지 지역 밖에 머물게 한다. 동시에 모든 곳에 있을 수도 있고, 한 가지를 정말 잘할 수도 있다. 둘 다는 안 된다.
영업 예시: 11x 기술 CEO의 실전 팁 실제로는 어떻게 생각해야 할까? 11x CEO Prabhav Jain의 실전 팁이다.
결과에 집중하라 랩에 강한 회사를 만드는 전술적 경로는 고객이 정말 중요하게 여기는 특정 결과에서 시작하는 것이다. 우리에게는 회사들이 더 많은 파이프라인을 만들도록 돕는 것이었다.
그다음 질문은 전술적이 된다. 파이프라인을 실제로 만드는 활동 중 무엇을 처음부터 끝까지 소유할 것인가? 각 활동을 작업으로 쪼개라. 어떤 작업이 에이전트형이고, 어떤 작업은 아닌가? 어떤 작업은 정교한 도메인 인사이트가 필요하고, 어떤 작업은 그렇지 않은가?
랩들도 워크플로를 출시할 것이다. 하지만 워크플로가 많은 단계, 지저분한 입력, 해석하기 어려운 상태, 현실 세계의 제약을 포함한다면 더 좋은 모델 하나만으로는 도달할 수 없다. 결국 좋은 구식 소프트웨어 엔지니어링의 일이 된다. 이 표면에서는 집중한 애플리케이션 회사에 비해 랩이 우위에 있지 않다.
예를 들어 우리가 처리하는 작업에는 다음이 있다. 커스텀 시그널 기반 리드 발굴, 리드 강화, 깊은 계정 리서치, CRM에서 맥락 가져오기, 채널별 메시지 작성기, 리드 검증 에이전트, 이메일 전달성 시스템. 이들은 한 번에 던져서 끝낼 수 있는 작업이 아니며 깊은 엔지니어링이 필요하다.
오즈 비유의 핵심 통찰은 실제 워크플로의 대략 절반은 비에이전트적이고, 이 부분에는 랩의 장점이 없다는 것이다. 모델 레이어 아래의 결정론적 소프트웨어를 작성하는 데 랩들이 당신보다 더 나을 이유는 없다.
그리고 에이전트적인 절반 역시 원하는 결과에 맞춰 모델을 조정하고, 학습시키고, 제한해야 한다. 도메인 지식은 보통 일반 학습 데이터에 없다. 그런 기술은 버티컬이나 기능을 위해 바닥부터 만들어지고, 워크플로의 적절한 순간에 모델로 주입된다. 우리 에이전트가 전화로 인바운드 리드를 검증할 때, 특정 산업과 페르소나에서 좋은 영업 대화가 무엇인지 학습되어 있어야 한다. 이것이 애플리케이션 회사의 일이고, 시간이 지날수록 복리로 쌓인다.
더 중요한 것은, 비즈니스가 진화하기 때문에 이런 기술은 계속 낡는다는 점이다. 그래서 워크플로와 맥락을 진화시키는 능력이 경쟁우위가 된다. 예를 들어 우리가 대규모 이메일 아웃리치 제품을 시작했을 때, “AI가 쓴” 이메일이 막 등장하던 시기였다. 지금은 사람들이 AI가 쓴 이메일과 사람이 쓴 이메일을 구분하는 감각을 갖게 됐고, 결정적으로 이 감각은 몇 달마다 바뀐다.
우리 에이전트는 시장 역학에 맞춰 계속 적응해야 한다. 하지만 바로 여기에 해자가 만들어진다. 실제로 이런 변화에도 불구하고, 우리의 긍정 응답률은 최근 몇 달 동안 4배 올랐고, 고객을 위해 수억 달러 규모의 파이프라인을 만들었다.
복잡성이 높은 문제를 다뤄라 복잡한 문제에서 진짜 비즈니스 가치가 열린다. 그렇지 않으면 얇은 래퍼를 만들게 된다.
충분히 복잡한 비즈니스 문제를 쪼개보면 지저분함이 금방 드러난다. GTM 세계에서 사소해 보이는 예를 들어보자. 이미 고객인 회사의 담당자에게 연락하면 안 된다. 하지만 전혀 간단하지 않다.
CRM에 회사 도메인이 있을 수도 있다. 그런데 자회사가 수십 개인 회사는? CRM 기록에 모회사 도메인이 들어 있다면? Salesforce의 오래된 매칭 필드 때문에 현재 고객사의 CRO에게 콜드 피치가 나간다면?
현실 세계의 데이터는 지저분하다. 인간도 어려워한다. 모델이 마법처럼 이 기준을 넘겨주지는 않는다. 이 혼란 속에서 질서를 만들려면 CRM을 바라보는 범용 코파일럿이 아니라, 문제의 특정 형태에 맞게 설계된 목적 특화 에이전트가 필요하다. 실제로 우리가 가진 데이터에 따르면, 우리 데이터의 품질과 신선도가 고객 데이터보다 훨씬 높다는 것을 알게 되었고, 그래서 기본적으로 우리 데이터를 기준으로 삼는다.
가드레일은 사고 방지만을 위한 게 아니다. 그것이 고객이 돈을 내는 이유다 가드레일은 심각하게 과소평가되어 있다. 같은 제품 안에서도 사용 사례마다 다른 가드레일이 필요하다.
우리에게 규제 금융 서비스 잠재고객은 미드마켓 SaaS 고객과 다른 보장을 요구한다. 그 보장은 에이전트가 어떻게 글을 쓸 수 있는지, 누구에게 연락할 수 있는지, 어떤 데이터에 접근할 수 있는지, 통화에서 무엇을 말할 수 있는지, 모든 결정이 어떻게 기록되는지까지 내려간다.
일률적인 시스템은 이런 변동성을 견디지 못한다. 가드레일은 사용 사례별로 만들고, 고객별로 설정하며, 지속적으로 감사해야 한다. 이 일은 전적으로 애플리케이션 회사의 몫이다.
그래서 우리는 고객 요구사항에 맞춰 조정하는 FDE와 기술 배포 전략가를 둔다. 예를 들어 우리는 F1000 기관과 함께 대규모 SMB 고객 기반을 대상으로 동의 기반 음성 아웃바운드를 진행했다. 초기 몇 번의 반복에서는 통화 연결률이 낮았다. 우리는 이 특정 청중이 통화 첫 10초 안에 어떻게 반응하도록 만들지 빠르게 반복하고 학습해야 했다. SMB 사업자는 대형 B2B 구매자나 소비자와 매우 다르게 행동한다.
이제 우리는 그 고객을 위해 하루에 만들어내는 영업 기회가 해당 세그먼트 전체 영업팀이 한 달 동안 만드는 것보다 많다.
보험 예시: FurtherAI CEO의 실전 팁 영업은 하나의 예다. 보험은 또 다른 예이고, 다른 각도에서 같은 요점을 보여준다. FurtherAI CEO Aman Gour는 길 밖에서 회사를 짓는 것을 이렇게 본다.
우리가 실제 보험 운영 안에 AI를 배포하기 시작했을 때, 특정한 가정을 계속 들었다. 모델이 지능이고, 워크플로는 그 주변의 발판일 뿐이라는 생각이다.
보험사들과 더 많이 일할수록, 우리는 이것이 반대라고 확신하게 됐다.
보험에서는 많은 지능이 워크플로 자체 안에 있다. 두 보험사가 겉보기에는 같은 경로로 제출 건을 처리할 수 있다. 제출, 검토, 견적, 바인드. 하지만 경로는 쉬운 부분이다.
두 보험사를 구분하는 것은 그 안의 모든 것이다. 어떤 위험이 에스컬레이션되는지, 어떤 손실 신호가 중요한지, 두 개의 인수 기준이 충돌할 때 어떤 기준이 이기는지, 언제 사람이 승인해야 하는지, 어떤 외부 데이터를 가져오는지, 최종 결정이 어떻게 문서화되는지다.
그 논리는 하나의 깔끔한 규칙 엔진 안에 있지 않다. SOP, 관리자 리뷰, 언더라이팅 철학, 보험사별 인수 성향, 수년간의 운영 경험에 흩어져 있다. 그중 많은 것은 모델이 그냥 읽을 수 있는 형태로 쓰여 있지도 않다.
그래서 우리는 매번 처음부터 추론하는 순수 에이전트를 믿지 않는다. 현실이 지저분해지는 순간 깨지는 경직된 워크플로도 믿지 않는다. 대신 에이전트형 워크플로를 만들고 있다.
워크플로는 반복 가능성, 감사 가능성, 비용 통제를 제공한다. 에이전트는 변동성을 처리하고, 이상적인 경로가 깨졌을 때 복구한다. 인간은 책임이 중요한 판단 호출에 계속 참여한다.
첫날에는 이것이 수작업을 자동화한다. 하지만 시간이 지나면 모든 에스컬레이션이 신호가 되고, 모든 예외가 피드백이 되며, 모든 인간의 수정이 런북의 빈틈을 보여준다. 시간이 지나면 워크플로는 스크립트가 아니라 보험사의 운영 기억이 된다.
이 부분이 랩들이 닿기 어려운 곳이다. 그들은 더 좋은 모델과 더 좋은 범용 에이전트를 계속 출시할 것이고, 그래야 한다. 하지만 그들은 보험사의 프로덕션 워크플로 안에 충분히 오래 머물러서 왜 어떤 계정이 에스컬레이션됐는지, 왜 어떤 위험이 거절됐는지, 왜 어떤 언더라이터가 인수 가이드를 override했고 그것이 옳았는지를 배우지 않는다.
그 이해는 워크플로를 프로덕션에서 수천, 수만 번 실행해야만 생긴다. 첫날 출시한 워크플로가 해자가 아니다. 프로덕션 사용이 시간이 지나며 만들어내는 루프가 해자다.
우리에게 길 밖에서 짓는다는 것은 그런 뜻이다.
내가 오즈의 나머지 지역에 있는지 어떻게 판단할까? 도구와 단계 테스트 그 일이 몇 단계로 이루어지는가? 그리고 그 일을 지원하려면 얼마나 복잡한 도구를 만들어야 하는가?
Google Drive를 대상으로 한 수평적 AI 검색을 생각해보자. 하나의 도구에 대해 한 단계 작업이고, 결과도 관대하다. 사용자는 요약을 읽고 틀리면 다시 묻는다.
반면 로펌의 3년치 선례를 기준으로 한 다단계 법률 레드라인을 생각해보자. 많은 도구에 걸친 수십 단계가 있고, 결과물은 파트너 리뷰를 통과해야 하며, 법정에서 주장되어야 할 수도 있다.
둘 다 “에이전트가 일을 한다”처럼 보인다. 하지만 집중한 팀이 수년간 쌓아야 하는 깊은 소프트웨어가 필요한 것은 하나뿐이다.
시스템 테스트 당신은 고객이 일을 그 안에서 실행하는 시스템을 만들고 있는가, 아니면 고객이 이미 가진 시스템 위에 얹히는 도구를 만들고 있는가?
시스템은 워크플로를 처음부터 끝까지 소유한다. 데이터 캡처, 거버넌스, 어떤 일이 완료됐는지에 대한 기록까지 포함한다. 고객이 실제 일이 어떻게 이루어지는지 설명할 때 가리키는 것이 시스템이다.
반면 도구는 고객이 이미 운영하는 워크플로에 지능을 더할 뿐이다. 도구도 실제 매출을 만들 수 있다. 하지만 랩들이 가져갈 수 있다. 고객이 당신을 오케스트레이션 레이어로 의존하지 않기 때문이다.
높은 ACV는 보통 시스템의 신호다. 시스템은 실제 인력을 대체하고 그에 맞는 돈을 받기 때문이다. 하지만 보장은 아니다. 스스로에게 물어봐라. 어떤 랩이 당신과 직접 경쟁하는 듯한 것을 출시해도 고객이 여전히 당신의 도구를 필요로 할까? 그렇다면 당신은 시스템을 만들고 있다. 아니라면 당신은 도구다. ACV가 높아도 마찬가지다.
헤지펀드 / 손익 테스트 랩의 성능은 벤치마크로 판단된다. 반면 오즈의 나머지 지역의 성능은 고객의 손익으로 판단된다.
고객은 당신의 모델이 SWE-Bench나 MMLU에서 점수가 좋았는지 신경 쓰지 않는다. 그들은 당신의 에이전트가 거래를 성사시켰는지, 계약서를 정확히 레드라인했는지, 올바른 보험을 바인드했는지를 본다.
고객이 범용 능력 점수가 아니라 워크플로별 결과에 집착한다면, 당신은 오즈의 나머지 지역에 있다. 고객이 범용 능력에 돈을 내고 있다면, 당신은 Claude나 Codex 좌석으로도 얻을 수 있는 것을 팔고 있는 것이다.
최고의 에이전트 비즈니스들은 헤지펀드처럼 실행해야 한다. 벤치마크 점수가 아니라 고객 손익에서 측정되는 알파로 이겨야 한다.
둘 다 이긴다, 그리고 실제로 이길 것이다 우리는 노란 벽돌길 위와 밖에서 모두 거대한 승자를 보게 될 것이다. 모델들은 계속 이길 것이다. 그들은 모델을 소유하고, 자신들이 설계한 수평 도구의 유통을 소유하기 때문이다.
오즈의 나머지 지역은 “일의 시스템”을 소유한다면 이길 수 있다. 회사의 실제 일이 실행되고, 그로부터 나오는 데이터가 포착되는 표면이다.
이 회사들은 데이터 캡처, 행동의 워크플로 시스템, 거버넌스를 소유한다. 더 복잡한 워크플로가 특정 버티컬에서 성숙할수록, 그것들은 고객이 의존하는 하나의 핵심 경험으로 복리화된다.
기존 기업과 신규 진입자가 새로운 모델 세대를 출시할수록, 이 회사는 그것들을 고객에게 통합하고 전달하는 레이어가 된다. 아래에 있는 모델은 대체 가능하다. 하지만 일의 시스템은 대체 가능하지 않다.
차세대 엔터프라이즈 소프트웨어는 길 밖에서 만들어질 것이다.