작성: Agentforce 제품팀(Pragya Anand , Moe Basi , Shiv Ramanna , Kyle Bransky )
1부: Agentforce 상호 운용성 아키텍처 선택 방법
상호 운용성에 대한 접근 방식을 정의하는 방법을 자세히 알아보세요.
그런 다음 구축 과정에서 참조 가이드로 활용할 수 있도록 2부를 다운로드하세요.
챕터 1 에이전트 설계: 단일 에이전트에서 멀티 에이전트 시스템으로
멀티 에이전트 시스템을 설계하기 전에 단일 에이전트가 작동하는 방식을 이해하는 것이 중요합니다. Agentforce 에이전트는 하위 에이전트 (이전에는 주제라고 함)로 구성됩니다. 하위 에이전트는 특정 도메인에 맞게 범위가 지정된 모듈식 구성 요소로, 각각 정의된 작업(예: 플로, Apex, 프롬프트)을 포함합니다.
각 Agentforce 에이전트는 자체 LLM 추론 루프를 실행하여 목표가 달성될 때까지 하위 에이전트 간에 작업을 위임하는 방식과 응답을 구성하는 방식을 오케스트레이션합니다. Agentforce 추론 엔진은 이 루프를 에이전트 스크립트 기반 결정성으로 확장하여 하위 에이전트 간의 명시적인 전환 및 순서를 추가하고, LLM의 결정에만 의존하는 대신 예측 가능하고 제어 가능한 동작을 보장합니다. LLM 추론과 결정적 스크립팅의 이러한 결합을 통해 비즈니스 워크플로를 구현할 수 있습니다. 단일 에이전트는 많은 작업을 처리할 수 있지만 복잡성이 증가하면 다음과 같은 한계에 부딪힙니다.
- 데이터 경계 제한: 서로 다른 Salesforce 조직 또는 시스템에 존재하는 데이터, 워크플로 및 권한에 액세스할 수 없습니다. 이는 단일 에이전트 설계로는 넘을 수 없는 아키텍처상의 한계입니다.
- 컨텍스트 과부하: LLM 추론 엔진의 컨텍스트가 지침, 작업 출력 및 대화 기록으로 가득 차면서 핵심 규칙을 무시하거나 주제를 혼동하기 시작합니다.
- 도메인 전문화 붕괴: 모든 분야의 전문가가 되려는 에이전트는 특정 하위 에이전트를 호출할 때 잘못된 로직을 적용합니다. 지침 블록이 클수록 정확도는 더 떨어집니다.
의사결정 프레임워크: 비즈니스 프로세스가 비교적 단순하고 단일 도메인 내에서 작동하며 하위 에이전트 전반에서 통합된 데이터 액세스가 필요한 경우 단일 에이전트를 사용하세요.
챕터 2 상호 운용성을 위한 일반적인 시나리오: 에이전트를 확장해야 하는 시점과 방법
상호 운용성 의사결정/기능 매트릭스
| 시나리오 | 단일 에이전트 | 멀티 에이전트(단일 조직) | 멀티 에이전트(여러 조직) | Agentforce MCP 클라이언트 |
아웃바운드 A2A | 인바운드 A2A | MCP 서버로서의 Agentforce |
|---|---|---|---|---|---|---|---|
| 주요 해결 문제 | 하나의 에이전트를 단순하고 독립적으로 유지 | 하나의 조직에서 여러 전문 에이전트 통합 | 여러 Salesforce 조직에 걸쳐 에이전트 통합 | Agentforce가 외부 기능을 도구로 사용할 수 있도록 함 | Agentforce가 외부 에이전트와 협업할 수 있도록 함 | 외부 에이전트가 전문가로서 Agentforce 에이전트를 호출할 수 있도록 함 | 외부 호스트가 표준화된 MCP를 통해 Agentforce를 호출할 수 있도록 함 |
| 일반적인 경계 | 단일 도메인/단일 Salesforce 조직 | 단일 Salesforce 조직 | 여러 Salesforce 조직 | Salesforce에서 외부 도구/시스템으로 연결 | Salesforce에서 외부 에이전트 플랫폼으로 연결 | 외부 플랫폼에서 Salesforce로 연결 | 외부 플랫폼에서 Salesforce로 연결 |
| 사용자의 주요 인터페이스 위치 | Agentforce | Agentforce | Agentforce | Agentforce | Agentforce | 외부 앱/에이전트 | 외부 앱/코파일럿/LLM 호스트 |
| 주요 오케스트레이터 | Agentforce | Agentforce 오케스트레이터/슈퍼 에이전트 | 의도적인 위임을 수행하는 Agentforce 네트워크 | Agentforce | 에이전트 간 공유/위임 | 외부 플랫폼 | 외부 플랫폼 |
| 가장 적합한 경우 | 공유 데이터 액세스를 사용하는 단순한 워크플로 | 하나의 Salesforce 조직에서 여러 도메인 에이전트에 연결되는 단일 진입점이 필요한 경우 | 여러 Salesforce 조직을 보유하고 데이터가 엄격하게 분리된 엔터프라이즈 | 외부 API, 검색, SaaS 작업, 워크플로에 액세스해야 하는 경우 | 추론/계획의 일부를 담당하는 외부 시스템에 위임해야 하는 경우 | 외부 포털/봇에서 심층적인 Salesforce 실행이 필요한 경우 | 외부 포털/봇에서 심층적인 Salesforce 실행이 필요한 경우 |
| 설정 작업 | 낮음: 빠르고 간단함 | 중간: 조정 필요 | 높음: 복잡한 설정 필요 | 중간: 도구 연결 필요 | 높음: 복잡한 파트너십 필요 | 높음: 심층적인 통합 필요 | 중간: 표준 설정 필요 |
| 보안 설정 | 간단한 권한 | 표준 권한 | 조직 간 로그인 설정이 복잡함 | 도구별 로그인 | 파트너 간 신뢰 | 앱-에이전트 간 신뢰 | 표준화된 허브 액세스 |
| 예시 | 서비스 에이전트가 자체 하위 에이전트로 사례 해결 | 슈퍼바이저 에이전트가 동일한 조직의 청구, 지원, 환불 에이전트에 작업 라우팅 | 국가/사업부별 조직을 별도로 운영하는 글로벌 엔터프라이즈 | Agentforce가 MCP를 통해 Jira, SharePoint, DB, 워크플로 엔진 호출 | Agentforce가 Google/Box/기타 외부 에이전트에 작업 위임 | 사용자 지정 포털이 Salesforce 워크플로를 실행하도록 Agentforce에 요청 | Microsoft Copilot 또는 ChatGPT가 MCP를 통해 Agentforce 기능 호출 |
| 장점 | 단순성 | 하나의 조직 내에서 통합된 진입점 제공 | 데이터를 통합하지 않고 조직 간 협업 가능 | 설정이 간편하며 Agentforce를 중앙 두뇌로 유지하면서 기능 확장 가능 | 플랫폼 간 에이전트의 네이티브 협업 | 외부 앱에 Salesforce 로직을 중복 구현하지 않고 재사용 가능 | 외부 앱에 Salesforce 로직을 중복 구현하지 않고 재사용 가능 |
| 가장 큰 제한 사항 | 경계에 빠르게 도달함 | 조직/시스템 경계를 넘을 수 없음 | 조직 간 ID/컨텍스트 관리가 복잡함 | MCP 도구의 과도한 증가 | 신뢰, 개인정보 보호, 기능 등록에 따른 오버헤드 | 외부 시스템에서 핸드오프/오케스트레이션을 관리해야 함 | Agentforce 내 여러 하위 에이전트에서 일관된 에이전트 기반 동작을 보장해야 함 |
| 기본 권장 사항 | 범위가 좁다면 여기에서 시작 | 문제가 여러 도메인에 걸쳐 있지만 동일한 조직에 있는 경우 사용 | 멀티 조직이 실제 요구 사항인 경우에만 사용 | 원격 대상이 기능/도구인 경우 기본적으로 사용 | 원격 대상이 실제 에이전트 파트너인 경우 사용 | 외부 앱이 주요 진입점이며 Agentforce의 전문 기능이 필요한 경우 사용 | 외부 플랫폼에서 표준화된 방식으로 Agentforce를 사용해야 하는 경우 사용 |
챕터 3 여러 Agentforce 에이전트 간 협업
단일 조직 멀티 에이전트 오케스트레이션
SOMA(단일 조직, 멀티 에이전트) 오케스트레이션을 사용하면 여러 전문 Agentforce 에이전트가 하나의 Salesforce 조직 내에서 원활하게 협업할 수 있습니다. 사용자가 서로 다른 에이전트와의 대화를 개별적으로 관리하도록 하는 대신, SOMA는 하나의 통합된 대화형 진입점 에이전트를 제공합니다. 백그라운드에서는 '슈퍼 에이전트' 또는 '오케스트레이터' 에이전트가 지능적으로 작업을 조정하고 전문 에이전트에 위임하여 각 작업을 가장 적합하게 처리할 수 있는 에이전트가 담당하도록 합니다.
의사결정 프레임워크: 단일 Salesforce(조직) 환경에서 운영되는 전문 에이전트에 대해 고객이 통합된 '진입점' 경험을 원하는 경우 SOMA를 사용하세요.
- 장점: 여러 전문 에이전트에 하나의 대화형 진입점을 제공하여 사용자 경험을 간소화합니다.
- 단점: 단일 Salesforce 조직에서 사용할 수 있는 데이터와 워크플로로 제한됩니다.
멀티 조직 멀티 에이전트 오케스트레이션
MOMA(멀티 조직 멀티 에이전트) 오케스트레이션은 단일 조직(SOMA) 모델에서 논리적으로 발전한 방식으로, 복잡한 데이터 통합 없이 여러 Salesforce 조직에서 통합된 에이전트 경험을 제공할 수 있도록 합니다. 이 아키텍처는 개방형 네트워크가 아닌 의도적인 위임을 기반으로 하며, 예측할 수 없는 연쇄 호출을 방지하기 위해 의도적으로 1단계 깊이의 제약 조건(에이전트 A>에이전트 B, 에이전트 A->B->C가 아님)을 적용합니다. 보안은 사용자 ID를 인식하는 실행 방식과 Data 360 One(DC1) 신뢰 경계 내에서의 운영을 통해 유지됩니다.
의사결정 프레임워크: 네이티브 Agentforce 네트워크에서 데이터 모델을 통합하지 않고 서로 다른 Salesforce 조직에 안전하게 작업을 위임해야 하는 경우 MOMA를 사용하세요.
- 장점: 엄격한 데이터 레지던시를 유지하면서 복잡한 엔터프라이즈 환경 전반에 통합된 에이전트 경험을 제공합니다.
- 단점: 여러 조직에서 사용자 ID를 매핑하고 조직 간에 컨텍스트를 공유하는 작업이 어려울 수 있습니다.
챕터 4 에이전트와 외부 시스템 간 협업 지원
MCP 클라이언트
모델 컨텍스트 프로토콜(MCP) 클라이언트를 사용하면 Agentforce 관리자가 외부 MCP 서버를 등록하여 빌더가 표준화된 방식으로 Agentforce 내에서 원격 도구, 리소스 및 작업을 통합할 수 있습니다. 이를 통해 Agentforce는 맞춤형 일대일 통합이 아닌 도구 계약을 통해 외부 기능을 사용할 수 있습니다.
의사결정 프레임워크: Agentforce를 주요 오케스트레이터로 유지하면서 외부 기능에 도구로 액세스해야 하는 경우 MCP 클라이언트를 사용하세요. 예를 들어 외부 시스템에서 데이터를 가져오거나, 워크플로를 호출하거나, 지식 소스를 검색하거나, 타사 플랫폼을 통해 작업을 수행하는 경우입니다.
MCP 클라이언트를 사용해야 하는 경우: Agentforce가 외부 기능을 도구로 사용해야 하는 경우입니다.
- 장점: 사용자 지정 코드 없이 외부 서비스를 Agentforce에서 안전하게 관리할 수 있는 도구로 전환합니다. 또한 시맨틱 무결성 검사(러그 풀 공격 방지) 및 위험 점수 평가와 같은 안전 기능을 포함하여 도구 포이즈닝을 방지합니다. Agentforce를 중심으로 추론 루프를 유지하면서 Agentforce가 수행할 수 있는 작업의 범위를 확장합니다.
- 단점: 이 추상화는 의도적으로 도구 중심으로 설계되었습니다. 원격 기능을 추론이나 워크플로의 일부를 담당하는 전문 에이전트로 모델링하는 것이 더 적합한 경우 이를 MCP에 억지로 적용하는 것은 자연스럽지 않을 수 있습니다. 또한 스키마가 외부 서버에서 정의되므로 계약이 변경되면 새로 고치거나 다시 등록할 때까지 통합이 작동하지 않을 수 있습니다.
Agentforce A2A(네이티브 아웃바운드 멀티 에이전트 오케스트레이션)
Agentforce A2A 아웃바운드는 Agentforce 에이전트가 타사 에이전트와 직접 협업할 수 있도록 하는 네이티브 방식입니다. 이를 활성화하려면 관리자가 먼저 외부 에이전트의 구체적인 기술, 기능 및 전송 프로토콜을 상세히 정의하여 등록해야 합니다. Agentforce 에이전트에 등록하고 연결하면 런타임에서 안전한 플랫폼 간 작업 위임에 사용할 수 있습니다.
의사결정 프레임워크: 네이티브 Agentforce 네트워크에서 Google 또는 Box와 같은 외부 공급업체의 에이전트와 안전하게 상호작용해야 하는 경우 Agentforce A2A를 사용하세요. 참고: 이 방식에서는 한 에이전트가 추론, 계획 또는 실행의 일부를 담당하는 다른 에이전트에 작업을 위임해야 합니다.
- 장점: Agentforce에 직접 구축되어 있으므로 이러한 멀티 에이전트 워크플로를 관리하기 위해 외부 오케스트레이션 도구를 별도로 구매할 필요가 없습니다. 사용자에게 '통합 브랜드' AI 에코시스템을 제공하며 외부 플랫폼의 사전 구축된 전문 기능을 활용할 수 있습니다.
- 단점: 타사 에이전트를 신뢰하고 시스템 간 데이터 개인정보를 보호하는 것이 어려울 수 있습니다. 타사 에이전트의 기능을 수동으로 등록하고 인증 표준을 일치시켜야 합니다.
MCP와 A2A 중 선택하는 방법
다음과 같은 간단한 규칙을 사용하세요. 핵심적인 차이는 양쪽에 AI가 존재하는지가 아닙니다. 핵심적인 차이는 원격 기능을 어떻게 모델링하는가입니다.
- 도구로 모델링된 경우 MCP를 사용합니다.
- 협업하는 에이전트로 모델링된 경우 A2A를 사용합니다.
챕터 5 Agentforce 에이전트를 외부 시스템에 통합
Agentforce 에이전트 사용(A2A 인바운드)
A2A 인바운드를 사용하면 외부 타사 에이전트가 Agentforce 에이전트의 전문 기능과 데이터에 네이티브 방식으로 액세스할 수 있습니다. 이 설정에서는 외부 시스템에서 호출하여 Salesforce 관련 작업을 수행할 수 있는 고부가가치 '전문가'로 Agentforce를 활용합니다. 안전한 API 엔드포인트를 통해 Agentforce 기능을 공개하면 외부 플랫폼에서 사용자가 타사 애플리케이션을 벗어나지 않고도 Salesforce에 작업을 위임할 수 있습니다.
의사결정 프레임워크: 기본 AI 인터페이스가 타사 시스템(예: 사용자 지정 포털 또는 외부 봇)에 있지만 Salesforce 내에서 복잡한 워크플로를 실행해야 하는 경우 인바운드 A2A를 사용하세요.
- 장점: 로직을 중복 구현하지 않고도 외부 애플리케이션에서 실시간 Salesforce 데이터와 자동화를 활용할 수 있습니다.
- 단점: 원활한 사용자 경험을 위해 외부 시스템에서 오케스트레이션 및 '핸드오프' 로직을 처리해야 합니다.
MCP 서버를 통한 Agentforce 에이전트 액세스
Salesforce의 호스팅 MCP 서버를 사용하면 표준화된 MCP 인터페이스를 통해 타사 에이전트, 코파일럿 및 LLM 플랫폼과 같은 외부 호스트에 Agentforce 기능을 공개할 수 있습니다. 이를 통해 외부 플랫폼은 Agentforce를 도구 제공자로 호출할 수 있으며, Agentforce는 복잡하고 전문적인 작업을 위한 엔터프라이즈 작업, 비즈니스 로직 및 오케스트레이션을 백그라운드에서 계속 캡슐화합니다.
의사결정 프레임워크: 외부 플랫폼에서 Agentforce를 도구 제공자로 사용해야 하는 경우 Agentforce 에이전트를 MCP 서버로 사용하세요. 특히 다음 두 가지 시나리오에 유용합니다.
- 엔터프라이즈 에이전트 상호 운용성: Microsoft Copilot과 같은 타사 엔터프라이즈 에이전트가 작업을 완료하는 데 필요한 엔터프라이즈 작업을 Agentforce가 보유하고 있어 Agentforce 에이전트를 호출해야 하는 경우입니다.
- 외부 LLM/채널 배포: ChatGPT, Gemini 또는 유사한 호스트와 같은 외부 대화형 환경에서 브랜드화된 Agentforce 기능을 사용할 수 있도록 하려는 경우입니다.
이 모델에서는 외부 플랫폼이 주요 호스트 경험을 유지하는 반면, Agentforce는 MCP를 통해 도구 엔드포인트로 의도적으로 공개됩니다. Agentforce가 내부적으로 에이전트 기반으로 작동하더라도 외부와의 관계가 동료 에이전트 간 위임이 아닌 도구 호출이므로 상호 운용성 패턴은 여전히 MCP입니다.
- 장점: Salesforce 데이터(청구, 지원 등)를 기반으로 비즈니스에 맞게 구축된 강력하고 전문적인 Agentforce 에이전트를 표준화된 프로토콜을 통해 Salesforce 외부에서도 쉽게 재사용할 수 있습니다. 외부 어시스턴트와 엔터프라이즈 에이전트가 Agentforce의 오케스트레이션과 비즈니스 작업을 다시 구축하지 않고 사용할 수 있으며, 엔터프라이즈 상호 운용성과 외부 채널 배포를 모두 지원합니다.
- 단점: 외부 호스트가 주요 사용자 경험과 추론 루프를 담당하므로 Agentforce가 언제, 어떻게 호출되는지에 대한 제어력이 떨어집니다. 또한 엔터프라이즈 환경에서는 인증, 권한 부여, ID 전달 및 컨텍스트 전달을 강력하게 처리해야 합니다.
챕터 6 2부 계속 읽기: 아키텍트를 위한 멀티 에이전트 오케스트레이션 참조 가이드
위 개요는 시작에 불과하며, 사용 사례에 적합한 오케스트레이션 패턴을 파악하는 데 도움이 됩니다. 계속 읽어 설계하고 배포하는 방법을 알아보세요.
2부: 아키텍트를 위한 멀티 에이전트 오케스트레이션 참조 가이드를 다운로드하면 다음 내용을 알아볼 수 있습니다.
- 복잡한 프로세스를 각자 책임을 명확하게 수행하는 에이전트로 분해하세요. 도메인 전문 지식, 워크플로 단계 또는 기능에 따른 세 가지 전략을 활용하면 비대해진 하나의 에이전트를 각자의 작업을 효과적으로 수행하는 여러 전문 에이전트로 전환할 수 있습니다.
- 아키텍처를 5가지 오케스트레이션 패턴 중 하나에 맞추세요. 감독 모드와 핸드오프 모드는 현재 일반적으로 사용할 수 있습니다. 병렬 실행, 이벤트 기반 백그라운드 에이전트, 계획 및 제시는 향후 로드맵에 포함되어 있습니다.
- LLM 기반 라우팅과 결정적 라우팅 중에서 선택하세요. 추론 엔진은 개방형 요청에 유연하게 대응합니다. 워크플로에 보장된 순서가 필요한 경우 에이전트 스크립트를 통해 결정적으로 제어할 수 있습니다. 대부분의 멀티 에이전트 설계에서는 두 가지를 모두 사용합니다.
- 가장 일반적인 7가지 안티패턴을 피하세요. 메시 오케스트레이션, 서로 겹치는 하위 에이전트, 지나치게 많은 위임 계층은 대규모 환경에서 거버넌스와 관찰 가능성을 약화시키는 가장 빠른 방법입니다.
- 현재 지원되는 기능을 고려하여 설계하세요. 에이전트 스크립트의 현재 제약 사항(고정된 핸드오프, 중첩된 위임, 연결 가능한 하위 에이전트 7개 제한)에 따라 지금 배포할 수 있는 패턴과 다음 분기에 계획해야 할 패턴이 결정됩니다.