법적으로 무엇이 먼저 걸리나

브랜드가 별개 법인이라면 브랜드 A가 수집한 고객 데이터를 브랜드 B가 쓰는 것은 대체로 제3자 제공입니다. 광고 플랫폼에 데이터를 제공할 때 제3자 제공에 대한 별도의 명시적 동의가 필수이고 수집·이용 동의만으로는 불충분하다는 원칙이 여기에도 그대로 적용됩니다.

같은 법인 안의 브랜드라 해서 자유로운 것도 아닙니다. 개인정보 보호법 제15조는 수집·이용에 명시적 동의를 요구하고, 제22조는 처리 목적별로 구분해 동의를 받도록 규정합니다. 브랜드 A의 가입 화면에서 "A 서비스 이용을 위해"라고 고지하고 받은 데이터를 브랜드 B의 마케팅에 쓰면 고지한 목적 범위를 벗어납니다. 통합 논의는 아키텍처 회의가 아니라 동의 문구 검토에서 시작해야 하는 이유입니다.

통합의 실익을 무엇으로 판단하나

법적 근거를 만들 수 있다고 해도 통합이 항상 이득은 아닙니다. 판단 근거는 고객이 실제로 브랜드를 넘나드는 비율입니다. 브랜드 A와 B 양쪽에 구매 이력이 있는 고객의 비율이 낮다면, 통합해도 새로 만들어지는 세그먼트는 거의 없고 비용만 늘어납니다.

이 비율은 통합 전에도 추정할 수 있습니다. 양쪽 회원 명단에서 동일한 연락처가 겹치는 건수를 세면 상한선이 나옵니다. 이때 표기 형식이 다르면 겹침이 실제보다 적게 나오므로, 앞뒤 공백 제거와 형식 정규화를 먼저 적용해야 합니다. 광고 매체의 고객 리스트 매칭에서 정규화 규칙을 어기면 매칭률이 급격히 떨어진다고 안내하는 것과 같은 이유입니다.

중간안은 어떤 형태인가

선택지는 전면 통합과 완전 분리 둘만 있는 것이 아닙니다. 세 번째 안은 식별자 층만 공유하고 행동·구매 데이터는 브랜드별로 분리해 두는 구조입니다. 이 구조에서는 "이 사람이 다른 브랜드 고객이기도 하다"는 사실만 알 수 있고, 무엇을 얼마에 샀는지는 넘어가지 않습니다.

이 안이 유용한 경우는 브랜드 간 중복 발송을 막는 것이 주된 목적일 때입니다. 같은 사람에게 세 브랜드가 각각 메시지를 보내 하루에 세 건이 나가는 상황은 식별자 연결만으로도 통제할 수 있습니다. 반대로 브랜드 간 교차 추천이 목적이라면 구매 데이터가 함께 넘어가야 하므로 중간안으로는 부족하고, 그때는 동의 설계를 다시 해야 합니다.

아키텍처를 나눌 때 무엇을 기준으로 삼나

CDP 제품 자체에도 이 구분이 반영돼 있습니다. Adobe Real-Time CDP는 Identity Resolution과 프로필 통합에 데이터 거버넌스와 동의 이행을 함께 묶어 제공하고, Salesforce Data Cloud는 매칭·정합 규칙을 룰셋으로 관리합니다. 즉 어느 데이터를 어느 범위까지 합칠지를 설정으로 통제할 수 있는 구조입니다.

다만 설정으로 나눴다고 법적 구분이 자동으로 만족되는 것은 아닙니다. 한 인스턴스 안에 브랜드별 영역을 나누는 방식과, 브랜드마다 별도 인스턴스를 두는 방식은 비용과 통제 수준이 다릅니다. 어느 쪽이든 브랜드 담당자가 다른 브랜드의 데이터를 조회할 수 없도록 접근권한을 나누는 것이 실제 통제의 핵심입니다. 개인정보보호위원회가 접근권한 최소 부여와 업무 변경 시 권한 변경·말소, 계정 공유 여부를 점검 항목으로 다루는 것도 같은 맥락입니다.

통합 이후 수신거부를 어떻게 관리하나

통합하고 나면 새로운 문제가 생깁니다. 고객이 브랜드 A의 메시지를 거부했을 때 브랜드 B의 메시지까지 멈춰야 하는지입니다. 수신동의는 전송자를 기준으로 하므로 브랜드별 거부와 전체 거부를 구분해 받는 구조가 필요합니다.

실무에서는 거부 화면에 두 선택지를 함께 제시하고, 프로필에는 브랜드별 상태와 전체 상태를 별도 필드로 저장합니다. 발송 직전 억제 조회에서는 두 필드를 모두 확인합니다. 수신거부·동의철회 이후의 전송 금지는 정보통신망법 제50조 제2항에 따른 의무이므로 이 판정에 지연이 있으면 안 되고, 통합 환경에서는 브랜드 하나만 반영되고 다른 브랜드에서 누락되는 사고가 특히 나기 쉽습니다.