"근거 법령을 확인했습니다"라고 쓰기 전에, LLM이 조문 번호와 내용을 그럴듯하게 지어내는 환각이 법령·SOP 영역에서 가장 위험합니다. RAG(검색 증강 생성)는 답을 만들기 전에 먼저 공식 문서에서 근거를 검색해 고정하고, 그 근거로만 답하며, 답이 근거에 충실한지 평가로 검증하는 방식입니다.
- 최소 청크가 보존하는 조문번호·출처·확인일과 운영 확장에 필요한 문서 ID·권한 메타데이터를 구분할 수 있습니다.
- 조·항 경계를 따른 청킹과 근거 메타데이터를 설계할 수 있습니다.
- 검색된 근거 밖의 내용을 답하지 않는 생성 경계를 만들 수 있습니다.
- 검색 오류와 생성 오류를 나눠 평가하고 사람 원문 확인으로 연결할 수 있습니다.
RAG는 오픈북 시험이다
두 가지 시험을 떠올려 봅시다. 폐쇄책 시험은 "기억해서 답하라"입니다. 헷갈리는 조문은 그럴듯하게 지어내게 됩니다. 오픈북 시험은 "책을 펴서 해당 대목을 보고 답하라"입니다. 답이 눈앞의 근거에 묶입니다.
LLM에게 법령을 그냥 물으면 폐쇄책 시험과 같습니다 — 조문을 지어냅니다. RAG는 이 시험을 오픈북으로 바꿉니다. 답을 만들기 전에 먼저 공식 문서에서 관련 대목을 검색해 책상 위에 펼쳐 놓고(검색), 그 펼쳐진 근거만 보고 답하게(생성) 합니다. 모델의 "기억"을 믿는 대신, 매번 원문을 다시 펴게 만드는 것입니다.
원리는 앞선 안내서들과 하나로 이어집니다. 프롬프트 작성 기초가 "원문을 붙여넣어 정리시켜라"였고, 법령 근거 확인 브리프가 "출처를 표로 먼저 고정하라"였다면, RAG는 그 붙여넣기를 검색으로 자동화한 것입니다. 세 안내서가 말하는 건 결국 같은 한 문장입니다: AI에게 지식을 캐묻지 말고, 근거를 쥐여 주고 정리시켜라.
가상 상황: 하루 수십 건의 조문 질의
가상의 상황을 하나 들어 보겠습니다. 예방·민원 부서에 "이건 무슨 법 몇 조 근거냐"는 질의가 하루에도 수십 건 들어옵니다. 법령 근거 확인 브리프처럼 한 건씩 원문을 찾아 표로 묶는 방식은 몇 건일 때는 정확하지만, 수십 건이 되면 사람이 매번 원문을 붙여넣기 어렵습니다.
이럴 때 필요한 게 검색 자동화입니다. 자주 쓰는 법령·SOP를 미리 검색 가능한 형태로 정리해 두면, 질문이 들어올 때마다 관련 조문을 자동으로 찾아 근거로 깔아 줍니다. 즉 RAG는 "정확도"보다 "규모"를 위한 도구입니다 — 한두 건이면 손으로 표를 만드는 편이 낫고, 반복되는 다건 질의라야 자동화가 값을 합니다. 단, 규모가 커진 만큼 "검색이 엉뚱한 조문을 가져오는" 새로운 실패가 생기므로, 뒤의 검증 단계가 반드시 따라붙습니다.
RAG 4단
| 단계 | 무엇을 | 핵심 원칙 |
|---|---|---|
| 1 정리 | 문서 → 텍스트 | 출처·확인일을 메타로 보존 |
| 2 청킹 | 텍스트 → 검색 조각 | 임의 분할 금지, 조/항 경계 |
| 3 생성 | 근거 → 답변 | 검색된 근거에만 기반, 링크 강제 |
| 4 검증 | 답변 → 점수 | 충실도·맥락정밀도 + 골든셋 회귀 |
1. 문서 정리
PDF 법령·매뉴얼을 검색 가능한 텍스트로 바꿉니다. 법령·지침은 대개 PDF라 그대로는 기계가 조문 단위로 읽을 수 없습니다. 텍스트로 바꾸는 게 오픈북의 "책을 펼치는" 첫 단추입니다.
→ 안전한 AI 운영 도구의 MarkItDown·Unstructured를 쓰고, 어떤 문서를 모을지는 소방 공공데이터·API 지도의 공식 법령 출처를 따르세요. 공개 법령·SOP만 쓰고, 내부 비공개 문서는 권한·보안을 따로 설계합니다.
2. 청킹 — 법령은 조문 경계로
청킹은 긴 문서를 검색이 집어 올릴 수 있는 크기의 조각으로 나누는 일입니다. 일반 RAG는 텍스트를 일정 토큰으로 자르지만, 법령을 토큰 수로 자르면 한 조문이 두 조각으로 쪼개져 근거가 깨집니다.
아래는 그 차이를 보여 주는 예시입니다(제△조는 자리표시자이며 실제 조문이 아닙니다).
# 토큰 수로 자른 경우 — 한 조문이 두 조각으로 갈림 조각 A: "… 제△조(가상) 첫머리 … 다음 각 호에" 조각 B: "따른다 … 제△조 나머지 …" → 검색이 조각 A만 집으면 "다음 각 호"의 내용이 통째로 빠진다. # 조/항 경계로 자른 경우 — 한 조문 = 한 조각 조각: "제△조(가상) [조문 전체 본문]" → 검색이 이 조각을 집으면 근거가 온전하다.
요리 레시피를 문장 수로 자르면 "재료: 밀가루" 다음에 "300g"이 다른 페이지로 넘어가 버립니다. 레시피는 항목 단위로 잘라야 하듯, 법령은 조문 단위로 잘라야 합니다. 그래서 조/항 경계로 나누고, 조문번호·출처·확인일을 메타로 같이 저장합니다.
import re # '제3조', '제3조의2' 경계로 분할 — 조문이 잘리지 않게 ARTICLE = re.compile(r"(제\s?\d+조(?:의\s?\d+)?)") parts = ARTICLE.split(law_text) chunks = [] for i in range(1, len(parts), 2): no = parts[i].strip() body = parts[i + 1].strip() if i + 1 < len(parts) else "" chunks.append({ "text": f"{no} {body}", "article": no, "source": source_url, # 공식 원문 링크 "checked_on": "2026-06-29", # 확인일(법령은 개정된다) })
⚠️ 이 최소 코드의 한계: article, source, checked_on만 보존합니다. 다음 메타데이터는 아직 구현하지 않았습니다:
- 문서 ID·버전 — 같은 조문을 여러 조판에서 가져올 때 중복 제거 불가
- 공개 범위·권한 — 비공개 SOP가 공개 사용자에게 검색될 수 있음
- 갱신·권한 필터 — 인덱스 재구성과 이전 버전 제거 자동화 불가
따라서 아래 운영 시나리오는 이 필터를 별도로 설계·검증한 확장 단계입니다. 최소 코드를 그대로 내부 문서 검색이나 권한이 있는 시스템에 쓰면 안 됩니다.
3. 근거 강제 생성
검색된 근거 조각만 컨텍스트로 주고, 답에 조문·출처를 붙이게 강제하며, 근거가 없으면 답하지 말고 "확인 필요"로 두게 합니다.
아래 [근거]는 공식 문서에서 검색된 조문입니다. [근거]에 있는 내용만으로 답하세요. 근거에 없으면 지어내지 말고 "확인 필요"라고 답하세요. 답의 각 문장 끝에 근거가 된 조문번호와 출처 링크를 붙이세요. 처분·과태료·의무 여부를 단정하지 말고, 해당 조문을 가리키며 "원문 확인 필요"로 안내하세요.
같은 질문에 답이 어떻게 달라지는지 보겠습니다(조문 번호는 자리표시자입니다).
- 근거 강제 없이(위험): "소화기는 제△조에 따라 6개월마다 점검해야 하며, 미이행 시 과태료가 부과됩니다." → 출처 링크가 없고, 처분을 단정합니다.
- 근거 강제 후(안전): "검색된 근거에 점검 주기 관련 조문이 있습니다. 다만 과태료·처분 여부는 이 근거만으로 단정할 수 없어 원문 확인이 필요합니다. — 근거: 제△조(출처 링크), 확인 필요" → 답이 검색된 근거를 가리키고, 단정 대신 확인을 안내합니다.
→ 이 단계의 출력은 법령 근거 확인 브리프의 입력이 됩니다. RAG는 조문 후보를 빠르게 모아 줄 뿐, 처분·해석의 최종 판단은 사람이 원문을 보고 합니다.
4. 검증 — 충실도와 맥락 정밀도
답이 정말 근거에 충실한지(faithfulness), 검색이 관련 조문을 잘 가져왔는지(context precision)를 Ragas로 점수화합니다.
두 지표를 오픈북 시험에 빗대면 이렇습니다. 충실도는 "책에 있는 내용만 썼는가, 딴 얘기를 지어냈는가"이고, 맥락 정밀도는 "펼쳐 준 페이지가 문제와 맞는 페이지였는가"입니다. 검색이 엉뚱한 페이지를 펼쳐 주면(정밀도 낮음), 답이 아무리 그 페이지에 충실해도(충실도 높음) 결국 틀립니다. 그래서 둘 다 봐야 합니다.
자주 묻는 질문으로 골든셋을 만들어, 프롬프트·청킹을 바꿀 때마다 회귀로 돌립니다.
from ragas import evaluate from ragas.metrics import faithfulness, context_precision # eval_dataset: question / answer / contexts(검색된 근거) / ground_truth(정답 근거) result = evaluate(dataset=eval_dataset, metrics=[faithfulness, context_precision]) print(result) # 평균 점수 df = result.to_pandas() # 항목별 점수 — 낮은 질문부터 사람이 원인을 본다
이 방법이 안 통할 때
RAG도 만능이 아닙니다. 오픈북 시험이라도 엉뚱한 페이지를 펴면 틀리듯, 다음 경우엔 여전히 사람이 앞에 서야 합니다.
- 검색이 빗나가면 환각은 남습니다 — 관련 조문을 못 찾았는데 답을 짜내면, 근거 없는 문장이 나옵니다. 근거를 못 찾으면 답하지 말고 "확인 필요"로 두게 하세요.
- 여러 조문이 얽힌 해석 질문 — "이 경우 처분 대상인가"는 단순 검색·요약으로 답할 수 없습니다. 여러 조문·상위법·내부 지침을 사람이 종합해야 합니다.
- 문서가 낡음 — 법령이 개정됐는데 인덱스가 옛 원문이면, 검색은 성실히 "틀린 근거"를 가져옵니다. 확인일 관리가 필수입니다.
- 비공개·내부 문서 — 권한·보안 설계 없이 올리면 유출 위험이 있습니다. 개인정보, AI에 넣기 전에 점검하기를 먼저 거치세요.
만들고 나서 운영에 들어가면 또 다른 위험이 시작됩니다. 법령 개정·프롬프트 수정·모델 교체가 어제까지 잘 나오던 답을 조용히 바꾸기 때문입니다. 골든셋 회귀 평가와 가드레일로 이를 막는 방법은 RAG 운영, 골든셋 회귀 평가와 가드레일로 이어집니다.
설계 판단
RAG는 문서가 많다고 자동으로 정답이 되는 장치가 아닙니다. 질문 빈도, 근거의 위험도, 문서 권한과 갱신 책임을 함께 보고 수동 확인과 검색 자동화 사이를 고릅니다.
| 방식 | 맞는 상황 | 트레이드오프 | 사람이 확인할 것 |
|---|---|---|---|
| 원문 수동 검색 + 근거표 | 질문이 적고 처분·의무처럼 오류 비용이 큰 때 | 속도와 대량 처리를 포기하고 근거 확인을 우선 | 정확한 원문·시행 시점·적용 범위 |
| 단일 공개 문서군 RAG | 반복 질문이 많고 확인된 문서 범위가 명확할 때 | 청킹·검색·갱신을 계속 평가해야 함 | 답변 링크와 검색 로그의 원문 일치 |
| 권한별로 분리한 문서군 RAG | 공개 자료와 내부 SOP가 섬세하게 다른 독자에게 제공될 때 | 인덱스·갱신·테스트 범위가 늘어남 | 사용자 권한과 검색 결과의 출처 일치 |
운영 시나리오
두 사례는 특정 법령·기관의 실제 사건이 아닌 가상 연습입니다. 현재 최소 코드에 없는 문서 ID·버전·권한 메타데이터와 검색 필터를 운영 확장으로 추가한다는 전제에서, 시스템이 어떤 근거를 보여 줬는지를 재현하는 데 초점을 둡니다.
가상 시나리오 1: 갱신한 문서 뒤에도 예전 근거가 검색된 경우
- 탐지: 문서 갱신 후 같은 질문의 근거 링크·확인일을 비교하니 예전 버전의 조각이 새 조각과 함께 나왔습니다.
- 원인 가설: 최소 청크에는 고유 문서 ID·버전이 없어 이전 조각을 확실히 식별·제거하지 못했고,
checked_on도 저장만 했을 뿐 검색 필터에 연결하지 않았다고 봅니다. - 대응: 질의응답 제공을 멈추고 문서 ID·버전 메타데이터와 갱신 절차를 먼저 구현한 뒤, 승인된 원문 한 스냅샷으로 인덱스를 재구성합니다.
- 재발 확인: 같은 골든 질문을 다시 돌려 예전 문서 ID가 검색되지 않고 출처·확인일이 현재 스냅샷과 일치하는지 확인합니다.
가상 시나리오 2: 권한이 다른 문서 조각이 함께 검색된 경우
- 탐지: 권한 메타데이터가 없는 최소 청크에 내부 SOP를 섞으면 공개 사용자에게도 검색될 수 있음을 배포 전 가상 권한 시험에서 확인했습니다.
- 원인 가설: 현재 최소 코드에는 문서 공개 범위와 사용자 권한을 표현하거나 검색 전에 거르는 구현이 없습니다.
- 대응: 내부 SOP를 인덱스에 넣지 않고, 문서군 분리 또는 검색 전 권한 필터와 보안 승인을 먼저 구현합니다.
- 재발 확인: 권한 조합별 가상 질문으로 허용된 문서 ID만 돌아오는지 확인하고, 금지 출처가 한 건이라도 나오면 배포를 중단합니다.
한계와 리스크
| 리스크 | 발생 조건 | 영향 | 완화·사람 승인 |
|---|---|---|---|
| 낡은 근거의 재검색 | 개정·갱신 후 이전 인덱스가 남음 | 답은 근거에 충실해도 현재 원문과 불일치 | 버전·확인일을 강제하고 갱신 후 담당자가 원문 대조 |
| 권한 경계 누락 | 서로 다른 공개 범위의 문서를 하나의 검색 공간에 섞음 | 비공개 출처·내용의 노출 가능성 | 검색 전 권한 검사와 분리 인덱스를 적용하고 보안 담당자 승인 |
| 근거 밖 생성 | 검색 조각이 부족한데도 모델이 기억으로 문장을 보완함 | 근거 없는 의무·처분 표현이 나올 수 있음 | 근거 없음을 응답 중단 조건으로 두고 외부 제공 전 사람이 공식 원문 확인 |
자주 묻는 질문
Q. RAG를 쓰면 환각이 없어지나요?
아닙니다. 근거를 못 찾거나 엉뚱한 근거를 찾을 수 있고, 맞는 근거 위에 모델이 다른 내용을 덧붙일 수도 있습니다. 근거 없음을 정상적인 중단 결과로 설계해야 합니다.
Q. 검색된 조문으로 처분·의무 여부를 바로 답해도 되나요?
안 됩니다. RAG의 출력은 확인할 원문 후보와 초안입니다. 여러 규정의 관계와 사실관계를 종합하는 법적 해석은 자동화 범위에 두지 않습니다.
Q. 청크를 작게 나누면 검색이 항상 좋아지나요?
작을수록 정밀한 대목을 찾기 쉬울 수 있지만, 단서·항·단서 부정처럼 함께 읽어야 할 문맥이 끊깁니다. 길이보다 조·항 경계와 메타데이터 보존을 먼저 검증합니다.
Q. 문서만 바꾸면 인덱스도 자동으로 최신이 되나요?
그렇지 않습니다. 입력 문서 승인, 이전 조각 제거, 새 인덱스 생성, 질문 회귀 검사를 하나의 갱신 절차로 관리해야 합니다.
핵심 정리
- RAG는 모델의 기억 대신 확인한 원문을 답변 앞에 놓는 구조입니다.
- 현재 최소 청크는 조문번호·출처·확인일만 보존합니다. 문서 ID·버전·권한은 운영 전에 별도 구현·검증해야 할 근거 메타데이터입니다.
- 검색 실패와 생성 실패를 분리해야 수정할 층을 정확히 고를 수 있습니다.
- 근거 없는 답, 낡은 근거, 권한 밖 근거는 모두 응답 중단과 사람 확인의 신호입니다.
다음 단계
- 법령 근거 확인 브리프: RAG가 모은 조문 후보를 공식 원문과 대조하는 사람 검토 형식을 익힙니다.
- RAG 운영 평가: 문서·프롬프트·모델이 바뀐 뒤에도 근거 품질이 유지되는지 회귀로 확인합니다.
- 개인정보 점검: 내부 문서와 질문을 인덱스에 넣기 전 민감정보 경계를 확인합니다.
사람 검토 체크리스트
- [ ] 공개 법령·SOP만 사용했고, 비공개 문서는 권한·보안을 따로 설계했습니다. - [ ] 청크에 조문번호·출처 링크·확인일이 보존돼 있습니다. - [ ] 답변마다 근거 조문·출처가 붙어 있고, 근거 없는 답은 "확인 필요"입니다. - [ ] faithfulness·context precision이 낮은 질문을 사람이 원인 분석했습니다. - [ ] 처분·과태료 같은 단정 표현이 사람 검토 없이 나가지 않습니다. - [ ] 실제 문서로 내보내기 전 [제출 전 1분 점검](ai-output-review.html)을 거쳤습니다.