Decision RAG란: 설명하는 AI에서 판정하는 AI로

왜 나왔나: 설명에서 멈추는 RAG

이 글은 기획 연재 '판정하는 AI: Decision RAG의 허와 실'의 1편이다. 기초편으로, 용어가 어디서 나왔고 무엇을 주장하는지부터 정리한다.

RAG(검색 증강 생성)는 질문과 관련된 문서를 먼저 찾고, 그 내용을 모델에 넣어 근거 있는 답을 만들게 하는 방식이다. RAG 설문 논문논문은 RAG가 환각, 낡은 지식, 추적하기 어려운 추론 과정 같은 LLM의 약점을 외부 데이터베이스의 지식으로 메우려고 나왔다고 정리한다. 그런데 기업 업무의 상당수는 '이 규정에 뭐라고 적혀 있나'에서 끝나지 않는다. 구매 요청을 승인할지, 티켓을 어느 팀에 배정할지, 사람에게 넘길지(에스컬레이션) 정해야 한다.

'Decision RAG'라는 이름은 Martin Connell의 LinkedIn 칼럼글에서 나왔다. 칼럼은 대부분의 RAG가 '알려 주도록(inform)' 설계됐을 뿐 '결정하도록' 설계되지 않았다고 말한다. 고도화된 구현도 결국 해석에서 멈추며 명시적인 결정, 일관된 규칙 적용, 구조화된 출력, 정해진 통제 범위 안의 동작, 반복 가능한 결과를 내지 못한다는 것이다. 다만 이 칼럼은 근거 논문이나 실제 사례 없이 쓴 의견 글이다. 이 연재는 Decision RAG를 '한 실무자의 제안'으로 다루고, 정착된 업계 용어로 쓰지 않는다.

같은 문제의식은 다른 곳에서도 보인다. 소프트웨어 개발사 Leanware의 글글은 RAG가 대체로 근거 있는 답을 내지만 지원 티켓 라우팅, 대출 승인, 규정 준수 예/아니오 판정에서는 막힌다고 짚는다. 같은 질문에도 실행할 때마다 다른 결과가 나올 수 있고, 업무 규칙을 지킨다는 보장이 없으며, 결정 기록(로그)이 구조화돼 있지 않고, 워크플로를 실행할 경로가 없다는 것이다. 이 글은 같은 구조를 '검색 증강 결정 엔진'이라고 부른다. 이름이 하나로 모이지 않았다는 점부터가 아직 개념이 자리 잡는 중이라는 신호다.

RAG 계보 속 판정형의 자리

판정형이 무엇을 새로 요구하는지는 앞선 RAG 갈래와 나란히 놓으면 잘 보인다. RAG 설문 논문논문은 RAG를 기본(Naive) RAG, 고도화(Advanced) RAG, 모듈형(Modular) RAG로 나누고 검색·생성·증강 세 축의 기술을 정리한다. 에이전틱 RAG 설문논문은 기존 RAG가 고정된 작업 흐름에 묶여 여러 단계의 추론을 못 한다고 보고, 반성·계획·도구 사용·멀티 에이전트 협업 같은 패턴으로 검색 전략을 동적으로 바꾸는 에이전틱 RAG를 정리한다.

네 갈래를 입력·출력·추론 방식·설명 책임으로 비교하면 이렇다. 기본 RAG는 질문 하나를 받아 관련 문서 조각을 찾고, 사람이 읽을 답을 쓴다. 추론은 모델 안에서 암묵적으로 이뤄지고, 출처를 보여 주면 좋지만 의무는 아니다. 고도화 RAG는 입력과 출력의 모양은 같고, 리랭커(재순위화 모델)나 하이브리드 검색으로 찾은 근거의 질을 높인다. 에이전틱 RAG는 목표 하나를 받아 검색과 도구 호출을 여러 번 되풀이하고, 그 과정이 길어지는 만큼 왜 그렇게 했는지 추적하기가 더 어려워진다. 에이전틱 RAG 설문논문도 평가·조율·거버넌스를 남은 과제로 꼽는다.

칼럼글이 말하는 판정형은 사건 하나(신청서·티켓·거래)와 그에 딸린 문서, 정형 기록, 정책을 함께 입력으로 받는다. 출력은 판정 결과와 근거를 담은 구조화된 레코드다. 추론은 '이 조건들에 비춰 평가하라'는 명시적 기준을 따르고, 설명은 선택이 아니라 필수다. 칼럼은 이 흐름을 '검색은 문서를, RAG는 답을, Decision RAG는 결과를 돌려준다'고 요약한다.

이 계보에서 주의할 점이 있다. 기본·고도화·모듈형·에이전틱 RAG는 설문 논문이 정리한 분류이고, 판정형은 칼럼 한 편이 덧붙인 자리다. 같은 무게의 분류로 보면 안 된다.

다섯 요소와 대응하는 연구·도구

칼럼글은 판정형을 다섯 요소로 설명한다. 이를 우리 말로 줄이고, 각 요소에 실제로 대응하는 연구와 도구를 붙이면 다음과 같다.

첫째, 여러 출처의 맥락을 결합한다. 문서 조각만이 아니라 정형 기록, 정책, 운영 데이터를 서로 맞춰 본다는 뜻이다. Leanware 글글은 이 단계를 검색 계층으로 설명한다. 비정형 지식은 벡터 DB에서, 정형 기록은 SQL 데이터베이스에서, 실시간 상태는 API에서, 정책은 문서 저장소에서 가져온다. Palantir의 AIP Logic 문서글도 LLM 기반 함수가 온톨로지 객체를 입력으로 받아 고객 이메일과 교차 확인하는 예를 든다.

둘째, 판정 기준을 명시한다. '이 정보가 무엇을 시사하나'가 아니라 '이 조건에 비춰 맞는 결과를 정하라'고 지시하는 것이다. RAD논문가 여기에 가장 가깝다. 이 연구는 기존 RAG에 정량적 가중치와 추적 가능한 추론 경로가 없다고 지적한다. 그래서 산업 문서에서 핵심 기준을 자동으로 뽑아 가중치가 붙은 계층형 결정 모델을 만들고, 그 모델에 따라 구조화된 보고서를 쓴다. 원래 다기준 의사결정 기법인 계층 분석법(AHP)은 전문가가 손으로 기준을 짜야 해서 규모를 키우기 어려웠는데, 그 일을 LLM과 여러 에이전트가 맡게 했다.

셋째, 결과를 구조화된 출력으로 내놓는다. OpenAI(w3)와 Anthropic글 모두 API 문서에서 구조화된 출력 기능을 제공한다. Claude 문서글는 이 기능이 제약된 디코딩(constrained decoding)으로 응답이 지정한 JSON 스키마를 따르도록 보장한다고 설명한다. 응답 형식을 정하는 JSON 출력과, 도구 입력을 스키마로 검증하는 엄격한 도구 사용(strict tool use) 두 가지가 있다.

넷째와 다섯째는 내장된 규칙·통제와 필수 설명이다. Policy-as-Skill논문이 둘을 함께 다룬다. 이 연구는 정책을 프롬프트 속 글로만 두지 않고, 버전이 붙은 실행 단위(스킬)로 묶는다. 스킬 하나에 정의하는 항목은 이름, 버전, 검색 범위, 필요한 근거, 판정 스키마, 사람 검토로 넘기는 조건, 감사 기록 항목, 근거가 없을 때의 동작, 프롬프트 템플릿, 맥락 계약이다. 연구진은 고정된 Gemma4 모델로 600개 개발 과제에서 13가지 방법을 비교했다. 감사 기능까지 붙인 구성(PaS+Audit)은 정확 일치 정확도 53.8%, 검토 라우팅 F1 0.854, 인용 정밀도 1.000, 감사 완전성 1.000을 기록했고, 거버넌스·검토 지표 대부분에서 LLM+RAG보다 나았다.

어떻게 작동하나: 판정 결과 예시

판정형 시스템의 흐름은 Leanware 글글이 계층으로 정리한 구조를 따르면 이해하기 쉽다. 검색 계층이 여러 출처에서 맥락을 모은다. 추론 계층의 LLM은 최종 결정을 내리지 않고 분류 라벨, 신뢰도 점수, 추출한 항목, 위험 평가 같은 신호를 만든다. 결정 로직 계층은 이 신호에 임계값, 정책 제약, 규제 규칙, 에스컬레이션 조건을 적용한다. 이 계층은 같은 입력이면 같은 출력을 내는 결정론적 계층이다. 마지막으로 실행 계층이 기록을 고치거나 워크플로를 띄우고, 모든 단계가 감사 기록으로 남는다.

아래는 사내 구매 요청 한 건을 판정한 결과를 이 글에서 직접 만들어 본 예시다. 실제 시스템의 출력이 아니다.

{"case_id": "PR-2026-1107", "decision": "사람 검토로 넘김", "policy": {"name": "구매 승인 정책", "version": "v3"}, "criteria": [{"rule": "예산 잔액 확인", "result": "충족"}, {"rule": "승인 한도 이내", "result": "초과"}, {"rule": "등록 공급사 여부", "result": "충족"}], "evidence": [{"source": "구매 승인 정책 v3, 4.2항", "quote": "한도를 넘는 건은 부서장 승인을 받는다"}, {"source": "ERP 예산 기록"}], "next_step": "부서장 승인 대기열로 배정", "needs_human_review": true}

필드마다 맡은 일이 있다. decision은 하위 시스템이 분기할 값이다. policy의 버전은 나중에 '그때 어느 규정으로 판단했나'를 되짚기 위해 남긴다. Policy-as-Skill논문이 감사 기록에 정책·모델 버전과 근거 ID를 남기게 한 것도 같은 이유다. criteria는 기준마다 충족 여부를 따로 적어서 '왜'를 한 줄씩 보여 준다. evidence는 참조한 원문 위치를 가리키고, next_step과 needs_human_review는 실행 계층과 사람 검토 흐름으로 이어지는 연결점이다.

이 예시에서 판정이 '승인'이나 '거절'이 아니라 '사람 검토로 넘김'인 데는 이유가 있다. 칼럼글도 판정형이 사람을 빼는 것이 아니라 위험이 낮은 건은 자동으로 처리하고, 중간 건은 돕고, 위험하거나 애매한 건은 사람에게 넘기는 것이라고 말한다. Policy-as-Skill논문 역시 근거가 모자라면 '알 수 없음'이나 '검토'로 처리하도록 실패 동작을 미리 정해 둔다.

'허'의 첫 신호: 새 이름, 오래된 일

판정형의 구조를 뜯어 보면 새로운 것은 생각보다 적다. 업무 규칙을 코드 밖에 따로 두고 같은 입력에 같은 결과를 내게 하는 일은 규칙 엔진, 업무 규칙 관리 시스템(BRMS), 의사결정 표(DMN, Decision Model and Notation 같은 의사결정 모델링 표준)가 오래 해 온 일이다. Leanware 글글도 결정 로직 계층을 규칙 엔진, 점수 모델, 단순 조건문으로 구현한다고 적는다. 그렇다면 판정형에서 새로운 것은 '판정'이 아니라, 흩어진 문서에서 판정 기준과 근거를 뽑아 규칙에 넣는 앞단을 LLM이 맡는다는 점에 가깝다. RAD논문가 하는 일도 바로 그 앞단, 즉 기준 추출과 가중치 부여다.

두 번째 신호는 구조화된 출력의 비용이다. Claude 문서글가 말하는 보장은 응답이 스키마를 지킨다는 형식의 보장이지, 판정이 맞는다는 보장이 아니다. 형식 제약 연구논문는 JSON·XML 같은 형식을 강제했을 때 LLM의 추론 능력이 크게 떨어지고, 형식 제약이 엄격할수록 추론 과제의 성능 하락이 대체로 커진다고 보고했다. 판정 JSON을 반드시 받아야 하는 시스템일수록 '먼저 자유롭게 추론하고, 그다음 형식에 담는' 순서를 따로 고민해야 하는 이유다.

세 번째 신호는 규칙의 효과가 고르지 않다는 점이다. Policy-as-Skill논문에서 결정론적 통제를 켜면 전체 정확도가 61.2%로 올랐지만, 연구진은 그 효과가 과제 유형에 크게 좌우된다고 밝혔다. 그래서 규칙 개입은 모든 곳에 걸지 말고 골라서 걸어야 한다고 결론 낸다. 같은 연구는 메타데이터를 많이 내보내기만 해도 종합 점수가 좋아 보일 수 있다고 경고한다. '설명이 붙어 있다'와 '판정이 맞다'는 다른 문제다.

혼동 주의도 하나 있다. 이 사이트의 '의사결정 모델(Decision model)' 글은 선택지마다 확률을 매겨 바로 고르는 모델 종류를 다룬다. 이 글의 판정형 RAG는 검색·규칙·구조화 출력을 묶은 시스템 설계를 가리키므로 둘은 다른 개념이다.

요즘 어디로 가고 있나

최근 연구에서는 '판정 로직을 LLM 바깥으로 꺼낸다'는 방향이 구체적인 성과로 나타나고 있다. 영상의학 지침 기반 결정 그래프 연구 GDGraph논문는 지침을 정리하는 단계와 개별 사례를 평가하는 단계를 떼어 놓는다. 먼저 LLM이 산문·표·상호 참조로 흩어진 임상 지침을 실행 가능한 결정 그래프로 바꿔 둔다. 사례를 평가할 때는 빠른 모델이 국소적인 질문에만 답하고, 참·거짓 논리는 결정론적 그래프 탐색이 처리한다. 신장 낭종, 부속기 종괴, 갑상선 결절 지침에 걸친 347개 사례에서 정확도가 57.3%에서 90.8%로 올랐고, 검색 증강 GPT-4o(80.1%)와 CoT를 쓴 그래프 안내 GPT-4o(82.7%)보다 높았다. 연구진은 지연과 비용도 훨씬 낮았다고 밝혔다. 다만 의료 지침이라는 특정 영역의 결과이고, 실제 진료 성능으로 바로 옮겨 읽으면 안 된다.

다른 방향은 사람의 판정 자체를 근거로 쌓는 것이다. iRAG논문는 지식 베이스가 처음에는 비어 있고, 사람이 내린 결정을 선례로 저장해 검색에 쓰는 시스템이다. 처음에는 조용히 지켜보다가, 근거를 들어 사람의 판단에 이의를 제기하는 단계를 거쳐, 판단을 보류할 수 있는 자동 처리로 옮겨 간다. 연구진은 오래된 선례의 비중을 낮추는 장치가 바뀐 지식에서는 성능을 높이지만 안정된 지식에서는 오류를 늘린다고 보고했다. 이는 일반적 우위가 아니라 맞바꿈이라는 것이다. 실제 사용자와의 사용성은 아직 평가하지 않았다고 밝혔다.

두 연구는 같은 그림을 가리킨다. LLM은 문서를 읽고 기준을 뽑는 일과 국소적인 판단에 쓰고, 판정의 뼈대는 그래프·규칙·선례처럼 추적 가능한 구조에 둔다. 금융 AI의 변천을 다룬 연구논문는 더 앞선 모델이나 자율 에이전트가 모든 과제에서 낫지는 않으며, 과제의 성격에 맞춰 방식을 골라야 한다고 정리한다. 판정형 RAG에도 그대로 들어맞는 조언이다.

언제 쓰고 언제 피하나

판정형 설계가 맞는 곳은 판정 기준이 문서로 존재하고, 결과가 소수의 선택지(승인·거절·검토·배정)로 떨어지며, 나중에 누가 왜 그렇게 정했는지 설명해야 하는 업무다. 규정 준수 분류, 사내 승인, 티켓 라우팅이 그 예다. 반대로 기준 자체가 아직 합의되지 않았거나, 답이 사람이 읽고 판단할 설명이면 충분한 업무라면 기존 RAG로도 된다. 판정 계층을 덧붙이면 관리할 것만 늘어난다.

흔한 실수는 네 가지다. 첫째, 정책 문장을 시스템 프롬프트에 붙여 넣고 통제가 생겼다고 여기는 것이다. Policy-as-Skill논문은 자연어 프롬프트만으로는 어느 정책 버전을 쓸지, 근거가 없을 때 어떻게 할지, 언제 사람에게 넘길지가 정해지지 않는다고 지적한다. 둘째, 스키마를 지킨 출력을 맞는 판정으로 착각하는 것이다논문. 셋째, 권한 통제가 입력에만 걸려 있는데 출력까지 보호된다고 믿는 것이다. Palantir 문서글는 행·열 접근 통제가 모델이 읽는 데이터를 걸러 주지만, 모델의 출력이나 모델이 만든 편집에는 적용되지 않는다고 명시한다. 넷째, 판정의 신뢰도 점수를 검증하지 않고 임계값에 바로 쓰는 것이다. Leanware 글글은 신뢰도 보정, 승인율 변화, 사람이 뒤집은 판정을 계속 지켜봐야 한다고 권한다.

가장 중요한 원칙은 사람의 최종 책임이다. 판정형의 목표는 일관성과 추적 가능성이지, 판단의 책임을 시스템에 넘기는 것이 아니다. 사람 검토로 넘기는 조건과 근거가 없을 때의 동작을 처음부터 설계에 넣어야 한다.

더 공부하려면, 그리고 2편으로

출발점은 Martin Connell의 칼럼글이다. 주장의 뼈대를 빠르게 파악할 수 있지만 의견 글이라는 점을 염두에 두고 읽는다. 다음으로 Leanware 글글에서 계층 구조와 RAG 대비 표를 보면 설계 감각이 잡힌다. 계보를 정확히 알고 싶다면 RAG 설문논문과 에이전틱 RAG 설문논문을 차례로 읽는다.

판정형의 각 요소를 연구로 확인하려면 기준 추출과 가중치는 RAD논문로, 통제·감사·사람 검토는 Policy-as-Skill논문로 이어서 읽는다. 특히 Policy-as-Skill은 결정론적 통제가 과제마다 다르게 작동한다는 분석이 있어 다음 편의 질문과 곧바로 이어진다. 구조화된 출력을 도입하기 전에는 형식 제약 연구논문를 꼭 함께 본다. 최근 흐름은 GDGraph논문와 iRAG논문가 잘 보여 준다.

2편에서는 이 글이 남긴 질문을 정면으로 다룬다. 판정 규칙을 LLM에 맡길 것인가, 규칙 엔진에 맡길 것인가. 그리고 그 경계를 어디에 그을 것인가.