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

AI 에이전트 워크플로 — 버티컬 영역에서 시스템 오브 워크를 구축하는 것이 핵심이다

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

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

노란 벽돌길 — 랩들이 걷는 길

고성능 모델에 G Drive, Slack, Salesforce, Notion, GitHub 같은 off-the-shelf 커넥터를 꽂고 그 위에 에이전트 오케스트레이션 레이어를 얹는 패턴이 바로 이것이다. 이 패턴이 위험한 이유는 랩들이 이미 동일한 일을 하고 있기 때문이다.

OpenAI는 Cowork를, Anthropic은 Claude Code를 내놓으며 모델지상에 똑같은 플레이북을 구현하고 있다. 스타트업이 이 플레이북을 그대로 따르는 순간, 막대한 유통망과 AI 분야 최대의 브랜드 후광을 가진 랩과 직접 경쟁하게 된다. 동일한 커넥터 조합, 서브 에이전트 부재, 유통 부재 상태에서 이 경로를 따르는 AI 앱 회사는 결국 "아무 데도 가지 못하는 길"을 걷게 된다.

오즈의 나머지 — 스타트업의 기회

오즈의 나머지 영역은 모델이 도구·자동화·통합의 복잡한 망을 통해 엮인 에이전트 경험을 구축하는 영역이다. 대부분 자연스럽게 버티컬로 귀결되며, 수평 플랫폼으로는 닿지 못하는 다단계·다중 참여자 작업에 집중한다.

데이터와 학습 플라이휠

학습셋에 없는 암묵적 산업 규범, 문서화되지 않은 표준, 현장 종사자 머릿속 부족 지식(tribal knowledge)은 공개 웹에 존재하지 않는다. 두 개의 플라이휠이 겹쳐서 작동한다.

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

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

100건의 법률 redline, 1,000건의 보험 underwriting, 10,000건의 SDR 캠페인을 돌린 회사는 신규 진입자가 갓 띄운 에이전트로 복제 불가능한 문제의 형태를 내재화한다. 수평 에이전트가 동일 학습 인프라를 만들 수 없는 핵심 이유는 UX다. 버티컬 플레이어만이 워크플로 표면을 정확히 설계할 수 있으며, Eval 셋과 라벨링된 출력, 엣지 케이스 분류 체계가 버티컬 특화 데이터 플라이휠로 누적되어 파인튜닝 연료가 된다.

모델 다양성과 복잡성 관리

랩들은 내부적으로 요청별 모델 라우팅과 앙상블을 이미 수행하지만, 벤더 간 라우팅과 경쟁사 모델 평가, 오픈소스 파인튜닝 모델을 좁은 영역에 투입하는 것은 불가능하다. Rest of Oz 회사는 모회사 랩이 출시한 것뿐 아니라 전체 모델 시장에서 서브태스크별 최적 모델을 선택한다. 업그레이드마다 eval 재실행, 고객 엣지 케이스에 맞춘 프롬프트 재보정, 프로덕션을 깨지 않는 롤아웃 같은 "아무도 하기 싫은 일"을 흡수한다.

비용 최적화

모든 쿼리를 프런티어 모델로 돌리는 것은 음의 매출총이익으로 가는 최단 경로다. 최고의 Rest of Oz 회사는 모델을 티어별 라우팅한다. 가장 어려운 작업에는 프런티어 모델을, 대부분 작업에는 mid-tier 자격을 갖춘 모델을, 부분에는 소형 커스텀·파인튜닝 모델을 사용한다. 일부 기업은 그 위에서 자체 post-training을 수행하여 고객이 신경 쓰는 좁은 슬라이스에 최적화한다.

거버넌스

해당 버티컬에서 고객이 AI를 운영하는 방식의 컨트롤 플레인이 되는 것에 상당한 가치가 있다. 권한, 감사, 에이전트가 무엇을 할 수 있는지, 실제로 무엇을 했는지가 모두 수렴한다. 도구·워크플로·데이터를 엔드투엔드로 소유하므로 수평 도구가 어려운 결정론적 결과 제공이 가능하다.

금융에서는 FRCP와 변호사 윤리 규정, 의료에서는 HIPAA, 금융에서는 SEC와 FINRA, 보험에서는 주 단위 보험 규제가 적용된다. CIO는 자신이 제공하는 에이전트의 컴플라이언스를 계약상 책임지는 파트너를 원한다.

실전 사례: 11x와 FurtherAI

Sales 사례 — 11x CEO Prabhav Jain

랩 내성을 갖춘 회사를 만드는 전술적 경로는 고객이 진정 신경 쓰는 특정 성과에서 출발하는 것이다. 각 활동을 태스크로 분해하여 에이전틱한 것과 아닌 것, 정교한 도메인 통찰이 필요한 것과 아닌 것을 구분한다. 다단계·지저분한 입력·해석 어려운 상태·실세계 제약이 있는 워크플로에서는 더 나은 모델만으로는 부족하며, 재래식 소프트웨어 엔지니어링이 필요하며 이 표면에서는 랩이 우위가 없다.

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

• 커스텀 시그널 기반 리드 prospecting

• deep account research

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

최근 몇 달간 positive reply rate가 4배 상승했으며, 고객을 위해 수억 달러 규모 파이프라인을 생성하고 있다.

Insurance 사례 — FurtherAI CEO Aman Gour

실제 보험 운영에 AI를 배포하며 반복적으로 접한 가정인 "모델이 지능이고 워크플로는 스캐폴딩에 불과하다"는 것은 캐리어들과 일할수록 거꾸로임을 확신하게 된다. 보험에서는 지능의 상당 부분이 워크플로 자체에 존재한다.

두 캐리어가 동일한 경로(submission → review → quote → bind)를 따르더라도, 차이는 그 안의 모든 것이다. 어떤 리스크가 escalation 되는가, 어떤 손실 시그널이 중요한가, appetite 규칙이 충돌할 때 어느 쪽이 이기는가, 인간 승인 시점, 외부 데이터 호출, 최종 의사결정 문서화 방식. 이 로직은 깔끔한 룰 엔진 한 곳이 아니라 SOP, 매니저 리뷰, 인수 철학, 캐리어 고유 appetite, 수년의 운영 경험에 분산되어 있고, 다수는 모델이 읽을 수 있는 형태로 문서화되지 않았다.

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

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

1. 도구·단계 테스트

작업이 몇 단계를 거치며 지원 도구가 얼마나 복잡한가. 수평 AI 검색(Google Drive 횡단)은 1단계, 1도구, 관대한 결과로 틀리면 다시 묻기만 하면 된다. 반면 법률 redline은 수십 단계, 다수 도구, 파트너 검토를 통과해야 하고 법정에서 다툴 수도 있는 출력이 필요하다. 둘 다 "에이전트가 일하는 모습"이지만, 한쪽만 포커스 팀이 수년간 만드는 깊은 소프트웨어를 요구한다.

2. 시스템 테스트

고객이 자신의 일을 통과시키는 시스템을 만들고 있는가, 아니면 이미 있는 시스템 위의 도구인가. 시스템은 데이터 캡처, 거버넌스, 수행 기록을 엔드투엔드로 소유하며 고객이 "실제 일이 일어나는 곳"으로 가리키는 대상이다. 도구는 고객이 이미 운영하는 워크플로에 지능을 추가할 뿐이다.

3. 헤지펀드/P&L 테스트

랩 성과는 벤치마크로, Rest of Oz 성과는 고객의 P&L로 평가된다. 고객은 SWE-Bench·MMLU 점수에 관심 없다. 에이전트가 딜을 클로즈했는지, 계약을 올바로 redline 했는지, 적절한 정책을 bind 했는지를 본다. 워크플로 특화 결과에 집착하는 고객에게는 Rest of Oz가, 일반 능력에 비용을 지불하는 고객에게는 Claude나 Codex seat으로 충분하다.

핵심 결론

노란 벽돌길 위에서도 거대한 승자가 나올 것이다. 랩들은 모델을 소유하고 자신들이 설계한 수평 도구의 유통도 소유한다. 그러나 Rest of Oz의 승리 조건은 system of work의 소유다. 회사의 일이 실제 실행되고 데이터가 캡처되는 표면을 소유해야 한다.

차세대 엔터프라이즈 소프트웨어는 "길 바깥"에서 만들어질 것이다. 모델은 교체 가능하지만 시스템 오브 워크(system of work)는 그렇지 않다. 데이터 캡처, 워크플로의 액션 시스템, 거버넌스를 소유하라. 버티컬에서 복잡한 워크플로가 성숙할수록 고객이 의존하는 하나의 핵심 경험으로 응축된다. 신구 모델 세대가 출시될 때 기업은 이를 통합·전달하는 레이어가 되고, 모델은 그 아래에서 대체 가능하지만 system of work는 아니다.

---

📚 출처

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

---

📚 출처

• https://a16z.com/avoiding-death-by-yellow-brick-road/