문서 폐기 대상 조회와 보류 승인 관리 시스템 구축 방법

보존기간이 지난 문서를 날짜만 보고 삭제하면, 아직 확인 중인 자료까지 폐기 대상으로 묶일 수 있습니다. 문서 폐기 관리 화면은 검토 시작일과 보류 사유를 함께 조회하고, 검토 후보·승인·실제 처리 완료를 나눠야 합니다. 보류 한 건을 해제했더라도 다른 보류가 남았다면 실행을 막는 설계입니다.

아래는 가상 사내 문서함의 설계 예시입니다. 특정 고객의 구축 사례나 법정 보존기간 안내가 아닙니다. 문서별 기간과 기산 사건은 업무·법무 담당자가 적용 기준을 확인한 뒤 등록하고, 이 글에서는 확정된 날짜를 받은 이후의 후보 조회만 다룹니다.

파일 수정일 대신 검토 시작일을 받습니다

등록 화면에는 문서 ID, 분류, 기준 사건일, 보존 규칙 버전, 검토 시작일을 둡니다. 파일을 다시 저장한 날을 기준 사건일로 덮어쓰지 않습니다. 예시의 eligible_on은 보존 마지막 날이 아니라 폐기 검토를 시작할 수 있는 첫날입니다. 한국시간 2026-11-09를 조회 기준일로 고정하고, 두 날짜가 같으면 검토 후보에 넣습니다. 실제 운영에서는 회사가 정한 시간대와 날짜 경계를 명시합니다.

보류는 문서마다 참·거짓 하나만 저장하지 않고 별도 이력으로 관리합니다. 내부 검토 H01과 자료 대조 H02가 같은 문서에 걸렸다면 각각의 사유·등록자·해제 권한자·해제 근거를 남깁니다. 화면에는 활성 보류 건수와 사유 목록을 함께 표시합니다. Laserfiche의 공식 안내도 여러 보류가 걸린 문서는 모두 해제할 때까지 수정 제한이 유지된다고 설명합니다.[1] 여기서는 이를 참고해 폐기 실행을 막는 자체 규칙을 정합니다.

날짜가 지났어도 후보가 아닌 문서

다음 SQL은 SQLite에서 파일이나 테이블을 만들지 않고 실행하는 조회 예제입니다. 날짜는 유효한 YYYY-MM-DD 문자열, 보류 건수는 집계가 확인된 0 이상의 정수라고 가정합니다. 영구 보존 여부는 0 또는 1입니다. 날짜·건수의 누락은 검토 필요로 남기며, 누락된 건수를 0으로 바꾸지 않습니다. 실제 입력 검증과 상위 폴더에서 상속된 보류 집계는 별도로 구현합니다.

WITH docs(id, eligible_on, permanent, holds) AS (
  VALUES
    ('D01', '2026-11-08', 0, 0),
    ('D02', '2026-11-09', 0, 0),
    ('D03', '2026-11-10', 0, 0),
    ('D04', NULL,         0, 0),
    ('D05', '2026-11-08', 1, 0),
    ('D06', '2026-11-08', 0, 2),
    ('D07', '2026-11-08', 0, NULL)
)
SELECT id, eligible_on, holds,
  CASE
    WHEN permanent = 1 THEN 'KEEP'
    WHEN holds IS NULL THEN 'CHECK'
    WHEN holds > 0 THEN 'HOLD'
    WHEN eligible_on IS NULL THEN 'CHECK'
    WHEN eligible_on <= '2026-11-09' THEN 'REVIEW'
    ELSE 'WAIT'
  END AS state
FROM docs
ORDER BY id;

CASE는 앞에서부터 조건을 확인해 처음 참인 분기를 선택하므로 영구 보존과 보류 검사를 날짜 비교보다 먼저 둡니다.[2] 이 결과는 대표 상태 하나이며, 화면의 원본 날짜와 모든 보류 사유까지 지우는 규칙은 아닙니다.

• D01·D02는 REVIEW입니다. 날짜 조건을 충족한 검토 후보이지 삭제 승인이 아닙니다.
• D03은 WAIT, 날짜가 없는 D04는 CHECK입니다. D04를 오래된 문서로 추정하지 않습니다.
• D05는 KEEP, 보류가 2건인 D06은 HOLD, 건수를 모르는 D07은 CHECK입니다.

로컬 SQLite 3.53.4에서 위 조회를 실행하고 결과를 확인했습니다. D06의 입력값 2를 1로 바꿔 다시 실행해도 HOLD가 나옵니다. 0으로 바꾸면 REVIEW로 바뀌지만 D04·D07의 CHECK는 그대로입니다. 이 변경은 예제 입력 비교일 뿐 실제 보류 해제 이력이 아닙니다. 단일 보류 버튼을 끄는 방식과 달리 남은 사유를 확인할 수 있습니다.

검토 요청에서 처리 확인까지

문서 담당자는 REVIEW 목록에서 분류·날짜·규칙 버전을 대조해 검토를 요청합니다. 승인자는 대상 문서와 버전을 고정한 목록을 열고 승인 또는 반려 사유를 기록합니다. 보류 등록·해제는 지정된 담당자만 허용하고, 일반 문서 담당자가 스스로 보류를 없애도록 만들지 않습니다. 이는 예시의 권한 분리안이며 조직별 승인 체계에 맞춰 조정합니다.

실행 작업은 승인 ID를 받더라도 최신 보류와 규칙 버전을 다시 확인합니다. 승인 뒤 새 보류가 붙었다면 대기 상태로 되돌리고 사유를 남깁니다. 확인과 실행 사이에 보류가 추가되는 충돌도 막도록 잠금 또는 버전 조건을 설계해야 합니다. 위 SELECT만으로 동시 실행이나 권한 검증까지 해결되지는 않습니다.

조회 화면에는 후보 수와 별개로 보류·정보 누락·반려·실행 실패 목록을 둡니다. 승인 버튼을 누른 시각은 처리 완료 시각이 아닙니다. 실제 저장소의 응답과 대상 확인을 받은 뒤 완료를 기록하고, 응답이 끊긴 건은 결과 확인 필요로 남깁니다. 원본 한 곳의 처리 성공을 백업·복제본까지 제거한 결과로 확대하지 않습니다.

구축 범위를 정할 때는 검토 시작일을 누가 확정하는지, 보류가 어디서 상속되는지, 처리 결과를 어느 저장소에서 확인하는지부터 합의하면 됩니다. 소프트모아의 개발 분야는 softmoa.com에서 확인할 수 있습니다.

확인 자료: [1] Laserfiche 보류 관리 안내, [2] SQLite CASE·NULL 공식 문서. 설계 관점 참고: ICRM의 폐기 보류와 승인 구분, CDI의 보존 기산 사건 설명.

소프트모아는 해당 시스템을 구축합니다. 문의하기