왜 서버 단 마스킹이 클라이언트 단보다 유리한가

클라이언트 사이드 태깅에서는 브라우저가 각 매체로 개별 요청을 직접 보내기 때문에, 어떤 값을 가공해서 보낼지 매체별로 각각 따로 설정해야 하고 그 설정이 브라우저 개발자도구에도 그대로 노출됩니다. 서버사이드 구조에서는 모든 데이터가 일단 서버 컨테이너를 거치므로, 이 지점 한 곳에서 "이 값은 해싱해서 보낸다", "이 값은 아예 제외한다" 같은 규칙을 중앙에서 관리할 수 있습니다. 이는 서버사이드 GTM의 공식 장점 중 "개인정보 제어 강화"에 해당하는 부분으로, 매체별로 흩어진 코드를 일일이 수정하지 않고 서버 단 설정 한 곳에서 정책을 바꿀 수 있다는 실무적 이점이 있습니다.

SHA-256 해싱은 정확히 어떻게 적용해야 하나

구글 애즈의 향상된 전환(Enhanced Conversions) 기능을 기준으로 보면, 원시(raw) 사용자 데이터를 그대로 태그에 넘기면 태그 시스템이 자동으로 웹세이프 Base64 인코딩 SHA256 방식으로 해싱합니다. 반대로 광고주가 서버 단에서 이미 해싱을 마친 데이터를 넘기는 경우에는 Hex 인코딩 SHA256 방식을 써야 합니다. 이 두 방식은 서로 호환되지 않기 때문에, 이미 해싱한 값을 다시 웹세이프 Base64로 재인코딩하는 식의 실수를 하면 매칭률이 0에 가깝게 떨어질 수 있습니다. 이런 사고를 막으려면 해싱을 서버 단에서 할지, 매체 태그가 자동으로 하게 둘지를 먼저 정하고 그 방식에 맞는 인코딩 규격을 태그 진단 리포트(커버리지·매칭률·전환 상승치 지표)로 반드시 검증해야 합니다.

모든 개인정보를 해싱하면 되는 것은 아니다

이름, 주민등록번호처럼 그 자체로 민감하거나 해싱해서 보낼 실익이 없는 값은 애초에 서버 단에서 광고 매체로 전송하지 않고 제외하는 것이 원칙입니다. 해싱은 이메일·전화번호처럼 매체가 사용자 매칭 목적으로 공식 지원하는 필드에 적용하는 기법이지, 모든 개인정보를 무조건 해싱해서 보내도 되는 만능 처리법이 아닙니다. 서버 컨테이너의 데이터 필터링 규칙을 설계할 때는 각 필드를 "매체가 매칭 목적으로 공식 지원하는 해싱 대상 필드"와 "애초에 전송 대상에서 제외해야 하는 필드"로 먼저 분류하는 작업이 선행돼야 합니다.

법적 리스크를 줄이는 데 이 설계가 왜 중요한가

개인정보보호 관련 법규(국내 개인정보보호법, EU GDPR 등)는 개인을 식별할 수 있는 정보를 목적 외로 제3자(광고 매체)에 넘기는 행위를 엄격히 규율합니다. 서버 단에서 어떤 값을 어떤 형태로, 어떤 매체에만 보낼지를 명시적으로 통제해두면, 이 통제 자체가 개인정보 처리방침에 기술한 "제공 항목"과 실제 전송 데이터를 일치시키는 근거가 됩니다. 반대로 클라이언트 사이드에서 각 매체 스크립트가 페이지의 모든 데이터레이어 값을 무분별하게 읽어가는 구조라면, 처리방침에 명시하지 않은 값이 의도치 않게 매체로 넘어갈 위험이 커집니다. 다만 이 강의는 마케팅·데이터 관점의 실무 원칙을 다루는 것이며, 구체적인 법규 해석과 처리방침 문구는 자사 법무팀·개인정보보호책임자(CPO)의 최종 확인을 거쳐야 하는 영역입니다.

마스킹 규칙을 데이터레이어 설계 단계부터 반영해야 하는 이유

10강에서 다루는 마스킹은 5강의 데이터레이어 설계와 별개로 나중에 덧붙이는 작업이 아니라, 애초에 데이터레이어를 설계하는 단계부터 함께 고려해야 하는 항목입니다. 데이터레이어에 이름·주민등록번호 같은 값을 아예 담지 않도록 설계하면, 서버 단에서 별도로 필터링 로직을 추가하지 않아도 애초에 그런 값이 서버 컨테이너에 들어오지 않습니다. 반대로 데이터레이어 단계에서 이런 값을 무분별하게 담아두면, 서버 단 필터링에 의존해야 하고 이 필터링 로직에 실수가 생기면 곧바로 개인정보 유출 리스크로 이어집니다. 즉 "서버 단에서 걸러내면 된다"는 접근보다 "애초에 필요한 값만 데이터레이어에 담는다"는 원칙이 더 안전한 설계 방향입니다.

매체별로 요구하는 필드가 다를 수 있다는 점도 감안해야 한다

구글 애즈의 향상된 전환이 요구하는 해싱 규격과, 메타·틱톡이 각자의 서버 API에서 요구하는 사용자 매칭 필드·해싱 규격은 서로 동일하지 않을 수 있습니다. 하나의 서버 컨테이너에서 여러 매체로 동시에 데이터를 보내는 구조라면, 매체마다 별도의 마스킹·인코딩 로직을 각각 적용해야 하는 경우가 생깁니다. 이 부분은 9강에서 정리한 매체별 공식 문서를 각각 다시 확인하며 매체별 요구사항 표를 만들어두는 것이 실무에서 인코딩 실수를 줄이는 데 도움이 됩니다.