Quiz: Retention Periods and Purging

청구 자료의 보존기간을 "3년" 으로 정할 때 반드시 함께 정해야 하는 것은?

• 3년을 어느 날부터 세는지(기산일)와 그 근거를 어디에 적을지
• 파기 배치를 매일 돌릴지 매달 돌릴지와 실행 시각
• 3년을 일수로 환산할 때 윤년을 365일로 볼지 366일로 볼지
• 파기 대상 목록을 CSV 로 낼지 JSON 으로 낼지

아직 종결되지 않은 청구는 종결일 칸이 비어 있다. 파기 판정에서 이 건을 어떻게 다뤄야 하는가?

• 빈 날짜를 아주 옛날로 채워 가장 먼저 파기 대상에 넣는다
• 기준일을 넣어 오늘 종결된 것으로 보고 3년 뒤를 만료일로 잡는다
• 기산일이 없으므로 시효가 시작되지 않은 것으로 보고 대상에서 뺀다
• 종결일 대신 사고일을 넣어 같은 3년을 적용한다

보존기간이 지난 건과 보존 명령이 걸린 건이 있다. 파기 판정의 순서로 옳은 것은?

• 보존 명령이 걸린 건을 먼저 제외한 뒤 남은 것에 기간 판정을 적용한다
• 보존 명령과 기간을 각각 계산해 둘 중 하나라도 해당하면 파기한다
• 보존 명령을 파기 실행 뒤에 확인해 잘못 지운 건을 백업에서 되살린다
• 기간이 지난 건을 먼저 뽑고, 그중 보존 명령이 걸린 건을 뺀다

파기 계획(dry-run)과 실제 파기를 나누는 가장 큰 이유는?

• 같은 코드를 두 번 돌려 두 결과가 같은지 비교하면 버그를 찾을 수 있어서
• 파기는 되돌릴 수 없어서, 사람이 목록을 확인할 자리를 절차에 넣어야 하기 때문에
• 계획 단계에서 대상을 미리 잠가 두어야 실행 중 목록이 바뀌지 않기 때문에
• 감사 대응에 계획 파일과 실행 로그가 각각 한 부씩 필요하기 때문에

파기를 끝낸 뒤 "정말 지워졌는가" 를 확인하는 방법으로 가장 알맞은 것은?

• 파기 스크립트의 종료 코드가 0 이고 로그에 오류가 없는지 본다
• 개인정보 표의 전체 행 수가 파기 건수만큼 줄었는지 확인한다
• 남은 파일과 표를 실제로 훑어 지워진 사람의 식별 정보가 읽히는지 확인한다
• 파기 이력 표의 건수가 계획의 건수와 같은지 대조한다

운영 데이터에서는 지웠지만 어제 받은 백업에는 같은 서류가 남아 있다. 이때 할 일로 가장 알맞은 것은?

• 백업 파일을 즉시 삭제해 파기를 완결한다
• 백업은 파기 대상이 아니므로 아무 조치도 하지 않는다
• 복원 시 자동으로 다시 지우도록 파기 스크립트를 복원 절차에 끼워 넣는다
• 어디에 무엇이 남았는지 목록으로 내고 백업 만료까지의 처리 일정을 함께 관리한다