UI 전에 승인 매트릭스 설계: 화면보다 규칙을 먼저 정하세요

화면은 매트릭스 없이 쉽게 실패한다

깔끔한 화면이 복잡한 프로세스를 가릴 수 있습니다. 승인 로직을 먼저 정의하지 않으면 사용자는 승인과 거절 버튼만 보고도 누가, 언제 행동해야 하며 다음에 무슨 일이 일어나는지 알지 못할 수 있습니다.

그 혼란은 실제 업무에서 금세 드러납니다. 누군가 요청을 제출하면 앱에 들어오고 첫 질문은 「이게 매니저에게 가나요, 재무에게 가나요, 혹은 둘 다 인가요?」가 됩니다. 화면은 완성된 것처럼 보이지만 의사결정 경로가 빠져 있습니다.

이유는 화면이 규칙을 실제보다 단순하게 보이게 만들기 때문입니다. 폼은 상태, 코멘트, 액션 버튼을 보여줄 수 있지만 프로세스 뒤의 실제 승인 매트릭스를 추측할 수는 없습니다. 금액 한도, 부서 규칙, 임시 대리자가 있는 경우 해당 케이스가 나타나면 UI가 곧 깨지기 시작합니다.

종종 예외 하나만으로도 업무가 앱 밖으로 밀려납니다. 보통은 부서장에게 가지만 긴급하거나 일정 금액 이상이거나 승인자가 휴가 중이면 다른 경로로 가는 경우가 있습니다. 그 경우를 매핑해두지 않으면 사람들은 이메일, 채팅, 스프레드시트로 돌아갑니다.

그다음 더 큰 문제가 생깁니다. 팀마다 각자 규칙을 적용하기 시작합니다. 운영팀은 한 방식으로, 재무는 다른 방식으로, 지원팀은 HR과 다르게 예외를 처리합니다. 앱은 일관되지 않은 결정을 위한 공동 화면이 되고, 공동 프로세스가 아닙니다.

경고 신호는 보통 쉽게 보입니다:

• 사용자가 다음 단계를 누가 담당하는지 묻는다
• 비슷한 요청이 팀마다 다른 결과를 받는다
• 예외가 채팅이나 이메일로 처리된다
• 정책 변경이 규칙 변경 대신 화면 변경을 요구한다

정책 업데이트는 이 약점을 빠르게 드러냅니다. 로직이 화면 내부에 있으면 한계치나 역할이 바뀔 때마다 UI 재작업으로 이어집니다. 이는 팀을 느리게 하고 오류를 만들며 사용자 신뢰를 잃게 합니다.

화면은 의사결정 경로를 반영해야지 그것을 정의해서는 안 됩니다. 매트릭스를 먼저 명확히 하면 UI는 더 단순하고 안정적이며 사용하기 쉬워집니다.

어떤 것을 와이어프레임 이전에 매핑해야 하는가

화면이 아니라 의사결정 로직부터 시작하세요. 견고한 승인 매트릭스는 누구에게 무엇을 승인할 권한이 있는지, 어떤 조건에서 그렇고, 누군가 부재 시엔 어떻게 되는지를 보여주는 단순한 표에서 시작합니다. 그 로직이 모호하면 다듬어진 인터페이스도 사람들을 혼란스럽게 할 것입니다.

요청 유형별로 승인 레벨을 순서대로 매핑하세요. 각 단계의 역할과 그 단계에서 할 수 있는 행동(승인, 거절, 검토, 되돌려보내기)을 적어두세요. 사람 이름보다 역할을 쓰는 편이 낫습니다. 사람은 이동하고 팀은 바뀌지만 프로세스는 유지되어야 합니다.

그다음 경로를 바꾸는 규칙을 정의하세요. 금액이 가장 흔한 트리거지만 유일한 것은 아닙니다. 승인 워크플로우 규칙은 지역, 부서, 공급업체 유형, 요청 카테고리, 위험 수준 등에 따라 달라집니다. 동일한 금액이 한 팀에서는 일상적이고 다른 팀에서는 민감할 수 있습니다.

부재 규칙도 필요합니다. 주요 승인자가 부재 중이면 누가 즉시 대신하나요? 백업이 임시라면 어떤 날짜가 적용되나요? 그게 없다면 요청은 이 주에 누가 담당하는지 몰라 멈춰 섭니다.

시간 제한도 중요합니다. 응답이 없을 때 무엇이 일어나는지 결정하세요. 하루 후 알림을 보낼지, 이틀 후 에스컬레이션할지, 삼일 후 운영에 통보할지 등은 상태 라벨, 알림, 대기열 뷰에 영향을 줍니다. 따라서 화면 설계 전에 정해야 합니다.

실용적인 매트릭스는 보통 다섯 가지 기본 질문에 답합니다:

• 이 규칙을 시작하는 조건은 무엇인가?
• 이 단계에서 누가 승인하는가(어떤 역할)?
• 백업은 누구인가?
• 승인자가 행동할 수 있는 시간은 얼마나 되는가?
• 기한을 놓치면 무슨 일이 일어나는가?

이 답들을 초기에 매핑하면 이후 작업이 훨씬 쉬워집니다.

매트릭스를 단계별로 만드는 방법

테이블, 화이트보드, 스프레드시트를 사용하세요. 관리자, 팀장, 프로세스 담당자가 한 번에 이해할 수 있을 만큼 단순하게 유지하세요.

먼저 승인해야 하는 모든 요청 유형을 나열하세요. 비즈니스가 이미 요청을 다르게 처리한다면 모든 것을 하나의 일반 흐름에 억지로 넣지 마세요. 구매 요청, 환불, 할인 승인, 접근 권한 요청은 종종 서로 다른 승인자, 한도, 기한이 필요합니다.

다음으로 첫 번째 승인자와 그 뒤의 각 의사결정 지점을 적으세요. 각 요청 유형에 대해 누가 먼저 검토하고 승인 또는 거절 후에 무슨 일이 일어나는지 적습니다. 승인, 거절, 수정 요청, 취소 등 최종 결과에 이를 때까지 경로를 따라가세요.

그다음 경로를 바꾸는 한계치를 추가하세요. 많은 팀이 이 지점에서 나중에 막힙니다. 예를 들어 $500 미만은 팀장이 처리하지만 $500 이상은 부서장이 처리한다면 지금 적으세요. 긴급 요청이 한 단계를 건너뛰거나 더 빠른 경로를 따른다면 그것도 기록하세요.

그다음 예외, 기한, 종료 상태를 기록하세요. 누락된 문서, 중복 요청, 정책 위반, 연체 승인 같은 케이스를 포함하세요. 일이 잘못될 때 어떻게 동작하는지 알기 전까지 규칙은 완성된 것이 아닙니다.

마지막으로 현재 요청을 승인하는 사람들과 초안을 검토하세요. 작업이 주로 어디서 멈추는지, 누가 단계를 건너뛰는지, 정상 승인자가 없을 때 무슨 일이 일어나는지 물어보세요. 실제 습관은 문서화되지 않은 규칙을 자주 드러냅니다.

작은 예시가 이를 분명히 합니다. 사무용품 구매 요청을 생각해보세요: $200 미만은 팀장에게, $200~$2,000는 부서장에게, 그 이상은 재무도 필요하다고 합시다. 폼이 금액과 카테고리를 초기에 캡처하지 않으면 UI는 요청을 올바른 경로로 보낼 수 없습니다.

사람들이 실제로 따를 수 있는 한도 설정

한도는 사람들이 빠르게 읽고 매번 같은 선택을 할 수 있을 때만 작동합니다. 규칙이 「작은 구매」나 「고위험 공급업체」처럼 모호하면 사람마다 다르게 해석합니다. 고정 숫자, 날짜, 명명된 조건을 사용하세요.

더 명확한 규칙 예: 「1,000달러까지는 팀장, 1,001~5,000달러는 부서장, 5,000달러 초과는 재무와 이사 검토」. 누구도 어디로 가야 할지 추측할 필요가 없습니다.

금액은 흔하지만 프로세스가 다른 요소에 의존한다면 유일한 트리거가 되어서는 안 됩니다. 신규 공급업체의 저가 소프트웨어 구매는 승인된 공급업체의 더 큰 주문보다 더 많은 검토가 필요할 수 있습니다.

대부분 팀은 소수의 라우팅 규칙만 필요합니다. 일반적인 예: 금액 범위, 공급업체 상태, 구매 카테고리, 부서, 긴급성. 중요한 것은 규칙 수가 아니라 모두가 같은 방식으로 적용하느냐입니다.

규칙의 순서도 중요합니다. 어떤 조건이 우선인지 모르면 같은 요청을 다르게 라우팅합니다. 한 가지 순서를 정하고 일관되게 지키세요. 예를 들어 공급업체 상태 → 카테고리 → 금액 순으로 확인하거나 금액 먼저 확인하고 예외를 나중에 처리할 수 있습니다. 어느 방식이든 모두가 같은 순서를 따르면 됩니다.

또 누가 한도를 무시할 수 있는지, 언제 그런 권한이 있는지도 정의하면 도움이 됩니다. 그렇지 않으면 직원은 너무 오래 기다리거나 이메일과 채팅으로 우회합니다. 「월말 마감 동안 재무 이사는 한도 초과 요청을 승인할 수 있다」는 식의 구체적인 규칙이 유용합니다. 「고위 경영진은 예외를 허용할 수 있다」처럼 모호한 표현은 피하세요.

간단한 테스트가 효과적입니다: 같은 예시 요청을 세 사람에게 주고 어디로 가야 하는지 물어보세요. 세 가지 다른 답이 나오면 한도는 아직 모호한 것입니다.

대체 승인자, 대리인, 에스컬레이션 계획하기

강한 매트릭스는 주요 승인자에서 멈추지 않습니다. 사람은 휴가나 병가로 비울 수 있고 응답하지 않을 수도 있습니다. 미리 대비하지 않으면 화면은 단정해 보여도 프로세스는 조용히 멈춥니다.

각 중요한 단계에 대해 대체 승인자를 지정하는 것부터 시작하세요. 이는 단순한 「다음 관리자」가 아니라 상황을 이해할 수 있는 역할이나 사람이어야 합니다. 예를 들어 특정 금액 이상은 재무 리드가 승인한다면 그 사람이 부재일 때 누가 대신할지 정하세요.

임시 대리인은 기간을 정해야 합니다. 대리인은 휴가 날짜나 계획된 휴가 기간처럼 정의된 기간 동안만 승인 권한을 가져야 합니다. 그래야 누군가가 장기간 불필요하게 승인 권한을 유지하는 일을 막을 수 있습니다.

단순한 설정은 네 가지를 답해야 합니다: 주요 승인자는 누구인지, 백업은 누구인지, 대리인이 얼마나 오래 행동할 수 있는지, 그리고 언제 요청이 상위 체인으로 이동하는지.

에스컬레이션은 추측이 아니라 명확한 트리거로 정하세요. 일반적 트리거는 시간, 금액, 위험, 누락 정보입니다. 예: 10,000달러 초과 구매 요청이 24시간 동안 방치되면 부서장에게 에스컬레이션합니다.

에스컬레이션 경로는 짧게 유지하세요. 다음 누가 받는지 이해하려면 복잡한 다이어그램이 필요하다면 규칙이 아마 너무 복잡한 것입니다. 한두 번의 명확한 점프면 충분한 경우가 많습니다.

각 결정을 기록하세요. 누가 승인했는지, 누가 대리했는지, 언제 인계가 일어났는지, 왜 에스컬레이션되었는지 저장하세요. 나중에 왜 지연되었는지 묻는 사람이 나오면 그 이력이 중요합니다.

또 한 가지 규칙은 루프를 피하는 것입니다. 요청이 이미 승인한 사람에게 다시 튀거나 그 사람을 대신해 행동한 대리인에게 다시 돌아가면 안 됩니다. 앱 로직을 만들기 전에 매트릭스에서 순환 경로가 없는지 확인하세요.

간단한 예: 구매 요청 승인

작은 회사가 일상 물품을 구매하는 상황을 그려보세요. 직원이 항목, 금액, 사유, 필요 날짜를 적어 하나의 구매 요청을 제출합니다. 라우팅은 누가 온라인인지가 아니라 규칙에 따라 진행됩니다.

요청이 $420이면 팀장으로 바로 갑니다. 소액 구매는 이렇게 빠르게 처리됩니다. $3,200 요청이면 예산 영향이 크므로 팀장을 건너뛰어 부서장에게 갑니다.

$7,800짜리 장비 요청을 보면 부서장이 여전히 검토하지만 그 수준만으로는 충분하지 않습니다. 금액이 $5,000를 넘으므로 재무 검토도 필요합니다. 높은 금액일수록 통제가 추가되지만 추측은 사라집니다.

부재도 중요합니다. 부서장이 휴가 중이면 요청이 멈추면 안 됩니다. 지정된 대리인이 자동으로 받아 정의된 기간 동안 행동할 수 있어야 합니다.

시간 제한도 명확해야 합니다. 아무도 이틀 내 반응하지 않으면 요청이 운영으로 에스컬레이션되도록 할 수 있습니다. 운영은 후속 조치, 재할당 또는 업무 차단 방지 중 하나를 수행할 수 있습니다.

이 예시에서 매트릭스는 몇 가지 중요한 질문에 답합니다: 요청 금액, 각 금액 구간에서 어떤 역할이 승인하는지, 언제 재무가 추가되는지, 누가 부재를 대신하는지, 기한을 놓치면 무엇이 일어나는지.

이 답들이 정해지면 화면 설계는 단순해집니다. 폼은 올바른 데이터만 받으면 되고, 요청 페이지는 현재 승인자, 대리자, 에스컬레이션 시계가 돌아가는지 여부만 보여주면 됩니다.

재작업을 유발하는 흔한 실수들

대부분 재작업은 단 하나의 화면도 그리기 전에 시작됩니다. 팀은 승인 경로를 추측한 다음 동의된 적 없는 규칙에 UI를 맞추려 합니다.

흔한 실수 중 하나는 조직도를 복사해 워크플로우라고 부르는 것입니다. 보기엔 깔끔해 보일지 몰라도 실제 요청은 보통 금액, 위험, 위치, 요청 유형에 따라 움직입니다. 매트릭스가 이를 무시하면 화면은 나중에 추가 필드, 상태, 어색한 예외로 가득 찹니다.

또 다른 문제는 특수 케이스를 잊는 것입니다. 긴급 요청, 규제 대상 구매, 교차 팀 요청은 종종 다른 경로가 필요합니다. 이런 예외를 초기에 매핑하지 않으면 사람들은 수동 해결을 요청하고 인터페이스에는 일회성 옵션이 쌓여 모두를 혼란스럽게 합니다.

두 사람에게 같은 권한을 주고 타이브레이크 규칙을 두지 않는 것도 문제를 만듭니다. 둘 다 승인할 수 있다면 누가 먼저 행동하나요? 둘이 다르면 어느 결정이 유효한가요? 답이 없으면 요청이 계속 왔다 갔다 하고 사용자는 신뢰를 잃습니다.

대리 규칙도 약한 부분입니다. 대리는 부재를 커버해야지 영구적 소유자가 되어선 안 됩니다. 임시 커버와 영구 소유가 섞이면 보고서가 엉망이 되고 책임 소재가 사라집니다.

라우팅이 확정되기 전에 폼을 설계하면 또 다른 재작업이 생깁니다. 폼은 완성된 것처럼 보여도 승인 규칙이 최종화되면 금액 밴드, 부서, 긴급성, 정책 플래그 같은 필드가 빠져 있음을 발견하게 됩니다. 그러면 레이아웃, 검증, 알림 전부 바꿔야 합니다.

빠른 현실 점검이 이를 초기에 잡아줍니다:

• 두 명의 승인자가 동시에 같은 요청을 받을 수 있는가?
• 임시 백업과 영구 소유 사이에 명확한 차이가 있는가?
• 긴급하거나 규제 대상인 경우 다른 경로를 따르는가?
• 각 라우팅 결정이 이미 존재하는 필드에 의존하는가?
• 한 승인자가 회사를 떠나도 프로세스가 여전히 말이 되는가?

어느 답이라도 불명확하면 거기서 멈추고 매트릭스를 고치세요.

화면을 디자인하기 전의 빠른 점검

폼이나 상태 배지를 스케치하기 전에 평범한 언어로 로직을 테스트하세요. 좋은 승인 매트릭스는 다이어그램을 열지 않고도 쉽게 설명할 수 있어야 합니다. 관리자, 재무 담당자, 운영팀원이 1분 정도 안에 경로를 설명하지 못하면 UI 작업을 하기엔 프로세스가 아직 모호합니다.

실제 사례를 사용해 빠른 검토를 진행하세요. 한 사람에게 요청에서 최종 결정까지 전체 경로를 설명하게 하세요. 모든 가능한 결과마다 다음 승인자가 이름으로 정해져 있는지(단지 긍정적 경로만 있는 것이 아닌지) 확인하세요. 모호한 한도는 「1,000달러 이하」, 「10% 초과 할인」처럼 정확한 규칙으로 다시 작성하세요. 백업과 에스컬레이션 규칙은 「24시간 후」, 「영업일 기준 2일 후」처럼 명확한 시간 한계를 사용하세요.

그다음 추적 가능성을 테스트하세요. 나중에 누군가 왜 요청이 지연되었고 누가 예외를 승인했으며 대리가 언제 개입했는지 물어볼 것입니다. 프로세스는 이미 그 질문에 답할 수 있어야 합니다. 타임스탬프, 결정 이력, 명확한 상태 변경은 부가 기능이 아니라 규칙의 일부입니다.

간단한 시나리오가 약점을 노출합니다. 예: 금요일 오후 도착한 $4,800짜리 구매 요청에 평소 승인자가 휴가 중이라면 누가 다음에 받나요? 시스템은 얼마나 기다리나요? 백업도 아무것도 하지 않으면 어떻게 되나요? 답이 문서화되어 있지 않다면 UI는 혼란을 숨길 뿐 해결하지 못합니다.

이 점검을 통과하면 화면 설계가 훨씬 쉬워집니다. 더 이상 무엇을 보여줄지 추측하는 것이 아니라 명확한 규칙에 맞는 형태를 주는 것입니다.

다음 단계: 매트릭스를 동작하는 앱으로 전환하기

규칙이 명확해지면 화면을 다듬기 전에 프로세스를 구축하세요. 로직, 데이터 필드, 승인 상태부터 시작하세요. 라우팅이 작동하면 인터페이스를 설계하는 것이 훨씬 쉬워집니다. 라우팅이 계속 바뀐다면 보기 좋은 화면만 문제가 가릴 뿐입니다.

실용적인 첫 버전은 보통 기본 항목을 포함합니다: 요청 유형, 금액, 부서, 현재 승인자, 최종 상태, 각 결정의 명확한 이력. 그런 다음 요청을 진행시키는 규칙, 대체 승인자에게 보내는 규칙, 누군가 제때 응답하지 않을 때 에스컬레이션을 트리거하는 규칙을 추가하세요.

첫 화면은 단순하게 유지하세요. 요청자는 제출, 상태 확인, 후속 질문에 응답할 수 있어야 합니다. 승인자는 검토, 승인, 거절, 재할당할 수 있어야 합니다. 그것만으로도 워크플로우가 일상에서 잘 작동하는지 테스트할 수 있습니다.

합리적인 빌드 순서는 다음과 같습니다:

• 핵심 데이터 필드와 상태 값을 정의한다
• 한계치, 대체 승인자, 대리인, 에스컬레이션에 대한 라우팅 규칙을 추가한다
• 요청자와 승인자를 위한 기본 화면을 만든다
• 모든 채널이 동일한 진실의 원천을 사용하도록 보장한다
• 더 넓게 배포하기 전에 하나의 실제 요청을 처음부터 끝까지 테스트한다

이 공유된 진실의 원천은 많은 팀이 예상보다 더 중요하게 여기는 부분입니다. 모바일이 한 상태를 보여주고 웹 패널이 다른 상태를 보여주며 백엔드가 다른 한도를 따른다면 신뢰는 빠르게 사라집니다.

AppMaster로 이 작업을 구성 중이라면 명확한 매트릭스가 설정을 훨씬 쉽게 만듭니다. 데이터를 모델링하고 비즈니스 로직과 승인 흐름을 먼저 만든 다음 동일한 프로세스를 백엔드, 웹, 모바일에 별도의 도구로 다시 작성하지 않고 적용할 수 있습니다.

첫 테스트에는 하나의 실제 케이스를 사용하세요. 한계치, 대체 승인자, 연체 에스컬레이션이 포함된 실제 구매 요청을 실행해 보세요. 사람들이 머뭇거리는 지점, 놓치는 데이터, 혼란스러운 상태 라벨을 관찰하세요.

그 후 문구와 레이아웃을 개선하세요. 실제 요청으로 프로세스가 작동하면 화면을 설계하기가 훨씬 쉬워지고 일주일 뒤에 다시 만들어야 할 가능성도 줄어듭니다.