예외 경로 설계: 승인을 하기 전에 거부를 계획하라

왜 해피 패스만으로는 충분하지 않은가

대부분의 팀은 깔끔한 버전의 워크플로부터 시작합니다. 요청이 들어오고, 누군가 검토하고, 승인됩니다. 효율적으로 느껴지지만 실제 작업이 일어나는 지점을 숨깁니다.

해피 패스는 보통 가장 짧은 경로입니다. 양식이 완전하고 첨부파일이 있으며 검토자는 할 일을 정확히 알고 있습니다. 실제 운영에서는 그 경우가 지연을 야기하는 경우가 드뭅니다.

지연은 무언가가 누락되었거나 불명확하거나 늦었거나 부분적으로만 허용될 때 시작됩니다. 관리자는 예산은 승인하지만 한 항목을 반려할 수 있습니다. 재무는 업로드되지 않은 세금 문서를 요구할 수 있습니다. 지원 담당자가 이유란이 너무 모호해서 요청을 되돌려 보낼 수도 있습니다. 그런 순간마다 추가 단계, 추가 메시지, 추가 대기 시간이 생깁니다.

그런 상황을 미리 계획하지 않으면 사람들이 즉흥적으로 결정을 내립니다. 한 검토자는 이메일을 보냅니다. 다른 사람은 도구에 코멘트를 남깁니다. 세 번째는 아무 설명 없이 요청을 반려합니다. 요청자는 무엇을 해야 할지 추측하게 됩니다: 문제를 고쳐야 하나, 다시 시작해야 하나, 아니면 누군가에게 도움을 요청해야 하나?

그 혼란에는 비용이 따릅니다. 요청을 제출한 사람, 검토자, 그리고 상황을 설명하러 끌려 들어온 모든 사람의 속도를 늦춥니다. 화이트보드에서 단순해 보였던 워크플로가 후속 채팅, 중복 제출, 수동 인수인계로 바뀝니다.

기본 승인 흐름은 쉽게 스케치할 수 있습니다:

• 요청 제출
• 요청 검토
• 요청 승인

하지만 실제 버전은 더 복잡합니다. 문서가 누락되면 어떻게 할까요? 요청의 일부만 승인되면요? 검토자가 반려했지만 사용자가 고칠 수 있다면요? 이런 경우는 드문 엣지 케이스가 아닙니다. 많은 팀에게는 정상적인 경우입니다.

그래서 화면을 그리고 상태 이름을 짓기 전에 예외 경로 설계에 주의를 기울여야 합니다. 예외 경로는 계획이 현실에 의해 중단될 때 무엇이 일어나는지를 정의합니다. 그리고 현실은 자주 그런 식으로 일어납니다.

내부 승인 앱을 만들든 노코드 플랫폼인 AppMaster 같은 도구를 쓰든, 반려되고 불완전한 경우는 승인된 경우만큼이나 신경 써야 합니다. 그들은 사람들이 보게 될 메시지, 다음에 취할 수 있는 행동, 워크플로가 사람들을 회복시키는지 아니면 막히게 하는지를 결정합니다.

해피 패스는 의도를 보여줍니다. 예외 경로는 프로세스가 실제 사용을 견딜 수 있는지를 보여줍니다.

예외 경로의 모습

예외 경로는 요청이 정상적으로 진행되지 못할 때 일어나는 일입니다. 드문 엣지 케이스가 아닙니다. 이는 거부된 요청, 양식이 불완전한 경우, 요청의 일부만 승인된 경우, 또는 작업이 단순히 멈춘 경우처럼 현실의 혼란을 처리하는 부분입니다.

명확한 예외 경로는 쉬운 언어를 사용합니다. 모호한 상태인 "실패(Failed)" 대신 구체적으로 적으세요: "예산 초과로 반려됨" 또는 "신분증 문서 대기 중". 사람들은 무엇이 잘못됐는지, 누가 조치를 해야 하는지, 다음에 무슨 일이 일어나는지를 알아야 합니다.

대부분의 워크플로는 몇 가지 예측 가능한 방식으로 깨집니다:

• 요청이 명확한 이유로 반려된다
• 필요한 문서나 필드가 누락된다
• 요청의 일부만 승인된다
• 요청에 담당자나 다음 단계가 정의되어 있지 않다

정보 누락은 가장 흔한 문제 중 하나입니다. 세금 문서와 은행 계좌 번호가 필요한 공급업체 온보딩 양식을 상상해 보세요. 둘 중 하나라도 누락되면 시스템이 단지 멈추면 안 됩니다. 요청을 불완전으로 표시하고, 정확히 무엇이 누락되었는지 보여주고, 적절한 사람에게 다시 보내야 합니다.

부분 승인은 그만큼 중요합니다. 비행, 호텔, 식비 예산이 포함된 출장 요청을 생각해 보세요. 관리자가 비행과 호텔은 승인하지만 식비는 삭감할 수 있습니다. 이제 프로세스에는 규칙이 필요합니다. 직원이 변경을 수락하나요, 요청을 업데이트하나요, 아니면 출장을 취소하나요?

정체도 중요합니다. 할당된 검토자가 퇴사했거나 팀이 백업 승인자를 설정하지 않았거나 다음 소유자가 없는 단계에 도달하면 요청이 손대지 않은 채로 멈출 수 있습니다. 기술적으로는 아무 것이 고장나지 않았지만 요청은 여전히 진행될 수 없습니다.

이러한 경로를 초기에 설계하지 않으면 사람들은 이메일, 채팅, 스프레드시트 메모로 처리합니다. 곧 누구도 어떤 버전이 최종인지 모르게 됩니다.

간단한 승인 예

영업 관리자 한 명이 이틀짜리 컨퍼런스 참석을 위한 출장 요청을 하는 상황을 보겠습니다. 문서상 흐름은 간단합니다: 직원이 여행 날짜, 예상 비용, 출장 이유를 입력합니다. 관리자가 승인하고 재무가 예산을 확인하면 출장 예약 단계로 넘어갑니다.

그 흐름은 깔끔하지만 불완전합니다.

같은 요청을 망가뜨려 보세요. 직원이 비행 견적과 컨퍼런스 티켓은 올렸지만 호텔 견적을 깜빡했다고 합시다. 시스템에 "제출됨(submitted)"과 "승인(approved)"만 있다면 사람들은 금세 막힙니다. 재무는 불완전한 요청을 볼 수 있고, 관리자는 준비된 것으로 생각할 수 있으며, 직원은 무엇이 누락되었는지 모를 수 있습니다.

더 나은 흐름은 그 요청에 자체 상태를 부여합니다. 예를 들어 "문서 대기(Waiting for document)" 또는 "수정 필요(Needs update)" 같은 상태 말입니다. 직원은 "이 요청을 재무로 넘기려면 호텔 견적을 추가하세요"라는 명확한 메시지를 볼 수 있어야 합니다. 관리자가 전체 여행을 반려해서 하나의 파일을 요청할 필요는 없어야 합니다.

이제 두 번째 문제를 추가해 보세요. 관리자는 출장은 허용하지만 전액은 아니라고 결정합니다. 비행과 호텔 1박은 승인하지만 추가 워크숍 비용과 두 번째 호텔 밤은 반려합니다.

많은 팀이 이 지점에서 부분 승인 프로세스가 없다는 것을 깨닫습니다.

워크플로가 요청의 일부만 승인할 수 없다면 사람들은 우회 방법을 사용하기 시작합니다. 전체 요청을 반려하고 직원에게 다시 제출하라고 하거나, 시스템이 하나의 예/아니오 결정만 저장하기 때문에 재무가 실수로 전액을 승인할 수도 있습니다.

명확한 모델은 각 비용 항목을 추적하거나 최소한 승인된 총액을 기록합니다. 요청은 다음과 같이 보일 수 있습니다:

• 항공: 승인됨
• 호텔: 1박 승인
• 워크숍 추가: 승인되지 않음
• 요청 총액: $1,450
• 승인 총액: $980

이 단일 예는 왜 승인 워크플로 오류가 종종 부주의한 사람들 때문이 아니라 규칙 누락 때문에 발생하는지를 보여줍니다. 화면을 설계하기 전에 그런 규칙을 정의하면 나머지 워크플로는 훨씬 더 신뢰할 수 있게 됩니다.

화면보다 예외를 먼저 설계하세요

워크플로를 개선하는 좋은 방법은 요청이 깔끔하게 통과되지 않을 것이라고 가정하는 것입니다. 그 한 가지 전환만으로도 설계 품질이 빠르게 바뀝니다.

먼저 엉망인 경우부터 시작하세요: 양식이 불완전하다, 정책이 불명확하다, 승인자가 부재하다, 또는 요청의 일부만 진행되어야 한다. 대부분의 팀은 이를 세 가지 주요 패턴으로 묶을 수 있습니다:

• 반려(rejection)
• 정보 누락(missing information)
• 부분 승인(partial approval)

그렇게 하면 작업이 관리 가능해집니다. 모든 엣지 케이스마다 새로운 답을 발명하기보다는, 소수의 패턴을 정의하고 각 요청 유형에 적용하세요.

작업 순서는 다음과 같습니다.

먼저 요청이 멈출 수 있는 모든 지점을 나열하세요. 누락 문서, 잘못된 값, 정책 위반, 기한 만료, 중복 제출, 수동 검토 등을 생각하세요. 요청이 대기하거나 실패하거나 발신자에게 돌아갈 수 있다면 적어두세요.

다음으로 각 경우에 무슨 일이 일어나는지 결정하세요. 모든 예외에 대해 네 가지 간단한 질문에 답하세요:

• 누가 통보받는가
• 요청에는 어떤 상태가 표시되는가
• 사용자가 다음에 무엇을 해야 하는가
• 요청은 언제 다시 움직이는가

예를 들어, 직원이 $600짜리 출장비 청구를 제출했는데 호텔 영수증이 누락되고 한 끼 식사가 정책을 초과했다고 합시다. 해피 패스만 설계하면 요청은 멈추거나 한꺼번에 반려될 뿐입니다. 예외를 먼저 설계하면 시스템은 누락된 영수증을 위해 청구를 일시 중지하고, 직원에게 명확한 메시지로 알리며, 허용된 항목은 조건부로 승인된 상태로 표시할 수 있습니다.

여기서 부분 승인 규칙이 중요해집니다. 승인된 금액이 지금 진행될 수 있는지, 나머지는 보류 상태로 남는지, 요청자가 논쟁된 부분만 편집할 수 있는지 아니면 전체를 다시 제출해야 하는지를 결정해야 합니다.

AppMaster로 프로세스를 구축하고 있다면, UI를 다듬기 전에 비즈니스 로직에서 그 분기를 매핑할 시점입니다. 반려, 수정 요청, 조건부 승인은 모호한 하나의 상태 뒤에 숨기지 말고 별도의 경로로 취급하는 것이 워크플로 신뢰도를 높입니다.

마지막으로 실제 시나리오 하나를 처음부터 끝까지 테스트하세요. 실제 숫자, 한 가지 실제 문서 누락, 한 가지 정책 예외를 사용하세요. 흐름을 읽는 사람이 1분 이내에 다음에 무엇이 일어나는지 말하지 못하면 설계는 아직 모호합니다.

인터페이스보다 규칙을 먼저 정하세요

화면은 구체적으로 느껴지기 때문에 팀은 종종 거기서 시작합니다. 버튼, 양식, 대시보드를 스케치하기 전에 규칙에 합의하지 않습니다. 그러면 인터페이스가 실제로 내리지 않은 결정을 숨기게 되어 나중에 문제가 생깁니다.

더 나은 순서는 단순합니다: 상태, 인수인계, 기한, 진행에 필요한 증빙을 먼저 정의한 다음 그에 맞춰 화면을 만드세요.

규칙 집합이 작고 명확할수록 예외 경로 설계는 훨씬 쉬워집니다. 요청이 승인되거나 반려되거나 수정 요청으로 돌아가거나 부분 승인될 수 있다면, 그 상태들은 하나의 의미만 가지는 명확한 이름이어야 합니다. "반송(returned)", "다시열림(reopened)", "수정 필요(needs changes)"처럼 거의 중복된 라벨은 실제로 동작이 다르지 않다면 피하세요.

구매 요청을 예로 들어보세요. 관리자가 열어보니 견적서가 없습니다. 팀이 다음에 무엇을 할지 결정하지 않았다면 사람들은 즉흥적으로 처리합니다. 어떤 관리자는 반려하고, 어떤 이는 보류로 둡니다. 또 다른 사람은 채팅으로 메시지를 보내고 시스템 상태는 바꾸지 않습니다. 곧 아무도 상태를 믿지 않게 됩니다.

먼저 규칙을 문서화하세요. 견적서가 없으면 요청은 "Needs documents" 상태로 이동합니다. 요청자는 다음 행동의 책임자입니다. 요청은 영업일 기준 5일간 그 상태에 머뭅니다. 아무 것도 도착하지 않으면 상태가 "Expired"로 바뀌고 새로 제출해야 합니다.

그 한 규칙이 목업보다 제품을 더 잘 형성합니다. 이제 사용자가 무엇을 봐야 하는지, 어떤 리마인더를 보내야 하는지, 어떤 이력을 남겨야 하는지 알 수 있습니다.

실용적인 규칙 집합은 네 가지 질문에 답해야 합니다:

• 매일 사용될 소수의 상태 이름은 무엇인가?
• 각 상태에서 누가 다음 행동을 하는가?
• 항목이 그 상태에 얼마나 머물 수 있는가(에스컬레이션, 만료, 종료 등)?
• 다음으로 이동하기 전에 어떤 필드, 파일, 검사가 필요한가?

부분 승인에도 동일한 수준의 주의가 필요합니다. 여행이 승인되었지만 호텔 비용이 승인되지 않았다면, 요청자가 같은 기록을 편집하나요 아니면 새로 만드나요? 재무는 변경된 부분만 다시 검토하나요 아니면 전체를 다시 보나요? 이를 일찍 결정하지 않으면 화면은 깔끔해 보여도 뒤의 프로세스는 여전히 엉망입니다.

팀이 먼저 규칙을 합의하면 인터페이스는 더 단순해집니다. 더 중요한 건, 사용자는 다음에 무엇을 해야 할지 정확히 압니다. 심지어 정답이 "아직 승인되지 않음"일지라도요.

사용자가 행동할 수 있는 메시지를 작성하세요

잘못된 예외 메시지는 모든 것을 늦춥니다. 사람들은 단지 무언가가 실패했다는 사실뿐만 아니라 무엇이 일어났고 무엇에 영향을 미치며 다음에 무엇을 해야 하는지도 알아야 합니다.

여기서 설계는 실사용자에게 실제가 됩니다. 내부 규칙이 명확하더라도 화면이 "오류(Error)"나 "검토 대기(Pending review)"만 표시하면 사람들은 추측하고 잘못된 파일을 다시 보내거나 지원팀에 문의하게 됩니다.

공급업체 승인 사례를 보세요. 사용자가 세금 문서, 은행 정보, 보험 증빙을 제출했다고 합시다. 은행 정보는 괜찮지만 세금 문서는 오래되었고 보험 증빙은 누락되었습니다. 시스템이 단지 "승인되지 않음(Request not approved)"만 표시한다면 사용자는 다음에 무엇을 해야 할지 알 수 없습니다.

더 나은 메시지는 이렇게 들립니다: "은행 정보는 승인되었습니다. 최종 승인을 위해서는 갱신된 세금 문서와 보험 증빙이 필요합니다." 이 문장 하나가 이미 무엇이 완료되었고 무엇이 남아 있는지를 분리해 주어 시간을 절약합니다.

좋은 메시지는 보통 네 가지 작은 질문에 답합니다:

• 어떤 부분이 반려되었거나 누락되었거나 아직 검토 중인가?
• 어떤 부분이 이미 수락되었나?
• 사용자가 무엇을 업로드하거나 변경하거나 확인해야 하나?
• 재제출 후 어떤 일이 일어나나?

마지막 부분은 중요합니다. 다음 단계가 명확할수록 사람들이 작업을 완료할 가능성이 높아집니다. "누락된 파일을 업로드하고 재제출하세요"는 "조치 필요(Action required)"보다 훨씬 낫습니다.

모호한 라벨은 불안을 만듭니다. "검토 대기(Pending review)"는 담당자를 기다리는 것인지, 데이터가 누락된 것인지, 내부 검사가 진행 중인 것인지 모두 뜻할 수 있습니다. 이유를 알고 있다면 그대로 표시하세요. "관리자 승인 대기(Waiting for manager approval)"와 "주소 증빙 대기(Waiting for proof of address)"는 같은 상황이 아니며 동일하게 보이면 안 됩니다.

프로세스가 부분 승인을 허용하면 상태 자체에서 그것을 분명히 보여주세요. 짧은 항목별 분해가 하나의 라벨보다 더 잘 작동합니다:

• 승인됨: 신분증 문서
• 수정 필요: 세금 양식
• 누락: 보험 증명서

이제 사용자는 필요한 것만 고치면 됩니다. 처음부터 다시 시작할 필요가 없습니다.

재제출 기능도 찾기 쉽게 해야 합니다. 메시지 근처에 다음 행동 버튼을 두고 다른 화면에 숨기지 마세요. AppMaster로 흐름을 구축한다면 사용자에게 보이는 상태 텍스트를 실제 비즈니스 프로세스 상태와 일치시키는 것이 앱이 워크플로가 무엇을 하는지 정확히 말하게 하는 데 도움이 됩니다.

좋은 메시지는 지원 티켓을 줄이고 승인 속도를 높이며 프로세스를 공정하게 느끼게 합니다. 사람들이 이유를 이해하면 반려를 받아들일 수 있습니다.

재작업을 만드는 실수들

대부분의 재작업은 한 가지 잘못된 가정에서 시작됩니다: 정상 경로만 설계하면 된다는 생각입니다. 팀은 요청 제출, 승인, 완료만 도식화하고 거기에서 멈춥니다. 그러다 실제 삶이 나타납니다: 파일이 누락되거나 관리자가 수정을 원하거나 요청의 일부만 진행될 수 있습니다.

그 차이가 곧바로 추가 작업을 만듭니다. 사람들은 수동으로 고치기 위한 방법을 만들고, 부수적인 메시지를 보내고, 상태 이름을 즉흥적으로 바꿉니다. 몇 주 후에는 모든 예외가 특별 사례처럼 느껴져서 아무도 워크플로를 신뢰하지 않게 됩니다.

한 가지 흔한 실수는 이상적인 경로를 제품으로 취급하고 나머지를 정리할 일이라고 보는 것입니다. 영수증, 부서 승인, 재무 검토가 필요한 비용 청구를 상상해 보세요. 영수증이 없으면 요청이 일시 중지되나요, 직원에게 돌아가나요, 아니면 반려되나요? 이 규칙이 처음부터 명확하지 않으면 팀은 나중에 이메일과 코멘트로 패치합니다.

혼란스러운 상태 이름은 또 다른 재작업을 만듭니다. "In review 2"나 "Pending action" 같은 라벨은 무해해 보이지만 사람들이 다음에 무슨 일이 일어나는지 추측하게 만듭니다. 명확한 이름은 문제, 소유자, 결과 또는 다음 단계 중 하나를 보여주기 때문에 실수를 줄입니다.

소유권도 워크플로가 깨지는 또 다른 지점입니다. 요청은 누구의 소유도 아닌 상태에 있어서는 안 됩니다. 케이스가 대기 중이면 누군가는 진행을 책임지고 추가 정보를 요청하거나 종료해야 합니다. 그렇지 않으면 지연이 쌓이고 사용자는 시스템이 요청을 잃어버렸다고 생각합니다.

부분 승인은 종종 잘못 처리됩니다. 팀들은 그것을 전체 거부처럼 취급하는 경향이 있습니다. 하지만 결과는 다릅니다. 여행 요청에서 항공과 호텔만 승인되고 식비는 거부되었다면, 그 경우는 자체 경로와 메시지, 후속 조치가 필요합니다.

부분 승인이 반려와 함께 묶이면 사람들은 전체 요청을 다시 제출하고 문서를 중복 업로드하며 이미 끝난 검토를 다시 시작합니다. 그건 순수한 재작업입니다.

간단한 테스트가 도움이 됩니다: 해피 패스가 아닌 각 상태를 읽고 "누가 이 상태를 소유하나, 사용자가 무엇을 보나, 다음에 무슨 일이 일어나나?"라고 물어보세요. 답이 모호하면 그 프로세스는 나중에 같은 지점에서 실패할 가능성이 큽니다.

구축 전에 빠르게 확인할 것들

화면을 만들거나 자동화하기 전에 엉망인 경우를 한 번 더 점검하세요. 좋은 예외 경로 설계는 보통 혼란이 재작업으로 변하기 전에 초기에 내린 몇 가지 명확한 결정입니다.

요청이 반려되거나 일시 중지되거나 부분 승인될 때 누군가는 항상 다음에 무슨 일이 일어나는지, 누가 할 일인지, 어떤 정보가 누락되었는지를 알아야 합니다.

프로세스의 각 예외에 대해 이 빠른 점검을 사용하세요:

• 모든 예외에는 소유자가 있다.
• 모든 상태는 하나의 명확한 다음 단계로 이어진다.
• 누락된 항목은 쉬운 언어로 명시된다.
• 부분 승인은 추측이 아닌 규칙을 가진다.
• 타이밍이 명확하다.

그다음 간단한 테스트를 실행하세요. 설계에 참여하지 않았던 사람에게 프로세스를 건네고, 반려된 요청과 문서 하나가 누락된 요청을 주어보세요. 그 사람이 1분 이내에 무엇을 해야 할지 말하지 못하면 프로세스는 아직도 너무 모호한 것입니다.

작은 예가 요점을 보여줍니다. 관리자가 소프트웨어 요청은 승인했지만 하드웨어 부분은 반려했다고 가정해 보세요. 상태가 단지 "부분 승인(Partially approved)"이라면 직원은 모든 것이 진행될 수 있다고 오해할 수 있습니다. 더 나은 상태는 무엇이 승인되었고 무엇이 거부되었으며 직원이 누락된 부분을 다시 제출할 수 있는지까지 정확히 말해줍니다.

이 규칙들을 작동하는 내부 앱으로 바꾸고 싶다면, 해피 패스보다 먼저 예외 상태를 매핑하세요. AppMaster에서는 상태, 비즈니스 규칙, 필수 필드를 정의한 다음 화면을 신경 쓰는 것이 현실적인 업무를 처리하는 노코드 앱을 만드는 실용적인 방법입니다.

다음 단계는 간단합니다: 상위 5가지 예외를 나열하고, 각 예외에 소유자를 지정하고, 사용자가 봐야 할 메시지를 작성하세요. 이 세 가지가 명확하면 구축 작업은 보통 훨씬 수월해집니다.