의사결정 테이블 예시: 업무 규칙을 작성하고 테스트하는 방법

의사결정 테이블은 업무 규칙을 조건과 결과의 조합으로 정리한 표입니다. 조건은 열에, 규칙은 행에 놓고, 각 행의 조건이 맞을 때 어떤 결과를 반환할지 적습니다. 실제로 들어올 법한 입력을 넣었을 때 의도한 결과가 정확히 나오는지 보면 규칙을 검토하기 쉽습니다.

예를 들어 고객 지원팀은 운영 환경에 문제가 있는지, 정상 작업이 막혔는지, 우회 방법이 있는지에 따라 문의를 다르게 배정할 수 있습니다. 표를 사용하면 조건 조합을 나란히 비교할 수 있습니다. 순서도에는 이 배정 판단이 전체 업무의 어느 단계에 있는지 표시할 수 있습니다.

순서도보다 의사결정 테이블이 명확한 경우

여러 입력이 함께 결과를 결정하고 규칙을 비교해야 한다면 의사결정 테이블이 적합합니다. 무엇을 먼저 하고 다음에 무엇을 하며 예외가 생기면 어디로 돌아가는지 설명하려면 순서도가 적합합니다. 같은 업무를 서로 다른 수준으로 표현할 수도 있습니다. Boardmix에서 전체 업무 흐름을 그린 뒤, 해당 판단 옆에 배정 규칙을 놓는 방식입니다.

순서도에서 ‘운영 환경에 영향이 있는가?’를 물은 뒤 여러 갈래에서 ‘우회 방법이 있는가?’를 반복한다고 생각해 보세요. 서로 모순되는 목적지로 이어지는 갈래가 있어도 알아차리기 어렵습니다. 표에서는 반복되는 질문을 하나의 열로 만들 수 있어, 교차하는 화살표를 따라가지 않고도 인접한 행을 비교할 수 있습니다.

의사결정 테이블은 의사결정 매트릭스와 다릅니다. 매트릭스는 비용이나 사용성 같은 기준에 따라 대안을 채점합니다. 테이블은 운영 환경에서 정상 작업이 막혔는지 같은 조건을 평가하고 정해진 결과를 반환합니다. 이 예시에서는 확률이나 기대 금액도 계산하지 않습니다.

규칙을 쓰기 전에 입력부터 정의하기

다음은 설명을 위해 만든 가상의 지원 업무이며 Boardmix의 지원 정책이 아닙니다. 문의의 초기 배정 경로를 정하는 예시로, 응답 시간을 약속하거나 장애 원인을 진단하는 것이 목적은 아닙니다.

• 운영 환경 영향:실제 업무에 사용하는 환경에서 문제가 발생한 경우입니다. 테스트 환경에서만 발생했다면 ‘아니요’입니다.
• 정상 작업 중단:사용자가 평소의 경로로 의도한 작업을 끝낼 수 없는 경우입니다. 화면 표시만 잘못된 문제는 ‘아니요’입니다.
• 우회 방법:사용자가 같은 작업을 끝낼 수 있는 확인된 임시 경로입니다. 아직 시도하지 않은 수정 아이디어는 우회 방법이 아닙니다.

‘작업 중단’과 ‘우회 방법 있음’은 반대말이 아닙니다. 정상 경로는 막혀 있어도 수동 작업이나 다른 경로는 가능할 수 있습니다. 이 차이를 표 옆에 적어두지 않으면 같은 문의를 보고도 사람마다 다른 입력을 선택할 수 있습니다.

이 학습용 예시에서는 세 입력을 모두 알아야 표를 평가합니다. 운영 환경에 영향이 있는지 보고 내용만으로 알 수 없다면 먼저 정보를 수집합니다. 알 수 없는 값을 자동으로 ‘아니요’로 바꾸지 않습니다.

고객 지원 배정을 위한 의사결정 테이블 예시

아래 표의 한 행은 하나의 규칙입니다. ‘무관’은 해당 값이 그 규칙의 결과에 영향을 주지 않는다는 뜻이지, 정보가 없어도 된다는 뜻은 아닙니다. 필요한 입력이 모두 있을 때 정확히 한 행에만 일치하도록 설계했습니다.

R3를 문장으로 읽으면 ‘운영 환경에 영향이 있고 정상 작업이 막혔지만 우회 방법이 있으면 우선 지원으로 보낸다’입니다. 결과는 배정할 곳입니다. 문제가 해결되었다는 뜻은 아닙니다.

‘운영 환경의 일괄 내보내기 버튼은 작동하지 않지만 개별 레코드 다운로드는 된다’는 문의를 생각해 보겠습니다. 개별 다운로드로 원래 작업을 완료할 수 있다고 확인했다면 입력은 ‘예 / 예 / 예’입니다. 운영 환경에 영향이 있으므로 R1에는 맞지 않습니다. 정상 작업이 막혔으므로 R2에도 맞지 않습니다. R3에는 일치하며, 우회 방법이 있으므로 R4에는 맞지 않습니다.

이번에는 발생 환경만 테스트 워크스페이스로 바꿔보겠습니다. 나머지 두 값과 관계없이 R1에 일치합니다. 문제가 중요하지 않다는 뜻이 아니라, 예시에서 명시한 배정 정책을 적용한 결과입니다. 다른 정책을 사용하는 팀은 예외를 주석에 숨기지 말고 규칙을 바꿔야 합니다.

겹치는 규칙과 빠진 입력 조합 찾기

불리언 입력 세 개에는 가능한 조합이 여덟 개 있습니다. R1이 네 조합, R2가 두 조합, R3와 R4가 각각 한 조합을 처리합니다. 서로 겹치지 않으므로 이 작은 표로 불리언 입력의 전체 조합을 다룰 수 있습니다.

모든 조합을 다루는 것과 업무상 올바른 것은 다릅니다. 빠진 조합이 없어도 잘못된 정책을 구현한 표일 수 있습니다. 배정 정책의 책임자가 결과를 검토하도록 하고, 특히 조직에서 ‘우선’과 ‘인시던트’가 무엇을 뜻하는지 맞춰두세요.

흔한 오류 두 가지는 다음과 같이 확인할 수 있습니다.

• 중복:R2의 작업 중단 조건을 ‘아니요’에서 ‘무관’으로 바꾸면, 운영 환경의 정상 작업이 막혀 있고 우회 방법이 있는 문의가 R2와 R3에 모두 일치합니다. 문의 한 건에 경로가 두 개 생깁니다.
• 누락:R3를 삭제하면, 운영 환경의 정상 작업이 막혀 있고 우회 방법이 있는 문의가 어떤 행에도 맞지 않습니다. 가장 비슷한 행을 골라 처리하면 없는 규칙을 임의로 만든 셈입니다.

정식 의사결정 모델링 도구에서는 규칙 일치 시의 처리 방식을 히트 정책(hit policy)이라고 합니다. Camunda의 히트 정책 설명에 따르면 Unique는 여러 규칙에 동시에 일치하는 것을 허용하지 않고, First는 처음 일치한 규칙을 선택합니다. First 표에서는 행의 순서를 바꾸면 결과도 바뀔 수 있으므로 중요한 차이입니다. 순서 자체를 정책의 일부로 정한 것이 아니라면 화면상의 행 순서에 판단을 맡기지 마세요.

이 글의 표는 설계 문서이지 실행 가능한 DMN 모델은 아닙니다. 개발자가 규칙 엔진이나 애플리케이션에 구현한다면 입력 형식, 일치 시 처리 방식, 오류 처리도 그곳에 정의해야 합니다.

구체적인 사례로 표 테스트하기

규칙 옆에 예시를 두면 나중에 수정했을 때 어떤 결과가 달라지는지 볼 수 있습니다. 다음 사례로 모든 배정 경로와 정보 부족 시의 별도 경로를 확인할 수 있습니다.

숫자나 날짜가 있는 규칙에는 경계 직전, 경계값, 경계 직후의 사례를 추가합니다. ‘금액이 100보다 크다’는 규칙이라면 해당 통화와 정밀도에 맞춰 99.99, 100, 100.01을 테스트합니다. 도형을 그리기 전에 경계값을 포함하는지 정하세요. ‘큰 요청’ 같은 표현은 업무상 기준이 정해지기 전에는 일관되게 테스트할 수 없습니다.

허용 값 밖의 입력도 테스트합니다. ‘예’와 ‘아니요’만 받는 입력이라면 빈칸, 오타, ‘아마도’를 어떻게 처리할지 명시해야 합니다. 기본 경로는 잘못된 입력을 숨기기 위한 수단이 아니라 의도적으로 선택한 결과여야 합니다.

자신의 업무 규칙에 적용할 수 있는 작성 틀

다음 항목을 짧게 정리한 뒤 규칙 행을 추가하세요. 다른 프로젝트 문서에 복사해도 표의 맥락을 이해할 수 있게 해줍니다.

• 판단할 질문:이 표가 답하는 한 가지 질문은 무엇인가?
• 입력:각 조건의 이름, 정의, 허용 값.
• 출력:반환할 수 있는 정확한 배정 경로, 분류 또는 행동.
• 일치 시 처리:정확히 한 규칙에 일치해야 하는가, 첫 일치를 사용하는가, 다른 정책인가?
• 알 수 없는 입력:필요한 사실이 없을 때 평가 전에 무엇을 하는가?
• 예시:각 결과로 이어지는 일반 사례와 범위 조건의 경계 사례.

Boardmix 캔버스의 왼쪽에는 입력 정의, 가운데에는 규칙 표, 오른쪽에는 문의 예시를 배치할 수 있습니다. 표와 테스트 사례에 같은 규칙 ID를 사용하세요. 그러면 검토자가 ‘가운데 세 번째 것’ 대신 ‘R3’를 지목할 수 있습니다. 아직 정하지 않은 정책 질문은 승인된 행과 구분해 두세요.

배정 경로에 합의했다면 문의 접수, 필요한 정보 수집, 규칙 평가, 담당 경로로 전달하는 전체 흐름과 연결합니다. Boardmix를 열어 의사결정 테이블과 업무 흐름을 정리해 보세요.