LangChain으로 RAG 파이프라인 만들기 — chunk_size가 지켜지지 않는 이유

chunk_size=500을 주면 청크가 500자로 나온다고 생각하기 쉽다. 실제로 논문 PDF 한 편을 CharacterTextSplitter로 자르면 2,191자에서 6,130자짜리 청크가 나온다. 파라미터를 줬다고 지켜지는 것이 아니다.

이 글은 그런 지점들을 코드와 실측값으로 확인하며 RAG 파이프라인을 조립한다. Load → Split → Embed → Store → Generate를 따라가고, 마지막에 이 직선 파이프라인이 왜 부족한지를 여섯 가지 한계로 정리한다. 앞 편에서 본 구성요소와 LCEL이 여기서 실제 도면이 된다.

용어 정리

앞 편의 용어에 이 편이 쓰는 것을 더했다.

두 국면 — 미리 하는 일과 매번 하는 일

도식은 데이터가 어떤 형태로 변해 가는지를 보여준다. 문서가 Chunk가 되고, Chunk가 벡터가 되고, 벡터가 벡터DB에 앉는다. 같은 파이프라인을 "무엇을 하는가"의 관점에서 여덟 단계로 펼친 것이 RAG 파이프라인 8단계이고, 단계별 선택지와 실패 모드는 그쪽에 정리돼 있다.

여기서 필요한 것은 하나 더 있다. 각 단계에 LangChain의 어느 구성요소가 붙는가다.

이 표가 무기인 이유는 비용과 지연이 어디서 갈리는지를 보여주기 때문이다. 임베딩 비용은 문서 수에 비례해 한 번 나가고, 검색·생성 비용은 트래픽에 비례해 계속 나간다.

RAG를 "검색해서 붙이는 것"이라고만 설명하면 이 선이 안 보인다. 임베딩 모델을 바꾸는 결정과 top-k를 바꾸는 결정은 비용 구조가 완전히 다른 결정이다.

Load — Document Loaders

from langchain_community.document_loaders import PyPDFLoader

loader = PyPDFLoader("data/Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.pdf")
pages = loader.load_and_split()      # 페이지 단위로 Document 리스트 생성

pages[0]
# -> Document(metadata={'source': '...pdf', 'page': 0}, page_content='Retrieval-Augmented ...')

모든 로더의 산출물은 동일하게 **Document(page_content, metadata)**다. metadata에 source와 page가 들어가는데, 이것이 나중에 **출처 표기(citation)**의 근거가 된다.

웹 로더 — 필요한 영역만 긁는다

import bs4
from langchain_community.document_loaders import WebBaseLoader

# 그냥 로드하면 헤더·푸터·광고까지 통째로 들어온다
loader = WebBaseLoader("https://www.espn.com/")

# bs4 SoupStrainer로 원하는 CSS 클래스만 파싱 -> 노이즈 제거
loader = WebBaseLoader(
    "https://www.espn.com/",
    bs_kwargs=dict(parse_only=bs4.SoupStrainer(class_=("headlineStack top-headlines"))),
)
loader.requests_kwargs = {"verify": False}   # SSL 검증 우회 (로컬 확인용. 운영에서는 쓰지 말 것)
data = loader.load()

필터 없이 로드한 스포츠 뉴스 페이지에는 메뉴·"Skip to main content"·푸터 링크가 본문과 뒤섞여 들어온다. 이 쓰레기가 그대로 청킹·임베딩되면 검색 결과에 계속 딸려 나온다.

RAG 품질의 절반은 검색 알고리즘이 아니라 로더 단계의 정제에서 결정된다. "RAG 정확도를 어떻게 올리나"라는 질문에 리랭커부터 답하는 것은 순서가 틀렸다.

리랭커는 검색된 후보를 재정렬하는 장치라, 애초에 색인에 들어간 노이즈는 재정렬로 사라지지 않는다. 색인에 들어가지 말았어야 할 것은 색인 이전에 막는 편이 압도적으로 싸다.

Split — 청킹 전략

같은 chunk_size=500, 완전히 다른 결과

from langchain_text_splitters import CharacterTextSplitter

text_splitter = CharacterTextSplitter(
    # separator="\n",        # 주석 처리됨 -> 기본 구분자 "\n\n" 사용
    chunk_size=500,
    chunk_overlap=100,
    length_function=len,
)
texts = text_splitter.split_documents(pages)
print([len(i.page_content) for i in texts])
# -> [2191, 5185, 4423, 3625, 5008, 3526, 3075, 4740, ... 6130 ...]   500을 한참 초과!

from langchain_text_splitters import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=100,
    length_function=len,
    is_separator_regex=False,
)
texts = text_splitter.split_documents(pages)
print([len(i.page_content) for i in texts])
# -> [441, 439, 498, 420, 473, 275, 406, ... 44, ... 499]   전부 500 이하

왜 이런 일이 벌어지나. CharacterTextSplitter는 구분자 하나(기본 "\n\n")로만 자른다. 논문 PDF는 문단 사이 빈 줄이 드물어 구분자가 거의 안 나타나고, 그러면 자를 자리가 없어 chunk_size를 초과한 덩어리가 그대로 남는다.

RecursiveCharacterTextSplitter는 구분자 목록 ["\n\n", "\n", " ", ""]을 위에서부터 재귀적으로 시도한다. 문단으로 안 되면 줄, 줄로 안 되면 공백, 그래도 안 되면 글자 단위로 쪼갠다. 그래서 항상 상한을 지킨다.

chunk_size는 상한이 아니라 목표치다. 구분자가 없으면 지켜지지 않는다.

그래서 특별한 이유가 없으면 RecursiveCharacterTextSplitter가 기본값이고, 청킹 결과는 반드시 길이 분포를 찍어서 눈으로 확인해야 한다. 이 실측이 주는 교훈은 스플리터 선택이 아니라 검증 습관 쪽이다.

chunk_overlap은 왜 필요한가

경계에서 문장이 잘리면 그 문장이 담고 있던 의미가 두 청크 어디에도 온전히 남지 않는다. 앞 청크의 끝 N자를 다음 청크 앞에 겹쳐 넣어(overlap) 경계 손실을 완화한다. 위 실습값은 chunk_size=500, chunk_overlap=100 — 20% 겹침이다.

청크 크기 선택 기준

결정 규칙: "이 질문에 답하는 데 필요한 최소 문맥 단위"가 청크 하나에 들어가야 한다. 사규 QA라면 조항 하나, 기술 문서라면 소단원 하나가 기준이다.

글자 수부터 정하지 말고 문서의 자연스러운 의미 단위부터 정하는 것이 순서다. 500이라는 숫자는 그 단위를 재고 나서 나오는 결과지 출발점이 아니다.

Embed — 임베딩

from langchain_openai import OpenAIEmbeddings

embeddings_model = OpenAIEmbeddings(model="text-embedding-3-small")

embeddings = embeddings_model.embed_documents([
    "Hi there!", "Oh, hello!", "What's your name?",
    "My friends call me World", "Hello World!",
])
len(embeddings), len(embeddings[0])
# -> (5, 1536)      문장 5개 -> 각 1536차원 벡터

print(embeddings[0][:10])
# -> [-0.0191, -0.0381, -0.0309, -0.0046, -0.0354, ...]   그냥 실수 배열이다

# 실제 파이프라인: PDF 로드 -> 재귀 분할 -> 전체 청크를 한 번에 임베딩
loader = PyPDFLoader("data/autogen_paper.pdf")
pages = loader.load()

text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100)
texts = text_splitter.split_documents(pages)

embeddings = embeddings_model.embed_documents([i.page_content for i in texts])
len(embeddings), len(embeddings[0])
# -> (412, 1536)    AutoGen 논문 1편이 청크 412개 = 벡터 412개가 됐다

실측값 둘을 남겨 둔다. text-embedding-3-small은 1,536차원이고, AutoGen 논문 PDF 1편은 chunk_size=500 재귀 분할 기준 412청크가 된다. 다만 이 숫자는 논문 PDF 한 편이라는 특정 문서에 대한 값이라, 문서 종류가 바뀌면 분포도 바뀐다.

두 메서드가 나뉜 이유가 인터페이스 설계의 좋은 예다. 모델에 따라 문서용과 질의용 프리픽스(passage: / query: 등)를 다르게 붙여야 성능이 나오기 때문이다.

OpenAI 모델은 양쪽을 동일하게 처리하지만, 인터페이스가 미리 나뉘어 있는 덕분에 그렇지 않은 모델로 갈아탈 때 호출부 코드를 안 고쳐도 된다. 지금 필요 없는 구분을 미리 그어 두는 것이 나중에 값을 하는 드문 경우다.

임베딩 모델을 무엇으로 고를지의 기준(언어·차원·비용·입력 길이·보안)은 임베딩 단계에 정리돼 있다. 여기서 한 가지만 못 박아 두면, 모델을 바꾸면 기존 벡터 전량을 다시 만들어야 한다. 질문과 문서가 같은 벡터 공간에 있어야 유사도가 의미를 갖기 때문에 부분 교체가 성립하지 않는다. 임베딩 모델 선택은 사실상 되돌리기 어려운 결정이다.

Store & Retrieve — 벡터스토어와 Retriever

from langchain.vectorstores import FAISS

# 청크 + 임베딩 모델을 넘기면 임베딩 생성부터 인덱싱까지 한 번에 처리
db = FAISS.from_documents(texts, embeddings_model)

retriever = db.as_retriever()      # 벡터스토어를 Retriever 인터페이스로 감싼다

query = "What is autogen"
retriever.invoke(query)            # 질문을 임베딩 -> 유사 청크 상위 k개 반환 (기본 k=4)

as_retriever()가 중요한 이유는 인터페이스 분리다. Retriever는 "질문을 주면 Document 리스트를 준다"만 약속하므로, 뒤에서 FAISS를 Chroma로 바꾸든 Elasticsearch로 바꾸든 체인 코드는 그대로다.

벡터스토어 선택

선택의 실질적 기준은 성능이 아니라 운영이다. 네 가지를 순서대로 확인한다.

메타데이터 필터 — 권한이 걸리는 자리

Retriever의 k·search_type·score_threshold 같은 튜닝 파라미터는 검색기 단계에 표로 정리돼 있다. 여기서 따로 짚을 것은 하나다.

retriever = db.as_retriever(search_kwargs={"filter": {"department": "finance"}})

search_kwargs의 메타데이터 필터는 품질 파라미터가 아니라 접근 제어 지점이다. 부서·기간·문서종류로 검색 범위를 좁히는 것이 사내 RAG에서 권한을 거는 실질적 위치다.

이것이 앞의 벡터스토어 선택 기준 2번과 직결된다. 메타데이터 필터가 약한 저장소를 고르면, 권한 분리를 애플리케이션 코드로 올려야 하고 그 순간 검색 결과를 받아 놓고 버리는 구조가 된다.

Generate — RAG 체인

검색기까지 준비되면 남은 것은 조립이다. 체인 골격 자체는 RAG 체인 조립과 문서 포맷터에 코드로 정리돼 있으므로 여기서는 각 조각이 없으면 무슨 일이 생기는지만 본다.

세 번째 행의 hub.pull("rlm/rag-prompt")가 눈여겨볼 부분이다. RAG 프롬프트를 직접 쓰지 않고 LangChain Hub에서 검증된 것을 가져온다. context·question 슬롯을 가진 규격이라 그대로 파이프에 꽂힌다.

format_docs가 사실 가장 손댈 데가 많은 함수다. 여기서 doc.metadata['source']와 page를 같이 붙이면 답변에 출처를 달 수 있고, 청크 순서를 재정렬하면 그것이 곧 리랭킹이다.

기본형은 "\n\n".join(...) 한 줄이지만, 출처 표기와 재정렬이 들어가는 자리가 전부 이 함수 안이다. 로더 단계에서 챙긴 metadata가 여기서 값을 한다.

노트북 포맷과 시크릿

RAG 실습이 대부분 노트북에서 이뤄지다 보니 반복적으로 나오는 사고가 하나 있다. API 키가 첫 셀에 평문으로 남은 채 공유되는 것이다.

노트북은 코드와 실행 결과가 한 파일에 붙어 있는 포맷이다. 그래서 시크릿뿐 아니라 고객 데이터·사내 문서 원문이 출력 셀에 함께 남아 유출된다.

AI 실습 코드를 팀에 전파할 때 별도 게이트가 필요한 이유가 여기 있다. 일반 소스 코드용 시크릿 스캔만으로는 출력 셀을 못 잡는다.

순수 RAG의 한계

지금까지 만든 체인은 직선 파이프라인이다. 질문이 들어오면 한 번 검색하고, 한 번 생성하고, 끝난다.

도식은 다섯 갈래인데 표는 여섯 행이다. 표에만 있는 것이 도구 사용 불가다. 앞의 다섯은 전부 "검색을 더 잘하면 되는" 문제라 한 묶음이지만, 여섯 번째는 성격이 다르다 — 계산이 필요한 질문은 검색을 아무리 잘해도 안 풀린다. 이 한 행이 RAG와 에이전트를 가르는 자리다. 표의 "Agentic RAG의 대응" 열도 도식이 담지 못하는 정보다. 한계를 아는 것과 그 한계를 무엇으로 푸는지 아는 것은 다르다.

구조적으로 말하면 순수 RAG는 **DAG(비순환 그래프)**이고, Agentic RAG는 사이클이 있는 그래프다. LCEL의 |는 왼쪽 출력을 오른쪽 입력으로 넘기는 연산이라 사이클을 표현할 수 없다. 조건 분기와 반복을 표현하려면 상태(State)를 들고 노드 사이를 오갈 수 있는 실행 모델이 필요하고, 그것이 LangGraph다. LCEL 체인과 LangGraph가 각각 어떤 작업에 맞는지는 체크포인터·HITL 편에서 아홉 개 축으로 정리한다.

그래서 학습 순서가 이렇게 짜인다. LCEL로 배관을 배우고 → 순수 RAG로 한계를 체감하고 → LangGraph로 루프를 얹는다.

"왜 LangGraph를 쓰나"라는 질문에 프레임워크 비교로 답하는 것은 두 번째로 좋은 답이다. 가장 좋은 답은 **"1회 검색으로 안 풀리는 질문이 실제로 있었다"**는 문제 서술이다.

여기까지가 LangChain으로 만드는 RAG의 전부이자 한계다. 검색 결과를 채점하고, 미달이면 질문을 재작성해 다시 검색하는 사이클 — 그것을 표현하려면 파이프가 아니라 그래프가 필요하다. 이어지는 시리즈에서 State·Node·Edge라는 실행 모델로 내려간다.

청크 크기를 무엇으로 정하는지, 임베딩 모델을 바꾸면 무슨 일이 생기는지처럼 RAG 설계에서 반복되는 질문은 기본기 Q&A에 결론부터 모아 두었다.