[Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화

 

 

[ kt cloud 마케팅커뮤니케이션팀 김지웅 님 ]

📋 요약

RAG 시스템의 성능을 좌우하는 청킹(Chunking) 전략과 최적화 방법을 다룹니다.

고정 길이, 의미 기반, 구조 기반 청킹의 원리와 실전 활용법을 상세히 소개합니다.

#RAG #청킹 #AI검색 #LLM #데이터전처리

---

들어가며 💭

안녕하세요, kt cloud 테크 마케터 김지웅입니다. 🙋‍♂️

RAG를 구축하다 보면 누구나 한 번쯤 이런 벽을 만나게 돼요.

“문서는 준비했고, 임베딩도 만들었는데… 왜 성능이 기대보다 낮지?”

 

이때 가장 먼저 의심해야 하는 부분이 바로 청킹(Chunking)이에요.

LLM이 이해할 수 있는 크기로 문서를 분할하는 단순한 작업처럼 보이지만, 실제로는 검색 품질·비용·지연까지 모두 좌우하는 핵심 변수거든요.

 

흥미로운 점은, 같은 문서라도 어디서 자르느냐에 따라 nDCG·Recall·Precision이 완전히 달라진다는 사실이에요. 심지어 파싱을 잘했더라도 청킹 전략이 어긋나면 정보가 잘려 나가거나 여러 개념이 섞이며 성능이 크게 흔들리죠. 그래서 청킹은 RAG 파이프라인에서 가장 실험이 많이 필요한 단계이자, 동시에 가장 오해가 많은 단계이기도 해요.

 

이번 3편에서는 이 ‘보이지 않는 설계 지점’을 제대로 들여다보려고 해요.
고정 길이와 의미 기반, 구조 기반 청킹의 원리부터, 청크 크기·오버랩 같은 주요 파라미터가 실제 성능에 어떤 영향을 미치는지, 그리고 코드·표·수식처럼 까다로운 문서 형태는 어떻게 다뤄야 하는지까지 차근차근 정리해볼게요.🛠️

 

그럼 이제 RAG 품질을 결정짓는 두 번째 핵심 단계, 청킹 전략과 최적화의 세계로 함께 들어가보겠습니다.🥸

---

문서를 이해하는 일, RAG 성능의 출발점이다

왜 "어떻게 자르느냐"가 중요한가

RAG(Retrieval-Augmented Generation) 시스템에서 청킹은 단순한 전처리가 아니라 검색과 생성 품질을 좌우하는 핵심 설계 요소예요. 여러 연구에서도 동일한 문서·임베딩 모델 환경에서 청킹 전략만 달라져도 Recall이 최대 9%p까지 변한다는 결과가 보고되었죠. 즉, 문서를 어떤 단위로 나누느냐는 RAG 성능의 토대를 결정하는 문제라고 볼 수 있어요.

 

청킹이 중요한 이유는 크게 세 가지로 정리할 수 있어요. 먼저 검색 정확도 측면이에요. 청크가 너무 작으면 문맥이 끊어져 Precision이 떨어지고, 반대로 너무 크면 의미가 뒤섞여 Recall이 하락하죠. NVIDIA의 2024년 실험에서도 512~1024 토큰 범위가 가장 안정적인 성능을 보였다는 결과가 이를 잘 보여줘요✨ 작은 청크는 문맥 단절, 큰 청크는 의미 희석이라는 특성이 뚜렷하니 최적 크기를 잡는 일이 정말 중요해지는 셈이에요.

 

두 번째로는 토큰 예산과 LLM 입력 한계예요. 문서를 그대로 길게 넣는 방식은 금세 컨텍스트 한계를 넘게 되고, 그 과정에서 중앙부 정보가 사라지는 ‘lost-in-the-middle’ 현상이 자주 발생해요. Pinecone과 Chroma 분석에서도 문서 전체를 입력하는 방식은 비용만 증가하고 정확도는 오히려 떨어진다고 지적했어요. 그래서 청킹은 단순 분할이 아니라 모델이 필요한 정보에만 집중하도록 하는 필터링 기법에 가깝다고 볼 수 있어요.

 

세 번째는 운영 효율성이에요. 청크를 지나치게 잘게 나누면 벡터 저장소 엔트리가 폭증해 인덱싱 비용과 latency가 크게 늘어나고, 반대로 너무 크게 나누면 검색 품질이 저하되죠. 다양한 연구에서는 전체 청크 길이의 약 10~25% 오버랩이 가장 효율적이라는 경향이 발견되었어요.

 

또한 문서의 도메인에 따라 최적 청크 크기가 다르게 나타난다는 점도 중요해요. 예를 들어 NVIDIA 실험에서는

• FAQ: 200~400 tokens
• 기술 문서: 600~1200 tokens
• 법률 문서: 800~1500 tokens

같은 패턴이 확인되었어요. 반면 일부 고밀도 도메인 문서에서는 100 tokens 수준의 짧은 청크가 더 안정적으로 작동하는 사례도 있었어요. 즉, 문서의 구조·정보 밀도·문장 길이에 따라 최적 청킹 전략이 서로 다르게 형성되는 모습이에요.

 

결국 하나의 규칙으로 모든 문서를 자를 수는 없고, 도메인과 구조, 정보 밀도에 맞춰 실험적으로 최적 청킹 전략을 찾아야 해요. 그래서 최근 RAG 설계에서는 “임베딩 모델 선택보다 청킹 전략을 먼저 잡아라”라는 말이 나올 정도로, 청킹은 RAG 효율과 품질을 결정하는 출발점이 되고 있어요.

---

분할 전략의 기본기 — 가장 먼저 결정해야 할 선택들

단순하지만 강력한 기준, 고정 길이 청킹

고정 길이 기반 청킹(fixed-size chunking)은 가장 널리 사용되는 기본 방식이에요. 텍스트를 일정한 토큰 또는 문자 단위로 균등하게 나누기 때문에 구현이 간단하고 처리 속도도 일정해, 대규모 문서를 빠르게 전처리해야 할 때 특히 강점을 발휘하죠. Haystack과 LangChain 같은 프레임워크에서 기본 전략으로 채택되는 이유도 바로 이런 예측 가능성과 안정성이에요.

🔍 단순하지만 동반되는 부작용

이 방식은 편리하지만 의미적 경계를 고려하지 않기 때문에 몇 가지 한계도 존재해요. 문장이나 문단이 중간에서 잘리면 개념이 분해되어 임베딩의 의미적 일관성이 떨어지고, Precision도 함께 낮아지죠. MDPI 임상 QA 연구에서도 이런 문제가 반복적으로 나타났다고 해요. 반대로 청크가 지나치게 크면 여러 주제가 하나의 벡터에 섞이는 ‘semantic mixing’이 발생해 Recall 성능이 저하되는 경향도 관찰되었어요.

 

그럼에도 고정 길이 방식은 baseline 전략으로 꾸준히 높은 평가를 받고 있어요. Firecrawl의 실험에서는 세 가지 실제 문서 사례에서 의미 기반 청킹보다 Recall이 더 높게 나온 경우가 있었고, Chroma Research 실험에서는 약 400 tokens 구간에서 Recall 88.1~89.5%로 매우 안정적인 값이 확인되었어요✨ 복잡한 튜닝 없이도 안정적인 성능을 확보할 수 있다는 점이 큰 장점이에요.

⚙️ 성능을 좌우하는 핵심 변수: ‘오버랩’

고정 길이 방식에서 가장 중요한 설정은 오버랩(overlap)이에요. 오버랩을 거의 주지 않으면 청크 경계에서 문맥이 끊어져 중요한 정보가 따로 떨어져 나가고, 반대로 지나치게 많이 주면 저장량·비용만 늘어나 성능 향상 효과는 거의 없어요. 그래서 여러 실험에서 전체 청크 길이의 약 10~25%가 가장 안정적인 구간이라는 결과가 반복적으로 확인되고 있어요.

 

물론 모든 도메인이 이 범위 안에서 움직이는 것은 아니에요. 예를 들어 화학 분야 논문을 대상으로 수행된 한 실험에서는 100 tokens 단위의 짧은 청크 + 비오버랩(RT100-0) 전략이 가장 효율적으로 나타난 사례도 있었어요. 문서 구조나 정보 밀도에 따라 오버랩이 거의 필요 없는 경우도 존재한다는 뜻이죠.

 

이처럼 오버랩은 단순한 설정값처럼 보여도 검색 정확도·정보 연결성·운영 비용을 동시에 좌우하는 민감한 변수예요. 그래서 실제 운영 환경에서는 문서 유형별로 오버랩 크기를 조금씩 바꿔가며 가장 안정적인 조합을 찾는 과정이 필수적이에요.

---

의미 흐름을 따라가는 Semantic 청킹

의미적 청킹(semantic chunking)은 문서 안의 의미 경계를 기준으로 텍스트를 분할하는 전략이에요. 고정 길이 기반처럼 일정 길이로 단순하게 자르지 않고, 문서가 전달하는 개념적 흐름을 따라 청크를 형성하는 점이 가장 큰 특징이에요. 보통 문장을 임베딩 모델로 벡터화한 뒤 문장 간 코사인 유사도를 비교하거나, 전체 문장을 클러스터링해 주제적 응집도를 기준으로 묶는 방식이 널리 활용돼요. 이런 접근은 청크 내부 의미를 자연스럽게 보존해 문맥 단절을 줄여준다는 장점이 있어요.

🧩 의미 흐름을 반영할 때 얻을 수 있는 이점들

여러 연구에서는 의미 기반 방식이 고정 길이보다 더 높은 검색 성능을 보인 사례가 반복적으로 보고되었어요. 예를 들어 Chroma Research에서는 ClusterSemanticChunker가 Recall 91.3%로 고정 길이 기반 RecursiveCharacterTextSplitter(약 88~90%)보다 우수한 결과를 보였고, LLM 기반 분할기인 LLMChunker도 Recall 0.919로 가장 높은 점수를 기록했어요. 또한 의미 단위로 정보를 묶어주면 문장 간 논리 연결성이 보존되기 때문에, 문맥 해석 과정에서 Precision이 안정적으로 개선되는 경향도 확인되고 있어요.

 

다만 모든 문서에서 의미 기반 방식이 더 좋은 것은 아니에요. 한 연구에서는 토픽이 강하게 뒤섞여 있는 stitched 데이터셋에서는 의미 기반이 확실히 우위였지만, 실제 업무 문서에서는 성능 차이가 거의 없거나 오히려 고정 길이가 더 나은 사례도 있었다고 해요. 대부분의 문서는 본래 일정한 논리 구조를 갖고 있기 때문에, 의미 기반 분할이 제공하는 이점이 제한적일 수 있다는 뜻이에요. 하지만 논문·기술 보고서·의료 진단서처럼 다양한 세부 토픽이 한 문서에 공존하는 유형에서는 의미 기반 청킹이 Recall 손실을 줄이는 데 효과적이에요.

⚠️ 높은 비용과 세분화 문제라는 현실적인 한계

의미적 청킹의 가장 큰 약점은 비용이에요. 모든 문장을 임베딩하고 유사도·클러스터링 계산을 수행해야 해서, 초기 인덱싱 비용이 고정 길이보다 3~5배까지 증가한다고 보고되었어요. 또 유사도 임계값을 너무 엄격하게 잡으면 문서가 지나치게 잘게 쪼개져 수십~수백 개의 청크가 생성되며 latency가 악화되는 현상도 종종 관찰되었어요. 반대로 클러스터 기반 방식은 Recall은 높지만 청크가 과도하게 커져 Precision이 떨어지는 문제도 보고되었죠.

 

이 때문에 많은 구현에서는 의미 기반 청킹에도 최대 길이(max chunk length) 제한을 함께 적용해요. Chroma 실험에서는 클러스터 기반 방식에 약 400 tokens 제한을 두었을 때 Recall 0.913으로 가장 좋은 값이 나왔고, 200 tokens처럼 지나치게 작은 길이를 적용하면 Recall이 줄고 Precision만 불필요하게 높아지는 trade-off가 나타났어요. LangChain의 SemanticChunker처럼 문서 통계를 이용해 임계값을 자동 조정해주는 접근도 있지만, 문서 전체 스캔이 필요해 비용 부담은 여전히 남아 있어요.

 

결론적으로 의미 기반 청킹은 문서의 실제 의미 흐름을 반영해 청크 응집력을 크게 끌어올릴 수 있는 강력한 전략이에요. 특히 장문·고밀도·다주제 문서는 효과가 두드러지지만, 비용·latency 부담도 크기 때문에 문서 도메인과 운영 목표를 고려해 선택적으로 적용하는 것이 더 적합해요.

---

문서 구조를 그대로 활용하는 Structure-aware 청킹

구조 기반 청킹(structure-aware chunking)은 문서의 형식적 구조 헤더, 섹션, 문단, 리스트, 표, 코드 블록 등을 기준으로 텍스트를 나누는 전략이에요. 사람의 글쓰기 방식이 가진 논리적 단위를 그대로 반영해 분할하기 때문에, 문맥 단절을 최소화할 수 있다는 점이 중요한 특징이에요. Pinecone과 Weaviate도 “청크 하나가 독립적으로 읽혀 의미가 충분히 전달되는가”를 청킹 품질의 핵심 기준으로 제시하며 자연스러운 경계 유지의 중요성을 강조하고 있어요.

📑 문서 구조를 활용하면 얻을 수 있는 강점

가장 기본적인 방법은 문단 단위 분할이에요. 문단은 하나의 주장이나 설명이 유기적으로 연결되어 있기 때문에, LLM이 청크 하나만으로도 내용을 충분히 해석할 수 있어요. 블로그, 보고서, 기술 문서처럼 구조가 잘 잡힌 도메인에서는 문단 단위만으로도 놀랄 만큼 안정적인 성능이 나오기도 해요✨

 

이보다 한 단계 더 들어가면 문서의 계층 구조(hierarchical structure)를 활용하는 방식이 있어요. 예를 들어 HTML 문서라면 <h1>~<h6> 헤더를 기준으로 섹션을 구분해 묶을 수 있고, 섹션이 길다면 <h3> 이하의 하위 헤더 기준으로 다시 세분화할 수 있어요. PDF 문서는 페이지 번호·장/절 제목·폰트 스타일 같은 단서를 활용해 페이지 단위 청킹도 가능한데, NVIDIA(2024) 벤치마크에서는 페이지 단위 청킹이 7개 전략 중 평균 정확도 0.648로 가장 높았다고 보고되었어요.

 

최근에는 레이아웃 인식 기술이 발전하면서 구조 기반 청킹의 활용도가 크게 높아졌어요.

• Google Document AI Layout Parser는 제목·표·문단·리스트를 자동 인식하고,
• Docling의 HierarchicalChunker는 섹션 구조를 유지하면서 표 요소를 독립 블록으로 분리하며,
• Unstructured AI의 hi_res 파티셔닝은 title-aware chunker로 구성되어 도메인 QA에서 최대 40% 이상의 정확도 향상까지 보고되었어요.

구조 기반 청킹은 특히 “주변 설명과 함께 해석되어야 의미가 살아나는 데이터”에서 강점을 보여요. 예를 들어 수식만 따로 저장하면 문맥 파악이 어렵지만 “수식 + 인접 설명”으로 구성하면 의미 전파가 훨씬 자연스러워지고, 코드 역시 함수나 클래스 전체를 묶을 때 특정 기능 관련 질의가 더 정확하게 처리돼요.

🧱 구조 기반과 의미 기반의 결합도 대세

최근에는 구조 기반과 의미 기반을 결합한 하이브리드·계층적 청킹(hierarchical/hybrid chunking)도 활발하게 연구되고 있어요. 먼저 문서를 큰 헤더 단위로 나누고, 그 내부에서 의미 기반 분할이나 클러스터링을 적용하는 방식이 대표적이에요. 이는 사람이 문서를 읽고 이해하는 방식과 유사해 장문 QA(NarrativeQA·QuALITY 등)에서 성능 향상을 보였다는 연구도 있어요.

 

물론 구조 기반 청킹이 모든 문서에 잘 맞는 것은 아니에요. Markdown이나 기술 매뉴얼처럼 구조가 명확한 문서는 큰 효과를 보이지만, 웹 크롤링 데이터처럼 구조가 흐릿하거나 노이즈가 많은 문서에서는 오히려 구조가 방해가 되는 경우도 많아요. 이 때문에 BeautifulSoup·Unstructured 같은 도구로 HTML 광고·내비게이션처럼 불필요한 요소를 제거해 구조를 재정리하는 파싱 단계가 중요해요.

 

정리하자면 구조 기반 청킹은 문서의 형식적 단서를 활용해 문맥 보존과 의미 일관성을 높여주는 전략이고, 구조가 뚜렷한 도메인에서는 매우 큰 위력을 발휘해요. 특히 표·코드·수식 등 주변 설명이 필수적인 구성 요소에서는 뛰어난 효과를 보여 RAG 시스템에서 중요한 선택지로 자리 잡고 있어요.

---

청킹 파라미터 튜닝 — 크기·오버랩·중복의 최적 균형 찾기

문맥을 잇는 기술, 오버랩(Windowing)의 효과

오버랩 청킹(overlapping chunking)은 연속된 청크 사이에 일정량의 텍스트를 중복 포함시키는 방식이에요. 청크 경계에서 문맥이 끊어지는 문제(context fragmentation)를 줄이기 위한 대표적인 기법이죠. 보통 슬라이딩 윈도우(sliding window) 방식으로 적용되는데, 예를 들어 512토큰 청크에 128토큰(25%) 오버랩을 주면 다음 청크는 이전 청크의 마지막 128토큰을 공유한 상태에서 시작돼요. 이렇게 중복된 구간이 생기면 경계에 걸린 중요한 문장도 한 청크 이상에서 온전히 포함되기 때문에 Recall 손실을 줄이는 데 큰 도움이 돼요.

🔎 Recall 향상에서는 매우 안정적인 효과

여러 연구에서는 오버랩이 Recall 향상에 지속적으로 긍정적 영향을 준다고 보고해요.

• Chroma 실험에서는 50% 오버랩이 무오버랩 대비 뚜렷한 Recall 상승을 보였고,
• 한 RAG 실험에서는 baseline Recall 0.40 → adaptive overlap 적용 후 0.88로 거의 두 배 이상 개선되기도 했어요.
• 화학 논문 벤치마크 연구에서도 RT100 조건에서 0% 오버랩 대비 60% 오버랩 시 Recall이 71.1% → 72.5%로 상승했어요.

이런 결과를 보면, 오버랩은 <u>탐색적 검색·증거 중심 질의·포괄적 회수 작업처럼 Recall이 중요한 상황에서 특히 강력한 도구</u>라는 사실이 확실히 드러나요✨

⚠️ 그러나 비용·Precision·중복 문제도 함께 따라와요

오버랩이 높을수록 비용과 Precision 문제도 빠르게 증가해요.
첫째, 중복 인덱싱 비용이 오버랩률에 비례해 늘어나요. 예를 들어 60% 오버랩이면 저장 공간·임베딩 호출 비용·인덱스 크기가 사실상 60% 증가하는 구조예요.

둘째, Precision 하락도 잦게 보고되었어요. 높은 오버랩일수록 비슷한 내용을 가진 청크가 동시에 검색 상위권에 올라와 top-k가 중복 청크들로 채워지는 문제가 생기기 때문이에요. 실제 화학 RAG 연구에서는 40% 이상 오버랩 구간에서 Precision이 40% 이상 감소했다고 보고되었어요.
셋째, LLM 입력에 중복된 청크가 반복 포함되면 attention이 분산되어 응답 품질이 저하될 가능성도 지적되고 있어요.

 

그래서 오버랩의 적정치는 문서 도메인과 비용 제약에 따라 달라져요. Qdrant 가이드에서는 10~20% 오버랩이 가장 안정적인 기본값이라고 제안해요. 이 범위는 문맥 보존 효과와 비용 사이의 균형이 좋아서 RAG 초기 구축에서 자주 쓰이는 설정이에요.
또한 일부 연구에서는 퍼센트 기반보다 ‘절대 토큰 규칙’(예: 512·1024·2048 청크에 50·100·200 토큰 오버랩)이 더 일관된 성능을 보였다는 분석도 있었어요.

 

의료 기록·법률 문서처럼 문맥 연속성이 특히 중요한 도메인에서는 25~30% 오버랩이 타당한 선택이 될 수 있어요. 하지만 대부분의 연구는 “30% 이상은 비용·Precision 감소에 비해 추가 이득이 거의 없다”고 일관되게 보고해요.

 

실제로 오버랩이 전혀 없으면 개념 정의와 사례가 서로 다른 청크에 분리되어 검색 시 정보가 조각조각 회수되는 문제가 생기지만, 적절한 오버랩이 있으면 정의·설명·근거가 하나의 청크 단위로 묶여 훨씬 안정적인 답변 생성이 가능해요. 반대로 오버랩이 지나치게 크면 검색 결과가 중복 청크로 가득 차서, 정말 필요한 중요한 청크가 상위 랭크에서 밀려나는 부작용도 생길 수 있다는 점을 꼭 주의해야 해요.

 

결론적으로 오버랩은 문맥 보존을 높여 Recall을 끌어올리는 매우 중요한 파라미터예요. 하지만 저장 비용 증가, Precision 저하, latency 악화 같은 부작용도 분명 존재하므로 실무에서는 10~20%를 기본값으로 시작해 지표(Recall@k, nDCG, Precision)를 보면서 점진적으로 조정하는 방식이 가장 널리 쓰이고 있어요. 고오버랩 전략은 법률·의료처럼 검색 실패의 비용이 큰 도메인에서만 선택적으로 사용하는 것이 더 바람직해요.

 

결국 오버랩은 고정된 규칙이라기보다 도메인·쿼리 특성·비용 제약을 모두 고려해 실험적으로 최적화해야 하는 핵심 청킹 변수라고 볼 수 있죠!

---

중복을 줄일 것인가, 문맥을 지켜낼 것인가

중복 인덱싱(minimizing duplication)과 문맥 보존(context preservation)은 청킹 파라미터를 조정할 때 항상 서로 부딪히는 목표예요. 오버랩(overlap)이나 의미 기반 병합처럼 문맥을 풍부하게 보존하는 전략은 Recall 향상에 효과적이지만, 그만큼 동일한 정보가 여러 청크에 반복 저장되기 때문에 비용이 빠르게 증가해요. 반대로 중복을 지나치게 억제하면 저장 비용은 줄지만, 청크가 “문맥이 잘린 파편”처럼 분리되어 필요한 근거가 회수되지 않는 문제가 생기죠.

🪙 중복이 만들어내는 비용 증가

중복 인덱싱으로 인한 비용 증가는 여러 지점에서 드러나요. 스토리지 측면에서는 오버랩 비율이 p%라면 인덱스 크기도 거의 동일하게 p% 증가해요. 예를 들어 25% 오버랩을 설정한 100만 개 청크 컬렉션은 약 25만 개의 벡터를 추가로 저장해야 하고, 장기적으로 큰 저장 비용으로 이어지죠. HNSW 기반 벡터 DB는 검색 복잡도는 낮아도 N이 늘어나면 latency가 밀리초 단위로 누적돼 체감 지연이 생겨요. 임베딩 생성 비용 역시 청크 수에 비례해 증가하고요.

 

또 중복은 품질에도 영향을 줘요. 동일 문장이 여러 청크에 반복 저장되면 유사 벡터가 다수 생성되고, top-k 검색 결과가 “다양한 정보”가 아니라 “비슷한 청크 묶음”으로 채워지는 문제가 발생해요. 화학 RAG 연구에서는 오버랩이 20%를 넘으면 Precision이 급락하고 Recall은 미세하게만 증가하는 비효율적 패턴이 나타나기도 했어요.

📚 중복을 줄일 때 생기는 문맥 단절

반대로 중복을 크게 줄이는 무오버랩(non-overlap) 전략은 복잡한 QA 상황에서 문맥 단절 문제가 즉시 나타나요. 하나의 질문을 구성하는 정보가 문서 여러 위치에 흩어져 있으면, 청크 각각이 일부 정보만 담게 되고 완전하지 않은 답변이 생성되기 쉬워요. MDPI 연구에서도 명제 단위로 지나치게 분리하면 개별 청크의 정확성은 높지만, 중요한 조건이 청크 밖으로 밀리며 Precision이 떨어지는 현상이 관찰되었어요.

 

반대로 의미 기반으로 너무 크게 묶으면 중복이 크게 늘어나 Precision이 하락하는 문제도 함께 나타나요. 그래서 일부 연구에서는 문서 구조와 중복 수준을 자동으로 조정하는 adaptive chunking이 제안되었고, Precision 0.17→0.50, Recall 0.40→0.88처럼 큰 개선 사례도 보고되었어요.

🔗 중복과 문맥을 함께 잡는 절충 전략들

중복과 문맥 보존의 균형을 맞추기 위한 실용적인 방법으로는 계층적 청킹(hierarchical chunking)이 있어요. 작은 청크(128~256 tokens)로 정밀 검색을 수행하고, 검색된 청크들이 동일 부모(1024~2048 tokens)에 많이 포함될 경우 부모 청크를 LLM에 전달하는 방식이에요. Pixion 실험에서는 작은 청크의 높은 Precision과 큰 청크의 풍부한 문맥을 동시에 확보하는 데 효과적이라고 보고되었어요.

 

또 실무에서는 유사도 기반 중복 제거(deduplication)도 널리 사용돼요. 예를 들어 유사도 0.9 이상이면 병합하거나, 대표 청크만 저장하고 나머지는 참조 메타데이터로 처리하는 방식이에요. LLM 입력 단계에서는 동일 청크가 반복 포함되지 않도록 ID 기반 제어도 함께 쓰고요.

 

이와 함께 relational linking·Graph-RAG 방식도 좋은 대안으로 떠올랐어요. 청크를 노드로, 이전/다음 문맥·상하위 구조·표·인용 등을 엣지로 만들어, 필요한 문맥을 추가 인덱싱 없이 이웃 노드에서 동적으로 확장하는 방식이에요. Microsoft GraphRAG에서도 멀티홉 질의에서 높은 성능을 보였다고 해요.

---

📈 한 단계 더 들어가 보기: 청크 크기·오버랩 변화가 nDCG·Latency에 미치는 영향

청크 크기(chunk size)와 오버랩(overlap)이 Retrieval 성능(nDCG, Recall, Precision)과 Latency에 어떤 영향을 주는지는 RAG 최적화의 핵심 실험 항목이에요. 다양한 연구에서는 이 관계가 단순한 직선이 아니라 중간 구간에서 성능 정점이 나타나는 비선형적 특성을 가진다고 보고하고 있어요.

📊 청크 크기·오버랩 변화에 따른 성능 변화

Retrieval 성능은 청크 크기에 따라 뚜렷한 곡선을 그려요. NVIDIA 실험에서는 512·1024 토큰이 가장 높은 성능을 보였고, FinanceBench에서도 1024 토큰(정확도 0.579)이 최적이었어요. 512 토큰(0.550)이나 2048 토큰(0.506)은 오히려 성능이 낮아졌고, RAGBattlePacket 역시 1024 토큰 구성(0.804)이 최적값이었어요. 이는 청크가 너무 길어지면 다양한 주제가 섞여 Precision을 떨어뜨리는 information dilution 문제가 발생한다는 점을 잘 보여줘요.

 

반대로 청크가 지나치게 작으면 문맥 단편화(fragmentation)가 발생해 Recall이 급격히 하락해요. 여러 RAG 벤치마크에서도 공통적으로, 128 토큰 이하의 극소 청크는 nDCG가 0.42 전후까지 떨어지는 등 가장 낮은 성능을 보였어요. 또 의료·법률·금융처럼 문맥 의존도가 높은 도메인 실험에서도, 청크가 너무 작을 때 정밀도(Precision)는 일시적으로 높아지지만 문맥이 부족해 Recall이 반복적으로 희생되는 패턴이 꾸준히 보고되었어요.

 

즉 다양한 분야의 실험 결과에서 한결같이 “너무 작아도 문제, 너무 커도 문제”라는 동일한 곡선 형태가 나타난다는 점이 확인되고 있어요.

 

오버랩 역시 비슷한 양상을 보였어요. 어떤 실험에서는 오버랩을 0%→60%까지 늘려도 Recall은 71.1%→72.5%로 아주 소폭만 증가했어요. 반면 Precision은 꾸준히 낮아져 F1·F2 지표도 거의 개선되지 않았죠.

 

또 다른 실험 유형에서는, 오버랩을 40~60 토큰 정도로 설정했을 때 Recall이 잠시 정점(72.7%)에 도달하기도 했어요. 하지만 동시에 중복 데이터가 크게 늘어나 Precision이 더 빠르게 떨어지면서 전체적인 종합 성능은 오히려 하락하는 결과가 나타났어요.

즉 오버랩을 늘리면
→ 중복 증가
→ 검색 다양성 감소
→ Precision 하락
이라는 흐름이 반복적으로 관찰되고 있어요.

⏱️ Latency 구조와 최적 구간

Latency는 청크 크기·오버랩·Top-k 설정이 함께 작용하는 복합 구조예요. Pixion 실험에서는 동일한 컨텍스트 길이 기준으로 2048 토큰 청크 1개 검색이 256 토큰 청크 8개 검색보다 latency가 낮다고 보고했어요. 작은 청크는 벡터 수가 급격히 늘어나 reranking 비용이 기하급수적으로 증가하기 때문이에요.

 

그렇다고 큰 청크가 항상 유리한 것은 아니에요. 큰 청크는 Top-1 검색 시 all-or-nothing 리스크가 크기 때문에, 첫 청크가 답을 포함하지 않으면 성능이 크게 떨어져요. 반대로 작은 청크는 다양한 후보가 Top-k 안에 포함되어 Recall은 높일 수 있지만 latency 증가라는 대가가 따라붙어요.

 

임베딩 생성 비용도 청크 크기에 비례해 증가해요. 예를 들어 E5-large-v2 기준으로 100 토큰 임베딩은 쿼리 생성 시간의 약 9%를 차지했지만, 500 토큰 임베딩은 27.5%까지 증가했다고 해요. Latency는 검색뿐 아니라 임베딩·프롬프트 구성 등 여러 요소가 함께 작용해 결정돼요.

 

이런 결과를 종합하면 Retrieval 성능과 Latency는 U자형 또는 역U자형 곡선을 그려요.

• 너무 작은 청크 → fragmentation으로 정보 부족
• 너무 큰 청크 → dilution·reranking 비용·latency 증가

그래서 대부분 연구에서는 300~500 토큰 또는 512~1024 토큰 구간이 실제 환경에서 가장 안정적인 sweet spot을 형성한다고 보고해요. Firecrawl·Weaviate·Chroma가 공통적으로 400~600 토큰을 practical optimum으로 제시한 이유도 여기에 있어요.

실무에서는 다음 같은 기준이 자주 활용돼요.

• 청크 크기 실험 축: 128·256·512·1024·2048
• 오버랩 실험 축: 0·10·20·30% (20% 이상은 비용 대비 효과 검증 필요)
• 평가 지표: nDCG@10, Recall@5, Precision@k, F1/F2, P95 Latency
• 도메인 기준: FAQ(256–512), 법률(800–1500), 학술(1000–2000)
• 프로덕션 검증: 지표 + 사용자 A/B 테스트 병행

결론적으로 청크 크기와 오버랩은 고정된 규칙이 아니라, 문서 구조·쿼리 특성·모델 성향·비용 제약을 함께 고려해 실험적으로 찾아야 하는 최적점이라는 사실이 여러 연구에서 반복적으로 확인되고 있어요.

---

특수 데이터 청킹 — 코드·표·수식, 그리고 멀티모달까지

코드·표·수식은 어디까지 분리해야 할까

코드(code), 표(table), 수식(equation)은 자연어 텍스트와 구조도 다르고, 의미가 완성되는 방식도 달라요. 그래서 RAG에서는 일반적인 청킹 규칙만으로는 제대로 처리하기 어려운 경우가 많아요. 이 요소들은 독립된 정보 단위이면서도 동시에 주변 설명과 함께 있어야 의미가 완전해지는 경우가 많기 때문에, 분리할지 통합할지에 따라 Retrieval 성능과 문맥 보존이 크게 달라져요.

🧑‍💻 코드 청킹: AST 기반 분할

먼저 코드 청킹에서는 함수·클래스·블록 단위의 구조적 무결성을 보존하는 것이 가장 중요해요. 라인 단위나 길이 기준으로 분할하면 함수·클래스가 청크 사이에서 잘려 코드 의미가 훼손될 수 있어요. 이런 한계를 보완하기 위해 최근에는 AST(Abstract Syntax Tree) 기반 접근이 많이 사용돼요.

 

여러 실험에서도 AST 기반 방식이 함수·클래스 단위의 자연스러운 경계를 유지해 코드 품질 손실을 크게 줄여준다는 점이 반복적으로 확인되고 있어요. 실제로 Tree-sitter로 생성한 AST를 활용하면 코드 블록을 구조 단위로 안정적으로 분리할 수 있고, CodeRAG 같은 실무 실험 환경에서도 Recall@5와 Pass@1이 모두 개선되는 결과가 보고되었어요. LangChain·LlamaIndex의 CodeTextSplitter 또한 이러한 구조 기반 접근을 따르고 있어요.

📊 표 청킹: 독립 보존 + 자연어 요약

표(table)는 구조상 텍스트 임베딩만으로는 다차원 정보를 충분히 반영하기 어려워요. 한 AI 솔루션 기업에서는 PDF·HTML 표를 구조 보존 상태로 추출한 뒤, 필요 시 표 단위로 분리해 다루는 방식을 권장하고 있어요.

 

또 어떤 RAG 엔진 팀에서는 표 원본은 독립 청크로 유지하고, 자연어 요약을 별도로 임베딩하는 ‘이중 청킹 요약 전략’을 제안하기도 했어요. 이 접근은 표 기반 질의에서 정보를 더 쉽게 찾아낼 수 있어 검색 성능 향상에 도움이 되었다고 해요. 특히 표는 “값 기반 검색”인지, “표 전체 의미 이해”인지 목적에 따라 분리·통합 전략이 크게 달라지기 때문에 상황별 설계가 중요해요.

🧮 수식 청킹: 문맥 결합 + Look-Ahead

수식(equation)은 단독으로 떼어놓으면 의미가 불완전해지기 쉬운 요소예요. 어떤 연구팀은 수식·코드 블록처럼 주변 텍스트와 약하게 연결된 것처럼 보이지만 실제 QA에서는 전후 문맥이 반드시 필요하다는 점을 지적했어요.

 

그래서 기존 청크뿐 아니라 다음 두 청크까지 의미적 연결을 살펴보는 “look-ahead 기반 2단계 병합 방식”을 제안했는데요. 이 접근은 수식 주변 문맥을 안정적으로 보존해 검색 정확도를 크게 높였다는 보고가 있었어요. 수식처럼 문맥 의존성이 큰 요소는 단순 분할보다 “차근차근 주변 설명까지 함께 보존하는 설계”가 훨씬 안정적이에요.

🔗 통합·분리의 절충: 관계 기반 전략

코드·표·수식 청킹에서 분리와 통합은 각각 분명한 장단점이 있어요. 분리하면 독립 검색은 쉬워지지만 문맥이 분리되어 Precision·생성 품질이 떨어지고, 통합하면 문맥은 좋아지지만 청크가 커지면서 임베딩 희석과 latency 부담이 발생하죠.

 

그래서 최근에는 Graph-RAG나 관계형 메타데이터 기반 전략이 각광받고 있어요. 코드·표·수식을 독립 노드로 유지하고, 본문 청크와의 상하위·참조·인접 관계를 그래프로 명시하는 방식이에요. Microsoft GraphRAG, AntGraph 실험에서는 멀티홉 질의나 기술 문서 검색에서 이 방식이 큰 효과를 냈다고 보고돼요.

실무에서는 보통 아래처럼 정리돼요.

• 코드 → AST 기반 함수·클래스 단위 분할
• 표 → 독립 보존 + 자연어 요약 병행
• 수식 → 주변 설명과 통합 + look-ahead 보완
• 원칙 → “가능하면 통합, 필요하면 분리, 분리했다면 반드시 관계 연결”

결국 특수 데이터는 자연어보다 구조가 복잡하기 때문에, 문서 유형·질의 목적·모델 능력·운영 비용을 종합해 최적 전략을 세우는 것이 중요해요.

---

이미지·오디오가 섞인 멀티모달 문서 다루기

멀티모달 RAG는 텍스트뿐 아니라 이미지, 오디오, 비디오처럼 여러 모달리티를 함께 활용하는 방식이에요. 그래서 단일 텍스트 기반 RAG보다 훨씬 복잡한 청킹 전략이 필요해요. 이미지와 비디오는 공간·시각 구조를 갖고 있고, 오디오는 시간 흐름을 따라 전개되며, 비디오는 시청각 요소가 동시에 움직이죠. 이런 특성 때문에 멀티모달 청킹은 단순히 “어디서 자를까?”의 문제가 아니라, 각 모달리티의 시간적·공간적 경계와 텍스트와의 정렬까지 함께 고려해야 하는 설계 문제로 확장돼요.

🖼️ 이미지 청킹: 캡션 + 텍스트 통합

이미지 청킹은 크게 두 가지 방향으로 발전해왔어요.
첫 번째는 이미지를 텍스트 캡션으로 변환해 인접 문단과 함께 하나의 청크로 묶는 방식이에요. 최근 시각·언어 모델들이 이미지 내용을 자연어로 잘 설명해주면서, “그림 1. 구성도” 같은 이미지 정보가 텍스트의 흐름 안에 자연스럽게 포함되는 방식이 자주 소개되고 있어요.

 

두 번째는 이미지를 독립적인 벡터 청크로 저장하는 방식인데,
이 접근은 정확도 측면에서 유용할 수 있지만 시스템 복잡도와 비용이 증가하는 단점이 있어요.
그래서 여러 실무 사례나 기술 노트에서는 “이미지를 텍스트 설명으로 변환한 뒤, 텍스트 RAG와 통합하는 전략이 효율성과 품질 사이에서 적절한 균형을 보인다”는 의견이 자주 언급돼요.
즉, 특정 방식이 ‘정답’이라기보다, 여러 프로젝트에서 안정적이라고 보고된 경향이 있다는 의미예요.

🎬 비디오 청킹: 시간 기반 세그먼트 + 리치 청크

비디오·오디오처럼 시간 축이 있는 데이터는 세그먼트 단위로 나누는 방식이 일반적으로 권장돼요.
여러 실험과 사례에서는 다음과 같은 구간이 문맥 유지와 효율 균형 면에서 적절한 것으로 보고되곤 해요.

• 비디오: 약 10~20초 단위
• 오디오: 약 30~60초 단위

또한 비디오 청킹에서는 단순 자막만 저장하는 것이 아니라, 전사(ASR), 화면 설명, 타임스탬프를 함께 묶어 ‘리치 청크(rich chunk)’ 형태로 구성하면 검색 안정성이 높아진다는 접근이 여러 기술 자료에서 반복적으로 등장해요.
시간 정보와 시각·텍스트 설명이 함께 담기면 특정 장면 검색이 더 정교해지는 경향이 있기 때문이죠.

🎧 오디오 청킹: 전사 기반 + 화자 단위 정렬

오디오는 ASR 전사 품질, 화자 구분(speaker diarization) 정확도에 강하게 의존해요.
기본 절차는

1. 오디오→전사(텍스트),
2. 의미 단위 또는 시간 단위 재청킹

이에요. 특히 화자 전환이 뚜렷한 대화형 데이터라면 화자 단위 청킹이 문맥 일관성을 크게 높여요.
최근 Multi-RAG 연구들은 비디오 프레임과 오디오 전사를 시간축 기반으로 정렬해, 오디오 청크와 비디오 청크가 서로 정확히 대응되도록 만드는 파이프라인을 제안하고 있어요.

🔗 멀티모달 정렬: 모달 간 불일치 해결

멀티모달 청킹에서 가장 까다로운 지점은 모달리티 간 정보가 서로 맞지 않는 상황(misalignment)이에요.
예를 들어, 화면 전환은 이미 다음 장면으로 넘어갔는데 설명은 이전 내용을 계속 말하고 있다면, 단순히 “10초 단위로 자르기” 같은 방식은 서로 다른 의미 단위를 한 청크로 묶어버리게 되죠.

 

이런 불일치는 검색 정확도에도 직접적인 영향을 줘요. 그래서 많은 파이프라인에서는 보통 모달별로 먼저 안정적인 세그먼트를 만든 뒤, 마지막에 정렬을 수행하는 방식을 사용해요.

• 오디오 기반 청킹으로 발화 중심 단위를 먼저 확보하고
• 시각 기반 청킹으로 장면(scene) 단위를 별도로 구분한 뒤
• 타임스탬프·세그먼트 ID·프레임 인덱스 등을 기준으로 서로를 다시 맞춰주는 방식이에요

이 과정을 거치면 “말은 이 장면에서 나왔다”, “영상 속 이 부분은 이 설명과 이어진다”처럼 모달 간 연결이 자연스럽게 복원돼요. 멀티모달 RAG에서 흔히 강조되는 정렬(alignment) 과정이 바로 여기에 해당하죠.

 

정리해보면 다음과 같은 흐름이 가장 자주 언급돼요.

• 이미지는 텍스트 설명(캡션)과 함께 하나의 청크로 묶어두는 전략이 현장에서 안정적이에요.
• 비디오·오디오는 시간 기반 세그먼트로 나눈 뒤, 전사·시각 설명·타임스탬프를 묶어 리치 청크(rich chunk) 형태로 저장하는 방식이 효과적이라는 의견이 많아요.
• 마지막으로, 여러 모달을 타임스탬프 기반으로 정렬하면 크로스모달 검색 정확도가 뚜렷하게 개선되는 경향이 보고되고 있어요.

멀티모달 청킹은 텍스트보다 고려할 요소가 훨씬 많지만, 이렇게 모달별 특징을 먼저 안정적으로 잡아주고 마지막에 정렬하는 흐름을 따르면 훨씬 일관된 성능을 확보할 수 있어요. ✨

---

RAG 파이프라인 설계와 최적화 — 청킹 품질과 도구 활용

RAG 시스템은 겉으로 보면 검색과 생성을 담당하는 LLM 쪽이 중심처럼 보이지만, 실제 성능의 기반은 훨씬 앞쪽에서 깔리곤 해요. 문서가 파이프라인에 들어오는 순간 시작되는 파싱 → 청킹 → 임베딩 → 인덱싱의 흐름은 단순히 기능이 나열된 절차가 아니라, 앞 단계에서 만든 정보가 뒤 단계까지 얼마나 깨지지 않고 이어지는가에 따라 품질의 편차가 결정되는 연속 구조예요. 그래서 실무 최적화의 초점도 자연스럽게 “각 단계의 독립적 성능”보다는 “단계 간 연결성(Connectivity)”을 중심으로 맞춰지게 되죠.

파싱→청킹→임베딩의 유기적 연계

🔍 파싱: 구조적 단서를 최대한 보존하는 출발점

파싱은 흔히 “텍스트를 뽑아오는 단계”처럼 보이지만, 실제로는 이후 단계가 활용할 수 있는 구조적 힌트를 최대한 보존하는 과정이에요. PDF처럼 레이아웃과 실제 구조가 다른 포맷에서는 문단·표·코드 블록이 제대로 복원되지 않으면 다음 단계가 아예 발을 못 붙이게 되고, HTML도 DOM이 어긋나 있으면 문단 경계를 찾기 어려워져요.
즉 파싱은 단순한 시작이 아니라 나머지 전 과정을 떠받치는 토대라서, 여기서 구조가 한번 흔들리면 뒤에서는 복구가 거의 불가능하다는 점이 중요해요.

✂️청킹: 파싱된 구조를 ‘임베딩 가능한 단위’로 연결하는 허리 역할

청킹은 텍스트 조각내기처럼 보이지만, 여기서는 “파싱 단계에서 보존된 구조적 정보를 임베딩이 활용할 수 있는 형태로 재정렬하는 단계”로 보는 것이 더 정확해요. 문단 경계, 표와 코드의 블록 구분, 문장 단서 등은 모두 파싱에서 넘겨준 재료들이고, 청킹은 그 재료들을 흐트러뜨리지 않고 의미 단위로 이어주는 역할을 해요.

 

이 과정이 안정적으로 작동해야 임베딩도 제자리를 잡을 수 있는데, 만약 청킹 단계에서 구조가 뒤섞이거나 메타데이터가 누락되면 그 영향은 고스란히 뒤로 전달돼요. 그래서 실무에서는 청킹이 단독으로 잘 작동하는가보다 파싱—청킹—임베딩이 얼마나 자연스럽게 이어지는가가 더 자주 문제의 원인이 되곤 해요.

🗂️ 임베딩: 의미 표현과 메타데이터 보존의 마지막 연결 지점

임베딩 단계에서는 텍스트만 벡터화하는 것이 아니라, 각 청크가 어느 문서의 어느 위치에서 왔는지와 같은 메타데이터가 함께 연결돼요. 문서 ID, 페이지 번호, 섹션 경로, 표·코드 여부 같은 정보가 검색 단계에서 문맥 재구성을 가능하게 해주기 때문이에요.

이 메타데이터는 앞 단계에서부터 이어져 내려오는 정보라서, 청킹에서 한 번 잘못 정리되면 임베딩은 구조적으로 완전성을 잃게 되죠. 그래서 임베딩 품질 문제처럼 보여도 실제 원인은 청킹에서의 정보 손실인 경우가 실무에서는 정말 자주 발견돼요.

 

이처럼 파싱에서 구조를 최대한 보존하고, 청킹에서 그 구조를 의미 단위로 정리하며, 임베딩에서 텍스트와 메타데이터를 함께 묶어내는 흐름이 안정적으로 이어져야 RAG 전체의 기반 품질이 만들어져요. 결국 특정 단계를 따로 최적화하는 것보다, 앞에서 넘어온 정보가 뒤까지 정확하게 전달되는 흐름 자체를 관리하는 접근이 훨씬 효과적이라는 점이 이 절에서 강조하려는 핵심이에요.

---

운영 품질을 가르는 핵심 지표: 청크 수·길이·토큰 분포

📊 청크 수·길이가 보내는 이상 신호

프로덕션 환경에서 청킹은 LLM 성능을 좌우하는 “전처리의 심장부”이기 때문에, 작은 변화에도 민감하게 반응해야 해요. 특히 문서당 청크 수는 파이프라인이 정상 작동 중인지 가장 먼저 알려주는 지표예요.

 

청크 수가 갑자기 늘거나 줄면 다음 문제가 의심돼요.

• 오버랩 설정 오류로 중복 청크가 폭증
• 파서 레이아웃 해석 실패
• HTML DOM 파손
• 의미 기반 청킹 과정에서 과도한 분리 발생

이런 변화는 곧바로 인덱스 크기 증가 → 검색 지연 증가 → 비용 상승으로 이어져 운영 환경에 큰 영향을 줘요.

📏 토큰 분포 기반 품질 진단

청크 길이가 지나치게 짧아지면 텍스트가 과하게 조각나 개념이 이어지지 않고, 반대로 길어지면 다양한 개념이 한 청크에 섞이면서 임베딩 품질이 급격히 떨어져요. 특히 토큰 분포(P50·P95·P99)는 청킹 품질을 정밀하게 진단하는 지표예요.

 

P99가 급등하는 시점은 대부분 다음 상황이에요.

• 표 또는 코드가 통째로 잘못 합쳐짐
• PDF 구조가 타일 형태로 추출되어 비정상적으로 긴 청크 생성
• 파서 오류로 ‘본문+각주+표 설명’이 한 덩어리로 붙음

이 경우 검색 정확도와 latency가 동시에 악화되어 운영 환경의 체감 품질이 바로 떨어지기 때문에 즉시 조치해야 해요⚡.

🔎 실무 모니터링 패턴

실무에서는 다음과 같은 방식으로 자동 모니터링 체계를 구축해요.

• 평균/표준편차 기반 이상 탐지
• IQR 기반 이상값 제거
• 시계열 기반 sudden drift 감지
• Grafana로 실시간 청크 지표 시각화
• 검색 지표(nDCG·Recall)를 함께 모니터링

특히 drift 감지가 잘 작동하면 “새로운 문서 유형 대량 유입”, “임베딩 모델 교체”, “구조 기반 청킹 정책 변경” 같은 사건을 초기에 발견할 수 있어 파이프라인 안정성 확보에 큰 도움이 돼요.

 

청킹은 고정값이 아니라 운영 데이터를 기반으로 연속적으로 조정해야 하는 동적 구성 요소예요.

---

RAG 도구 기반 청킹 기능과 실전 활용

🧰 RAG 도구들이 제공하는 청킹 기능

RAG 생태계에서는 최근 LangChain·Haystack·LlamaIndex 같은 RAG 프레임워크들이 제공하는 청킹 기능이 널리 활용되고 있어요. 덕분에 고정 규칙 기반·구조 기반·의미 기반 분할을 상황에 맞게 조합하며 빠르게 실험할 수 있는 환경이 마련되었죠.

LangChain

• RecursiveCharacterTextSplitter는 개행→문장→단어 순으로 자연스러운 경계를 고려해 분할해요.
• Markdown·Python 등 포맷 특화 분할기도 제공해 기술 문서 처리에 강해요.

Haystack

• PreProcessor는 문단·문장 등 구조 기반 분할을 안정적으로 유지해 매뉴얼이나 기술 문서에서 좋은 성능을 보여줘요.

LlamaIndex

• TokenTextSplitter는 임베딩 모델의 실제 토크나이저를 활용해 정확한 토큰 단위 분할을 수행해요.
• 컨텍스트 초과를 방지하고 임베딩 안정성을 크게 높여줘요.

이들 도구는 Document/Node 구조, 메타데이터 전달 방식이 서로 다르기 때문에 초기 단계에서 문서 ID·섹션 경로·페이지 번호 같은 메타데이터 스키마를 통일해두면 유지보수와 재인덱싱 부담을 크게 줄일 수 있어요.

🧭 전략적 활용 포인트

• 청킹 도구의 목적을 문서 유형에 따라 명확히 구분해야 해요.
  • 예: 기술 문서는 구조 기반(문단·섹션), 보고서는 의미 기반, 코드는 AST 기반
• 도구 선택보다 중요한 것은 파이프라인 전반의 일관성 유지예요.
  • 즉, 파서→청킹→임베딩→인덱싱이 같은 문서 스키마로 연결되는 구조
• 실험 초기에는 다양한 splitter 전략을 비교해 토큰 분포·Recall 변화를 직접 확인하고, 운영 단계에서는 splitter 변경 자체가 drift를 유발할 수 있으므로 버전 관리가 필수예요.

이처럼 청킹 기능을 RAG 도구들과 함께 구조적으로 통합하면, 검색 정확도와 비용 효율을 동시에 끌어올릴 수 있어요

---

📝 마치며: 청킹은 RAG의 품질을 정하는 ‘조용한 설계자’

이번 3편에서는 RAG 시스템 안에서 쉽게 지나칠 수 있는 단계, 하지만 성능을 결정짓는 데는 가장 예민한 단계인 청킹(Chunking)을 차분히 들여다봤어요. 실제 운영 환경에서 흔들림이 생기는 지점도 대부분 이 단계에서 비롯되곤 하죠.

 

재미있는 건, 청킹을 잘 설계해두면 검색 정확도나 응답 품질 같은 핵심 지표들이 놀라울 만큼 안정적으로 유지된다는 점이에요. 반대로 작은 설정 하나만 빗나가도 전체 파이프라인이 미묘하게 흔들리기 시작하죠. 그래서 청킹은 단순한 “자르기”가 아니라, RAG의 흐름을 설계하는 일에 가까운 작업이라는 사실을 다시 한 번 느낄 수 있었어요.

 

또 하나 중요한 포인트는 도메인과 문서 구조에 따라 최적값이 계속 달라진다는 점이에요. 결국 청킹은 한 번 정하면 끝나는 정적 규칙이 아니라, 운영 데이터와 사용자 피드백을 기반으로 꾸준히 조정해야 하는 ‘살아 있는 구성 요소’예요. 이런 반복적인 점검과 개선이 RAG 품질을 지탱하는 가장 실질적인 기반이 되죠.

 

앞으로 더 많은 기업 문서가 멀티모달로 확장되고, 다양한 포맷이 섞여 들어오면서 청킹 전략은 지금보다 훨씬 더 중요해질 거예요. 그래서 결국 관건은 우리 도메인에 맞는 기준을 세우고, 안정적인 자동화·모니터링 체계를 마련하는 것이에요. 이 기본 설계가 단단하게 잡혀 있으면 RAG 시스템은 문서가 아무리 복잡해져도 흔들리지 않죠!

 

kt cloud도 고객들이 매일 마주하는 그 질문들 “어디서 잘라야 하지?”, “어떻게 해야 안정적으로 운영할 수 있지?”, “우리 도메인에 맞는 최적값은 무엇이지?” 을 함께 고민하며 해결해가고 있어요.

 

kt cloud는 실전 환경에서 축적된 경험과 노하우를 바탕으로, 더 많은 고객이 자신만의 최적화된 RAG를 구축할 수 있도록 지원해 나갈 예정이에요.

RAG가 열어가는 지식 증강 AI의 미래,
kt cloud AI Foundry와 함께라면 더 가깝고 더 현실적인 길이 될 거예요.✨

 

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #1 : 핵심 개념과 시스템 구조 이해

 

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #2 : 데이터 파싱과 전처리 최적화

---

❓ 자주 묻는 질문 (FAQ)

Q. RAG 시스템에서 청킹(Chunking)이 중요한 이유는 무엇인가요?

A. 청킹은 문서를 LLM이 처리 가능한 논리 단위로 분할하는 과정이며, RAG 성능을 좌우하는 핵심 요소입니다. 청크가 너무 작으면 문맥이 단절되어 Recall이 떨어지고, 너무 크면 서로 다른 주제가 섞여 Precision이 감소합니다. 이때 검색 품질 저하는 그대로 생성 품질 저하로 이어져, 실제로 동일한 문서와 임베딩 모델을 사용하더라도 청킹 전략에 따라 Recall이 최대 9%p까지 차이가 발생할 수 있습니다. 또한 청크 크기와 개수는 임베딩·검색·생성 단계의 토큰 예산과 비용에도 직접적 영향을 미칩니다. 따라서 청킹은 단순 전처리가 아니라, 문서 도메인·정보 밀도·사용 시나리오에 맞춰 실험적으로 최적화해야 하는 설계의 중심 요소입니다.

---

📚 관련/출처

https://arxiv.org/html/2410.13070v1 https://arxiv.org/html/2502.15734v1 https://arxiv.org/html/2504.14493v2 https://arxiv.org/html/2402.05131v3 https://arxiv.org/html/2505.23990v1 https://weaviate.io/blog/chunking-strategies-for-rag https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/ https://developer.nvidia.com/blog/nvidia-text-embedding-model-tops-mteb-leaderboard/ https://www.llamaindex.ai/blog/evaluating-the-ideal-chunk-size-for-a-rag-system-using-llamaindex-6207e5d3fec5 https://developers.llamaindex.ai/python/framework-api-reference/node_parsers/token_text_splitter/ https://research.trychroma.com/evaluating-chunking https://www.firecrawl.dev/blog/best-chunking-strategies-rag-2025