RAG 성능을 2배 높이는 프롬프트 엔지니어링과 데이터 전처리 기법

시작하며: "문서는 다 넣었는데, 왜 AI는 자꾸 엉뚱한 소리를 할까요?"

많은 팀이 RAG(Retrieval-Augmented Generation) 시스템을 구축할 때 가장 먼저 하는 일은 PDF나 위키 문서를 벡터 DB에 쏟아붓는 것입니다. 하지만 결과는 실망스럽기 일쑤입니다. 분명히 문서에 있는 내용인데도 "관련 정보를 찾을 수 없다"고 답하거나, 엉뚱한 문단을 참조해 거짓 정보를 만들어내기도 합니다.

이런 현상이 발생하는 이유는 AI 모델의 지능이 부족해서가 아니라, AI가 읽기 좋은 형태로 데이터를 떠먹여 주지 않았기 때문입니다. RAG 성능의 80%는 모델이 아니라 '검색된 컨텍스트의 품질'과 그 컨텍스트를 요리하는 '프롬프트'에서 결정됩니다. 본 가이드에서는 현장에서 즉시 적용 가능한 데이터 전처리 루틴과 프롬프트 최적화 기법을 4단계로 나누어 설명합니다.

왜 RAG 성능이 안 나오나: 실패 패턴 3가지

1. '무지성' 문단 나누기 (Fixed-size Chunking)

단순히 500자씩 기계적으로 문서를 자르면, 문장의 허리가 끊기거나 핵심 맥락이 다음 덩어리(Chunk)로 넘어가 버립니다. 검색 시 반쪽짜리 정보만 가져오게 되어 답변 품질이 급락합니다.

2. 노이즈 섞인 원문 그대로 사용

PDF의 페이지 번호, 머리말, 꼬리말, 표 형식의 깨진 텍스트 등이 그대로 포함되면 벡터 유사도 계산 시 방해 요소로 작용합니다. AI는 이 '쓰레기 데이터'까지 중요한 정보로 착각하여 답변에 섞어버립니다.

3. 방관형 프롬프트 ("다음 내용을 참고해서 답해줘")

검색된 내용이 질문과 직접적인 관련이 없을 때, AI에게 거절할 권한을 주지 않으면 어떻게든 답변을 지어내려 합니다(Hallucination). 명확한 가이드라인 없는 프롬프트는 거짓 답변의 일등 공신입니다.

실무 체크리스트: 도입 전에 고정할 항목

문서 포맷 표준화: 마크다운(Markdown) 형식을 기본으로 사용 (구조 파악에 용이)
청크 크기(Chunk Size): 도메인 용어의 길이를 고려하여 300~800 토큰 사이에서 실험
중첩(Overlap) 비율: 문맥 유지를 위해 청크 간 10~20% 영역을 겹치게 설정
임베딩 모델 선택: 다국어 지원이 강력한 모델(예: BGE-M3) 우선 검토
평가 데이터셋: 정답이 명확한 질문-답변 세트 50개를 먼저 확보

1단계: 시맨틱 청킹(Semantic Chunking) 적용

단순 글자 수가 아니라 '의미 단위'로 문서를 나눕니다. 마크다운의 헤더(#, ##)나 재귀적 텍스트 분할기(RecursiveCharacterTextSplitter)를 사용하여 문장의 마침표나 줄바꿈 단위로 자르는 것이 기본입니다.

산출물: 문맥이 끊기지 않은 고품질 텍스트 덩어리(Chunks)

2단계: 메타데이터 강화 및 필터링

각 청크에 문서 제목, 생성 날짜, 카테고리, 그리고 필요하다면 해당 청크를 요약한 한 문장을 메타데이터로 추가합니다. 검색 시 유사도뿐만 아니라 카테고리 필터링을 병행하면 정확도가 비약적으로 상승합니다.

산출물: 필터링 가능한 속성이 부여된 벡터 데이터

3단계: 컨텍스트 재구성 프롬프트 설계

검색된 여러 개의 청크를 단순히 나열하지 말고, AI에게 "질문과 관련 없는 내용은 무시하라"는 강력한 지침을 줍니다. 또한 답변의 출처(Source)를 반드시 명시하도록 강제합니다.

산출물: 답변의 근거가 명확히 표시된 고신뢰도 프롬프트 템플릿

4단계: 리랭킹(Re-ranking) 프로세스 추가

1차로 벡터 검색을 통해 10~~20개의 후보를 뽑은 뒤, '리랭커(Re-ranker)' 모델을 통과시켜 질문과 가장 밀접한 3~~5개만 최종 프롬프트에 넣습니다. 이 단계 하나만으로도 답변 정확도가 30% 이상 개선됩니다.

평가 기준: 리랭킹 전후의 답변 일치도(Recall@K) 비교

편집자의 시선: "데이터 청소는 한 번으로 끝나지 않습니다"

현장에서 본 가장 큰 실수는 RAG를 '한 번 구축하면 끝나는 시스템'으로 생각하는 것입니다. 사용자의 질문은 계속 변하고, 문서도 업데이트됩니다. 성공적인 RAG 운영팀은 매주 '검색에 실패한 질문' 리스트를 뽑아 그 질문이 왜 실패했는지(데이터가 없는지, 검색이 안 됐는지, 모델이 이해를 못 했는지) 분석하고 전처리 로직을 수정합니다. 기술적인 화려함보다 지루한 '데이터 정제 루틴'이 좋은 AI를 만듭니다.

실전 사례: 사내 인사 규정 챗봇 개선

상황

"복지 포인트 사용처 알려줘"라고 물으면 연봉 규정이나 퇴직금 규정이 섞여서 나와 답변이 혼란스러웠습니다.

적용 방법

모든 PDF를 마크다운으로 변환하여 표 구조 유지.
청킹 시 '카테고리: 복지' 메타데이터 강제 부여.
프롬프트에 "제공된 컨텍스트에 답변이 없으면 모른다고 답하고, 인사팀 내선번호(1234)를 안내하라"는 가드레일 추가.

결과

답변 정확도(정답 매칭률)가 65%에서 92%로 상승했습니다. 특히 엉뚱한 정보가 섞이는 현상이 사라졌습니다.

교훈

검색 범위를 좁혀주는 메타데이터와 '모를 땐 모른다고 하기' 지침이 사용자 신뢰도를 높이는 데 결정적이었습니다.

핵심 실행 요약

항목	실행 기준
전처리 방식	마크다운 기반 재귀적 분할 (Recursive Splitting)
메타데이터	제목, 카테고리, 청크 요약본 포함
프롬프트 지침	"관련 없는 정보 무시", "근거 문서 번호 기재" 필수
검색 최적화	벡터 검색(Hybrid) + 리랭킹(Re-ranking) 조합
품질 유지	매주 실패 질문 20건 분석 및 큐레이션(Data Curation)

자주 묻는 질문(FAQ)

Q1. 청크 크기를 크게 가져가면 정보 유실이 적지 않을까요?▾

청크가 너무 크면 질문과 상관없는 노이즈가 많이 포함되어 모델이 집중력을 잃습니다. 또한 프롬프트가 길어져 비용이 늘어납니다. 정보 유실은 '중첩(Overlap)'과 '시맨틱 청킹'으로 해결하는 것이 정석입니다.

Q2. 한국어 RAG에서 가장 주의할 점은 무엇인가요?▾

조사와 어미 변화가 심한 한국어 특성상, 단순 키워드 검색보다는 의미 기반의 임베딩 검색이 유리합니다. 다만, 고유명사나 전문 용어(예: 제품명)는 벡터 검색이 놓칠 수 있으므로 키워드 검색과 벡터 검색을 섞은 '하이브리드 검색'을 권장합니다.

Q3. 리랭킹 모델은 꼭 유료 모델을 써야 하나요?▾

아니요. BGE-Reranker 같은 우수한 오픈소스 모델이 많습니다. 로컬 서버에 직접 구동하면 비용 부담 없이 성능을 크게 높일 수 있습니다.