구현 조건 및 데이터 파이프라인 설계: 각 채널에서 실시간으로 발생하는 원시 데이터를 CDP 핵심 서버 API로 전송하는 웹훅(Webhook) 및 SDK 인프라

CDP 도입 실무에서 가장 먼저 해야 할 일은 벤더를 고르는 게 아니라, 우리 조직의 데이터가 소스 시스템에서 CDP까지 어떤 경로로 흐를지 그려보는 것입니다. Salesforce Data Cloud 공식 문서는 이 흐름을 세 단계로 정리합니다—먼저 Data Streams가 CRM·마케팅 플랫폼·데이터 레이크 등 소스 시스템의 데이터를 Data Lake Objects(DLO)라는 원시 데이터 영역으로 수집하고, 이어서 Data Transforms가 이 원시 데이터를 정제·정규화하며, 마지막으로 Identity Resolution이 정제된 데이터에 매칭 규칙을 적용해 통합 프로필을 만듭니다. 이 3단계 구조는 Salesforce만의 특수한 방식이 아니라 대부분의 CDP가 공통으로 따르는 일반 원리이므로, 다른 벤더를 쓰더라도 이 순서로 설계를 시작하는 게 안전합니다.

수집 방식은 데이터의 성격에 따라 갈립니다. 웹사이트·앱에서 발생하는 클릭·스크롤·화면 진입 같은 행동 데이터는 대개 클라이언트 SDK(자바스크립트 SDK, 모바일 SDK)를 페이지·앱에 심어 실시간으로 전송합니다. 반면 결제 완료, 배송 상태 변경처럼 서버(백엔드)에서 발생하는 이벤트는 서버사이드 API 호출이나 웹훅(Webhook)으로 보내는 것이 일반적입니다. 웹훅은 특정 이벤트가 발생했을 때 외부 시스템(CDP)의 지정된 엔드포인트로 자동 HTTP 요청을 보내는 방식으로, 결제 시스템·CRM처럼 CDP가 직접 폴링(polling)하기 어려운 외부 시스템의 이벤트를 실시간에 가깝게 전달하는 데 씁니다. CRM 데이터나 과거 거래 이력처럼 실시간성이 필요 없는 대량 데이터는 배치 커넥터(Data Streams류)로 정기 동기화하는 것이 일반적입니다.

파이프라인을 설계할 때 가장 자주 간과되는 부분이 식별자(identifier) 표준화입니다. 웹은 쿠키 기반 익명 ID, 앱은 기기 ID, 회원 시스템은 회원번호, POS는 멤버십 카드번호를 쓰는 식으로 시스템마다 식별자 체계가 다르면, 아무리 데이터를 잘 모아도 이후 Identity Resolution(8강에서 자세히 다룹니다) 단계에서 같은 사람인지 판단할 공통 기준이 없어 정확도가 떨어집니다. 따라서 파이프라인 설계 단계에서부터 "이메일은 소문자로 정규화한다", "전화번호는 국가 코드를 포함한 E.164 형식으로 통일한다" 같은 규칙을 미리 정해 각 시스템의 전송 스펙에 반영해두는 것이, 나중에 정제 단계에서 다시 손보는 것보다 훨씬 적은 비용으로 끝납니다.

CDP 벤더 대부분은 웹·iOS·안드로이드용 SDK와 서버사이드 API를 기본 제공하지만, 실제 설치·검증은 개발팀 리소스가 필요한 작업입니다. 실무에서는 우선순위를 정해 단계적으로 진행하는 것이 현실적입니다—먼저 핵심 전환 이벤트(회원가입, 구매) 몇 개만 SDK로 심어 데이터가 실제로 CDP에 들어오는지 검증하고, 이후 세부 행동 이벤트(장바구니 담기, 특정 페이지 조회)를 추가하는 순서입니다. 처음부터 모든 이벤트를 한 번에 설계·구현하려 하면 개발 일정이 지연되고, 정작 마케팅팀이 당장 필요한 핵심 세그먼트조차 만들 데이터가 없는 상태로 오래 머물게 됩니다.