사내 계약서 분석 자동화 프로젝트를 맡았을 때, 저도 처음엔 청킹(chunking)을 그냥 텍스트 자르는 작업 정도로 봤습니다. 그런데 실제로 서비스를 돌려보니, 임베딩 모델이나 벡터 DB보다 청킹 전략이 결과 품질을 훨씬 크게 좌우했습니다. 청킹이란 긴 문서를 LLM이 처리할 수 있는 크기의 조각으로 나누는 작업으로, RAG 파이프라인 전체의 성능을 결정짓는 핵심 단계입니다.
고정 크기 청킹이 실패한 날
처음에 적용한 방식은 고정 크기(fixed-size) 청킹이었습니다. 고정 크기 청킹이란 문서의 내용이나 구조를 고려하지 않고 일정한 글자 수나 토큰 수 단위로 텍스트를 잘라내는 방식입니다. 구현이 단순하고 직관적이라 많은 RAG 튜토리얼에서 첫 번째 예시로 등장하는 방법이기도 합니다.
결과는 솔직히 예상 밖이었습니다. 계약서의 조항 번호와 실제 내용이 서로 다른 청크에 분리되거나, 한 문장이 중간에 잘려 LLM이 전혀 엉뚱한 답을 내놓는 상황이 빈번했습니다. "제3조에 명시된 손해배상 한도는 얼마입니까?"라고 물었을 때, 모델이 제3조의 제목만 담긴 청크를 가져와서 "내용이 없다"고 대답하는 식이었습니다. 청크 경계가 잘못 설정되면 정보 손실이 발생한다는 것을 몸으로 배운 순간이었습니다.
이후 LangChain의 RecursiveCharacterTextSplitter로 전환했습니다. 이 방식은 단락(\n\n) → 줄바꿈(\n) → 문장 → 단어 순서로 자연스러운 경계를 찾아 분리합니다. 여기에 오버랩(overlap)을 200자로 설정했는데, 오버랩이란 인접한 청크 사이에 일정 분량의 텍스트를 중복으로 포함시켜 경계에서 맥락이 단절되는 문제를 줄이는 기법입니다. 이것만으로도 답변 품질이 눈에 띄게 올라갔습니다(출처: LangChain 공식 문서).
계층적 청킹으로 정확도를 끌어올리다
RecursiveCharacterTextSplitter로도 아쉬운 부분이 남았습니다. 계약서는 '장(Chapter) → 조(Article) → 항(Clause)'이라는 명확한 위계 구조를 가지고 있는데, 이 구조를 무시하고 텍스트 경계만으로 분리하면 문맥의 위계 정보가 사라지기 때문입니다. 그래서 제가 직접 실험해본 것이 계층적(hierarchical) 청킹 방식이었습니다.
계층적 청킹이란 문서의 헤더나 섹션 구조를 기준으로 1차 분할을 먼저 수행하고, 그 안에서 다시 세밀하게 나누는 다단계 분할 방식입니다. 계약서에서는 먼저 각 조(Article)를 기준으로 상위 청크를 구성하고, 그 안의 항(Clause)을 하위 청크로 분리했습니다. 검색 시에는 상위 청크가 요약 역할을 하고, 하위 청크가 세부 내용을 담당하는 구조로 활용했습니다.
이 방식의 장점은 RAG(Retrieval-Augmented Generation) 파이프라인에서 두드러집니다. RAG란 외부 문서에서 관련 정보를 검색해 LLM의 응답에 활용하는 방식으로, 모델이 학습하지 않은 최신 정보나 사내 문서를 다룰 때 특히 유용합니다. 계층적 청킹을 적용하자 질문에 대한 정확한 조항을 찾는 검색 정밀도가 눈에 띄게 올라갔고, 답변의 맥락 완결성도 함께 개선되었습니다.
청크 크기 선정에서도 실험이 필요했습니다. 512토큰, 1024토큰, 2048토큰으로 각각 나눠 동일한 질문에 대한 답변 품질을 비교했을 때, 저희 프로젝트에서는 1024토큰이 가장 균형 잡힌 결과를 냈습니다. 청킹 전략 선택 시 고려해야 할 핵심 기준을 정리하면 다음과 같습니다.
- 청크 크기가 너무 작으면 맥락이 부족해 LLM이 온전한 답을 생성하기 어렵습니다.
- 청크 크기가 너무 크면 검색 단계에서 정밀도가 떨어져 관련 없는 내용이 섞여 들어옵니다.
- 오버랩 설정은 청크 경계에서 발생하는 맥락 단절을 완화하는 데 효과적입니다.
- 문서 구조(헤더, 단락, 조항)를 적극적으로 활용하면 분리 품질이 크게 향상됩니다.
Greg Kamradt의 연구에서도 문서 유형에 따라 최적 청크 크기가 다르며 단일 전략으로 모든 케이스를 커버할 수 없다는 점이 강조됩니다(출처: Pinecone, Chunking Strategies for LLM Applications). 제 경험상 이건 정말 맞는 말입니다. 계약서와 뉴스 기사, 기술 매뉴얼은 분명히 다른 전략이 필요합니다.
"청킹은 이제 필요 없다"는 주장, 어디까지 맞는가
200K 토큰이라는 대형 컨텍스트 창을 가진 모델이 등장하면서, "이제 문서 전체를 한 번에 넣으면 되니 청킹은 필요 없다"는 시각도 있습니다. 컨텍스트 창(context window)이란 LLM이 한 번의 요청에서 처리할 수 있는 최대 토큰 수를 의미합니다. 창이 커질수록 더 긴 문서를 통째로 넣을 수 있다는 건 사실입니다.
그런데 저는 이 주장에 동의하기 어렵습니다. 비용과 레이턴시 문제가 현실적으로 크기 때문입니다. 200K 토큰을 매 쿼리마다 꽉 채워 넣으면 API 비용이 폭발적으로 증가합니다. 실제 서비스에서 수천 건의 질의가 발생하는 상황을 생각해보면, 전략적 청킹 없이 운영하는 건 비용 측면에서 현실적이지 않습니다. 레이턴시(latency), 즉 요청에서 응답까지 걸리는 시간도 컨텍스트가 길수록 늘어나기 때문에 사용자 경험에도 부정적인 영향을 줍니다.
물론 대형 컨텍스트 창이 쓸모없다는 게 아닙니다. 소수의 고가치 문서를 깊이 분석해야 하는 경우에는 긴 컨텍스트가 확실한 이점을 줍니다. 다만 대규모 문서 처리나 실시간 서비스 환경에서는 임베딩(embedding) 기반 검색과 전략적 청킹을 결합한 RAG 구조가 여전히 가장 현실적인 접근이라고 봅니다. 임베딩이란 텍스트를 의미적 유사성을 계산할 수 있는 수치 벡터로 변환하는 기술로, 수만 개의 청크 중에서 질문과 가장 관련 높은 조각만 골라낼 수 있게 해줍니다.
청킹은 RAG 파이프라인에서 가장 과소평가되는 단계라는 생각은 지금도 변함이 없습니다. 많은 튜토리얼이 임베딩 모델 선택이나 벡터 DB 구성에 집중하지만, 실제 서비스 품질은 그 이전 단계인 청킹에서 이미 상당 부분 결정됩니다.
RAG 파이프라인을 처음 구성하고 있다면, 고정 크기 청킹으로 빠르게 프로토타입을 만들어본 뒤 RecursiveCharacterTextSplitter로 전환하고, 문서 구조가 명확하다면 계층적 청킹을 실험해보는 순서를 권합니다. 청크 크기는 반드시 여러 옵션으로 실험해야 합니다. 정답은 문서 유형과 서비스 특성에 따라 달라집니다.
참고:
- LangChain. (2024). Text Splitters. https://python.langchain.com/docs/concepts/text_splitters/
- Kamradt, G. (2023). Chunking Strategies for LLM Applications. Pinecone. https://www.pinecone.io/learn/chunking-strategies/
- Anthropic. (2024). Long context tips. https://docs.anthropic.com/en/docs/build-with-claude/long-context-window