Salesforce Data Cloud vs CDP를 비교할 때 대부분의 조직은 잘못된 질문에서 출발합니다. “어떤 제품이 데이터를 더 잘 저장하는가”가 아니라 “통합된 프로필이 실행 계층까지 끊김 없이 이어지는가”가 진짜 질문입니다. 일반 CDP는 세그먼트를 만드는 데서 끝나지만, Data Cloud(현재는 Data 360으로 명명)는 그 세그먼트가 Agentforce의 판단과 Flow의 자동화까지 실시간으로 연결되도록 설계되어 있습니다. 이 차이를 이해하지 못하면 도입 후 6개월 안에 “우리가 왜 이 비용을 내고 있는가”라는 질문이 나옵니다.
Salesforce Data Cloud vs CDP 논쟁이 잘못 설정되는 이유
시장에서 도는 비교표 대부분은 저장 용량, 커넥터 개수, 가격 구조 같은 표면적 지표를 나열합니다. 하지만 엔터프라이즈 환경에서 실제로 걸려 있는 문제는 다릅니다. CDP는 대개 마케팅 조직의 도구로 설계되어 캠페인 오디언스를 만드는 데 최적화되어 있습니다. 반면 Salesforce Data Cloud vs CDP 구도에서 Data Cloud는 처음부터 CRM, Service Cloud, Commerce Cloud, 그리고 Agentforce가 공유하는 단일 데이터 기반으로 설계되었습니다.
이 차이는 조직도에도 반영됩니다. CDP 프로젝트는 대부분 마케팅 부서가 단독으로 발주하고 IT는 데이터 파이프라인만 연결해줍니다. 그 결과 마케팅이 정의한 고객 세그먼트가 서비스 조직이나 영업 조직에서는 전혀 활용되지 않는 사일로가 생깁니다. 3,000개 이상의 리테일 터치포인트를 운영하는 조직에서 흔히 관찰되는 패턴은, 마케팅 CDP와 서비스 CRM이 서로 다른 고객 정의를 가진 채 몇 년간 병존하다가 어느 시점에 “왜 콜센터가 방금 이탈 캠페인을 받은 고객에게 프로모션을 보내는가”라는 사고가 터지는 것입니다.
Data Cloud는 이 문제를 근본적으로 다른 방식으로 접근합니다. Data Streams로 수집된 원천 데이터는 Data Model Objects(DMO)로 정규화되고, Identity Resolution ruleset을 거쳐 Unified Individual로 병합됩니다. 이 통합 프로필은 마케팅뿐 아니라 Service Cloud 케이스 화면, Agentforce의 Atlas Reasoning Engine, CRM Analytics 대시보드가 동시에 참조하는 단일 진실 공급원이 됩니다. 즉 통합의 단위가 “캠페인”이 아니라 “고객 그 자체”입니다.
Identity Resolution이 통합의 실질적 차이를 만드는 방식
일반 CDP의 Identity Resolution은 대개 결정론적 매칭(이메일, 전화번호 정확 일치)에 머무릅니다. 이는 단일 채널 환경에서는 충분하지만, 매장 POS, 앱, 콜센터, 웹사이트가 각각 다른 식별자 체계를 쓰는 환경에서는 통합률이 급격히 떨어집니다. Data Cloud의 Identity Resolution ruleset은 결정론적 규칙과 확률적 규칙을 조합해 매칭 우선순위를 계층화할 수 있습니다. 예를 들어 이메일 일치를 1순위로, 기기 지문과 행동 패턴 유사도를 보조 신호로 설정하는 식입니다.
여기서 중요한 아키텍처 결정은 매칭 규칙을 얼마나 보수적으로 설계하느냐입니다. 매칭을 과도하게 관대하게 설정하면 서로 다른 두 사람이 하나의 Unified Individual로 병합되는 오탐이 발생하고, 이는 서비스 케이스 히스토리 오염이나 개인정보 보호법(PIPA) 관점의 처리 근거 문제로 이어집니다. 반대로 너무 보수적이면 통합률이 낮아져 Data Cloud를 도입한 의미가 퇴색됩니다. 이 균형점은 업종별로 다르며, 리테일과 금융 서비스는 통상 요구되는 정확도 기준이 다릅니다.
Identity Resolution 설계에서 실제로 검증해야 할 항목은 다음과 같습니다.
- 매칭 정확도: 샘플 데이터셋에 대해 수동 검증한 정탐률과 오탐률
- 통합률: 채널별 고유 식별자 대비 Unified Individual로 병합된 비율
- 재처리 주기: 신규 데이터 유입 시 재매칭이 배치인지 실시간인지
- 예외 처리: 매칭 신뢰도가 낮은 레코드를 자동 병합할지 수동 검토 큐로 보낼지
이 항목들을 프로젝트 초기에 승인 기준으로 문서화하지 않으면, 도입 후 데이터 품질 논쟁이 끝없이 반복됩니다. Identity Resolution의 구체적 설계 원칙은 별도로 다룬 적이 있으니 Data Cloud Identity Resolution이 중복 문제를 해결하는 방식에서 상세 로직을 참고하는 것이 좋습니다.
Data Graphs와 Calculated Insights가 CDP와의 실행 격차를 벌리는 지점
Salesforce Data Cloud vs CDP 비교에서 가장 저평가되는 요소는 Data Graphs입니다. 대부분의 CDP는 세그먼트를 만들 때마다 조인 쿼리를 실시간으로 실행하거나, 야간 배치로 미리 계산해둔 평면 테이블을 씁니다. 두 방식 모두 확장성 문제를 안고 있습니다. 실시간 조인은 프로필 수가 늘어날수록 쿼리 지연이 커지고, 배치 평면 테이블은 최신성이 떨어집니다.
Data Graphs는 자주 조회되는 조인 패턴을 사전 계산된 구체화 뷰로 만들어 둡니다. 예를 들어 “고객-주문-제품-서비스케이스”라는 4단계 조인을 Data Graph로 정의해두면, Agentforce의 Action이나 Flow가 이 뷰를 밀리초 단위로 조회할 수 있습니다. 이는 단순한 성능 최적화가 아니라 아키텍처적 선택입니다. 실행 계층(에이전트, 자동화)이 데이터 계층의 복잡도를 신경 쓰지 않고도 즉시 판단할 수 있게 만드는 구조이기 때문입니다.
Calculated Insights도 마찬가지 맥락입니다. 일반 CDP에서 “지난 90일간 평균 구매 주기”나 “이탈 위험 점수” 같은 지표는 대개 별도 데이터 웨어하우스나 BI 도구에서 계산되어 CDP로 다시 흘러 들어옵니다. 이 왕복 과정 자체가 지연과 동기화 오류의 원인이 됩니다. Data Cloud는 이런 프로필 단위 계산 지표를 Calculated Insights로 플랫폼 안에서 직접 정의하고, 그 결과를 즉시 Segments나 Agentforce Instructions에서 참조합니다.
이 구조가 의미하는 바는 명확합니다. CDP는 “인사이트를 만드는 도구”이고 Data Cloud는 “인사이트가 실행으로 이어지는 파이프라인”입니다. 마케팅 팀이 세그먼트 하나를 만드는 데는 두 방식 모두 비슷한 노력이 들지만, 그 세그먼트가 콜센터 에이전트의 다음 행동 제안이나 Agentforce의 자율 응답까지 이어지는 데는 결정적 차이가 생깁니다.
Salesforce Data Cloud vs CDP 도입에서 대부분이 빠지는 함정
가장 흔한 실수는 기존 CDP를 그대로 두고 Data Cloud를 “추가 마케팅 도구”로 병렬 도입하는 것입니다. 이 접근은 예산 승인은 쉽지만 아키텍처적으로는 문제를 두 배로 만듭니다. 두 시스템이 각각 다른 Identity Resolution 결과를 만들어내면, 어느 쪽이 진실인지에 대한 논쟁이 조직 내부에 영구적으로 남습니다. Data Cloud를 CRM과 Service Cloud와 통합된 단일 프로필 기반으로 자리잡게 하려면, 처음부터 기존 CDP의 역할을 축소하거나 이관 계획을 명시해야 합니다.
두 번째 함정은 Data Streams 설계를 데이터 이관 프로젝트처럼 취급하는 것입니다. 원천 시스템의 스키마를 그대로 복사해 DMO를 만들면, 나중에 Identity Resolution과 Data Graphs를 설계할 때 정규화 작업을 다시 해야 합니다. DMO 설계는 처음부터 “이 데이터가 어떤 Unified Individual 속성으로 쓰일 것인가”를 전제로 시작해야 하며, 이는 마케팅, 서비스, IT 아키텍트가 함께 정의해야 하는 작업입니다. 이 정의를 마케팅 팀 단독으로 진행하면 Sanofi 규모의 이관 프로젝트에서 관찰되는 것과 유사한 재작업 비용이 발생합니다. 핵심 데이터의 정규화 원칙을 초기에 재사용 가능한 템플릿으로 만들어두면 이런 오류율을 크게 낮출 수 있습니다.
세 번째 함정은 거버넌스 부재입니다. Identity Resolution ruleset을 한 번 설정하고 방치하면, 신규 채널이 추가될 때마다 매칭 정확도가 서서히 저하됩니다. Data Cloud 운영에는 CDP와 달리 정기적인 매칭 감사 프로세스가 필요하며, 이는 조직의 Data Cloud 아키텍처 거버넌스에 포함되어야 할 항목입니다. Data Cloud 전체 아키텍처 설계와 거버넌스 체계에 대한 배경은 Salesforce Data Cloud 아키텍처의 실전 설계 원칙에서 다룬 내용을 참고하는 것이 도움이 됩니다.
마지막으로, Agentforce와의 통합을 나중 단계로 미루는 조직이 많습니다. Data Cloud를 먼저 안정화한 뒤 Agentforce를 붙이겠다는 순서 자체는 합리적이지만, 문제는 Data Graphs와 Calculated Insights를 Agentforce 사용 사례를 고려하지 않고 설계해버리는 경우입니다. 이렇게 되면 Agentforce 도입 시점에 Data Graphs를 다시 정의해야 하는 이중 작업이 발생합니다. 처음부터 Agentforce의 Topics와 Actions가 어떤 데이터 뷰를 필요로 할지 가정하고 Data Graphs를 설계하는 편이 장기적으로 훨씬 적은 재작업을 요구합니다.
핵심 정리
- Salesforce Data Cloud vs CDP의 본질적 차이는 저장 방식이 아니라 실행 계층 통합 여부다. CDP는 세그먼트 생성에서 끝나지만 Data Cloud는 Agentforce와 Flow까지 실시간으로 연결된다.
- Identity Resolution ruleset은 결정론적 규칙과 확률적 규칙을 계층화해 설계해야 하며, 매칭 정확도와 통합률을 승인 기준으로 사전 문서화해야 한다.
- Data Graphs는 자주 쓰이는 조인 패턴을 사전 계산해 에이전트와 자동화가 밀리초 단위로 조회할 수 있게 만드는 아키텍처적 선택이다.
- 기존 CDP를 병렬로 유지한 채 Data Cloud를 추가하면 두 개의 서로 다른 고객 정의가 조직 내에 공존하는 근본적 문제가 생긴다.
- DMO와 Data Graphs 설계는 Agentforce 사용 사례를 처음부터 전제로 삼아야 하며, 그렇지 않으면 도입 후 재작업 비용이 누적된다.
Data Cloud 아키텍처를 CDP 마이그레이션 관점이 아니라 통합 실행 기반 관점에서 설계하려면 초기 진단 단계에서 Identity Resolution 규칙과 Data Graphs 우선순위를 함께 검토하는 것이 중요합니다. 이런 진단과 설계 검토가 필요하다면 Salesforce 딜리버리 서비스에서 구체적인 접근 방식을 확인할 수 있습니다.
