Salesforce Headless 360 출시 해석: 한국 B2B가 다시 써야 할 SaaS 평가 4가지 기준
Salesforce가 TDX 2026 키노트와 공식 발표문에 담은 문장 하나를 먼저 읽어주세요. Joe Inzerillo(Salesforce President, Enterprise & AI Technology)가 키노트 무대에서 전달한 메시지입니다.
"If your platform requires humans to click through UIs or write code directly to make progress, it is not ready for the Agentic Enterprise."
"당신의 플랫폼이 사람이 UI를 클릭하거나 코드를 직접 써야만 일이 진전되는 구조라면, Agentic Enterprise에 준비되지 않은 겁니다."
25년간 "UI에서 클릭하는 CRM"으로 업계 표준을 만든 회사가 공식 발표문에 이 문장을 담았습니다. UI 클릭과 직접 코딩 두 가지를 같이 실패 모드로 지목한 겁니다.
엔트리에이아이를 운영하면서 저는 Salesforce 엔터프라이즈 라이선스를 쓰면서도 UI에 거의 로그인하지 않습니다. 데이터는 API로 넣고, 조회는 MCP 에이전트로 합니다. 이 운영 방식을 지난 몇 달간 써왔는데, 이번 발표로 Salesforce가 밀고 있는 공식 방향이 됐습니다.
Salesforce가 자신의 25년 제품을 재정의한 의미
공동창업자 Parker Harris가 TDX 직전에 던졌다는 질문입니다.
"Why should you ever log into Salesforce again?"
"왜 Salesforce에 다시 로그인해야 합니까?"
발표문은 이 질문을 방향(direction)으로 규정한다고 명시합니다. 도발(provocation)이 아니라는 단서까지 붙었어요. 그리고 2.5년 전 내부 결정을 공개했어요.
"Two and a half years ago, we made a decision: Rebuild Salesforce for agents."
"2.5년 전에 우리는 결정했습니다. Salesforce를 에이전트를 위해 다시 만들자고."
그리고 앞서 인용한 문장이 이어집니다. CRM 시장을 만든 회사가 자기 회사의 25년 제품 아키텍처를 공식적으로 레거시로 선언한 순간입니다.
"2.5년 전에 결정했다"는 공개에는 타이밍이 있습니다. 경쟁사가 이 선언을 따라오기 어려운 지점까지 쌓아놓고 공개했다는 뜻입니다. 60개 이상의 신규 MCP 도구, 30개 이상의 코딩 스킬, Claude Code·Cursor·Codex·Windsurf 같은 외부 코딩 에이전트에서 Salesforce 플랫폼 전체에 라이브 액세스 — 이게 2.5년간의 축적물입니다.
Headless란 무엇인가: 25년 UI 중심 SaaS의 종말 신호
Headless 360의 의미를 이해하려면 "Headless"라는 단어부터 짚고 가야 합니다. 번역하면 "머리(head)가 없다"인데, 여기서 머리는 사용자 인터페이스(UI), 프론트엔드를 뜻합니다. 백엔드와 프론트엔드가 하나로 묶여 있던 전통적 소프트웨어 구조에서 프론트엔드를 떼어낸 아키텍처가 Headless입니다.
이 개념이 업계에 본격적으로 퍼진 계기는 2013년 베를린에서 창업한 Contentful이라는 Headless CMS입니다. 그 전까지 WordPress로 대표되던 전통 CMS는 콘텐츠와 UI를 한 묶음으로 제공했어요. 블로그를 만들려면 WordPress가 내놓는 UI 안에서 써야 했습니다. Contentful은 이 구조를 뒤집었습니다. 콘텐츠는 API로만 제공하고, UI는 웹·모바일·IoT 기기 등 소비 주체가 알아서 만들도록 했어요. 소비 채널이 다양해지는 시대에 맞게 백엔드 한 벌로 여러 프론트엔드를 먹이는 구조가 된 겁니다.
Salesforce Headless 360은 이 Headless 개념을 CRM 전체에 적용한 선언입니다. 25년간 Salesforce는 "UI 안에서 쓰는 CRM"이었어요. 데이터도, 오브젝트도, 워크플로우도, 권한도 Salesforce UI라는 문을 통과해야 만날 수 있었습니다. Headless 360은 이 문을 걷어냅니다. UI는 Salesforce에 접근하는 여러 방법 중 하나로 내려가고, API·MCP·CLI 세 가지 표면이 동등한 접근 경로가 됩니다. 에이전트가 직접 쓰든, 개발자가 코드로 쓰든, 사람이 UI로 쓰든, 접근되는 것은 같은 Salesforce입니다.
이게 "25년 UI 중심 SaaS의 종말 신호"라는 해석이 과장이 아닌 이유입니다. UI는 여전히 존재하지만, UI가 더 이상 SaaS의 본체가 아니게 됐습니다.
Salesforce Headless 360이 바꾸는 것: 운영 모델 재프로그래밍
Diginomica의 Phil Wainewright가 이 발표를 다음과 같이 해석했습니다.
"Salesforce is making them legible to agents, effectively reprogramming its operating model rather than its products."
"Salesforce는 자신의 기능들을 에이전트가 읽을 수 있게 만들고 있습니다. 제품이 아니라 운영 모델(operating model)을 다시 프로그래밍하고 있는 겁니다."
— Phil Wainewright (Diginomica, 2026-04-15)
Salesforce가 Headless 360에서 한 일은 기존 기능을 에이전트가 탐색할 수 있는 구조로 분해해서 노출한 것입니다. 데이터, 워크플로우, 권한이 모두 API·MCP·CLI 세 가지 표면에 동시에 노출됩니다. UI는 그중 하나의 소비 방식일 뿐이에요.
"The surface changes. The platform doesn't."
"표면은 바뀝니다. 플랫폼은 바뀌지 않습니다."
Slack에서 접근하든, ChatGPT에서 접근하든, Claude에서 접근하든, MCP를 지원하는 어떤 클라이언트에서 접근하든, 같은 데이터·워크플로우·권한이 호출됩니다. 어느 표면으로 접근하든 호출당하는 쪽의 구조가 플랫폼의 본질이라는 재정의입니다.
이 관점을 한국 B2B 조직에 대입하면 질문을 해보면요,
우리 조직은 에이전트에게 읽히는가(legible)?
데이터 관점에서 궁합이 잘 맞는가 라고 할 수 있죠.
우리가 도입한 SaaS, 우리가 만드는 SaaS, 우리 내부 프로세스가 에이전트가 탐색할 수 있는 구조인가요? organizational design 차원의 질문인데, 실무로 내려오면 네 개 질문이 됩니다.
한국 B2B가 SaaS를 평가할 때 다시 읽어야 할 4가지 기준 (제품 3축 + 내부 역량 1축)
1. API·MCP·CLI 세 가지 표면이 모두 열려 있는가
Salesforce EVP이자 Headless 360의 핵심 설계자인 Jayesh Govindarjan이 VentureBeat 인터뷰에서 이 선택의 배경을 설명했어요.
"To be very honest, not at all sure that MCP will remain the standard. When MCP first came along as a protocol, a lot of us engineers felt that it was a wrapper on top of a really well-written CLI."
"MCP가 표준으로 남을지 전혀 확신하지 못합니다. MCP가 프로토콜로 처음 나왔을 때, 저희 엔지니어 다수는 그게 잘 쓰인 CLI 위의 wrapper라고 느꼈거든요."
— Jayesh Govindarjan, Salesforce EVP (VentureBeat, 2026-04-17)
Headless 360을 설계한 당사자가 MCP의 미래에 대해 확신하지 못합니다. 그래서 세 가지 표면을 동시에 열었어요. MCP가 무너져도 API와 CLI는 남습니다.
한국 B2B가 SaaS를 고를 때 물어야 합니다. API·MCP·CLI 중 최소 두 가지 표면이 동등한 수준으로 열려 있는가. 한 표면만 있는 SaaS는 여전히 위험성을 안고 가는 거라고 생각합니다.
2. 데이터 모델이 에이전트가 탐색 가능한 구조인가
UI 없이 쓰려면 에이전트가 따라갈 수 있는 데이터 모델 구조여야 합니다. Salesforce는 오브젝트 간 관계가 엔터프라이즈 규모로 정규화되어 있고, SOQL 한 번으로 연결된 데이터를 끌어옵니다. 에이전트가 "이 고객의 최근 3개월 지원 티켓과 갱신 일정과 담당자의 최근 이메일"을 한 번에 조회할 수 있어요. 네 개 CRM의 데이터 모델이 왜 이렇게 다르게 생겼는지는 따로 정리한 적이 있는데, 창업자의 질문이 데이터 구조를 결정했고 그 구조는 20년이 지나도 쉽게 안 바뀝니다.
많은 한국 B2B SaaS는 UI에서 잘 보이도록 데이터를 설계하고, API는 UI의 개별 화면을 흉내내는 수준으로 제공합니다. 같은 CRM이라도 사람이 UI로 쓸 때와 AI가 API로 접근할 때 경험이 완전히 다를 수 있어요. UI는 나쁜 데이터 구조를 시각적 정리, lazy loading, 필드 자동 번역으로 가려줍니다. API는 그걸 못 해요. 좋은 CRM UI와 좋은 CRM API는 같은 것이 아닙니다. 에이전트가 한 번의 호출로 필요한 맥락을 모을 수 없으면, MCP를 붙여도 "똑똑한 챗봇 흉내" 이상이 되기 어렵습니다.
도입 평가 때 던져야 할 질문입니다. 에이전트 한 번의 호출로 의사결정에 필요한 맥락이 모이는가? 호출이 다섯 번 여섯 번 필요하다면, 그 SaaS는 UI를 위해 만들어진 제품입니다.
3. 조직이 만들어내는 맥락 중 SaaS에 저장되는 비율은 얼마인가
Headless 360이 가진 전제는 "맥락은 Salesforce 안에 있다"입니다. 발표문에 이런 표현이 있어요.
"A coding agent connected to a raw database doesn't know that a customer has an open escalation, a renewal due in 30 days, a breached support SLA, and a relationship owner with a personal connection to their CFO."
"원시 데이터베이스에만 연결된 코딩 에이전트는 고객에게 미해결 에스컬레이션이 있는지, 30일 뒤 갱신이 있는지, 깨진 SLA가 있는지, 담당자가 고객사 CFO와 개인적 관계가 있는지 모릅니다."
맞는 말입니다. 다만 한국 B2B 조직의 현실을 대입하면 다른 질문이 떠오릅니다. 그 맥락이 CRM 안에 이미 들어가 있나요? CRM·ERP 같은 엔터프라이즈 소프트웨어에 도메인 지식이 다 들어있다는 생각부터 착각일 수 있습니다.
한국 조직의 맥락은 Slack 내부 대화, KakaoTalk 채팅, 이메일, 미팅 녹취, LinkedIn 대화, 채널톡 DM에 흩어져 있습니다. 이 중 상당수는 아무 데도 기록되지 않고 세일즈맨의 머릿속에만 남습니다.
숫자로 보면 선명해집니다. 제가 엔트리에이아이에서 Composio로 연결해둔 데이터 소스는 15개인데, 이 중 Salesforce는 1개입니다.
나머지 14개는 전부 Salesforce 바깥입니다.
커뮤니케이션: Gmail, Slack, Slackbot, LinkedIn
미팅·일정: Fireflies, Calendly, Google Meet, Google Calendar
문서·저장: Google Docs, Google Sheets, Google Drive
웹 분석·개발: Google Search Console, Google Analytics, GitHub
Headless 360은 이 15개 중 Salesforce 한 곳의 문만 엽니다. 나머지 14개의 맥락이 그 1개로 흘러 들어오는 문제는 Salesforce가 풀어주지 않습니다.
Salesforce가 플랫폼을 아무리 에이전트 친화적으로 만들어도, 조직이 만들어내는 맥락 중 SaaS 안에 저장되는 비율이 낮으면 Headless 360의 약속은 한국 조직에서 제한적으로만 실현됩니다. Salesforce가 해결한 건 "CRM 안의 맥락을 에이전트에게 꺼내주는 문제"입니다. CRM 바깥의 맥락이 CRM 안으로 들어오는 문제는 한국 조직이 따로 풀어야 합니다.
4. 이 선언을 조직 안에서 실행할 사람이 있는가 (Builder Gap)
앞의 세 기준이 SaaS 제품 자체를 평가하는 잣대라면, 네 번째는 그 SaaS를 에이전트 시대에 맞게 운영할 사람 문제입니다. 발표 이후 나온 평론 중 하나가 SalesforceDevops.net의 Ben McCarthy가 쓴 "Builder Gap" 관찰입니다.
"Salesforce Headless 360 is a play for the Claude-pilled generation. But the Trailblazers who built the ecosystem still aren't invited to this party."
"Headless 360은 Claude에 익숙한 세대를 위한 판입니다. 이 생태계를 만들어온 Trailblazer들은 여전히 이 파티에 초대받지 않았습니다."
— Ben McCarthy (SalesforceDevops.net, 2026-04-15)
25년간 Salesforce를 low-code로 운영해온 관리자·컨설턴트들은 이번 발표의 대상이 아닙니다. Headless 360, MCP 도구, Agent Script, React 네이티브는 pro-code 메뉴입니다. Salesforce가 도입부 선언에서 "UI 클릭"과 "코드 직접 쓰기"를 같이 실패 모드로 지목한 이유가 여기에 있어요. low-code 운영자도, 전통적 pro-code 개발자도, 에이전트가 주도하는 개발 방식에는 부족합니다.
한국 B2B에도 같은 구도가 작동합니다. 한국 기업 안에서 "CRM 관리자" 역할을 하는 분들, 도입한 SaaS의 UI를 매뉴얼로 관리해온 분들은 이 파티의 주인공이 아니에요. 조직이 앞으로 필요로 하는 건 API·MCP·CLI를 다룰 줄 알고 LLM 행동을 디버깅할 줄 아는 사람입니다.
우리 조직 안에 이 선언을 현장에서 실행할 사람이 있는가? 없다면, 외부 파트너를 어떻게 구성할 것인가. SaaS 벤더 선택과 내부 역량 구축은 이제 따로 결정할 수 없는 문제가 됐습니다.
Headless 360 도입 전 반드시 확인해야 할 계약 조건
Salesforce 선언의 방향이 맞다고 해서 도입이 단순해지는 건 아닙니다. CIO에 실린 기사에서 Info-Tech Research Group의 Scott Bickley는 세 가지 공백을 지적했습니다.
가격·라이선싱 모델이 공개되지 않음
MCP tool call의 SLA가 명시되지 않음
거버넌스 도구의 성숙에 12~18개월 소요 예상
Medium에 글을 올린 아키텍트 Shikher Goel은 경제성 측면을 짚습니다. 에이전트가 반복 호출하는 과정에서 Apex governor limits, async limits, per-org ceiling에 부딪히는 비용 구조 문제를 TDX 무대에서 아무도 다루지 않았다는 지적입니다.
도입 결정권자가 이 방향을 따라갈 때 계약 회의 테이블에 올려야 할 질문 세 가지입니다.
가격 구조 — 사용자 수 기반인지, usage 기반인지, 혼합인지
호출 SLA — MCP tool call과 API 호출의 응답 보장 수준
한도 정책 — per-org 호출량 한도와 초과 시 요금 구조
한국 B2B 조직도 "AI 에이전트 지원"이라는 마케팅 문구 뒤에 이 세 가지가 계약서에 명시되어 있는지 계약 전에 물어야 합니다.
Agentic Enterprise 가 되려면
"If your platform requires humans to click through UIs or write code directly to make progress, it is not ready for the Agentic Enterprise."
Salesforce가 지난 25년 걸어온 자기 제품의 방향을 공식적으로 재정의한 순간입니다. CRM 시장을 만든 회사가 이렇게 선언한 이상, 한국 B2B가 지금 도입하려는 SaaS, 운영하고 있는 SaaS, 만들고 있는 SaaS도 같은 질문 앞에 서게 됩니다.
여러분의 조직은 에이전트에게 잘 읽혀지는 형태로 구조화되어 있나요?
API·MCP·CLI 중 무엇이 열려 있는지
에이전트가 한 번의 호출로 맥락을 모을 수 있는 데이터 모델인지
조직이 만들어내는 맥락이 어떤 형태로 저장되고 있는지
이걸 운영할 사람이 조직 안에 있는지
Headless는 Salesforce에서 끝나는 흐름이 아닙니다.
앞으로 더 많은 Headless 제품이 출시될 겁니다.
소프트웨어 제품을 만들고 있다면 Builder의 입장에서,
소프트웨어 도입을 고민하고 있다면 같은 4가지 질문이 똑같이 필요합니다.