왜 조직 단위로 나누면 다투게 되나

"데이터는 IT, 캠페인은 마케팅"처럼 조직 단위로 나누면 경계에 있는 일이 전부 공백이 됩니다. 이벤트 이름을 누가 정하는지, 세그먼트 조건의 정합성을 누가 검증하는지, 데이터가 틀렸을 때 누가 먼저 확인하는지가 명시되지 않기 때문입니다.

대신 산출물 목록을 먼저 만들고 각 산출물마다 정의하는 쪽과 구현하는 쪽을 나눠 적습니다. 최소한 이벤트 스키마, 식별자 체계, 세그먼트 정의, 동의 필드 구조, 지표 용어집, 데이터 보관·삭제 정책, 장애 대응 절차 일곱 가지는 목록에 들어가야 합니다. 이 방식은 조직이 개편돼도 문서가 유지된다는 장점이 있습니다.

마케팅이 정의하고 IT가 구현하는 것은 무엇인가

이벤트 스키마가 대표적입니다. 어떤 행동을 이벤트로 남길지, 그 행동에 어떤 속성이 필요한지는 세그먼트를 만들 사람이 정해야 합니다. IT가 임의로 정하면 나중에 필요한 속성이 빠져 있어 다시 개발 요청을 넣게 됩니다.

세그먼트 정의도 같습니다. 조건의 의미를 마케팅이 문장으로 적고, 그것을 쿼리나 룰로 옮기는 것은 IT의 몫입니다. 다만 옮긴 결과가 원래 의도와 같은지 확인하는 책임은 정의한 쪽에 있습니다. 검수 방법은 단순합니다. 조건을 적용한 결과에서 표본을 뽑아 실제 고객 몇 명의 이력을 직접 열어 보는 것입니다. 이 확인 없이 넘어가면 잘못된 조건으로 몇 달치 발송이 나갑니다.

IT와 법무가 정의하는 영역은 어디까지인가

식별자 체계는 마케팅이 정하면 안 되는 영역입니다. 한번 부여한 식별자를 되돌릴 수 없는 도구가 많고, 어떤 값을 식별자로 쓸지는 보안과 개인정보 최소수집 원칙이 함께 걸리기 때문입니다. Braze 공식 문서가 이메일을 식별자로 쓰는 것에 대해 쉽게 추측 가능해 공격에 취약하다고 경고하는 것도 같은 맥락입니다.

데이터 보관과 삭제도 마찬가지입니다. 여기에는 처리방침에 적어 둔 기준과 실제 운영이 일치해야 한다는 제약이 걸립니다. 개인정보 보호법 제30조는 처리방침에 처리 목적, 처리·보유 기간, 제3자 제공, 파기 절차와 방법 등을 담도록 하고 수립·변경 시 공개하도록 규정하며, 처리방침과 계약 내용이 다르면 정보주체에게 유리한 것을 적용하도록 합니다. 마케팅은 이 제약 안에서 세그먼트를 설계하는 쪽입니다.

지표 정의는 왜 별도 산출물이어야 하나

현장에서 가장 자주 터지는 갈등은 시스템 장애가 아니라 숫자가 다르다는 문제입니다. CDP가 말하는 구매 건수와 재무팀의 매출 건수가 다르고, 마케팅의 활성 고객 수와 CS의 회원 수가 다릅니다. 대부분 정의가 달라서 생기는 차이입니다.

그래서 용어집을 프로젝트 산출물로 명시합니다. 구매 한 건의 기준, 반품·취소의 반영 방식, 활성의 정의, 누적 금액이 총액인지 순액인지, 회원과 고객의 구분 같은 항목을 문장으로 적고 담당자를 지정합니다. 이 문서가 없으면 회의마다 같은 논쟁이 반복되고, 새로 합류한 사람은 매번 처음부터 확인해야 합니다.

외부 파트너가 들어오면 무엇이 달라지나

CDP 구축을 외부에 맡기거나 발송 대행사를 쓰면 개인정보 처리위탁 관계가 생깁니다. 처리위탁과 제3자 제공은 업무의 목적과 이익이 누구에게 귀속되는지로 구분하며, 위탁자의 업무를 대신 수행하고 위탁자의 이익을 위해 데이터를 받으면 처리위탁입니다.

위탁 관계라면 위탁자에게 관리·감독 의무가 생깁니다. 수탁자를 교육하고 처리 현황을 점검해 안전하게 처리하는지 감독해야 하며, 계약서에는 법규 준수, 비밀유지, 제3자 제공 금지, 사고 시 책임, 위탁기간, 종료 후 반환 또는 파기 의무 등을 규정해야 합니다. 위탁 종료 시에는 원칙적으로 5일 이내에 파기하거나 반환하도록 하는 기준이 안내되고 있습니다. 이 의무를 마케팅과 IT 중 누가 수행할지 문서에 이름을 적어 두지 않으면 아무도 하지 않게 됩니다. 도구를 고르는 것은 마케팅이지만 계약 조항과 감독 절차를 확인하는 것은 별개 역할이므로, 도입 결재 문서에 두 이름을 나란히 적는 방식이 실무에서 가장 잘 작동합니다.