오늘은 Data 360 파트였다. 참고로 Data 360은 Salesforce Data Cloud의 새 명칭이다. Customer Data Platform(CDP) → Genie → Data Cloud → Data 360 순으로 이름을 계속 바꿔왔는데 같은 제품이다. 그래서 앱 실행기에서는 여전히 "Data Cloud"로 표시되고, 이 글에서도 두 이름이 혼용된다.
어제가 에이전트 만드는 날이었다면, 오늘은 그 에이전트가 쓸 데이터를 어떻게 통합하고 관리하는지 보는 날. 근데 솔직히 말하면 오늘이 훨씬 어려웠다. 개념도 낯설고 연습문제도 11개나 됐고, 세팅도 바로바로 되지 않고 시간이 좀 걸렸다. 중간중간 가이드 복붙해도 오류나고... 오늘 꽤 오래걸렸다 ㅜ
오늘의 핵심 개념 — 그래서 Data 360이 뭐임?
실습 전에 개념부터 정리하고 가야 할 것 같다. 나도 하면서 계속 "이게 왜 필요하지?"를 반복했으니까.
문제: 데이터가 여기저기 흩어져 있다
실습용 가상 회사인 Pronto를 예로 들면, 고객 데이터가 이렇게 나뉘어 있다.
- Salesforce: 고객 연락처 (Contact)
- Amazon S3: 고객 계정 데이터, 주문 데이터
같은 고객인 Alex Morgan이 Salesforce에도 있고 S3에도 있는데, 각자 다른 ID로 저장돼 있다. 시스템이 이걸 같은 사람인지 모른다. 이 상태에서 AI 에이전트한테 "Alex Morgan 주문 내역 보여줘"라고 하면 제대로 된 답이 안 나온다.
해결: Data 360이 다 모아준다
Data 360(= Salesforce Data Cloud)은 여러 소스의 데이터를 하나의 통합 프로필로 합쳐주는 플랫폼이다. 흐름을 요약하면 이렇다.
[Salesforce CRM] ──┐
├──▶ Data 360 수집 ──▶ 공통 데이터 모델 매핑 ──▶ ID 통합 ──▶ Salesforce 활성화
[Amazon S3] ──┘이걸 하고 나면 Salesforce에서 고객 하나를 클릭했을 때 S3에 있던 주문 데이터까지 같이 보인다. 에이전트도 당연히 이 통합된 데이터를 쓸 수 있게 됨.
핵심 개념 3가지
실습 내내 이 세 가지가 계속 나왔는데, 헷갈려서 정리해봤다.
| 개념 | 약자 | 설명 |
|---|---|---|
| Data Lake Object | DLO | 외부에서 가져온 원본 데이터 그대로. 창고에 쌓아둔 박스 느낌 |
| Data Model Object | DMO | DLO를 공통 규격에 맞게 정리한 것. 박스 내용물을 규격 선반에 정리한 것 |
| Customer 360 Data Model | - | DMO들이 따르는 공통 규격. Individual, Contact Point 같은 표준 객체들 |
쉽게 말하면: DLO는 원재료, DMO는 가공품, Customer 360 모델은 그 가공 규격이다.
실습 1 — CRM 커넥터로 Salesforce 연락처 가져오기
Data Cloud 앱에서 Data Streams 탭 → New → Salesforce CRM 커넥터 선택.
여기서 Object Bundle이라는 걸 쓰는데, Account, Contact, Lead 같은 관련 객체들을 한 번에 묶어서 가져오는 방식이다. 하나하나 따로 설정 안 해도 돼서 편함.
배포하고 나면 Contact_Home이라는 DLO가 생긴다.
그다음에 이 DLO가 Customer 360 데이터 모델에 어떻게 매핑됐는지 확인했는데, Contact 하나가 무려 5개의 DMO에 쪼개져서 들어간다.
- Individual — 이름, 생일 같은 개인 기본 정보
- Account Contact — 계정과의 관계
- Contact Point Email — 이메일 주소
- Contact Point Phone — 전화번호
- Contact Point Address — 주소
처음엔 왜 이렇게 쪼개나 싶었는데, 다른 시스템에서 같은 이메일로 고객을 찾을 때 Contact Point Email만 보면 되니까 여러 소스를 합치기가 훨씬 쉬워진다.
실습 2 — Amazon S3 연결 만들기
Data Cloud 설정에서 Other Connectors → Amazon S3 선택 후 연결 정보 입력. Access Key, Secret Key, 버킷 이름 넣고 연결 테스트 후 저장.
이건 설정 자체는 간단했다. 다음 실습에서 이 연결을 써서 데이터를 가져옴.
실습 3 — S3에서 고객 데이터 가져오기
pronto_customer_accounts.csv 파일을 S3에서 가져와서 Customer Accounts라는 DLO를 만들었다.
여기서 중요한 설정이 몇 개 있었다.
- Category: Profile — 이 데이터가 "사람"에 대한 정보라는 선언
- Primary Key: customerId — 각 레코드를 구분하는 고유 키
- 이메일, 전화번호 필드 타입을 Email, Phone으로 명시적으로 지정
그다음 이 DLO를 Customer 360 모델에 매핑. Salesforce Contact가 5개 DMO에 매핑됐던 것처럼, 여기서도 Individual이랑 Contact Point Email에 매핑했다. 두 소스가 같은 DMO를 공유하게 되는 게 포인트.
매핑 테이블이 좀 복잡했는데 핵심만 보면:
| DLO 필드 | 매핑 대상 DMO | DMO 필드 |
|---|---|---|
| Customer Id | Contact Point Email | Contact Point Email Id / Party |
| Contact Point Email | Email Address | |
| Customer Id | Individual | Individual Id |
| First Name | Individual | First Name |
| Last Name | Individual | Last Name |
Customer Id 하나가 두 군데 들어가는 게 헷갈렸는데, Contact Point Email의 Party 필드가 "이 이메일이 어떤 Individual 것인지"를 연결해주는 외래키 역할을 한다.
실습 4 — S3에서 주문 데이터 가져오기
pronto_order_data.csv 파일로 Order DLO 생성.
여기서 Customer 360 모델과 다른 점이 하나 있었다. 주문(Order)에 해당하는 표준 DMO가 없다. Customer 360 모델은 "사람" 중심으로 설계되어 있어서, 주문처럼 업종별로 다른 개념은 Custom DMO를 직접 만들어야 한다.
Order DLO에서 데이터 매핑 시작 → Custom Data Model 탭 → New Custom Object. DLO 기반으로 자동 생성되니까 필드 매핑은 알아서 됨.
그리고 Order DMO와 Individual DMO 사이에 N:1 관계를 만들었다. 주문 여러 개가 한 사람한테 속하는 구조. 관계 설정하고 나서 데이터 모델을 그래프로 보면 선으로 연결된 게 보인다. 이게 시각적으로 보이니까 좀 신기하고 복잡해보임.
실습 5 — 중복 프로필 합치기 (ID Resolution)
이게 오늘의 하이라이트였다. 개념 이해가 제일 안 됐던 파트이기도 하고.
상황 파악
Data Explorer에서 Individual DMO를 조회해보면, Alex Morgan이 두 개가 나온다.
- Salesforce에서 온 Alex Morgan (Individual ID = Salesforce Record ID)
- S3에서 온 Alex Morgan (Individual ID = 고객 ID) 합쳐야 에이전트가 "Alex Morgan의 주문"을 제대로 가져올 수 있다.
ID Resolution이 하는 일
ID Resolution(신원 확인)은 이름이랑 이메일 같은 속성을 비교해서 "이 두 레코드는 같은 사람이다"를 판단하고 Unified Individual이라는 통합 레코드를 만들어준다.
규칙 세트 만들 때 선택한 매칭 방법이 두 가지였다.
- Fuzzy Name: 이름이 살짝 달라도 ("Alex" vs "Alexander") 같은 사람으로 인식
- Normalized Email: 이메일 주소 정규화해서 비교 (대소문자, 공백 같은 거 무시)
이걸 실행하면 기존 Individual 두 개는 그대로 있고, 거기서 파생된 Unified Individual ccid라는 통합 레코드가 새로 생긴다. 기존 레코드가 사라지는 게 아니라 "두 개가 같은 사람"이라는 링크가 만들어지는 것.
ID Resolution 실행하고 Data Explorer에서 다시 조회하면 이제 Alex Morgan이 하나로 보임.
실습 6 — Salesforce에서 통합 데이터 보기
Data 360에서 합쳐진 데이터를 Salesforce로 "활성화"하는 단계.
Data Cloud 관련 목록을 만들어서 Alex Morgan 연락처 페이지에 주문 목록이 뜨도록 설정했다. 그냥 관련 목록은 최근 7일치만 보여주는 기본 제한이 있어서, 동적 관련 목록으로 필터를 따로 걸어줬다.
Order Date가 빈 값이 아닌 것만 보여줘라 → 결과적으로 전체 주문이 다 나옴.
연락처 페이지에 S3에 있던 주문 데이터가 뜨는 걸 보니까 "아 이래서 Data 360을 쓰는 거구나" 싶었다. Salesforce 안에 없는 데이터가 Salesforce UI에서 보이는 거니까.
실습 7~8 (선택) — 계산된 인사이트
이건 선택 실습인데 나는 다 따라했다.
Calculated Insights(계산된 인사이트)는 Data 360에 있는 데이터를 집계해서 새로운 값을 만드는 기능. SQL의 GROUP BY + 집계 함수랑 비슷한 느낌.
만든 것:
- Lifetime Orders: 고객이 총 몇 번 주문했는지 (COUNT)
- Lifetime Value: 고객이 전체 주문에서 얼마를 썼는지 (SUM)
이걸 고객별로 집계하려면 Unified Individual을 기준으로 묶어야 한다. Individual(중복 포함)로 묶으면 같은 고객이 두 번 집계될 수 있으니까.
계산이 끝나면 Copy Fields 기능으로 이 값들을 Salesforce Contact 필드에 복사해줬다. 이제 Alex Morgan 연락처 페이지에서 Lifetime Value, Lifetime Orders 값이 바로 보임.
실습 9~10 (선택) — 보고서랑 Flow
보고서(실습 9): Data 360 카테고리에서 "Customer with Orders" 보고서 유형을 고르면 Data 360 데이터를 Salesforce 보고서에서 쓸 수 있다. 행 수준 수식으로 "주문일로부터 며칠 지났는지"도 계산해봤다.
Flow(실습 10): Case 레코드에서 버튼 하나로 Flow를 실행하면, CRM 데이터 + Data 360 주문 데이터를 동시에 가져와서 화면에 보여주고 후속 작업(Task)까지 만들어주는 흐름을 만들었다. 실제 업무에서도 쓸 수 있을 것 같은 패턴이었다.
실습 11 (선택) — SOQL로 Data 360 데이터 조회하기
가이드에는 Code Builder 앱으로 하라고 나와 있는데, org에 Code Builder가 없었다. 그래서 VS Code로 대신 했다.
Individual 데이터는 잘 됐는데 Orders 쿼리는 VS Code에서도 안 됐다. Data Model Object는 SOQL 쿼리에 제한이 있어서 일반 환경에서는 조회가 잘 안 된다고... 결국 Data Cloud 앱 안에 있는 Query Editor 탭에서 조회했다.
오늘 가장 고생한 것 — order__dlm vs orders__dlm
실습 내내 가이드에서 복붙하면 오류가 나는 경우가 있었는데, 이유가 있었다. 가이드에는 orders__dlm으로 나와 있는데, 내 org에서 만들어진 DLO 이름이 order__dlm이었던 것.
Salesforce가 API 이름을 자동으로 만들 때 어떻게 생성하는지, 아니면 내가 뭔가 다르게 입력한 건지 정확한 원인은 잘 모르겠는데, 어쨌든 가이드 그대로 복붙하면 나한테는 안 맞는 케이스가 있었다.
오늘 배운 것 정리
오늘 전체 흐름을 한 줄로 정리하면 이렇다.
데이터를 수집하고(Data Stream) → 공통 규격에 맞추고(DMO 매핑) → 같은 사람을 하나로 합치고(ID Resolution) → Salesforce에 다시 꺼내 쓴다(활성화)
개념적으로는 이해가 됐는데, 막상 따라 하면서는 왜 이 필드가 여기에 매핑되는지, 왜 이 DMO가 필요한지 계속 헷갈렸다. 한 번 더 해봐야 제대로 익힐 것 같은 파트다.
내일은 Prompt Builder랑 RAG라고 한다. 에이전트한테 데이터를 어떻게 잘 먹이는지 보는 파트인 것 같은데, 내일은 칼퇴할 수 있기를... 🙏
