Salesforce가 Formula 1 팀 VCARB와 Agentforce 360(에이전트포스 360) 파트너십을 발표했다. 팬 인게이지먼트 자동화라는 표면적 사용 사례 뒤에는 더 구조적인 신호가 있다. AI 에이전트 SI 재편이 스포츠 산업에서 먼저 가시화되고 있다는 점이다. 한국 대기업 CIO 입장에서 이 사례가 중요한 이유는 팬 서비스 때문이 아니라, 기존 SI 파트너 의존 구조가 AI 에이전트 레이어에서 어떻게 균열을 일으키는지를 보여주기 때문이다.
VCARB 사례가 드러내는 아키텍처 전환점
VCARB의 Agentforce 360 배포는 단순한 챗봇 고도화가 아니다. Atlas Reasoning Engine(추론 엔진)을 중심으로 Topics(범위 정의), Actions(도구 실행), Instructions(행동 규칙)가 조합된 에이전트 레이어가 CRM 위에 올라가는 구조다. 이 구조에서 핵심은 에이전트가 Data Cloud의 Unified Individual(통합 개인 프로필)을 실시간으로 참조하면서 팬별 맥락을 유지한다는 점이다.
기술적으로 보면, Data Streams로 수집된 팬 행동 데이터가 Identity Resolution ruleset을 거쳐 Unified Individual로 병합되고, Calculated Insights가 프로필 단위 지표를 사전 계산한다. Agentforce는 이 Data Graph를 조회해 추론 컨텍스트를 구성한다. 전통적인 SI 방식이라면 이 파이프라인 각 단계마다 별도 프로젝트, 별도 계약, 별도 팀이 붙는다.
문제는 이 아키텍처가 단계별 SI 납품 모델과 근본적으로 맞지 않는다는 데 있다.
한국 SI 구조가 AI 에이전트와 충돌하는 지점
한국 대기업의 IT 조달 구조는 대형 SI가 플랫폼 통합을 책임지고, 하위 협력사가 기능 단위 개발을 담당하는 계층형 모델이다. 이 모델은 요구사항이 명확하고 납품 범위가 고정될 때 효율적이다. 그러나 AI 에이전트는 이 전제를 무너뜨린다.
Agentforce의 Topics와 Actions는 비즈니스 로직이 에이전트 설정 레이어에 직접 인코딩된다. 기존 SI 방식에서는 비즈니스 로직이 Java 코드나 ABAP 모듈 안에 있었고, SI가 그 코드를 소유했다. AI 에이전트 구조에서는 Prompt Builder 템플릿, Instructions 문자열, Flow 오케스트레이션이 로직의 실체다. 이것을 누가 설계하고 유지보수하느냐가 SI 파트너 관계의 핵심 권력 구조를 바꾼다.
구체적으로 세 가지 충돌이 발생한다.
- 납품 단위 불일치: SI는 기능 완성을 납품 기준으로 삼는다. 에이전트는 지속적 튜닝이 필요하다. Agentforce Testing Center에서 측정하는 응답 품질 지표는 프로젝트 종료 후에도 계속 관리해야 한다.
- 역량 공백: 대형 SI의 Salesforce 역량은 Sales Cloud, Service Cloud 구현에 집중되어 있다. Data Cloud의 Identity Resolution ruleset 설계나 Atlas Reasoning Engine의 추론 경로 최적화는 다른 전문성이다.
- 책임 경계 모호성: 에이전트가 잘못된 응답을 생성했을 때, 그것이 Data Graph 설계 문제인지, Prompt Builder 템플릿 문제인지, Instructions 정의 문제인지 SI 계약 구조로는 책임 소재가 불분명하다.
대기업 CIO가 직면하는 실질적 결정
AI 에이전트 SI 재편이 진행되는 방식은 빅뱅 교체가 아니다. 기존 SI 계약이 유지되는 동안 에이전트 레이어만 별도 트랙으로 진행되다가, 어느 시점에 두 트랙이 충돌하는 패턴이 일반적이다.
접점 3,000개 이상의 멀티채널 환경을 운영하는 대기업에서 이 충돌은 보통 18개월 안에 가시화된다. Data Cloud 실시간 활성화의 일반적 지연이 2~5분 수준이라면, 에이전트가 참조하는 프로필 데이터의 신선도 문제가 SI가 관리하는 레거시 데이터 파이프라인과 직접 충돌한다.
CIO가 지금 결정해야 할 것은 에이전트 도입 여부가 아니다. 에이전트 레이어의 설계 권한과 운영 책임을 기존 SI 구조 안에 둘 것인지, 별도 역량으로 내재화할 것인지다. 이 결정을 미루면 2~3년 후 두 구조가 병렬로 존재하면서 유지보수 비용이 중복되는 상황이 된다.
개인정보 보호법(PIPA) 관점에서도 이 결정은 중요하다. Agentforce가 Data Cloud의 Unified Individual을 참조할 때, 그 데이터에 포함된 개인정보의 처리 위탁 관계가 SI 계약 구조와 맞아야 한다. 에이전트 레이어를 외부 SI가 운영하면 위탁 처리 계약과 데이터 접근 범위를 별도로 정의해야 하고, 이것이 기존 SI 계약에 명시되지 않은 경우가 대부분이다.
SI 파트너 생태계 재편의 실제 방향
VCARB 사례에서 주목할 점은 Salesforce가 직접 구현 파트너로 참여했다는 구조다. 대형 SI를 통한 간접 납품이 아니라, 플랫폼 벤더가 아키텍처 설계에 직접 개입하는 방식이다. 이 패턴은 AI 에이전트 도입 초기에 반복적으로 나타난다.
한국 시장에서 이것이 의미하는 바는 명확하다. 기존 SI 파트너가 Agentforce 아키텍처 역량을 빠르게 확보하지 못하면, 에이전트 레이어 프로젝트는 SI를 우회해 Salesforce 직접 서비스나 전문 부티크로 이동한다. 이미 금융권과 유통 대기업에서 이 패턴이 시작되고 있다.
SI 파트너 입장에서 생존 경로는 두 가지다. Data Cloud 파이프라인 설계와 에이전트 오케스트레이션을 핵심 역량으로 전환하거나, 레거시 시스템 통합 레이어에 집중하면서 에이전트 레이어는 전문 파트너에게 넘기는 협업 구조를 만드는 것이다. 중간 지점, 즉 에이전트 역량도 없이 에이전트 프로젝트를 수주하는 방식은 납품 품질 문제로 이어지고 결국 고객 신뢰를 잃는다.
Agentforce의 프로덕션 준비도를 평가하는 구체적 기준은 SI 파트너 선정 기준으로도 그대로 적용된다. 에이전트 Topics 설계 능력, Agentforce Testing Center 활용 경험, Data Cloud Identity Resolution 구성 이력이 없는 파트너에게 에이전트 레이어를 맡기는 것은 구조적 리스크다.
Agentforce 360 아키텍처 설계의 구체적 접근 방식은 Agentforce 아키텍처 서비스에서 확인할 수 있다.
핵심 정리
- AI 에이전트 SI 재편은 빅뱅 교체가 아니라 에이전트 레이어가 기존 SI 구조와 병렬로 진행되다 충돌하는 패턴으로 진행된다. 접점 3,000개 이상 환경에서 이 충돌은 도입 후 18개월 안에 가시화된다.
- Agentforce의 Topics, Actions, Instructions는 비즈니스 로직의 소재지를 코드 레이어에서 에이전트 설정 레이어로 이동시킨다. 이것이 SI 파트너의 기술 권력 구조를 바꾸는 핵심 메커니즘이다.
- 개인정보 보호법(PIPA) 준수를 위해 에이전트가 Data Cloud Unified Individual을 참조하는 구조에서 위탁 처리 계약과 데이터 접근 범위를 기존 SI 계약과 별도로 정의해야 한다.
- Data Cloud Identity Resolution ruleset 설계와 Atlas Reasoning Engine 추론 경로 최적화는 기존 Sales Cloud·Service Cloud 구현 역량과 다른 전문성이다. 이 역량 공백이 SI 파트너 재편의 실질적 원인이다.
- CIO가 지금 결정해야 할 것은 에이전트 레이어의 설계 권한과 운영 책임을 기존 SI 구조 안에 둘지, 별도 역량으로 내재화할지다. 이 결정을 2년 미루면 중복 유지보수 비용과 책임 경계 분쟁이 동시에 발생한다.
