지금 읽는 곳세 가지 층위로 나눠 봐야 하는 이유목차
외부시선 › G-6. 대행 계약·정산·분쟁 감사 › 과목 G34 › 레슨 05
고객 데이터 보관·파기·백업의 책임 분리
고객 데이터가 대행사 서버, 광고주 서버, 클라우드 백업까지 세 곳에 흩어져 있다면, 계약이 끝났을 때 어디까지 파기해야 하는지 헷갈릴 수 있습니다.
핵심요약
- 고객 데이터는 원본 저장, 처리 중 임시 저장, 백업이라는 세 가지 층위로 나눠 책임을 분리해야 한다
- 각 층위마다 보관 주체와 파기 시점이 다를 수 있어 하나로 뭉뚱그리면 파기가 불완전해진다
- 개인정보보호법상 위탁 계약 종료 시 5일 이내 파기 또는 반환 원칙이 이 모든 층위에 적용돼야 한다
- 파기 완료를 확인하는 증빙(파기확인서 등)을 받아야 실제로 파기됐는지 검증할 수 있다
- 책임 분리가 불명확하면 계약 종료 후에도 어딘가에 고객 데이터가 남아 있을 위험이 있다
세 가지 층위로 나눠 봐야 하는 이유
고객 데이터는 광고주의 원본 시스템(CRM, 자사몰 데이터베이스)에 저장되는 원본, 대행사가 마케팅 작업을 위해 내려받아 쓰는 처리 중 임시 데이터, 그리고 이 둘을 안전하게 보관하기 위한 백업이라는 세 층위로 존재하는 경우가 많습니다. 계약 종료 시 "데이터를 파기했다"고 할 때, 이 세 층위 중 어디까지를 포함하는지 명확히 하지 않으면 일부 층위에만 파기가 이뤄지고 나머지는 남아 있을 위험이 있습니다.
층위별로 책임 주체가 다른 이유
원본 데이터는 광고주가 직접 관리하는 경우가 많지만, 처리 중 임시 데이터는 대행사의 로컬 환경이나 대행사가 쓰는 마케팅 툴(이메일 발송 시스템, 광고 타겟팅 툴)에 저장됩니다. 백업은 대행사의 클라우드 저장소나 별도 백업 서비스에 있을 수 있습니다. 이 세 층위 모두에 대행사가 접근했다면, 계약 종료 시 파기·반환 대상도 이 세 층위 전체를 포괄해야 합니다.
실무에서는 이 세 층위가 물리적으로도 다른 담당자·부서가 관리하는 경우가 흔합니다. 원본은 광고주 IT팀, 임시 처리는 대행사 실무 담당자, 백업은 대행사의 별도 인프라팀이 관리하는 식으로 나뉘어 있으면, 계약 종료 통보가 실무 담당자에게만 전달되고 백업 담당 부서까지는 전달되지 않는 경우도 있을 수 있습니다.
5일 파기 원칙을 세 층위에 적용하는 법
개인정보보호법상 위탁 계약이 종료되면 원칙적으로 5일 이내에 수탁자가 보유한 개인정보를 파기하거나 위탁자에게 반환해야 합니다. 이 원칙은 대행사가 어떤 형태로든(원본이든, 임시 처리 데이터든, 백업이든) 보유하고 있는 모든 개인정보에 적용돼야 하며, 계약서에 이를 명시할 때는 "본 계약과 관련해 수탁자가 보유한 모든 형태의 개인정보(백업 포함)"라고 범위를 분명히 하는 것이 좋으며, 이 문구 하나가 나중에 특정 층위를 파기 대상에서 제외하려는 시도를 원천적으로 막아줍니다.
파기 완료를 확인하는 증빙
파기할 경우 복원이 불가능하도록 완전하게 파기해야 한다는 것이 원칙이지만, 광고주 입장에서 이 파기가 실제로 이뤄졌는지 확인할 방법이 필요합니다. 대행사로부터 "파기확인서"나 이에 준하는 문서(파기 일시, 파기 방법, 파기 대상 목록)를 받는 것이 이 확인의 실무적 방법입니다. 이 증빙이 없으면 계약 종료 후 문제가 발생했을 때 대행사가 실제로 데이터를 파기했는지 다투게 됩니다.
파기확인서를 요청할 때는 파기 대상 목록에 세 층위(원본, 임시 처리, 백업) 모두가 포함돼 있는지 항목별로 대조하는 것이 좋습니다. 대행사가 성실하게 작성했더라도 특정 층위를 빠뜨린 채 확인서를 보내는 경우가 있을 수 있으므로, 받은 확인서를 그대로 보관하기 전에 한 번 더 항목을 맞춰보는 습관이 필요하며, 빠진 항목이 있다면 재발급을 요청해 파기확인서 자체가 세 층위를 모두 포괄하도록 만들어야 합니다.
책임 분리가 불명확할 때의 위험
세 층위의 책임 주체가 계약서에 명시되지 않으면, 계약 종료 후 "그 데이터는 저희가 아니라 다른 팀이 처리 중이던 백업이라 몰랐다"는 식의 책임 회피가 발생할 수 있습니다. 이런 상황을 막으려면 계약 초기부터 대행사 내부에서 고객 데이터를 다루는 모든 접점(임시 처리, 백업 포함)을 파악해 계약서에 반영해야 합니다.
이런 책임 회피는 대행사가 의도적으로 발뺌하려는 경우보다, 대행사 내부에서도 어느 팀이 어떤 데이터를 어디에 보관하고 있는지 파악이 안 돼 있는 경우에 더 자주 발생합니다. 계약 초기에 대행사 측에 내부적으로 고객 데이터를 다루는 모든 부서·시스템을 한 번 정리해달라고 요청해두면, 이런 파악 부족으로 인한 책임 공백을 사전에 줄일 수 있고 계약 종료 시점에도 그 정리 자료를 그대로 활용할 수 있습니다.
파기와 반환 중 어느 쪽을 선택할지 정하는 기준
계약이 끝난 데이터를 파기할지 반환받을지는 그 데이터를 향후에도 활용할 계획이 있는지에 따라 달라집니다. 새 대행사에 인계해 계속 활용할 CRM 데이터라면 반환을 선택해 광고주 시스템으로 이관받아야 하고, 특정 캠페인을 위해 일회성으로 수집했던 데이터라면 파기를 선택하는 것이 개인정보 보호 원칙에도 부합합니다. 이 선택을 항목별로 미리 정해두면, 계약 종료 시점에 매번 새로 고민할 필요 없이 정해진 기준대로 처리할 수 있고, 담당자가 바뀌더라도 같은 기준으로 판단할 수 있어 일관성이 유지됩니다.
백업 데이터가 가장 놓치기 쉬운 이유
원본 데이터와 처리 중 임시 데이터는 담당자들이 비교적 쉽게 떠올리지만, 백업은 자동화된 시스템에 의해 별도 인지 없이 쌓이는 경우가 많아 파기 대상에서 누락되기 쉽습니다. 특히 대행사가 사용하는 클라우드 서비스의 자동 백업 정책이 90일, 1년처럼 별도 보관 기간을 두고 있다면, 계약 종료 시점에 이 자동 백업본까지 함께 파기 대상에 포함하도록 명시적으로 요청해야 합니다. 그렇지 않으면 계약서상 파기가 완료됐다고 해도 자동 백업 시스템 어딘가에 데이터가 남아 있을 수 있고, 이는 계약서상 파기 의무를 다했다고 믿었던 것과 실제 상황이 다른 대표적인 사례가 됩니다.