판정 규칙은 누가 쥐나: 규칙 엔진·DMN·정책 코드와 LLM의 분업

왜 '누가 판정 규칙을 쥐나'가 문제인가

이 글은 '판정하는 AI: Decision RAG의 허와 실' 시리즈의 2편이다. 1편에서는 Decision RAG를 검색한 근거로 '승인·거절·배정' 같은 판정과 그 근거를 구조화해 내놓자는 제안으로 정리했고, '어디까지 LLM에 맡기나'라는 질문을 남겼다. 이번 편은 그 질문에 실무 방법론으로 답한다.

문제는 판정 로직이 어디에 사느냐다. LLM에 판정을 맡기면 보통 판정 기준을 프롬프트 문장에 적어 넣는다. DMN 유도 프롬프팅 연구논문는 이렇게 판정 로직이 프롬프트에 묻히면 업무 담당자가 이를 고치거나 다듬기 어렵고, 프롬프트 작성 자체도 시행착오에 기대게 되어 투명성·재사용·유지보수에 문제가 생긴다고 지적한다. 같은 입력에 다른 답이 나올 수 있는 확률적 생성의 성질도 판정에는 부담이다. 감사 담당자가 '왜 이 건은 승인됐나'를 물을 때 '모델이 그렇게 판단했다'로는 답이 되지 않는다.

그렇다고 규칙 엔진만으로는 부족하다. 규칙 엔진은 구조화된 값(금액, 날짜, 점수)이 들어와야 돌아가는데, 현장의 입력은 청구서·진단서·이메일처럼 비정형 문서인 경우가 많다. 그래서 판정을 두 일로 나눠 보는 시각이 쓸모 있다. 사실을 정리하는 서기와 규정집을 넘기는 심사관에 빗대 보자. 서기는 어지러운 서류에서 '청구 금액은 얼마, 가입한 지 몇 개월'을 뽑아 정리하고, 심사관은 그 사실을 규정집에 대 보고 결론을 낸다. 이 글의 질문은 결국 서기와 심사관 자리에 각각 누구를 앉히느냐다.

오래된 해법: 규칙 관리 시스템과 DMN 결정표

판정 로직을 프로그램 코드에서 떼어 따로 관리하자는 생각은 새롭지 않다. 업무 규칙 관리 시스템(BRMS)이 오래 해 온 일이다. 예를 들어 IBM Operational Decision Manager 제품 페이지글는 이 제품이 규칙 기반 업무 결정을 발견·포착·분석·자동화·통제(govern)하는 데 쓰인다고 설명한다. 또 결정이 어떻게 내려졌는지 문서로 남겨 감사와 컴플라이언스를 돕고, 규제가 바뀌면 정책을 빠르게 바꿀 수 있다고 밝힌다.

DMN(Decision Model and Notation)은 이런 판정 로직을 그리는 표준이다. OMG 공식 페이지글는 DMN을 업무 결정과 업무 규칙을 정밀하게 명세하는 모델링 언어·표기법으로 소개하고, 프로세스 표준인 BPMN과 함께 쓰도록 설계됐다고 설명한다. OMG 명세 페이지글에 따르면 DMN은 결정 사이의 의존 관계를 보여 주는 그래픽 표기와, 실행할 수 있을 만큼 자세한 표현 언어라는 두 도구로 이뤄진다. XML 표현이 있어 조직 사이에서 결정 모델을 주고받을 수도 있다. 이 페이지에는 1.0(2015년 9월)부터 1.6(2026년 9월)까지의 공식 버전과 1.7 베타가 올라 있다. Camunda DMN 튜토리얼글은 핵심 요소로 결정표(입력·조건·출력), 조건을 쓰는 식 언어 FEEL(Friendly Enough Expression Language), 결정이 표 하나로 안 끝날 때 쓰는 결정 요구 다이어그램(DRD)을 꼽는다.

직접 하나 만들어 보자. 아래는 보험금 소액 자동 지급을 판정하는 가상의 결정표다. 위에서부터 차례로 보고 처음 맞는 규칙을 적용한다고 가정한다.

| # | 서류 완비 | 청구 금액(원) | 가입 기간(개월) | 최근 1년 청구 횟수 | 처리 | |---|---|---|---|---|---| | 1 | false | - | - | - | "보완 요청" | | 2 | true | < 1000000 | >= 12 | <= 2 | "자동 지급" | | 3 | true | < 1000000 | < 12 | - | "담당자 심사" | | 4 | - | - | - | - | "담당자 심사" |

읽는 법은 단순하다. 한 줄이 규칙 하나이고, 한 줄 안의 조건은 모두 AND로 묶인다. '-'는 '어떤 값이든 상관없음'이다글. 2번 줄은 '서류가 갖춰졌고, 100만 원 미만이며, 가입 12개월 이상이고, 최근 1년 청구가 2회 이하면 자동 지급'으로 읽힌다. 조건을 다 피해 간 건은 마지막 줄이 받아 사람에게 넘긴다. `< 1000000`, `>= 12` 같은 조건이 FEEL 식이다. Camunda 튜토리얼글은 FEEL로 문자열 일치, 참·거짓, 수의 크기 비교와 범위, 날짜의 앞뒤 같은 조건을 쓸 수 있다고 설명한다. DMN 유도 프롬프팅 연구논문가 예로 든 가상 대출 표('연봉이 50,000을 넘고 신용점수가 700 이상이면 승인', 마지막 줄은 '-'로 나머지를 받음)도 같은 모양이다. 핵심은 업무 담당자가 읽는 이 표를 엔진이 그대로 실행한다는 점이다. Camunda는 이렇게 하면 분석가와 개발자 사이의 오해가 줄고 운영 중에도 빠르게 바꿀 수 있다고 설명한다글.

정책을 코드로: OPA와 판정 질의

DMN이 업무 담당자가 읽는 표에서 출발했다면, '정책을 코드로(policy as code)' 흐름은 개발·인프라 쪽에서 나왔다. OPA 공식 문서글는 OPA(Open Policy Agent)를 스택 전반의 정책 집행을 한데 모으는 오픈소스 범용 정책 엔진으로 소개한다. 정책은 Rego라는 선언형 언어로 쓴다. 선언형은 '어떤 순서로 계산하라'가 아니라 '어떤 조건이 참이어야 하는가'를 적는 방식이다. 문서는 마이크로서비스, 쿠버네티스, CI/CD 파이프라인, API 게이트웨이를 쓰임새로 들고, OPA가 CNCF 졸업 프로젝트라고 밝힌다.

설계의 핵심은 판정(decision-making)과 집행(enforcement)을 떼어 놓는 데 있다글. 서비스가 판정이 필요해지면 JSON 같은 구조화된 데이터를 입력으로 OPA에 질의하고, OPA는 그 입력을 정책·데이터와 맞춰 평가해 판정을 돌려준다. 집행은 다시 서비스의 몫이다. 판정 결과가 허용·거부 같은 예·아니오에 그치지 않고 임의의 구조화된 데이터일 수 있다는 점도 중요하다. 문서의 예시 정책은 '인터넷에서 닿는 서버는 보안이 약한 http 프로토콜을 열면 안 된다', 'telnet은 열면 안 된다'이다. Rego로 이 조건을 적어 두면, 서버를 만들 때 막을 수도 있고 컴플라이언스 팀이 주기적으로 위반 서버를 찾아낼 수도 있다.

LLM과 엮어 보면 OPA식 설계가 주는 교훈이 분명해진다. 판정 엔진은 '구조화된 입력이 들어오면 구조화된 판정을 낸다'는 계약만 지키면 되고, 그 입력을 누가 만들었는지는 상관하지 않는다. LLM이 비정형 문서에서 뽑은 사실을 정해진 JSON 모양으로 넘기면, 판정은 사람이 검토하고 버전을 붙여 관리하는 정책 코드가 맡을 수 있다. DMN과 비교하면 쓰는 사람이 갈린다. 업무 담당자가 직접 읽고 고쳐야 하는 판정은 DMN 결정표가 맞고, 접근 권한·배포 조건처럼 엔지니어가 관리하는 판정은 Rego 같은 정책 코드가 맞는다.

세 가지 분업 패턴 비교

LLM과 결정론적 규칙을 섞는 방식은 크게 셋으로 나눠 볼 수 있다. 첫째, LLM 단독 판정: 규칙을 프롬프트에 적고 판정까지 LLM이 낸다. 둘째, LLM 추출 + 규칙 엔진 판정: LLM은 비정형 문서에서 사실만 뽑아 정해진 스키마로 넘기고, 판정은 결정표나 정책 코드가 한다. 셋째, 규칙 엔진 판정 + LLM 보조: 입력이 이미 정형이어서 판정은 엔진이 내고, LLM은 고객에게 보낼 설명문을 쓰거나 규칙이 '담당자 심사'로 넘긴 예외 건을 검토하는 일만 돕는다.

기준별로 따져 보면 이렇다(아래 표의 평가는 이 글의 판단이다). 정확성: LLM 단독은 여러 단계의 규칙 적용에서 흔들릴 수 있다(다음 절의 연구 참고). 추출형은 판정 자체는 정확하지만 추출이 틀리면 그대로 틀린다. 규칙 판정형은 입력이 맞으면 판정도 맞는다. 일관성: 같은 입력에 같은 판정을 보장하는 것은 규칙 엔진이 들어간 두 패턴뿐이다. 감사 용이성: 규칙 엔진은 '몇 번 규칙에 걸렸다'를 남길 수 있지만, LLM 단독은 모델이 쓴 설명이 실제 판정 이유와 같다는 보장이 없다. 규칙 변경 비용: 프롬프트 한 줄 고치기는 쉬워 보여도 그 영향을 확인하기가 어렵다. 규칙 엔진 쪽은 고치는 절차는 무겁지만 바뀐 효과를 표 단위로 시험할 수 있다. 비정형 입력: 규칙 판정형은 입력이 정형이어야 쓸 수 있다.

그래서 적합한 업무가 갈린다. LLM 단독은 위험이 낮고 규칙이 아직 문장으로만 있으며 자주 바뀌는 초기 분류나 초안 작성에 맞다. 추출형은 입력은 비정형인데 기준은 명문화된 업무, 예를 들어 보험 청구 서류나 대출 신청 서류 심사에 맞다. 규칙 판정형은 금액·점수처럼 입력이 이미 데이터베이스에 있고 감사 요구가 엄격한 업무에 맞다. 실무에서는 한 업무 안에서 둘째와 셋째를 함께 쓰는 경우가 많다. LLM이 사실을 뽑고, 엔진이 판정하고, LLM이 그 판정을 설명하는 식이다. 이때 설명문은 엔진이 내놓은 판정과 근거 규칙 번호를 입력으로 받아 쓰게 해야 판정과 설명이 어긋나지 않는다.

연구는 어디로 가고 있나

아래 수치는 모두 각 논문이 정한 실험 조건(데이터셋, 모델, 과제)에서 나온 것이다. 다른 업무에서도 같은 효과가 난다는 뜻으로 읽으면 안 된다.

DMN 유도 프롬프팅논문은 판정 로직을 DMN으로 모델링하고, 이 모델로 프롬프트 구조를 잘게 나눠 LLM이 정해진 결정 경로를 따르게 한다. 대학원 수업에서 학생 과제에 대한 피드백을 만드는 데 적용했고, 강사가 생성된 피드백에 맞음·틀림 라벨을 붙여 평가했다. 이 사례 연구에서는 같은 내용을 CoT(Chain-of-Thought) 프롬프트로만 쓴 경우보다 결과가 좋았고, 기술수용모델(TAM) 기반 설문에서 학생들은 피드백이 유용하다고 답했다. 판정은 여전히 LLM이 하지만, 규칙의 원본을 업무 담당자가 고칠 수 있는 DMN에 두었다는 점에서 'LLM 단독'과 '규칙 엔진' 사이에 있는 방식이다.

기호 작업 기억 연구논문는 LLM이 규칙을 왜 놓치는지 들여다봤다. 예비 분석에서 LLM은 규칙 한 번 적용에는 강했지만, 단계가 늘수록 성능이 떨어졌고 규칙이 적용 순서와 다르게 주어지면 더 나빠졌다. 연구진은 지금 어떤 규칙을 어떤 사실에 적용할지 찾는 '규칙 그라운딩'을 원인으로 본다. 그래서 사실과 규칙을 자연어와 기호(Prolog) 두 형태로 외부 작업 기억에 담고, 그라운딩은 기호 매칭으로, 실제 규칙 적용은 LLM으로 나눴다. CLUTRR, ProofWriter, AR-LSAT, Boxes 네 데이터셋에서 GPT-4와 GPT-3.5로 CoT 계열과 기호 기반 기준선보다 나은 결과를 보고했다. 신경-기호 표현 연구논문는 방향이 조금 다르다. 모델의 Hidden Representation을 신경-기호 벡터로 바꿔 그 공간에서 문제를 푼 뒤 원래 상태에 합친다. 수학 추론 과제 묶음에서 CoT 프롬프팅과 LoRA 파인튜닝보다 교차 엔트로피 손실이 평균 88.6% 낮고 맞힌 문제가 15.4배 많았다고 보고했다. 다만 업무 규칙이 아니라 수치 계산 규칙을 다룬 연구라, 판정 시스템에 바로 옮기기보다 '정확한 규칙 따르기는 기호 쪽에 맡기면 낫다'는 같은 방향을 보여 주는 근거로 읽는 편이 맞다.

Policy-as-Skill논문은 실무에 가장 가깝다. 근거 검증, 검토 라우팅, 버전 관리, 감사를 '실행할 수 있고 버전이 붙은 정책 기능'으로 묶은 런타임이다. Gemma4 백엔드를 고정하고 600개 개발 과제에서 13가지 방법을 비교했다. PaS+Audit의 정확 일치는 53.8%, 검토 F1은 0.854, 인용 정밀도와 감사 완결성은 1.000이었고, 대부분의 거버넌스·검토 지표에서 LLM+RAG를 앞섰다. 결정론적 통제를 붙이면 전체 정확도가 61.2%로 올랐지만 효과는 과제마다 크게 달랐다. 연구진은 이를 근거로 규칙 기반 개입을 모든 판정에 씌우지 말고 골라서 붙이라고 결론 내린다. 정확 일치가 절반을 조금 넘는 수준이라는 점도 함께 기억해 둘 만하다.

상용 도구의 흐름과 온톨로지의 자리

상용 도구도 비슷한 분업으로 움직인다. 어느 제품이 낫다는 뜻이 아니라, 공식 문서에 적힌 설계를 보는 것이다. IBM ODM 제품 페이지글는 판정을 작성·시험하는 인터페이스, 시나리오와 핵심 성과 지표(KPI)에 비춘 시험·시뮬레이션, 역할 기반 권한 관리, 거버넌스·변경 관리 기능을 내세운다. DMN을 따르는 오픈소스 기반 제품(IBM Decision Manager Open Edition)도 함께 소개한다. watsonx Orchestrate의 대화 기능과 통합하면 사용자가 대화로 판정 엔진을 호출할 수 있다고도 설명하는데, 대화는 LLM이 받고 판정은 엔진이 하는 셋째 패턴과 닮았다.

팔란티어 AIP Logic 문서글는 LLM 기반 함수를 노코드로 만들고 시험·배포하는 환경이라고 설명한다. Logic 함수는 온톨로지 객체나 텍스트를 입력으로 받아 객체·문자열을 돌려주거나 온톨로지를 직접 편집할 수 있다. 쓰임새로는 비정형 입력의 핵심 정보를 온톨로지에 연결하는 일을 든다. 자동화를 걸면 온톨로지 편집을 바로 적용할 수도, 사람 검토 대기로 돌릴 수도 있다. 같은 문서는 행·열 접근 통제가 모델이 '읽는' 데이터만 거른다고 밝힌다. 모델의 출력이나 모델이 만든 온톨로지 편집에는 이 통제가 미치지 않으므로, 하류로 흐르는 데이터는 마킹이나 분류 기반 접근 통제를 함께 써서 보호하라고 권한다.

여기서 온톨로지 연재와 이어진다. 온톨로지의 행동 유형(action type)은 '어떤 객체를, 어떤 조건에서, 어떻게 바꿀 수 있는가'를 미리 정의해 둔 자리다. 판정을 실제 실행으로 옮기는 관문이 바로 여기다. 규칙 엔진이나 LLM이 '자동 지급'이라는 판정을 내도, 지급 상태를 바꾸는 일은 권한과 검증이 걸린 행동 유형을 거쳐야 한다. 판정과 실행을 떼어 놓는 이 구조는 OPA가 판정과 집행을 나눈 철학과 같다. 판정이 틀려도 실행 관문에서 한 번 더 막을 수 있고, 위험도에 따라 바로 적용할지 사람 검토로 돌릴지를 실행 쪽에서 정할 수 있다.

규칙이 바뀔 때: 버전 관리와 회귀 테스트

규칙은 반드시 바뀐다. 규제가 개정되고, 자동 지급 한도가 오르고, 예외 조항이 붙는다. 이때 따라 할 순서를 문장으로 정리하면 다음과 같다. 첫째, 판정 규칙을 프롬프트 문장에서 꺼내 결정표나 정책 파일로 옮긴다. DMN에는 XML 교환 형식이 있어글 결정 모델을 파일로 다룰 수 있고, Rego 정책도 코드 파일이다. 둘째, 규칙에 버전을 붙인다. Policy-as-Skill논문이 정책을 '버전이 붙은 실행 단위'로 묶은 것과 같은 발상이다. 셋째, 판정 결과마다 어떤 규칙 버전의 몇 번 규칙을 적용했는지 함께 남긴다. 그래야 나중에 '그때 그 판정'을 같은 조건으로 재현할 수 있다.

넷째, 회귀 테스트 세트를 만든다. 입력과 기대 판정을 짝지은 대표 사례 묶음이다. 앞의 보험 결정표라면 각 줄의 경계(정확히 12개월, 100만 원 바로 아래·위, 청구 3회째)를 하나씩 넣는다. 규칙을 바꾸면 '바뀌어야 할 사례가 의도대로 바뀌었나'와 '바뀌지 말아야 할 사례가 그대로인가'를 함께 본다. IBM ODM 페이지글가 시나리오 기반 시험·시뮬레이션을 내세우는 이유도 이 확인을 배포 전에 하기 위해서다.

다섯째가 LLM 시대에 새로 생긴 일이다. 규칙만 시험하면 안 되고, 추출 프롬프트와 설명 프롬프트도 같은 세트로 함께 시험해야 한다. 규칙 엔진은 그대로인데 추출 프롬프트를 고쳐 '가입 기간'을 다르게 뽑기 시작하면 판정이 소리 없이 바뀐다. 거꾸로 규칙을 고쳤는데 설명 프롬프트가 옛 기준으로 고객 안내문을 쓸 수도 있다. 그래서 테스트 세트에는 정형 입력만이 아니라 원본 문서도 넣어 '문서 → 추출 → 판정 → 설명' 전 과정을 한 번에 돌려야 한다. AIP Logic 문서글가 함수를 격리해 개발하는 Foundry Branching과, 실패한 테스트 사례를 원인별로 묶고 프롬프트 수정을 제안하는 AIP Evals 결과 분석기를 함께 소개하는 것도 같은 맥락이다.

흔한 실수, 더 공부하려면, 그리고 3편으로

흔한 실수는 다섯 가지 정도로 모인다. 판정 기준을 프롬프트에만 적어 두고 버전도 테스트도 없는 경우, 반대로 모든 판정을 규칙으로 덮으려다 규칙이 감당 못 하는 업무에서 오히려 결과가 나빠지는 경우(Policy-as-Skill논문이 결정론적 통제의 효과가 과제마다 다르다고 보고한 점을 떠올리자), 추출 단계의 오류를 판정 단계가 알아채지 못하는 경우가 있다. 넷째, LLM이 쓴 설명문이 엔진이 실제로 적용한 규칙과 어긋나는 경우다. 다섯째, 읽기 권한 통제만 믿고 모델이 만든 출력과 편집의 흐름을 따로 통제하지 않는 경우다글. 추출 결과는 스키마로 검증하고, 값이 비거나 애매하면 결정표의 마지막 줄처럼 사람 검토로 보내는 출구를 반드시 둔다.

더 공부하려면 순서를 이렇게 권한다. 먼저 Camunda DMN 튜토리얼글로 결정표·FEEL·hit policy를 손으로 익히고, OPA 공식 문서글의 서버 정책 예제를 따라 해 '판정과 집행의 분리'를 체감한다. 그다음 DMN 유도 프롬프팅논문으로 표준 판정 모델과 LLM을 잇는 가장 단순한 방법을 보고, 기호 작업 기억 연구논문로 LLM이 여러 단계의 규칙 적용에서 왜 흔들리는지 이해한다. 마지막으로 Policy-as-Skill논문에서 근거 검증·검토 라우팅·감사를 하나의 런타임으로 묶는 설계와, 그 한계 수치를 함께 읽는다.

규칙을 어디에 둘지 정했다면 남는 질문은 '그 판정을 믿을 수 있나'다. 추출이 얼마나 확실한지, 판정의 근거가 실제 문서와 맞는지, 나중에 감사 담당자가 판정 과정을 그대로 따라갈 수 있는지. 3편 '판정을 믿을 수 있나: 신뢰도·근거·감사'에서 이 세 가지를 다룬다.