피드로 돌아가기
How We Accidentally Built a Customer Data Platform
Dev.toDev.to
Backend

다중 소스 ID 파편화 해결을 통한 고밀도 Identity Resolution 레이어 설계

How We Accidentally Built a Customer Data Platform

Higgie2026년 5월 6일11intermediate

Context

서로 다른 ID 체계를 가진 CallRail, Intaker 등 다수 외부 시스템의 데이터 통합 과정에서 식별자 불일치 발생. 단순 대시보드 구축 목적에서 데이터 정합성 보장을 위한 CDP 수준의 Identity Resolution 아키텍처 설계로 전환한 사례.

Technical Solution

  • Phone platform API 기반의 COM-prefixed UUID를 Canonical Identifier로 채택하여 전 시스템 단일 네임스페이스 구축
  • Phone numeric ID, Vendor slug, Domain, Sender email을 허브-스포크 모델의 Resolution Graph로 연결하여 매핑 로직 구현
  • API(UUID)와 Webhook(Numeric ID) 간의 포맷 불일치 해결을 위한 composite primary key 기반의 Translation Table 도입
  • 'Resolve before Write' 원칙을 적용하여 식별 불가능한 레코드를 Primary Store 진입 전 Quarantine Table로 격리
  • 40개 이상의 불변성(Invariants)을 정의한 Engineering Constitution을 통해 장애 기반의 시스템 안정성 확보

Impact

  • Translation Table 도입을 통해 누락되었던 212건의 Call 데이터 가시성 확보
  • 13개 계정 전반에 걸친 189개의 매핑 데이터를 통해 데이터 정합성 복구

1. 다중 소스 데이터 통합 시 최상위 Canonical ID 네임스페이스를 먼저 정의했는가

2. 외부 시스템의 API와 Webhook 간 ID 포맷 차이를 검증하고 Translation Layer를 설계했는가

3. 식별되지 않은 데이터가 메인 DB를 오염시키지 않도록 Quarantine 메커니즘을 갖추었는가

4. Identity Lifecycle 관리를 위한 Merge 및 Tombstone 처리 전략이 존재하는가

원문 읽기