RAG를 도입하기 전 확인해야 할 5가지
RAG는 만능이 아닙니다. 도입 전에 답해야 할 5가지 질문이 있습니다. 이 질문에 답하지 않고 시작한 RAG 프로젝트는 거의 예외 없이 LLM이 엉뚱한 답을 한다는 결론으로 끝납니다.
요즘 거의 모든 AI 도입 문의에 RAG가 등장합니다. '사내 문서를 학습시켜서 질문하면 답하게 해주세요.' 익숙한 요청입니다.
문제는, RAG로 시작한 프로젝트의 상당수가 '써보니 LLM이 엉뚱한 답을 한다'는 결론으로 끝난다는 겁니다. 이유는 RAG가 어려워서가 아닙니다. RAG에 적합하지 않은 문제에 RAG를 적용해서입니다.
Plan AI는 RAG 프로젝트를 받기 전에 항상 5가지 질문을 먼저 합니다. 이 5개에 답이 안 나오면 RAG로 가지 말자고 권합니다.
1. 답해야 할 질문이 '검색'인가, '추론'인가?
가장 중요한 질문입니다.
RAG가 잘하는 건 '문서 어딘가에 답이 적혀 있는 질문'입니다. '휴가 정책이 뭐야?', '제품 A의 사양이 어떻게 돼?' 같은 검색형 질문.
RAG가 못하는 건 '여러 문서를 종합해서 새 결론을 내야 하는 질문'입니다. '지난 분기 매출 트렌드와 이번 마케팅 캠페인을 봤을 때 다음 분기에 뭘 해야 할까?' 같은 추론형 질문. 이건 RAG가 아니라 분석 시스템이 필요합니다.
도입 회의에서 자주 듣는 말이 '사내 데이터로 질문하면 다 답해주는 챗봇을 만들어주세요'입니다. 이 요청을 실제로 분석해보면 90%는 검색이지만 10%는 추론입니다. 그리고 사용자는 추론 질문을 했을 때 답이 틀리면 시스템 전체를 못 믿게 됩니다. 90%가 맞아도 10%에서 무너집니다.
해결: 도입 전에 사용자가 실제로 할 질문 30개를 모으세요. 검색형과 추론형을 분류하고, 추론형 비중이 20%를 넘으면 RAG만으로는 안 됩니다.
2. 원본 문서가 깨끗한가?
RAG의 성능은 LLM이 아니라 문서의 품질이 결정합니다. 이 사실을 가장 자주 잊습니다.
원본 문서가 다음 중 하나라도 해당되면 RAG는 시작 전부터 어렵습니다.
- 같은 정보가 여러 문서에 다른 버전으로 존재한다 (어느 게 최신인지 모름)
- 표·이미지·다이어그램에 핵심 정보가 들어있다 (텍스트 추출하면 손실)
- 문서가 회의록·메일 같은 흐름체라서 맥락 없이 한 조각만 보면 의미 불명
- 작성 시점이 적혀있지 않거나, 이미 폐기된 문서가 섞여 있다
RAG가 답을 찾는 단위는 문서 전체가 아니라 잘게 자른 조각입니다. 조각이 맥락 없이 모호하면 LLM은 그 모호함을 그대로 답합니다. '확실하지 않다'고 답하면 다행이고, 보통은 그럴듯하게 지어냅니다.
해결: RAG 시작 전에 핵심 정보가 들어있는 문서 20개를 추리고, 그중 절반 이상이 위 4개 항목 중 하나에 해당하면 먼저 문서 정비 프로젝트부터 합니다. RAG는 그 다음입니다.
3. '모른다'고 답할 수 있어야 하는가?
이 질문에 '그렇다'고 답하는 회사는 RAG가 적합합니다. '아니다, 무조건 답해야 한다'고 답하는 회사는 RAG가 위험합니다.
LLM은 기본적으로 답을 만들어내는 기계입니다. 모르는 걸 모른다고 말하는 것은 RAG가 잘하는 일이 아니라, 추가로 설계해야 하는 기능입니다. 검색 결과의 관련도가 낮으면 답하지 않도록 임계값을 설정하고, 인용한 문서를 같이 보여주고, 답할 수 없는 경우 사람에게 에스컬레이션하는 흐름까지 설계해야 합니다.
이 설계 없이 RAG를 만들면, 시스템은 모든 질문에 답을 합니다. 그중 일부는 틀린 답입니다. 사용자는 어느 답이 맞는지 모릅니다. 결국 시스템 전체를 안 씁니다.
해결: RAG 도입 전에 '답할 수 없는 질문에 어떻게 반응할 것인가'를 먼저 정의하세요. 이게 정의되지 않으면 RAG는 만들지 마세요.
4. 문서가 얼마나 자주 바뀌는가?
RAG는 검색 인덱스를 만듭니다. 원본 문서가 바뀌면 인덱스도 바뀌어야 합니다.
문서 변경 빈도가 낮다면 — 분기에 한 번 정도 — RAG 운영은 단순합니다. 인덱스를 주기적으로 다시 만들면 됩니다.
문서가 매일 바뀌는 회사라면 — 영업 자료, 제품 사양, 가격표 — 인덱스 동기화가 운영의 주요 업무가 됩니다. 동기화가 늦어지면 사용자는 옛날 답을 받습니다. 그리고 그게 옛날 답인지 사용자는 모릅니다.
해결: '이 시스템의 문서가 한 달에 몇 번 바뀌는가' 그리고 '변경 후 몇 시간 안에 시스템에 반영되어야 하는가'를 먼저 정하세요. 답이 '매일/즉시'라면, RAG보다 원본 시스템에 직접 질의하는 구조가 더 적합할 수 있습니다.
5. 평가 기준이 정의되어 있는가?
마지막 질문이자 가장 자주 빠지는 질문입니다.
RAG는 '잘 작동하는지' 판단이 어렵습니다. 어떤 답은 맞고 어떤 답은 그럴듯하지만 틀립니다. 시스템 전체의 정확도를 알려면 사람이 직접 채점한 데이터셋이 필요합니다.
평가셋이 없으면 RAG 개선은 '여기 고치면 저기 망가지는' 수렁에 빠집니다. 프롬프트를 한 줄 바꿨을 때 전체 정확도가 올라갔는지 떨어졌는지 아무도 모릅니다.
해결: 도입 전에 질문-정답 쌍 50개를 만드세요. 사용자가 실제로 할 만한 질문과 이상적인 답입니다. 이 50개로 매번 시스템 전체를 자동 평가합니다. 50개가 아깝다고 느껴진다면, 그 시스템은 운영할 자원이 부족한 시스템이라는 신호입니다.
정리
5가지 질문을 한 줄씩 다시 정리하면:
- 사용자가 할 질문은 검색인가, 추론인가?
- 원본 문서는 깨끗한가?
- '모른다'고 답할 수 있어야 하는가?
- 문서는 얼마나 자주 바뀌는가?
- 평가셋 50개가 준비되어 있는가?
이 5개에 답이 명확하면 RAG는 잘 작동합니다. 답이 흐릿한 항목이 2개 이상이면, RAG를 만들기 전에 그 항목부터 풀어야 합니다. 이 순서를 거꾸로 가면 시스템은 만들어지지만, 안 쓰이게 됩니다.
Plan AI가 RAG 프로젝트를 시작할 때 첫 주를 통째로 이 5가지 질문에 쓰는 이유입니다. 코드보다 이 합의가 훨씬 어렵고, 훨씬 중요합니다.