권한, 상태, 승인으로 업무를 모델링하는 실무 기준

업무 모델링이 필요한 이유

업무를 시스템으로 옮길 때 많은 조직이 화면부터 떠올립니다. 하지만 화면은 결과일 뿐입니다. 먼저 정리돼야 하는 것은 업무가 어떤 규칙으로 움직이는지에 대한 모델입니다.

그 모델을 가장 현실적으로 설명하는 축이 권한, 상태, 승인입니다.

세 축은 따로 설계하면 충돌합니다

권한, 상태, 승인은 각각 독립된 설정처럼 보이지만 실제 업무에서는 한 문장으로 연결됩니다. 예를 들어 ‘검토 중인 요청은 검토자만 보완 요청할 수 있고, 보완 사유가 남아야 작성자가 재제출할 수 있다’는 규칙에는 역할, 상태, 행동, 기록이 모두 들어 있습니다. 메뉴 권한만 먼저 정하거나 상태 이름만 나열하면 이 연결이 빠져 실제 화면에서 예외가 생깁니다.

모델링은 복잡한 도식을 만드는 일이 아니라, 업무 건이 어떤 조건에서 다음 단계로 이동하는지 합의하는 작업입니다. 한 상태에서 가능한 행동과 금지된 행동, 행동을 수행할 수 있는 역할, 행동 뒤 남는 기록을 표로 만들면 이해관계자가 같은 기준으로 검토할 수 있습니다.

상태 전이 표를 먼저 만듭니다

표의 상태와 역할은 예시일 뿐입니다. 업무마다 필요한 단계는 다르지만, ‘완료’ 뒤에도 수정이 가능한지, 담당자 부재에는 누가 행동하는지 같은 질문을 빼지 않는 것이 중요합니다. 이 질문은 예외를 늘리기 위한 것이 아니라, 예외가 생겼을 때 메일로 흐름이 빠져나가지 않게 하기 위한 것입니다.

긴급 생산 변경을 공식 흐름에 넣으려면

다음은 가상의 생산 변경 요청입니다. 일반 요청은 작성자·검토자·승인자의 세 단계로 처리하지만, 긴급한 상황에서는 담당자가 일반 절차를 건너뛰고 싶어 할 수 있습니다. 모델에 긴급 상태와 권한이 없다면 담당자는 상태를 임의 수정하거나 별도 메신저에서 허가를 받게 됩니다.

대신 긴급 요청이라는 별도 행동을 두고, 요청 사유와 영향 범위를 입력하게 하며, 정해진 책임자가 이를 승인한 뒤 제한된 상태로 진행하게 설계할 수 있습니다. 사후 검토가 필요하다면 완료 뒤의 확인 상태도 둡니다. 이 가상 사례의 목적은 긴급 처리를 자동으로 허용하자는 것이 아니라, 표준 밖 행동도 책임과 기록을 갖게 하는 방법을 보여 주는 데 있습니다.

모델을 화면·알림·로그에 연결합니다

모델이 정해지면 화면에는 현재 상태와 가능한 행동만 보여 주고, 알림은 다음 책임자에게 보내며, 로그는 전이와 사유를 남깁니다. 이 세 구현 요소가 같은 모델을 사용해야 합니다. 화면에는 승인 버튼이 있는데 서버는 권한을 막지 않거나, 알림은 갔는데 상태가 바뀌지 않는다면 사용자는 흐름을 신뢰하기 어렵습니다. 개발·업무·운영 담당자가 전이 표를 함께 검토하는 이유가 여기에 있습니다.

진행 중인 건에는 별도의 전환 기준을 둡니다

상태 전이나 승인 역할을 바꿀 때 새 요청만 생각하면, 이미 진행 중인 건이 이전 규칙과 새 규칙 사이에 남습니다. 예를 들어 검토 단계를 하나 추가하면 기존 ‘승인 대기’ 건을 새 검토로 돌릴지, 기존 경로로 끝낼지를 정해야 합니다. 이를 정하지 않으면 같은 유형의 요청이 생성일에 따라 서로 다른 기준으로 처리되고, 담당자는 화면 밖에서 예외를 조율하게 됩니다.

첫 적용에서는 새 규칙이 적용되는 기준 시점과 기존 건의 처리 방식을 전이 표에 한 줄 추가합니다. 이관이 필요한 건에는 담당자와 사유를 남기고, 재검토가 필요한 건에는 이전 승인이나 첨부가 유효한지도 확인합니다. 모델의 완성도는 상태 수가 아니라, 규칙이 바뀌어도 진행 중인 업무의 책임과 이력이 끊기지 않는지에서 드러납니다.

예외가 잦은 업무 하나로 전이 표를 검증합니다

전이 표의 변경은 기존 진행 건에 어떤 영향을 주는지도 확인하고, 필요하면 이관 또는 재검토 기준을 운영 절차에 함께 추가합니다.

반복 빈도가 높고 예외가 잦은 업무 하나를 골라 상태 전이 표를 작성해 보세요. 표에서 책임자나 근거가 빠진 칸이 실제 운영에서 메일과 기억에 의존하게 될 지점입니다.

전이 표는 고정된 산출물이 아니라 실제 운영을 통해 보완하는 기준입니다. 초기에는 자주 발생하는 정상·반려·재제출 경로부터 모델링하고, 실제 예외가 발생했을 때 임시 우회로를 만들기보다 어떤 상태와 판단 규칙이 부족했는지 검토합니다. 변경한 모델은 업무 담당자, 운영자, 개발자가 함께 확인해야 합니다. 그래야 시스템의 버튼, 권한, 알림, 이력이 서로 다른 규칙을 따르는 상황을 줄일 수 있습니다.

상태 이름보다 전환의 책임이 중요합니다

상태 모델은 ‘진행 중’처럼 넓은 이름을 붙이는 작업이 아닙니다. 같은 진행 중이라도 작성자가 보완 중인 상태와 검토자가 판단 중인 상태는 허용되는 행동과 책임자가 다릅니다. 각 상태에는 들어오는 조건, 담당 역할, 가능한 행동, 나갈 때 필요한 근거를 적습니다. 특히 완료는 단지 마지막 상태가 아니라 정정·취소·재처리가 가능한지와 보관 기준을 함께 결정해야 하는 상태입니다. 이 네 가지 질문에 답할 수 없다면 상태를 더 늘리기보다 규칙을 먼저 정리하는 편이 낫습니다.

상태마다 들어오는 조건, 현재 책임, 허용 행동, 나갈 때 필요한 근거를 적습니다. ‘진행 중’처럼 책임이 다른 일을 한 상태에 묶지 않고, 보완 중과 검토 중을 구분합니다. 완료 상태에도 정정·취소·재처리 가능 여부와 보관 기준을 둡니다. 정정이 필요하면 과거 승인을 삭제하거나 상태만 되돌리지 않고, 정정 사유·영향 범위·재검토 책임자가 있는 경로로 이동합니다. 이렇게 해야 승인 사실과 그 뒤의 조치가 함께 남습니다.

권한 표와 전이 표를 분리해 검토합니다

역할 권한은 상태 모델과 비슷해 보이지만 다른 질문입니다. 전이 표가 어떤 행동이 다음 상태를 만드는지 설명한다면, 권한 표는 누가 그 행동과 조회를 할 수 있는지 설명합니다. 대리 처리, 겸직, 담당자 변경은 이 둘이 어긋나기 쉬운 지점입니다. 예를 들어 대리자는 원 담당자의 모든 이력을 수정할 필요 없이, 제한된 기간에 제출 또는 검토만 할 수 있어야 할 수 있습니다. 권한 부여 사유와 만료 시점도 업무 건과 연결하면 임시 접근이 영구 권한으로 남는 위험을 줄일 수 있습니다.

모델을 배포하기 전에는 정상 전이뿐 아니라 이미 처리된 건을 다시 눌렀을 때, 두 사람이 동시에 처리했을 때, 규칙이 바뀐 뒤 기존 건을 열었을 때를 확인합니다. 결과가 예상과 다르면 화면의 버튼을 숨기는 것으로 끝내지 말고 원래 전이·권한·이력 규칙 중 어디가 부족한지 수정해야 합니다. 모델은 다이어그램 자체가 아니라 실제 업무가 같은 기준으로 움직이게 하는 계약입니다.

메신저와 수동 보정은 모델의 빈칸을 보여 줍니다

특정 상태를 건너뛰는 수동 처리, 승인 뒤 메신저로 이뤄지는 재작업, 담당자 변경 때마다 새로 만드는 임시 권한은 모델의 빈칸을 보여 줍니다. 이런 사례를 사용자 실수로만 종료하지 말고, 실제 전이에 없는 경로인지, 역할 경계가 좁은지, 화면에서 필요한 정보를 못 찾는지 검토합니다. 예외를 공식 전이로 승격할지 수동 절차로 제한할지 결정하고, 어느 쪽이든 사유와 확인 책임을 남겨야 운영 규칙이 현실을 따라갈 수 있습니다.

반복 예외만 공식 전이로 승격합니다

정상 흐름이 잘 그려진 모델도 담당자 부재, 재제출, 정정처럼 현실의 예외가 화면 밖으로 나가면 곧 무너집니다. 업무 책임자는 빠른 처리를 위해 우회를 원할 수 있고, 운영자는 우회 사실과 근거를 남겨야 합니다. 전문가는 예외를 모두 새 상태로 만들기보다, 반복되고 책임이 달라지는 예외만 공식 전이로 승격합니다. 드문 예외는 수동 절차로 두되 승인자와 기록 위치를 분명히 합니다.

대리 처리에는 허용 행동, 적용 기간, 권한 부여 사유를 두고 원 역할의 모든 권한을 복제하지 않습니다. 동시에 두 사용자가 행동하면 나중 요청은 최신 상태를 다시 읽고 중단해야 하며, 수동 보정이 필요하면 사유와 승인자를 남깁니다. 정정은 이전 결정을 삭제하는 대신 영향과 재검토 범위를 가진 새 전이로 처리합니다. 이 복구 기준이 없으면 화면은 정상처럼 보여도 실제 이력과 책임이 어긋납니다.

전이가 실패했을 때 복구하고 모델을 갱신합니다

상태 변경이 실패하면 사용자는 같은 버튼을 반복하기보다 현재 상태와 처리 결과를 확인할 수 있어야 합니다. 운영자는 실패 시각, 입력한 근거, 동시 처리 여부를 보고 재시도·수동 처리·에스컬레이션 중 하나를 선택합니다. 수동으로 상태를 보정했다면 사유와 승인자를 남기고, 모델에 없는 일이 반복되는지 다음 회의에서 검토합니다.

상태 모델의 변경은 알림과 보고서에도 영향을 줍니다. 새 상태가 추가되면 누가 알림을 받고, 기존 미완료 목록에서 어떻게 보이는지 확인해야 합니다. 보이지 않는 상태는 결국 사람의 기억과 수동 목록으로 관리될 가능성이 큽니다.

최근 수동 보정한 건 하나를 전이 표에 대입해, 빠진 상태보다 먼저 빠진 책임·근거·복구 행동을 표시해 보세요.