Summer '26 멀티에이전트 오케스트레이션과 에이전트 자동화 거버넌스

Summer ‘26 릴리스에서 Salesforce가 공개한 멀티에이전트 오케스트레이션 기능은 단순한 기능 추가가 아니다. 한국 대기업이 수십 년간 유지해온 SI 의존 자동화 구조에 처음으로 실질적인 대안이 생겼다는 신호다. 문제는 기술이 준비됐느냐가 아니라, 에이전트 자동화 거버넌스 체계 없이 이 기능을 도입하면 SI 의존도가 줄어드는 게 아니라 오히려 통제 불가능한 자동화 부채로 전환된다는 점이다.

Summer ‘26 멀티에이전트 오케스트레이션이 실제로 바꾸는 것

6월 15일 GA(General Availability) 예정인 멀티에이전트 오케스트레이션은 Atlas Reasoning Engine(추론 계층) 위에서 여러 Agentforce 에이전트가 서로 작업을 위임하고 결과를 집계하는 구조를 지원한다. 이전까지 단일 에이전트는 Topics(범위)와 Actions(도구) 조합으로 단일 도메인 내 작업만 처리할 수 있었다. 오케스트레이션이 추가되면 “영업 에이전트가 재고 확인 에이전트에게 쿼리를 위임하고, 그 결과를 받아 계약 초안 에이전트에게 전달하는” 흐름이 플랫폼 네이티브로 구현된다.

한국 대기업 맥락에서 이게 중요한 이유는 명확하다. 지금까지 이런 크로스 도메인 자동화는 SI가 커스텀 미들웨어나 MuleSoft 통합 레이어를 별도로 구축해야 가능했다. 유지보수 계약이 따라붙고, 변경 요청마다 품의가 올라가고, 실제 로직은 SI 인력 머릿속에 남아 있는 구조다. 멀티에이전트 오케스트레이션은 이 미들웨어 레이어의 상당 부분을 Agentforce 플랫폼 안으로 흡수한다.

Slack-first 워크플로우 통합도 같은 맥락이다. 에이전트가 Slack 채널에서 직접 승인 요청을 보내고, 담당자 응답을 트리거로 다음 에이전트 액션을 실행하는 패턴은 기존에 Flow 오케스트레이션과 외부 알림 시스템을 조합해야 했던 작업을 단순화한다. 사업부 15개 이상이 각각 다른 승인 프로세스를 운영하는 대기업에서 이 패턴의 표준화 가치는 상당하다.

한국 SI 의존 구조의 실제 취약점

한국 대기업의 Salesforce 운영 구조를 보면 공통 패턴이 있다. 초기 구축은 대형 SI가 담당하고, 이후 운영은 SI 유지보수 계약으로 이어진다. 문제는 이 구조가 플랫폼 역량을 내재화할 인센티브를 조직 내부에서 제거한다는 점이다. CIO 입장에서는 SI가 있으니 내부 Salesforce 전문가를 키울 이유가 없고, SI 입장에서는 고객이 자립할수록 계약이 줄어드니 지식 이전에 적극적이지 않다.

멀티에이전트 오케스트레이션이 이 구조를 흔드는 방식은 두 가지다. 첫째, 자동화 로직이 SI 커스텀 코드가 아니라 Agentforce Topics·Actions·Instructions 조합으로 선언적으로 정의된다. 이는 로직이 플랫폼 안에 가시화된다는 의미다. 둘째, Agentforce Testing Center를 통한 에이전트 행동 검증이 표준화되면서, SI가 “블랙박스 테스트”로 유지하던 자동화 로직을 조직이 직접 감사할 수 있게 된다.

그러나 이 전환이 자동으로 SI 의존도를 낮추지는 않는다. 오히려 에이전트 자동화 거버넌스 체계 없이 멀티에이전트를 도입하면, 누가 어떤 에이전트를 승인했는지, 어떤 데이터에 접근하는지, 실패 시 책임 소재가 어디인지 불명확한 상태로 자동화가 확산된다. SI 의존도가 줄어드는 게 아니라 통제 주체가 없는 자동화 스프롤(sprawl)로 전환되는 것이다.

에이전트 자동화 거버넌스 설계의 핵심 구조

멀티에이전트 환경에서 에이전트 자동화 거버넌스는 세 개 레이어로 설계해야 한다.

접근 제어 레이어: 에이전트가 호출할 수 있는 Actions의 범위를 Salesforce Permission Set과 Named Credentials 조합으로 제한한다. 멀티에이전트 오케스트레이션에서 에이전트 간 위임이 발생할 때, 위임받은 에이전트가 위임한 에이전트보다 더 넓은 권한을 갖지 못하도록 권한 상속 규칙을 명시적으로 설계해야 한다. 이를 설계하지 않으면 낮은 권한의 에이전트가 높은 권한 에이전트를 경유해 데이터에 접근하는 권한 에스컬레이션 경로가 생긴다.

감사 추적 레이어: Platform Events를 활용해 에이전트 액션 실행 이벤트를 실시간으로 기록한다. 멀티에이전트 체인에서 어떤 에이전트가 어떤 순서로 실행됐는지, 각 단계에서 어떤 데이터를 읽고 썼는지 추적 가능해야 한다. 개인정보 보호법(PIPA) 관점에서 개인정보가 포함된 Data Cloud DMO(Data Model Object)에 에이전트가 접근했다면, 그 접근 목적과 처리 근거가 감사 로그에 남아야 한다. PIPA 제29조의 안전성 확보 의무는 자동화 에이전트에도 동일하게 적용된다.

변경 관리 레이어: 에이전트 Topics·Instructions 변경을 Salesforce DevOps Center 또는 외부 CI/CD 파이프라인을 통해 버전 관리한다. 멀티에이전트 오케스트레이션에서 하나의 에이전트 Instructions 변경이 전체 체인 동작에 미치는 영향을 Agentforce Testing Center에서 회귀 테스트로 검증하는 프로세스가 필수다. 이 레이어가 없으면 에이전트 행동이 언제, 왜 바뀌었는지 추적이 불가능해진다.

Agentforce 프로덕션 준비도 평가에서 다룬 것처럼, 에이전트를 프로덕션에 올리기 전 거버넌스 체계 검증은 기술 준비도 점검만큼 중요하다.

Tableau MCP와 실시간 데이터 활성화가 거버넌스에 미치는 영향

Summer ‘26에서 함께 발표된 Tableau MCP(Model Context Protocol) 통합과 Data Cloud 실시간 활성화 개선은 멀티에이전트 거버넌스 복잡도를 높인다.

Tableau MCP는 에이전트가 Tableau 데이터 소스를 직접 쿼리할 수 있게 한다. 이는 에이전트가 접근 가능한 데이터 범위가 CRM 데이터를 넘어 분석 레이어까지 확장된다는 의미다. 기업 내 Tableau 대시보드에는 임원 보고용 재무 데이터, 인사 데이터, 공급망 데이터가 혼재하는 경우가 많다. 에이전트의 Tableau 접근 권한을 Row-Level Security와 연동해 설계하지 않으면, 에이전트가 사용자 권한 범위를 초과하는 데이터를 조회하는 경로가 생긴다.

Data Cloud 실시간 활성화의 경우, 접점 3,000개 이상 규모의 엔터프라이즈 조직에서 Data Cloud 실시간 활성화의 일반적 지연은 2~5분이다. Summer ‘26에서 이 지연이 단축되면 에이전트가 더 최신 데이터를 기반으로 액션을 실행하게 된다. 이는 정확도 향상이지만, 동시에 에이전트 액션의 실시간성이 높아질수록 잘못된 액션의 파급 속도도 빨라진다는 의미다. Data Cloud Identity Resolution의 Unified Individual 프로필을 에이전트가 실시간으로 참조할 때, 매칭 ruleset 오류가 에이전트 액션 오류로 즉시 전파되는 경로를 차단하는 회로 차단기(circuit breaker) 패턴이 필요하다.

SI 의존 탈피의 현실적 경로

Summer ‘26 기능이 아무리 강력해도, 한국 대기업이 SI 의존 구조에서 벗어나려면 기술 전환보다 조직 전환이 선행되어야 한다. 구체적으로는 세 가지가 필요하다.

내부 플랫폼 오너십 확립이 첫 번째다. 에이전트 Topics·Actions 설계를 SI에 위임하는 순간, 로직의 소유권이 다시 외부로 넘어간다. 내부 Salesforce 아키텍트 또는 플랫폼 팀이 에이전트 설계의 최종 승인권을 가져야 한다. 컨설턴트 200명, 사업부 15개 규모의 Center of Excellence 조율 경험이 있는 조직에서도 에이전트 거버넌스 소유권이 불명확하면 사업부별 에이전트 스프롤이 6개월 안에 발생한다.

두 번째는 거버넌스 선행 설계다. 에이전트를 먼저 만들고 거버넌스를 나중에 붙이는 순서는 작동하지 않는다. 멀티에이전트 오케스트레이션 도입 전에 접근 제어·감사 추적·변경 관리 세 레이어를 설계하고, 첫 번째 에이전트 배포 시점부터 이 체계 안에서 운영해야 한다.

세 번째는 SI 역할 재정의다. SI를 완전히 배제하는 것이 목표가 아니다. SI의 역할을 “자동화 로직 구축 및 유지”에서 “플랫폼 역량 내재화 지원 및 복잡한 통합 레이어 구축”으로 전환하는 것이다. MuleSoft 기반 외부 시스템 통합처럼 SI가 실질적 가치를 제공하는 영역은 여전히 존재한다. 에이전트 로직 자체를 SI 블랙박스로 두는 구조만 해체하면 된다.

Salesforce 거버넌스와 SI 의존도 글에서 다룬 거버넌스 프레임워크는 멀티에이전트 환경에서도 동일하게 적용된다. 플랫폼이 바뀌어도 소유권 구조 문제는 반복된다.

에이전트 자동화 거버넌스 체계를 먼저 설계하고 싶다면 Agentforce 아키텍처 서비스에서 구체적인 접근 방식을 확인할 수 있다.

핵심 정리

• 멀티에이전트 오케스트레이션의 아키텍처적 의미: Agentforce Summer ‘26의 멀티에이전트 오케스트레이션은 크로스 도메인 자동화를 위해 SI가 구축하던 커스텀 미들웨어 레이어를 플랫폼 네이티브로 대체한다. 자동화 로직이 플랫폼 안에 선언적으로 정의되면서 가시성과 감사 가능성이 높아진다.

• 에이전트 자동화 거버넌스 없는 도입의 위험: 거버넌스 체계 없이 멀티에이전트를 도입하면 SI 의존도가 줄어드는 것이 아니라, 통제 주체 없는 자동화 스프롤로 전환된다. 권한 에스컬레이션 경로와 감사 불가능한 에이전트 체인이 생긴다.

• PIPA 적용 범위: 개인정보가 포함된 Data Cloud DMO에 에이전트가 접근하는 경우, PIPA 제29조 안전성 확보 의무가 적용된다. 에이전트 액션 실행 이벤트의 감사 로그 보존은 선택이 아니라 규제 요건이다.

• Tableau MCP 권한 설계: Summer ‘26 Tableau MCP 통합은 에이전트 접근 범위를 분석 레이어까지 확장한다. Row-Level Security와 연동하지 않으면 에이전트가 사용자 권한 범위를 초과하는 데이터를 조회하는 경로가 생긴다.

• SI 역할 재정의의 방향: SI 완전 배제가 아니라 역할 전환이 현실적 경로다. 에이전트 로직 소유권을 내부로 가져오고, SI는 MuleSoft 기반 외부 통합처럼 실질적 가치가 있는 영역에 집중하도록 계약 구조를 재설계해야 한다.