AI 앱 레이어가 OpenAI·Anthropic 같은 대형 랩에 잠식될 것이라는 우려가 창업자들 사이에 확산되고 있으나, 앱 레이어는 단일한 기회가 아니라 "노란 벽돌길(Yellow Brick Road)" 과 "오즈의 나머지 영역(Rest of Oz)" 으로 나뉘는 구조

노란 벽돌길은 코드 생성·글쓰기·이미지 생성처럼 모델 자체 성능 향상만으로 품질이 개선되는 수평적 영역으로, 랩들이 막대한 자원을 투입하는 경로

오즈의 나머지 영역은 버티컬·다단계·다중 승인 워크플로처럼 모델 위의 스캐폴딩(scaffolding) 이 신뢰성과 컴플라이언스를 결정하는 영역으로, 스타트업이 고객을 소유할 수 있는 기회 존재

OpenAI·Anthropic이 엔터프라이즈 맞춤화를 위한 대규모 forward-deployed 합작법인을 발표한 사실 자체가 일반화된 AI 코워커만으로 모든 문제를 해결할 수 없음을 시사

차세대 엔터프라이즈 소프트웨어는 "길 바깥(off the road)" 에서 만들어질 것이며, 모델은 교체 가능하지만 시스템 오브 워크(system of work) 는 그렇지 않다는 점이 핵심 방어선

핵심 질문과 전제

창업자·예비 입사자로부터 반복적으로 받는 질문은 "OpenAI와 Anthropic이 모든 것을 죽일 것인가, AI 앱 레이어에 만들 것이 남아있는가"

일부는 영구적 하층 계급을 피할 수 있는 곳은 대형 랩 내부 혹은 로보틱스·하드테크 같은 프런티어 뿐이라고 결론

글쓴이는 AI 맥시멀리스트 입장에서 그들이 "절반은 맞다"고 평가, 랩들이 앱 표면의 상당 부분을 흡수하는 것은 사실

다만 앱 레이어가 단일 기회가 아니라는 점이 핵심 — 노란 벽돌길 위인지, 오즈의 다른 곳인지가 올바른 프레이밍

The Yellow Brick Road — 랩들이 걷는 길

고성능 모델에 G Drive, Slack, Salesforce, Notion, GitHub 같은 off-the-shelf 커넥터를 꽂고 그 위에 에이전트 오케스트레이션 레이어를 얹는 패턴

이 패턴이 위험한 이유는 랩들이 Cowork와 Codex로 이미 동일한 일을 하고 있기 때문

모델을 소유 → 더 나은 마진, 통제력, 다운스트림에 대한 가격 결정력

제품이 잘 풀도록 정의된 아키텍처 선택권 보유 — 지금까지 "model + tool calls" 패턴을 의도적으로 채택했고, 이는 길 위의 수평적 저단계 작업에 정확히 맞음

스타트업이 Codex나 Claude Code를 성능으로 앞선다 해도 랩들은 막대한 유통망과 AI 분야 최대의 브랜드 후광 보유

동일 커넥터 조합, 서브 에이전트·구성 부재, 유통 부재 상태로 이 플레이북을 도는 AI 앱 회사는 "아무 데도 가지 못하는 길"

The Rest of Oz — 스타트업의 기회

모델이 도구·자동화·통합의 복잡한 망을 통해 엮인 에이전트 경험을 구축하는 영역, 대부분 자연스럽게 버티컬로 귀결

수평 플랫폼으로는 닿지 못하는 다단계·다중 참여자 작업에 집중 가능

시스템 전반에서 컨텍스트 수집 후, 단계별 승인이 필요한 다수의 사람에게 라우팅

하나 이상의 레거시 시스템 연계, 결정론적 결과가 필요하며 모호함이 허용되지 않음

가치 있는 비즈니스 성과와 연결된 경우 多

랩들도 이 문제의 가치를 인지하고 있어 외주 구성 조직(outsourced configuration shops) 을 직접 운영하고, 강화학습 비즈니스의 업마켓 클래스가 존재하는 이유

오즈의 나머지가 마법사에게 잠식되지 않을 이유

Data and learning flywheels (데이터·학습 플라이휠)

학습셋에 없는 암묵적 산업 규범, 문서화되지 않은 표준, 현장 종사자 머릿속 부족 지식(tribal knowledge) 은 공개 웹에 존재하지 않음

두 개의 플라이휠이 겹쳐서 작동

across-customer: 동일 문제의 변형을 여러 고객에게서 보며 누적되는 패턴

within-customer: 특정 결정의 이유, 암묵적 예외, 그 회사 고유의 경험칙

100건의 법률 redline, 1,000건의 보험 underwriting, 10,000건의 SDR 캠페인을 돌린 회사는 신규 진입자가 갓 띄운 에이전트로 복제 불가능한 문제의 형태를 내재화

수평 에이전트가 동일 학습 인프라를 만들 수 없는 핵심 이유는 UX — 버티컬 플레이어만이 워크플로 표면을 정확히 설계 가능

Eval 셋, 라벨링된 출력, 엣지 케이스 분류 체계가 버티컬 특화 데이터 플라이휠로 누적되어 파인튜닝 연료가 됨

Managing model variability and complexity (모델 다양성·복잡성 관리)

랩들은 내부적으로 요청별 모델 라우팅과 앙상블을 이미 수행, 그러나 벤더 간 라우팅, 경쟁사 모델 평가, 오픈소스 파인튜닝 모델을 좁은 영역에 투입하는 것은 불가능

Rest of Oz 회사는 모회사 랩이 출시한 것뿐 아니라 전체 모델 시장에서 서브태스크별 최적 모델 선택

업그레이드마다 eval 재실행, 고객 엣지 케이스에 맞춘 프롬프트 재보정, 프로덕션을 깨지 않는 롤아웃 같은 "아무도 하기 싫은 일"을 흡수

랩은 다음 모델을 팔고 "마이그레이션하라"고 통보할 뿐, Rest of Oz 회사가 마이그레이션을 흡수하여 고객에게 전체 시장에서 최고 지능과 업그레이드 연속성을 제공

Cost optimization (비용 최적화)

모든 쿼리를 Opus 4.7로 돌리는 것은 음의 매출총이익으로 가는 최단 경로

최고의 Rest of Oz 회사는 모델을 티어별 라우팅

가장 어려운 작업에는 프런티어 모델

대부분 작업에는 mid-tier

자격을 갖춘 부분에는 소형 커스텀·파인튜닝 모델

일부 기업은 그 위에서 자체 post-training을 수행, 고객이 신경 쓰는 좁은 슬라이스에 최적화하여 프런티어 API 대비 일부 비용으로 서빙

랩이 "X달러에 최소 지능"이라는 바닥 가격을 설정한다면, Rest of Oz 회사는 그 역, 즉 워크플로가 실제 요구하는 지능 수준에 대해 최저 달러 비용을 판매

Governance (거버넌스)

해당 버티컬에서 고객이 AI를 운영하는 방식의 컨트롤 플레인이 되는 것에 상당한 가치 존재 — 권한, 감사, 에이전트가 무엇을 할 수 있는지, 실제로 무엇을 했는지가 모두 수렴

컨트롤 플레인은 산업·직무별로 완전히 다른 유스케이스별 가드레일로 구성

도구·워크플로·데이터를 엔드투엔드로 소유하므로 수평 도구가 어려운 결정론적 결과 제공 가능

최종 구매자 대신 규제 복잡성을 흡수하는 주체

법률: FRCP와 변호사 윤리 규정

의료: HIPAA

금융: SEC와 FINRA

보험: 주(state) 단위 보험 규제 등

CIO는 자신이 제공하는 에이전트의 컴플라이언스를 계약상 책임지는 파트너를 원함

공통 결론: 포커스

버티컬(보험·법률·회계)이든 깊게 수행되는 펑션(영업·고객지원·재무)이든, 단일 고객 집합의 워크플로·엣지 케이스·규제에 헌신하는 팀 필요

랩은 모두를 위해 어디에나 존재해야 하는 구조이므로 이 일을 수행할 수 없음 — "어디에나 있거나" 혹은 "한 가지를 잘하거나" 둘 중 하나

Sales 사례 — 11x CEO Prabhav Jain의 실전 팁

Focus on outcomes (성과에 집중)

랩 내성을 갖춘 회사를 만드는 전술적 경로는 고객이 진정 신경 쓰는 특정 성과에서 출발하는 것 — 11x의 경우 파이프라인 생성

각 활동을 태스크로 분해 → 에이전틱한 것과 아닌 것, 정교한 도메인 통찰이 필요한 것과 아닌 것 구분

다단계·지저분한 입력·해석 어려운 상태·실세계 제약이 있는 워크플로에서는 더 나은 모델만으로는 부족, 재래식 소프트웨어 엔지니어링이 필요하며 이 표면에서는 랩이 우위 없음

11x가 처리하는 태스크 예시

커스텀 시그널 기반 리드 prospecting, lead enrichment, deep account research

CRM 컨텍스트 페처, 채널별 메시지 작성기, 리드 자격 검증 에이전트, 이메일 전달성 시스템

일반 학습 데이터에 없는 도메인 지식을 워크플로의 적절한 시점에 모델에 주입하는 것이 앱 회사의 일이며 누적됨

스킬은 비즈니스 진화로 끊임없이 낡으므로 워크플로·컨텍스트 진화 능력 자체가 경쟁우위

예: AI 작성 이메일이 등장하던 시점부터 사용자 감각이 수개월마다 변화, 에이전트는 시장 동학에 맞춰 계속 적응

최근 몇 달간 positive reply rate 4배 상승, 고객을 위해 수억 달러 규모 파이프라인 생성

Work on problems where complexity is high (복잡성 높은 문제)

복잡한 문제에서 진짜 비즈니스 가치 해제, 그렇지 않으면 얇은 래퍼(thin wrapper) 가 됨

GTM 예시: "이미 고객인 회사의 컨택트에게 연락하면 안 된다"는 단순 규칙도 실제로는 매우 복잡

CRM에 도메인 매핑이 있을 수 있고, 수십 개 자회사를 가진 기업, 모회사 도메인만 기록된 경우, Salesforce의 stale 매칭 필드로 인해 현 고객 CRO에게 콜드 피치가 가는 사고

실세계 데이터는 지저분하며 인간도 모델도 마법처럼 해결 못함 — 문제의 구체적 형태에 맞춰 엔지니어링된 목적 특화 에이전트 필요

11x 데이터 기준 자사 데이터의 품질·신선도가 고객 측보다 높아 자사 데이터에 앵커링하는 것이 기본

Guardrails — 나쁜 일 방지가 아닌 고객이 돈 내는 본질

가드레일은 심각하게 과소평가됨, 같은 제품 안에서도 유스케이스마다 별도 필요

규제 받는 금융 서비스 잠재 고객과 mid-market SaaS 고객의 요구 보증이 다르고, 이는 에이전트의 작성 방식·연락 대상·접근 데이터·통화 발언·의사결정 로깅 방식까지 흘러내림

일률(one-size-fits-all) 시스템은 붕괴, 유스케이스별 설계·고객별 구성·지속적 감사 필요

이를 위해 고객 요구에 맞춰 튜닝하는 FDE(Forward Deployed Engineer) 와 기술 배포 전략가 운영

F1000 기관 사례

대규모 SMB 고객 대상 동의 기반 아웃바운드 음성을 수행

초기 반복에서 낮은 픽업률 → 통화 첫 10초 안에 SMB 사업주를 참여시키는 방법을 빠르게 학습

SMB 사업주는 대형 B2B 바이어나 컨슈머와 다르게 행동, 현재 해당 세그먼트에 대해 고객사 영업팀의 한 달치보다 하루에 더 많은 영업 기회 창출

Insurance 사례 — FurtherAI CEO Aman Gour

실제 보험 운영에 AI를 배포하며 반복적으로 접한 가정 — "모델이 지능이고 워크플로는 스캐폴딩에 불과하다" — 는 캐리어들과 일할수록 거꾸로임을 확신

보험에서는 지능의 상당 부분이 워크플로 자체에 존재

두 캐리어가 동일한 경로(submission → review → quote → bind)를 따르더라도, 차이는 그 안의 모든 것

어떤 리스크가 escalation 되는가

어떤 손실 시그널이 중요한가

appetite 규칙이 충돌할 때 어느 쪽이 이기는가

인간 승인 시점, 외부 데이터 호출, 최종 의사결정 문서화 방식

이 로직은 깔끔한 룰 엔진 한 곳이 아니라 SOP, 매니저 리뷰, 인수 철학, 캐리어 고유 appetite, 수년의 운영 경험에 분산되어 있고, 다수는 모델이 읽을 수 있는 형태로 문서화되지 않음

결론은 매번 처음부터 추론하는 순수 에이전트도, 현실이 지저분해지면 깨지는 경직된 워크플로도 아닌 agentic workflows

워크플로 → 반복성, 감사 가능성, 비용 통제

에이전트 → 변동성 처리, happy path가 깨질 때 회복

휴먼인더루프 → 책임이 중요한 판단 콜

Day 1에는 수작업 자동화, 시간이 흐르며 모든 escalation이 시그널, 예외가 피드백, 인간 수정이 런북의 누락 지점을 드러내는 신호가 되어 워크플로가 캐리어의 운영 기억(operating memory) 으로 진화

랩은 더 나은 모델과 더 나은 일반 에이전트를 계속 출시하겠지만, 어떤 계좌가 escalation 되었는지·어떤 리스크가 거절되었는지·언더라이터가 appetite 가이드를 뒤집고 옳았던 이유는 캐리어의 프로덕션 안에 충분히 오래 머물지 않으면 학습 불가

"Day 1에 출시한 워크플로가 해자가 아니라, 프로덕션 사용이 시간에 걸쳐 만드는 루프가 해자"

오즈의 나머지에 속하는지 판별하는 3가지 테스트

The tools-and-steps test (도구·단계 테스트)

작업이 몇 단계를 거치며 지원 도구가 얼마나 복잡한가

비교

수평 AI 검색 (Google Drive 횡단): 1단계, 1도구, 관대한 결과 — 틀리면 다시 묻기

법률 redline (3년치 펌 선례 대조): 수십 단계, 다수 도구, 파트너 검토를 통과해야 하고 법정에서 다툴 수도 있는 출력

둘 다 "에이전트가 일하는 모습"이지만, 한쪽만 포커스 팀이 수년간 만드는 깊은 소프트웨어 요구

The system test (시스템 테스트)

고객이 자신의 일을 통과시키는 시스템을 만들고 있는가, 아니면 이미 있는 시스템 위의 도구인가

시스템은 데이터 캡처, 거버넌스, 수행 기록을 엔드투엔드로 소유하며 고객이 "실제 일이 일어나는 곳"으로 가리키는 대상

도구는 고객이 이미 운영하는 워크플로에 지능을 추가할 뿐, 매출은 발생하지만 랩이 가져갈 수 있는 영역

High ACV가 시스템의 신호인 경우가 많으나 보증은 아님 — 랩이 직접 경쟁 제품을 내놓아도 고객이 여전히 당신의 도구가 필요한가가 판별 기준

The hedge fund / P&L test (헤지펀드/P&L 테스트)

랩 성과는 벤치마크로, Rest of Oz 성과는 고객의 P&L로 평가

고객은 SWE-Bench·MMLU 점수에 관심 없음 — 에이전트가 딜을 클로즈했는지, 계약을 올바로 redline 했는지, 적절한 정책을 bind 했는지를 본다

워크플로 특화 결과에 집착하는 고객 → Rest of Oz, 일반 능력에 비용을 지불하는 고객 → Claude나 Codex seat으로 충분

최고의 에이전트 비즈니스는 헤지펀드처럼 고객 P&L로 측정되는 알파로 승부해야 함

양쪽 모두 승리할 수 있다

노란 벽돌길 위에서도 거대한 승자가 나올 것 — 랩들은 모델을 소유하고 자신들이 설계한 수평 도구의 유통도 소유

Rest of Oz의 승리 조건은 system of work의 소유 — 회사의 일이 실제 실행되고 데이터가 캡처되는 표면

데이터 캡처, 워크플로의 액션 시스템, 거버넌스를 소유

버티컬에서 복잡한 워크플로가 성숙할수록 고객이 의존하는 하나의 핵심 경험으로 응축

신구 모델 세대가 출시될 때 기업은 이를 통합·전달하는 레이어가 됨

모델은 그 아래에서 대체 가능(fungible), 하지만 system of work는 아님