Minbook
EN
Headless 시대, 가치는 어디로 협공당해 모이는가 — 빌더 레이어의 수직 압축

Headless 시대, 가치는 어디로 협공당해 모이는가 — 빌더 레이어의 수직 압축

M. · · 15 분 소요

위·아래에서 동시에 빌더 자리가 좁아질 때

1부에서 본 그림은 캔버스의 상품화와 시장의 폭발이었다. 캔버스라는 그릇은 옅어지지만 자동화 시장 자체는 5년 만에 4배 가까이 커진다는 데이터. 2부에서 본 그림은 그 빈자리에 코드 에이전트가 들어와도 노코드는 죽지 않는다는 것이었다. 확률적 생성이 늘어날수록 결정적 골격의 가치가 같이 커진다. 빌더는 에이전트 실행의 거버넌스 레이어로 자리를 옮기며 살아남는다.

3부의 질문은 한 단계 더 깊다. 그 빌더 레이어가 들어앉아 있는 자리 자체가, 위·아래에서 동시에 좁아진다면 어떻게 되는가?

위에서는 하이퍼스케일러(AWS·Azure·Google Cloud)가 에이전트 런타임을 인프라 기본재로 내리고 있고, 아래에서는 프론티어 모델랩(OpenAI·Anthropic·Google DeepMind)이 자기 챗 인터페이스 안에 빌더 기능을 흡수하고 있다. 흥미로운 점은 이 협공이 추상적 트렌드가 아니라, 2025년 10월부터 2026년 4월까지 7개월 안에 일어난 구체적 사건들의 누적이라는 것이다. 빌더가 들어 있던 공간이 양쪽에서 동시에 좁아진다.

3부의 한 줄 thesis는 이렇다.

빌더 레이어는 수직으로 압축되고, 가치는 그 위층 — 맞춤 ops 조립과 데이터 배기가스가 만들어내는 방어가능성 — 으로 옮겨간다.

이제 위·아래·중간 세 자리를 차례로 본다. 위에서 어떤 압력이 내려오고, 아래에서 어떤 압력이 올라오고, 빌더 레이어는 어디로 밀려가는가. 그리고 그 결과 가치가 모이는 새 자리에서 무엇이 방어가능한가.

위에서 내려오는 압력 — 하이퍼스케일러의 상향 통합

가장 강한 신호는 AWS, Microsoft Azure, Google Cloud 세 하이퍼스케일러가 같은 6개월 안에 에이전트 런타임을 GA(General Availability, 정식 출시) 단계로 끌어올렸다는 사실이다. 세 회사 모두 빌더가 팔던 것과 거의 같은 묶음을 인프라 기본재로 내렸다.

플랫폼GA 시점핵심 기능
AWS Bedrock AgentCore2025년 10월 13일Runtime, Memory, Gateway, Identity, Code Interpreter, Browser, Observability, Evaluation, Policy
Azure AI Foundry Agent Service2025년 11월M365 통합, 원클릭 Teams 배포, 10,000+ 고객 확보 후 GA
Google Vertex AI Agent Engine2026년 1분기Gemini 통합, Vertex Pipelines 연동, 엔터프라이즈 SLA

세 플랫폼이 공통으로 제공하는 것을 정리하면 한 가지가 보인다 — 빌더가 팔던 것과 거의 그대로 같은 묶음이다. 런타임, 메모리, 신원, 거버넌스, 관측성. 빌더의 가치 제안 핵심이 이제 클라우드 인프라의 기본 제공 항목으로 내려왔다.

AWS Bedrock AgentCore — 12개 컴포넌트 단위 과금

AWS는 가장 두텁고 명시적인 묶음을 내놨다. AgentCore의 코어 서비스는 다음 9개로 구성된다.

  • Runtime — 에이전트 실행 환경, 세션 격리. $0.0895 per vCPU-hour + $0.00945 per GB-hour로 활성 CPU 사용량 + 메모리 피크 기준 과금.
  • Memory — 단기 컨텍스트와 장기 지식 저장소.
  • Gateway — 도구·API 호출의 인증·라우팅.
  • Identity — 어떤 에이전트가 누구를 대신해 어떤 권한으로 행동하는가.
  • Code Interpreter — 샌드박스 안 코드 실행.
  • Browser — 클라우드 브라우저로 웹 조작.
  • Observability — 모든 호출과 결과 로깅.
  • Evaluation — 에이전트 성능·정확도 측정.
  • Policy — 에이전트 외부에서 도는 정책 엔진. $0.000025 per authorization request로 호출 단위 과금.

이 묶음을 보면 1부와 2부에서 빌더 회사들이 “우리만의 가치”라고 주장하던 항목과 거의 같다. n8n 2.0의 샌드박스 코드 실행, 지속 메모리, 데이터 주권은 AgentCore의 Code Interpreter·Memory·Identity와 일대일로 대응한다. 빌더가 차별점이라고 외치던 기능이 클라우드 인프라 한 단계 아래로 내려와 기본재가 됐다.

흥미로운 신호 중 하나는 AgentCore의 확장 속도다. 2026년 5월 11일에는 Payments(Preview) 컴포넌트가 추가됐다. Coinbase CDP와 Stripe Privy 지갑 통합으로, 에이전트가 직접 결제·송금까지 처리할 수 있게 됐다. Coinbase CDP 기준 $0.005 per wallet operation. 에이전트의 행동 범위가 SaaS 호출에서 결제·실세계 거래까지 확장되는 흐름을 인프라가 먼저 만들고 있다.

AgentCore의 GA 후 6개월 안에 실제로 채택된 사례를 보면, 빌더 SaaS와 직접 경쟁할 수밖에 없는 구조가 드러난다.

  • CloudZero(FinOps 플랫폼) — 클라우드 비용 최적화 에이전트를 AgentCore 위에 구축. 기존 빌더 도구에서 마이그레이션.
  • Apex Fintech Solutions — 금융범죄 조사 워크플로우를 AgentCore로 전환. 컴플라이언스 요구가 강한 환경에서 인프라 단위 격리가 결정적이었다.
  • Genpact — riskCanvas® Data Explorer 솔루션을 에이전트-투-에이전트(agent-to-agent) 통신 패턴으로 구축. 멀티 에이전트 오케스트레이션이 인프라 기본 제공이라는 점이 채택 이유.
  • Reply + Totemia — Reply가 프랑스의 어린이 여행 캠프 매칭 플랫폼 Totemia와 협력해 AgentCore 위에 Offer Agent를 구축. AgentCore Runtime + Gateway + Memory를 활용해, Totemia의 월간 사용자 30,000명에게 60개 옵션을 5–10개 맞춤 추천으로 좁혀준다. 검색 시간 65% 감소, 예약 40% 증가, 전환율 25% 상승, 1년차 ROI 200–300% 측정.

이 네 사례의 공통점은 한 가지다 — 빌더 SaaS를 거치지 않고 AgentCore에 직접 붙었다. Totemia의 30K MAU Offer Agent는 Zapier·n8n 같은 빌더 위에 만들 수도 있었지만, 인프라 격리·확장성·SLA를 위해 AgentCore를 골랐다. 이 패턴이 반복되면, 빌더 SaaS의 가운데 자리가 좁아진다.

Azure AI Foundry — 10,000+ 고객 확보 후 GA

Microsoft는 다른 차원의 압력을 만든다. GA 이전에 이미 10,000개+ 고객을 확보한 상태로 정식 출시했다. 원클릭 Teams 배포라는 가벼워 보이는 기능이 의외로 큰 효과를 낸다. 이미 직원이 Microsoft 365를 쓰는 조직 입장에서 별도 빌더 SaaS를 도입할 이유가 줄어든다.

Azure AI Foundry는 두 가지 자산을 합쳤다. 하나는 Azure 인프라의 격리·컴플라이언스 — VPC, Private Link, 지역별 데이터 거주. 다른 하나는 M365 데이터·신원 — 사용자가 이미 Microsoft 계정을 갖고 있고, SharePoint·Outlook·Teams의 데이터가 한 자리에 있다. 두 자산을 합치면, 신원·데이터·실행이 한 계정 안에 있는 에이전트 환경이 만들어진다. 빌더 SaaS가 같은 묶음을 제공하려면 별도 SSO·데이터 동기화·신원 매핑을 다 해야 한다.

빌더가 제공하던 UX 우위 — 한 사람이 워크플로우를 시각적으로 만들고 즉시 배포 — 가 Microsoft 생태계 안에서 같이 가능해진다. 그리고 그 위에 거버넌스·감사가 인프라 기본 제공으로 깔린다.

Google Vertex AI Agent Engine — Gemini와 통합

Google은 2026년 1분기에 Vertex AI Agent Engine을 정식 출시했다. Gemini 모델과 깊이 통합되어 있고, Vertex Pipelines(기존 ML 파이프라인 인프라)와 연동된다. AWS·Azure에 비하면 출시 시기가 늦었지만, Workspace(Google Docs·Sheets·Gmail) 데이터에 네이티브로 붙는다는 점이 핵심이다.

세 하이퍼스케일러가 같은 6개월 안에 같은 묶음을 GA로 끌어올렸다는 사실은 우연이 아니다. 인프라 회사들의 관점에서 에이전트 런타임은 다음 세대 컴퓨팅의 기본 단위다. 가상머신, 컨테이너, 함수(서버리스), 그리고 이제 에이전트 — 인프라가 단계적으로 추상화되어 온 흐름의 다음 칸이다. 그래서 빌더의 핵심 가치를 다 흡수해도, 그건 빌더를 죽이려는 의도가 아니라 인프라 표준을 잡으려는 움직임이다. 결과적으로 빌더 레이어가 협공받지만, 협공의 의도는 그게 아니다.

아래에서 올라오는 압력 — 모델랩의 제품 확장

같은 시점에 반대 방향의 압력이 올라온다. 프론티어 모델랩들이 챗 인터페이스에서 위로 올라와, 자기 제품 안에 빌더 기능을 흡수하고 있다.

이 흐름의 정점이 2026년 4월 22일이었다. 한 주 안에 다섯 개의 거대 플랫폼이 엔터프라이즈 에이전트 제품을 거의 동시에 출시했다. (Anthropic은 2주 빨리 4월 8일에 Claude Managed Agents를 public beta로 풀었다.)

출시일회사제품핵심
2026-04-08AnthropicClaude Managed Agents (public beta)샌드박스 실행, 체크포인팅, 권한 한정, 추적. 토큰 + 세션시간당 $0.08. Notion·Asana·Sentry pre-launch 채택
2026-04-22OpenAIWorkspace AgentsCodex 기반 클라우드 네이티브, 스케줄·Slack 트리거, Business/Enterprise/Edu 플랜
2026-04-22MicrosoftCopilot Studio + Agent 365M365 데이터 위 에이전트 빌드, 직원 단위 라이선스
2026-04-22GoogleGemini Enterprise Agent PlatformWorkspace·Vertex 통합, A2A(Agent-to-Agent) 프로토콜 발표
2026-04-22SalesforceAgentforce 360CRM 데이터 기반 에이전트, 영업·서비스 자동화

이 동시 출시가 말하는 것은 한 가지다 — 빌더의 핵심 사용 사례가 모델랩과 SaaS 거인의 제품 안으로 흡수되고 있다.

OpenAI Workspace Agents — Codex가 워크플로우를 대체한다

OpenAI Workspace Agents가 명시한 사용 사례를 보면 그림이 한층 또렷해진다. 내부 소프트웨어 요청 분류, 제품 피드백 라우팅, 영업 리드 자격심사, 회계 정산 — 이건 그대로 Zapier·n8n·Gumloop 같은 빌더가 지난 10년 팔던 워크플로우 카탈로그다.

Workspace Agents의 핵심 변화는 자율성의 수준이다. 기존 ChatGPT는 사용자가 매번 프롬프트를 줘야 작동했다. Workspace Agents는 스케줄(매일 오전 9시)이나 Slack 메시지를 트리거로 백그라운드에서 자율 실행된다. 한 번 만들면 팀 전체가 ChatGPT나 Slack 안에서 공유해서 쓸 수 있고, 다단계 작업을 여러 도구에 걸쳐 처리한다. 별도 빌더 도구를 켤 이유가 줄어든다.

가격 모델도 빌더와 직접 경쟁한다. Business/Enterprise/Edu/Teachers 플랜에 포함되고, 출시 후 2주(2026년 5월 6일까지)는 free-tier로 풀린 다음 credit 기반 과금으로 전환된다. 기존 ChatGPT 구독 안에 묶이기 때문에, 빌더 SaaS의 별도 라이선스 비용보다 entry barrier가 낮다.

Anthropic Claude Managed Agents — MCP 네이티브의 의미

Anthropic은 2주 빨리(4월 8일) Claude Managed Agents를 public beta로 출시했다. 다른 각도의 접근이다. OpenAI Workspace Agents가 챗 인터페이스 안에 에이전트를 박는다면, Anthropic은 개발자가 자기 시스템에 가져다 쓰는 매니지드 런타임을 제공한다.

샌드박스 실행 환경, 체크포인팅(중간 상태 저장·복구), 권한 한정(scoped permissions), 실행 추적(tracing). 가격은 표준 Claude API 토큰 요금 + 세션 시간당 $0.08. 프로덕션 launch 전부터 미리 도입한 곳은 Notion, Asana, Sentry — 이후 Rakuten 같은 early adopter도 합류했다. 이 회사들이 채택했다는 사실 자체가 신호다. 각자가 자체 빌더 인프라를 만들 수 있는 회사들이지만, Anthropic의 매니지드 런타임을 골랐다. 빌드 vs 바이(build vs buy) 결정에서 매니지드 쪽이 이긴 사례다.

그리고 더 중요한 한 가지 — Claude Agent SDK가 MCP(Model Context Protocol, 모델·도구 연결 표준) 네이티브라는 점이다. 1부에서 본 통합 표준화 흐름의 정점이다. 개발자가 코드로 에이전트를 정의하고, MCP를 통해 통합을 가져오고, Claude API로 추론을 돌린다. 비주얼 빌더가 필요 없는 사용자에게 캔버스를 건너뛰는 옵션이 처음부터 잘 닦여 있다.

7일 안에 같은 답에 도달한 두 모델랩

2부에서 잠깐 짚었던 이 사건의 의미를 3부에서 다시 본다. Anthropic은 4월 8일, OpenAI는 4월 22일. 두 모델랩이 7일 간격으로 거의 같은 architecture에 도달했다. 둘 다 강조한 항목 — 샌드박스 실행, 자격증명 관리, 컨트롤 플레인(control plane, 의사결정 층)과 실행 플레인(execution plane, 동작 층)의 분리.

이게 우연일 수가 없다. 두 회사가 각각 독립적으로 같은 결론에 도달했다는 사실은, 프로덕션 에이전트가 갖춰야 하는 조건이 시장 전체에서 수렴하고 있다는 신호다. 그리고 그 조건은 노코드 빌더가 지난 10년 팔던 묶음과 본질적으로 같다.

Microsoft·Google·Salesforce의 통합 흡수

같은 4월 22일에 세 거인도 같이 움직였다.

  • Microsoft Copilot Studio + Agent 365 — M365 라이선스에 묶여 들어가는 에이전트 빌더. 직원 단위 라이선스. 별도 빌더 SaaS의 가장 큰 위협이 여기서 나온다. 이미 Microsoft에 돈을 내고 있는 조직 입장에서 추가 라이선스를 사지 않아도 된다.
  • Google Gemini Enterprise Agent Platform — Workspace·Vertex와 묶여서 출시. 동시에 발표된 A2A(Agent-to-Agent) 프로토콜은 에이전트 간 통신 표준을 잡으려는 시도다. MCP가 모델·도구 연결이라면, A2A는 에이전트끼리의 연결.
  • Salesforce Agentforce 360 — CRM 데이터 위의 영업·서비스 에이전트. Salesforce 안에서 만들어진 에이전트는 CRM 데이터의 컨텍스트를 자연스럽게 갖는다. 이건 외부 빌더가 따라 하기 가장 어려운 자리다.

가장 상징적인 사건은 OpenAI와 AWS의 협업이다. OpenAI Frontier는 AWS가 독점 3자 유통권을 갖고, AWS Bedrock AgentCore 위에 stateful 런타임으로 구축됐다. 위에서 내려오는 압력(AgentCore)과 아래에서 올라오는 압력(OpenAI 제품)이 같은 자리에서 만나 합쳐졌다. 빌더 레이어가 협공받는 그림이 가장 또렷하게 드러나는 사례다.

이 협공의 결과는 한 가지 — “운영 기계장치(operational machinery)가 어디 사느냐”의 컨트롤 플레인이 새로운 전장이 됐다. 기업은 이제 단지 어떤 챗봇을 쓸지 고르는 게 아니라, 자기 회사 AI 작업의 실제 실행 엔진이 어디에 자리잡을지를 결정한다. Microsoft 스택 안인지, OpenAI API 레이어 안인지, Anthropic 매니지드 런타임 안인지, AWS AgentCore 위인지, 오픈 프레임워크 안인지, 또는 이 모두의 하이브리드인지.

빌더가 차지하던 자리는 이 컨트롤 플레인의 한 후보가 됐을 뿐이다. 다른 후보들 — 클라우드 인프라, 모델랩 SDK, 기존 SaaS 거인 — 이 같은 자리를 노린다.

빌더 레이어는 어디로 밀려가는가 — 압축과 재배치

위에서 내려오는 인프라와 아래에서 올라오는 제품이 빌더 자리를 좁히면, 빌더는 사라지는 게 아니라 위치를 옮긴다. 새 위치를 정리하면 4-레이어 그림이 보인다.

---
config:
  look: handDrawn
  theme: neutral
---
flowchart TB
    L4["레이어 4 — 맞춤 ops/ERP<br/>각 조직별 무한 개인화<br/>(역량의 자리)"]
    L3["레이어 3 — 빌더/오케스트레이션<br/>도메인 특화 조립 도구<br/>(빌더의 새 자리)"]
    L2["레이어 2 — 컨트롤 플레인<br/>모델랩 + 하이퍼스케일러 공동전장<br/>(OpenAI · Anthropic · Copilot · Agentforce)"]
    L1["레이어 1 — 인프라/런타임<br/>AgentCore · Foundry · Vertex<br/>(하이퍼스케일러)"]
    L4 --> L3
    L3 --> L2
    L2 --> L1

이 4-레이어 그림에서 각 자리의 성격을 보면 —

  • 레이어 1 — 인프라/런타임. 런타임, 메모리, 신원, 거버넌스가 인프라 기본재로 내려옴. 하이퍼스케일러의 자리. AgentCore의 채택 사례(CloudZero·Apex Fintech·Genpact·Reply)가 보여주듯, 빌더가 여기서 이기기 어렵다.
  • 레이어 2 — 컨트롤 플레인. “운영 기계장치가 어디 사느냐”의 진짜 전장. 모델랩이 챗 인터페이스에서 위로, 클라우드가 인프라에서 위로 올라와 충돌하는 자리. OpenAI Frontier가 AgentCore 위에 사는 사례, Anthropic Managed Agents의 매니지드 런타임이 양쪽이 합쳐지는 상징.
  • 레이어 3 — 조립/오케스트레이션. 빌더의 새 자리. 런타임 위에서 도메인 특화 ops를 조립하는 도구로 재정의. AgentCore의 “협력자(partner)“로 거론되는 CrewAI, LangGraph, SmythOS, LangChain이 여기에 위치.
  • 레이어 4 — 맞춤 ops/ERP. 각 조직마다 다른, 무한 개인화된 운영 레이어. 도구가 아니라 역량의 자리. 마진과 희소성이 살아 있는 곳.

빌더의 새 위치가 레이어 3이라는 점에 주목할 만하다. 빌더는 최종 제품이 아니라, 인프라 위에서 맞춤 ops를 조립하는 제작자용 도구로 재정의된다. 1부에서 본 음악 산업 비유를 호출하면, 빌더는 Spotify(레이어 1, 인프라)와 음원 코덱(레이어 2)이 아니라, 프로듀서가 쓰는 DAW(Digital Audio Workstation, 작곡 도구)에 가까운 자리다. 최종 소비자에게는 안 보이는 제작자 도구로 깊어진다.

이 재배치의 흥미로운 신호 중 하나가 AgentCore의 공식 문서다. AgentCore는 CrewAI, LangGraph, SmythOS, OpenAI Agents SDK를 “협력자”로 명시한다. “협력자”라는 표현이 핵심이다 — 같은 자리에서 싸우는 경쟁자가 아니라, AgentCore 위에서 도는 위층 도구로 자리를 정리한 것이다. 빌더가 AgentCore의 프론트엔드 역할을 하면서, AgentCore는 그 빌더의 백엔드 인프라가 된다.

a16z ‘Losing its Head’가 더하는 그림 — UI가 제품이었다

이 협공·재배치 그림에 결정적인 한 조각을 더하는 게 a16z의 분석이다. “Is Software Losing Its Head?”라는 글에서 a16z는 한 가지 재정의를 던진다 — 지난 20년간 엔터프라이즈 소프트웨어가 판 것은 데이터베이스가 아니라 UI였다.

세일즈포스를 예로 보면 의미가 또렷하다. 세일즈포스가 영업 리더에게 판 것은 영업 데이터베이스가 아니라, “영업 리더가 팀을 운영하는 방식” — 파이프라인 뷰, 대시보드, 분기 마감 화면 같은 UI 경험이었다. 많은 영업 리더가 이직할 때 세일즈포스를 가져가는 건 데이터베이스 자체가 좋아서가 아니라 그 UI에 형성된 근육 기억 때문이다. 인간이 인터페이스에 살았기 때문에 생긴 해자다.

그런데 에이전트가 API로 직접 데이터를 읽고 쓰는 시대가 오면, 이 해자가 증발한다. UI가 사라지면(headless), 방어선이 아래로(데이터 모델·권한·워크플로우 로직·컴플라이언스)와 위로(네트워크·독점 데이터 생성·실세계 실행) 이동한다. 1부에서 본 “캔버스가 옅어지고 가치가 다른 레이어로 옮겨가는 흐름”의 SaaS 버전이다. 빌더의 캔버스가 옅어진 자리에 데이터 레이어와 거버넌스 레이어가 짙어졌듯, SaaS의 UI가 옅어진 자리에 데이터 모델과 실행 레이어가 짙어진다.

a16z가 이 그림에 더하는 가장 새로운 개념이 데이터 배기가스(data exhaust)다.

방어 가능한 데이터는 외부에서 임포트한 데이터가 아니라, 제품이 고유하게 존재함으로써 생성된 데이터다. 최고의 비즈니스는 다른 데서 입력된 데이터를 창고에 쌓는 게 아니라, 루프 안에 있음으로써 새 데이터 배기가스를 만든다 — 관찰된 행동, 응답률, 타이밍 패턴, 프로세스 결과, 예외 패턴, 에이전트 성능 추적.

— a16z, “Is Software Losing Its Head?”

이 개념이 레이어 4(맞춤 ops)의 가치를 한 단계 더 깊게 만든다. 단순히 ops를 조립하는 게 아니라, 그 ops가 돌면서 고유 데이터를 생성하느냐가 진짜 해자가 된다. 다른 사람이 같은 도구를 써도 만들지 못하는 데이터를 자기 루프 안에서 생산하는가. 음악 비유로 치면, 큐레이션하면서 동시에 새 음원을 녹음하는 행위에 가깝다.

방어가능성의 6기준 — 새 스코어카드

a16z가 같은 글에서 제안하는 6기준은 빌더 협공 후의 새 가치 자리를 평가하는 데 그대로 쓸 수 있다. 레이어 4에 들어선 솔루션이 방어 가능한지 묻는 6가지 질문이다.

기준질문빌더 레이어에 적용
1. SoR 재현 난이도시스템 오브 레코드(System of Record, 진실 원본)를 재현하기 얼마나 어려운가단순 워크플로우 정의는 쉽게 재현됨. 도메인 깊이가 SoR화될수록 어려워짐
2. 독점 데이터의미 있는 자기 고유 데이터가 있는가워크플로우 실행 결과의 패턴, 예외, 성공률 — 이게 쌓이느냐
3. 액션 레이어 소유관찰만 하는가, 실행 안에 있는가빌더는 실행 레이어. 단 실행이 외부 API 호출만이면 가치 약함
4. 실세계 실행디지털 외 실세계에 닿는 요소가 있는가제조·필드서비스·물류 워크플로우는 강함. 순수 SaaS-to-SaaS는 약함
5. 네트워크 효과사용자가 많아질수록 가치가 커지는가표준 워크플로우 라이브러리, 통합 카탈로그, 협업 — 일부 구현됨
6. 구매자 기술 역량구매자가 직접 만들 능력이 있는가 (없을수록 가치↑)운영적으로 복잡하지만 기술적으로 저개발된 카테고리에 가장 큰 기회

각 기준의 의미를 깊이 풀어 본다.

기준 1 — SoR 재현 난이도

System of Record는 한 회사의 진실 원본 데이터가 사는 곳이다. 영업 데이터는 Salesforce에, 인사 데이터는 Workday에, 재무 데이터는 Oracle/SAP에. SoR을 갈아치우는 것은 천문학적 비용이 든다. 빌더 레이어가 SoR로 자리잡으려면, 단순한 워크플로우 카탈로그를 넘어 그 회사만의 핵심 운영 데이터가 빌더 안에 쌓여야 한다. 일반적 빌더 SaaS는 여기서 약하다. 도메인 특화 빌더(예: 금융 백오피스 전용)는 SoR로 진화할 가능성이 있다.

기준 2 — 독점 데이터 (data exhaust)

앞에서 본 핵심 개념이다. 빌더가 실행하는 워크플로우의 결과 — 성공률, 실패 패턴, 응답 시간, 사용자 개입 빈도 — 가 그 빌더만의 데이터로 쌓이는가. 이게 쌓이면 다음 워크플로우 최적화, 이상 탐지, 추천에 쓸 수 있다. 한 회사가 자기 빌더 안에서 1년간 실행한 데이터는, 다른 회사가 같은 빌더를 새로 도입해도 갖지 못하는 자산이다.

기준 3 — 액션 레이어 소유

관찰(observation)만 하는 시스템 — 예: 대시보드, 로그 분석 — 보다, 실행(action) 안에 있는 시스템이 강하다. 빌더는 본질적으로 액션 레이어다. 워크플로우를 실행해서 슬랙 메시지를 보내고, DB를 업데이트하고, 결제를 처리한다. 단, 그 실행이 외부 API 호출 중계에 그치면(예: Zapier가 단순히 A 앱의 데이터를 B 앱으로 옮기는 수준) 가치가 약하다. AgentCore의 Payments(Preview)가 가리키는 방향 — 에이전트가 실세계 거래까지 처리 — 이 액션 레이어를 더 깊게 만든다.

기준 4 — 실세계 실행

순수 SaaS-to-SaaS 자동화는 디지털 안에 갇혀 있다. 그 외부 — 제조 라인, 필드 서비스 기사, 물류 트럭, 의료 장비 — 에 닿는 워크플로우는 디지털 only 시스템이 따라 하기 어렵다. 이건 빌더 SaaS가 약한 자리이고, 도메인 특화 ops(레이어 4)의 가장 큰 기회 자리이기도 하다. Reply의 여행 예약 에이전트(30K MAU)가 강한 이유는 호텔·항공 예약이라는 실세계 거래에 닿기 때문이다.

기준 5 — 네트워크 효과

빌더 시장에서 네트워크 효과는 통합 카탈로그(앱 A가 빌더에 있으니 앱 B도 들어와야 한다), 표준 워크플로우 템플릿(사용자가 많을수록 더 많은 템플릿이 공유됨), 협업(팀 단위 공유)을 통해 일부 작동한다. 단, 1부에서 본 guMCP와 MCP 표준화 흐름이 통합 자체의 네트워크 효과를 약화시킨다.

기준 6 — 구매자 기술 역량

가장 깊은 기준이다. 누구나 이론상 자기 에이전트를 만들 수 있는 세상에서도, 실제 능력에는 큰 격차가 있다. 운영적으로 복잡하지만 기술적으로 저개발된 카테고리 — 제조 백오피스, 건설 현장 관리, 산업·필드서비스 워크플로우, 회계, 의료 행정 — 가 가장 큰 기회의 자리다. 이런 곳의 구매자는 자체 DB, 로직, 에이전트 스택, 거버넌스를 만들고 유지·개선할 가능성이 낮다.

이 6기준을 빌더 시장의 협공 후 그림에 겹쳐 보면 흥미로운 결론이 나온다. 빌더 도구 자체로 6기준을 다 만족하기 어렵다. 도구는 통합·실행·관측을 제공하지만, 독점 데이터, 실세계 실행, 도메인 SoR 깊이는 그 도구를 쓰는 사용자가 만들어야 한다. 그래서 가치가 도구에서 사용자 — 더 좁혀 말하면 도구를 도메인에 맞게 조립하는 역량 — 으로 이동한다. 6기준이 가리키는 자리가 그대로 4-레이어 그림의 레이어 4다.

마무리 — 협공 속에서 가치가 정착하는 자리

지금까지 본 그림을 한 줄로 모으면 이렇다. 빌더 레이어는 위(하이퍼스케일러)와 아래(모델랩)에서 동시에 압축되고, 가치는 그 압축의 결과로 레이어 4(맞춤 ops)와 그 위 데이터 배기가스로 옮겨간다.

2025년 10월부터 2026년 4월까지 7개월 안에 일어난 일들 — AgentCore GA(10월), Azure Foundry GA(11월), Vertex Agent Engine GA(1분기), Anthropic Managed Agents(4월 8일), OpenAI Workspace Agents·Microsoft·Google·Salesforce 동시 출시(4월 22일) — 은 우연이 아니라 한 시장이 같은 방향으로 동시에 움직인 사건의 누적이다. 위에서, 아래에서, 같은 자리를 향해.

이 결과 가장 큰 가치가 모이는 자리는 도구가 아니라 역량이다. 누가 클라이언트의 업무를 이해하고, 어느 런타임 위에 어떤 ops를 조립할지 설계하고, 그 ops가 돌면서 고유 데이터를 만들어내는 루프를 닫느냐 — 이 조립·큐레이션 능력이 협공받지 않고 오히려 커진다.

1부에서 시작한 음악 산업 비유로 시리즈를 받아 정리하면 — 스트리밍 시대에 가장 큰 가치는 인프라(Spotify)도 코덱(음질)도 아니라 큐레이션과 A&R(Artists & Repertoire, 아티스트 발굴·매니지먼트)이었다. 무한 공급 위에서 “무엇을, 누구를 위해, 어떻게 조합하느냐”를 아는 사람. 빌더 시장에서도 같은 자리가 떠오른다. 빌더는 인프라 안으로 흡수되지만, “맞춤 ops를 설계하는 큐레이터”의 가치는 협공받지 않고 오히려 커진다.

시리즈 3편의 결론을 한 줄로 모으면 다음과 같다.

끝나는 건 캔버스다. 빌더 카테고리가 아니다. 가치의 그릇은 캔버스에서 컨텍스트·실행·거버넌스로 옮겨가고, 그 위에서 맞춤 ops 조립과 데이터 배기가스가 새 큐레이션 프리미엄을 만든다.

a16z의 그림에는 한 가지 사각지대가 남아 있다. 이 글은 a16z의 통찰을 빌더 레이어에 적용했지만, a16z 자체가 AI-네이티브 스타트업 투자자라는 출처 편향이 있다. 그래서 “기존 incumbent가 흔들린다”는 결론으로 자연스럽게 기운다. 이 편향을 어떻게 할인해서 받을지, 그리고 a16z 본문이 흘리는 균열(전환 비용의 과소평가)을 어떻게 봐야 하는지는 별도 글에서 다룰 예정이다.


시리즈 — 빌더의 미래


참고 자료

  • AWS, “Bedrock AgentCore General Availability” (2025년 10월 13일)
  • AWS, “AgentCore Pricing — 12 Components” (Runtime $0.0895/vCPU-hour, Memory $0.00945/GB-hour, Policy $0.000025/request)
  • AWS Partner Network Blog, “Enterprise AI Agent Solutions with AgentCore” (CloudZero, Apex Fintech, Genpact, Reply+Totemia 채택 사례)
  • AWS, “AgentCore Payments (Preview)” (2026년 5월 11일, Coinbase CDP + Stripe Privy)
  • Microsoft, “Azure AI Foundry Agent Service GA” (2025년 11월, 10,000+ 고객, Teams 통합)
  • Google Cloud, “Vertex AI Agent Engine” (2026년 Q1)
  • Anthropic, “Claude Managed Agents Public Beta” (2026년 4월 8일, Notion·Asana·Sentry pre-launch + Rakuten early adopter, platform.claude.com/docs/managed-agents)
  • OpenAI, “Workspace Agents” (2026년 4월 22일, Codex 기반)
  • Microsoft, “Copilot Studio + Agent 365” (2026년 4월 22일)
  • Google, “Gemini Enterprise Agent Platform + A2A 프로토콜” (2026년 4월 22일)
  • Salesforce, “Agentforce 360” (2026년 4월 22일)
  • VentureBeat, “The Agent Control Plane is the Next Enterprise Battleground”
  • a16z, “Is Software Losing Its Head?” (UI as product, data exhaust, 6 criteria of defensibility)
공유

관련 글