상신 누른 직후 발견한 단가 오류, 결재판 멈추는 문서 회수 기술의 이면

월요일 오전 8시 40분, 중견 기계장비 제조사 영업관리팀 모니터에는 주간 발주 승인 요청 30여 건이 한꺼번에 올라왔다. 담당 직원은 원자재 단가 인상분이 반영되지 않은 지난달 견적서가 결재선에 포함된 사실을 상신 버튼을 누른 직후에야 발견했다. 결재권자가 아직 문서를 열람하지 않은 상태였지만, 시스템에서 즉시 문서를 거두지 못하면 잘못된 단가가 전산에 그대로 남을 수 있는 상황이었다.

중견 제조업 현장에서는 생산 계획과 단가 승인이 맞물려 돌아가기 때문에 기안자가 결재 진행 중 실수를 바로잡는 기능이 필수적이다. 결재자가 이미 서명했거나 문서를 열어본 뒤에는 원칙적으로 회수가 제한되지만, 이전 단계에서는 기안자가 직접 회수해 수정한 뒤 재상신할 수 있어야 결재선의 혼선을 막을 수 있다.

상태 전이 제어와 락킹 매커니즘

문서 회수 기능의 핵심은 결재 엔진의 상태 제어 구조에 있다. 기안자가 회수 요청을 보내는 순간 시스템은 해당 문서에 쓰기 잠금(Write Lock)을 걸어 상위 결재자의 추가 승인 처리를 일시 차단한다. 쓰기 잠금은 동일한 데이터에 여러 요청이 동시에 발생할 때 충돌을 막기 위해 다른 사용자의 수정을 제한하는 기술 방식이다.

이후 결재 진행 상태가 열람 전인지 확인하는 검증 루틴을 거쳐 기안 상태를 초기 작성 단계로 되돌린다. 이때 데이터베이스 내부에서는 결재 대기열에 걸려 있던 트랜잭션을 안전하게 취소(Rollback)하고, 기안자의 임시 저장소로 문서 소유권을 다시 넘긴다.

"결재자가 문서를 읽는 순간과 기안자가 회수 버튼을 누르는 순간이 겹칠 때 데이터 충돌이 생기기 쉽다. 이때는 상태 검증 로직이 엄격하게 동작해 중복 처리를 막아야 결재 누락이나 승인 오류를 방지할 수 있다." 제조사 시스템 운영팀 관계자의 설명이다.

회수 이력 보존과 감사 로그 설계

단순히 문서를 되돌리는 것에 그치지 않고 회수 과정 전체를 감사 로그에 남기는 작업도 뒷단에서 이뤄진다. 잘못된 기안을 올렸다가 회수한 뒤 내용을 임의로 변조하는 부정행위를 막기 위해서다. 시스템은 기안 시점, 회수 요청 시각, 회수 사유, 당시 결재선의 진행 상황을 분리된 로그 스토리지에 기록한다.

감사 로그는 일반 업무 데이터베이스와 물리적으로 분리된 저장소에 보관되며, 위변조를 방지하기 위해 해시 체인 방식으로 묶인다. 결재 문서가 회수되어 결재판에서 사라지더라도 내부 감사팀은 언제든 원본 기안과 회수 사유 로그를 대조할 수 있도록 인프라를 구축한다.

기간계 시스템과의 트랜잭션 정합성 유지

그룹웨어에서 문서가 회수될 때 ERP(전사적 자원관리)나 SCM(공급망 관리) 등 외부 시스템과의 데이터 일치 여부도 함께 점검해야 한다. 구매 품의서나 단가 승인 문서가 상신되는 시점에 ERP 시스템에 가등록된 전표 데이터가 존재한다면, 회수 이벤트가 발생했을 때 이 전표 역시 즉시 연동 해제되거나 무효화되어야 한다.

이를 위해 결재 엔진은 REST API와 웹훅(Webhook)을 통해 기간계 시스템에 회수 이벤트를 실시간으로 전송한다. 외부 시스템이 회수 신호를 정상 수신했다는 응답(ACK)을 보내야만 최종적으로 그룹웨어 내 문서 회수 처리가 완료된다. 연동 장애로 한쪽 시스템만 취소되는 불일치 현상을 차단하기 위한 조치다.

회수 기능 도입 시에는 조직 내 전결 규정에 맞춘 세부 권한 설정도 선행되어야 한다. 결재자가 열람만 하고 승인하지 않은 상태에서 회수를 허용할지, 결재선 중간에 합의 부서가 포함된 경우 어떤 단계까지 회수 권한을 부여할지 기준을 명확히 세우지 않으면 부서 간 업무 마찰로 이어질 수 있다는 지적이 나온다.

※ 본 기사의 사례는 도입 현장에서 반복적으로 확인되는 상황을 바탕으로 재구성한 것이다.