규모 확장에도 견디는 승인 워크플로우 청사진

팀이 커질수록 승인 워크플로우가 깨지는 이유

승인 워크플로우는 사람들이 신경 쓰지 않아서 실패하는 경우가 드뭅니다. 대부분은 프로세스가 소규모 팀을 기준으로 설계되어 있어 모든 사람이 암묵적인 규칙을 알고 있다고 가정했기 때문에 실패합니다. 팀이 커지면 그 공유된 기억은 사라집니다.

규모가 커질 때 워크플로우가 깨지는 모습은 대개 이렇습니다: 다음 단계의 소유자가 누구인지 몰라 요청이 방치되거나, 승인 결정이 채팅이나 이메일에서 일어나 감사 기록이 남지 않거나, 기한을 맞추기 위해 사람들이 프로세스를 우회해 재무나 운영팀이 뒤처리를 해야 하거나, 최신 버전과 맥락이 불명확해 동일한 요청이 두 번 승인되거나 전혀 승인되지 않는 경우입니다.

근본 원인은 규칙이 워크플로우에 적혀 있지 않고 사람들 머릿속에만 있다는 점입니다. 예를 들어 "마케팅 도구는 $500 이하이면 팀장이 승인할 수 있지만 신규 공급업체이면 예외" 같은 규칙을 누군가가 알고 있지만 시스템에는 반영되어 있지 않습니다. 그 사람이 자리를 비우면 모든 것이 느려집니다.

성장하면서 "승인"의 의미도 바뀝니다. 요청 유형, 승인자, 예외가 늘어납니다. 구매 요청은 할인 요청이나 접근 권한 요청과 같지 않습니다. 각 요청은 다른 위험도를 가지며 다른 정보와 증빙이 필요합니다.

볼륨이 두 배로 늘어날 때도 견디는 워크플로우는 몇 가지 기본을 보호해야 합니다:

• 명확성: 현재 단계와 다음 행동의 소유자가 모두 보입니다.
• 속도: 흔한 경우는 "그 한 사람"을 기다리지 않고 빠르게 진행됩니다.
• 책임성: 결정과 코멘트는 기록되어 검색 가능합니다.
• 예측 가능성: 기한, SLA, 에스컬레이션은 수동으로 쫓아다니는 것이 아니라 내장되어 있습니다.

대개는 임시 메시지에서 명시적 프로세스로 옮겨야 합니다. 단계, 조건, 소유권을 가시적으로 만들고 반복 가능하게 설계하세요.

범위와 명확한 완료 정의로 시작하세요

많은 워크플로우가 실패하는 이유는 요청이 무엇인지, 언제 끝나는지에 대한 합의가 없기 때문입니다. 무엇을 그리기 전에 경계와 완료선을 정의하세요.

요청을 평이한 용어로 정의하세요. 누가 제출할 수 있나요? 어떤 정보가 포함되어야 하나요? 검토하기에 충분히 완전하다고 간주되는 기준은 무엇인가요? 양식에 사람들이 "해당 없음(N/A)"를 아무 데나 넣을 수 있으면 승인자는 모든 것을 막거나 무비판적으로 승인하게 됩니다.

승인 외의 결과를 정의하세요. 승인자가 변경을 요구하면 어떻게 되는가, 요청이 더 이상 필요 없을 때는 어떻게 처리할 것인가, 거부되면 어떤 결과가 발생하는가를 결정하세요. 이러한 선택은 이후의 모든 단계를 형성합니다.

초기에 소유권을 할당하세요. 프로세스 소유자는 규칙과 업데이트에 대한 책임이 있습니다. 승인자는 결정에 책임이 있으며 설계까지 책임지지 않습니다. 재무, 보안, 법무 같은 검토자는 조언을 제공할 수 있지만 항상 최종 결정을 소유하지는 않습니다.

범위를 명확히 규정하세요. "$500 초과의 모든 지출 요청"은 명확합니다. 반면에 "구매"는 모호합니다. 또한 범위에서 제외되는 항목(예: 출장비 환급이나 갱신은 다른 곳에서 처리됨)도 명시해 워크플로우가 모든 것을 포함하는 잡동사니가 되지 않도록 하세요.

구축 전에 짧은 요구사항 점검을 하면 나중에 재작업을 줄일 수 있습니다:

• 누가 제출하고 누가 요청을 볼 수 있는가?
• 어떤 필드가 필수인지, 어떤 값이 허용되는가?
• 어떤 결과(승인, 거부, 수정 요청, 취소)가 존재하며 누가 각 결과를 트리거할 수 있는가?
• 프로세스 소유자는 누구이며 어떤 역할이 승인 권한을 가지는가?
• 명시적으로 범위에서 제외되는 항목은 무엇인가?

간단한 예: 노트북 요청은 "승인되어 조달로 인계되었을 때", "사유를 붙여 거부되었을 때", 또는 "누락된 세부사항 목록과 함께 되돌려졌을 때"만 완료된 것으로 간주합니다. 이런 정의가 없으면 동일한 요청이 여러 날 동안 떠돌아다닐 수 있습니다.

재사용 가능한 간단한 승인 흐름 골격

작고 반복 가능한 골격으로 시작하고 신중하게 확장하세요. 대부분의 확장 문제는 책임이 뒤섞이거나 "하나만 더" 예외를 추가하면서 다음에 무엇이 일어나는지 추적을 잃을 때 발생합니다.

많은 워크플로우에 재사용할 수 있는 골격:

• 접수(Intake): 누군가가 요청을 제출합니다.
• 검증(Validation): 완전성 및 정확성에 대한 기본 검사.
• 검토(Review): 맥락, 질문, 보조 자료 수집.
• 결정(Decision): 승인 또는 거부.
• 이행(Fulfillment): 승인된 작업을 수행.
• 기록 보관(Recordkeeping): 종료하고 발생한 일을 저장.

**검사(Checks)**는 **승인(Approvals)**과 분리하세요. 검사는 "이것이 유효하고 완전한가?"를 답합니다. 승인은 "우리가 허용해야 하는가?"를 판단합니다. 검증은 보통 운영팀이나 요청 소유자에게 속합니다. 승인은 위험, 예산, 정책에 책임이 있는 역할에 속합니다.

또한 단계를 작게 유지하세요: 목표는 한 단계당 하나의 결정입니다. 하나의 단계에서 예산, 규정 준수, 기술적 타당성을 모두 판단하도록 하면 정체되거나 회의로 이어집니다.

마지막으로, '요청 변경' 경로를 포함해 적절한 장소로 돌아가게 하세요. 예를 들어 재무가 누락된 견적을 요구하면 요청자(또는 검증 단계)로 라우팅한 다음 재무 검토로 다시 돌아가게 하세요. 법무나 경영단계를 다시 반복할 필요는 없습니다.

읽기 쉬운 조건부 라우팅 규칙

조건부 라우팅은 워크플로우가 미로로 바뀌는 지점입니다. 해결책은 대부분 규율입니다: 소수의 입력을 선택하고, 규칙을 평이한 문장으로 작성한 뒤 그대로 구현하세요.

사람들이 이미 이해하고 일관되게 입력할 수 있는 라우팅 입력값(금액, 부서 또는 비용 센터, 위험 수준, 공급업체 유형(기존 vs 신규), 지역 등)에만 의존하세요.

규칙은 구현하기 전에 한 줄 문장으로 작성하세요. 한 줄에 들어가지 않으면 보통 너무 많은 일을 하려는 신호입니다.

읽기 쉬운 예시:

• "금액이 $1,000 미만이면 팀장으로 라우팅합니다. $1,000 이상이면 재무로 라우팅합니다."
• "공급업체가 신규이면 재무 전에 벤더 관리(Vendor Management)를 추가합니다."
• "위험이 높으면 부서와 무관하게 보안 검토를 추가합니다."

특별한 경우는 피할 수 없으니 이름을 붙여 분리하세요. "긴급(Urgent)"은 흔한 예입니다. 긴급의 정의(24시간 내 마감, 고객 장애 등)를 정한 뒤 더 적은 단계지만 더 엄격한 노트를 요구하는 빠른 경로로 라우팅하세요.

여러 규칙이 적용될 때는 충돌 해결 방식을 미리 결정하세요. 일반적인 패턴으로는 우선순위 순서(위험이 금액을 우선함), 쿼럼(3명 중 2명), 전원 승인(직렬 또는 병렬), 또는 타이브레이커 역할이 있습니다.

라우팅을 2분 대화로 설명할 수 있으면 팀이 두 배가 되어도 읽기 쉽게 유지됩니다.

수동 추적 없이 SLA와 에스컬레이션 작동시키기

SLA는 "보통은 작동한다"는 프로세스를 볼륨이 커져도 예측 가능한 것으로 바꿉니다. 목표는 단순합니다: 결정은 제때 이루어지고, 누구도 큐를 계속 붙들고 있지 않아도 됩니다.

대부분의 팀은 하나 이상의 시계가 필요합니다:

• 첫 응답 시간(Time to first response) (인정, 수정 요청, 승인 또는 거부)
• 최종 결정 시간(Time to final decision) (승인 또는 거부)
• 이행 시간(Time to fulfill) (승인된 후 후속 작업이 완료되는 시간)

모든 것에 하나의 전역 타이머를 사용하지 마세요. 위험이 낮은 요청은 결정에 24시간을 허용하고, 고가치 요청은 더 짧은 기준이 필요할 수 있습니다. SLA는 요청 유형, 금액, 위험에 연결해 규칙이 공정하게 느껴지도록 하세요.

에스컬레이션은 사다리형으로 설계하세요, 놀라운 재할당이 되어선 안 됩니다. 간단한 패턴:

• 현재 승인자에게 알림(리마인더)
• 승인자의 매니저(또는 대리인)에게 에스컬레이션
• 필요 시 대체 승인자 그룹으로 재할당
• 변경된 상태와 예상 다음 시간을 요청자에게 알림

끝없는 논쟁을 막는 한 가지 세부사항: 시계를 언제 일시 정지하는지 정의하세요. 요청이 추가 정보 때문에 반송되면 SLA는 요청자 응답이 있을 때까지 정지되어야 합니다. 외부 서류를 기다리는 경우는 단순 코멘트가 아니라 실제 "대기(Waiting)" 상태여야 합니다.

나중에 필요할 상태, 감사 기록, 권한

확장 가능한 워크플로우는 단계와 조건만이 아닙니다. 명확한 상태, 신뢰할 수 있는 감사 기록, 조직 방식에 맞는 권한이 필요합니다. 이를 건너뛰면 첫날에는 괜찮아 보이지만 30일 후에는 고통스러워집니다.

모두가 이해할 수 있는 상태 레이블로 시작하세요. 워크플로우 전반에 걸쳐 일관되게 유지하세요: 초안(Draft), 대기(Pending), 승인(Approved), 거부(Rejected). 세부가 필요하면 팀별로 새로운 최상위 상태를 발명하기보다 "Pending: Finance" 같은 하위 상태를 추가하세요.

감사 기록에 무엇을 남길지 정의하세요. 추후 분쟁, 규정 준수, 디버깅을 위한 미래 대비로 다루세요:

• 누가 행동했는가 (사용자, 역할, 팀)
• 어떤 행동이 있었는가 (제출, 승인, 거부, 수정 요청, 오버라이드)
• 언제 일어났는가 (타임스탬프, 관련 기한)
• 무엇이 변경되었는가 (핵심 필드의 이전 vs 변경 값)
• 왜 일어났는가 (코멘트, 거부 사유, 첨부 설명)

알림은 사람의 기억이 아니라 상태를 따라가야 합니다. 요청이 Pending이 되면 다음 승인자와 요청자에게 알림을 보내고, 거부되면 이유와 함께 요청자에게 알리고, 승인되면 조달 같은 후속 팀에 알립니다.

권한은 워크플로우가 압박을 받을 때 깨지기 쉬운 부분입니다. 미리 결정하세요:

• 요청자(Requester): 초안 생성 및 편집; 항상 보기 가능
• 승인자(Approver): 할당되면 보기 및 결정; 코멘트 추가
• 관리자(Admin): 전체 보기; 데이터 문제 수정; 비상 시 재라우팅
• 재무/법무/보안(Finance/Legal/Security): 관련 시 보기; 필수 필드 추가
• 감사자(Auditor): 요청 및 이력에 대한 읽기 전용 접근

실용적인 규칙: 요청이 Pending이 되면 중요한 필드(금액, 공급업체, 범위)를 잠그세요. 변경이 필요하면 '수정 요청'으로 돌려 초안 상태로 변경해 이력이 깨끗하게 유지되도록 하세요.

단계별: 시각적 비즈니스 프로세스 편집기에서 구축하기

시각적 편집기를 사용하면 전체 워크플로우를 보기 전에 예외로 엉망이 되는 일을 막을 수 있습니다. 여러 번에 걸쳐 구축해 먼저 작동하는 경로를 만들고 그다음 규칙을 추가하세요.

다섯 단계로 흐름을 구축하세요

1. 골격을 맵핑하세요. 접수, 검증, 승인, 이행, 종료 단계를 만들고 명확한 종료 상태(승인, 거부, 반송)를 추가합니다.

2. 입력 데이터와 검증을 추가하세요. 필드(금액, 비용 센터, 공급업체, 필요 날짜)를 정의하고 초기에 빠른 검사를 추가해 잘못된 요청이 큐에 들어오지 않게 합니다.

3. 조건부 라우팅을 추가하세요. 누가 승인해야 하는지가 바뀌는 지점에서만 분기하세요. 일반적인 충돌(예: 요청자와 승인자가 같은 경우)을 명시적으로 처리하세요.

4. 타이머와 에스컬레이션을 추가하세요. 단계별 SLA를 설정하세요. 타이머가 만료되면 리마인더와 계단형 에스컬레이션을 실행하세요.

5. 실제 사례와 엣지 케이스로 테스트하세요. 소규모 시나리오 세트를 끝까지 실행해 태스크, 메시지, 상태, 감사 항목이 올바른지 확인하세요.

재사용할 소규모 테스트 세트

항상 워크플로우를 변경할 때 일관된 시나리오 세트를 사용하세요:

• 소액의 정상 경로
• 재무 검토가 필요한 고액 요청 및 지연 시 에스컬레이션
• 필수 필드 누락(접수 단계에서 차단)
• 충돌: 요청자와 승인자가 같은 경우(올바르게 재라우팅되는지)
• "수정 요청" 루프(올바른 단계로 돌아가고 이력을 유지하는지)

테스트 후 불명확한 단계를 이름을 바꾸고 임시 분기를 제거하세요. 지금 읽기 어렵다면 성장할수록 버티기 어렵습니다.

흔한 함정과 회피법

대부분의 승인 흐름 실패는 예측 가능한 이유에서 옵니다. 처음부터 명확성과 예외 처리를 설계하세요.

함정: 승인자를 계속 추가해 아무 것도 움직이지 않게 만드는 것. 승인자를 늘리면 안전하게 느껴지지만 대기 시간이 길어지고 혼란이 생깁니다. 단계당 책임 있는 승인자 한 명만 유지하고, 나머지는 정보 수신(FYI)으로 처리하세요.

함정: 소유자가 없는 에스컬레이션. SLA는 아무도 행동할 권한이 없으면 의미가 없습니다. 에스컬레이션 소유자(사람이 아닌 역할)를 지정하고 그들이 무엇을 할 수 있는지 정의하세요: 승인, 거부, 재라우팅, 수정 요청 등.

함정: 규칙이 받은편지함과 채팅에만 존재하는 경우. 라우팅 로직이 어딘가에 합의되어 있지만 프로세스에 반영되지 않으면 결정이 일관되지 않습니다. 조건을 워크플로우에 직접 넣고 각 규칙이 존재하는 이유를 짧게 적어두세요.

함정: 수정 요청 루프가 없는 경우. 검토자가 승인 또는 거부만 할 수 있다면 요청을 다시 시작해야 하고 맥락을 잃게 됩니다. 필요한 수정이 요청자에게 돌아가도록 '수정 필요(Needs changes)' 상태를 추가하세요.

함정: 예외로 인해 사람들이 프로세스 밖으로 나가는 경우. 긴급 항목과 누락 문서는 발생합니다. 통제된 예외 경로를 추가하고 누가 왜 예외를 사용했는지 로깅하세요.

재사용 가능한 요구사항 수집 체크리스트

승인 워크플로우를 만들기 전에 항상 동일한 입력을 모으세요. 이렇게 하면 흐름이 읽기 쉬운 상태로 유지되고 "특수 사례"가 나중에 긴급 수정으로 바뀌는 일을 막을 수 있습니다.

요청자, 승인자, 준수 및 리포팅 담당자를 포함해 30~45분짜리 짧은 워크숍을 진행하세요. 다음을 캡처합니다:

• 요청 유형과 필요한 데이터: 카테고리, 필수 필드, 필요한 증빙(견적서, 스크린샷, 문서)
• 승인자 역할 및 위임: 역할 기반 승인, 휴가 시 백업, 위임 규칙, 충돌 처리 방법
• 라우팅 규칙과 예외: 임계값, 조건, 빠른 경로, 통제된 예외 처리
• SLA, 일시정지 규칙, 에스컬레이션: 요청 유형별 목표, 시계 일시정지 시점, 각 단계별 에스컬레이션 의미
• 감사, 접근권한, 산출물: 무엇을 기록해야 하는지, 누가 무엇을 볼 수 있는지, 승인 후 무엇이 발생하는지(티켓, PO 요청, 권한 부여, 결제 단계)

예시 청사진: 조건부 라우팅이 포함된 구매 승인

이 예시는 볼륨과 팀 규모가 커져도 명확하게 유지됩니다.

시나리오와 라우팅 규칙

요청자는 금액, 비용 센터, 공급업체, 목적을 적어 구매를 제출합니다. 라우팅은 몇 가지 단순한 임계값과 공급업체 위험 규칙을 따릅니다:

• $1,000 미만: 부서장
• $1,000 ~ $10,000: 부서장 → 재무
• $10,000 초과: 부서장 → 재무 → 임원 승인(CFO/COO)
• 모든 금액: 공급업체가 플래그되어 있으면(신규 공급업체, 고객 데이터를 다루거나 고위험 목록에 있는 경우) 보안 검토 추가

공급업체 위험 규칙은 금액 규칙과 분리해두세요. 그러면 공급업체 기준을 조정해도 나머지 흐름을 건드릴 필요가 없습니다.

SLA, 에스컬레이션, 결과

요청자를 보호하는 하나의 SLA를 설정하세요: 첫 응답은 영업일 기준 1일 이내. "첫 응답"은 승인, 거부, 또는 수정 요청을 의미합니다.

24시간 내 조치가 없으면 승인자의 매니저에게 에스컬레이션하고 요청자에게 알립니다. 첫 에스컬레이션에서 즉시 재할당하지 마세요. 먼저 가시성을 올리고 필요하면 재할당하세요.

결과를 명확히 하세요:

• 승인: Approved 상태로 이동하고 후속 인계(PO 요청, 티켓, 결제 단계)를 트리거합니다.
• 거부: 사유를 요구하고 Rejected로 종결합니다.
• 수정 요청: 코멘트를 붙여 Needs updates로 보내고 변경 후 동일한 단계로 돌아가게 합니다.

프로세스가 작동하는지 확인하려면 단계별 승인 시간, 수정률(얼마나 자주 수정 요청이 발생하는지), 단계 및 부서별 에스컬레이션 빈도를 추적하세요.

다음 단계: 파일럿, 측정, 구현

의도적으로 작게 시작하세요. 한 팀과 한 요청 유형(소프트웨어 접근, 구매 요청, 휴가)으로 2~4주 파일럿을 실행하세요. 설계한 대로 흐름을 유지해 실제 작업에서 어디가 약한지 파악하세요.

규칙과 워크플로우 로직을 함께 보관하세요. 라우팅이 문서에 있고 로직은 다른 곳에 있으면 둘은 점점 달라집니다. 단계에 영향을 주는 규칙 옆에 평이한 언어의 설명을 넣어 "왜 여기로 갔지?"에 답하기 쉽게 하세요.

초기에 가벼운 모니터링을 추가하세요. 화려한 대시보드가 없어도 많은 것을 배울 수 있습니다. 각 단계별 평균 체류 시간, 상위 정체 이유(누락 정보, 잘못된 승인자, 불명확한 정책), 에스컬레이션 횟수, 재작업률을 추적하세요.

변화에 대비해 누가 새 규칙을 제안하고 누가 검토하며 업데이트를 어떻게 공지할지 계획하세요. 주간 또는 격주 검토면 충분한 경우가 많습니다. 각 변경에는 짧은 메모를 요구하세요: 해결하려는 문제, 영향을 받는 사람, 성공을 어떻게 측정할지.

코드 없이 이 청사진을 작동하는 앱으로 만들고 싶다면 AppMaster (appmaster.io)는 노코드 플랫폼으로 요청 데이터를 모델링하고 시각적 Business Process Editor에서 승인 로직을 구성하며 웹 및 네이티브 모바일 화면을 빠르게 배포해 모든 감사 기록을 한 곳에 보관할 수 있습니다.