Salesforce가 Fin 인수 계약을 체결했다. 표면적으로는 고객 서비스 AI 강화다. 그러나 한국 엔터프라이즈 아키텍처 관점에서 이 인수가 던지는 질문은 다르다. AI 에이전트 자동화가 한국 기업의 SI 의존 구조를 실질적으로 바꿀 수 있는가.
Fin 인수가 Agentforce 아키텍처에 미치는 영향
Fin은 단순한 챗봇 회사가 아니다. Intercom이 구축한 Fin은 대화 흐름을 자체적으로 추론하고, 외부 지식 소스를 실시간으로 참조하며, 해결되지 않은 케이스를 인간 에이전트에게 넘기는 판단 로직을 갖추고 있다. 이 구조는 Agentforce의 Atlas Reasoning Engine(추론 계층)이 Topics와 Actions를 조합해 다단계 작업을 처리하는 방식과 직접적으로 겹친다.
인수 후 통합 시나리오에서 가장 주목할 지점은 두 가지다. 첫째, Fin의 대화 해결률 데이터가 Agentforce Testing Center의 벤치마크 기준으로 편입될 가능성이다. 현재 Agentforce 도입 조직이 에이전트 품질을 측정하는 방식은 대부분 수작업 시나리오 검증에 의존한다. Fin이 쌓아온 수억 건의 대화 해결 패턴이 이 공백을 채운다면, 에이전트 검증 비용이 구조적으로 낮아진다. 둘째, Fin의 지식 그래프 연결 방식이 Data Cloud의 Data Graphs와 결합할 경우, 고객 프로필 기반 실시간 응답 생성이 현재보다 훨씬 낮은 구성 복잡도로 가능해진다.
한국 엔터프라이즈 CTO 입장에서 이 두 변화는 단순한 기능 추가가 아니다. 지금까지 “AI 에이전트 자동화를 도입하려면 SI 파트너가 필요하다”는 전제를 흔드는 아키텍처 변화다.
한국 SI 의존 구조가 만들어진 이유
한국 대기업의 Salesforce 운영 구조를 보면 공통 패턴이 있다. 초기 구축은 대형 SI가 담당하고, 이후 운영·고도화도 동일 SI가 유지한다. 이 구조가 고착된 데는 기술적 이유보다 조직적 이유가 크다.
Salesforce 플랫폼 자체의 설정 복잡도가 높은 것은 사실이지만, 더 근본적인 문제는 내부 역량 부재다. Flow 오케스트레이션, Prompt Builder 템플릿 설계, Data Cloud의 Identity Resolution ruleset 구성 같은 작업을 직접 수행할 수 있는 내부 인력이 없는 조직이 대부분이다. 결과적으로 변경 요청 하나에도 SI 품의가 필요하고, 단순한 프로세스 수정이 수개월 프로젝트로 늘어난다.
이 구조의 비용은 단순히 SI 계약 금액이 아니다. 변경 속도 저하, 비즈니스 요구사항과 기술 구현 사이의 해석 오류 누적, 그리고 플랫폼 로드맵에 대한 의사결정권 상실이 실질적인 비용이다. 컨설턴트 200명, 사업부 15개 규모의 조직에서 이 구조가 고착되면, 플랫폼 전환 비용이 실제 기술 비용의 3배를 넘는 경우가 일반적이다.
AI 에이전트 자동화가 SI 의존도를 낮출 수 있는 조건
AI 에이전트 자동화가 SI 의존 구조를 실질적으로 대체하려면 세 가지 조건이 동시에 충족되어야 한다.
구성 복잡도 감소. Agentforce의 Topics-Actions-Instructions 구조는 이미 비개발자가 에이전트 행동을 정의할 수 있도록 설계되어 있다. Fin의 대화 설계 방법론이 통합되면, 고객 서비스 시나리오에서 SI 없이 에이전트를 구성하는 것이 현실적으로 가능해진다. 단, 이것은 표준 시나리오에 한정된다. ERP 연동, 레거시 시스템 API 호출, 복잡한 승인 워크플로우가 얽힌 케이스는 여전히 아키텍처 설계 역량이 필요하다.
데이터 파이프라인 자립. Data Cloud의 Data Streams와 Calculated Insights를 내부 팀이 직접 운영할 수 있어야 한다. 현재 한국 기업 대부분은 Data Cloud 구성을 SI에 위탁한다. Fin 인수로 고객 서비스 데이터 흐름이 더 단순화되더라도, 기반 데이터 파이프라인을 SI가 쥐고 있으면 에이전트 자동화의 실질적 자율성은 제한된다.
내부 역량 축적. 가장 어려운 조건이다. Agentforce Testing Center를 활용한 에이전트 검증, Prompt Builder의 Flex 템플릿 설계, Identity Resolution ruleset 튜닝은 모두 플랫폼 깊이를 요구한다. 이 역량이 내부에 없으면 도구가 단순해져도 SI 의존은 유지된다.
Agentforce 도입 시 프로덕션 준비 기준을 다룬 글에서 지적했듯, 에이전트를 배포하는 것과 에이전트를 운영하는 것은 다른 역량을 요구한다. Fin 인수가 배포 장벽을 낮추더라도, 운영 역량 없이는 SI 의존 구조가 형태만 바뀔 뿐이다.
한국 시장에서 현실적으로 작동하는 아키텍처
SI 의존도를 낮추는 데 실제로 효과적인 패턴은 “완전 자립”이 아니라 “의존 범위 축소”다.
핵심 아이디어는 SI가 담당하는 작업을 두 계층으로 분리하는 것이다. 첫 번째 계층은 초기 아키텍처 설계, 레거시 시스템 통합, 복잡한 데이터 모델 구성이다. 이 계층은 전문 역량이 필요하고, SI 또는 독립 아키텍트가 담당하는 것이 합리적이다. 두 번째 계층은 에이전트 Topics 수정, Prompt Builder 템플릿 업데이트, Segment 조건 변경 같은 반복적 운영 작업이다. 이 계층을 내부화하는 것이 현실적 목표다.
Agentforce의 현재 아키텍처는 이 분리를 지원한다. Topics와 Instructions는 선언적으로 정의되어 있어 코드 변경 없이 수정 가능하다. Prompt Builder의 Field Generation 템플릿은 마케터나 서비스 운영자가 직접 편집할 수 있다. Data Cloud의 Segments는 SQL 없이 조건 기반으로 구성된다.
Fin 통합이 완성되면 고객 서비스 에이전트의 대화 흐름 수정도 이 범주에 들어올 가능성이 높다. 그렇게 되면 SI가 개입해야 하는 작업의 범위가 실질적으로 줄어든다.
PIPA와 데이터 거버넌스: 한국 특유의 제약
한국 기업이 AI 에이전트 자동화를 확장할 때 반드시 고려해야 하는 변수가 있다. 개인정보 보호법(PIPA)이다.
Agentforce가 고객 데이터를 기반으로 응답을 생성할 때, 그 데이터가 어떤 경로로 LLM에 전달되는지는 PIPA 위탁 처리 조항과 직결된다. Fin의 대화 데이터가 Salesforce 인프라로 통합되는 과정에서 데이터 국외 이전 이슈가 발생할 수 있다. 특히 금융, 의료, 공공 분야 조직은 이 지점을 사전에 법무팀과 검토해야 한다.
실무적으로는 Data Cloud의 Data Streams 구성 단계에서 개인식별정보(PII) 필드를 명시적으로 마스킹하거나 제외하는 설계가 필요하다. Agentforce에 전달되는 컨텍스트가 Unified Individual 프로필 전체가 아니라 에이전트 작업에 필요한 최소 필드로 제한되어야 한다는 의미다. 이 설계를 SI에 위탁하면 나중에 감사 대응이 어려워진다. 내부 데이터 거버넌스 담당자가 이 구조를 직접 이해하고 있어야 한다.
Agentforce와 PIPA 데이터 보안에서 다룬 것처럼, 에이전트 컨텍스트 설계는 기능 문제이기 전에 규제 준수 문제다.
핵심 정리
- Salesforce의 Fin 인수는 고객 서비스 에이전트의 구성 복잡도를 낮추는 방향으로 작동할 가능성이 높다. 그러나 이 효과는 표준 시나리오에 집중되며, 레거시 통합이 복잡한 한국 대기업 환경에서는 제한적이다.
- AI 에이전트 자동화가 SI 의존도를 낮추려면 도구 단순화만으로는 부족하다. 내부 팀이 Topics, Prompt Builder, Data Cloud Segments를 직접 운영할 수 있는 역량이 선행 조건이다.
- 한국 기업의 현실적 목표는 SI 완전 대체가 아니라 의존 범위 축소다. 초기 아키텍처와 레거시 통합은 전문 역량이 필요하지만, 반복적 운영 작업은 내부화 가능하다.
- PIPA 준수 설계는 에이전트 컨텍스트 구성 단계에서 결정된다. Data Streams에서 PII 필드를 어떻게 처리하는지가 나중에 규제 감사의 핵심 쟁점이 된다.
- Fin 통합의 실질적 가치는 2027년 이후 Agentforce 플랫폼에 반영될 가능성이 높다. 지금 당장 Fin 인수를 근거로 도입 결정을 앞당길 이유는 없다. 대신 내부 역량 축적과 데이터 거버넌스 구조 정비에 투자하는 것이 더 높은 수익을 낸다.
AI 에이전트 자동화의 아키텍처 설계와 한국 시장 특화 거버넌스 구조가 필요하다면 Agentforce 아키텍처 서비스에서 구체적인 접근 방식을 확인할 수 있다.
