나는 최근 여러 기업의 LLM 도입 프로젝트를 지켜보며 한 가지 흥미로운 공통점을 발견했다. 프로토타입 단계에서는 놀라운 답변을 내놓던 RAG(검색 증강 생성) 시스템이, 실제 운영 환경에 배포되는 순간 갑자기 ‘엉뚱한 소리’를 하거나 답변의 품질이 급격히 떨어지는 현상이다. 단순히 벡터 데이터베이스에 문서를 밀어 넣는 것만으로는 해결되지 않는, 이른바 ‘엔지니어링의 늪’에 빠진 사례들이었다.
단순한 RAG가 프로덕션에서 무너지는 이유
많은 개발자가 RAG를 구현할 때 ‘문서 로드 → 청킹(Chunking) → 임베딩 → 벡터 DB 저장 → 유사도 검색 → 생성’이라는 기본 파이프라인만 구축한다. 하지만 실제 사용자의 질문은 정제되어 있지 않다. 사용자는 모호하게 질문하고, 기업의 내부 데이터는 복잡한 PDF 표나 깨진 텍스트, 중복된 정보로 가득 차 있다. 이 과정에서 검색 정보의 누락이나 부적절한 컨텍스트 주입이 발생하며 시스템은 신뢰도를 잃게 된다.
특히 가장 치명적인 것은 ‘환각(Hallucination)’ 문제다. LLM은 기본적으로 확률적인 다음 단어 예측 모델이기 때문에, 검색된 문서에 답이 없더라도 어떻게든 답을 만들어내려는 경향이 있다. 또한, 임베딩 모델의 토큰 제한으로 인해 문맥이 중간에 잘려나가면, LLM은 파편화된 정보만을 가지고 추론하게 되어 결국 잘못된 결론에 도달한다.
데이터 준비 단계의 정교한 설계
RAG의 성능은 생성 모델보다 데이터 준비 단계에서 결정된다. 단순히 고정 길이로 텍스트를 자르는 방식은 의미론적 단절을 야기한다. 문장 단위로 분리하거나, 의미적 일관성을 유지하는 전략적인 청킹이 필요하다. 또한, 파일 경로, 제목, 생성 날짜와 같은 메타데이터를 함께 저장해야 나중에 필터링을 통해 검색 정확도를 높일 수 있다.
실제로 LlamaIndex나 LangChain 같은 프레임워크를 사용할 때, 데이터 추출 단계에서 PDF의 표(Table)나 이미지 내 텍스트를 제대로 처리하지 못해 검색 품질이 떨어지는 경우가 많다. 이를 해결하기 위해 전처리 파이프라인에서 데이터를 정규화하고, 불필요한 노이즈를 제거하는 필터링 과정이 필수적이다.
데이터를 벡터 DB에 적재하기 위한 기본적인 파이썬 환경 설정과 라이브러리 설치 순서는 다음과 같다.
- 가상 환경을 생성하고 활성화한다.
- 필요한 핵심 라이브러리(LlamaIndex, ChromaDB 등)를 설치한다.
- 임베딩 모델(OpenAI 또는 HuggingFace)의 API 키를 환경 변수로 설정한다.
- 데이터 소스 경로를 지정하고 인덱싱을 수행한다.
# 필수 라이브러리 설치
pip install llama-index chromadb openai
# 환경 변수 설정 (Bash 기준)
export OPENAI_API_KEY="sk-your-api-key-here"
# 간단한 RAG 인덱싱 스크립트 예시
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
# './data' 폴더 내의 모든 문서를 로드하여 인덱싱
documents = SimpleDirectoryReader("./data").load_data()
index = VectorStoreIndex.from_documents(documents)
# 쿼리 엔진 생성 및 질문
query_engine = index.as_query_engine()
response = query_engine.query("회사 내 보안 규정 중 외부 협력사 관련 조항은 무엇인가요?")
print(response)검색 품질을 높이는 고급 전략: Query Transformation
사용자의 질문 하나만으로 벡터 검색을 수행하면, 질문의 단어와 문서의 단어가 일치하지 않을 때 검색에 실패할 확률이 높다. 이를 극복하기 위해 쿼리 변형(Query Transformation) 기법을 도입해야 한다. LLM을 이용해 사용자의 질문을 여러 개의 검색 쿼리로 확장하거나, 질문을 더 구체적인 형태로 재작성하는 방식이다.
예를 들어, “작년 성과 어땠어?”라는 질문을 “2023년도 분기별 매출 실적”, “2023년 주요 프로젝트 달성률”, “2023년 전년 대비 성장률”과 같이 세분화하여 검색하면, 훨씬 더 풍부한 컨텍스트를 확보할 수 있다. 이후 검색된 결과들을 다시 리랭킹(Re-ranking) 하여 가장 관련성이 높은 상위 K개의 문서만 LLM에 전달하는 과정이 추가되어야 한다.
# LLM을 이용한 쿼리 확장 프롬프트 예시
PROMPT_TEMPLATE = """
You are a helpful assistant that generates multiple search queries based on a single input query.
Generate 4 diverse search queries related to: {USER_INPUT}
OUTPUT (4 queries):
"""
# 실제 구현 시에는 이 템플릿을 LLM에 전달하여
# 생성된 4개의 쿼리로 각각 벡터 검색을 수행하고 결과를 합산(Aggregation)합니다.실무에서 마주치는 에러와 해결 팁
RAG 시스템을 운영하다 보면 RateLimitError나 ContextWindowExceeded 같은 에러를 자주 마주하게 된다. 특히 검색된 문서의 양이 너무 많아 LLM의 최대 토큰 길이를 초과하는 경우가 빈번하다. 이때 무작정 문서를 많이 넣기보다는, 리랭커(Re-ranker)를 도입해 정밀도를 높이고 입력 토큰 수를 최적화하는 것이 정답이다.
또한, 벡터 DB의 인덱스가 꼬이거나 데이터 업데이트 후 검색 결과에 즉시 반영되지 않는 동기화 문제가 발생할 수 있다. 이럴 때는 인덱스 재생성 전략을 세우거나, 메타데이터 필터링을 통해 특정 버전의 문서만 조회하도록 쿼리를 수정해야 한다. “검색 결과가 왜 이렇게 나오지?”라는 의문이 든다면, LLM의 답변을 보기 전에 먼저 검색된 원문(Retrieved Context)을 로그로 출력해 확인하는 습관을 들여야 한다. 답변의 문제는 대개 생성 단계가 아니라 검색 단계에서 이미 결정되어 있기 때문이다.
더 나은 시스템을 위해 고민할 점
결국 성공적인 RAG 시스템은 단순한 기술 스택의 조합이 아니라, 데이터의 특성을 얼마나 깊게 이해하고 파이프라인을 세밀하게 튜닝하느냐에 달려 있다. 100% 완벽한 정답률을 추구하는 학술적 접근보다는, 실제 사용자가 겪는 불편함을 기반으로 청킹 전략 수정 → 쿼리 확장 → 리랭킹 도입 순으로 점진적으로 개선하는 엔지니어링적 타협이 필요하다.
이제는 단순히 ‘답변이 잘 나온다’를 넘어, 어떻게 하면 정량적으로 RAG의 품질을 평가할 수 있을지 고민해 볼 때다. 여러분의 시스템에서는 검색 정확도(Recall)와 생성 정확도(Precision) 중 어디에서 더 많은 병목이 발생하고 있나요?