RAG를 붙이기 전에: 정말 검색이 필요한 문제인가

RAG를 붙이기 전에 물어야 할 것

LLM에 회사 문서나 사용자 데이터를 물리려고 하면 RAG라는 단어부터 나옵니다. 문서를 쪼개고, 임베딩하고, 벡터 저장소를 세우고, 검색해서 프롬프트에 붙이는 구조입니다.

그런데 이 구조를 다 만들고 나서 "그냥 전부 넣었어도 됐는데"라는 걸 알게 되는 경우가 있습니다. RAG는 데이터가 컨텍스트에 안 들어갈 때 쓰는 우회로이지, AI에 데이터를 연결하는 기본 방법이 아닙니다.

먼저 재봐야 할 숫자

판단 기준은 단순합니다. 내 데이터 전체가 컨텍스트 윈도우에 들어가는가?

들어간다면 RAG가 필요 없습니다. 매 요청에 전부 넣으면 됩니다. 검색이 틀릴 일이 없으니 정확도는 오히려 더 높습니다.

기준은 토큰 수입니다. 문서를 모아 실제로 토큰을 세어보세요. 사내 위키 몇십 페이지, 제품 FAQ, 약관 정도는 생각보다 작습니다. 반대로 고객 문의 이력 수만 건이라면 명백히 안 들어갑니다.

다만 "들어간다"와 "넣는 게 좋다"는 다릅니다. 매 요청마다 비용이 붙고 응답도 느려집니다. 그래서 실제 판단은 세 갈래가 됩니다.

• 작고 거의 안 변함 → 프롬프트에 그대로 포함. 반복되는 앞부분 입력에 할인이 적용되는 제공자라면 비용도 크게 줄어듭니다.
• 중간 크기이고 질문마다 필요한 부분이 다름 → RAG가 값을 합니다.
• 정형 데이터 → 아래를 보세요.

정형 데이터라면 검색이 아니라 질의다

여기가 가장 자주 잘못 선택되는 지점입니다.

"지난달 매출 상위 5개 상품"을 묻는 기능을 RAG로 만들면 잘 안 됩니다. 매출 데이터를 문장으로 바꿔 임베딩해두고 유사도로 찾는 방식은 집계·정렬·필터에 맞지 않습니다. 벡터 검색은 "비슷한 것"을 찾지 "정확히 계산"하지 않습니다.

이런 데이터는 이미 데이터베이스에 있고, 필요한 건 질의입니다. LLM에게 자연어를 SQL로 바꾸게 하거나, 미리 만들어둔 조회 함수를 도구로 제공하는 편이 정확합니다.

비정형 텍스트(문서·매뉴얼·대화 기록)는 RAG, 표로 관리되는 데이터는 질의. 이 구분만 지켜도 큰 실패를 피합니다.

RAG가 실제로 필요한 조건

아래에 해당하면 RAG가 맞습니다.

• 문서량이 컨텍스트에 안 들어간다
• 질문마다 필요한 문서가 다르다
• 답변에 출처를 표시해야 한다
• 문서가 자주 바뀌어 모델을 다시 학습시킬 수 없다

세 번째가 의외로 중요합니다. 검색해서 넣으면 "이 답이 어느 문서에서 나왔는지"를 함께 보여줄 수 있습니다. 사용자가 확인할 수 있다는 점이 신뢰에 큰 차이를 만듭니다.

RAG의 실패는 대부분 검색 실패다

붙이고 나서 "답이 이상하다"는 문제가 생기면, 원인은 대개 생성이 아니라 검색입니다.

엉뚱한 문서를 가져오면 모델은 그 문서를 근거로 그럴듯한 답을 만듭니다. 모델 탓으로 보이지만 실제로는 검색 단계에서 이미 틀린 것입니다.

그래서 디버깅 순서가 정해져 있습니다.

1. 검색 결과를 눈으로 확인한다. 질문을 넣었을 때 어떤 조각이 올라오는지 로그에 남기세요. 이게 없으면 원인을 못 찾습니다.
2. 올바른 문서가 안 올라온다면 검색 문제입니다. 청킹, 임베딩 모델, 키워드 검색 병행을 손봅니다.
3. 올바른 문서가 올라왔는데 답이 틀리다면 그때가 프롬프트 문제입니다.

이 순서를 건너뛰고 프롬프트만 고치면 아무리 해도 나아지지 않습니다.

모르면 모른다고 하게 만들기

RAG에서 가장 위험한 실패는 관련 문서가 없는데 모델이 답을 지어내는 경우입니다.

두 가지를 함께 겁니다. 유사도 임계값을 두어 아무것도 안 걸리면 검색 결과를 비우고, 프롬프트에 근거 제한을 명시합니다.

아래 자료에 있는 내용만으로 답하라. 자료에 없으면 "자료에서 확인할 수 없습니다"라고 답하라. 추측하지 마라.

이 문장이 없으면 모델은 자기가 학습한 일반 지식으로 답을 채웁니다. 사내 규정을 묻는 질문에 일반적인 통념이 섞여 나오는 상황이 여기서 생깁니다.

만들기 전에 해볼 것

본격적으로 구축하기 전에 손으로 한 번 해보세요.

질문 하나를 고르고, 관련 문서를 직접 찾아서, 프롬프트에 붙여넣고, 원하는 답이 나오는지 봅니다. 여기서 답이 안 나오면 검색을 아무리 잘 만들어도 소용없습니다. 프롬프트나 문서 자체의 문제이기 때문입니다.

이 확인을 건너뛰고 파이프라인부터 만들면, 나중에 어느 단계가 문제인지 구분할 수 없게 됩니다.

파인튜닝과는 어떻게 다른가요?

RAG는 참고 자료를 그때그때 건네주는 것이고, 파인튜닝은 모델의 응답 방식 자체를 조정하는 것입니다. 사실 정보를 다루는 목적이라면 대체로 RAG가 맞습니다. 문서가 바뀌면 저장소만 갱신하면 되고, 출처도 보여줄 수 있기 때문입니다. 반대로 특정한 형식이나 말투를 일관되게 지켜야 하는 경우에는 파인튜닝이 더 맞습니다. 둘은 대체재가 아닙니다.

문서가 바뀌면 어떻게 반영하나요?

문서 단위로 갱신 시각을 기록해두고, 바뀐 문서의 조각만 다시 임베딩해 교체하는 방식이 일반적입니다. 전체를 매번 다시 만들면 비용과 시간이 커집니다. 그리고 삭제된 문서의 조각을 지우는 경로를 빠뜨리기 쉬운데, 이게 남아 있으면 없어진 규정이 계속 답변에 인용됩니다.

답변 품질을 어떻게 재나요?

질문과 기대 답변, 그리고 "어느 문서가 근거여야 하는가"를 묶은 평가 세트를 만들어두세요. 검색이 올바른 문서를 가져왔는지와 최종 답이 맞는지를 따로 재는 것이 핵심입니다. 합쳐서 재면 어느 단계를 고쳐야 할지 알 수 없습니다.

작게 시작해서 필요해지면 늘리기

문서 열 개로 시작해 프롬프트에 전부 넣어보고, 안 들어갈 만큼 커졌을 때 검색을 도입하는 순서가 낭비가 적습니다.

AI 기능이 들어간 프로젝트를 만들었다면 Vibeollio에 프로젝트 등록해서 공개해보세요. 실제 사용자 질문이 들어오기 시작하면, 어떤 질문이 검색에서 실패하는지가 구체적으로 드러납니다.