조직 개편 공지가 올라온 날이면 개발팀에 어김없이 요청이 들어옵니다. "구매 품의 결재선에 신설 실장을 넣어 주세요." 결재선이 코드 안에 들어 있는 회사에서 반복되는 장면입니다. 이 글에서는 승인 기능을 하나의 워크플로 엔진으로 분리할 때 필요한 설계 기준을 정리합니다.
승인 로직이 화면마다 흩어진 시스템
구매, 휴가, 지출, 견적 승인을 필요할 때마다 따로 만들면 비슷하지만 조금씩 다른 승인 코드가 네 벌 생깁니다. 상태값 이름도, 반려 처리 방식도 제각각입니다.
한국형 결재선의 요구사항
국내 결재는 유형이 세분화되어 있어 단순한 승인/반려 모델로는 담기 어렵습니다.
결재선은 조건에 따라 자동으로 결정되어야 합니다. 예를 들어 지출 500만 원 미만은 팀장 전결, 500만 원 이상 3,000만 원 미만은 본부장, 3,000만 원 이상은 대표 승인으로 두는 식입니다. 여기에 회수, 반려 후 재상신, 진행 중 결재선 변경까지 더하면 상태 전이는 생각보다 복잡해집니다.
워크플로 엔진의 데이터 모델
핵심은 네 가지를 분리하는 것입니다.
결재선 정의에는 사람이 아니라 "기안자의 팀장", "재무팀 담당자" 같은 역할을 적고, 상신 시점에 조직도에서 실제 사람으로 풀어 인스턴스에 고정합니다. 조직도와 직위에는 유효 시작일·종료일을 두어 과거 문서를 열어도 당시 직책이 그대로 보이도록 합니다. 겸직자는 어느 부서 자격으로 결재했는지를 이력에 남깁니다.
모든 것을 설정으로 만들려는 시도는 권하지 않습니다. 금액 구간, 단계 수, 역할 매핑은 설정으로 두고, 결재 완료 후의 업무 처리는 코드로 남기는 편이 운영하기 쉽습니다.
업무 시스템과 연결하는 방식
엔진은 "결재 완료" 이벤트를 발행하고, 업무 시스템이 이를 받아 자기 데이터의 상태를 바꿉니다. 결재 상태 변경과 이벤트 기록을 한 트랜잭션에 묶는 아웃박스 패턴을 쓰면 이벤트 누락을 막을 수 있습니다. 수신 측은 문서 ID 기준으로 중복 처리를 막고, 실패한 건은 간격을 늘려 가며 재시도한 뒤 그래도 실패하면 관리자 화면에 노출합니다. 하루 한 번 양쪽 상태를 대조하는 배치도 함께 두는 것이 안전합니다.
기존 그룹웨어를 쓸지는 연동 범위로 판단합니다. 일반 품의처럼 문서 중심이면 그룹웨어 결재로 충분합니다. 반면 승인 결과가 재고·발주·정산 데이터를 직접 바꿔야 하는데 그룹웨어의 연동 API가 제한적이라면 자체 엔진이 유리합니다.
운영에서 드러나는 문제들
POLYGLOTSOFT의 접근
POLYGLOTSOFT는 승인 기능을 업무 화면에서 떼어 내 공통 승인 모듈로 설계하고, ERP·MES·WMS 등 여러 시스템이 같은 엔진을 호출하는 구조를 제안합니다. 결재 규칙은 구축 후에도 계속 바뀌기 때문에, 구독형 개발로 위임전결 규정 개정이나 조직 개편에 상시 대응하는 방식이 잘 맞습니다. 결재선이 바뀔 때마다 개발 일정을 잡고 계신다면 POLYGLOTSOFT에 문의해 주시기 바랍니다.