Salesforce가 앱을 기능으로 바꾼다: Headless 360과 MCP가 AI 에이전트 개발을 바꾸는 방식

AI 에이전트를 만들 때 가장 오래 걸리는 일은 모델을 고르는 것이 아닙니다. 고객 데이터가 어디에 있고, 어떤 워크플로우를 호출할 수 있으며, 누가 어떤 행동을 승인하는지 연결하는 일이 더 어렵습니다.

Salesforce는 2026년 8월 25일 Headless 360 확장 계획을 발표했습니다. 핵심은 Salesforce의 각 클라우드와 데이터를 화면 중심의 애플리케이션이 아니라, 권한과 업무 규칙을 포함한 재사용 가능한 기업 기능으로 노출하는 것입니다. 발표에는 Headless 360 MCP Server, Data 360 MCP Server, Slack 연동, 재사용 가능한 Skills, Headless Experience Layer가 포함됐습니다. Salesforce 공식 발표

이 소식이 중요한 이유는 “Salesforce에 MCP 서버가 하나 더 생겼다”가 아닙니다. 앞으로의 엔터프라이즈 AI 에이전트가 애플리케이션 API를 일일이 외워 호출하는 대신, 허용된 기능을 스스로 발견하고 업무 컨텍스트에 맞춰 실행하는 방향으로 바뀔 수 있기 때문입니다.

앱을 AI에 연결하는 방식이 “API를 하나씩 붙이는 통합”에서 “권한이 있는 기능을 발견해 조합하는 플랫폼”으로 이동하고 있다.

Salesforce 발표에서 실제로 달라지는 것

Salesforce가 설명한 Headless 360은 기존 애플리케이션을 없애는 개념이 아닙니다. CRM, 마케팅, 서비스, 커머스, 분석 등에 이미 존재하는 데이터·메타데이터·워크플로우·권한을 다른 AI 경험에서도 재사용할 수 있게 노출하는 계층에 가깝습니다.

발표 내용에서 개발자가 주목할 부분은 네 가지입니다.

Salesforce는 100개 이상의 재사용 가능한 Skills와 Agentforce, Claude, ChatGPT, Cursor 등에서의 활용을 언급합니다. 다만 이것은 Salesforce의 제품 발표에 따른 설명이므로, 실제 제공 범위와 계정별 조건은 공식 문서와 제품 계약에서 다시 확인해야 합니다.

“API 통합”과 “기능 발견”은 어떻게 다른가

기존 엔터프라이즈 AI 프로젝트는 보통 아래처럼 시작합니다.

1
2
3
4
5
6
7
에이전트 목표
   ↓
개발자가 API 목록 작성
   ↓
각 API의 스키마·인증·예외를 프롬프트와 코드에 연결
   ↓
변경이 생길 때마다 에이전트 설정을 다시 배포

이 방식은 작은 PoC에서는 빠르지만, 조직 규모가 커질수록 문제가 생깁니다. 영업팀과 고객지원팀이 서로 다른 API를 사용하고, 같은 고객 데이터를 여러 서비스가 복제하며, 담당자가 바뀔 때 권한 규칙이 프롬프트에 남아 버립니다.

Headless 360과 MCP가 지향하는 흐름은 다음과 같습니다.

1
2
3
4
5
6
7
8
9
사용자·에이전트 인증
        ↓
MCP 서버가 허용된 기능과 스키마를 노출
        ↓
에이전트가 현재 목표에 필요한 기능을 발견
        ↓
권한·정책·업무 규칙 확인
        ↓
데이터 조회 또는 액션 실행 + 감사 로그

여기서 MCP(Model Context Protocol)는 에이전트와 도구 사이의 공통 인터페이스입니다. MCP가 권한 모델 자체를 대신하는 것은 아니며, 서버가 어떤 리소스와 도구를 어떤 조건에서 공개하는지가 핵심입니다. “MCP를 연결했으니 안전하다”가 아니라 “MCP 서버가 기존의 인증·권한·감사 체계를 그대로 집행하는가”를 확인해야 합니다.

본문 중간 그림: 앱에서 기능으로 내려가는 계층

다음 그림처럼 애플리케이션의 데이터·워크플로우·인증이 MCP를 통해 에이전트의 발견·이해·행동으로 이어집니다. 가운데의 MCP는 마법 같은 AI 계층이 아니라, 기존 업무 기능을 도구로 설명하고 호출하는 경계입니다.

개발자가 다시 설계해야 할 5가지

1. 도구 목록보다 “도구의 경계”를 먼저 정의한다

에이전트에게 update_customer, send_email, create_case를 모두 열어 주는 것은 통합이 아니라 위험의 확장입니다. 도구를 다음처럼 업무 단위로 나누고, 읽기와 쓰기를 분리하세요.

1
2
3
4
읽기: 고객·주문·케이스 조회
초안: 답변·리포트·업무 업데이트 제안
쓰기: 레코드 변경·케이스 생성
외부 행동: 이메일 발송·환불·계약 변경

특히 외부 행동은 모델이 호출할 수 있다는 사실과 실제 실행 권한을 분리해야 합니다. 사용자 확인, 조직 정책, 금액 한도, 시간 제한을 서버에서 검사하는 것이 기본입니다.

2. MCP 서버에 도메인 지식을 넣되, 프롬프트에 숨기지 않는다

에이전트가 “고객 등급이 Platinum이면 환불 승인 없이 처리해도 된다”는 규칙을 프롬프트로만 알고 있다면 정책이 바뀔 때 사고가 납니다. 업무 규칙은 가능한 한 원 시스템의 정책 엔진이나 서버 코드에서 판정하고, MCP 도구는 판정 결과와 근거를 구조화해 반환해야 합니다.

1
2
3
4
5
6
7
8
9
type ActionDecision = {
  allowed: boolean;
  reason: string;
  requiresApproval?: boolean;

async function decideRefund(input, identity): Promise<ActionDecision> {
  // 실제 권한·금액 한도·고객 상태는 서버의 정책 계층에서 확인한다.
  return policyEngine.evaluate("refund.create", { input, identity });
}

이 예제의 핵심은 함수 이름이 아니라 allowed, requiresApproval, policyVersion을 도구 결과로 남기는 습관입니다. 에이전트가 왜 행동했는지 나중에 재현할 수 있어야 합니다.

3. “발견 가능성”과 “노출 최소화”를 동시에 달성한다

MCP의 장점은 에이전트가 모든 도구를 하드코딩하지 않아도 된다는 점입니다. 반대로 도구를 너무 많이 공개하면 모델이 불필요한 기능을 선택하고, 민감한 메타데이터가 컨텍스트에 섞일 수 있습니다.

테넌트·역할·업무 단계에 따라 서버가 노출하는 도구 목록을 줄이고, 도구 설명에는 모델이 선택에 필요한 정보만 넣으세요.

1
2
나쁜 설명: “고객을 업데이트합니다.”
좋은 설명: “현재 사용자가 소유한 고객 레코드의 전화번호만 수정합니다. 이메일·등급 변경에는 승인 필요.”

도구 설명도 API 계약의 일부입니다. 변경 이력을 버전 관리하고, 설명 변경이 에이전트의 선택률에 어떤 영향을 주는지 평가해야 합니다.

4. 재사용 가능한 Skill을 코드 모듈처럼 관리한다

Salesforce는 업무 로직을 Skills와 Plugins로 패키징하는 방향을 제시했습니다. 개발팀이 이 흐름을 도입한다면 Skill을 단순 프롬프트 파일로 보지 말고, 다음 항목을 갖춘 배포 단위로 취급하는 편이 좋습니다.

• 입력·출력 스키마
• 사용할 수 있는 MCP 도구 목록
• 읽기·쓰기 권한과 승인 조건
• 대표 성공·실패 예시
• 평가 데이터셋과 변경 이력
• 담당 팀과 폐기 기준

이렇게 하면 같은 Skill을 Agentforce, 사내 챗봇, 고객지원 도구에서 사용하더라도 동작 차이를 추적하기 쉬워집니다.

5. UI가 아닌 “업무 완료”를 관찰한다

Headless Experience Layer처럼 같은 기능이 웹, 모바일, Slack, 대화형 UI에서 재사용되면 화면별 지표만 봐서는 품질을 비교하기 어렵습니다. 다음 이벤트를 공통 스키마로 기록하세요.

1
2
3
4
5
6
7
8
9
10
{
  "trace_id": "trace_...",
  "actor_id": "user_...",
  "tool_name": "case.create",
  "policy_version": "2026-08-27",
  "approval": "required",
  "result": "completed",
  "latency_ms": 842,
  "source_channel": "slack"
}

중요한 지표는 대화 길이나 토큰 수만이 아닙니다. 올바른 케이스가 만들어졌는지, 중복 생성이 없었는지, 사람이 승인한 비율은 얼마인지, 원 시스템에 근거와 함께 기록됐는지를 봐야 합니다.

MCP를 도입할 때 흔한 오해

“MCP가 있으면 모든 모델에서 바로 쓸 수 있다”

MCP는 연결 규격이지 모델의 도구 선택 능력을 보장하는 기능이 아닙니다. 모델별 함수 호출 품질, 스트리밍 방식, 인증 흐름, 도구 제한을 별도로 테스트해야 합니다.

“데이터를 한 곳으로 복제해야 한다”

Headless 360의 방향은 기존 데이터와 업무 로직을 재사용하는 것입니다. 실제 구현에서 캐시나 검색 인덱스가 필요할 수는 있지만, 에이전트용 복제 DB를 무조건 새로 만드는 것과 MCP 서버가 원 시스템의 기능을 안전하게 노출하는 것은 다른 선택입니다.

“에이전트가 알아서 권한을 지킨다”

권한은 모델의 선의가 아니라 서버의 강제 규칙이어야 합니다. 에이전트가 잘못된 도구를 골라도 서버가 거부하고, 거부 이유를 사용자와 운영자에게 설명할 수 있어야 합니다.

“오픈 표준이면 벤더 종속이 사라진다”

MCP로 호출 규격을 통일해도 데이터 모델, 정책 엔진, Skill 정의, 감사 로그는 플랫폼에 남을 수 있습니다. 이식성을 원한다면 도메인 모델과 평가 케이스를 별도로 관리하고, MCP 어댑터를 교체 가능한 계층으로 두세요.

지금 팀이 시작할 수 있는 작은 실험

처음부터 모든 Salesforce 클라우드를 에이전트에 공개할 필요는 없습니다. 한 가지 읽기 업무와 한 가지 승인형 쓰기 업무를 골라 다음 순서로 검증해 보세요.

1. case.search처럼 부작용이 없는 읽기 도구 하나를 정의한다.
2. 역할별로 반환 필드와 레코드 범위를 제한한다.
3. 같은 도구를 웹 챗봇과 Slack 등 두 채널에서 호출한다.
4. 오답, 권한 거부, 빈 검색 결과, API 타임아웃을 평가한다.
5. case.create를 승인 필수로 추가하고 중복 실행 테스트를 한다.
6. 성공률보다 업무 완료율과 감사 로그의 재현성을 먼저 검토한다.

이 실험이 안정화되면 Data 360 같은 고객 컨텍스트, 재사용 Skill, 외부 MCP 클라이언트로 범위를 넓혀도 됩니다.

결론: 다음 경쟁은 “가장 똑똑한 모델”보다 “가장 잘 포장된 업무 기능”이다

Salesforce의 Headless 360 발표는 기업용 AI의 연결 단위가 애플리케이션 화면에서 권한을 가진 기능(capability) 으로 이동하고 있음을 보여줍니다. MCP는 이 이동을 가능하게 하는 공통 언어가 될 수 있지만, 실제 차별화는 서버의 권한 설계·정책 버전·데이터 품질·관찰성에서 만들어집니다.

개발자가 지금 준비할 일은 새 에이전트를 더 많이 만드는 것이 아닙니다.

• 반복되는 업무를 작고 검증 가능한 기능으로 분해하고
• 각 기능의 입력·출력·권한을 계약으로 만들고
• MCP 어댑터와 원 시스템의 정책 계층을 분리하고
• 여러 채널에서 같은 업무 완료율을 측정하는 것

이 구조가 갖춰지면 Salesforce뿐 아니라 어떤 CRM, 데이터 플랫폼, 사내 시스템에도 에이전트를 붙일 때 재작업을 줄일 수 있습니다. 앱이 AI를 호출하는 시대에서, AI가 신뢰할 수 있는 기업 기능을 찾아 일을 끝내는 시대로 넘어가는 중입니다.

출처

• Salesforce 공식 발표: Salesforce Turns Enterprise Applications into Enterprise Capabilities
• Model Context Protocol 공식 사이트