임계값 기반 라우팅으로 유연한 승인 규칙 만들기

하드코딩된 승인 규칙이 왜 문제인지

하드코딩된 승인 규칙은 처음에는 괜찮아 보입니다. 개발자가 몇 가지 조건을 추가하면 워크플로가 돌아가고 팀은 다음 일로 넘어갑니다.

문제는 비즈니스가 변할 때 드러납니다. 재무가 지출 한도를 올리거나, 특정 지역에 다른 정책이 적용되거나, 어떤 부서에서 특정 요청에 대해 추가 승인자가 필요해지는 경우입니다. 그때는 작은 업데이트로 보였던 것이 앱 로직 수정, 테스트, 릴리즈를 필요로 하게 됩니다.

그 지연은 비용이 큽니다. 몇 분이면 끝날 정책 변경이 기술 작업에 묶여 며칠이 걸릴 수 있습니다. 그 사이 직원들은 옛 규칙을 따르고, 승인 처리는 지연되며, 관리자들이 이메일이나 채팅으로 예외를 처리하게 됩니다.

숨겨진 예외는 상황을 더 악화시킵니다. 시간이 지나면서 팀은 "금액이 5,000 초과이고 부서가 영업이면 Director A에게 보낸다" 또는 "요청이 유럽에서 왔으면 이 단계를 건너뛴다" 같은 일회성 규칙을 추가합니다. 그런 규칙들이 워크플로 깊숙이 숨겨지면 소수만 볼 수 있게 됩니다.

그다음 간단한 질문들이 답하기 어려워집니다:

• 특정 금액 초과 구매는 누가 승인하나?
• 마케팅은 운영과 같은 정책을 따르나?
• 다른 지역에서는 어떻게 되나?
• 지난 분기에 추가된 예외는 무엇인가?

전체 규칙 세트를 아무도 볼 수 없을 때 실수가 발생합니다. 누군가는 자신이 정책을 따르고 있다고 생각하지만 앱은 여전히 옛 규칙을 사용합니다. 새 관리자는 볼 필요 없는 요청을 받게 되고, 실제 승인자는 배제됩니다.

이것이 승인 정책이 자주 바뀔 때 임계값 기반 라우팅이 더 나은 이유입니다. 규칙을 앱의 고정된 부분으로 취급하는 대신, 검토하고 업데이트할 수 있는 비즈니스 데이터로 저장합니다.

간단한 비용 정책을 떠올려 보세요. 1,000 미만은 팀 리드에게, 1,000~10,000은 부서장에게, 그 이상은 재무로 갑니다. 다음 달에 한계가 바뀐다면 비즈니스는 승인 흐름을 유지하기 위해 개발자를 필요로 해서는 안 됩니다.

하드코딩은 평범한 정책 업데이트를 소프트웨어 프로젝트로 바꿉니다. 그게 진짜 비용입니다.

임계값 기반 라우팅이 의미하는 것

임계값 기반 라우팅은 미리 정의한 값에 따라 승인 경로가 바뀐다는 뜻입니다. 임계값은 단순히 경계입니다. 예: $1,000 초과 금액, Finance 부서에서 온 요청, 또는 유럽에서 발생한 구매 등입니다.

그 규칙들을 앱에 직접 쓰는 대신 테이블에 저장합니다. 워크플로는 테이블을 읽어 일치하는 규칙을 찾고 요청을 적절한 사람에게 보냅니다.

기본적인 설정은 다음과 같을 수 있습니다:

• $500 미만은 팀 리드에게 간다.
• $500~$5,000는 부서 관리자에게 간다.
• $5,000 초과는 이사에게 간다.
• HR 요청은 한 경로를 따르고 IT 요청은 다른 경로를 따른다.
• 북미와 EMEA는 다른 승인자를 가질 수 있다.

프로세스는 동일하지만 그것을 제어하는 값은 바뀔 수 있습니다.

로직과 정책 분리하기

이것이 핵심 아이디어입니다. 로직은 "규칙을 확인하고 첫 번째 일치 항목을 선택한다"는 부분입니다. 정책 데이터는 규칙의 목록 자체입니다: 금액 범위, 부서, 지역, 승인자, 우선순위 등입니다.

로직과 정책이 뒤섞이면 작은 변경에도 개발자가 워크플로를 편집해야 합니다. 분리하면 워크플로는 안정적으로 유지되고 변경되는 것은 규칙 행뿐입니다.

예를 들어 APAC의 영업은 이제 $5,000 대신 $3,000 이상이면 이사 승인이 필요하다면, 테이블의 한 행을 업데이트하면 됩니다. 전체 승인 프로세스를 재구축할 필요가 없습니다.

정책은 프로세스 구조보다 더 자주 바뀌기 때문에 이 방식이 관리하기 쉽습니다. 팀이 재편성되고 예산이 이동하며 지역에 새로운 담당자가 생깁니다. 테이블은 하드코딩된 조건보다 이를 더 잘 처리합니다.

AppMaster 같은 노코드 플랫폼에서는 보통 규칙 테이블을 만들고 비즈니스 프로세스가 런타임에 이를 확인하도록 합니다. 모델은 비기술 팀이 이해하기 쉬운데, 현실의 정책이 쓰이는 방식과 같습니다: 이 조건에 맞으면 여기로 보낸다.

규칙 테이블에 무엇을 넣어야 하나요

좋은 규칙 테이블은 한 가지 간단한 질문에 답해야 합니다: 이 조건에 맞는 요청은 누가 승인해야 하나?

라우팅이 코드 속의 값에 의존하면 모든 정책 업데이트가 재빌드를 의미합니다. 테이블은 그 변경을 가시화하고 관리하기 쉽게 만듭니다.

실용적인 규칙 테이블은 보통 요청을 설명하는 필드로 시작합니다:

• amount
• currency
• department
• region
• request type
• approver role

금액과 통화는 중요합니다. 같은 숫자라도 예산이나 국가에 따라 의미가 다를 수 있습니다. 5,000 USD는 한 경로를 따를 수 있고, 5,000 EUR나 500,000 JPY는 다른 경로를 필요로 할 수 있습니다.

부서와 지역은 기업이 실제로 작동하는 방식을 반영합니다. Finance, HR, Operations는 같은 지출이라도 종종 다른 승인 경로를 가집니다. 지역도 현지 규칙이나 관리자가 다르면 결과가 달라집니다.

요청 유형도 유용한 필터입니다. 출장, 소프트웨어 구매, 공급업체 대금, 할인 승인 등은 각기 다른 검토자가 필요할 수 있습니다. 이 필드가 없으면 관련 없는 요청들이 같은 규칙을 쓰게 됩니다.

승인자에는 사람 이름 대신 역할을 저장하세요. Department Manager, Regional Director, Finance Controller 같은 값을 사용하면 누군가가 직책을 옮겨도 역할 배정만 한 번 업데이트하면 됩니다.

시작일과 종료일을 추가하면 도움이 됩니다. 특정 일자에 시작되는 정책, 예산 시즌의 임시 규칙, 다음 분기를 위한 예정된 변경을 다룰 수 있습니다. 만료된 규칙이 활성 상태로 남지 않도록 이력을 관리할 수 있습니다.

우선순위 필드도 추가할 가치가 있습니다. "EU + Finance + 10,000 초과" 같은 규칙은 "모든 부서 + 10,000 초과"보다 우선해야 합니다. 명확한 우선순위가 라우팅을 예측 가능하게 합니다.

테이블 구조 설계

구조는 단순하게 유지하세요: 한 행은 한 승인 규칙과 같아야 합니다.

예를 들어 유럽에서 마케팅 비용이 $2,000 초과하면 지역 관리자가 필요하다면, 그 내용은 하나의 레코드에 있어야 합니다. 각 행이 명확한 의미를 가질 때 설정을 업데이트하고 테스트하고 감사하기가 쉬워집니다.

주 테이블은 트리거가 되는 조건과 워크플로가 다음에 무엇을 해야 하는지를 알려주는 결과 두 가지만 집중하세요. 이렇게 하면 비즈니스 사용자와 프로세스를 구성하는 사람 모두에게 읽기 쉬워집니다.

실용적 레이아웃

깔끔한 테이블에는 보통 다음 필드가 포함됩니다:

• 규칙 ID 또는 규칙 이름
• 활성 상태 및 선택적 시작/종료일
• 최소 금액, 최대 금액, 부서, 지역, 요청 유형 같은 조건 필드
• 승인자 역할, 승인자 사용자, 다음 단계 같은 결과 필드
• 우선순위 및 기본 규칙 플래그

조건 열에는 가능한 한 자유 텍스트 대신 정확한 필드를 사용하세요. 부서 ID는 매번 "Finance"를 직접 입력하는 것보다 안전합니다. 지역 코드, 요청 유형, 비용 센터도 마찬가지입니다. 부서, 지역, 승인자 역할에 대한 작은 조회(lookup) 테이블은 오탈자를 줄이고 필터링을 쉽게 합니다.

결과 열에서는 워크플로가 무엇을 반환해야 할지 결정하세요. 일부 팀은 규칙이 특정 개인을 가리키길 원하고, 다른 팀은 Regional Manager나 Finance Director 같은 역할을 가리키길 원합니다. 한 가지 접근을 골라 일관성 있게 유지하세요.

우선순위는 두 개 이상의 규칙이 동일한 요청에 매칭될 수 있기 때문에 중요합니다. 행 순서나 생성일에 의존하지 마세요. 숫자형 우선순위 필드를 추가하고 예: 1이 먼저 검사되고 100이 나중에 검사된다는 식으로 규칙을 정의하세요.

또한 폴백(fallback) 규칙이 필요합니다. 특정 행으로 커버되지 않는 모든 항목에 대한 안전망입니다. 기본 규칙은 일치하지 않는 요청을 운영 관리자나 관리자 검토 큐로 보낼 수 있습니다. 폴백이 없으면 요청이 라우팅되지 못하고 멈출 수 있습니다.

AppMaster에서 이 테이블을 시각적으로 편집할 수 있다면 정책 변경은 하드코딩된 워크플로 분기가 아닌 데이터 수준에서 이뤄집니다.

설정 방법

테이블이 아니라 의사결정부터 시작하세요. 워크플로가 대답해야 하는 정확한 질문들을 적어보세요. $5,000 초과 구매는 관리자가 승인해야 하나? Finance가 영업에서 오는 모든 것을 검토하나? 한 지역의 요청은 다른 경로를 따르나?

그 질문들이 분명해지면 임계값 기반 라우팅은 더 쉬워집니다. 정책을 저장하는 것이고 나중에 로직을 추측하려 들지 않기 때문입니다.

간단한 설정은 보통 다섯 단계로 진행합니다.

첫째, 라우팅에 영향을 주는 필드로 승인 규칙 테이블을 만드세요. 일반적인 열은 amount_min, amount_max, department, region, approver_role, priority, active_status입니다.

둘째, 어떤 필드를 비워둘 수 있는지 결정하세요. 부서나 지역을 비워두면 "이 규칙은 모두에 적용"이라는 뜻으로 해석할 수 있습니다.

셋째, 가장 구체적인 규칙부터 가장 일반적인 규칙 순서로 추가하세요. "Sales + Europe + 10,000 초과" 같은 규칙은 "모든 부서 + 10,000 초과"보다 먼저 검사되어야 합니다.

넷째, 출시 전에 실제 사례로 테스트하세요. 정확히 $5,000인 경우, 부서 데이터 누락, 특정 지역에 규칙이 없는 경우 등 엣지 케이스를 사용해 보세요.

다섯째, 테이블을 편집할 수 있는 사람을 제한하세요. 정책 변경은 쉬워야 하지만 모두에게 열려 있어서는 안 됩니다.

간단한 예를 들면 $12,000, HR, 북미 요청은 먼저 "HR 10,000 초과" 규칙에 매칭되어 HR 이사에게 보내질 수 있습니다. HR 전용 규칙이 없으면 시스템은 더 넓은 규칙인 "모든 부서 10,000 초과"로 폴백해 재무로 보낼 수 있습니다.

순서는 많은 팀이 생각하는 것보다 더 중요합니다. 넓은 규칙이 좁은 규칙보다 먼저 있으면 잘못된 사람에게 요청이 가고 시스템 신뢰도가 떨어집니다.

출시 전에 규칙 변경 담당자 한 명을 지정하고 짧은 정책 문서를 유지하며 각 업데이트 후 다시 테스트하세요. 작은 라우팅 변경이 큰 영향을 줄 수 있습니다.

실제 사례

한 회사가 모든 팀에 대해 하나의 구매 요청 양식을 사용한다고 가정해 보겠습니다. 각 요청에는 금액, 부서, 지역이 포함됩니다. 시스템은 그 값을 규칙 테이블과 대조해 적절한 승인자를 선택합니다.

회사가 마케팅과 IT 두 부서를 가지고 있고 둘 다 $4,000 요청을 제출할 수 있지만 승인 경로는 같을 필요가 없습니다.

같은 금액의 두 요청을 비교해 보세요. 미국에서 마케팅의 $4,000 요청은 Marketing Manager에게 갑니다. 미국에서 IT의 $4,000 요청은 IT Manager를 건너뛰고 CTO에게 갑니다. IT는 더 낮은 임계값을 가지고 있기 때문입니다.

지역도 결과를 바꿀 수 있습니다. 미국에서 $2,500인 마케팅 요청은 Marketing Manager에게 가지만, 같은 금액의 EU 요청은 Regional Marketing Lead로 갑니다. 양식은 동일하고, 매칭되는 규칙만 바뀝니다.

이것이 규칙 테이블의 진짜 가치입니다. 정책이 데이터에 저장되어 있고 워크플로 로직 안에 있지 않습니다.

다음 달에 회사가 정책을 업데이트하면 전체 프로세스를 재구축할 필요가 없습니다. IT가 $2,000 초과 요청을 CTO로 보내기로 결정하면 한 행만 수정하면 됩니다:

• 이전 규칙: IT, US, $3,001+, CTO
• 새 규칙: IT, US, $2,001+, CTO

나머지는 그대로 작동합니다. 새 요청은 즉시 새 정책을 따르고 앱 구조는 변경되지 않습니다.

피해야 할 흔한 실수

임계값 기반 라우팅에서 가장 어려운 부분은 보통 핵심 아이디어가 아닙니다. 정책이 바뀌고 누군가가 왜 요청이 잘못된 사람에게 갔는지 기억하지 못할 때 나타나는 복잡한 엣지 케이스들입니다.

흔한 실수 중 하나는 명확한 우선순위 없이 규칙이 겹치는 것입니다. 예를 들어 마케팅의 $3,000 초과는 부서장에게 보내고, $5,000 초과는 재무로 보내는 규칙이 있을 수 있습니다. $6,000짜리 마케팅 요청은 둘 다 매칭되므로 시스템은 명확한 우승자가 필요합니다. 우선순위는 숨겨진 워크플로 로직이 아니라 규칙 테이블에 넣으세요.

또 다른 실수는 사람을 하드코딩하는 것입니다. 이름은 바뀝니다. 팀은 바뀝니다. 누군가 휴가를 가거나 부서를 옮기면 "Maria Lopez에게 보내라"는 규칙을 매번 수정해야 합니다. Regional Finance Manager나 Sales Director 같은 역할로 라우팅한 뒤 그 역할을 현재 담당자에게 매핑하는 것이 더 안전합니다.

폴백 경로를 건너뛰면 조용한 실패가 발생합니다. 결국 어느 요청은 어떤 규칙에도 매칭되지 않을 것입니다. 그때 워크플로는 기본 큐나 관리자 팀으로 보내지는 등 안전한 동작을 해야 합니다.

지역 예외도 약점입니다. 한 국가에서 통하는 정책이 다른 국가에서는 현지 지출 한도, 세금 규칙, 보고 요구로 인해 통하지 않을 수 있습니다. 한 지역만 테스트하면 EU, US, APAC 요청이 다른 경로를 따라야 하는 경우를 놓칠 수 있습니다.

시간 기반 규칙도 잊혀지기 쉽습니다. 분기 말, 예산 동결, 특정 프로젝트를 위한 임시 규칙을 만들었다면 시작일과 종료일을 반드시 설정하세요. 만료된 규칙이 자동으로 비활성화되지 않으면 옛 예외가 남아 잘못된 경로로 요청을 보냅니다.

출시 전 최종 점검

임계값 기반 라우팅을 켜기 전에 실제 사용자의 관점에서 검토하세요. 모든 요청이 누군가가 왜 그렇게 되는지 추측할 필요 없이 올바른 승인자에게 이동해야 합니다.

최종 검토는 간단하게 유지하세요.

각 정상적인 요청에 대해 하나의 명확한 매칭이 있는지 확인하세요. 동시에 두 규칙이 적용될 수 있다면 결과가 일관되지 않습니다.

폴백 경로가 있는지 확인하세요. 누락된 부서, 신규 지역, 특이한 금액이라도 안전한 곳으로 가야 합니다.

정책 업데이트를 개발자가 없이 할 수 있는지 확인하세요. 재무나 운영팀이 한도, 날짜, 승인자를 바꿔야 할 때 테이블의 레코드를 편집할 수 있어야 합니다.

값뿐 아니라 날짜도 테스트하세요. 어제의 정책과 다음 달의 정책이 유효일이 설정돼 있을 때 모두 예상대로 작동해야 합니다.

라우팅 로직을 한 페이지에 평이한 언어로 작성하세요. 관리자가 명확히 설명할 수 없다면 아마 복잡한 것입니다.

유용한 최종 테스트는 정상 사례, 엣지 케이스, 만료된 정책 사례를 포함한 다섯 개의 샘플 요청을 만드는 것입니다. 팀이 실행하기 전에 결과를 예측할 수 있다면 설정이 준비된 것입니다. 예측할 수 없다면 더 단순하게 만드세요.

다음 단계

작게 시작하세요. 현재 가장 큰 지연이나 혼란을 일으키는 승인 흐름 하나를 선택하세요. 예: 일정 금액 이상의 구매 요청이나 부서별 비용 청구. 먼저 그것을 만들고 실제 사례로 테스트한 뒤 더 많은 규칙 유형을 추가하세요.

이 접근법은 라우팅 모델을 신뢰하기 쉽게 합니다. 사람들이 규칙이 어떻게 작동하는지, 어디에 예외가 있는지, 무엇을 바꿔야 하는지 볼 수 있기 때문에 설정이 커지기 전에 문제를 발견할 수 있습니다.

첫 롤아웃은 다음 네 가지 질문에 답해야 합니다:

• 어떤 요청 유형을 먼저 자동화할 것인가?
• 금액, 부서, 지역 같은 라우팅을 결정하는 필드는 무엇인가?
• 현재 각 경우를 누가 승인하나?
• 정책이 바뀔 때 누가 규칙을 업데이트할 것인가?

마지막 항목이 매우 중요합니다. 정책 업데이트에 명확한 소유자가 없으면 워크플로는 실제 업무 방식에서 서서히 벗어나게 됩니다. 규칙 변경을 검토하고 편집을 승인하며 변경 이유를 간단히 기록할 한 사람 또는 소규모 팀을 지정하세요.

검토 일정도 정해 두면 도움이 됩니다. 정책이 자주 바뀐다면 매월 검토하고, 과정이 안정적이면 분기별 검토로도 충분할 수 있습니다. 짧은 검토로 오래된 임계값, 누락된 부서, 지역 예외를 사전에 잡을 수 있습니다.

검토는 실제적이어야 합니다. 간단한 질문을 던지세요: 승인들이 올바른 사람에게 가고 있는가, 팀 구조가 바뀌었나, 현재 한도가 재무 정책과 일치하는가, 수동 오버라이드가 너무 많은가?

시각적으로 구축하고 싶다면 AppMaster는 규칙 테이블, 라우팅 프로세스, 비기술 직원이 정책을 업데이트할 수 있는 관리자 화면을 만드는 데 적합합니다. 노코드 애플리케이션을 완성하기 위한 도구로 설계되어 있어 비즈니스 팀이 개발자에게 모든 업데이트를 요청하지 않고 직접 정책을 관리할 수 있을 때 유용합니다.

한 흐름이 잘 작동하면 같은 패턴을 다음 프로세스에도 재사용하세요. 전체 재구축보다 작고 명확한 단계가 보통 더 효과적입니다.