분실물 접수와 소유자 확인·인계 관리 시스템 구축 방법

분실물 목록에 사진이 있어도 보관 위치와 인계 기록이 빠지면 담당자가 바뀐 뒤 물건을 찾거나 돌려준 사실을 확인하기 어렵습니다. 분실물 관리 시스템은 습득물과 분실 문의를 각각 접수하고, 소유자 확인을 거쳐 실물 인계까지 연결하도록 설계해야 합니다. 아래는 숙박시설이나 행사장의 운영을 가정한 구축 예시이며, 특정 고객의 도입 사례가 아닙니다.

물건 한 건과 문의 한 건을 따로 접수합니다

습득 등록 화면에는 물품 번호, 발견 시각, 장소, 품목, 특징, 접수 직원, 사진, 보관함 위치를 입력합니다. 예를 들어 LF-20261004-001을 '검은 우산 1개, 1층 안내대 옆, B-02 보관함'으로 등록합니다. 라벨에도 같은 번호를 붙여 화면의 기록과 실물을 연결합니다. 보관함을 옮길 때는 기존 위치를 덮어쓰기보다 이동 시각과 옮긴 직원을 이력으로 남깁니다.

분실 문의는 물건이 아직 발견되지 않아도 접수할 수 있어야 합니다. 문의 번호 C-017에 분실 추정 시각과 장소, 물품 특징, 연락 방법을 기록하고 습득물 후보를 나중에 연결합니다. 문의와 물품을 한 행에 저장하면 후보가 없다는 이유로 문의를 버리거나, 두 사람이 같은 물건을 찾는 상황을 표현하기 어렵습니다. 한 물품에 여러 문의를 연결하되 인계 대상으로 승인된 문의는 하나만 두는 방식이 적합합니다.

검색 결과는 소유자 확인의 출발점입니다

직원은 접수일 범위, 발견 장소, 품목으로 후보를 조회합니다. '검은 우산'처럼 흔한 설명은 자동 일치 결과가 있어도 인계 승인으로 바꾸지 않습니다. 신청자가 제시한 분실 상황과 물품의 비공개 특징을 담당자가 비교하고, 어떤 근거로 판단했는지 검토 기록을 남깁니다. 확인 자료가 부족하면 추가 질문 상태로 돌리고, 두 문의의 주장이 충돌하면 책임자 검토 대상으로 묶습니다.

• 접수 직원은 습득물 등록과 보관 위치 변경을 맡습니다. 소유자 확인 근거와 연락처의 열람 범위는 별도로 제한합니다.
• 검토 담당자는 문의별 확인 결과를 기록하고 인계 대상을 승인합니다. 승인 취소에는 사유를 남기도록 합니다.
• 인계 직원은 승인된 문의와 물품 번호를 다시 대조한 뒤 실물 전달을 기록합니다. 공용 계정 대신 직원별 계정으로 처리 이력을 남깁니다.

외부 조회 화면에는 연락처, 상세 사진, 보관함 번호를 그대로 노출하지 않는 설계가 필요합니다. 직원 화면에서도 업무에 필요한 항목만 보여주고 다운로드 권한을 구분합니다. 확인을 이유로 신분증 전체 사본을 기본 첨부값으로 요구하는 대신, 필요한 확인 항목과 자료 보관 범위를 먼저 정합니다.

같은 승인 버튼을 두 번 눌렀을 때 확인할 값

승인 화면을 열어둔 사이 다른 직원이 처리했다면 이전 화면의 정보로 다시 승인하면 안 됩니다. 물품의 현재 상태와 버전을 조건으로 확인하면서 변경하는 방법을 사용할 수 있습니다. 다음 SQL은 임시 예시 테이블이며, SQLite UPDATE 문법에 맞춰 로컬 SQLite CLI에서 실행했습니다. demo.sql로 저장하고 sqlite3 :memory: < demo.sql을 실행하면 운영 데이터 없이 동작을 확인할 수 있습니다.

CREATE TABLE item (
  id INTEGER PRIMARY KEY,
  state TEXT NOT NULL,
  version INTEGER NOT NULL,
  claim_id INTEGER
);
INSERT INTO item VALUES (1, 'STORED', 3, NULL);

UPDATE item
SET state = 'READY', version = version + 1, claim_id = 17
WHERE id = 1 AND state = 'STORED' AND version = 3;
SELECT changes();

UPDATE item
SET state = 'READY', version = version + 1, claim_id = 17
WHERE id = 1 AND state = 'STORED' AND version = 3;
SELECT changes();
SELECT state, version, claim_id FROM item;

출력은 차례로 1, 0, READY|4|17입니다. changes()는 직전에 끝난 변경문의 영향 행 수를 알려줍니다. 첫 요청은 한 행을 변경했고, 재요청은 이전 상태와 버전이 맞지 않아 변경하지 않았습니다. 0이면 성공 안내를 띄우기 전에 현재 승인 대상을 다시 조회해야 합니다. 다른 직원의 처리인지, 이미 완료된 같은 요청인지에 따라 안내도 달라집니다.

이 예시는 조건부 변경만 확인합니다. 신청자의 소유권, 직원 권한, 서로 다른 연결의 동시 처리까지 검증한 코드는 아닙니다. 실제 서버에서는 권한과 문의 검토 결과를 확인하고 물품 상태 변경과 승인 이력 저장을 같은 트랜잭션에서 처리해야 합니다. 요청값은 SQL 문자열에 이어 붙이지 말고 바인딩합니다.

인계 승인 뒤에도 물건은 보관 중일 수 있습니다

READY는 인계 준비 상태입니다. 방문자가 수령했다는 뜻이 아닙니다. 방문 인계 화면에는 물품 번호, 승인된 문의 번호, 수령 확인, 인계 직원과 시각을 기록하고 그때 RETURNED로 바꿉니다. 대리 수령은 별도의 확인 절차와 승인 근거를 남깁니다. 잘못 완료 처리한 기록은 삭제하지 않고 정정 사유와 이전 상태를 보존합니다.

택배 반환도 송장 발급, 운송사 인수, 수령 확인을 나눠야 합니다. 송장만 만든 상태를 반환 완료 건수에 넣으면 실제로 보관함에 남아 있는 물건이 통계에서 빠집니다. 방문 수령과 배송 수령을 따로 집계하고, 배송 실패나 반송 건은 담당자가 다시 확인하도록 표시합니다.

운영 조회 화면에는 '실물 보관 중', '확인 대기 문의', '인계 준비', '배송 중'을 나눠 보여줍니다. 예를 들어 접수 후 7일이 지난 미확인 건을 점검 목록으로 올릴 수 있지만, 이 숫자는 업무 점검 예시이지 법정 보관 기간이나 자동 폐기 기준이 아닙니다. 물품 보관·관계 기관 인계·개인정보 보유 기준은 적용 규정과 기관 방침을 확인해 별도로 확정해야 합니다.

도입 검수에서는 같은 번호의 물품을 다른 보관함으로 옮기는 경우, 두 문의가 한 물건을 주장하는 경우, 승인 후 방문하지 않는 경우, 송장 발급 후 반송되는 경우를 직접 따라가 봅니다. 화면에 완료가 표시되는지만 보지 말고 다음 근무자가 실물 위치와 미처리 사유를 설명할 수 있는지 확인합니다. 처음에는 접수·위치 조회·소유자 검토·방문 인계부터 만들고, 처리량에 맞춰 알림과 배송 연계를 추가할 수 있습니다.

설계 질문을 정리할 때 참고한 자료: Prostay 분실물 기록 안내, ileftmystuff 운영 가이드. 해외 자료의 보관 기간과 법률 설명은 위 예시에 적용하지 않았습니다.

소프트모아의 업무 시스템 구축 서비스는 softmoa.com에서 확인할 수 있습니다.

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