노란 벽돌길에서 죽음을 피하는 법 - 앱 레이어는 아직 죽지 않았다

• 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는 아님
• 차세대 엔터프라이즈 소프트웨어는 "길 바깥" 에서 만들어질 것