Salesforce가 Agentforce 3에서 MCP(Model Context Protocol) 지원과 AgentExchange 확장을 공식 발표했다. 기술 스펙만 보면 오픈 표준 연동과 LLM 유연성 확보라는 글로벌 아키텍처 이야기다. 그런데 한국 시장에서 이 발표가 갖는 의미는 다르다. AI 에이전트 자체 구축이 SI 업체 없이도 가능한 구조로 바뀌고 있다는 신호이기 때문이다.
한국 SI 의존 구조가 만들어낸 문제
한국 대기업과 금융권의 Salesforce 도입 패턴은 일관된 구조를 따른다. 초기 구축은 대형 SI가 담당하고, 이후 운영·고도화도 동일 SI에 의존한다. 이 구조가 고착되는 이유는 단순하다. 플랫폼 내부 아키텍처를 SI가 독점적으로 이해하고 있기 때문이다.
Agentforce 1·2 세대에서 에이전트 구축은 Topics, Actions, Instructions 설계와 Atlas Reasoning Engine의 추론 흐름을 이해해야 했다. Flow 오케스트레이션, Prompt Builder 템플릿 유형(Sales Email, Field Generation, Flex)의 적절한 조합, Data Cloud Data Streams와의 연결 설계까지 고려하면, 내부 팀이 독립적으로 구축하기에는 진입 장벽이 높았다. 결과적으로 “에이전트 하나 추가”도 SI 변경 요청으로 처리되는 구조가 반복됐다.
이 구조의 비용은 속도다. 시장 변화에 반응해야 하는 에이전트 로직 수정이 품의-발주-개발-검수 사이클을 거치면 수개월이 걸린다. 에이전트 AI의 가치가 빠른 반복에 있다는 점을 감안하면, 이 지연은 단순한 불편이 아니라 구조적 경쟁력 손실이다.
MCP 지원이 바꾸는 에이전트 아키텍처
MCP는 에이전트가 외부 도구·데이터 소스와 상호작용하는 방식을 표준화한 프로토콜이다. Agentforce 3에서 MCP 지원이 추가됐다는 것은 두 가지를 의미한다.
첫째, Salesforce 외부 시스템과의 연동이 MuleSoft 커스텀 커넥터 없이도 가능해진다. 기존에는 ERP, 그룹웨어, 사내 레거시 시스템을 Agentforce Actions에 연결하려면 External Services 설정이나 MuleSoft 통합 레이어가 필요했다. MCP 서버를 통해 표준화된 인터페이스를 제공하면, 에이전트가 직접 해당 도구를 호출할 수 있다. SI가 커스텀 통합을 독점적으로 관리하던 영역이 열린다.
둘째, AgentExchange에서 파트너가 제공하는 MCP 서버를 조합해 에이전트를 구성할 수 있다. 이는 레고 블록 방식의 에이전트 조립에 가깝다. 내부 팀이 AgentExchange에서 필요한 기능 블록을 선택하고, Topics와 Actions로 조합하면 기본 에이전트가 완성된다. 처음부터 커스텀 개발이 필요한 범위가 줄어든다.
Agentforce의 Atlas Reasoning Engine이 실제로 어떻게 작동하는지를 이해하면, MCP 연동이 추론 루프에서 어떤 위치를 차지하는지 더 명확해진다. 에이전트가 사용자 요청을 받아 계획을 수립하고 도구를 호출하는 ReAct 루프에서, MCP는 도구 호출 레이어를 표준화한다. 추론 로직 자체는 Atlas가 담당하고, 외부 연동의 복잡도는 MCP가 흡수한다.
AI 에이전트 자체 구축이 가능해지는 조건
AI 에이전트 자체 구축이 현실적으로 가능해지려면 세 가지 조건이 충족되어야 한다. Agentforce 3는 이 세 조건을 동시에 진전시켰다.
표준화된 연동 인터페이스. MCP 지원으로 외부 시스템 연결의 커스텀 개발 의존도가 낮아진다. 내부 팀이 MCP 서버 스펙을 이해하면 직접 연동 설계가 가능하다.
재사용 가능한 컴포넌트 생태계. AgentExchange 확장으로 검증된 Actions와 MCP 서버 컴포넌트를 조합할 수 있다. 처음부터 구축하는 대신 조합과 설정에 집중할 수 있다.
테스트와 검증 도구. Agentforce Testing Center를 통해 에이전트 동작을 내부에서 검증할 수 있다. SI에 의존하지 않고 품질 기준을 자체적으로 관리할 수 있는 기반이 생긴다.
이 세 조건이 갖춰지면, 내부 Salesforce 팀이 에이전트 로직을 직접 설계하고 반복할 수 있다. SI는 초기 아키텍처 설계와 복잡한 통합 레이어에 집중하고, 운영 단계의 에이전트 고도화는 내부에서 처리하는 구조로 전환이 가능하다.
실제로 이 전환이 가능한 조직은 내부에 Salesforce 플랫폼을 이해하는 인력이 있는 경우다. 사업부 15개 이상, 컨설턴트 200명 규모의 Center of Excellence를 운영하는 조직에서는 이미 이 방향으로 움직이고 있다. 문제는 그 아래 규모의 조직이다. 내부 역량이 없는 상태에서 MCP와 AgentExchange가 생겨도, 여전히 SI 없이는 시작하기 어렵다.
한국 기업이 놓치기 쉬운 함정
MCP 지원과 AgentExchange 확장이 SI 의존도를 자동으로 낮추지는 않는다. 몇 가지 함정이 있다.
첫 번째는 데이터 거버넌스 문제다. 에이전트가 MCP를 통해 외부 시스템에 접근할 때, 개인정보 보호법(PIPA) 준수 여부를 누가 검증하는가. SI가 통합을 담당할 때는 SI가 이 책임을 일부 공유했다. 내부 팀이 직접 MCP 서버를 연결하면, 데이터 접근 범위와 처리 목적의 적법성 검토가 내부 책임이 된다. 에이전트가 고객 데이터를 조회하고 외부 LLM에 전달하는 흐름이 생기면, PIPA의 위탁 처리 및 제3자 제공 조항을 검토해야 한다. 이 부분을 간과하고 빠르게 구축하면 규제 리스크가 생긴다.
두 번째는 Data Cloud 연동의 복잡도다. Agentforce 에이전트가 실질적인 개인화 응답을 하려면 Data Cloud의 Unified Individual 프로필과 Calculated Insights를 참조해야 한다. Data Graphs를 통한 사전 계산 조인 설계, Identity Resolution ruleset 구성은 MCP가 단순화해주는 영역이 아니다. 에이전트 자체 구축이 가능해졌다고 해서 Data Cloud 아키텍처 설계까지 단순해진 것은 아니다. Data Cloud Identity Resolution이 실제로 어떻게 작동하는지 이해하지 못한 상태에서 에이전트를 구축하면, 에이전트가 단편적인 고객 데이터를 기반으로 잘못된 응답을 생성하는 문제가 발생한다.
세 번째는 LLM 유연성의 함정이다. Agentforce 3에서 호스팅 LLM 선택지가 확장됐다. 이는 기회이기도 하지만, 어떤 LLM을 어떤 에이전트 유형에 사용할지 결정하는 것이 새로운 아키텍처 판단 영역이 됐다는 의미다. 비용, 응답 품질, 지연 시간, 데이터 국외 이전 여부를 동시에 고려해야 한다. 특히 한국 금융권과 공공 부문에서는 데이터가 국내 인프라에 머물러야 하는 요건이 있다. LLM 선택이 자유로워졌다는 것이 곧 아무 LLM이나 써도 된다는 의미가 아니다.
SI 역할의 재정의
SI 의존도가 낮아진다는 것이 SI가 필요 없어진다는 뜻은 아니다. 역할이 바뀐다.
기존 SI의 역할은 플랫폼 지식의 독점적 보유자였다. Agentforce 3 이후에는 이 독점이 약해진다. 대신 SI가 가치를 제공할 수 있는 영역은 초기 아키텍처 설계, 복잡한 멀티클라우드 통합, 그리고 PIPA 준수 설계다. 에이전트 로직의 반복적 고도화는 내부 팀이 담당하고, SI는 플랫폼 기반 설계와 거버넌스 프레임워크 구축에 집중하는 구조가 합리적이다.
이 전환을 준비하는 CIO·CTO라면 지금 해야 할 질문은 하나다. 내부 팀이 Agentforce의 Topics-Actions-Instructions 구조를 직접 설계하고 Agentforce Testing Center로 검증할 수 있는 역량을 갖추고 있는가. 그 역량이 없다면, MCP와 AgentExchange가 아무리 열려도 SI 의존 구조는 유지된다.
Agentforce 아키텍처 설계에서 내부 역량 구축과 SI 협업 구조를 어떻게 설계할지는 초기 단계에서 결정해야 한다. 나중에 바꾸기 어렵다.
핵심 정리
- Agentforce 3의 MCP 지원은 외부 시스템 연동의 커스텀 개발 의존도를 낮추지만, Data Cloud 아키텍처 설계와 PIPA 준수 검토는 여전히 전문 역량이 필요하다.
- AgentExchange의 파트너 MCP 서버 생태계는 에이전트 조립 방식을 레고 블록 모델로 전환한다. 처음부터 구축하는 범위가 줄어들고, 조합과 설정이 핵심 역량이 된다.
- AI 에이전트 자체 구축이 가능해지는 조건은 플랫폼 기술이 아니라 내부 인력이다. Topics-Actions-Instructions 설계를 직접 할 수 있는 내부 팀이 없으면 MCP 지원은 이론적 가능성에 머문다.
- 한국 기업의 SI 의존 구조는 플랫폼 지식 독점에서 비롯됐다. Agentforce 3는 그 독점을 약화시키지만, 데이터 거버넌스와 LLM 선택 판단이라는 새로운 내부 책임 영역을 만든다.
- 에이전트가 고객 데이터를 참조하고 외부 LLM에 전달하는 흐름이 생기면, PIPA의 위탁 처리 조항 검토가 선행되어야 한다. 이 검토를 생략하고 빠르게 구축하는 것이 가장 흔한 실수다.
