[AI] LangChain RAG 오류: 임베딩 문제와 해결 전략

목차

• 왜 LangChain RAG 오류가 임베딩 단계에서 자주 생길까요?
• LangChain RAG 오류를 이해하는 핵심 개념
• 임베딩 벡터 차원(Dimension, 벡터 길이)
• 청크 전략(Chunking Strategy, 문서 분할 방식)
• 검색 품질과 임베딩 모델 선택
• 실전 구현: 안정적인 LangChain RAG 기본 골격
• LangChain RAG 오류를 줄이는 검증 코드
• LangChain 임베딩 문제, 이런 식으로 터집니다
• 1. 임베딩 모델을 바꿨는데 기존 인덱스를 그대로 쓴 경우
• 2. 문서는 들어갔는데 검색이 너무 엉뚱한 경우
• 3. 임베딩 호출은 되는데 일부 문서가 빠지는 경우
• 4. 한국어 문서 검색이 유독 약한 경우
• 운영 관점에서 추천하는 LangChain RAG 오류 디버깅 체크리스트
• 검증 결과는 어떻게 봐야 할까요?
• 임베딩 모델 선택 시 현실적인 기준
• 정리: LangChain 임베딩 문제는 로그와 검증 루틴으로 잡아야 합니다
• 자주 묻는 질문
• Q1. 에러가 없는데도 답변 품질이 낮으면 어디부터 봐야 하나요?
• Q2. 벡터 저장소는 언제 다시 만들어야 하나요?
• Q3. RAG 디버깅에서 가장 먼저 자동화할 것은 뭔가요?

LangChain RAG 오류: 임베딩 문제와 해결 전략

LangChain RAG 오류를 처음 겪으면 꽤 당황스럽습니다. 문서는 분명 들어갔는데 검색 결과가 엉뚱하게 나오고, 어떤 날은 벡터 저장소에서 차원 불일치 에러가 터지고, 또 어떤 날은 임베딩 단계에서 조용히 일부 문서만 빠지기도 하거든요. 저도 문서 검색용 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 파이프라인을 여러 번 손보면서 같은 문제를 반복해서 봤는데, 막상 파고 들어가 보니 원인은 모델 하나가 아니라 문서 전처리, 청크(chunk, 문서 분할 단위), 메타데이터, 패키지 구성, 임베딩 모델 선택이 얽혀 있더라고요.

이번 글에서는 LangChain RAG 오류 중에서도 특히 자주 마주치는 LangChain 임베딩 문제를 중심으로, 실제 디버깅할 때 먼저 보는 체크포인트와 해결 전략을 정리해보겠습니다. 단순히 따라 하는 설정이 아니라 왜 이런 문제가 생기는지까지 같이 보면, 이후 LLM 애플리케이션 개발에서도 훨씬 덜 헤매게 됩니다.

문서 로더, 텍스트 분할기, 임베딩 모델, 벡터 저장소, 검색기, LLM 응답 생성까지 이어지는 흐름과 오류가 자주 발생하는 지점을 설명하는 이미지입니다.

왜 LangChain RAG 오류가 임베딩 단계에서 자주 생길까요?

쉽게 말해 임베딩(Embedding, 텍스트를 숫자 벡터로 바꾸는 과정)은 RAG의 바닥 공사입니다. 여기서 조금만 어긋나도 이후 검색 품질이 크게 흔들립니다. 생성 모델은 멀쩡한데 답변이 이상한 경우, 의외로 원인은 검색 단계 이전인 임베딩 쪽에 있는 경우가 많더라고요.

제가 직접 겪어보니 특히 아래 네 가지가 반복적으로 문제를 만들었습니다.

• 임베딩 모델을 바꿨는데 기존 벡터 저장소를 그대로 재사용한 경우
• 문서 청크가 비어 있거나 너무 짧거나 너무 긴 경우
• 질문과 문서의 언어 특성이 다른데 모델 특성을 고려하지 않은 경우
• 배치 처리(batch processing)와 API 제한 때문에 중간에 누락이 생기는 경우

여기서 중요한 포인트가 하나 있습니다. 오류가 눈에 보이게 터지면 오히려 낫습니다. 진짜 까다로운 건 에러 없이 검색 품질만 나빠지는 상황입니다. 이건 로그만 봐서는 잘 안 보여서, 검증 루틴을 따로 만들어두는 게 진짜 편하더라고요.

LangChain RAG 오류를 이해하는 핵심 개념

임베딩 벡터 차원(Dimension, 벡터 길이)

각 임베딩 모델은 고정된 형태의 벡터를 만듭니다. 벡터 저장소는 이 차원 정보를 기준으로 데이터를 저장하는데, 나중에 다른 임베딩 모델로 바꾸면서 기존 인덱스를 그대로 읽어오면 차원 불일치가 발생할 수 있습니다. 같은 텍스트라도 숫자 표현 방식 자체가 다르기 때문에, 서로 다른 모델에서 만든 벡터를 같은 인덱스에 섞어 쓰면 안 됩니다.

청크 전략(Chunking Strategy, 문서 분할 방식)

RAG 디버깅을 하다 보면 임베딩 모델보다 청크 전략이 더 큰 영향을 주는 경우가 많습니다. 문서를 너무 크게 자르면 검색 결과가 뭉뚱그려지고, 너무 잘게 자르면 문맥이 끊깁니다. 특히 FAQ, 기술 문서, 설정 가이드처럼 구조가 뚜렷한 문서는 헤더 기준 분할이 꽤 중요합니다.

검색 품질과 임베딩 모델 선택

임베딩 모델 선택은 단순히 성능 좋은 모델을 고르는 문제가 아닙니다. 문서 언어, 도메인, 비용, 지연 시간, 운영 방식까지 같이 봐야 합니다. 예를 들어 한국어 문서 비중이 높은데 영어 중심 평가만 믿고 가면 검색 적중률이 기대보다 낮게 나올 수 있습니다. 반대로 내부 문서가 짧은 영어 설정 파일 위주라면 과한 모델이 꼭 필요한 것도 아니고요.

실전 구현: 안정적인 LangChain RAG 기본 골격

아래 예시는 가장 기본적인 구조입니다. 현재 LangChain 생태계는 패키지가 분리되어 있어서, 문서 로더는 <code>langchain-community, OpenAI 임베딩은 langchain-openai, 텍스트 분할기는 langchain-text-splitters를 함께 설치하는 쪽이 안전합니다. 핵심 흐름은 문서를 읽고, 청크를 만들고, 임베딩한 뒤, 벡터 저장소에 넣고, 검색기로 바로 검증하는 겁니다.

1. 문서를 로드합니다.
2. 청크 크기와 겹침(overlap)을 정합니다.
3. 임베딩 모델명을 명시적으로 고정합니다.
4. 벡터 저장소를 새로 생성하거나, 메타데이터와 함께 관리합니다.
5. 질문 샘플로 검색 결과를 직접 검증합니다.

python -m venv .venv
source .venv/bin/activate
pip install -U langchain langchain-community langchain-openai langchain-text-splitters faiss-cpu pypdf

환경 변수도 먼저 분리해두는 게 좋습니다. 운영하다 보면 테스트 키와 운영 키가 섞여서 엉뚱한 장애를 만들기도 하거든요.

export OPENAI_API_KEY="your_api_key"
export SOURCE_DOCS_DIR="./docs"
export VECTOR_DIR="./vector_store"

이 코드는 PDF 문서를 로드해 청크를 나누고, 빈 청크를 제거한 뒤, 임베딩을 생성해 FAISS 인덱스로 저장하는 예시입니다. 실무에서는 OpenAIEmbeddings()를 기본값으로 두기보다 모델명을 명시해두는 편이 추적하기 쉽습니다.

import os
from pathlib import Path

from langchain_community.document_loaders import PyPDFDirectoryLoader
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter

DOCS_DIR = Path(os.environ.get("SOURCE_DOCS_DIR", "./docs"))
VECTOR_DIR = os.environ.get("VECTOR_DIR", "./vector_store")

loader = PyPDFDirectoryLoader(str(DOCS_DIR))
docs = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=120,
    separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = splitter.split_documents(docs)
chunks = [chunk for chunk in chunks if chunk.page_content and chunk.page_content.strip()]

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = FAISS.from_documents(chunks, embeddings)
vectorstore.save_local(VECTOR_DIR)

print(f"documents={len(docs)}")
print(f"chunks={len(chunks)}")

여기서 제가 꼭 넣는 줄이 있습니다. 바로 빈 청크 제거입니다. 이거 하나만 넣어도 나중에 검색 이상 현상이 생겼을 때 원인 추적이 훨씬 쉬워집니다.

실전 구현 단계에서 어떤 순서로 데이터가 이동하는지, 그리고 어느 단계에서 검증 로그를 남겨야 하는지 시각적으로 보여주는 이미지입니다.

LangChain RAG 오류를 줄이는 검증 코드

RAG 디버깅은 "만들었다"로 끝나지 않습니다. 인덱스를 만든 직후 검색 결과를 바로 확인해야 합니다. 저는 보통 아래처럼 샘플 질의를 몇 개 정해서 바로 돌려봅니다.

한 가지 주의할 점도 있습니다. FAISS.load_local(..., allow_dangerous_deserialization=True)는 로컬에 저장한 신뢰 가능한 인덱스를 다시 읽을 때만 쓰는 옵션입니다. 외부에서 받은 인덱스 파일에 이 옵션을 켜는 건 위험합니다.

from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = FAISS.load_local(
    "./vector_store",
    embeddings,
    allow_dangerous_deserialization=True
)

queries = [
    "이 문서는 어떤 시스템 구성에 대한 설명인가?",
    "장애 대응 절차는 어떻게 정리되어 있나?",
    "설정 파일 경로와 관련된 설명을 찾아줘"
]

for query in queries:
    print(f"\n[QUERY] {query}")
    results = vectorstore.similarity_search(query, k=3)
    for idx, doc in enumerate(results, start=1):
        preview = doc.page_content[:180].replace("\n", " ")
        print(f"{idx}. {preview}")

이 검증을 해보면 생각보다 빨리 감이 옵니다. 질문은 맞는데 본문 일부가 계속 헛나오면 청크 문제일 가능성이 높고, 전혀 다른 문서가 튀어나오면 임베딩 모델 적합성이나 메타데이터 필터 조건을 먼저 의심해보면 됩니다.

LangChain 임베딩 문제, 이런 식으로 터집니다

이 섹션이 핵심입니다. 실제로 많이 마주치는 증상과 원인을 표로 먼저 정리해보겠습니다.

증상	가능한 원인	우선 조치
차원 불일치 오류	기존 인덱스를 다른 임베딩 모델로 재사용	벡터 저장소를 새로 생성
에러는 없는데 검색 품질이 낮음	청크 전략 부적절, 언어 특성 불일치	청크 크기/겹침 조정, 샘플 질의 검증
임베딩 중간 실패 또는 누락	배치 크기 과다, API 제한, 재시도 부족	배치 축소, 로깅 추가, 재시도 적용
유사도 검색 결과가 비어 있음	문서 로드 실패, 빈 청크 저장	문서 수와 청크 수를 먼저 출력

1. 임베딩 모델을 바꿨는데 기존 인덱스를 그대로 쓴 경우

이건 정말 자주 나옵니다. 테스트 단계에서는 모델을 자주 바꿔보게 되거든요. 그런데 FAISS 같은 벡터 저장소는 기존 벡터 차원을 기준으로 인덱스를 유지하므로, 모델을 바꿨다면 거의 항상 재생성이 안전합니다.

해결 전략은 단순합니다. 벡터 저장소 디렉터리에 메타 파일을 두고, 어떤 임베딩 모델과 청크 설정으로 생성했는지 기록하세요.

import json
from pathlib import Path

meta = {
    "embedding_provider": "openai",
    "embedding_model": "text-embedding-3-large",
    "chunk_size": 800,
    "chunk_overlap": 120,
}

Path("./vector_store").mkdir(exist_ok=True)
Path("./vector_store/index_meta.json").write_text(
    json.dumps(meta, ensure_ascii=False, indent=2),
    encoding="utf-8"
)

2. 문서는 들어갔는데 검색이 너무 엉뚱한 경우

처음엔 이게 뭔가 싶었는데, 실제로는 청크 설계 문제가 원인인 경우가 많았습니다. 설정 문서와 장애 대응 문서를 한 덩어리로 넣으면 질문 의도와 상관없이 공통 단어에 끌려가더라고요. 특히 한국어 문서는 줄바꿈, 제목, 코드 블록이 의미 단위를 나누는 데 중요해서, 무작정 문자 수만 기준으로 자르면 손해를 보기 쉽습니다.

해결 전략은 아래 순서로 잡으면 편합니다.

• 문서 유형별로 분리합니다. 예: 매뉴얼, 장애일지, 설정 예제
• 헤더 단위 분할을 우선 고려합니다.
• 청크 미리보기 로그를 남깁니다.
• 질문 5개 정도를 고정해 회귀 테스트처럼 돌립니다.

3. 임베딩 호출은 되는데 일부 문서가 빠지는 경우

이건 조용히 지나가는 경우가 있어서 더 위험합니다. 배치 처리 중 일부 실패, 비정상 문서 인코딩, 너무 긴 텍스트 같은 이유로 누락될 수 있습니다. 저도 나중에 청크 개수와 저장 결과를 대조하다가 발견한 적이 있었는데, 그때 로그가 없었으면 원인 찾는 데 훨씬 오래 걸렸을 겁니다.

해결 전략은 임베딩 전후 카운트를 반드시 비교하는 겁니다.

expected_chunks = len(chunks)
vectorstore = FAISS.from_documents(chunks, embeddings)

print(f"expected_chunks={expected_chunks}")
print("index build completed")

단순해 보여도 이 출력 하나가 삽질 시간을 꽤 줄여줍니다.

4. 한국어 문서 검색이 유독 약한 경우

여기서는 문서와 질문의 언어 분포를 먼저 봐야 합니다. 내부 문서는 한국어인데 질의 테스트를 영어 예문으로만 돌리면 평가가 왜곡됩니다. 반대로 영어 설정 파일을 한국어로만 묻는 상황도 마찬가지고요. 결국 임베딩 모델 선택은 데이터 특성과 함께 봐야 합니다.

저는 보통 아래 기준으로 판단합니다.

• 문서 언어가 한국어 중심인지
• 질의 언어가 문서와 같은지
• 코드, 로그, 설정 키가 많은지
• 짧은 답을 찾는지, 긴 문맥을 찾는지

실무에서 자주 겪는 임베딩 오류 유형과 각각의 원인, 우선 확인해야 할 체크포인트를 한눈에 정리한 이미지입니다.

운영 관점에서 추천하는 LangChain RAG 오류 디버깅 체크리스트

RAG 디버깅은 감으로 하면 오래 갑니다. 체크리스트로 고정해두면 훨씬 수월합니다.

1. 문서 수와 청크 수를 출력합니다.
2. 청크 샘플 3~5개를 직접 눈으로 봅니다.
3. 사용한 임베딩 모델 정보와 청크 설정을 메타데이터로 남깁니다.
4. 인덱스 생성 직후 고정 질의 세트를 돌립니다.
5. 검색 결과 상위 3개를 로그로 저장합니다.
6. 임베딩 모델 변경 시 기존 인덱스를 재사용하지 않습니다.
7. 문서 인코딩과 특수문자 깨짐 여부를 확인합니다.

이 정도만 지켜도 대부분의 LangChain RAG 오류는 꽤 빨리 좁혀집니다. 특히 4번과 5번은 꼭 해보세요. 검색 결과를 눈으로 안 보면, 문제를 LLM 탓으로 착각하기 쉽습니다.

검증 결과는 어떻게 봐야 할까요?

검증 단계에서는 정답 문장 하나를 맞췄는지보다, 관련 있는 문서를 안정적으로 가져오느냐를 먼저 봐야 합니다. RAG는 1차 검색이 맞아야 2차 생성도 좋아집니다. 저는 보통 아래 기준으로 확인합니다.

• 같은 질문을 여러 번 해도 상위 결과가 크게 흔들리지 않는지
• 문서 제목 또는 섹션 단위로 관련성이 보이는지
• 질문 표현을 조금 바꿔도 비슷한 결과가 나오는지
• 한국어 질의와 영어 키워드 혼합 질의에서 성능 차이가 과한지

상위 3개 문서가 납득 가능한 수준으로 꾸준히 나오기 시작하면, 그다음부터는 프롬프트(prompt, 모델 지시문) 튜닝으로 넘어가면 됩니다. 이 지점이 오면 한숨 돌려도 됩니다. 이거 진짜 체감이 확 오더라고요.

샘플 질의를 기준으로 검색 결과의 일관성과 관련성을 확인하는 검증 화면을 표현한 이미지입니다.

임베딩 모델 선택 시 현실적인 기준

모델 이름만 비교하면 판단이 오히려 어려워집니다. 운영 조건까지 같이 적어두면 의사결정이 훨씬 쉬워집니다.

기준	질문	판단 포인트
언어	한국어 문서 비중이 높은가?	다국어 대응 여부를 우선 확인
문서 형태	코드/로그/설정 파일이 많은가?	토큰 분포와 특수문자 처리 성향 확인
운영 비용	대량 재색인이 자주 필요한가?	배치 처리 비용과 속도 고려
지연 시간	실시간 임베딩이 필요한가?	오프라인 색인과 온라인 질의 경로 분리

모델을 바꾸면 다 해결될 줄 알았는데, 실제 원인은 청크 설정이었던 경우가 생각보다 많습니다. 저도 처음엔 모델만 계속 갈아타다가 시간을 꽤 썼습니다. 운영에서는 좋은 모델 하나보다 일관된 파이프라인이 더 중요하더라고요.

이전 글에서 다룬 문서 청크 설계 글도 함께 읽어보시면 흐름이 더 잘 잡힙니다. 내부 링크를 걸어두면 독자 입장에서도 다음 액션이 분명해서 체류 시간 관리에 도움이 됩니다.

정리: LangChain 임베딩 문제는 로그와 검증 루틴으로 잡아야 합니다

오늘 내용만 딱 정리하면 이렇습니다.

• 차원 불일치가 보이면 임베딩 모델 변경 여부부터 확인합니다.
• 검색 품질 저하는 청크 전략과 문서 구조를 먼저 봅니다.
• 조용한 실패를 막으려면 문서 수, 청크 수, 샘플 질의 결과를 반드시 기록합니다.
• 임베딩 모델 선택은 언어, 문서 유형, 운영 비용까지 같이 판단합니다.

다음 글에서는 RAG 디버깅을 좀 더 확장해서, 재순위화(Reranking, 검색 결과 재정렬)와 하이브리드 검색(Hybrid Search, 키워드+벡터 검색 결합) 기준도 다뤄볼 예정입니다. 이전 글의 문서 청크 설계 내용과 함께 보면 이해가 더 빨라집니다.

문서 로딩, 청크 분할, 임베딩 생성, 인덱스 재생성, 검색 검증까지의 해결 흐름을 한 장으로 요약한 이미지입니다.

자주 묻는 질문

Q1. 에러가 없는데도 답변 품질이 낮으면 어디부터 봐야 하나요?

A. LLM보다 먼저 검색 결과를 보셔야 합니다. 상위 문서 3개가 질문과 관련이 없으면, 거의 항상 임베딩이나 청크 쪽 문제입니다.

Q2. 벡터 저장소는 언제 다시 만들어야 하나요?

A. 임베딩 모델을 바꿨거나, 청크 전략을 크게 바꿨거나, 문서 구조가 크게 바뀌었다면 재생성이 안전합니다.

Q3. RAG 디버깅에서 가장 먼저 자동화할 것은 뭔가요?

A. 고정 질의 세트 기반의 회귀 테스트입니다. 같은 질문에 대한 검색 결과를 저장해두면 변경 영향이 바로 보입니다.

📚 함께 읽으면 좋은 글

• Ollama 비용 비교: 로컬 AI vs 클라우드 API 실측 분석
• LlamaIndex RAG 시스템 구축 실패 사례: 흔한 문제와 디버깅 전략
• AI API 비용 절감 전략: GPT-4o vs Claude Sonnet vs Gemini Pro 비교 분석