Salesforce가 6월 24일 Agentforce Commerce를 공식 발표했습니다. Shopper Agent는 즉시 사용 가능하고, B2B 채널에는 WhatsApp·SMS 기반 Buyer Agent가, 카탈로그 관리에는 Merchant Agent가 투입됩니다. Cimulate 인수로 확보한 Agentic Commerce Search까지 결합되면서 헤드리스 아키텍처와 통합 재고 오케스트레이션이 표준 스펙으로 자리 잡았습니다. 그런데 이 발표를 국내 기업 관점에서 읽으면 질문이 하나로 좁혀집니다. 결국 이 기능들을 실제로 붙이고 운영할 수 있는가, 그리고 그 역할은 누가 맡는가입니다. 대부분의 국내 대기업 Salesforce 조직에서 이 역할은 내부 IT팀이 아니라 SI 파트너에게 위임되어 있고, 바로 여기서 Salesforce SI 통합 역량의 격차가 드러납니다.
Agentforce Commerce는 기능 자체보다 통합 표면적이 문제입니다. Shopper Agent 하나만 해도 Commerce Cloud, Data Cloud, Service Cloud 데이터가 실시간으로 맞물려야 하고, Merchant Agent는 ERP·PIM·재고 시스템과의 양방향 동기화를 전제로 설계되어 있습니다. 이런 구조에서 SI가 표준화된 통합 패턴 없이 프로젝트마다 임기응변으로 붙이면, 초기 데모는 성공해도 6개월 뒤 운영 단계에서 반드시 무너집니다.
국내 SI 생태계의 구조적 문제는 무엇인가
한국 Salesforce 시장은 소수의 대형 SI와 다수의 부티크 파트너로 나뉘어 있습니다. 대형 SI는 인력 규모는 크지만 Agentforce처럼 릴리즈 주기가 빠른 신기능에 대한 내부 전문성 축적 속도가 느립니다. 프로젝트 단위로 컨설턴트를 재배치하는 조직 구조상, Agentforce Commerce 같은 신규 스택을 다뤄본 인력이 다음 프로젝트에 그대로 투입된다는 보장이 없습니다.
더 근본적인 문제는 기술 표준화의 부재입니다. 같은 Agentforce Commerce 구축이라도 SI A가 채택한 Data Streams 설계와 SI B가 채택한 방식이 전혀 다른 경우가 흔합니다. Identity Resolution ruleset을 어떻게 구성하는지, Data Graphs를 어느 단위로 구체화하는지에 대한 사내 표준이 없는 상태에서 매 프로젝트가 처음부터 다시 설계됩니다. 이는 단순히 비효율의 문제가 아닙니다. 3~5년 뒤 조직이 SI를 교체하거나 내재화를 시도할 때, 문서화되지 않은 개별 설계 방식이 마이그레이션 비용을 기하급수적으로 키웁니다.
Agentforce Commerce의 OpenAI 채널 통합, 향후 예정된 Google 채널 확장은 이 문제를 더 심화시킵니다. 외부 LLM 채널과의 연동은 프롬프트 설계, 응답 검증, 실패 시 폴백 로직까지 아키텍처 결정이 늘어난다는 뜻입니다. SI가 이 결정들을 프로젝트별 임기응변으로 처리하면, 커머스 에이전트가 잘못된 재고 정보를 고객에게 응답하거나 개인정보를 포함한 데이터가 외부 채널로 유출되는 시나리오가 현실화됩니다. 실제로 접점 3,000개 이상의 리테일 조직에서 멀티클라우드 통합을 설계할 때 가장 먼저 드러나는 리스크가 바로 이 표준화 부재입니다.
Salesforce SI 통합 역량을 검증하는 프레임워크
CIO가 SI를 선정하거나 기존 SI의 역량을 재평가할 때 필요한 것은 감으로 하는 판단이 아니라 검증 가능한 체크리스트입니다. Agentforce Commerce 도입 맥락에서는 다음 네 가지 축이 핵심입니다.
첫째, Data Cloud 아키텍처 표준화 여부입니다. Shopper Agent와 Merchant Agent가 참조하는 DMO 구조, Data Streams 매핑 규칙, Calculated Insights 정의 방식이 문서화되어 있고 다음 프로젝트에도 재사용 가능한지 확인해야 합니다. SI가 매 프로젝트마다 처음부터 설계한다면, 이는 표준화가 아니라 일회성 커스터마이징입니다.
둘째, Identity Resolution ruleset의 재현 가능성입니다. B2C Shopper와 B2B Buyer가 동일한 Unified Individual로 묶이는 로직은 업종별로 편차가 크지만, 최소한 규칙 설계 원칙과 검증 절차는 표준화되어야 합니다. 이 부분에 대한 구체적 매칭 전략은 Data Cloud Identity Resolution이 중복 고객 데이터를 처리하는 방식에서 다룬 아키텍처 패턴을 참고할 만합니다.
셋째, Atlas Reasoning Engine 기반 Topics·Actions 설계의 재사용성입니다. Merchant Agent의 카탈로그 관리 Action, Buyer Agent의 WhatsApp 응답 Instruction이 프로젝트마다 처음부터 재작성되는지, 아니면 검증된 템플릿 라이브러리에서 파생되는지가 SI 성숙도를 가르는 기준입니다.
넷째, External Services와 MuleSoft를 통한 외부 채널 통합 패턴입니다. OpenAI 채널 연동, ERP·PIM 연동에서 SI가 인증·오류 처리·재시도 로직을 표준 컴포넌트로 관리하는지, 아니면 매번 커스텀 코드를 새로 짜는지 확인해야 합니다. 이런 통합 아키텍처 결정의 무게는 Agentforce와 SI 파트너 선정에서 짚었던 문제의식과 정확히 맞닿아 있습니다.
이 네 가지 축을 실제 검증하려면 SI에게 과거 프로젝트의 설계 문서와 재사용 컴포넌트 목록을 요구하는 것이 가장 확실한 방법입니다. 말로 하는 역량 소개가 아니라 실물 아티팩트를 요구해야 품의 단계에서 근거로 쓸 수 있습니다.
PIPA 준수와 통합 아키텍처가 충돌하는 지점
Agentforce Commerce의 OpenAI 채널 통합은 한국 시장에서 특히 민감한 이슈를 하나 더 얹습니다. Shopper Agent가 고객 대화 맥락을 외부 LLM 채널로 전달하는 구조는 개인정보 보호법(PIPA) 상 위탁 처리와 국외 이전 이슈를 동시에 건드립니다. 국내 SI 대부분은 이 문제를 계약서 상 면책 조항으로 처리하려 하지만, 이는 근본적 해결책이 아닙니다.
실무적으로 필요한 것은 Data Cloud 단에서 PII 필드를 식별하고 마스킹하는 정책, 그리고 OpenAI 채널로 넘어가는 페이로드에서 개인정보가 최소화되도록 하는 Flow 기반 사전 처리 레이어입니다. 이 설계를 SI가 프로젝트 초기 단계부터 명시적으로 제안하는지 여부가 그 SI의 진짜 역량을 보여줍니다. 반대로 이 이슈를 계약 후반부에 언급하거나 아예 언급하지 않는 SI는, Agentforce Commerce 프로젝트가 오픈된 이후에야 이 문제를 발견하게 될 가능성이 높습니다.
Merchant Agent의 B2B 카탈로그 관리 기능도 마찬가지입니다. 재고·가격 데이터가 여러 리전에 분산된 글로벌 기업이라면, 데이터가 어느 리전의 Data Cloud 인스턴스에 적재되고 어떤 경로로 동기화되는지 명확한 데이터 흐름도가 필요합니다. 이 흐름도 없이 계약이 체결되는 경우가 국내 SI 프로젝트에서 여전히 흔하며, 이는 나중에 감사나 ISMS 인증 과정에서 반드시 문제가 됩니다.
대부분의 조직이 놓치는 함정
가장 흔한 실수는 Agentforce Commerce의 신기능 목록에 매몰되어 통합 역량 검증을 건너뛰는 것입니다. Shopper Agent 데모가 인상적이라는 이유로 SI 선정 과정에서 기술 표준화 질문을 생략하는 CIO가 많습니다. 하지만 데모는 항상 이상적인 데이터 상태에서 진행됩니다. 실제 운영 환경의 레거시 데이터, 다중 채널 재고 불일치, 수년간 누적된 커스텀 오브젝트는 데모에 등장하지 않습니다.
두 번째 함정은 SI를 단일 벤더로 고정하는 계약 구조입니다. Agentforce Commerce처럼 릴리즈 주기가 빠른 제품군은 특정 SI의 초기 설계가 6개월 뒤 아키텍처 부채로 바뀔 위험이 큽니다. 계약 단계에서 아키텍처 문서화 의무, 지식 이전 조항, 표준 컴포넌트의 소유권을 명시하지 않으면 조직은 특정 SI에 종속됩니다. 이 종속은 단순 불편이 아니라 재계약 협상력 자체를 잃는 결과로 이어집니다.
세 번째 함정은 내부 거버넌스 체계 없이 SI에게 아키텍처 결정을 전적으로 위임하는 것입니다. Agentforce Testing Center를 통한 검증 프로세스, Prompt Builder 템플릿의 버전 관리, Topics·Actions 변경 이력 추적 같은 최소한의 거버넌스 체계는 내부 조직이 직접 소유해야 합니다. SI 의존도가 구조적으로 고착되면, 조직은 자체적인 판단 없이 SI의 제안을 그대로 승인하는 구조로 굳어집니다. 이런 거버넌스 공백이 어떻게 조직 전체의 리스크로 확산되는지는 Salesforce 거버넌스와 SI 의존도 문제에서 더 자세히 다루고 있습니다.
Agentforce Commerce 도입을 앞둔 조직이라면 SI 선정 이전에 내부적으로 아키텍처 원칙 문서를 먼저 만들어야 합니다. Data Cloud 표준, Identity Resolution 정책, PIPA 대응 프레임워크를 조직이 먼저 정의하고 SI에게 이를 준수하도록 요구하는 순서가 맞습니다. 이 순서가 뒤바뀌면 SI의 습관이 조직의 표준이 되어버립니다. 관련해서 Agentforce 아키텍처 설계 전반의 원칙은 Agentforce 아키텍처 서비스 페이지에서 다루는 접근 방식을 참고할 수 있습니다.
핵심 정리
- Agentforce Commerce는 Shopper·Buyer·Merchant 세 에이전트와 Cimulate 기반 Agentic Commerce Search를 결합해 통합 표면적을 크게 넓혔고, 이는 SI의 아키텍처 표준화 수준을 그대로 시험대에 올립니다.
- 국내 SI 생태계는 프로젝트 단위 인력 재배치 구조 때문에 Agentforce Commerce 같은 신규 스택에 대한 전문성 축적 속도가 느리고, Data Cloud·Identity Resolution 설계가 프로젝트마다 표준화 없이 반복 재설계되는 경우가 흔합니다.
- SI 역량 검증은 Data Cloud 표준화, Identity Resolution 재현성, Topics·Actions 재사용성, External Services 통합 패턴 네 가지 축으로 실물 아티팩트를 요구해 확인해야 합니다.
- OpenAI 채널 통합은 PIPA상 위탁 처리와 국외 이전 이슈를 동반하므로, PII 마스킹과 데이터 흐름도를 SI가 초기 단계부터 명시적으로 제안하는지가 핵심 판단 기준입니다.
- SI 선정 이전에 조직이 먼저 아키텍처 원칙과 거버넌스 체계를 정의해야 하며, 이 순서가 뒤바뀌면 Salesforce SI 통합의 방향을 SI가 아닌 조직이 주도할 기회를 영구히 잃게 됩니다.
