환각을 잡는 가장 현실적인 방법, RAG 실전 구축 가이드

결론 3줄 요약

1. RAG는 LLM에게 정답지를 쥐여주는 기술입니다. 모델이 아는 척하며 지어내는 대신, 실제 문서를 찾아 근거로 답하게 만듭니다.
2. 성패는 화려한 모델이 아니라 검색 품질에서 갈립니다. 청킹, 임베딩, 벡터 DB라는 세 가지 기본기가 시스템의 수준을 결정합니다.
3. 거창한 인프라 없이도 시작할 수 있습니다. 작은 데이터셋과 오픈소스 도구만으로 충분히 쓸모 있는 사내 지식 검색 시스템을 만들 수 있습니다.

1. 서론: 똑똑한 AI가 왜 자꾸 거짓말을 할까?

안녕하세요, 10년 차 개발자입니다. 여러분도 한 번쯤 겪어보셨을 겁니다. LLM에게 회사 내부 규정이나 특정 제품 스펙을 물어봤더니, 너무나 자신감 넘치는 말투로 완전히 틀린 답을 내놓는 그 황당한 순간 말입니다. 우리는 이걸 환각(Hallucination)이라고 부르죠.

이게 왜 생길까요? LLM은 기본적으로 학습 시점까지의 지식만 가지고 있고, 그마저도 '가장 그럴듯한 다음 단어'를 확률적으로 이어 붙이는 방식으로 동작하기 때문입니다. 즉, 모르는 걸 모른다고 말하기보다 아는 척 채워 넣으려는 경향이 있습니다. 우리 회사 내부 문서를 학습한 적이 없으니 당연히 정확히 알 리가 없죠.

그래서 등장한 현실적인 해법이 바로 RAG(Retrieval-Augmented Generation), 검색 증강 생성입니다. 개념은 의외로 단순합니다. 시험을 볼 때 머릿속 기억만으로 답하는 폐쇄형 시험 대신, 관련 자료를 찾아보고 답하는 오픈북 시험으로 바꿔주는 것입니다. 오늘은 이 RAG를 어떻게 실제로 구축하는지, 현업 관점에서 차근차근 풀어보겠습니다.

2. 본론: RAG 파이프라인은 어떻게 동작하는가

RAG는 크게 두 단계로 나뉩니다. 미리 문서를 검색 가능한 형태로 저장해 두는 '준비 단계'와, 질문이 들어왔을 때 관련 문서를 찾아 답을 생성하는 '실행 단계'입니다. 하나씩 뜯어보겠습니다.

2.1. 청킹(Chunking): 문서를 어떻게 자를 것인가

가장 먼저 할 일은 우리가 가진 문서를 적당한 크기로 잘게 쪼개는 것입니다. 이걸 청킹이라고 부르는데요. 왜 통째로 안 쓰고 자를까요? LLM이 한 번에 처리할 수 있는 컨텍스트에는 한계가 있고, 검색 정확도를 높이려면 질문과 직접 관련된 부분만 콕 집어 가져와야 하기 때문입니다.

청킹은 RAG에서 의외로 가장 과소평가되는 단계입니다. 너무 잘게 자르면 문맥이 끊겨 의미를 잃고, 너무 크게 자르면 불필요한 내용까지 섞여 검색 정확도가 떨어집니다. 보통 수백 자 단위로 자르되, 청크 사이에 약간의 중복(overlap)을 두어 문맥이 갑자기 끊기지 않게 합니다. 문서의 성격에 따라 전략도 달라집니다. 기술 매뉴얼이라면 제목과 단락 구조를 따라 자르는 것이 좋고, 대화록이라면 발화 단위로 자르는 편이 자연스럽습니다.

2.2. 임베딩(Embedding)과 벡터 DB: 의미로 검색하기

청크를 다 만들었다면, 이제 각 청크를 숫자 벡터로 바꿔야 합니다. 이 과정을 임베딩이라고 합니다. 핵심은 '의미가 비슷한 문장은 벡터 공간에서도 가까이 위치한다'는 점입니다. 덕분에 사용자가 "환불 어떻게 해요?"라고 물으면, '반품 및 환불 정책'이라는 단어가 직접 안 들어 있어도 의미적으로 가까운 청크를 찾아낼 수 있습니다. 기존 키워드 검색이 못 하던 일이죠.

이렇게 만든 벡터들을 저장하고 빠르게 검색하는 곳이 벡터 DB입니다. 작게 시작한다면 메모리 기반의 가벼운 라이브러리로도 충분하고, 규모가 커지면 전용 벡터 데이터베이스를 도입하면 됩니다. 사용자의 질문도 똑같이 임베딩한 뒤, 벡터 공간에서 가장 가까운 청크 몇 개를 골라오는 것이 검색의 핵심 동작입니다.

2.3. 생성(Generation): 근거를 쥐여주고 답하게 하기

이제 마지막 단계입니다. 검색해 온 관련 청크들을 사용자 질문과 함께 프롬프트에 담아 LLM에게 건넵니다. "다음 자료를 근거로만 답하고, 자료에 없으면 모른다고 답해줘"라는 식의 지시를 함께 넣어주는 것이 중요합니다. 이렇게 하면 모델이 함부로 지어내는 일이 크게 줄어듭니다.

여기서 한 가지 팁을 드리자면, 답변과 함께 출처를 같이 보여주는 것이 좋습니다. "이 답변은 3번 문서에서 나왔습니다"처럼요. 사용자가 근거를 직접 확인할 수 있으니 신뢰도가 올라가고, 혹시 잘못된 답이 나와도 어디서 문제가 생겼는지 추적하기 쉬워집니다.

3. 현업에서 RAG를 잘 쓰는 노하우

이론은 단순하지만 막상 실무에 적용하면 생각만큼 답변이 똑똑하지 않은 경우가 많습니다. 제가 겪은 시행착오를 바탕으로 몇 가지 현실적인 조언을 드립니다.

첫째, 검색이 안 좋으면 모델을 아무리 좋은 걸 써도 소용없습니다. RAG에서 8할은 검색 품질이 좌우합니다. 답이 이상하면 모델을 바꾸기 전에 "이 질문에 대해 검색된 청크가 과연 적절한가?"부터 확인하는 습관을 들이세요. 둘째, 평가 체계를 갖추는 것이 중요합니다. 예상 질문과 정답 쌍을 미리 만들어 두고, 파이프라인을 바꿀 때마다 점수가 올랐는지 떨어졌는지 확인해야 감으로 튜닝하는 함정을 피할 수 있습니다. 셋째, 메타데이터를 적극 활용하세요. 문서의 작성일, 부서, 카테고리 같은 정보를 함께 저장해 두면, 검색할 때 "최신 문서만" 또는 "특정 부서 문서만" 같은 필터링이 가능해져 정확도가 한층 올라갑니다.

마지막으로, 완벽을 처음부터 노리지 마세요. RAG는 한 번에 완성되는 시스템이 아니라, 실제 사용자의 질문 로그를 보며 계속 다듬어 나가는 살아있는 시스템에 가깝습니다. 작게 시작해서 빠르게 개선하는 것이 정답입니다.

4. 결론: RAG는 AI를 신뢰할 수 있게 만드는 다리다

LLM은 분명 강력하지만, 그 자체로는 우리 조직의 사정을 전혀 모르는 외부인입니다. RAG는 그 똑똑한 외부인에게 우리만의 자료를 적시에 건네주어, 비로소 우리 일에 도움이 되는 동료로 만들어주는 기술입니다.

환각이라는 LLM의 고질적인 약점을 가장 현실적인 비용으로 잡는 방법이 바로 RAG라는 점은, 앞으로도 한동안 변하지 않을 것 같습니다. 거창한 인프라가 없어도 괜찮습니다. 작은 문서 묶음과 오픈소스 도구 몇 개로 오늘 당장 첫 RAG 파이프라인을 만들어 보세요. 검색이라는 기본기에 충실하다 보면, 어느새 환각 없이 근거를 대며 답하는 든든한 AI 비서를 손에 쥐게 될 겁니다.