Salesforce Data Cloud 데이터 마이그레이션은 기술 문제가 아니라 설계 문제다. 대부분의 실패는 소스 시스템 데이터를 그대로 옮기려는 시도에서 시작된다. Data Cloud는 데이터 웨어하우스가 아니다. 그 차이를 무시하면 마이그레이션 완료 후에도 Unified Individual(통합 개인 프로필)이 제대로 생성되지 않고, Segment(오디언스 세그먼트)는 예상 모수의 30~40%만 반환하는 상황이 반복된다.
왜 Data Cloud 마이그레이션은 일반 ETL과 다른가
레거시 CDP나 DMP에서 Data Cloud로 이행할 때 가장 흔한 오판은 “데이터를 옮기면 기능이 따라온다”는 가정이다. Data Cloud의 핵심 가치는 데이터 보관이 아니라 Identity Resolution(신원 통합)과 실시간 활성화에 있다. 이 두 기능은 소스 데이터의 구조와 품질에 직접 의존한다.
Data Cloud의 데이터 수집 경로는 Data Streams(데이터 스트림)다. Data Streams는 단순한 파이프라인이 아니라 Data Model Objects(DMO, 정규화된 데이터 엔터티)에 매핑되는 구조화된 수집 레이어다. 소스 시스템의 스키마를 DMO에 매핑하지 않고 플랫 파일로 밀어 넣으면, 데이터는 들어오지만 Identity Resolution ruleset이 참조할 수 있는 표준 필드가 없어 통합 프로필이 생성되지 않는다.
엔터프라이즈 환경에서 레거시 시스템 7개 이상에 걸친 마이그레이션을 설계할 때, 소스별 식별자 체계가 다른 경우가 대부분이다. 이메일, 전화번호, 쿠키 ID, 멤버십 번호가 각각 다른 시스템에 분산되어 있고, 어떤 시스템도 단독으로 완전한 프로필을 갖고 있지 않다. 이 상황에서 마이그레이션 순서와 Identity Resolution ruleset 설계는 분리할 수 없는 하나의 문제다.
Identity Resolution Ruleset을 마이그레이션 전에 설계해야 하는 이유
Identity Resolution은 마이그레이션 완료 후 설정하는 사후 작업이 아니다. Ruleset 설계가 Data Streams의 매핑 구조를 결정하고, 매핑 구조가 소스 데이터 정제 범위를 결정한다. 이 순서를 뒤집으면 데이터를 두 번 처리하게 된다.
실용적인 접근은 다음 순서다.
- 소스 시스템별 식별자 인벤토리 작성 (이메일 유효성 비율, 전화번호 형식 일관성, 고유 ID 존재 여부)
- Identity Resolution의 매칭 우선순위 결정 (결정론적 매칭 우선, 확률론적 매칭 보완)
- 매칭에 사용할 필드를 DMO 표준 필드에 매핑
- 해당 필드가 소스에서 정제된 상태로 들어오도록 Data Streams 전처리 정의
결정론적 매칭(이메일 정확 일치, 전화번호 정규화 후 일치)만으로 커버되지 않는 레코드 비율이 20%를 넘으면, 확률론적 매칭 임계값 설정에 신중해야 한다. 임계값을 낮추면 허위 통합(false merge)이 발생하고, 이를 되돌리는 작업은 마이그레이션 자체보다 복잡해진다.
Data Cloud Identity Resolution의 중복 처리 메커니즘에서 ruleset 설계의 기술적 세부를 다루고 있다. 마이그레이션 설계 전에 참고할 것을 권장한다.
마이그레이션 단계별 아키텍처 패턴
1단계: 소스 데이터 프로파일링과 DMO 매핑 설계
소스 시스템마다 Data Streams를 별도로 정의한다. 하나의 Data Stream에 여러 소스를 혼합하면 Identity Resolution 디버깅이 불가능해진다. 소스별로 분리하면 어느 시스템의 데이터 품질 문제가 통합 프로필에 영향을 주는지 추적할 수 있다.
DMO 매핑에서 가장 중요한 결정은 Individual(개인) DMO와 Contact Point(연락처) DMO의 관계 설정이다. 소스 시스템이 개인과 연락처를 1:1로 관리했더라도, Data Cloud에서는 한 Individual이 여러 Contact Point를 가질 수 있도록 설계해야 한다. 이 구조가 Identity Resolution의 전제 조건이다.
2단계: 배치 수집과 실시간 수집의 분리
마이그레이션 초기에는 배치 수집(Bulk API 또는 S3 기반 Data Stream)으로 히스토리 데이터를 적재하고, 실시간 수집(Platform Events 또는 Streaming API 기반 Data Stream)은 별도 파이프라인으로 운영한다. 두 경로를 혼합하면 히스토리 데이터 적재 중 실시간 이벤트가 불완전한 프로필에 결합되어 Calculated Insights(계산 지표) 결과가 왜곡된다.
히스토리 데이터 적재 완료 후 Identity Resolution을 전체 실행하고, 그 결과를 검증한 뒤 실시간 파이프라인을 연결하는 순서가 안전하다. 접점 3,000개 이상 규모의 리테일 환경에서 이 순서를 지키지 않으면, 실시간 활성화 지연이 정상 범위(2~5분)를 벗어나 10분 이상으로 늘어나는 경우가 관찰된다.
3단계: Calculated Insights와 Segment 검증
데이터 적재와 Identity Resolution 완료 후, Calculated Insights를 재계산하기 전에 Unified Individual 수를 소스 시스템의 예상 고유 고객 수와 비교한다. 허용 오차는 조직마다 다르지만, 10% 이상 차이가 나면 Identity Resolution ruleset을 재검토해야 한다.
Segment 검증은 단순 카운트가 아니라 샘플 프로필 검사로 진행한다. Segment가 반환하는 모수가 맞더라도 개별 프로필의 Contact Point가 올바르게 통합되지 않으면, 이메일 활성화 시 중복 발송이 발생한다. 이는 개인정보 보호법(PIPA) 관점에서도 문제가 된다. 동의 없이 동일인에게 중복 발송된 경우, 수신 동의 관리 기록과 실제 발송 기록 간 불일치가 발생하기 때문이다.
마이그레이션에서 가장 많이 틀리는 지점
동의 데이터 처리를 마지막으로 미루는 것. 수신 동의, 마케팅 동의, 데이터 처리 동의는 마이그레이션 설계 초기에 DMO 구조에 반영해야 한다. Data Cloud의 Consent DMO는 소스 시스템의 동의 필드와 직접 매핑되지 않는 경우가 많다. 동의 데이터를 나중에 추가하면 이미 생성된 Unified Individual에 동의 상태를 역으로 연결하는 작업이 필요하고, 이 과정에서 동의 이력이 손실될 수 있다.
Data Graphs(데이터 그래프) 설계를 적재 후로 미루는 것. Data Graphs는 사전 계산된 조인 구조로, Agentforce(에이전트포스)나 Prompt Builder(프롬프트 빌더)가 실시간으로 프로필 컨텍스트를 참조할 때 사용한다. 마이그레이션 완료 후 Data Graphs를 설계하면, 어떤 DMO 관계를 구체화해야 하는지 판단하기 위해 데이터 구조를 다시 검토해야 한다. 마이그레이션 설계 단계에서 Data Graphs의 참조 패턴을 미리 정의하면 DMO 관계 설계가 더 명확해진다.
소스 시스템 종료 시점을 마이그레이션 완료와 동일시하는 것. Data Cloud에서 Segment와 Calculated Insights가 안정적으로 동작하는 것을 확인하기 전까지 소스 시스템을 병행 운영해야 한다. 병행 기간 동안 두 시스템의 고유 고객 수, 활성 Segment 모수, 주요 지표를 일별로 비교하는 검증 프로세스가 필요하다. 이 기간은 데이터 규모와 Identity Resolution 복잡도에 따라 다르지만, 800만 건 이상의 레코드를 처리하는 환경에서는 최소 4~6주를 확보하는 것이 현실적이다.
Data Cloud 아키텍처 전반의 설계 원칙은 Data Cloud 아키텍처 서비스에서 확인할 수 있다.
핵심 정리
- Identity Resolution ruleset은 마이그레이션 설계의 입력값이다. 완료 후 설정하는 것이 아니라, DMO 매핑과 소스 데이터 정제 범위를 결정하는 선행 조건이다.
- 소스별 Data Streams 분리는 디버깅 가능성을 결정한다. 혼합 수집은 데이터 품질 문제의 출처를 추적 불가능하게 만든다.
- 배치 수집과 실시간 수집은 마이그레이션 단계에서 분리 운영해야 한다. 히스토리 적재 완료 및 Identity Resolution 검증 후 실시간 파이프라인을 연결하는 순서가 안전하다.
- 동의 데이터는 초기 DMO 설계에 포함해야 한다. PIPA 준수 관점에서 동의 이력 손실은 사후 복구가 어렵다.
- 소스 시스템 병행 운영 기간을 계획에 명시해야 한다. 800만 건 이상 규모에서 최소 4~6주의 검증 기간이 필요하며, 이 기간을 생략하면 활성화 오류가 운영 환경에서 발견된다.
