모든 업무 시스템은 전자결재와 연동되어야 한다

출퇴근 정정, 연차 신청, 구매 요청 — 회사의 거의 모든 업무는 결국 “누군가의 승인”으로 귀결됩니다. 그렇다면 결재를 별도 시스템으로 떼어 놓을 게 아니라, 모든 업무가 결재와 같은 뼈대를 공유해야 합니다. 이게 에이전트 시대에는 선택이 아니라 필수였습니다. 이 글은 “결재가 모든 업무의 등뼈”라는 원칙이 왜 옳았는지의 기록입니다.

전자결재·결재선·상태머신

용어: 전자결재

종이 결재판을 시스템으로 옮긴 것입니다. 누군가 문서를 올리면(상신) 정해진 사람들이 차례로 승인하고, 마지막 승인이 끝나면 법적 효력이 생깁니다.

용어: 결재선

그 문서가 거쳐 갈 승인자들의 순서입니다. “팀장 → 부서장 → 임원” 같은 줄입니다. 사무직과 생산직처럼 처리 방식이 다르면 이 줄이 갈라집니다.

용어: 상태머신(state machine)

문서가 가질 수 있는 상태(작성·상신·승인 중·승인·반려…)와 그 사이 허용된 이동만 정의한 규칙표입니다. “승인 끝난 문서는 다시 작성 상태로 못 돌아간다” 같은 제약을 한 곳에서 강제합니다.

승인은 모든 업무의 공통 분모다

처음엔 출퇴근은 출퇴근대로, 연차는 연차대로, 결재는 결재대로 따로 만들 생각이었습니다. 그런데 들여다볼수록 같은 구조가 반복됐습니다 — 누군가 무언가를 요청하고, 정해진 라인을 따라 승인이 흐르고, 완료되면 효력이 생깁니다. 이 흐름을 모듈마다 제각각 구현하면 같은 버그를 여러 번 만들고, 같은 규칙을 여러 곳에 흩뿌리게 됩니다.

에이전트 관점에서는 더 분명해집니다. 에이전트가 “이 업무에서 사람의 승인이 필요한 지점”을 일관되게 다루려면, 승인이라는 행위가 한 가지 형태여야 합니다. 모듈마다 다른 승인 메커니즘이 있으면 에이전트는 모듈 수만큼의 예외를 외워야 합니다. 반대로 승인이 하나의 형태면, 에이전트는 “승인 필요 → 결재 문서 생성 → 결재선에 올림” 한 패턴만 알면 모든 모듈에서 똑같이 작동합니다.

가장 에이전트에 근접했던 모듈

전자결재는 처음부터 “요청 → 판단 → 승인/반려”라는 흐름을 가졌기 때문에, 구현된 모듈 중 에이전트 시대 패턴(이벤트 → 판단 → 인간 승인)에 가장 가까웠습니다. 우연이 아닙니다 — 결재는 본래 동사(“승인한다·반려한다”)로 이뤄진 업무이기 때문입니다. 나머지 모듈을 결재 쪽으로 끌어당기는 게 옳은 방향이라는 신호였습니다.

구체적 사례 — 출퇴근 정정이 결재 문서가 되다

이 원칙을 실제로 적용한 게 출퇴근 정정입니다. 직원이 잘못 찍힌 출퇴근 기록을 고쳐 달라고 요청하는 상황을 떠올려 보세요. 흔한 설계라면 출퇴근 모듈 안에 “정정 승인” 절차를 따로 만듭니다. 우리는 그렇게 하지 않았습니다.

1. 정정 요청 — 직원이 “이 날 출근 시각을 고쳐 주세요”라고 요청합니다.
2. 결재 문서 자동 생성 — 그 순간 전자결재 문서가 자동으로 만들어집니다. 별도 승인 절차가 아니라, 진짜 결재 문서입니다.
3. 결재선을 탄다 — 그 문서가 정해진 결재선을 따라 흐릅니다. 다른 모든 결재와 똑같이.
4. 분기는 결재선으로 흡수 — 사무직과 생산직처럼 처리 방식이 달라야 하면, 별도 시스템이 아니라 결재선 분기로 갈립니다.

덕분에 정정 요청도 다른 모든 결재와 똑같이 추적되고, 똑같은 권한 규칙을 따르고, 똑같은 상태 흐름을 가집니다. “출퇴근 정정 전용” 코드를 거의 새로 짜지 않고, 이미 있는 결재 뼈대를 그대로 빌려 쓴 것입니다. 사소해 보이는 정정 한 건도 결재 문서로 만들면, 일관성과 법적 추적성을 공짜로 얻습니다.

법적 효력을 지키는 단일 권위 — 상태 전이

모든 업무를 결재로 묶으면 한 가지가 절대적으로 중요해집니다 — 상태 전이를 한 곳에서만 관리하는 것입니다. 문서가 작성·상신·승인 중·승인·반려·회수 사이를 오갈 때, 그 전이가 모듈마다 제각각이면 무결성이 깨집니다. 어떤 서비스가 “승인 완료된 문서를 슬쩍 작성 상태로 되돌리는” 코드를 짜 버리면, 그 순간 전자결재의 법적 효력이 무너집니다.

문서가 가질 수 있는 상태와 허용된 이동만 그린 그림입니다. 승인 완료에서 다시 작성으로 돌아가는 화살표는 없습니다. 고치려면 정식 재오픈 절차를 거쳐야 합니다. 반려·취소는 종착(terminal)이라 더 이상 움직이지 않습니다. 이 표가 한 곳에만 있어야 무결성이 지켜집니다.

그래서 다음 규칙들을 시스템이 물리적으로 강제하게 했습니다.

규칙	무엇을 막는가
모든 상태 변경은 단일 게이트 통과	서비스가 제멋대로 상태를 쓰는 것
완료 문서 본문 수정 금지	승인 끝난 문서를 조용히 고치는 것 (정식 재오픈만 허용)
마감 회계 기간 재오픈 거부	닫힌 장부를 되여는 것
전자서명은 무효화만 허용	서명을 사후 조작하는 것

함정: “완료된 것은 불변”이 법적 효력의 조건이다

이 규칙들은 편의가 아닙니다. 결재 완료된 문서를 누가 조용히 고칠 수 있다면, 전자결재는 법적으로 무의미해집니다. “이 문서는 그때 이 사람이 분명히 승인했다”는 증명이 깨지기 때문입니다. 그래서 게이트 우회(직접 상태 쓰기)가 생기지 않도록 코드 리뷰로 막고, 완료 문서의 불변성을 시스템이 강제하게 했습니다. 편하자고 한 줄 우회하면 법적 효력 전체가 무너집니다.

별도로 짓는 것보다 항상 싸다

모듈마다 승인 절차를 따로 짓는 건 처음엔 빨라 보입니다. 출퇴근 정정 승인을 출퇴근 모듈 안에서 후딱 만들면 되니까요. 그런데 그렇게 하면 같은 “요청-승인-완료” 로직이 모듈 수만큼 복제되고, 상태 전이 규칙도 모듈마다 따로 살게 됩니다. 버그를 한 번 고치면 다른 모듈에서 같은 버그가 또 튀어나옵니다.

반대로 모든 업무를 하나의 결재 뼈대에 태우면, 상태 전이·권한·추적이 한 곳에서 관리됩니다. 새 업무가 승인을 필요로 할 때마다 “결재 문서를 만들어 결재선에 올린다”는 한 줄이면 끝이고, 차이는 결재선 분기로 흡수합니다. 등뼈는 하나, 갈비뼈만 모듈마다 다른 셈입니다.

	모듈마다 따로	하나의 결재 뼈대
승인 로직	모듈 수만큼 중복	한 곳에 한 번
상태 전이 규칙	모듈마다 따로 (불일치 위험)	단일 게이트가 강제
버그 수정	같은 버그가 모듈마다 재발	한 번 고치면 전부 적용
새 업무 추가	승인 절차를 또 짠다	”문서 생성 → 결재선” 한 줄
모듈 간 차이	별도 시스템으로 분기	결재선 분기로 흡수

교훈

승인은 거의 모든 업무의 공통 분모이므로, 결재를 별도 시스템으로 분리하면 같은 로직을 모듈 수만큼 중복하게 됩니다. 모든 업무를 하나의 전자결재 뼈대(같은 상태머신·같은 권한·같은 추적)에 태우고, 차이는 결재선 분기로 흡수하세요. 출퇴근 정정처럼 사소해 보이는 요청도 결재 문서로 만들면 일관성과 법적 효력을 공짜로 얻습니다. 그리고 상태 전이는 반드시 한 곳에서만 강제하세요 — 우회로가 하나라도 생기면 법적 효력 전체가 무너집니다.

---

이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.