워크플로의 위임 승인: 휴가 모드와 대체 승인자

사람들이 자리를 비우면 승인이 지연되는 이유

승인이 멈추는 이유는 단순합니다. 워크플로가 특정 개인 한 사람을 기다리고 있는데, 그 사람이 오프라인일 때 시스템이 어떻게 처리해야 할지 모르는 경우입니다. 요청이 해당 사람의 인박스로 도착하지만 다른 누구도 권한이 없어 모든 것이 중단됩니다.

이 문제는 승인이 이름에 묶여 있고 역할에 묶여 있지 않을 때 더 심해집니다. 팀은 바뀌고, 사람이 휴가를 가고, 매니저가 출장 가기도 합니다. 워크플로가 자동으로 대체자를 전환할 수 없다면 "긴급"한 알림, 수동 우회 방법, 지연된 결정이 반복됩니다.

사람들이 자주 혼동하는 몇 가지 유사한 개념을 분리해 두면 도움이 됩니다:

• 위임(Delegation): 원래 승인자가 책임을 유지하되, 대체자가 일정 기간이나 특정 경우에 대신 행동할 수 있습니다.
• 전달(Forwarding): 작업이 공유되거나 다른 사람에게 전송되지만 시스템은 여전히 원래 사람이 응답하기를 기대할 수 있습니다.
• 재할당(Reassignment): 승인 작업의 소유권이 다른 사람에게 이동합니다. 보통 영구적이거나 단일 요청에 대해 이루어집니다.

진짜 목표는 단순히 속도가 아닙니다. 예측 가능성과 깨끗한 기록입니다.

관리자와 감사인에게 "투명성(Transparent)"은 두 가지를 의미합니다: 왜 워크플로가 대체자로 라우팅되었는지 볼 수 있어야 하고, 누가 언제 어떤 규칙으로 승인했는지 증명할 수 있어야 합니다. 예를 들어 Alex가 휴가 중이고 Priya가 구매를 승인했다면, 기록에는 Priya가 Alex의 대리로 행동했다는 표시가 있어야 합니다. Alex가 승인한 것처럼 보이면 안 되고, 개인 대화 속으로 사라져서도 안 됩니다.

목표 결과는 간단합니다: 요청이 막히지 않고, 누가 무엇을 했는지(사람이 자리를 비웠을 때도) 검토 가능한 명확한 기록이 남는 것.

핵심 용어: 승인자, 대체자, 위임

명확한 용어는 이후 규칙을 깔끔하게 만듭니다. 사람들이 누가 무엇을 승인할 수 있는지 동의하지 않으면 워크플로는 멈추거나 감사 문제가 생깁니다.

대부분 승인 워크플로에는 몇 가지 공통 역할이 있습니다:

• 요청자(requester): 프로세스를 시작하는 사람(지출, 구매 요청, 접근 요청).
• 승인자(approver): 결정을 내리는 사람.
• 관리자(admin): 워크플로, 권한, 규칙을 설정하는 사람.
• 대체자(substitute): 다른 사람을 대신해 승인할 수 있도록 허용된 사람(때로는 delegate라고도 함).

**주요 승인자(primary approver)**는 단계별로 기본적으로 승인을 기대하는 사람입니다. **백업 승인자(backup approver)**는 주요 승인자가 없을 때 대체하는 사람입니다.

사람들은 종종 "백업 승인자"와 "두 번째 승인자(second approver)"를 혼동하지만 둘은 다릅니다. 두 번째 승인자는 추가 검토 레벨을 더하는 것이고, 백업은 동일한 레벨의 대체 경로입니다.

위임은 대체자가 행동할 수 있게 하는 규칙입니다. 일반적인 두 가지 스타일은:

• 항상 활성화되는 위임(always-on delegation): 대체자는 주요 승인자가 사용 가능한 경우에도 언제든지 승인할 수 있습니다.
• 부재 시에만 적용되는 위임(absence-only delegation): 주요 승인자가 부재로 표시되었거나 타임아웃이 발생했을 때만 대체자가 승인할 수 있습니다.

승인 **레벨(levels)**은 요청이 통과해야 하는 순서(예: 매니저 → 재무 → 법무 → IT)를 정의합니다. "레벨"은 무엇을 승인해야 하는지를, "대체자"는 평소 사람이 없을 때 누가 승인할 수 있는지를 정의합니다.

프로세스에 맞는 위임 모델 선택하기

모든 팀에 동일한 백업 방식이 필요한 것은 아닙니다. 올바른 모델은 사람들이 얼마나 자주 자리를 비우는지, 결정의 위험도, 승인 단계의 예측 가능성에 따라 달라집니다.

먼저 한 가지 기본 모델을 정하고 나머지는 예외로 처리하세요. 처음부터 모든 옵션을 섞어 쓰면 사용자가 혼란스러워하고 감사가 더 어려워집니다.

일반적인 위임 모델(언제 유용한가)

대부분 팀은 다음을 조합해 사용합니다:

• 휴가 모드(날짜 기반): 승인자가 시작일과 종료일을 설정하면 그 기간 동안 요청이 지정된 대체자에게 라우팅됩니다.
• 수동 일회성 위임: 긴급 상황에서 관리자나 매니저가 단일 요청에 대해 대체자를 지정합니다.
• 규칙 기반 위임: 팀, 요청 카테고리, 금액 같은 규칙으로 대체자를 선택합니다.
• 에스컬레이션: 아무도 정해진 시간 내에 응답하지 않으면 요청이 다음 사람(대개 승인자의 매니저나 온콜 큐)로 이동합니다.
• 직무 분리(Separation of duties): 민감한 승인에서는 요청자나 대체자가 스스로 승인할 수 없도록 다른 사람(또는 두 번째 승인자)을 요구합니다.

휴가 모드는 보통 일상에서 가장 간단합니다. 규칙 기반 위임은 대형 팀에서 수동으로 커버리지를 결정하는 일을 줄여줍니다. 에스컬레이션은 위임을 대체하는 것이 아니라 타임아웃에 대한 안전망입니다.

모델을 빠르게 결정하는 질문들

몇 가지 답변으로 옵션을 빠르게 좁힐 수 있습니다:

• 이 승인이 고위험(금액, 접근, 규정 준수)인가요, 아니면 저위험(일상적인 관리)인가요?
• 사람당 한 명의 대체자가 필요한가요, 아니면 "재무 온콜" 같은 풀(pool)이 필요한가요?
• 대체자를 요청자가 볼 수 있게 할 건가요, 아니면 관리자만 보게 할 건가요?
• 타임아웃 후 몇 시간까지 요청을 기다릴 수 있나요?
• 자기 승인(self-approval)을 막는 강제 규칙이 필요한가요?

휴가 모드와 대체자 설계 규칙

휴가 모드는 예측 가능할 때만 작동합니다. 목표는 단순합니다: 승인이 계속 진행되고, 누가 책임지는지 모두가 볼 수 있어야 합니다.

명확한 시간 창을 요구하세요. 모든 위임에는 시작일과 종료일(국제 조직인 경우 시간대 포함)이 있어야 합니다. "추후 통지까지" 같은 표현은 피하세요. 누군가 끄는 것을 잊으면 승인 권한이 몇 주 동안 잘못된 사람에게 라우팅될 수 있습니다.

대체자를 누가 선택할 수 있는지 결정하세요. 소규모 팀에서는 스스로 선택하는 위임이 작동할 수 있지만, 훈련되지 않은 사람을 선택하면 위험합니다. 매니저가 지정하는 방식이 대부분 조직도에 적합합니다. 관리자가 지정하는 방식은 엄격한 통제가 필요할 때 좋지만 설정이 느려질 수 있습니다.

시스템이 강제할 수 있는 자격 규칙을 설정하세요. 규칙은 단순하게 유지하고 사람 머릿속에만 있는 "특별 사례"를 허용하지 마세요. 일반적인 규칙은 동일한 부서나 비용 센터 소속, 적절한 승인 레벨 보유, 필수 교육 이수 등이 있습니다. 명백한 충돌은 항상 차단하세요: 대체자는 요청자가 될 수 없고 순환 승인도 방지해야 합니다.

진행 중인(in-flight) 승인에 대해 어떻게 처리할지 정의하세요. 많은 팀은 새 요청은 대체자로 라우팅하지만 이미 보류 중인 항목은 주요 승인자에게 남겨두되, 연체되면 자동 재할당하거나 에스컬레이션합니다.

상태를 가시적으로 표시하세요. 요청자는 현재 승인자, 위임이 활성화되었는지, 다음 단계가 무엇인지 볼 수 있어야 합니다. "승인 대기 중(대체자 Alex, 1월 30일까지)" 같은 상태는 후속 문의를 줄이고 신뢰를 높입니다.

단계별: 워크플로에 대체 승인자 구현하기

우선 한 가지 일반적인 요청(구매, 접근, 정책 예외)에 대해 정확한 승인 경로를 적어보세요. 범위를 작게 유지하세요. 설계를 위한 패턴을 만들기엔 2~4단계면 충분합니다.

실용적 구현 패턴

1. 각 단계에 역할과 기록상 단일 소유자(owner of record)를 매핑하세요. 대체자가 행동할 수 있더라도 단계별로 하나의 주요 승인자를 유지해 책임을 명확히 합니다.

2. 위임을 트리거하는 주요 수단 하나를 선택하세요. 대부분 팀은 부재 플래그, 날짜 창, 또는 매니저 제어 스위치를 사용합니다. 먼저 하나를 정해 사람들에게 무언의 재라우팅에 놀라지 않게 하세요.

3. 행동 승인자를 선택하는 라우팅 규칙을 추가하세요. 예측 가능한 순서가 나중에 설명하기 가장 쉽습니다: 사용자가 선택한 대체자 → 매니저 → 공유 백업 큐. 대체자가 즉시 승인할 수 있는지, 아니면 타임아웃 후에만 가능한지도 결정하세요.

4. 알림으로 기대치를 설정하세요. 요청자는 누가 현재 책임자인지 봐야 합니다. 주요 승인자는 위임이 활성화되었음을 통지받고 끄는 방법을 안내받아야 합니다. 대체자는 맥락과 함께 자신이 행동을 거부할 수 있는 명확한 방법을 받아야 합니다.

5. 엔드투엔드 테스트를 한 번 실행하고 기록을 점검하세요. 누가 할당되었고, 왜 위임이 발생했는지, 누가 언제 승인했는지 볼 수 있어야 합니다.

테스트 및 확인

현실적인 시나리오를 사용하세요: 주요 승인자가 "휴가" 상태일 때 대체자가 승인하는 흐름을 실행합니다. 그런 다음 대체자도 없는 상황을 반복해 폴백 규칙이 제대로 작동하는지 확인하세요. 마지막으로 감사 로그가 주요 승인자와 대체자, 위임 사유를 모두 보여 주는지 확인해 감사인이 누구에게 책임이 있었는지 묻지 않아도 이해할 수 있게 하세요.

명확한 승인 기록(감사 트레일)에 기록할 항목

감사 트레일은 추측 없이 세 가지 질문에 답해야 합니다: 무슨 일이 일어났는가, 누가 했는가, 그리고 왜 허용되었는가. 위임 승인의 경우 "책임 있는 승인자"와 "실제로 클릭한 사람"이 다를 수 있어서 더욱 중요합니다.

위임 규칙은 설정으로서가 아니라 일급 기록으로 로그에 남기세요. 누가 누구에게 위임했는지, 시작 및 종료 시간, 범위(어떤 요청, 금액, 팀 또는 문서 유형), 그리고 프로세스상 서명이 필요하면 누가 변경을 승인했는지를 캡처하세요.

승인 결정은 불변의 이벤트로 기록해야 합니다. "보류(pending)"를 덮어써서 "승인(approved)"으로 바꾸지 마세요. "승인", "거부", "수정 요청" 같은 이벤트를 기록하고 워크플로가 재시작되더라도 보존하세요.

실용적인 감사 트레일에는 보통 다음이 포함됩니다:

• 이벤트 ID, 워크플로 항목 ID, 단계 이름
• 타임스탬프(시간대 포함), 행동자 신원, 당시 역할
• 대리로 행동한 정보(원래 승인자, 위임 규칙 ID)
• 결과와 코멘트, 이유 코드, 첨부 파일
• 위임 규칙에 대한 편집 기록(누가 언제 무엇을 변경했는지)

코멘트와 첨부 파일은 결정 이벤트에 묶어 두세요. 별도의 채팅이나 일반 "메모" 필드에 있으면 어떤 코멘트가 어떤 결정을 뒷받침하는지 증명하기 어렵습니다.

마지막으로 기록을 읽기 쉽게 만드세요. 위임 변경, 발송된 알림, 내려진 결정, 에스컬레이션을 시간 순으로 보여 주는 단일 타임라인은 이후 분쟁을 예방합니다.

승인 과정 중 사용자에게 보여줘야 할 투명성

사람들은 무슨 일이 일어나고 있는지 볼 수 있을 때 지연을 받아들입니다. 보이지 않으면 잘못된 사람을 쫓아가고, 요청을 다시 보내거나 시스템이 고장났다고 가정합니다.

요청자와 검토자는 항상 현재 승인자와 그 사람이 선택된 이유를 볼 수 있어야 합니다. 작업이 주요 승인자에서 대체자로 이동했다면 명확히 표시하세요: "담당: Priya (Maya 대리)" 같은 한 줄이면 혼란을 막고 책임을 보호합니다.

또한 위임 기간과 누가 설정했는지도 보여 주세요. "위임 활성: 1월 10일~1월 20일, 설정: Alex" 같은 정보는 인수인계가 의도적이었음을 신뢰하게 합니다.

숨겨진 재할당은 감사 문제를 초래합니다. 누군가 흔적 없이 승인자를 바꿀 수 있다면 사용자는 신뢰를 잃고 관리자도 누가 결정을 내렸는지 알기 어렵습니다. 적절한 사람들에게 재할당을 보이게 하고, 항상 누가 트리거했는지 기록하세요.

간단한 "기록 보기(View history)" 패널이면 충분합니다. 핵심 내용만 보여 주세요: 현재 상태, 현재 승인자와 이유, 위임 기간, 수동 재할당 내역, 결정 코멘트.

개인정보 보호도 중요합니다. 각 역할이 무엇을 볼 수 있는지 정의하세요. 요청자는 이름과 상태가 필요할 수 있지만 HR, 재무, 법무 워크플로는 내부 메모를 마스킹해야 할 수 있습니다.

지연이나 감사 문제를 유발하는 흔한 실수들

위임은 보통 단순한 이유로 실패합니다: 규칙이 너무 느슨하거나, 기록이 모호하거나, 백업 계획이 없습니다. 결과는 예측 가능합니다: 요청이 공중에 떠 있고, 나중에 아무도 누가 무엇을 승인했는지 증명하지 못합니다.

흔한 함정은 해당 유형의 요청을 승인할 자격이 없는 사람에게 위임하는 것입니다. 예를 들어 구매 담당자가 지출 한도가 없는 팀원에게 구매 승인을 위임하면, 그 팀원이 승인을 클릭하고 재무가 이를 발견해 문제를 되돌려야 할 수 있습니다.

자주 발생하는 실수들:

• 자기 자신에게 위임하거나 자격이 없는 사람에게 위임(잘못된 역할, 한도 초과, 이해 충돌)
• 종료일 없는 위임
• 기록에서 원래 승인자를 덮어쓰기(책임 사슬 상실)
• 주요 승인자와 대체자 둘 다 없을 때의 에스컬레이션 경로 부재
• 알림이 너무 많아 사람들이 무음 처리하고 중요한 알림을 놓침

알림 과부하는 미묘한 문제입니다. 모든 단계가 이메일, 채팅, 푸시, 리마인더를 트리거하면 사용자는 결국 모두 무시하게 됩니다.

대부분 문제를 예방하는 설계 선택:

• 위임에 대해 시작일과 종료일을 요구하고 자동 만료 설정
• 활성화 전 대체자의 자격을 명확한 규칙으로 검증
• 항상 두 정체성 유지: "할당된 승인자(assigned approver)"와 "행동한 사람(acted by)", 원래 사람은 절대 지우지 않기
• 에스컬레이션 추가: X시간 내에 조치 없으면 매니저나 온콜 큐로 라우팅

롤아웃 전에 빠른 체크리스트

위임은 "지루한 세부사항"이 일관될 때 작동합니다. 휴가 모드를 전사적으로 활성화하기 전에 각 승인 단계마다 오늘 지정된 승인자가 없으면 다음에 무엇이 일어나는지 점검하세요.

• 모든 단계에 이름이 지정된 백업(또는 정의된 온콜 큐)이 있고, 그 백업은 적절한 권한을 가지고 있는가?
• 위임 규칙은 시간으로 한정되어 있고, 관리자가 활성화된 위임을 볼 수 있는가?
• 승인 기록에 책임자와 실제 행동자가 모두 표시되는가?
• 어떤 기록에 대해서도 "누가 언제 어떤 규칙으로 승인했는지"를 추측 없이 답할 수 있는가?
• 타임아웃에 대한 에스컬레이션이 있는가(예: 48시간 후 매니저나 큐로 재할당)

그런 다음 최소한 하나의 "사람이 휴가 중인" 시나리오를 엔드투엔드로 테스트하세요: 휴가 시작 전에 제출된 요청이 휴가 기간 중 승인되고, 사람이 돌아왔을 때 검토가 가능한지 확인합니다.

예: 휴가 중 현실적인 승인 인수인계

영업팀이 12개의 헤드셋(USD 1,200) 구매 요청을 제출합니다. 평소 이 요청은 Sales Manager인 Maya에게 갑니다. 그러나 Maya는 2주간 휴가 중이고 승인은 기다릴 수 없습니다.

떠나기 전에 Maya는 휴가 모드를 활성화하고 최대 USD 5,000까지의 구매 승인을 Sales Ops Lead인 Jordan을 대체자로 지정합니다. 그 이상은 여전히 재무로 갑니다.

깔끔하고 감사 친화적인 인수인계는 다음과 같이 진행됩니다:

• 월요일 9:10: 담당자가 벤더와 비용 센터를 포함한 "온보딩용 헤드셋"을 제출합니다.
• 월요일 9:10: 워크플로가 단계를 Maya에게 할당한 뒤, 휴가 모드가 활성화되어 즉시 Jordan으로 재라우팅합니다.
• 월요일 9:18: Jordan이 요청을 검토하고 승인합니다. 기록에는 "Jordan (Maya 대리로 행동)"으로 표시되며 Jordan의 메모("Q1 온보딩 승인. 예산 확인됨")가 포함됩니다.
• 월요일 9:18: 워크플로가 예산 확인을 위해 재무로 넘어가고 최종적으로 요청은 승인 처리됩니다.

두 가지 세부 사항이 신뢰를 높입니다. 요청자는 왜 승인자가 바뀌었는지 볼 수 있고(예: "대체자 라우팅: Maya 부재"), Maya는 복귀 후 자신에게 어떤 일이 일어났는지 추적할 수 있습니다.

Maya가 돌아오면 "부재 중 승인(Approvals during absence)" 뷰를 열어 Jordan이 그녀를 대신해 승인한 항목을 검토합니다. 기간, 금액, 요청자별로 필터링할 수 있습니다. Maya는 아무것도 재승인하지 않지만, 이상해 보이는 항목은 추후 조치 대상으로 표시할 수 있습니다.

나중에 감사인이 "누가 이 구매를 승인했고 왜 Maya가 승인하지 않았나?"라고 물으면 타임라인은 일관된 이야기를 알려 줍니다: 원래 승인자, 위임 사유(휴가 모드), 대체자 신원, 대리로서의 표기, 타임스탬프가 찍힌 결정, 그리고 메모.

다음 단계: 안전하게 롤아웃하고 유지 관리는 간단하게

위임은 체크박스 하나가 아닌 작은 제품 변경처럼 취급하세요. 목표는 변함없습니다: 사람이 자리를 비워도 승인이 계속 진행되고, 나중에 모든 결정을 설명할 수 있어야 합니다.

문제가 발생하는 하나의 워크플로(지출, 구매 승인, 접근 요청 중)를 선택해 시작하세요. 범위를 좁게 유지하세요: 한 팀, 한 승인 경로, 그리고 "누군가 부재로 인해 24시간 이상 승인 대기하지 않음" 같은 명확한 성공 기준 하나를 정하세요.

사람들이 실제로 따를 간단한 위임 정책을 작성하세요: 누가 위임할 수 있는지, 무엇을 위임할 수 있는지(예: 특정 금액 이하만), 위임이 어떻게 시작되고 끝나는지, 긴급 우회가 어떻게 보이고 기록되는지.

역할과 규칙의 소유자를 한 명 지정하고 정기적인 검토(월간 또는 분기별)를 설정해 오래된 대체자를 정리하세요. 장기적인 문제의 대부분은 꺼지지 않은 채 남아 있는 오래된 위임에서 옵니다.

무거운 코딩 없이 승인 앱을 만들고 싶다면 AppMaster (appmaster.io)는 사용자, 역할, 위임 창을 데이터베이스에 모델링하고 시각적 비즈니스 프로세스 편집기에서 라우팅과 타임아웃을 구현하며 감사에 적합한 일관된 승인 기록을 유지할 수 있습니다.

단계적으로 롤아웃하고 혼란을 경청하며 첫 워크플로가 몇 주 동안 원활히 운영된 후 다음 워크플로로 확장하세요.