담당자가 “왜 이 요청은 승인됐고, 저 요청은 거절됐는가”를 다시 물었을 때 같은 답을 낼 수 있어야 하는 업무가 있다. 고객 등급별 혜택, 구매 한도, 정산 보류, 내부 승인, 계약 조건 검토처럼 기준이 정해져 있고 결과에 책임이 따르는 흐름이 그렇다.
이런 업무에 LLM을 붙이면 문서를 읽고 자연스러운 답변을 만드는 데에는 도움이 된다. 그러나 문장을 잘 만드는 능력과 정해진 조건을 빠짐없이 적용해 판정하는 능력은 다르다. 정책 문구가 같아도 프롬프트, 검색 결과, 모델 버전, 대화 맥락에 따라 결론이 흔들릴 수 있기 때문이다.
요구사항 단계에서 먼저 정할 질문은 “AI가 이 업무를 자동화할 수 있는가”가 아니다. 누가 결론을 내리고, 누가 그 결론의 이유를 사람에게 전달할 것인가다. 판정은 규칙 엔진이 맡고, RAG는 조직의 문서를 찾아 설명을 보강하는 구조가 필요한 업무가 분명히 있다.
판정과 설명은 같은 작업이 아니다
규칙 엔진은 입력된 사실과 사전에 정의한 조건을 대조해 결과를 낸다. 예를 들어 고객 상태, 금액, 계약 기간, 승인 여부처럼 구조화한 값을 받아 조건을 충족하면 특정 결과를 반환한다. 같은 사실과 같은 규칙 집합을 넣으면 같은 결과가 나와야 한다는 점이 핵심이다.
RAG는 검색 증강 생성 방식이다. 사용자의 질문이나 업무 맥락에 맞는 사내 규정, 운영 매뉴얼, 계약서, 공지 등을 찾아 언어 모델의 답변 근거로 제공한다. 문서가 길고 표현이 다양할 때, 사람이 읽기 쉬운 설명을 만드는 데 적합하다.
둘을 한 시스템 안에서 쓸 수는 있지만 책임을 섞으면 안 된다.
- 규칙 엔진은 승인, 거절, 보류, 담당자 검토 요청 같은 업무 결과를 결정한다.
- RAG와 LLM은 적용된 정책의 취지, 관련 문서 조항, 다음 행동을 이해하기 쉬운 문장으로 안내한다.
- 사람은 규칙에 없는 예외를 승인하거나, 규칙 자체가 현실과 맞는지 수정한다.
이 구분이 없으면 LLM이 문서의 일부를 다르게 해석해 정책상 허용되지 않는 결론을 제시할 수 있다. 반대로 규칙만으로 구성하면 결과는 일관되지만, 현업과 고객은 기계적인 코드나 조건식만 보고 이유를 추정해야 한다.
분리 구조가 더 적합한 업무와 LLM 단독으로도 가능한 업무
모든 자동화에 규칙 엔진이 필요한 것은 아니다. 판단 결과가 조직의 공식 처리가 되는지, 결과를 나중에 재현해야 하는지가 기준이다.
다음 조건이 많다면 규칙 엔진과 RAG를 분리하는 쪽이 적합하다.
| 업무 조건 | 권장 설계 |
|---|---|
| 승인·거절·가격·한도·자격처럼 결과가 외부 처리로 이어짐 | 규칙 엔진이 판정, RAG가 설명 |
| 같은 입력에 같은 결과를 재현해야 함 | 규칙과 입력 사실의 버전 관리 |
| 여러 정책이 충돌하거나 우선순위를 가짐 | 규칙 우선순위와 충돌 검토 절차 |
| 담당자가 결과를 되짚어 수정해야 함 | 발화 규칙, 미발화 규칙, 입력값 기록 |
| 문서에서 사실을 찾아야 하지만 문서 해석이 불완전할 수 있음 | RAG 결과를 후보 사실로 취급하고 검증 후 규칙 입력 |
| 초안 작성, 요약, 문의 분류처럼 결과가 공식 판정이 아님 | LLM 단독 또는 RAG 중심 설계 가능 |
가령 “이 고객에게 할인 쿠폰을 발급해도 되는가”는 재고, 고객 등급, 중복 사용 여부, 캠페인 기간 같은 조건이 명확하다면 규칙으로 결정할 수 있다. 반면 “이번 캠페인의 고객 반응을 어떤 표현으로 요약할 것인가”는 하나의 정답보다 맥락 있는 서술이 중요하므로 LLM의 역할이 더 크다.
핵심은 업무의 난이도가 아니다. 틀린 결과를 누가 어떤 기록으로 수정하고 설명해야 하는가가 더 중요한 기준이다.
RAG가 읽은 문서를 바로 규칙의 사실로 넣을 때 생기는 문제
문서 검색 결과에는 정답만 들어 있지 않다. 오래된 지침, 특정 부서에만 적용되는 예외, 문맥상 조건이 빠진 표, 서로 다른 버전의 정책이 함께 검색될 수 있다. LLM이 문서 내용을 구조화해 “고객은 예외 승인 대상”이라는 사실을 만들고, 이 값을 바로 규칙 엔진에 넣으면 오류가 더 단단한 결론으로 바뀔 수 있다.
따라서 문서에서 꺼낸 정보는 다음 세 층으로 나눠 다루는 편이 안전하다.
- 확정 사실: 고객 ID, 계약 시작일, 주문 금액처럼 원천 시스템에서 조회한 값이다. 규칙 판정에 바로 사용할 수 있다.
- 추출 사실: PDF, 이메일, 자유 서술 문서에서 모델이 찾아낸 값이다. 신뢰도와 원문 위치를 함께 보관하고, 중요 조건이면 사람이 확인하거나 별도 검증을 거친다.
- 설명 자료: 판정이 난 뒤 관련 정책을 이해시키기 위해 가져온 문서다. 결론을 바꾸지 않고 이유를 설명하는 데 쓴다.
이 구분은 RAG를 배제하자는 뜻이 아니다. 오히려 RAG가 잘하는 일을 좁혀 신뢰할 수 있게 만드는 방법이다. 검색은 관련 문서를 찾고, 언어 모델은 내용을 풀어 쓰며, 규칙은 정해진 입력으로 업무 상태를 바꾼다.
요구사항에 먼저 적어야 할 감사 단위
“판정 근거를 남긴다”는 문장만으로는 구현 범위가 정해지지 않는다. 개발팀과 현업이 함께 확인할 수 있도록, 한 건의 업무 처리에서 무엇을 저장할지 정해야 한다.
최소한 다음 질문에는 답할 수 있어야 한다.
- 판정 시점에 사용한 입력값은 무엇이었는가.
- 어떤 규칙 버전이 적용됐고, 어떤 조건이 충족됐는가.
- 적용 가능한 규칙이 여러 개였다면 어떤 우선순위로 하나를 선택했는가.
- 적용되지 않은 중요한 규칙은 무엇이며, 어느 값이 조건을 충족하지 못했는가.
- 설명에 사용한 문서는 무엇이고, 당시 문서 버전은 무엇이었는가.
- 운영자가 결과를 바꾸었다면 누가 어떤 사유로 변경했는가.
여기서 규칙의 식별자와 문서의 식별자를 분리해 두는 것이 중요하다. “정책 문서에 그렇게 쓰여 있다”는 설명과 “이 조건식이 실행됐다”는 실행 기록은 같은 정보가 아니다. 전자는 사람의 이해를 돕고, 후자는 시스템의 처리를 재현하게 한다.
규칙 간 충돌도 요구사항으로 다뤄야 한다. 예를 들어 한 규칙은 장기 고객에게 승인을 주고, 다른 규칙은 연체 상태에서 거절을 내릴 수 있다. 이런 충돌이 가능한지, 가능하다면 어느 결과가 우선인지, 충돌 시 자동 처리 대신 검토 대기열로 보내는지를 정책 소유자가 정해야 한다. 규칙 엔진을 도입한다고 충돌이 사라지는 것은 아니다. 충돌을 숨기지 않고 발견 가능한 형태로 만든다는 데 의미가 있다.
초기 구축은 ‘정답률’보다 경계 사례로 검증한다
첫 단계에서 모든 정책 문서를 검색 가능하게 만들고 모든 규칙을 코드로 옮기려 하면 범위가 커진다. 우선 결과의 책임이 크고 조건이 비교적 명확한 업무 하나를 고르는 편이 낫다. 승인 또는 거절이 분명하고, 현업이 현재도 판단 근거를 설명해야 하는 흐름이 후보가 된다.
검증할 때는 정상 사례만 준비하지 말아야 한다. 다음 상황을 포함해야 설계 결함이 드러난다.
- 기준값 바로 위와 바로 아래에 있는 입력
- 서로 다른 규칙이 동시에 적용될 수 있는 입력
- 필요한 사실이 누락된 입력
- 오래된 문서와 최신 문서가 함께 검색되는 상황
- 사람이 예외 처리한 뒤 재처리해야 하는 상황
- 설명 문구는 자연스럽지만 실제 규칙 결과와 다른 상황
이 테스트에서 확인할 것은 LLM의 문장 품질만이 아니다. 결론이 입력값과 규칙에 따라 일관되게 바뀌는지, 설명이 결론을 과장하거나 새 조건을 만들어 내지 않는지, 운영자가 오류 원인을 찾을 수 있는지 확인해야 한다.
프로젝트 발주나 솔루션 검토 단계라면 “자연어로 정책을 등록할 수 있는가”보다 다음을 물어보는 편이 낫다. 규칙 변경 이력과 승인 절차를 관리하는지, 규칙 충돌을 어떻게 찾는지, 판정 당시의 입력과 실행 경로를 보존하는지, 검색된 문서가 결론을 바꾸는지 설명에만 쓰이는지 확인해야 한다.
업무 규칙이 아직 문서와 담당자의 머릿속에 흩어져 있다면, LLM을 먼저 붙여 결정을 자동화하기보다 판정 기준부터 표로 꺼내는 작업이 선행돼야 한다. 그 표에서 예외와 우선순위가 드러나면, 어디까지는 규칙으로 자동 처리하고 어디부터는 문서 검색과 사람의 검토로 넘길지 더 현실적으로 정할 수 있다.
