Agentforce 액션 가이드 (2026): Native Flows vs. MuleSoft vs. 외부 서비스
Source: Dev.to
개요
Salesforce의 **Agentforce**는 Atlas Reasoning Engine 위에서 동작하며, reason → act → observe 루프를 통해 실제 비즈니스 작업을 완료합니다—단순히 질문에 답하는 것이 아닙니다. 에이전트가 Salesforce 내부에만 존재하고(예: Opportunity 업데이트, Data Cloud 쿼리) 하면 빠르게 배포할 수 있습니다.
대부분의 배포는 에이전트가 스택의 다른 부분과 상호작용해야 할 때 멈춥니다—Slack에 포스트하기, Jira/Linear 업데이트하기, GitHub PR 확인하기, 회의 일정 잡기, PagerDuty 인시던트 생성하기 등. 이때 **“액션”**이 병목이 됩니다.
Salesforce 문서는 Flow HTTP Callouts, Standard Actions 라이브러리, 또는 MuleSoft를 사용하도록 안내합니다. 각각은 빠르게 움직이면서 비용이나 보안 태세를 해치지 않으려는 엔지니어링 팀에게 중요한 트레이드‑오프를 제공합니다.
Agentforce “Action”이란 무엇인가요?
Agentforce Action은 Atlas 엔진이 계획의 단계를 실행하기 위해 호출할 수 있는 도구입니다. Action은 다음과 같이 실행됩니다:
- Salesforce 내에서 – 레코드 업데이트와 같은 기본 작업.
- 외부 시스템에서 – OpenAPI 사양으로부터 생성된 External Services 액션을 통해.
에이전트가 SaaS 생태계 전반에 걸쳐 신뢰할 수 있게, 안전하게, 적절한 권한으로 액션을 실행할 수 있을 때에만 추론이 의미가 있습니다.
주요 요점
| 이슈 | 인사이트 |
|---|---|
| 병목 현상 | Agentforce는 추론은 가능하지만, 에이전트가 외부 작업을 안정적으로 실행하지 못하면 배포가 실패합니다. |
| 기본 트레이드‑오프 | Flow HTTP 호출 + 사용자별 Named Credentials는 지속적인 인증/관리 부담을 증가시키며; 스키마 변경은 플로우를 깨뜨릴 수 있습니다. |
| 커버리지 격차 | 표준 액션 및 커넥터는 장기적인 혹은 깊은 엔드포인트를 거의 다루지 못합니다. |
| 최적 패턴 | 선별된 OpenAPI 사양을 External Services에 가져오면, 부서지기 쉬운 글루 코드를 사용하지 않고도 탐색 가능한 Agentforce 액션을 생성합니다. |
| 솔루션 | Composio는 브리지 역할을 하여, 보안적인 OpenAPI‑호환 커넥터를 생성하고 이를 Salesforce에 액션으로 직접 가져옵니다. |
| 결과 | 며칠 안에 깊이 통합된 에이전트를 배포하여, 사용자 수준 보안이 엄격히 적용된 SaaS 도구의 “롱테일”에 접근할 수 있습니다. |
Agentforce 액션 병목 현상 (대부분 배포가 정체되는 이유)
Atlas engine 은 정교한 추론 루프를 사용합니다:
- Reason – 사용자 질의를 평가합니다.
- Plan – 답변을 위한 경로를 설계합니다.
- Act – 그 계획을 실행할 도구(액션)를 찾습니다.
에이전트가 CRM 내부에만 존재한다면(예: 기회 업데이트 또는 Data Cloud 조회) 문제 없습니다.
하지만 비즈니스 로직이 Salesforce 외부로 흐를 때 마찰이 발생합니다. Google Calendar 회의를 잡을 수 없는 영업 에이전트는 무용지물이며, Linear 티켓 상태를 확인할 수 없는 지원 에이전트는 실패합니다.
“액션 격차”를 메우기 위한 세 가지 일반적인 선택
| 접근 방식 | 설명 |
|---|---|
| Flow HTTP Callouts / Apex | 시작은 빠르지만 규모가 커질수록 깨지기 쉽고 관리가 어려워집니다. |
| Standard Actions / MuleSoft | 폭넓거나 깊은 기능을 제공하지만, 종종 속도를 희생하거나 무거운 거버넌스를 요구합니다. |
| Generic iPaaS | 시스템 수준 연결성을 제공하지만 사용자별 보안 컨텍스트가 부족합니다. |
이러한 패턴 각각은 Agentforce 고유의 요구 사항을 충족시키지 못하는 경우가 많습니다.
Agentforce Integration Options Compared
| 옵션 | 출시 소요 시간 | 롱테일 범위 | 엔드포인트 깊이 | 사용자당 보안 | 운영 부담 | 일반적인 실패 모드 |
|---|---|---|---|---|---|---|
| Flow HTTP Callouts + Apex | 중간 | 높음 (DIY) | 높음 (DIY) | 가능 (어려움) | 높음 | 스키마 매핑 오류; 인증 분산 |
| Standard Actions library | 빠름 | 낮음‑중간 | 낮음‑중간 | 상황에 따라 | 낮음 | 엔드포인트 혹은 워크플로우 세부사항 누락 |
| MuleSoft | 느림‑중간 | 중간 | 중간‑높음 | 강함 (설계 시) | 중간‑높음 | 롱테일에 과도함; 반복 속도 느림 |
| Generic iPaaS (system key) | 빠름 | 높음 | 중간 | 약함 | 중간 | “시스템 사용자” 데이터 유출 위험 |
| Curated OpenAPI → External Services (Composio) | 빠름 | 높음 | 높음 | 강함 | 중간‑낮음 | 범위 초과 액션 또는 거버넌스 누락 |
표준 통합 패턴이 Agentforce에 실패하는 이유
1. Flow HTTP Callouts 및 Apex (관리 함정)
Salesforce는 여기서 개선되었습니다: OAuth 핸드셰이크를 위해 Named Credentials를 사용하고, 코드 없이 통합하기 위해 Flow HTTP Callouts를 사용할 수 있습니다. 이는 단순한 시스템‑대‑시스템 연결에 잘 작동합니다.
마찰
| 문제 | 왜 중요한가 |
|---|---|
| User Context | Agentforce는 사용자와 동일하게 동작해야 합니다 (예: “Sarah로 Slack에 게시”). 이를 네이티브하게 구현하려면 사용자별 Named Credential이 필요하며, 이는 각 외부 도구마다 개별 Auth Provider를 설정하고 세부 스코프를 관리해야 함을 의미합니다. 이를 확장하는 것은 매우 어렵습니다. |
| Schema Complexity | 현대 API(Jira, GitHub)는 방대한 중첩 JSON을 반환합니다. Flow HTTP Callouts는 이러한 스키마를 처리하는 데 종종 어려움을 겪습니다. |
| Maintenance | 여전히 입력/출력을 수동으로 매핑해야 합니다. 외부 API가 변경되면 Flow가 중단되고 에이전트가 실패합니다. |
2. Standard Actions 및 MuleSoft (범위 vs. 깊이 vs. 속도)
Salesforce는 주요 플랫폼(Jira, ServiceNow 등)을 위한 “Standard Actions” 라이브러리를 빠르게 구축하고 있습니다. 표준 액션이 정확히 필요한 기능을 제공한다면 사용하세요.
현실
- Breadth Gap (Long Tail) – 대부분의 조직은 50개 이상의 도구(Linear, Notion, PagerDuty, Brex, Asana 등)를 사용합니다. Salesforce는 이 모든 도구에 대한 네이티브 커넥터를 구축하지 않을 것입니다. 이러한 롱테일 앱을 위해 MuleSoft 프로젝트를 시작하면 속도가 크게 저하됩니다.
- Depth Gap – 표준 커넥터는 API 엔드포인트 중 상위 약 10%만 노출합니다(예: “Create Ticket”). 에이전트가 “Custom Field 업데이트” 또는 “Transition History 조회”와 같이 노출되지 않은 엔드포인트가 필요하면, 다시 처음부터 직접 구축해야 합니다.
3. Generic iPaaS (시스템‑키 통합)
많은 팀이 일반적인 iPaaS를 사용하고 단일 시스템 사용자로 연결합니다. 이는 빠르고 폭넓은 연결성을 제공하지만:
| 우려사항 | 영향 |
|---|---|
| Security Context | 작업이 시스템 계정으로 실행되어 사용자별 출처 정보를 잃게 됩니다. |
| Data Leakage Risk | 사용자가 접근 권한이 없는 데이터에 실수로 접근하거나 조작할 수 있습니다. |
Composio 솔루션
Composio는 보안이 강화된 OpenAPI‑준수 커넥터를 생성하여 Salesforce에 External Services 액션으로 직접 가져옵니다.
- Curated OpenAPI specs → 검색 가능한 액션으로 가져오기.
- Per‑user security가 Named Credentials를 통해 자동으로 적용됩니다.
- Low operational burden – 커스텀 Apex가 없고, 깨지기 쉬운 Flow 매핑도 없습니다.
결과
- 며칠 안에 깊게 통합된 에이전트를 배포합니다.
- 사용자 수준 보안이 엄격히 적용된 SaaS 도구들의 “롱테일”에 접근합니다.
- 유지보수 부담을 줄이고 반복 속도를 높입니다.
TL;DR
| 필요 사항 | 최적 솔루션 |
|---|---|
| 빠르고, 사용자별, 안전한 외부 작업 | Curated OpenAPI → External Services (Composio) |
| 간단한 시스템‑간 호출, 낮은 볼륨 | Flow HTTP Callouts + Named Credentials |
| 엔터프라이즈 수준 통합 및 강력한 거버넌스 | MuleSoft |
| 빠르고, 광범위한 연결, 사용자별 컨텍스트 없이 | Generic iPaaS (system key) |
취약하고 관리 부담이 큰 패턴에서 Composio‑driven External Services 로 전환하면 대부분의 Agentforce 배포를 지연시키는 주요 병목 현상을 제거하고 빠르고 안전하며 장기적인 SaaS 통합을 가능하게 합니다.
Source: …
보안 격차 (컨텍스트 문제)
이는 일반적인 iPaaS 도구(예: Zapier)의 가장 치명적인 실패 지점입니다. 이러한 도구는 일반적으로 “시스템 사용자”—모든 접근을 관리하는 하나의 API 키—에 의존합니다.
위험
인턴이 에이전트에게 “Q3 전략적 위험은 무엇인가요?”라고 묻는다고 가정해 보세요.
에이전트는 문서를 확인해야 한다는 논리로 Google Drive에 대한 시스템 키를 사용해 “Risks”를 검색합니다. 시스템 키가 관리자 권한을 가지고 있기 때문에, 에이전트는 인턴이 절대 볼 수 없어야 할 기밀 M&A 문서를 가져옵니다.
요구 사항
엄격한 사용자 수준 OAuth가 필요합니다. 에이전트는 사용자 그대로 행동해야 하며, 외부 도구에서 각 사용자의 특정 권한을 존중해야 합니다.
Composio 접근 방식: Agentforce를 위한 관리형 액션
Composio는 AI 에이전트를 위한 특화된 통합 레이어를 제공함으로써 “핸즈‑오프” 문제를 해결합니다. MuleSoft 백본을 대체하는 것이 아니라, 에이전트가 지금 필요로 하는 민첩하고 장기적인 SaaS 연결을 100 % API 커버리지와 함께 처리합니다.
- Salesforce 사용자를 외부 아이덴티티에 매핑합니다.
- Salesforce가 기본적으로 지원하는 표준 OpenAPI 사양을 생성합니다.
워크플로우
- Connect & Curate – 개발자가 도구(예: GitHub, Slack)를 선택하고 노출할 액션을 지정합니다.
- Export – Composio가 선별된, 엄격히 타입이 지정된 OpenAPI 사양을 생성하여 Salesforce 제한에 최적화하고 “spec bloat” 오류를 방지합니다.
- Import – 개발자가 최적화된 사양을 Salesforce External Services에 가져옵니다.
- Deploy – Agentforce가 즉시 이러한 새로운 엔드포인트를 Actions 로 인식하여 Atlas Engine에서 사용할 수 있게 합니다.
Flow JSON 파서를 다루거나 Auth Provider를 설정하느라 시간을 낭비할 필요가 없습니다—그냥 기능을 가져오기만 하면 됩니다.
Deep Dive: The “Deal Room” Workflow
Scenario: A Sales Rep tells the agent:
“Update the Acme deal stage and notify the solutions team channel.”
| Step | Description |
|---|---|
| 1. Reasoning (The Brain) | Atlas는 두 가지 작업을 식별합니다: Salesforce 객체 업데이트와 Slack 메시지 전송. |
| 2. Data Access (Internal) | 에이전트는 표준 Salesforce 권한을 사용해 Opportunity 레코드를 업데이트합니다. |
| 3. External Action (The Hands) | 에이전트는 External Services에 정의된 Composio_Slack_PostMessage 액션을 호출합니다. |
| 4. Authentication (The Passthrough) | 요청은 Composio를 통해 라우팅되며, 여기서 시작 사용자의 OAuth 자격 증명이 헤더에 삽입됩니다. |
| 5. Zero‑Data Retention | 페이로드는 암호화된 터널을 통해 저장되지 않고 Composio 데이터베이스를 통과합니다 (SOC 2, 제로‑지식). |
| 6. Observation | Composio는 성공 플래그 또는 구조화된 오류를 반환하고, Atlas는 사용자에게 작업을 확인합니다. |
Note on data handling: 기업은 로깅/보존을 구성할 수 있습니다. Composio는 SOC 2 제어를 지원하며 정책에 따라 페이로드 로깅을 최소화하거나 회피할 수 있습니다.
왜 “User‑Level” 인증은 협상 불가
자율‑에이전트 세계에서는 least privilege이 데이터 유출에 대한 유일한 방어 수단입니다. “System” 자격 증명(일반적인 통합에서 흔히 사용)을 사용할 경우 외부 SaaS 도구의 보안 제어를 우회하게 됩니다.
Composio는 Salesforce 사용자와 외부‑도구 ID 간에 1:1 mapping을 생성하여 에이전트가 절대 “superuser”로 기본 설정되지 않도록 합니다. Jira, GitHub, HRIS 플랫폼 등 민감한 시스템과 상호 작용하는 에이전트를 안심하고 배포할 수 있으며, 이 에이전트가 명령하는 사람보다 높은 권한을 갖지 못한다는 것을 알 수 있습니다.
Agentforce Actions Deployment Checklist (Production‑Ready)
| ✅ | 항목 | 세부 사항 |
|---|---|---|
| 1 | 아이덴티티 모델 선택 | 최소 권한 접근을 위해 기본값을 per‑user authentication(사용자당 인증)으로 설정합니다. |
| 2 | 액션 허용 목록 정의 | 에이전트가 필요로 하는 액션만 노출합니다(최소 기능 원칙). |
| 3 | 선별된 OpenAPI 사양 사용 | 타입이 지정된 최소한의, 임포터 친화적인 사양을 선호합니다. 방대한 원시 API 정의는 피하세요. |
| 4 | 스키마 및 제한 검증 | 요청/응답 형태가 런타임을 깨지 않도록 보장합니다(예: 큰 중첩 객체, 선택적 필드, 페이지네이션). |
| 5 | 정책 제어 추가 | 로깅/보존, 감사 추적, 환경 분리, 보안 요구사항을 충족하는 비밀 관리 등을 포함합니다. |
| 6 | 안전하게 실패 | 구조화된 오류 메시지를 반환하여 Atlas가 복구할 수 있도록 합니다(예: 누락된 필드 요청, 재시도, 에스컬레이션). |
| 7 | 비용 및 신뢰성 측정 | 액션 성공률, 재시도, 타임아웃을 추적합니다. 액션이 계량화되므로 신뢰성은 ROI에 직접 영향을 미칩니다. |
사용 방법
- 프로덕션에 액션을 배포하기 전에 각 항목을 검토하십시오.
- 준수 여부를 확인하면서 체크박스에 표시하십시오.
- 액션 정의나 배포 환경에 변경이 있을 경우 체크리스트를 다시 실행하십시오.
결론
Agentforce는 CRM의 미래를 대표하지만, 연결 제약으로 인해 잠재력이 제한됩니다. Atlas Reasoning Engine은 실행 준비가 되어 있지만, 여전히 효과적으로 실행하기 위한 적절한 도구가 필요합니다.
- Flow의 스키마 오류 때문에 에이전트가 실패하지 않도록 하세요.
- MuleSoft 커넥터를 기다리며 몇 주가 걸리는 일을 피하세요.
- 표준 작업에 필요한 특정 API 엔드포인트가 없을 때 막다른 길에 빠지지 않도록 하세요.
Salesforce에서 두뇌를 구축하고, 손은 Composio가 담당하도록 하세요.
Frequently Asked Questions
Composio는 내 데이터를 저장하나요?
아니요. Composio는 전달‑전용 실행 레이어로 동작합니다. 인증 토큰은 저장 시 암호화되지만, 에이전트가 실행하는 액션 페이로드(입력 또는 출력)는 저장하지 않습니다. 로그는 제로‑지식으로 구성할 수 있어 엄격한 데이터‑거주 및 프라이버시 요구사항(SOC 2)을 충족합니다.
왜 Composio가 필요한가요?
- 모든 외부 호출에 대해 사용자‑레벨 OAuth 제공
- 정제된 OpenAPI 사양을 생성하여 Salesforce External Services에 깔끔하게 가져올 수 있음
- 보안적인 제로‑지식 전달 역할을 수행, 맞춤형 미들웨어나 “시스템” 자격 증명이 필요 없음
- 세밀한 정책 제어(로그, 보존, 감사 추적)를 제공하여 엔터프라이즈 보안 표준을 만족
Salesforce에 표준 액션이 있나요?
표준 액션은 주요 플랫폼에서 일상적인 사용 사례(예: “Jira 티켓 생성”)에 잘 작동합니다. 하지만 다음과 같은 경우에는 한계가 있습니다:
- “Long Tail” 앱(예: Notion, Linear, PagerDuty 등)에 접근해야 할 때
- Jira와 같이 특정 비표준 API 엔드포인트를 호출하는 깊은 작업을 수행해야 할 때
Composio는 수백 개 앱에 대한 커넥터를 제공하고 전체 API 표면을 노출함으로써 이러한 제한을 해결합니다—가장 일반적인 액션만 제공하는 것이 아니라 전체 기능을 사용할 수 있습니다.
Composio는 Salesforce Agentforce와 어떻게 연결되나요?
- Export: Composio에서 표준 OpenAPI 사양을 내보냅니다.
- Import: 해당 사양을 Salesforce External Services에 가져옵니다.
- Salesforce가 네이티브 액션을 생성하고, Agentforce Atlas Engine이 이를 즉시 발견하고 사용할 수 있습니다.
이것이 Salesforce Flex Credits를 소비하나요?
예. 액션 실행은 다른 액션과 마찬가지로 Flex Credits를 소모합니다. Composio 커넥터는 유지 관리되고 엄격히 타입 지정되어 있기 때문에, 자체 제작 통합에서 흔히 발생하는 실패 호출이나 “환상적인” 파라미터 때문에 발생하는 불필요한 크레딧 소모를 방지할 수 있습니다.
현재 가격: $