Salesforce-Databricks 연계와 AI에이전트 데이터거버넌스

Salesforce와 Databricks의 파트너십 발표는 단순한 기술 제휴가 아니다. AI에이전트 데이터거버넌스 문제를 플랫폼 레벨에서 해결하겠다는 아키텍처 선언이다. 한국 기업 입장에서 이 발표가 중요한 이유는 따로 있다. 개인정보 보호법(PIPA) 규제 환경과 SI 의존적 데이터 구조 속에서 AI 에이전트가 실제로 쓸 수 있는 데이터를 어떻게 확보하느냐는 문제가 이번 연계로 구체적인 해법 경로를 얻었기 때문이다.

왜 지금 이 파트너십이 한국 시장에 의미 있는가

한국 대기업의 데이터 환경을 보면 공통된 패턴이 있다. 핵심 트랜잭션 데이터는 온프레미스 ERP나 자체 데이터 레이크에 있고, Salesforce는 CRM 레이어로 분리 운영된다. 두 시스템 사이의 데이터 이동은 SI가 구축한 배치 파이프라인이 담당하며, 실시간 동기화는 예외적인 경우에만 존재한다.

이 구조에서 Agentforce(에이전트포스)를 도입하면 즉각적인 벽에 부딪힌다. Atlas Reasoning Engine이 추론을 수행하려면 신뢰할 수 있는 컨텍스트 데이터가 필요한데, 그 데이터가 Salesforce 외부에 있다. 외부 데이터를 끌어오려면 MuleSoft나 External Services를 통한 API 호출이 필요하고, 이는 레이턴시와 거버넌스 양쪽에서 문제를 만든다.

Databricks 연계는 이 구조적 단절을 해소하는 방향으로 설계됐다. Databricks의 Unity Catalog가 관리하는 데이터를 Data Cloud의 Data Streams로 직접 수집하거나, Data Cloud에서 Databricks의 Delta Lake로 세그먼트와 Calculated Insights를 역방향 동기화하는 패턴이 가능해진다. 에이전트가 참조하는 데이터가 Salesforce 플랫폼 경계 안에서 거버넌스된 상태로 존재하게 된다는 뜻이다.

PIPA 준수와 데이터 국외 이전 문제

한국 기업 CIO가 AI 에이전트 도입을 검토할 때 가장 먼저 법무팀에서 제동이 걸리는 지점이 있다. 개인정보가 포함된 데이터를 AI 추론 과정에서 어떻게 처리하느냐는 질문이다.

PIPA 관점에서 AI 에이전트의 데이터 처리는 세 가지 리스크를 동시에 건드린다. 첫째, 개인정보의 목적 외 이용 금지 원칙. 에이전트가 고객 데이터를 참조해 자율적으로 액션을 취할 때 원래 수집 목적 범위를 벗어날 수 있다. 둘째, 위탁 처리 계약 요건. 데이터가 Salesforce 인프라를 통해 처리될 때 위탁 처리 계약이 적절히 체결되어 있어야 한다. 셋째, 데이터 국외 이전. Salesforce와 Databricks 모두 글로벌 클라우드 인프라를 사용하므로, 개인정보가 국외로 이전되는 경우 별도 동의 또는 표준 계약 조항이 필요하다.

Salesforce-Databricks 연계 아키텍처에서 이 문제를 다루는 핵심은 데이터 처리 위치와 거버넌스 레이어의 명확한 분리다. Unity Catalog의 column-level access control과 Data Cloud의 Identity Resolution ruleset을 결합하면, 에이전트가 참조하는 데이터에서 개인 식별 정보를 마스킹하거나 집계된 형태로만 노출하는 파이프라인을 구성할 수 있다. 에이전트는 Unified Individual 프로필의 집계 지표를 보지, 원시 개인정보를 직접 처리하지 않는 구조다.

이 패턴이 PIPA 준수를 자동으로 보장하지는 않는다. 하지만 법무팀과 품의를 진행할 때 “에이전트가 어떤 데이터에 어떤 방식으로 접근하는가”를 기술적으로 증명할 수 있는 아키텍처 근거를 제공한다. 이것이 실질적인 차이다.

아키텍처 패턴: Data Cloud와 Databricks의 데이터 흐름

실제 구현 관점에서 이 연계가 어떻게 작동하는지 구체적으로 보면, 두 가지 주요 패턴이 있다.

패턴 1: Databricks → Data Cloud 수집

Databricks의 Delta Lake에 있는 고객 행동 데이터, 구매 이력, 제품 사용 로그를 Data Cloud의 Data Streams로 수집한다. 수집된 데이터는 Data Model Objects(DMOs)로 정규화되고, Identity Resolution이 매칭 ruleset을 적용해 Unified Individual 프로필을 생성한다. Agentforce의 Topics와 Actions는 이 통합 프로필을 컨텍스트로 사용한다.

이 패턴의 장점은 에이전트 추론이 항상 Data Cloud 내부에서 완결된다는 점이다. 외부 API 호출 없이 Data Graphs의 사전 계산된 조인을 활용하므로, 에이전트 응답 레이턴시가 안정적으로 유지된다. 엔터프라이즈 환경에서 Data Cloud 실시간 활성화의 일반적 지연은 2~5분 수준이지만, Data Graphs를 활용하면 에이전트 추론 시점의 조회 레이턴시는 밀리초 단위로 줄어든다.

패턴 2: Data Cloud → Databricks 역방향 동기화

Data Cloud에서 생성한 Segments와 Calculated Insights를 Databricks로 역방향 동기화한다. 이 패턴은 Databricks 기반의 ML 모델 학습에 Salesforce CRM 데이터를 활용하거나, 기존 데이터 레이크 기반 분석 워크플로우에 Salesforce 세그먼트를 통합할 때 유용하다.

한국 기업 환경에서 이 패턴이 특히 의미 있는 이유는 SI가 구축한 기존 Databricks 환경을 그대로 유지하면서 Salesforce 데이터를 점진적으로 통합할 수 있기 때문이다. 빅뱅 방식의 데이터 마이그레이션 없이 단계적 통합이 가능하다.

[Databricks Unity Catalog]
        ↓ Data Streams (수집)
[Data Cloud DMOs]
        ↓ Identity Resolution
[Unified Individual Profile]
        ↓ Data Graphs (사전 계산 조인)
[Agentforce Atlas Reasoning Engine]
        ↓ Topics / Actions
[에이전트 액션 실행]
        ↓ Calculated Insights / Segments
[Databricks Delta Lake] ← 역방향 동기화

한국 기업이 실제로 마주치는 구현 함정

이 파트너십의 기술적 가능성과 실제 한국 기업 환경에서의 구현 사이에는 몇 가지 현실적 간극이 있다.

가장 흔한 함정은 데이터 품질 문제를 거버넌스 레이어로 해결하려는 시도다. Databricks에 있는 데이터가 중복되거나 스키마가 일관되지 않은 상태라면, Data Cloud의 Identity Resolution이 아무리 정교한 ruleset을 적용해도 신뢰할 수 있는 Unified Individual 프로필이 나오지 않는다. 에이전트는 잘못된 컨텍스트를 기반으로 추론하게 된다. 800만 건 이상의 레코드를 다루는 데이터 통합 프로젝트에서 Identity Resolution 정확도가 목표치에 도달하려면 소스 데이터 정제에 전체 프로젝트 기간의 40~60%가 소요되는 것이 일반적인 패턴이다.

두 번째 함정은 Agentforce의 Topics 설계를 데이터 가용성과 분리해서 진행하는 경우다. Topics는 에이전트가 어떤 상황에서 어떤 Actions를 실행할지 정의하는데, 이 설계가 Data Cloud에서 실제로 제공 가능한 데이터 구조와 맞지 않으면 에이전트가 추론 중에 필요한 컨텍스트를 찾지 못한다. Agentforce Testing Center에서 이 불일치를 조기에 발견하지 못하면 프로덕션 배포 후 에이전트 실패율이 예상보다 훨씬 높게 나온다.

세 번째는 PIPA 관련 거버넌스 설계를 아키텍처 초기 단계가 아니라 배포 직전에 추가하려는 패턴이다. 개인정보 처리 방침, 위탁 처리 계약, 데이터 국외 이전 동의 체계는 데이터 파이프라인 설계 단계에서 함께 정의되어야 한다. 나중에 추가하면 파이프라인 전체를 재설계해야 하는 경우가 생긴다.

Agentforce 프로덕션 배포 전 체크리스트에서 이 함정들을 피하는 구체적인 검증 단계를 확인할 수 있다.

이 연계가 한국 AI 에이전트 도입 경로를 어떻게 바꾸는가

지금까지 한국 기업의 Agentforce 도입 경로는 대체로 두 가지였다. Salesforce 내부 데이터만으로 에이전트를 구성하거나, MuleSoft를 통해 외부 데이터를 실시간으로 끌어오는 방식이다. 전자는 에이전트의 컨텍스트가 빈약하고, 후자는 레이턴시와 거버넌스 복잡도가 높다.

Databricks 연계는 세 번째 경로를 만든다. 기업이 이미 Databricks에 축적한 데이터 자산을 Data Cloud를 통해 거버넌스된 방식으로 에이전트에 공급하는 경로다. 이 경로의 전략적 의미는 AI 에이전트가 기업 고유의 데이터 자산을 활용할수록 경쟁 차별화가 커진다는 점에 있다. 범용 LLM 기반 에이전트와 자체 데이터로 훈련된 에이전트의 차이는 시간이 지날수록 벌어진다.

한국 기업 CTO 입장에서 지금 해야 할 판단은 명확하다. Databricks 환경이 이미 있다면, Data Cloud와의 연계 아키텍처를 설계하는 것이 Agentforce 도입의 선결 조건이 된다. Databricks가 없다면, AI 에이전트 데이터 레이어로 Data Cloud를 단독으로 구성하는 것이 더 단순하고 빠른 경로다. 두 경우 모두 PIPA 준수 설계는 아키텍처 결정과 동시에 이루어져야 한다.

AI에이전트 데이터거버넌스를 플랫폼 레벨에서 해결하려는 방향은 옳다. 문제는 항상 구현 세부에 있다. Data Cloud와 Agentforce 아키텍처 설계에서 이 연계를 실제 한국 기업 환경에 맞게 구성하는 방법을 다룬다.

핵심 정리

• Salesforce-Databricks 연계는 Databricks Unity Catalog의 데이터를 Data Cloud Data Streams로 수집해 Agentforce의 추론 컨텍스트로 공급하는 아키텍처를 가능하게 한다. 에이전트가 외부 API 호출 없이 거버넌스된 데이터를 참조할 수 있게 된다.

• PIPA 준수 설계는 배포 전 추가가 아니라 데이터 파이프라인 설계 단계에서 동시에 이루어져야 한다. Identity Resolution ruleset과 column-level access control의 조합이 개인정보 처리 범위를 기술적으로 제한하는 핵심 메커니즘이다.

• Data Graphs를 활용한 사전 계산 조인은 에이전트 추론 시점의 조회 레이턴시를 밀리초 단위로 유지하는 핵심 패턴이다. 실시간 활성화의 2~5분 지연과 에이전트 추론 레이턴시는 별개의 문제다.

• 소스 데이터 품질이 Identity Resolution 정확도를 결정한다. 대규모 통합 프로젝트에서 데이터 정제에 전체 기간의 40~60%가 소요되는 것이 현실적인 기준이다. 거버넌스 레이어가 데이터 품질 문제를 해결하지는 않는다.

• Databricks 환경이 있는 한국 기업은 Data Cloud 연계 아키텍처 설계를 Agentforce 도입의 선결 조건으로 다루어야 한다. 없다면 Data Cloud 단독 구성이 더 빠른 경로다.