🎬 1분 브리핑 영상
RAG로 재난 매뉴얼 챗봇을 만들려면 검색증강생성의 구성요소와 문서 근거 표기 방식을 먼저 이해해야 합니다.
📌 3줄 요약
- RAG는 LLM이 답하기 전에 문서를 먼저 찾아 근거로 쓰는 구조
- 매뉴얼·조례는 출처와 최신성이 생명이라 RAG가 특히 잘 맞음
- 벡터 검색, 청크 분할, 출처 표기가 챗봇 신뢰도를 좌우함
재난 상황실에 전화가 걸려옵니다. "하천 수위가 위험 수위를 넘었을 때 대피 명령은 누가 내리나요?" 담당자는 수십 쪽짜리 매뉴얼과 조례집을 뒤적입니다. 이럴 때 챗봇이 즉시 답해주면 좋겠다는 생각, 누구나 한 번쯤 해봤을 겁니다.
문제는 일반 생성형 AI에게 그냥 물어보면 그럴듯하지만 틀린 답을 자신 있게 내놓을 수 있다는 점입니다. 매뉴얼에 없는 내용을 지어내거나, 작년에 개정된 조례를 모른 채 옛날 기준으로 답하기도 합니다. 재난 업무에서 이런 오답은 단순한 불편이 아니라 위험으로 이어질 수 있습니다. 그래서 등장한 방법이 검색증강생성, 줄여서 RAG입니다.
🔍 RAG가 뭔가요? LLM이랑 뭐가 다른가요?
RAG는 Retrieval-Augmented Generation의 줄임말로, '검색한 뒤 생성한다'는 뜻입니다. 일반 거대언어모델(LLM, 방대한 텍스트로 학습해 문장을 만드는 AI)은 학습 당시 기억한 내용으로만 답합니다. 반면 RAG는 질문이 들어오면 먼저 관련 문서 조각을 찾아오고, 그 내용을 참고자료로 붙여서 답을 생성합니다. 비유하자면 일반 LLM은 암기한 지식으로 시험 보는 학생이고, RAG는 오픈북 시험을 보는 학생입니다. 책을 펴 놓고 답을 찾으니 틀릴 확률이 줄어듭니다. 재난 매뉴얼처럼 조항 하나하나가 법적 근거가 되는 문서에서는 암기보다 오픈북 방식이 훨씬 안전합니다.
🧩 RAG는 어떤 부품들로 이루어져 있나요?
RAG는 크게 네 가지로 구성됩니다. 첫째, 문서를 잘게 쪼개는 청크 분할(문서를 의미 단위로 나누는 작업). 둘째, 쪼갠 조각을 숫자 벡터로 바꾸는 임베딩(텍스트의 의미를 벡터 공간의 좌표로 표현하는 기술). 셋째, 질문과 비슷한 의미의 조각을 찾는 벡터 데이터베이스 검색. 넷째, 찾아온 조각을 근거로 답을 만드는 LLM입니다. 이 네 단계가 순서대로 돌아가야 "질문과 의미가 비슷한 매뉴얼 조항"을 정확히 찾아낼 수 있습니다. 홍수 대응 매뉴얼 챗봇이라면, "주의보와 경보의 차이"를 물었을 때 수백 쪽 중 해당 조항만 콕 집어 가져오는 게 바로 이 검색 단계의 역할입니다.
📋 매뉴얼·조례 같은 문서에 RAG가 특히 잘 맞는 이유는?
매뉴얼과 조례는 조항 번호, 발령 기준, 책임 소재가 명확히 적힌 '근거형 문서'입니다. 이런 문서는 창의적인 답보다 원문 그대로의 정확한 인용이 중요합니다. RAG는 LLM이 지식을 지어내는 대신 실제 문서 조각을 가져와 답하게 만들기 때문에, 환각(hallucination, AI가 사실이 아닌 내용을 그럴듯하게 만들어내는 현상)을 상당히 줄여줍니다. 또한 문서가 바뀌면 벡터 데이터베이스만 다시 만들면 되고, LLM 자체를 재학습시킬 필요가 없습니다. 산사태 위기대응 실무편람처럼 자주 개정되는 문서를 다루는 조직이라면, 모델을 새로 훈련하는 대신 문서 저장소만 갱신하는 RAG 구조가 운영비 면에서도 현실적입니다.
📎 챗봇이 "어디서 나온 답"인지 어떻게 보여주나요?
RAG의 가장 큰 장점 중 하나는 출처 표기가 자연스럽다는 점입니다. 검색 단계에서 이미 "몇 번째 문서, 몇 쪽, 몇 조항"이라는 정보를 함께 가져오기 때문에, 답변 끝에 "근거: OO시 재난대응 매뉴얼 3장 2절"처럼 출처를 붙이기가 수월합니다. 이 출처 표기는 단순한 친절 기능이 아니라 사용자가 답을 검증할 수 있게 해주는 안전장치입니다. 담당자가 챗봇 답을 그대로 믿지 않고 원문 조항을 열어 한 번 더 확인하는 습관을 들이는 것이 중요합니다. 대피소 운영 기준처럼 책임이 따르는 정보일수록, 출처 링크를 눌러 원문을 대조하는 절차를 조직 내 업무 규칙으로 만들어 두는 것이 좋습니다.
🗓️ 매뉴얼이 개정되면 챗봇은 어떻게 최신 정보를 따라가나요?
RAG의 약점은 검색 대상 문서 저장소, 즉 벡터 데이터베이스가 낡으면 아무리 검색을 잘해도 옛날 답을 준다는 점입니다. 조례가 개정되거나 매뉴얼이 새 버전으로 바뀌면, 반드시 기존 문서를 빼고 새 문서를 다시 청크 분할해 임베딩하는 갱신 작업을 해줘야 합니다. 이 과정을 자동화하지 않으면 "최신 조문"과 "예전 조문"이 뒤섞여 검색되는 일이 생길 수 있습니다. 실제로 운영해보면 개정 주기, 문서 버전 관리 규칙을 미리 정해두지 않고는 금방 꼬인다는 걸 알게 됩니다. 이건 해봐야 아는 부분이라, 소규모 문서 몇 개로 먼저 갱신 주기와 절차를 시험해보고 범위를 넓히는 방식을 권합니다.
🖥️ 화면에서 따라하기
- 문서 준비
활용할 매뉴얼·조례 PDF나 한글 파일을 폴더 하나에 모은다 - 청크 분할
문서를 문단·조항 단위로 나누는 도구(예: LangChain, LlamaIndex)로 텍스트를 쪼갠다 - 임베딩 생성
쪼갠 텍스트를 임베딩 모델에 넣어 벡터로 변환한다 - 벡터 저장소 구축
변환된 벡터를 Chroma, FAISS 같은 벡터 데이터베이스에 저장한다 - 질의응답 테스트
실제 질문을 입력해 검색된 조각과 답변, 출처가 맞는지 확인한다 - 갱신 절차 점검
문서를 개정판으로 교체한 뒤 벡터 저장소를 다시 만들어 반영되는지 확인한다
※ 프로그램 버전에 따라 메뉴 이름이 조금씩 다를 수 있습니다. 위 그림은 순서를 정리한 도식입니다.
✍️ 그대로 복사해 쓰는 프롬프트
매뉴얼 PDF를 RAG용으로 분할할 기준을 LLM에게 설계받기
당신은 재난안전 분야 문서 관리 담당자를 돕는 어시스턴트입니다. [재난 매뉴얼 이름]이라는 문서를 RAG 챗봇에 넣으려고 합니다. 이 문서는 [장, 절, 조항] 구조로 되어 있습니다. 검색 정확도를 높이기 위한 청크 분할 기준(길이, 겹침 범위, 기준 단위)을 제안해주세요. 또한 각 청크에 포함시켜야 할 메타데이터 항목(예: 장 제목, 조항 번호, 개정일)도 목록으로 알려주세요. 확실하지 않은 수치는 '상황에 따라 조정 필요'라고 표시해주세요.
※ 대괄호 부분을 상황에 맞게 바꿔서 쓰세요. 받은 답은 그대로 쓰지 말고 사실 확인을 거치세요.
🧪 직접 해보기
- 공개된 LangChain이나 LlamaIndex 튜토리얼 문서로 간단한 RAG 예제를 직접 돌려보기
- 가지고 있는 재난 매뉴얼 한 편을 조항 단위로 손으로 나눠보며 청크 분할 감 잡기
- 챗봇 답변에 출처 조항을 붙였을 때와 안 붙였을 때 신뢰도 차이를 동료와 비교해보기
❓ 자주 묻는 질문
Q. RAG를 쓰면 챗봇이 절대 틀린 답을 안 하나요?
A. 아닙니다. 검색이 엉뚱한 조각을 가져오거나 문서 자체가 오래됐으면 틀린 답이 나올 수 있습니다. 출처를 항상 함께 표시해 사람이 검증하는 절차가 필요합니다.
Q. RAG를 쓰려면 LLM을 직접 학습시켜야 하나요?
A. 아닙니다. 기존 LLM을 그대로 쓰면서 검색 단계만 추가하는 구조라 별도의 모델 재학습이 필요 없는 경우가 많습니다. 대신 문서를 벡터로 만드는 준비 작업이 필요합니다.
Q. 벡터 데이터베이스는 꼭 유료 서비스를 써야 하나요?
A. 꼭 그렇지는 않습니다. Chroma, FAISS처럼 무료로 쓸 수 있는 오픈소스 도구도 있으며, 문서량과 운영 환경에 맞춰 선택하면 됩니다.
RAG의 네 가지 부품과 출처 표기, 최신성 관리의 중요성을 짚어봤으니, 다음 편에서는 실제로 재난 매뉴얼 챗봇을 어떤 도구로 처음부터 구축해보는 과정을 다뤄보겠습니다.
GeoAI 기초 시리즈 24편 · 전체 43편
재난안전과 GeoAI 이야기를 더 보고 싶다면 아래 채널도 함께 보세요.
📌 바로가기
댓글 없음:
댓글 쓰기