전자결재 시스템 구축 6단계, 결재선 설계가 먼저

전자결재 시스템 구축의 성패는 화면 디자인이 아니라 결재선과 예외 흐름 설계에서 갈립니다. 누가 어떤 순서로 결재하는지, 반려되면 어디로 돌아가는지, 결재자가 자리를 비우면 누가 대신 처리하는지를 데이터로 먼저 정한 뒤 개발에 들어가야 나중에 구조를 갈아엎지 않습니다. 기능 목록보다 회사의 결재 규정을 문서로 확정하는 일이 먼저입니다.

핵심 요약

• 결재선은 화면에 그리는 그림이 아니라 부서·금액·문서 종류에 따라 자동으로 바뀌는 규칙으로 설계합니다.
• 전결·대결·협조·반려·재상신 같은 예외 흐름이 실제 개발 난이도의 대부분을 차지합니다.
• 종이 결재 규정을 먼저 문서로 정리해야 시스템에 담을 규칙이 드러납니다.
• 규정이 단순하면 그룹웨어 도입, 복잡하고 연동이 많으면 자체 개발이 유리합니다.
• 전자문서로 승인한 기록도 법적 효력을 인정받으므로 이력과 보존 설계를 빠뜨리면 안 됩니다.

전자결재 용어부터 팀 전체가 맞춘다

같은 회사 안에서도 결재 용어를 서로 다르게 쓰는 경우가 많습니다. 기안은 문서를 처음 작성해 올리는 것, 결재는 중간 결재자가 승인하는 것, 최종결재는 마지막 승인권자가 확정하는 것을 뜻합니다. 여기에 전결·대결·협조가 붙습니다.

전결은 최종 결재권을 미리 위임받은 사람이 대표 대신 확정하는 방식이고, 대결은 결재자가 부재중일 때 대리인이 그 권한을 대신 행사하는 방식입니다. 협조는 결재선 밖의 부서가 의견을 다는 절차입니다. 이 용어들이 정리되지 않으면 요구사항 회의에서 같은 단어로 다른 것을 말하다 시간을 버립니다.

전자결재를 두고 흔한 오해가 몇 가지 있습니다. 종이 결재를 화면에 그대로 옮기면 끝이라고 여기기 쉽지만, 실제로는 규정에 없던 예외가 개발 도중에 드러나 일정을 늘립니다. 시스템만 사면 결재 규칙까지 따라온다고 믿는 경우도 있는데, 규칙은 회사마다 달라 결국 직접 정해 넣어야 합니다. 결재선만 잘 만들면 된다고 방심하다가는 반려와 위임 같은 예외 처리를 빠뜨려 운영 첫 주에 문제가 터집니다.

결재선은 고정이 아니라 규칙으로 설계한다

초보 설계에서는 결재선을 화면에 고정으로 그려 넣는 실수가 가장 흔합니다. 실제 회사는 금액이 얼마를 넘으면 결재자가 한 명 더 붙고, 문서 종류가 바뀌면 결재선 자체가 달라집니다. 결재선을 사람 이름이 아니라 조건과 규칙으로 저장해야 하는 이유입니다.

예를 들어 지출 100만 원 미만이면 팀장 전결, 이상이면 팀장을 거쳐 대표 결재처럼 금액 구간과 문서 유형을 입력으로 받아 결재선을 만들어 내는 구조입니다. 인사이동으로 팀장이 바뀌어도 규칙은 그대로 두고 사람만 갈아 끼우면 됩니다. 실제 프로젝트에서 막히는 지점은 기능이 아니라, 이 경우 누가 결재하나가 회사 안에서도 정해져 있지 않다는 데서 옵니다. 그래서 담당자에게 이렇게 물어봐야 합니다. "지금 종이로 결재할 때, 금액이 얼마를 넘으면 결재선이 어떻게 바뀌나요?"

예외 흐름이 시스템의 진짜 난이도다

정상적으로 순서대로 승인만 되는 흐름은 어렵지 않습니다. 문제는 예외입니다. 결재자가 반려하면 문서는 기안자에게 돌아가고, 기안자는 고쳐서 다시 올립니다. 이때 원래 문서를 지우고 새로 만들면 왜 반려됐는지 기록이 사라집니다. 반려 사유와 수정 이력, 문서 버전을 남기도록 설계해야 나중에 분쟁을 피합니다.

대결도 까다롭습니다. 결재자가 휴가를 가면 그 기간에 올라온 문서만 대리인에게 넘어가야 하고, 복귀하면 원래 권한으로 되돌아와야 합니다. 위임 기간과 위임 범위를 데이터로 관리하지 않으면 엉뚱한 사람이 계속 결재하는 사고가 납니다. 이런 상태 변화를 어디에 어떻게 저장할지는 데이터베이스 기초 개념과 함께 잡아 두면 이해가 빠릅니다.

구축은 규정 문서화부터 시작한다

전자결재는 코드보다 규정 정리가 먼저입니다. 순서대로 밟으면 재작업을 크게 줄입니다.

1. 지금 종이나 메신저로 하는 결재를 문서 종류별로 모두 적습니다.
2. 문서마다 금액·부서 조건에 따라 결재선이 어떻게 바뀌는지 표로 정리합니다.
3. 전결·대결·협조 규칙과 예외 처리 기준을 명문화합니다.
4. 이 규정을 요구사항 정의서 형태로 개발자와 공유합니다.
5. 규칙 기반 결재선, 반려·재상신, 위임을 순서대로 개발하고 검수합니다.
6. 부서 한 곳에서 시범 운영한 뒤 전사로 확대합니다.

직접 개발과 그룹웨어 도입, 어떻게 고르나

모든 회사가 전자결재를 직접 만들 필요는 없습니다. 규정이 단순하면 이미 나와 있는 그룹웨어가 빠르고 저렴합니다. 반대로 결재 규칙이 복잡하거나 회계·인사 시스템과 촘촘히 연동해야 하면 자체 개발이 오히려 총비용을 줄입니다.

구분	그룹웨어 도입	자체 개발
도입 속도	빠르다	느리다
결재 규칙 유연성	정해진 틀 안에서만	회사 규정에 맞춰 자유롭게
타 시스템 연동	제한적	필요한 만큼 설계
적합한 경우	규정 단순·소규모	규정 복잡·연동 많음

사내 업무 시스템을 웹으로 만드는 범위와 방식은 웹앱 개발 쪽에서 더 구체적으로 다룹니다. 웹사이트와 사내 시스템의 차이가 헷갈리면 웹앱과 웹사이트 차이를 먼저 읽어 두면 좋습니다.

가상 예시로 정리해 보겠습니다. 직원 20명 제조업체가 지출결의서를 전자결재로 옮긴다고 가정합니다. 100만 원 미만은 팀장 전결, 그 이상은 대표까지, 3,000만 원을 넘으면 재무 협조를 자동으로 추가하는 규칙을 세웁니다. 대표가 출장이면 그 기간 문서만 부사장이 대결하도록 위임을 걸어 둡니다. 규칙으로 짜 두면 사람이 바뀌어도 화면은 손대지 않습니다.

전자결재로 승인한 문서도 종이 못지않은 효력이 있습니다. 전자문서 및 전자거래 기본법은 전자적 형태라는 이유만으로 문서의 법적 효력을 부인하지 않고, 내용을 열람하고 형태를 재현할 수 있게 보존한 전자문서는 서면으로 봅니다(찾기 쉬운 생활법령). 그래서 승인 기록과 보존 설계를 처음부터 넣어야 합니다.