왜 원시 데이터를 그대로 넘기면 안 되나

이메일·전화번호 같은 원시 개인정보를 광고 매체 서버에 평문 그대로 전달하면, 매체가 그 데이터를 어떻게 저장·활용하는지에 대한 통제권을 광고주가 사실상 잃게 됩니다. 해시 매칭은 이 문제를 기술적으로 줄이는 방식입니다. 광고주와 매체 양쪽이 동일한 해시 알고리즘(SHA-256)으로 각자 데이터를 해싱한 뒤, 그 해시값끼리만 비교해 일치 여부를 확인합니다. 매체는 원본 개인정보를 보유하지 않고도 광고주의 고객 리스트와 자사 로그인 사용자를 매칭할 수 있다는 점이 이 방식의 핵심 가치입니다.

구글 고객 매치는 정확히 어떤 해싱 규격을 요구하나

구글 고객 매치(Customer Match)에 업로드하는 이메일·전화번호·이름 데이터는 SHA256을 Hex 인코딩 방식으로 처리해야 합니다(Google Ads Help 공식 문서). 해싱 전에는 몇 가지 정규화가 선행돼야 합니다 — 앞뒤 공백 제거, 전체 소문자 변환, 전화번호는 E.164 국제 표준 형식(+82로 시작하는 형태)으로 정규화, gmail.com·googlemail.com 이메일 주소는 '.' 문자를 제거하는 처리입니다. 국가·우편번호 필드는 해싱하지 않고, 모바일 광고 ID는 아예 해싱 대상이 아니라 원문 그대로 사용합니다. 이 규칙 중 하나라도 빠지면 매칭률이 크게 떨어집니다.

메타 맞춤 타겟의 해싱 규격은 무엇이 다른가

메타 맞춤 타겟(Custom Audiences)도 SHA-256 단방향 해시를 사용합니다(Meta Business Help Center 공식 문서). 업로드된 정보는 해싱된 뒤 메타가 보유한 해시값과 비교되고, 매칭·비매칭 여부와 무관하게 처리가 끝나면 해시 데이터 자체가 삭제됩니다. 다만 구글과 메타의 정규화 세부 규칙(소문자 변환 순서, 특수문자 처리 등)이 완전히 동일하다고 단정할 근거는 없으므로, 한 매체용으로 만든 해시 파이프라인을 다른 매체에 그대로 재사용하면 매칭률이 떨어질 수 있습니다. 매체별 공식 가이드를 각각 따로 확인하고 파이프라인을 분리 설계하는 것이 안전합니다.

해시 매칭도 동의가 필요한 이유

해시 매칭이 '완전 익명화'를 의미하지는 않습니다. 원본 식별자를 해시값으로 변환해 매체에 전달하는 행위 자체가 개인정보보호법상 제3자 제공에 해당할 수 있어, 별도의 명시적인 제3자 제공 동의가 여전히 필요합니다. 실제로 리타게팅 광고를 위해 광고 플랫폼에 사용자 데이터를 제공하는 경우 제3자 제공에 대한 별도 동의가 필수이며, 수집·이용 동의만으로는 불충분하다는 것이 개인정보보호위원회의 확인된 입장입니다. "해싱했으니 개인정보가 아니다"라는 논리는 규제 관점에서 위험한 오해입니다.

실시간 자동화 파이프라인은 어떻게 구성하나

실무에서는 CRM·CDP에 신규 고객 데이터가 들어오는 즉시 정규화(소문자 변환, 공백 제거, 전화번호 포맷 통일) → 해싱(매체별 규격에 맞춰 각각) → 매체 API 업로드 순서로 자동화하는 것이 일반적입니다. 이 파이프라인에서 가장 자주 발생하는 오류는 정규화 단계를 건너뛰고 원시 데이터를 바로 해싱하는 경우입니다. 예를 들어 대문자가 섞인 이메일을 그대로 해싱하면 소문자로 정규화된 매체 측 해시값과 절대 일치하지 않습니다. 업로드 전 샘플 데이터로 매칭률을 테스트하는 검증 단계를 자동화 파이프라인에 포함시켜야, 매칭률 급락을 사전에 잡아낼 수 있습니다.

어떤 식별자부터 우선 해싱 대상으로 잡아야 하나

모든 필드를 한 번에 자동화하려 하기보다, 매칭률 기여도가 가장 큰 식별자부터 순서를 정하는 편이 효율적입니다. 일반적으로 이메일은 구글·메타 양쪽에서 가장 안정적으로 매칭되는 식별자이고, 전화번호는 국가별 포맷 차이(국가번호 포함 여부, 하이픈 유무)로 정규화 오류가 특히 잦은 필드입니다. 이름·주소 조합은 매칭 기여도는 낮지만 이메일·전화번호가 없는 레코드를 보완하는 용도로 쓰입니다. 처음에는 이메일 해싱 파이프라인부터 안정화하고, 매칭률이 확인된 뒤 전화번호·기타 식별자로 확장하는 순서가 실무적으로 리스크가 적습니다.

해시 데이터는 사내에 얼마나 보관해야 하나

해시값 자체는 원본을 복원할 수 없는 단방향 변환 결과이지만, 그렇다고 무기한 보관해도 되는 것은 아닙니다. 매체 업로드용으로 생성한 해시값도 원본 개인정보의 처리 목적·보유기간 범위 안에서만 보관하는 것이 안전한 운영 방침입니다. 동의 철회나 회원 탈퇴가 발생하면 원본 데이터뿐 아니라 이미 매체에 업로드된 해시 기반 오디언스에서도 해당 레코드를 제거 요청하는 절차를 함께 마련해야, 4강에서 다룬 동의 철회 권리가 실질적으로 지켜집니다.