Salesforce Summer ‘26 릴리스의 핵심은 기능 추가가 아니다. 에이전트 자동화 아키텍처의 제어권이 SI에서 기업 내부로 이동하는 구조적 전환점이다. 한국 대기업 CIO·CTO가 이 릴리스를 단순한 업데이트로 읽는다면, 3년 후 SI 계약 협상 테이블에서 불리한 위치에 서게 된다.
한국 대기업의 SI 의존 구조가 만들어진 이유
한국 엔터프라이즈 Salesforce 도입 패턴은 일본이나 유럽과 다르다. 대부분의 조직에서 Salesforce 설정·커스터마이징·운영 전반을 SI 파트너가 장기 유지보수 계약으로 담당한다. 이 구조가 형성된 데는 이유가 있다. Salesforce의 선언적 도구(Flow, Apex, 커스텀 메타데이터)는 내부 인력이 직접 다루기에 학습 곡선이 가파르고, 비즈니스 요구사항이 바뀔 때마다 개발 요청을 SI에 넣는 것이 빠르게 느껴졌다.
결과적으로 많은 조직이 Salesforce 플랫폼 위에서 SI가 만든 커스텀 레이어를 운영하는 구조가 됐다. 플랫폼 업그레이드 때마다 SI 검증이 필요하고, 새 기능을 활성화하려면 별도 품의와 프로젝트 착수가 필요하다. 이 구조에서 Agentforce(에이전트포스) 도입은 또 하나의 SI 프로젝트가 된다.
Summer ‘26은 이 방정식을 바꾼다.
Summer ‘26 멀티에이전트 오케스트레이션의 아키텍처적 의미
6월 15일 GA(일반 공개)로 전환된 멀티에이전트 오케스트레이션은 단일 에이전트가 처리하던 작업을 여러 전문 에이전트가 협력해 처리하는 구조다. Atlas Reasoning Engine(추론 계층)이 작업을 분해하고, 각 에이전트에 Topics(범위)와 Actions(도구)를 할당하며, 결과를 통합한다.
기술적으로 중요한 변화는 세 가지다.
첫째, 에이전트 간 핸드오프(handoff) 로직이 코드가 아니라 Instructions(행동 지침) 레이어에서 정의된다. 기존에는 복잡한 업무 흐름을 Apex나 Flow로 구현해야 했고, 이 코드를 SI가 소유했다. 이제 오케스트레이션 로직은 자연어에 가까운 Instructions로 표현되며, 내부 비즈니스 담당자가 직접 수정할 수 있는 영역이 넓어진다.
둘째, IT Service 도메인 팩(Domain Pack)이 강화됐다. 서비스 요청 분류, 에스컬레이션 라우팅, 지식 기사 생성 같은 반복 업무가 사전 구성된 에이전트 템플릿으로 제공된다. 한국 대기업의 IT 헬프데스크나 고객 서비스 센터에서 SI가 수개월에 걸쳐 구현하던 로직의 상당 부분이 플랫폼 기본 기능으로 흡수된다.
셋째, Security Mesh(보안 메시) 출시다. 에이전트가 외부 시스템이나 데이터에 접근할 때 적용되는 정책 레이어로, 개인정보 보호법(PIPA) 준수 관점에서 중요하다. 에이전트가 고객 데이터를 처리하는 과정에서 접근 제어와 감사 로그가 플랫폼 수준에서 관리된다. 이전에는 이 보안 레이어를 SI가 커스텀으로 구현했고, 그 구현체가 SI 의존도를 높이는 핵심 요소 중 하나였다.
에이전트 자동화 아키텍처를 내재화하는 실질적 경로
에이전트 자동화 아키텍처의 내재화는 “SI를 끊겠다”는 선언이 아니다. SI가 담당하던 영역 중 어느 부분이 플랫폼 기능으로 대체 가능한지를 정확히 파악하고, 내부 역량을 그 경계에 맞게 재배치하는 작업이다.
실용적인 접근은 다음 세 단계로 구성된다.
1단계: 에이전트 소유권 지도 작성. 현재 운영 중인 자동화 로직(Flow, Apex, 외부 연동)을 에이전트로 전환 가능한 항목과 그렇지 않은 항목으로 분류한다. IT Service 도메인 팩이 커버하는 영역은 SI 재개발 없이 전환 가능한 1순위 후보다. 이 분류 작업 자체를 SI에 맡기면 결과가 왜곡될 수 있다.
2단계: Prompt Builder와 Instructions 역량 내재화. Agentforce의 Topics와 Instructions는 Salesforce 관리자 수준의 역량으로 운영 가능하도록 설계됐다. Prompt Builder(프롬프트 빌더)의 Flex 템플릿을 활용하면 에이전트 응답 로직을 내부에서 직접 조정할 수 있다. 이 역량을 내부 CoE(Center of Excellence)에 구축하는 것이 SI 의존도 감소의 실질적 출발점이다.
3단계: Data Cloud 연동 범위 결정. 실시간 오퍼 관리(Real-time Offer Management)는 Data Cloud의 Data Streams와 Calculated Insights(계산된 인사이트)를 에이전트 컨텍스트로 연결하는 구조다. 이 연동을 SI가 커스텀으로 구현하면 Data Cloud 업그레이드마다 재검증이 필요해진다. 플랫폼 네이티브 연동 방식을 선택하면 이 유지보수 부담이 사라진다. Data Cloud 아키텍처 설계 원칙에 대해서는 Data Cloud Identity Resolution이 실제로 작동하는 방식에서 더 자세히 다뤘다.
대부분의 조직이 잘못하는 지점
Summer ‘26 릴리스를 받아서 SI에 “이걸 구현해 달라”고 요청하는 것이 가장 흔한 실수다. 멀티에이전트 오케스트레이션의 가치는 구현 자체가 아니라, 구현 이후 비즈니스 팀이 직접 에이전트 로직을 조정할 수 있는 구조를 만드는 데 있다. SI가 오케스트레이션 레이어를 커스텀으로 구현하면, 그 레이어는 다시 SI 의존 자산이 된다.
두 번째 함정은 Security Mesh를 보안팀 과제로만 보는 것이다. Security Mesh는 에이전트가 어떤 데이터에 접근할 수 있는지를 정의하는 정책 레이어다. 이 정책이 잘못 설계되면 에이전트가 PIPA 위반 방식으로 고객 데이터를 처리하게 된다. 보안팀과 데이터 거버넌스 담당자가 에이전트 설계 초기부터 참여해야 한다.
세 번째는 Agentforce Testing Center(테스트 및 검증 센터)를 QA 단계에서만 쓰는 패턴이다. 멀티에이전트 환경에서는 에이전트 간 핸드오프 시나리오가 예상치 못한 방식으로 실패한다. Testing Center를 설계 단계부터 활용해 핸드오프 경계에서의 실패 모드를 사전에 식별해야 한다. 실제로 에이전트 수가 3개를 넘어가면 핸드오프 실패 시나리오가 기하급수적으로 늘어나고, 이를 운영 환경에서 처음 발견하면 복구 비용이 크다.
보증 자동화(Warranty Automation) 기능도 주목할 필요가 있다. 제조·유통 업종의 한국 대기업에서 보증 처리 프로세스는 ERP와 Salesforce 사이의 복잡한 연동으로 구현되는 경우가 많다. Summer ‘26의 보증 자동화 에이전트는 이 연동 복잡도를 줄이는 방향으로 설계됐다. 단, MuleSoft(뮬소프트) 연동 레이어가 이미 있는 조직은 에이전트와 기존 연동 레이어의 책임 경계를 명확히 정의해야 한다. 두 레이어가 동일한 데이터를 중복 처리하는 구조가 되면 오히려 복잡도가 증가한다.
에이전트 자동화 아키텍처를 프로덕션 환경에 안정적으로 배포하는 체크리스트가 필요하다면 Agentforce 프로덕션 준비도 점검을 참고할 수 있다.
지금 결정이 3년 후 SI 계약을 결정한다
멀티에이전트 오케스트레이션이 GA로 전환된 지금, 한국 대기업 CIO·CTO 앞에는 두 가지 경로가 있다. 하나는 이번 릴리스도 SI 프로젝트로 소화하는 것이고, 다른 하나는 에이전트 자동화 아키텍처의 소유권을 내부로 가져오는 구조를 설계하는 것이다.
첫 번째 경로를 선택하면 2~3년 후 에이전트 운영 로직 전체가 SI 자산으로 묶인다. 에이전트를 수정하거나 새 도메인으로 확장하려면 다시 SI 프로젝트가 필요해진다. 플랫폼이 제공하는 자율성이 SI 계약 구조에 의해 상쇄되는 역설이 발생한다.
두 번째 경로는 초기에 더 많은 내부 투자를 요구한다. CoE 구성, Prompt Builder와 Instructions 역량 내재화, Security Mesh 정책 설계를 내부에서 주도해야 한다. 그러나 이 투자는 SI 유지보수 계약 갱신 때마다 협상력으로 돌아온다.
Summer ‘26은 기술적 전환점이 아니라 거버넌스 전환점이다. 에이전트 자동화 아키텍처의 제어권을 누가 갖느냐가 향후 Salesforce 플랫폼 투자 효율을 결정한다. 이 결정을 지금 내리지 않으면, 다음 릴리스에서도 같은 선택지 앞에 서게 된다. 단지 전환 비용이 더 높아진 상태로.
Agentforce 아키텍처 설계와 내재화 전략에 대한 구체적인 접근은 Agentforce 아키텍처 서비스에서 확인할 수 있다.
핵심 정리
- Summer ‘26의 멀티에이전트 오케스트레이션은 에이전트 간 핸드오프 로직을 코드가 아닌 Instructions 레이어로 이동시켜, 내부 비즈니스 팀이 직접 수정 가능한 영역을 확장한다.
- IT Service 도메인 팩 강화로 서비스 요청 분류·에스컬레이션·지식 기사 생성 같은 반복 업무가 플랫폼 기본 기능으로 흡수된다. SI가 수개월 프로젝트로 구현하던 영역이다.
- Security Mesh는 에이전트의 데이터 접근 정책을 플랫폼 수준에서 관리한다. PIPA 준수 관점에서 에이전트 설계 초기부터 보안팀과 데이터 거버넌스 담당자가 참여해야 한다.
- SI가 멀티에이전트 오케스트레이션 레이어를 커스텀으로 구현하면, 그 레이어는 다시 SI 의존 자산이 된다. 플랫폼 네이티브 구현 방식을 선택하는 것이 장기 협상력을 유지하는 유일한 경로다.
- 에이전트 수가 3개를 넘어가면 핸드오프 실패 시나리오가 기하급수적으로 증가한다. Agentforce Testing Center를 설계 단계부터 활용해 운영 환경 배포 전에 실패 모드를 식별해야 한다.
