CAPI가 다루는 데이터의 성격부터 재확인한다

3강에서 다룬 것처럼 CAPI 페이로드의 em(이메일), ph(전화번호), external_id는 해싱되긴 하지만 원본은 명백한 개인식별정보(PII)입니다. 해싱은 값을 안전하게 전송하기 위한 기술적 조치일 뿐, 그 자체로 "동의 없이 제3자(메타)에게 데이터를 넘겨도 된다"는 법적 근거가 되지는 않습니다. 즉 CAPI를 고도화한다는 것은 곧 이 서버 로직이 개인정보보호법상 제3자 제공·마케팅 활용 동의 요건과 맞물려 설계돼야 한다는 뜻입니다. 이 부분을 순수 기술 프로젝트로만 다루면, 데이터 정합성은 완벽해도 컴플라이언스 리스크가 그대로 남습니다.

메타의 LDU는 한국 상황에 그대로 대입할 수 없다

메타는 미국 각 주(州)의 소비자 프라이버시법(캘리포니아 CCPA 계열 등) 대응을 위해 LDU(Limited Data Use)라는 메커니즘을 제공합니다. 픽셀과 CAPI 양쪽에 data_processing_options 파라미터(및 관련 state·country 파라미터)를 실어 보내면, 메타는 해당 이벤트를 광고 개인화(유사 타겟팅·리타겟팅 확장) 용도로는 쓰지 않고 전환 측정·통계적 모델링 용도로만 제한 처리합니다.

다만 이 기능은 미국 주법 대응에 특화된 메타 자체 기능으로, 한국 개인정보보호법의 마케팅 동의(Opt-in) 요건과는 법적 근거와 적용 범위가 다릅니다. LDU를 켠다고 해서 한국 개인정보보호법상 동의 요건을 충족한 것으로 볼 수 있는지는 이번 조사에서 확인하지 못했습니다(미확인). 국내 서비스에서 LDU를 컴플라이언스 대응 수단으로 사용하기 전에는 개인정보보호위원회 가이드라인이나 사내 법무 검토로 이 부분을 별도로 확인해야 합니다.

서버 단에서 동의 필터를 거는 실무 구조

한국 서비스에서 실무적으로 더 직접적인 대응은 CAPI로 데이터를 보내기 전에 자체 CRM·회원 DB의 동의 상태 필드를 서버 로직에서 먼저 확인하는 것입니다. 구조적으로는 회원 테이블에 마케팅 활용 동의 여부(marketing_opt_in) 필드를 두고, CAPI 전송 함수가 실행되기 직전에 이 필드를 조회해 동의하지 않은 사용자의 이벤트는 em·ph 같은 PII 필드를 비우거나 이벤트 전송 자체를 건너뛰도록 분기하는 방식입니다.

주의할 점은 이 동의 상태가 실시간으로 바뀔 수 있다는 것입니다. 사용자가 마이페이지에서 마케팅 동의를 철회한 직후에도 여전히 이전 캐시된 값을 참조해 CAPI로 데이터가 나가고 있다면 실질적으로 동의 철회가 반영되지 않은 것이 됩니다. 동의 상태를 캐싱한다면 철회 이벤트 발생 시 캐시를 즉시 무효화하는 로직까지 함께 설계해야 합니다. 게스트 결제처럼 애초에 동의 절차 자체가 없는 흐름이라면, 이 경우 개인정보 항목을 CAPI로 보내는 것이 적절한지부터 법무 검토 대상으로 삼는 것이 안전합니다.

감사 가능성을 남기는 로그 설계

컴플라이언스 관점에서는 "필터링이 실제로 작동했다"는 근거를 남기는 것도 중요합니다. CAPI 전송 직전 동의 여부를 확인해 건너뛴 이벤트가 있다면, 그 건수와 사유를 별도 로그로 남겨두는 것을 권장합니다. 이는 추후 감사나 내부 점검에서 "동의하지 않은 사용자의 데이터가 실제로 제3자에게 전달되지 않았다"는 것을 입증할 수 있는 근거 자료가 됩니다.

마케팅팀과 개발팀이 각자 놓치기 쉬운 지점

마케팅팀 입장에서는 "동의 안 한 사람도 어차피 해싱돼서 나가니 괜찮지 않냐"고 생각하기 쉽고, 개발팀 입장에서는 "동의 필드 체크는 마케팅 요구사항 문서에 없었다"고 넘어가기 쉽습니다. 이 간극이 실제 컴플라이언스 사고로 이어지는 경우가 많으므로, CAPI 스펙 문서를 작성할 때부터 동의 필터링 로직을 별도 항목으로 명시해 두 팀이 같은 기준을 공유하도록 만드는 것이 사고를 막는 가장 확실한 방법입니다.