SOFTMOA TECHNOLOGY
사내 규정 배포와 직원 확인 이력 관리 시스템 구축 방법
소프트모아가 정리한 기술 기록입니다.
Contents
새 사내 규정을 메일로 보냈는데 누가 어느 버전을 확인했는지 알 수 없다면, 메일 발송 기록과 직원 확인 기록을 분리해야 합니다. 규정 배포 시스템은 문서 번호·개정 버전·대상 직원을 연결하고, 해당 버전의 확인을 제출하지 않은 사람만 보여 주도록 설계합니다. 메일을 열었거나 PDF를 내려받았다는 이유로 확인 완료를 표시하지 않습니다.
아래는 외부 저장매체 사용 지침 SEC-07의 버전 2를 직원 3명에게 배포하는 가상 설계입니다. 고객 사례나 법정 확인 절차를 뜻하지 않습니다. 소프트모아의 개발 분야는 softmoa.com에서 확인할 수 있습니다.
확인 버튼이 가리키는 문서를 고정합니다
등록 화면에는 문서 번호, 버전, 개정 사유, 시행일, 담당 부서와 파일을 입력합니다. 담당자가 초안을 제출하면 DRAFT에서 REVIEW로 바뀌고, 승인자는 변경 내용과 적용 대상을 확인합니다. 반려하면 이유를 남겨 초안으로 돌려보냅니다. 승인된 버전만 배포 대상으로 선택할 수 있게 합니다.
배포 담당자는 E101·E102·E103을 대상으로 정하고 확인 기한을 2026년 10월 21일 18:00 한국시간으로 지정합니다. 이는 이 예시의 운영값이며 공통 의무 기한이 아닙니다. 배포 시점의 대상 명단을 따로 저장하고, 이후 인사 명단이 달라져도 과거 대상자를 몰래 바꾸지 않습니다. 신규 직원은 추가 배정 이력으로 남깁니다.
직원 화면에는 SEC-07 버전 2와 개정 요약, 시행일, 확인 기한을 함께 보여 줍니다. 파일명 대신 승인된 버전의 저장 위치를 연결하고, 배포 후 본문을 덮어쓰지 않도록 합니다. 새 내용은 버전 3으로 등록합니다. 이전 버전의 확인 기록은 보존하되 새 버전의 확인으로 옮기지 않습니다.
직원이 제출하고 관리자가 조회하는 순서
- 직원은 '내 확인 대상'에서 배정된 규정을 엽니다. 열람 시각은 참고 기록으로 남기고, 확인 상태는 아직 PENDING으로 둡니다.
- 직원이 '이 버전의 문서를 확인했습니다'를 제출하면 서버가 로그인한 직원과 배정 버전을 대조합니다. 요청에 실린 직원 번호를 그대로 믿지 않고, 저장이 끝난 뒤 ACKNOWLEDGED로 표시합니다.
- 관리자는 버전별 대상자, 제출 시각, 미확인자와 기한 초과 여부를 조회합니다. 일반 직원은 자신의 배정과 이력만, 부서 관리자는 담당 부서만 보도록 조회 권한을 나눕니다.
버전 2 화면을 열어 둔 사이 버전 3이 배포될 수 있습니다. 이 설계에서는 서버가 현재 배정 버전을 다시 검사하고, 바뀌었다면 확인 저장을 거부해 새 문서를 안내합니다. 구버전 제출을 신버전 완료로 바꿔 저장하면 안 됩니다. 반복 클릭에도 기록이 늘어나지 않도록 문서 번호·버전·직원 번호를 필수값으로 정하고 조합에 UNIQUE 제약을 둡니다. SQLite에서는 UNIQUE만으로 NULL을 막지 못하므로 각 필드의 NOT NULL도 필요합니다.[3]
확인 로그가 4건이어도 완료자는 1명입니다
관리 화면의 미확인 목록은 전체 로그 수가 아니라 배정된 문서·버전·직원 조합으로 계산합니다. 아래는 SQLite에서 실행할 수 있는 읽기 전용 SQL입니다. WITH의 예시 데이터는 이 문장 안에서만 쓰이며 실제 테이블을 만들거나 규정 확인을 저장하지 않습니다.[1]
WITH target(policy_id, version, employee_id) AS (
VALUES ('SEC-07', 2, 'E101'),
('SEC-07', 2, 'E102'),
('SEC-07', 2, 'E103')
), acknowledgment(policy_id, version, employee_id) AS (
VALUES ('SEC-07', 2, 'E101'),
('SEC-07', 1, 'E102'),
('SEC-99', 2, 'E103'),
('SEC-07', 2, 'E999')
)
SELECT t.employee_id
FROM target AS t
WHERE NOT EXISTS (
SELECT 1 FROM acknowledgment AS a
WHERE a.policy_id = t.policy_id
AND a.version = t.version
AND a.employee_id = t.employee_id
)
ORDER BY t.employee_id;결과는 E102와 E103입니다. E101은 SEC-07 버전 2를 제출했지만 E102의 기록은 버전 1이고, E103의 기록은 다른 문서 SEC-99입니다. E999는 이번 배포 대상이 아니므로 완료자 수에 더하지 않습니다. NOT EXISTS는 세 조건을 모두 만족하는 기록이 없는 대상자만 남깁니다.[2] 따라서 이 배포의 집계는 대상 3명, 확인 1명, 미확인 2명입니다.
같은 조건에서 E102의 버전 2 기록을 추가하면 결과에는 E103만 남습니다. 확인 기록을 전부 없애면 세 대상자가 모두 나와야 합니다. 이 SQL과 두 경계 사례는 SQLite 3.54.0에서 확인했습니다. 여기서는 취소되지 않은 확인 기록만 다룹니다. 운영 조회에서는 승인된 제외 대상과 확인 취소 이력을 먼저 반영해야 합니다. 작은 예시는 조회 조건을 검증할 뿐이며, 실제 알림 전송이나 로그인·승인 기능을 실행한 결과는 아닙니다.
미확인 사유와 제출 사실을 구분해 남깁니다
알림 실패는 직원의 확인 여부와 별도 상태로 관리합니다. 발송 요청이 접수됐다고 도착한 것은 아니며, 알림이 도착했다고 문서를 이해한 것도 아닙니다. 재알림 대상은 매번 미확인 목록에서 다시 계산하고, 기한 전·기한 도래·기한 초과 같은 발송 단계별 이력을 남겨 같은 안내의 반복 발송을 점검합니다.
휴직이나 퇴사로 확인 대상에서 제외할 때는 관리자가 사유와 적용 시각을 승인해 기록합니다. 화면에서는 전체 배정 인원, 제외 인원, 현재 확인 대상 인원을 따로 보여 줍니다. 기존 행을 지워 분모를 줄이면 과거 보고와 현재 숫자를 설명하기 어렵습니다. 확인 취소도 삭제 대신 취소 사유를 남기고 다시 PENDING으로 계산하는 정책을 정합니다.
내보내기에는 문서 번호와 버전, 대상 명단, 제출 시각, 제외·취소 이력을 포함하고 열람 권한과 보관 기간은 회사 정책에 맞춰 정합니다. 확인 버튼은 직원이 제출했다는 기록입니다. 실제 이해도, 교육 이수나 법적 동의를 증명해야 하는 업무는 이 기록만으로 완료 처리하지 말고 별도의 검토 절차를 설계해야 합니다.
SQL 문법 참고
소프트모아는 해당 시스템을 구축합니다. 문의하기
