보존 정책은 정책의 옷을 입은 엔지니어링 문제다

모든 보존 정책은 정확히 두 가지를 약속한다. 특정 기록을 충분히 오래 보관한다. 특정 기록을 너무 오래 갖고 있지 않는다. 문서는 컴플라이언스 폴더에 살지만, 두 약속 모두 시스템 동작에 관한 주장이다 — 그리고 시스템 동작에 관한 주장은 엔지니어링되어 검증 가능하거나, 아니면 장식이다.

대부분은 장식이다. 누가 거짓말을 해서가 아니다. 정책이 산문으로 쓰였고, 시스템이 강제하는 속성으로 번역된 적이 없기 때문이다. 진짜 일은 그 번역에 살고 있고, PDF가 보이는 것보다 훨씬 어렵다.

“7년 보관한다”는 부재에 관한 주장이다

첫 번째 약속을 지키려면 기록이 오늘 존재하는 것으로는 부족하다. 아무것도 일찍 사라지지 않았음을 보일 수 있어야 한다. 이것은 삭제의 부재에 관한 주장인데, 부재야말로 평범한 저장소가 시연할 수 없는 것의 첫머리에 있다.

ID 순번에 빈 자리가 없는 테이블은 거의 아무것도 증명하지 못한다. 순번은 재사용되고, 마이그레이션은 번호를 다시 매기고, 삭제된 행은 제 ID를 조용히 데리고 사라진다. 백업이 증명하는 건 백업 시점에 존재했던 것이지, 백업과 백업 사이에 일어난 일이 아니다. 그사이 평범한 위협들이 일한다. WHERE 절이 너무 넓었던 정리 잡, 샤드 하나를 떨어뜨린 스토리지 이전, 정책이 생기기 전에 설정된 컴팩션. 어느 것도 공격이 아니다. 전부, 정책이 “일어나선 안 된다”고 말하는 삭제가 아무도 세지 않는 방식으로 일어난 것이다.

삭제를 보이게 만드는 장치가 아키텍처 어디에도 없다면 — 깨지는 사슬 구조, 안 맞아지는 집계, 나타나지 않는 수령증 — “전부 보관하고 있습니다”는 희망의 표명이다. 그 데이터베이스를 상대로 지금까지 돌았던 모든 잡을 대신해서 하는 희망의 표명.

“90일 뒤 삭제한다”는 사본에 관한 주장이다

두 번째 약속은 반대 방향으로 실패한다. 행을 지우는 건 쉽다. 행이 문제였던 적은 없다.

문제는 데이터가 살아 있는 동안 다녀간 모든 곳이다. 복제본, 분석용 웨어하우스, 검색 인덱스, 요청 본문을 통째로 받아적은 디버그 로그, 보존 기한보다 오래 사는 백업 로테이션, 데이터 과학자가 선의로 만든 추출본. 원본을 지우고 그림자 다섯을 남기는 삭제는 컴플라이언스가 아니다 — 정리정돈이다.

이 약속을 지키려면 사본이 어디 있는지 알아야 하고, 그러려면 사본이 만들어질 때 기록되어 있어야 한다. 전파를 추적한 적 없는 시스템에 그 지식을 소급 적용하는 건 고고학이고, 마감에 쫓기는 고고학은 개인정보 사고가 우리가 아니라 규제 당국에게 발견되는 경로다.

감사인이 배운 질문

감사 실무는 단순한 업그레이드로 수렴하고 있다. “정책을 보여주세요”에서 “이 기록의 이력을 정책과 대조해서 보여주세요”로. 기록 부류를 하나 고른다. 시계는 언제 시작됐고, 어느 규칙이 적용됐고, 언제 폐기됐고, 폐기가 사본까지 닿았음을 무엇이 증언하는가?

이 질문을 위해 설계된 시스템은 보존을 크론잡의 동작이 아니라 기록의 속성으로 다룬다. 기록 부류마다 시계를 지닌다. 폐기는 증거를 낳는다 — 날짜와 서명이 있는 행위이지, 침묵하는 부재가 아니다. 그 사이의 연속성은 검증 가능해서, 조기 삭제는 보이지 않는 사건이 아니라 탐지되는 이벤트가 된다. 어느 것도 특별한 기술이 아니다. 전부 데이터가 도착하기 전에 정해둬야 하는 것들이고, 바로 그래서 좀처럼 존재하지 않는다.

십 초 시험

정책이 “지난 분기에 삭제됨”이라고 말하는 기록 하나와, “2033년까지 생존 필수”라고 말하는 기록 하나를 골라라. 앞의 것에 대해, 언제, 어느 규칙 아래 삭제됐고 사본도 사라졌음을 보일 수 있는가? 뒤의 것에 대해, 쓰인 이후 한 번도 손대지지 않았음을 보일 수 있는가?

어느 쪽 답에든 회의가 필요하다면, 정책과 시스템은 아직 만난 적이 없는 것이다. 정책은 의도를 말한다. 약속을 지킬 수 있는 건 시스템뿐이다.

Axowl은 기록을 쓰는 시점에 봉인하고 두 약속을 모두 증명 가능하게 만듭니다 — 검증할 수 있는 연속성과, 수령증을 남기는 폐기. 어떻게 동작하는지 보기.