결정 테이블로 복잡한 비즈니스 규칙을 운영하는 방법
결정 테이블의 조건·행동 구조와 Hit Policy, 검증·버전 관리, 성능 최적화, Python 평가기 구현 예시를 정리한다.
2026-08-14 · 최초 발행 2025-12-22
조건 조합을 정책으로 분리하는 방식
결정 테이블(Decision Table)은 조건의 조합과 그에 따른 행동 또는 결과를 표로 적는 규칙 표현 방식이다. 각 행은 하나의 규칙이며, 열에는 조건이나 행동이 놓인다. 코드 곳곳에 흩어진 if-else 분기를 정책 단위로 모으기 때문에, 무엇이 어떤 결과를 만드는지 확인하기 쉬워진다.
충돌이 발생했을 때는 Hit Policy로 처리 방식을 정한다. 첫 매칭을 우선하는 First, 우선순위를 따르는 Priority, 하나의 규칙만 허용하는 Unique, 일치한 결과를 누적하는 Collect가 이에 해당한다. 누락·중복을 검증하고 Default 또는 Fallback 규칙을 두는 방식도 함께 권장된다.
조건 영역에는 입력 필드, 타입, =, >, in, between 같은 연산자와 와일드카드(-)를 정의한다. 파생 변수 계산 로직은 별도 계층으로 분리하는 편이 낫다. 행동 영역은 출력 값이나 실행 액션을 담되, 알림과 외부 호출처럼 부수 효과가 있는 작업은 분리한다. 규칙 ID, 우선순위, 유효기간, 버전, 소유자, 감사 정보는 메타데이터로 관리한다.
규칙이 코드보다 먼저 보이게 만든다
조건과 결과를 매트릭스로 표현하면 요구사항을 읽고 규칙을 검토하는 과정이 단순해진다. 규칙 ID를 로그와 결과에 연결하면 어떤 규칙이 어떤 판단을 내렸는지 1:1로 추적할 수 있고, 규칙 단위의 테스트 케이스와 커버리지 관리도 가능해진다.
중복, 충돌, 누락은 자동 검증 대상으로 둘 수 있다. 값의 범위와 도메인 제약을 함께 적용하면 입력 데이터 품질도 관리할 수 있다. Hit Policy와 Default Rule은 항상 결정 가능한 상태를 만들고, 예외 경로를 드러내는 장치다.
규칙을 외부화하면 코드 배포 없이 정책을 바꿀 수 있다. 스프레드시트나 DMN 표준을 적용하기도 쉽다. 대량 규칙 평가에서는 인덱싱과 캐시를 사용해 성능을 보완한다. 기본 평가 복잡도는 O(n)이지만, 해시·트라이·범위 트리 같은 전처리 인덱스를 적용하면 O(1)~O(log n)까지 낮출 수 있다.
운영 관점에서는 버전, 유효기간, 롤백 전략이 필요하다. 승인 워크플로와 4-eyes 원칙을 적용하고, 영향 분석(Impact Analysis)에 따라 점진적으로 릴리스할 수 있다. 평가 엔진에는 시간 제한과 안전 가드, 폴백 규칙을 둬야 한다.
모델링부터 변경 이력까지
먼저 적용 범위를 정하고 용어 사전을 만든다. 입력 스키마, 도메인, 단위를 확정한 뒤 조건 목록과 값 범위, 연산자를 정의한다. 파생 변수 계산은 테이블 밖의 규칙으로 분리한다.
테이블을 설계할 때는 First, Priority, Unique, Collect 가운데 Hit Policy를 선택하고 Default 또는 Fallback 규칙을 명시한다. 각 행에는 규칙 ID, 우선순위, 유효기간, 버전 메타데이터를 넣는다.
검증 단계에서는 중복·충돌·누락을 자동으로 확인한다. 경계값과 조건 조합을 기준으로 테스트 케이스를 만들고, 행 커버리지와 조건 조합 커버리지를 측정한다. 배포는 Canary, A/B처럼 단계적으로 진행하며 입력, 규칙 ID, 결과를 포함한 실시간 감사 로그를 남긴다. 규칙 히트 분포, 미스율, 폴백률, 평균 평가 시간은 운영 지표로 확인한다.
변경 이력과 승인 워크플로를 운영하고, 영향 분석과 롤백 절차를 준비해 둔다.
규제와 운영 자동화에서의 사용처
금융 대출 심사와 리스크 등급 결정에서는 신용점수, 소득, 부채비율, 연체 이력을 입력으로 받아 임계값과 범위에 따라 등급과 한도를 결정할 수 있다. 규제 변경을 빠르게 반영하고 감사에 대비하기 좋다.
보험 언더라이팅과 요율 산정에서는 연령, 차종, 사고 이력, 지역을 바탕으로 할증·할인 규칙을 적용한다. 복잡한 요율 정책을 표준화하고 테스트를 자동화하는 데 쓸 수 있다.
전자상거래 가격과 프로모션 엔진은 고객 등급, 카테고리, 장바구니 금액, 기간을 조건으로 삼아 쿠폰과 할인 우선순위를 정한다. 캠페인별 실험과 빠른 정책 전개에 적합하다.
규제 준수와 제재 스크리닝에서는 국가, 산업, 매출 임계치, 제재 리스트 매칭을 평가해 승인·보류·거절을 결정한다. 규정 변화에 대응하면서 감사 가능성을 강화할 수 있다.
IT 운영 자동화에도 적용할 수 있다. 심각도, 서비스, 시간대, 과거 히스토리를 조건으로 에스컬레이션이나 치유 스크립트 호출을 정하면 운영 판단의 일관성을 유지하고 MTTR 단축을 기대할 수 있다.
변경 속도와 평가 성능에서 얻는 효과
조직과 도메인에 따라 차이는 있지만, 코드 분기를 6080% 줄이고 규칙 외부화로 배포 소요를 5090% 단축하는 효과를 기대할 수 있다. 변경 리드타임은 3070% 단축되고 회귀 결함률은 2040% 감소할 수 있다. 인덱싱과 캐시를 적용한 경우 규칙 평가 p95 지연은 5~20ms로 유지하는 것을 목표로 삼을 수 있다.
정량 지표 외에도 정책의 투명성과 감사 가능성이 높아지고, 비즈니스와 개발 조직의 협업이 쉬워진다. 규칙이 표준화되면 온보딩과 지식 전수에 도움이 되며 리스크 통제도 강화된다.
외부화 전략과 운영 비용의 균형
정책 외부화는 BRMS·DMN 또는 경량 사내 엔진을 채택해 API 평가 서비스로 구성할 수 있다. 규칙 스냅샷은 버전 단위로 캐시하고, TTL과 버전 키를 사용해 무중단 갱신을 설계한다.
작성, 검토, 승인, 배포 권한은 분리한다. 규칙 변경에는 전자서명과 감사 로그를 적용하고, PII는 최소화·마스킹한다. 규칙 평가 요청과 응답은 암호화한다.
성능을 높이는 선택에는 비용이 따른다. 인덱스 사전계산은 지연을 줄이지만 메모리 사용을 늘린다. Priority 정렬은 빠른 First-Hit을 보장하지만 삽입과 정렬 비용을 높인다. Collect 정책은 풍부한 결과를 제공하는 대신 누적계산의 복잡성이 커진다.
| 접근 방식 | 성능 | 확장성 | 일관성 | 안정성 | 운영 편의 |
|---|---|---|---|---|---|
| 코드 if-else | 초기 빠름, 분기 증가 시 급격한 복잡도 상승 | 낮음, 변경 시 재배포 필요 | 개발자 개별 구현 편차 큼 | 테스트 누락 시 리스크 | 낮음, 비개발자 참여 어려움 |
| 결정 테이블 | 중간, 인덱싱 시 안정적 | 높음, 규칙 외부화 | 높음, 검증·커버리지 용이 | 폴백·정책으로 예측 가능 | 높음, 스프레드시트/DMN 편집 |
| 룰 엔진(BRMS) | 높음, 최적화·Rete 등 | 매우 높음, 모듈화 지원 | 높음, 표준 언어 | 엔진 복잡도 관리 필요 | 중간~높음, 플랫폼 종속성 |
| 결정 트리 | 중간, 경로 길이에 비례 | 중간, 구조 변경 부담 | 시각적 일관성 높음 | 분기 편향·누락 위험 | 중간, 시각화 강점 |
Python으로 확인하는 경량 평가기
전제조건은 Python 3.10+이며 외부 라이브러리는 필요하지 않다. 터미널에서 다음 파일을 실행할 수 있다.
# decision_table.py
from typing import Any, Callable, Dict, List, Optional
Rule = Dict[str, Any]
def match(rule: Rule, ctx: Dict[str, Any]) -> bool:
for cond, spec in rule["when"].items():
val = ctx.get(cond)
if isinstance(spec, tuple) and len(spec) == 2 and all(isinstance(x, (int, float)) for x in spec):
lo, hi = spec
if not (lo <= val <= hi):
return False
elif isinstance(spec, set):
if val not in spec:
return False
elif spec == "-": # wildcard
continue
else:
if val != spec:
return False
return True
def evaluate(rules: List[Rule], ctx: Dict[str, Any], hit_policy: str = "FIRST") -> Dict[str, Any]:
hits = [r for r in rules if match(r, ctx)]
if not hits:
return {"rule_id": "DEFAULT", "action": {"decision": "fallback"}}
if hit_policy == "FIRST":
r = sorted(hits, key=lambda x: x.get("priority", 0), reverse=True)[0]
return {"rule_id": r["id"], "action": r["then"]}
if hit_policy == "PRIORITY":
# highest priority; tie-breaker: latest version
r = sorted(hits, key=lambda x: (x.get("priority", 0), x.get("version", 0)), reverse=True)[0]
return {"rule_id": r["id"], "action": r["then"]}
if hit_policy == "UNIQUE":
if len(hits) != 1:
raise ValueError("UNIQUE policy violated: multiple or zero matches")
r = hits[0]
return {"rule_id": r["id"], "action": r["then"]}
if hit_policy == "COLLECT":
return {"rule_ids": [r["id"] for r in hits], "actions": [r["then"] for r in hits]}
raise ValueError(f"Unsupported hit policy: {hit_policy}")
if __name__ == "__main__":
rules = [
{"id": "R1", "priority": 10, "version": 1, "when": {"score": (750, 900), "income": (0, 1_000_000), "delinquent": False}, "then": {"grade": "A", "limit": 30000}},
{"id": "R2", "priority": 8, "version": 3, "when": {"score": (680, 749), "income": (0, 1_000_000), "delinquent": False}, "then": {"grade": "B", "limit": 20000}},
{"id": "R3", "priority": 9, "version": 2, "when": {"score": (0, 679), "delinquent": True}, "then": {"grade": "D", "limit": 0}},
{"id": "R4", "priority": 5, "version": 1, "when": {"score": "-", "income": (0, 1_000_000)}, "then": {"grade": "C", "limit": 10000}},
]
ctx = {"score": 720, "income": 600000, "delinquent": False}
print(evaluate(rules, ctx, hit_policy="FIRST"))실행 명령은 python decision_table.py다. 출력 예는 {'rule_id': 'R2', 'action': {'grade': 'B', 'limit': 20000}}이다.
평가 결과가 감사 로그로 이어지는 흐름
표준과 테스트 지표를 함께 관리한다
DMN 표준과 FEEL 표현식을 채택하면 도구 호환성을 확보할 수 있다. 최신 호환성은 벤더 문서 기준으로 검증해야 한다.
테스트는 조건 경계값, 극단값, 조합테스트(페어와이즈)를 기준으로 최소 세트를 구성하고 행 커버리지 100%를 목표로 한다. 운영에서는 규칙 히트 상위 N, 미스율, 폴백률, 평균·95p·99p 지연을 확인하며 배포 전후 변동을 분석한다.