AI 공부 · 03 / 검색·RAG
“우리 서비스의 환불 기간이 며칠인가요?”라는 질문에 언어모델이 학습 때 본 지식만으로 답하면, 오늘 적용되는 정책을 확인할 수 없습니다. RAG는 답을 만들기 전에 관련 자료를 검색해 모델에 제공하는 설계입니다. 그러나 검색 결과 하나를 붙였다고 정답이 보장되지는 않습니다. 문서를 어떻게 나누고 찾았는지, 그 자료가 현재 유효한지, 답의 각 주장을 뒷받침하는지를 따로 확인해야 합니다.
이 그림은 학습을 위한 일반적인 응용 프로그램 흐름입니다. 이 글은 RAG 서비스를 실제 배포하거나 성능을 측정했다는 기록이 아닙니다.
1. RAG에서 ‘검색’과 ‘생성’은 다른 단계다
RAG는 Retrieval-Augmented Generation, 우리말로 검색 증강 생성입니다. 먼저 질문과 관련된 자료를 찾는 검색 단계, 그 자료를 참고해 답을 쓰는 생성 단계로 나눌 수 있습니다. Google Cloud의 RAG 구성 문서도 이 두 단계를 구분합니다. 2020년 RAG 원 논문은 생성 모델에 외부 지식 검색을 결합하는 연구를 제시했습니다.
RAG를 ‘새 언어모델의 이름’이나 ‘반드시 모델을 다시 학습시키는 방법’으로 이해하면 설계가 흐려집니다. 오늘의 많은 응용에서는 기존 모델을 그대로 사용하면서 질문마다 찾은 자료를 입력에 보태는 방식으로 구현합니다. 검색 자체는 키워드, 벡터, 기존 검색 엔진 등 여러 방법을 쓸 수 있습니다. 따라서 벡터 DB가 없으면 RAG가 아니다라는 말도 정확하지 않습니다. Google Cloud 역시 기존 검색 시스템을 검색기로 연결하는 경로를 안내합니다.
2. 청킹: 문서 전체보다 관련 단락을 찾아야 하는 이유
검색할 자료가 PDF나 긴 매뉴얼이라면 먼저 텍스트를 읽어내고, 제목·절·표·페이지 같은 구조를 파악해야 합니다. 이어 문서를 검색하기 좋은 크기의 조각인 청크(chunk)로 나눕니다. Google Cloud의 문서 파싱·청킹 안내는 문서 전체 대신 관련 청크를 반환하면 답변에 필요한 정보를 더 잘 고르고 모델의 처리 부담도 줄일 수 있다고 설명합니다.
청크를 무조건 같은 글자 수로 자르면 조건이 분리될 수 있습니다. 예를 들어 문장 하나에는 “환불 기간은 14일”만 남고 다음 청크에는 “10월 1일부터 신규 결제에 적용”만 들어갈 수 있습니다. 앞 조각만 검색되면 기간은 맞아 보여도 시행일과 적용 대상을 잃습니다. 제목과 단락 경계를 유지하고, 필요한 경우 이웃 청크를 함께 가져오며, 각 조각에 문서 제목·버전·시행일·원문 위치를 붙이는 이유입니다. 제목을 청크에 보태 문맥 손실을 줄이는 방법도 공식 문서에 소개됩니다.
3. 임베딩과 벡터 DB는 무엇을 맡나?
임베딩(embedding)은 텍스트를 의미가 비슷한지 비교하기 쉬운 숫자 배열, 즉 벡터로 표현한 것입니다. 문서 청크의 임베딩을 만들어 저장하고 질문도 같은 계열의 모델로 임베딩하면, 가까운 벡터를 가진 후보를 찾을 수 있습니다. Google Cloud의 구성 문서는 청크 생성 → 임베딩 → 벡터 검색 → 재순위화 → 답변 생성의 흐름을 예시로 듭니다.
벡터 DB 또는 벡터 검색 인덱스는 이 숫자 표현을 저장하고 가까운 후보를 빠르게 찾는 역할을 합니다. 벡터가 ‘정답’을 저장하는 것은 아닙니다. 비슷한 주제의 오래된 정책이 더 높은 유사도를 받을 수도 있습니다. 자료에는 원문 텍스트와 출처·버전·권한 같은 메타데이터도 함께 보관해야 하고, 검색 결과를 사용자에게 보여주려면 원문으로 돌아갈 수 있어야 합니다.
반대로 제품 코드, 법 조항 번호, 오류 코드처럼 정확한 문자열이 중요한 질문은 키워드 검색이 더 직접적일 수 있습니다. 두 방식을 섞거나, 작은 문서 모음에는 기존 검색 기능부터 시험하는 것도 합리적입니다. 이는 벡터 검색이 불필요하다는 주장이 아니라, 검색 방식을 자료와 질문에 맞춰 고르는 설계 판단입니다.
4. 검색 결과를 다시 고르고 답에 넣는다
첫 검색은 보통 정답 하나를 확정하는 단계가 아니라 후보를 모으는 단계입니다. 이어 재순위화(reranking)로 질문에 실제로 답하는 청크를 위로 올릴 수 있습니다. Google Cloud의 순위화 문서는 의미 유사도만 보는 검색과, 후보 문서가 질문에 얼마나 직접 답하는지 다시 평가하는 단계를 구분합니다. 여기에 시행일·버전·권한 필터를 적용하는 일은 별개의 설계 문제입니다.
후보를 고른 다음에는 모델에 “아래 자료에 없는 사실은 추측하지 말고, 각 주장에 출처 ID를 붙이며, 근거가 모자라면 확인 불가라고 답하라”고 지시할 수 있습니다. 이 지시는 도움이 되지만 보증 장치는 아닙니다. 모델이 근거에 없는 결론을 쓸 수 있고, 인용한 구절이 실제 주장 전체를 뒷받침하지 않을 수도 있습니다. 앞선 LLM 글의 환각 예시가 RAG에도 그대로 적용됩니다.
5. 가상 정책 두 건으로 끝까지 따라가 보기
아래 자료는 실제 회사의 정책이 아닌 학습용 가상 문서입니다. 질문은 “2026년 9월 30일에 결제한 이용자의 환불 신청 기간은?”입니다.
| 문서 | 내용 | 메타데이터 |
|---|---|---|
| 정책 A | 결제 후 7일 이내 환불 신청 가능 | 2026년 1월 1일 시행, 9월 30일까지 적용 |
| 정책 B | 결제 후 14일 이내 환불 신청 가능 | 2026년 10월 1일 이후 신규 결제부터 적용 |
“환불 신청 기간”이라는 단어만 보면 두 문서가 모두 검색됩니다. 새로운 문서 B를 무조건 우선하거나 “14일” 문장만 떼어 모델에 주면 9월 30일 결제에 대해 틀린 답이 나옵니다. 먼저 결제일과 시행 조건으로 후보를 걸러야 합니다. 이 예시에서 기대하는 답은 “정책 A 기준, 결제 후 7일 이내입니다. 정책 B의 14일 규정은 10월 1일 이후 신규 결제부터 적용됩니다”입니다. 실제 서비스라면 시간대, 정책 변경 이력, 예외 조항까지 추가로 확인해야 합니다.
이 예시는 검색의 관련성과 답의 유효성이 다르다는 것을 보여줍니다. 정책 B는 주제상 관련이 있지만 질문 날짜에는 적용되지 않습니다. 어떤 검색 방식이 후보를 올렸든, 버전과 적용 시점을 확인하지 않으면 RAG도 자신 있게 오답을 만들 수 있습니다.
6. 답변을 검증할 때 볼 네 가지 실패 지점
| 단계 | 실패 예 | 확인 방법 |
|---|---|---|
| 문서 준비 | 표·각주·시행일이 파싱에서 빠짐 | 원문과 추출 텍스트, 청크 경계 대조 |
| 검색 | 정책 A가 후보에서 빠짐 | 정답 문서가 상위 후보에 들어오는지 시험 |
| 선택 | 미래 정책 B가 현재 문서로 선택됨 | 시행일·버전·권한 조건 확인 |
| 생성 | 올바른 청크를 받고도 14일이라고 답함 | 답의 주장마다 인용 문단과 의미 대조 |
인용 링크가 표시됐다는 것만으로 답이 검증된 것은 아닙니다. Google Cloud의 근거 확인 문서는 답의 주장과 참고 자료 사이의 지지 관계를 따로 평가하는 방법을 설명합니다. 높은 유사도 점수, 원문 구절의 존재, 실제 질문에 대한 정답은 각각 다른 문제입니다. 중요한 업무에서는 근거가 부족할 때 “모르겠다”고 답하고 사람 확인으로 넘길 수 있어야 합니다.
7. 우리 자동화 프로젝트에 RAG가 꼭 필요한가?
멍냥잇의 모닝 브리핑은 공식 발표 최대 세 건을 그날 직접 수집해 한 번의 요약 요청에 넣습니다. 현재 프로그램은 문서 청크를 인덱싱하거나 벡터 DB를 검색하지 않습니다. 따라서 이것을 “벡터 DB를 갖춘 RAG 구현”이라고 소개하지 않습니다. 외부 원문을 모델에 제공한다는 점에서는 근거 기반 생성의 원리를 공유하지만, 저장된 방대한 문서에서 질문마다 검색하는 시스템과는 규모와 검색 단계가 다릅니다.
여러 해의 발표를 질문으로 찾아보는 자료실이나 사내 문서 Q&A를 만든다면 검색 인덱스가 필요해질 수 있습니다. 이때도 첫 선택은 “벡터 DB 설치”가 아니라 질문 유형·자료 규모·정확한 코드 검색 필요성·권한·최신성을 확인하는 일입니다. 자료가 몇 건뿐이고 직접 읽을 수 있다면 단순한 키워드 검색이나 명시적 문서 선택부터 시작할 수 있습니다. 그 결과로 원하는 문단을 못 찾을 때 임베딩·재순위화·청킹 전략을 추가하는 편이 원인을 설명하고 성능을 비교하기 쉽습니다.
8. RAG를 한 문장으로 다시 정리하면
RAG는 질문에 맞는 외부 자료를 먼저 찾고, 그 자료를 참고해 답을 생성하는 시스템 설계입니다. 청킹은 찾을 단위를 만들고, 임베딩과 벡터 검색은 후보를 찾는 방법 중 하나이며, 재순위화는 후보를 다시 고릅니다. 마지막의 검증은 답이 실제 출처와 적용 조건에 맞는지 확인하는 별도 단계입니다. “RAG라서 환각이 없다”는 결론은 성립하지 않습니다.
직접 설계할 때는 가상 정책 예시처럼 정답을 아는 질문 몇 개와 일부러 헷갈리는 문서를 먼저 준비해 보세요. 어느 단계에서 실패했는지 기록하면, 모델을 바꿔야 하는지, 청크를 다시 나눠야 하는지, 날짜 필터를 추가해야 하는지 구분할 수 있습니다. AI 공부 목록으로 돌아가기 →
확인한 원문: 2020년 RAG 논문 · Google Cloud RAG 단계와 구성 요소 · 문서 파싱과 청킹 · 검색 결과 재순위화 · 답변 근거 확인. 환불 정책 A·B는 설명용으로 만든 가상 자료입니다. 이 글은 검색·RAG를 설명한 학습 글이며 실제 벡터 검색 성능 시험 결과를 주장하지 않습니다.