Salesforce Data Cloud 구축을 시작하는 많은 조직이 같은 기대를 합니다. 흩어진 데이터를 한곳에 모으면 단일 고객 뷰가 나온다는 기대입니다. 그런데 구축이 끝나고 나면, 같은 고객이 대시보드에서 여전히 여러 명으로 보입니다. 한 사람의 주문 이력은 세 개의 레코드로 쪼개져 있고, 마케팅과 영업이 보는 고객이 서로 다릅니다. 대부분은 원인을 수집 단계에서 찾습니다. 문제는 수집이 아닙니다. 문제는 Identity Resolution(아이덴티티 레졸루션)과 데이터 모델을 먼저 설계하지 않았다는 데 있습니다.
Data Cloud(데이터 클라우드)는 데이터를 모으는 그릇이 아니라 고객을 하나로 묶는 엔진입니다. 그 엔진의 성패는 데이터를 얼마나 많이 끌어왔느냐가 아니라, 끌어온 데이터를 어떤 규칙으로 한 사람으로 합치느냐에서 갈립니다. 이 글에서는 통합 고객 뷰가 깨지는 구조적 원인을 짚고, 한국 엔터프라이즈가 무엇을 먼저 진단해야 하는지 아키텍처 관점에서 정리합니다.
수집만으로는 통합 뷰가 나오지 않습니다
Data Cloud 구축의 첫 단계는 Data Streams(데이터 스트림) 수집입니다. CRM, ERP, 콜센터, 웹 로그, 마케팅 자동화 도구에서 데이터를 끌어와 Data Lake Object로 받습니다. 여기까지는 대부분의 프로젝트가 무리 없이 도달합니다. 데이터를 연결하고 흘려보내는 일은 커넥터가 처리합니다.
문제는 그다음입니다. 수집된 데이터는 소스마다 고객을 다른 키로 식별합니다. ERP는 거래처 코드로, 콜센터는 전화번호로, 웹은 쿠키 ID로, CRM은 이메일로 같은 사람을 가리킵니다. Data Cloud는 이 키들이 같은 사람을 가리킨다는 사실을 스스로 알지 못합니다. 누군가 규칙으로 알려줘야 합니다. 그 규칙이 없으면, 한 명의 고객은 다섯 개의 소스에서 다섯 명으로 남습니다. 수집은 데이터를 한 플랫폼 안으로 들여놓을 뿐, 한 사람으로 합치지 않습니다.
여기서 많은 팀이 멈춥니다. 데이터는 다 들어와 있는데 단일 뷰가 나오지 않으니, 더 많은 소스를 연결하면 나아질 것이라 기대합니다. 그러나 소스를 늘릴수록 분절은 오히려 심해집니다. 식별 규칙 없이 데이터만 늘리는 일은, 정리되지 않은 서랍에 서류를 더 밀어 넣는 것과 같습니다. 통합은 데이터의 양이 아니라 식별 규칙의 정확도에서 나옵니다.
데이터 모델을 먼저 그려야 합니다
Identity Resolution이 동작하려면 그 아래에 표준 데이터 모델이 있어야 합니다. Data Cloud는 수집한 원천 데이터를 표준 데이터 모델인 DMO(Data Model Object)로 매핑합니다. 어떤 소스 필드가 Individual의 어떤 속성에 대응하는지, 이메일과 전화번호가 어느 DMO의 어느 컬럼으로 들어가는지를 설계자가 선언해야 합니다. 이 매핑이 흐릿하면 Identity Resolution은 비교할 기준 자체를 잃습니다.
실무에서 데이터 모델 설계를 건너뛰는 패턴은 분명합니다. 소스 데이터를 그대로 받아 빠르게 결과를 보려는 압박 때문에, 매핑을 자동 추천에 맡기고 넘어갑니다. 초기에는 데모가 그럴듯하게 나옵니다. 그러나 소스가 늘고 데이터가 쌓이면, 어긋난 매핑이 매칭 정확도를 갉아먹습니다. 어떤 고객은 과하게 합쳐져 다른 사람의 정보가 섞이고, 어떤 고객은 끝내 합쳐지지 않습니다. 두 오류 모두 신뢰를 무너뜨립니다. 과합치기는 잘못된 사람에게 메시지를 보내고, 못 합치기는 같은 사람에게 중복으로 보냅니다.
표준 DMO에 무엇을 매핑할지는 수집 전에 정해야 하는 결정입니다. 데이터가 흘러 들어온 뒤에 모델을 바꾸면, 이미 적재된 데이터를 다시 처리해야 하고 그동안의 매칭 결과를 폐기해야 합니다. 모델을 먼저 그리고 수집을 맞추는 순서가, 수집을 먼저 하고 모델을 끼워 맞추는 순서보다 언제나 빠릅니다. 이 순서를 지키면, 이후의 모든 매칭 개선이 같은 모델 위에서 누적됩니다.
Identity Resolution이 Unified Individual을 만듭니다
데이터 모델이 자리를 잡으면, Identity Resolution ruleset을 설계합니다. ruleset은 어떤 조건이 맞으면 두 레코드를 같은 사람으로 볼지를 정하는 규칙의 묶음입니다. 이메일이 정확히 일치하면 합친다. 전화번호와 이름이 함께 일치하면 합친다. 주소가 비슷하면 후보로 본다. 이런 매칭 규칙(matching rule)과 통합 규칙(reconciliation rule)이 모여, 흩어진 소스 프로필을 하나의 Unified Individual로 묶습니다.
ruleset 설계에는 절충이 있습니다. 규칙을 느슨하게 잡으면 더 많이 합쳐지지만 잘못 합칠 위험이 커집니다. 규칙을 엄격하게 잡으면 오합치는 줄지만 같은 사람을 못 합치는 경우가 늘어납니다. 이 균형점은 비즈니스가 그 데이터로 무엇을 하느냐에 따라 다릅니다. 마케팅 세그먼트는 약간의 오합치를 견디지만, 환불이나 청구 같은 금전 거래는 단 한 건의 오합치도 사고가 됩니다. 그래서 ruleset은 한 번 정하고 끝내는 설정이 아니라, 매칭 결과를 보며 조이고 푸는 반복 작업입니다.
Unified Individual이 만들어지면, 그 위에서 Calculated Insights(계산 인사이트)로 고객별 지표를 집계할 수 있습니다. 최근 90일 구매액, 평균 주문 주기, 이탈 위험 점수 같은 값이 Unified Individual 단위로 계산됩니다. 여기서 핵심은 순서입니다. Identity Resolution이 흔들리면 Calculated Insights도 함께 흔들립니다. 쪼개진 프로필 위에서 계산한 구매액은 실제의 절반밖에 안 되고, 그 잘못된 숫자가 세그먼트와 에이전트의 판단으로 흘러갑니다. 지표는 그 아래 식별 규칙만큼만 정확합니다.
이 구조는 Agentforce 같은 후속 사용처에서 그대로 드러납니다. 에이전트가 고객의 최근 주문을 묻는데 프로필이 쪼개져 있으면, 에이전트는 그중 하나만 보고 답합니다. Data Cloud의 단일 뷰가 부실하면 그 위에 올린 모든 것이 부실해지는 셈입니다. 이 연결 고리는 Agentforce 도입, 파일럿이 프로덕션에서 멈추는 이유에서 더 자세히 다룹니다.
한국 기업이 자주 놓치는 함정
기술 설계가 끝나도 프로덕션 승인이 나지 않는 경우가 많습니다. 한국 엔터프라이즈에는 고유한 통제 지점이 있습니다.
첫 번째는 레거시와 ERP 통합입니다. 국내 대기업의 고객 데이터는 오래된 기간계 시스템과 자체 구축 ERP에 깊이 묶여 있습니다. 거래처 코드 체계가 사업부마다 다르고, 같은 고객이 법인 단위와 사업장 단위로 따로 등록돼 있기도 합니다. 이 키 체계를 Data Cloud의 표준 모델에 어떻게 매핑할지 정하지 않으면, Identity Resolution은 시작도 하기 전에 막힙니다. ERP 통합은 커넥터를 연결하는 기술 작업이 아니라, 서로 다른 식별 체계를 하나의 기준으로 합의하는 데이터 거버넌스 작업입니다.
두 번째는 데이터 품질입니다. 통합 뷰의 정확도는 들어오는 데이터의 품질을 넘어설 수 없습니다. 전화번호 형식이 소스마다 다르고, 이름에 직함이 섞여 있고, 한 거래처가 철자만 다르게 여러 번 등록돼 있으면, 아무리 정교한 ruleset도 이들을 안정적으로 묶지 못합니다. 데이터 품질 정리를 수집과 분리된 별도의 단계로 두고, 표준화 규칙을 수집 경로에 넣어야 합니다. 정제 없이 들어온 데이터는 통합 뷰가 아니라 통합된 오류를 만듭니다.
세 번째는 개인정보 보호법(PIPA)입니다. Data Cloud는 본질적으로 흩어진 개인 데이터를 한 사람 단위로 묶는 작업입니다. 그래서 수집 근거, 처리 위탁, 국외 이전 동의가 정리돼 있지 않으면 그 자체로 규제 위험이 됩니다. 어떤 데이터를 어느 목적으로 통합하는지, 통합된 프로필이 어디에 쓰이는지를 보안팀이 검토할 수 있게 문서로 만들어 두지 않으면, 기술이 준비돼도 승인 단계에서 멈춥니다. 품의 결재선에 올릴 때 이 문서가 없으면, 검토는 다음 분기로 넘어갑니다. PIPA 검토를 구축 막바지에 시작하는 대신, 데이터 모델을 그리는 단계에서 보안팀과 통합 범위를 먼저 합의하는 편이 일정을 지킵니다.
진단을 시작하는 순서
세 계층을 동시에 손대면 어디서 효과가 났는지 알 수 없습니다. 순서가 중요합니다.
먼저 통합이 답해야 하는 질문 목록을 만듭니다. 단일 고객 뷰로 무엇을 하려는지, 어떤 세그먼트와 지표가 필요한지를 스무 개쯤 적습니다. 이 목록이 데이터 모델의 범위를 정하고, 어떤 소스를 어떤 정확도로 묶어야 하는지를 알려 줍니다. 다음으로 각 질문에 필요한 데이터가 어느 소스에 있고 어떤 키로 식별되는지를 표시합니다. 키 체계가 어긋나는 지점이 곧 Identity Resolution이 가장 먼저 풀어야 할 지점입니다.
그다음에 표준 데이터 모델을 그리고, 소스 매핑을 확정하고, ruleset을 설계합니다. 수집은 이 설계가 자리를 잡은 뒤에 시작합니다. 데이터 품질 정제는 수집 경로 안에 넣어, 오염된 데이터가 통합 단계에 닿기 전에 걸러냅니다. 마지막으로 Unified Individual 위에서 Calculated Insights를 얹습니다. 이 순서를 지키면, 각 단계의 효과를 따로 측정할 수 있고 매칭이 틀어졌을 때 어느 계층의 문제인지 분리해서 볼 수 있습니다.
이 진단은 한 번에 끝나는 작업이 아닙니다. 통합 범위는 비즈니스가 단일 뷰로 하려는 일이 넓어질수록 함께 자랍니다. 그래서 처음부터 모든 소스를 묶으려 하기보다, 가장 가치가 큰 두세 개 소스로 시작해 모델과 ruleset을 단단히 다지고, 그 위에서 소스를 더해 가는 방식이 현실적입니다. 좁게 시작해 단단하게 넓히는 편이, 넓게 시작해 어디가 약한지 모르는 것보다 빠릅니다.
핵심 정리
Salesforce Data Cloud 구축의 성패는 데이터를 얼마나 모으느냐가 아니라, 그 데이터를 어떤 규칙으로 한 사람으로 합치느냐에서 갈립니다. 정리하면 다음과 같습니다.
- 통합 뷰가 쪼개져 보이면 수집량이 아니라 Identity Resolution ruleset과 데이터 모델부터 봅니다.
- 표준 DMO 매핑은 수집 전에 확정합니다. 수집 후에 모델을 바꾸면 적재된 데이터를 다시 처리해야 합니다.
- Calculated Insights는 Unified Individual만큼만 정확합니다. 식별이 흔들리면 모든 지표가 흔들립니다.
- 레거시·ERP 키 매핑, 데이터 품질 정제, PIPA 통제는 구축 초기에 합의합니다. 막바지에 시작하면 일정이 무너집니다.
지금의 Data Cloud 설계가 이후 모든 사용처의 정확도를 결정합니다. 데이터 모델과 식별 규칙을 초기에 정리한 조직은 새 사용 사례를 더할 때마다 같은 단일 뷰를 재사용합니다. 반대로 수집부터 서둘러 시작한 조직은 사용처가 늘 때마다 같은 분절 문제를 다시 만납니다. 한쪽은 시간이 지날수록 빨라지고, 다른 쪽은 느려집니다. 모이기만 한 데이터가 아니라 한 사람으로 합쳐진 데이터를 목표로 한다면, Identity Resolution 설계와 데이터 모델부터 그려야 합니다. 진단의 범위와 산출물은 Data Cloud 데이터 기반 진단·설계에 정리해 두었습니다.
