사내 방문객 출입 승인과 퇴실 확인 시스템 구축 방법

방문 승인을 받았다는 이유로 재실 인원에 넣거나, 약속 시간이 지났다는 이유로 퇴실 처리하면 출입대장이 실제 상황과 어긋납니다. 사내 방문객 시스템은 방문 승인, 현장 입실, 퇴실 확인을 따로 기록하고, 퇴실 근거가 없는 건을 담당자에게 남겨야 합니다. 아래는 소프트모아의 실제 고객 사례가 아닌 가상의 사무실 구축 예시입니다.

접견자의 승인으로 입실 기록을 만들지 않는다

신청 화면에는 방문자 이름, 접견 직원, 방문 목적, 방문 사업장, 예정 시작·종료 시각을 받습니다. 예시에서는 한 신청을 한 사람의 한 차례 방문으로 정의합니다. 동행자가 3명이면 대표자 1건으로 세지 않고 방문 기록 3건을 만듭니다. 재방문도 새 방문번호를 발급해 지난 퇴실 기록과 섞이지 않게 합니다.

접견자는 본인이 담당하는 신청만 승인하거나 반려합니다. 승인 후에도 방문자는 '도착 전'입니다. 안내 데스크는 방문번호와 현장의 방문자를 확인하고, 승인된 사업장과 시간 범위가 맞을 때 입실을 기록합니다. 승인 전 도착, 취소된 신청, 다른 사업장 방문은 임의로 통과시키지 않고 접견자에게 돌려보냅니다. QR을 사용하더라도 신청을 찾는 수단일 뿐, 소지자와 승인 대상자가 같다는 증거로 삼지 않습니다.

• 접견 직원: 자신의 방문 신청 승인, 일정 변경 요청, 미확인 건 확인 요청 수신.
• 안내 데스크: 담당 사업장의 입실·퇴실 기록과 방문증 회수 확인.
• 보안 담당자: 담당 사업장의 퇴실 미확인 조회와 정정 사유 검토.

방문자가 보는 단말에는 다른 방문자의 이름 목록이나 이름 자동완성 결과를 띄우지 않는 설계로 잡습니다. 퇴실 때는 자신의 방문번호로 조회하고 현장 담당자가 대상을 확인합니다. 조회 권한을 나누는 것과 공용 화면에 이름을 노출하지 않는 것은 별개의 설정입니다.

예정 종료 30분 뒤에는 퇴실 대신 확인 요청

이 예시의 규칙은 '입실 기록이 있고 퇴실 기록이 없으며, 예정 종료 후 30분 이상 지났으면 확인 요청'입니다. 30분은 가정한 내부 운영 기준이지 출입 허용시간의 연장이나 개인정보 보관기한이 아닙니다. 접견자는 면담 연장인지 이미 떠난 뒤 기록만 빠졌는지 확인합니다. 연락이 닿지 않으면 미확인 상태를 유지하고 보안 담당자에게 넘깁니다.

퇴실 화면에는 방문번호, 확인한 퇴실 시각, 기록자, 확인 방법을 저장합니다. 방문증 회수와 사람의 퇴실은 별도 항목으로 둡니다. 방문증이 반납됐어도 동행자가 남아 있을 수 있고, 방문증을 잃어버렸어도 사람이 떠났을 수 있기 때문입니다. 정정할 때는 원래 값과 변경 사유, 실제 퇴실 시각과 입력 시각을 함께 남깁니다. 단순 마감 작업은 '자동 마감'으로 표시하고 확인된 퇴실과 구분합니다.

승인 4건이 실제로는 어떻게 나뉘는지 확인한다

다음 SQL은 승인된 가상 방문 4건만 비교합니다. in_at은 입실, out_at은 확인된 퇴실, end_at은 예정 종료입니다. 비교 시각은 2026년 10월 30일 13:30 한국시간으로 고정했습니다. 코드의 Z는 UTC 표시이므로 04:30Z와 같은 시점입니다. 실제 개인정보나 운영 DB를 사용하지 않으며, 입력 시각은 형식과 선후관계를 검증한 정상값이라고 가정합니다.

SQLite 3.54.0에서 아래 내용을 visits.sql로 저장하고 sqlite3 :memory: < visits.sql로 실행해 확인했습니다. WITH 공식 문서의 문장 범위 임시 조회와 날짜 함수 공식 문서의 unixepoch 초 단위 계산을 사용한 SELECT이며, 테이블이나 출입 상태를 변경하지 않습니다.

WITH visits(id, in_at, out_at, end_at) AS (
  VALUES
  ('V01', NULL, NULL, '2026-10-30T04:00:00Z'),
  ('V02', '2026-10-30T03:00:00Z', NULL, '2026-10-30T04:00:00Z'),
  ('V03', '2026-10-30T02:00:00Z', '2026-10-30T03:00:00Z', '2026-10-30T03:00:00Z'),
  ('V04', '2026-10-30T04:00:00Z', NULL, '2026-10-30T04:00:01Z')
), clock(now_at) AS (
  VALUES ('2026-10-30T04:30:00Z')
)
SELECT id, CASE
  WHEN in_at IS NULL THEN 'NOT_ENTERED'
  WHEN out_at IS NOT NULL THEN 'EXIT_RECORDED'
  WHEN unixepoch(now_at) - unixepoch(end_at) >= 30 * 60
    THEN 'CHECK_EXIT'
  ELSE 'OPEN'
END AS result
FROM visits CROSS JOIN clock
ORDER BY id;

실행 결과는 다음과 같습니다.

V01|NOT_ENTERED
V02|CHECK_EXIT
V03|EXIT_RECORDED
V04|OPEN

V01은 승인됐지만 입실 기록이 없어 '도착 전'으로 표시됩니다. 실제 도착 여부까지 증명하지는 않습니다. V02는 예정 종료에서 정확히 30분이 지나 확인 대상입니다. V03은 퇴실 기록이 있습니다. V04는 29분 59초가 지나 아직 확인 기준 전입니다. OPEN도 재실을 보증하는 값이 아니라 퇴실 미확인 중 기준 시간 전인 상태입니다. 따라서 승인 4건, 입실 기록 3건, 퇴실 기록 1건, 퇴실 미확인 2건, 그중 확인 요청 대상 1건으로 집계해야 합니다.

퇴실 기록을 보완한 뒤에도 남는 건

담당자가 V02의 13:25 퇴실을 확인했다고 가정하고, 해당 행의 out_at인 NULL만 '2026-10-30T04:25:00Z'로 바꾼 별도 예시를 실행하면 V02는 EXIT_RECORDED가 됩니다. 미확인은 1건, 확인 요청 대상은 0건으로 바뀌지만 V01은 입실 기록이 없는 상태로 남고 V04도 여전히 퇴실 미확인입니다. 이 실행은 가상 입력을 바꾼 조회일 뿐 원본 파일이나 운영 기록을 수정하지 않습니다.

구축 검수 때는 미승인 입실 차단, 같은 방문의 중복 입실·퇴실 요청, 입실보다 이른 퇴실 시각 거절, 정정 권한을 확인합니다. 네트워크가 끊기면 임시 기록에 현장 시각과 기록자를 남기고, 복구 후 같은 방문번호의 서버 기록과 대조한 뒤 반영합니다. 이 SQL은 권한 검사나 동시 요청 처리를 구현하지 않습니다. 대시보드 숫자만으로 실제 잔류 인원이나 비상 대피 완료를 확정하지 않고 현장 확인 절차와 함께 사용해야 합니다.

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