RAG(Retrieval-Augmented Generation) 시스템을 처음 구축하고 나면 기대에 부풀어 이런저런 질문을 던져보게 됩니다. 그런데 막상 답변을 받아보면 의외의 벽에 부딪히는 경우가 많습니다. 분명 문서 안에 있는 내용인데 AI가 찾질 못하거나, 엉뚱한 문맥을 끌어와서 답변이 횡설수설하는 상황 말입니다. 임베딩 모델을 바꿔보고, 프롬프트를 다듬어보고, 벡터 데이터베이스 설정도 이리저리 건드려보지만 근본적인 개선이 잘 되지 않습니다.

사실 RAG 답변 품질의 열쇠는 의외로 파이프라인의 가장 앞단에 숨어 있습니다. 바로 문서를 어떻게 나누느냐, 즉 청킹(Chunking) 전략입니다. 아무리 뛰어난 임베딩 모델과 LLM을 사용해도 원본 문서가 적절하게 분할되지 않으면 검색 결과 자체가 부정확해집니다. 정보의 맥락이 중간에서 잘린 채 검색되거나, 너무 많은 내용이 한 덩어리로 뭉쳐서 핵심을 놓치는 일이 반복됩니다.

이 글에서는 RAG 성능을 근본부터 좌우하는 청킹 전략을 깊이 있게 살펴봅니다. 가장 기본적인 고정 크기 분할부터 2026년 현재 주목받고 있는 최신 기법까지, 각 방법의 원리와 장단점 그리고 어떤 상황에서 어떤 전략을 선택해야 하는지를 구체적으로 안내해 드리겠습니다.

청킹이란 무엇이고, 왜 이렇게 중요한가

청킹(Chunking)은 원본 문서를 일정한 기준에 따라 더 작은 텍스트 조각으로 나누는 과정입니다. RAG 파이프라인에서 청킹은 가장 첫 번째 단계에 해당합니다. 원본 문서를 청크로 나눈 뒤 각 청크를 임베딩 벡터로 변환하고, 사용자 질문이 들어오면 질문과 가장 유사한 청크를 검색해서 LLM에 전달하는 것이 RAG의 기본 흐름이죠.

여기서 핵심 포인트가 있습니다. LLM이 참고하는 정보의 품질은 검색된 청크의 품질에 전적으로 의존한다는 것입니다. 검색 단계에서 잘못된 청크가 넘어오면 LLM이 아무리 뛰어나도 정확한 답변을 만들어낼 수 없습니다. 이른바 Garbage In, Garbage Out 원칙이 RAG에서도 그대로 적용되는 셈입니다.

청킹이 RAG 성능에 미치는 영향을 구체적으로 살펴보면 크게 세 가지 측면이 있습니다.

• 검색 정밀도(Precision): 청크가 너무 크면 관련 없는 내용이 함께 검색됩니다. 질문과 직접 관련된 한두 문장 때문에 수천 자짜리 텍스트 전체가 딸려오면서 LLM의 주의가 분산됩니다.
• 검색 재현율(Recall): 반대로 청크가 너무 작으면 하나의 개념이 여러 조각으로 흩어져서, 정작 필요한 맥락 정보를 놓치게 됩니다. 예를 들어 원인과 결과가 서로 다른 청크에 담기면 전체 그림을 파악하기 어렵습니다.
• 의미 보존(Semantic Coherence): 문장 중간이나 문단의 논리적 흐름이 끊기는 지점에서 잘리면 청크 자체의 의미가 불완전해집니다. 임베딩 벡터도 부정확해지고, 검색 품질이 떨어집니다.

결국 청킹은 이 세 가지 요소 사이에서 최적의 균형점을 찾는 작업입니다. 어떤 전략을 선택하느냐에 따라 같은 문서, 같은 모델을 쓰더라도 체감 성능이 크게 달라집니다. 실제로 여러 벤치마크 연구에서 청킹 전략 변경만으로 답변 정확도가 20~40% 이상 개선된 사례가 보고되고 있습니다.

핵심 청킹 전략 다섯 가지 비교

현재 널리 사용되는 청킹 전략은 크게 다섯 가지로 나눌 수 있습니다. 각각의 원리와 적합한 사용 사례를 자세히 살펴보겠습니다.

1. 고정 크기 청킹 (Fixed-size Chunking)

가장 단순하고 직관적인 방법입니다. 문서를 일정한 글자 수 또는 토큰 수 단위로 기계적으로 잘라냅니다. 예를 들어 500토큰씩 끊는다고 설정하면 문서의 처음부터 끝까지 정확히 500토큰 단위로 분할됩니다.

장점은 구현이 매우 간단하고 처리 속도가 빠르다는 것입니다. 어떤 형태의 문서든 일관된 크기의 청크를 만들어내므로 벡터 저장소의 관리도 쉽습니다. 대량의 문서를 빠르게 처리해야 할 때 기본 베이스라인으로 적합합니다.

단점은 문장이나 문단의 의미 경계를 전혀 고려하지 않는다는 것입니다. 문장 중간에서 잘리는 일이 빈번하게 발생합니다. 예를 들어 계약서에서 조항의 조건과 결과가 서로 다른 청크에 담기면 의미 파악이 불가능해집니다. 임베딩 품질도 떨어지고 검색 정확도에 악영향을 줍니다.

적합한 상황: 빠른 프로토타이핑, 구조가 단순한 텍스트(채팅 로그, 짧은 게시글 모음), 성능 베이스라인 측정용.

2. 문장·단락 기반 청킹 (Sentence/Paragraph Chunking)

텍스트의 자연어 구조를 존중하는 방법입니다. 마침표, 줄바꿈, 빈 줄 등 자연어의 구분점을 기준으로 문장 또는 단락 단위로 나눕니다. 보통 NLP 라이브러리의 문장 분리기(sentence tokenizer)를 활용하거나, 간단하게는 정규표현식으로 마침표와 줄바꿈을 기준 삼아 분할합니다.

장점은 문장 단위의 의미 완결성이 보장된다는 것입니다. 각 청크가 최소한 하나의 완전한 문장으로 시작하고 끝나므로 임베딩 품질이 고정 크기 방식보다 월등히 좋아집니다. 구현도 비교적 간단한 편입니다.

단점은 청크 크기가 들쭉날쭉해진다는 것입니다. 한 문장짜리 청크가 생길 수도 있고, 아주 긴 문단은 통째로 하나의 거대한 청크가 되기도 합니다. 또한 여러 문장에 걸쳐 전개되는 논리(예: 원인 → 과정 → 결과)가 서로 다른 청크로 나뉠 수 있습니다.

적합한 상황: 뉴스 기사, 블로그 포스트, 일반 산문 형태의 문서. 문장 구조가 비교적 균일하고 독립적인 정보 단위가 문장/문단과 잘 일치하는 경우.

3. 재귀적 문자 청킹 (Recursive Character Chunking)

LangChain의 RecursiveCharacterTextSplitter로 널리 알려진 방법입니다. 여러 단계의 구분자를 우선순위대로 적용하여 텍스트를 나눕니다. 보통 빈 줄(문단 구분) → 줄바꿈 → 마침표 → 공백 순서로 분할을 시도하고, 각 청크가 설정한 최대 크기 이하가 될 때까지 재귀적으로 분할을 반복합니다.

장점은 의미 경계를 최대한 존중하면서도 청크 크기를 일정 범위 안에서 통제할 수 있다는 것입니다. 고정 크기와 문장 기반의 장점을 절충한 실용적인 방법이라 할 수 있습니다. 가장 큰 단위(문단)로 먼저 나누려고 시도하고, 그래도 크면 더 작은 단위로 내려가는 방식이라 의미 손실을 최소화합니다.

단점은 구분자의 순서와 최대 크기 설정에 따라 결과가 크게 달라진다는 것입니다. 범용적인 기본 설정이 있긴 하지만 문서 유형마다 미세 조정이 필요한 경우가 많습니다. 또한 본질적으로 텍스트의 표면 구조(구분 문자)에 의존하므로 의미적 연결까지는 파악하지 못합니다.

적합한 상황: 범용적인 RAG 시스템의 기본 전략으로 가장 많이 선택됩니다. 다양한 종류의 문서를 처리해야 하는 상황에서 합리적인 출발점입니다. 많은 RAG 프레임워크에서 기본값으로 채택하고 있을 정도로 검증된 방법입니다.

4. 의미 기반 청킹 (Semantic Chunking)

텍스트의 표면 구조가 아닌 실제 의미 변화를 감지하여 분할하는 고급 기법입니다. 각 문장을 임베딩 벡터로 변환한 뒤, 인접한 문장들 사이의 코사인 유사도를 계산합니다. 유사도가 급격히 떨어지는 지점, 즉 주제가 전환되는 지점을 청크의 경계로 삼습니다.

장점은 같은 주제에 대해 이야기하는 문장들이 하나의 청크로 자연스럽게 묶인다는 것입니다. 고정 크기나 재귀적 방식에서는 놓칠 수 있는 의미적 연결을 보존할 수 있어 검색 품질이 크게 향상됩니다. 특히 하나의 문서 안에서 여러 주제가 자유롭게 오가는 텍스트(회의록, 인터뷰 전사본, 포럼 스레드 등)에서 위력을 발휘합니다.

단점은 모든 문장을 미리 임베딩해야 하므로 전처리 비용이 상당히 높다는 것입니다. 특히 대량의 문서를 처리할 때는 시간과 비용이 급격히 증가합니다. 또한 유사도 임계값(threshold) 설정이 까다로운데, 이 값이 너무 낮으면 청크가 과도하게 잘게 나뉘고, 너무 높으면 서로 다른 주제가 하나의 청크에 섞입니다.

적합한 상황: 비정형 텍스트, 주제 전환이 잦은 문서, 높은 검색 품질이 중요한 핵심 문서. 처리 비용을 감당할 수 있는 환경에서 프리미엄 전략으로 적합합니다.

5. 문서 구조 기반 청킹 (Document Structure Chunking)

문서 자체의 구조적 요소를 활용하는 방법입니다. HTML의 헤딩 태그(h1, h2, h3), 마크다운의 제목 기호(#), PDF의 목차 구조, 코드 파일의 함수/클래스 경계 등 문서 형식이 제공하는 구조 정보를 청킹 기준으로 사용합니다.

장점은 문서 작성자가 의도한 논리 구조를 그대로 활용한다는 것입니다. 기술 문서, 법률 문서, 학술 논문처럼 체계적으로 구조화된 문서에서는 섹션과 하위 섹션이 곧 의미 단위이므로 가장 자연스러운 청킹이 가능합니다. 또한 메타데이터(섹션 제목, 계층 정보)를 청크에 함께 저장하면 검색 시 필터링과 맥락 파악에 큰 도움이 됩니다.

단점은 문서에 구조 정보가 없으면 적용할 수 없다는 것입니다. 순수 텍스트 파일이나 구조가 불규칙한 문서에서는 무용지물입니다. 또한 하나의 섹션이 매우 길 경우 추가적인 분할 전략을 병행해야 합니다.

적합한 상황: 기술 문서(API 레퍼런스, 매뉴얼), 법률 문서(계약서, 약관), 학술 논문, 위키 문서 등 명확한 구조를 갖춘 문서.

청크 크기와 오버랩, 최적의 균형점 찾기

어떤 청킹 전략을 선택하든 반드시 결정해야 하는 두 가지 핵심 파라미터가 있습니다. 바로 청크 크기(Chunk Size)와 오버랩(Overlap)입니다. 이 두 값의 설정이 RAG 성능에 미치는 영향은 전략 선택 못지않게 큽니다.

청크 크기의 영향

청크 크기는 하나의 청크에 담기는 텍스트의 양을 결정합니다. 보통 토큰 수 또는 문자 수로 지정하며, 일반적으로 200토큰에서 2000토큰 사이에서 설정합니다.

작은 청크(200~500토큰)를 사용하면 검색 정밀도가 높아집니다. 각 청크가 좁은 주제를 다루므로 질문과 정확히 일치하는 정보를 찾아낼 확률이 올라갑니다. 사실 확인(fact-checking) 성격의 질문, 즉 구체적인 수치나 날짜를 찾는 질문에 특히 효과적입니다. 반면 넓은 맥락이 필요한 질문에는 불리합니다. 하나의 청크만으로는 충분한 배경 정보를 제공하지 못할 수 있습니다.

큰 청크(1000~2000토큰)를 사용하면 풍부한 맥락을 담을 수 있습니다. 원인과 결과, 논증의 전개, 개념 간의 관계 등 복합적인 정보가 하나의 청크 안에 보존됩니다. 요약형 질문이나 설명을 요구하는 질문에 적합합니다. 다만 관련 없는 정보가 함께 딸려올 가능성도 커지고, LLM의 컨텍스트 윈도우를 비효율적으로 사용하게 됩니다.

오버랩의 역할

오버랩은 인접한 청크들이 서로 공유하는 텍스트 영역입니다. 예를 들어 청크 크기가 500토큰이고 오버랩이 100토큰이면, 첫 번째 청크의 마지막 100토큰이 두 번째 청크의 시작 100토큰과 동일합니다.

오버랩이 중요한 이유는 청크 경계에서 발생하는 정보 손실을 완화하기 때문입니다. 하나의 개념이 두 청크에 걸쳐 있을 때 오버랩 영역 덕분에 양쪽 청크 모두에서 해당 정보의 일부를 포함하게 됩니다. 오버랩이 전혀 없으면 경계 지점의 문맥이 완전히 단절되어 검색에서 누락될 수 있습니다.

일반적으로 청크 크기의 10~20%를 오버랩으로 설정하는 것이 좋은 출발점입니다. 500토큰 청크라면 50~100토큰 정도의 오버랩이 적절합니다. 너무 큰 오버랩은 저장 공간 낭비와 중복 검색 결과를 초래하므로 주의가 필요합니다.

문서 유형별 권장 설정

모든 상황에 맞는 만능 설정은 없지만, 출발점으로 삼을 만한 권장 범위를 정리하면 다음과 같습니다.

• 기술 문서, API 레퍼런스: 청크 크기 300~500토큰, 오버랩 50토큰. 개별 항목이 비교적 독립적이므로 작은 청크가 유리합니다.
• 일반 산문(뉴스, 블로그, 보고서): 청크 크기 500~800토큰, 오버랩 100토큰. 문단 단위의 맥락을 살리면서 적절한 크기를 유지합니다.
• 법률 문서, 계약서: 청크 크기 800~1500토큰, 오버랩 200토큰. 조항 간의 상호 참조가 많으므로 넉넉한 맥락이 필요합니다.
• 학술 논문: 청크 크기 600~1000토큰, 오버랩 150토큰. 섹션 구조와 병행하면 효과적입니다.
• 코드 문서: 청크 크기를 함수 또는 클래스 단위로 설정. 고정 크기보다 구조 기반 청킹이 훨씬 효과적입니다.

이 수치는 어디까지나 시작점입니다. 실제 운영에서는 자신의 문서와 질문 패턴에 맞춰 실험하고 조정하는 과정이 반드시 필요합니다.

2026년 주목할 차세대 청킹 기법

기본 전략들이 어느 정도 성숙한 가운데, 최근에는 보다 지능적인 청킹 기법들이 등장하여 RAG 성능의 새로운 가능성을 열고 있습니다. 2026년 현재 특히 주목받고 있는 세 가지 기법을 소개합니다.

컨텍스추얼 청킹 (Contextual Chunking)

Anthropic이 2024년 말에 소개하여 큰 반향을 일으킨 기법입니다. 핵심 아이디어는 단순합니다. 각 청크에 문서 전체 맥락을 요약한 짧은 설명을 앞에 붙여주는 것입니다.

예를 들어 회사 연간 보고서의 3분기 매출 데이터가 담긴 청크가 있다면, 이 청크 앞에 해당 문서가 어떤 회사의 몇 년도 연간 보고서이고, 이 청크가 보고서의 재무 섹션에서 3분기 매출을 다루고 있다는 맥락 정보를 짧게 추가합니다. 이 맥락 문장은 LLM을 활용하여 자동으로 생성할 수 있습니다.

효과가 놀랍습니다. 원래 청크만으로는 이 숫자들이 어떤 회사의 어떤 기간 데이터인지 알 수 없었지만, 맥락 정보가 추가되면 임베딩이 훨씬 풍부해지고 검색 정확도가 크게 올라갑니다. 벤치마크에서 검색 실패율을 최대 49%까지 줄였다는 보고가 있을 정도입니다.

다만 모든 청크에 대해 LLM 호출이 필요하므로 전처리 비용이 증가합니다. 문서 수가 많지 않은 고품질 지식 베이스나, 검색 정확도가 비즈니스 핵심인 경우에 투자 대비 효과가 큽니다.

레이트 청킹 (Late Chunking)

기존 방식은 먼저 텍스트를 청크로 나눈 뒤 각 청크를 개별적으로 임베딩합니다. 레이트 청킹은 이 순서를 뒤집습니다. 문서 전체를 먼저 임베딩 모델에 통과시켜 토큰별 벡터를 얻은 뒤, 그 다음에 청크 경계를 적용하여 각 청크의 벡터를 풀링하는 방식입니다.

이 접근의 장점은 각 토큰의 임베딩이 문서 전체의 맥락을 반영한 상태에서 만들어진다는 것입니다. 일반적인 청킹 후 임베딩에서는 각 청크가 고립된 텍스트로 처리되어 문맥 정보가 손실되지만, 레이트 청킹에서는 전체 문서 문맥이 자연스럽게 보존됩니다. 대명사 참조나 암묵적 맥락 같은 요소가 임베딩에 반영되어 검색 품질이 향상됩니다.

현재 Jina AI 등에서 이 방식을 지원하는 임베딩 모델과 도구를 제공하고 있으며, 2026년 들어 주류 RAG 프레임워크에도 통합이 진행되고 있습니다. 다만 긴 문서를 통째로 임베딩 모델에 넣어야 하므로 모델의 최대 입력 길이 제한에 영향을 받습니다.

프로포지션 기반 청킹 (Proposition Chunking)

텍스트를 문장이나 문단이 아닌 독립적인 명제(proposition) 단위로 분해하는 기법입니다. 하나의 문장이 여러 사실을 포함하고 있다면 각각의 사실을 별도의 명제로 분리합니다. 예를 들어 서울은 대한민국의 수도이며 인구가 약 950만 명이다 라는 문장은 서울은 대한민국의 수도이다, 서울의 인구는 약 950만 명이다 두 개의 명제로 분리됩니다.

각 명제는 다른 정보에 의존하지 않고 독립적으로 의미가 통하도록 정리됩니다. 대명사는 원래 지칭하는 명사로 치환되고, 암묵적인 주어나 맥락은 명시적으로 추가됩니다.

이렇게 하면 각 청크가 하나의 명확한 사실만을 담게 되어 정밀 검색에 매우 유리합니다. 구체적인 사실을 찾아야 하는 질의응답 시나리오에서 높은 성능을 보여줍니다. 반면 명제 추출 과정에 LLM 호출이 필요하고, 전체적인 논리 흐름이나 맥락이 파편화될 수 있다는 한계가 있습니다.

부모-자식 청킹 (Parent-Child Chunking)

하나의 전략만 쓰는 것이 아니라 서로 다른 크기의 청킹을 계층적으로 조합하는 방법입니다. 작은 청크(자식)로 정밀 검색을 수행하되, 실제 LLM에는 해당 청크를 포함하는 큰 청크(부모)를 전달합니다.

예를 들어 문서를 먼저 2000토큰짜리 부모 청크로 나누고, 각 부모 청크를 다시 200토큰짜리 자식 청크로 세분화합니다. 벡터 검색은 200토큰 자식 청크를 대상으로 수행하여 가장 관련 있는 지점을 정밀하게 찾아내고, LLM에는 해당 자식이 속한 2000토큰짜리 부모 청크를 넘겨서 충분한 맥락을 제공합니다.

작은 청크의 검색 정밀도와 큰 청크의 맥락 풍부함을 동시에 얻을 수 있어 실전에서 매우 효과적입니다. LlamaIndex 같은 프레임워크에서 이 패턴을 공식적으로 지원하고 있으며, 2026년 현재 프로덕션 RAG 시스템에서 가장 인기 있는 고급 기법 중 하나입니다.

실전에서 바로 쓰는 청킹 최적화 팁

지금까지 다양한 청킹 전략과 파라미터를 살펴보았습니다. 마지막으로 실제 RAG 시스템에 청킹을 적용할 때 반드시 기억해야 할 실전 팁들을 정리합니다.

문서 전처리가 절반이다

아무리 좋은 청킹 전략을 써도 원본 문서의 품질이 나쁘면 효과가 반감됩니다. 청킹 전에 반드시 해야 할 전처리 작업들이 있습니다.

• 불필요한 요소 제거: 머리글, 바닥글, 페이지 번호, 목차 중복, 광고 텍스트 등 실제 내용과 무관한 요소를 제거합니다.
• 인코딩 정리: 깨진 문자, 특수 유니코드, 불필요한 공백 연속을 정리합니다.
• 표와 이미지 처리: 표는 텍스트로 변환하되 행/열 관계가 보존되도록 합니다. 이미지의 캡션이나 대체 텍스트를 별도로 추출합니다.
• 중복 제거: 동일하거나 거의 동일한 내용이 여러 문서에 반복되는 경우 중복을 식별하고 처리합니다.

메타데이터를 적극 활용하라

청크에 텍스트만 저장하는 것은 큰 낭비입니다. 각 청크에 메타데이터를 함께 저장하면 검색 품질을 크게 높일 수 있습니다.

• 출처 정보: 파일명, 문서 제목, 작성일, 작성자
• 구조 정보: 섹션 제목, 계층 경로(예: 매뉴얼 → 설치 가이드 → 시스템 요구사항), 페이지 번호
• 유형 정보: 문서 종류(계약서, 매뉴얼, FAQ 등), 언어, 보안 등급

이 메타데이터를 벡터 검색과 결합하면 하이브리드 검색이 가능해집니다. 예를 들어 벡터 유사도로 관련 청크를 찾되, 메타데이터 필터로 특정 문서나 섹션으로 범위를 좁힐 수 있습니다. 또한 LLM에 청크를 전달할 때 출처 정보를 함께 주면 답변에 인용 표시를 붙이도록 유도할 수 있습니다.

하나의 전략에 얽매이지 마라

서로 다른 종류의 문서에는 서로 다른 청킹 전략이 적합합니다. 하나의 RAG 시스템에서 여러 유형의 문서를 처리해야 한다면, 문서 유형을 자동으로 감지하고 적합한 청킹 전략을 선택하는 라우팅 로직을 구현하는 것이 좋습니다.

예를 들어 마크다운 문서는 구조 기반 청킹을, 일반 텍스트는 재귀적 청킹을, 코드 파일은 AST(Abstract Syntax Tree) 기반 청킹을 각각 적용하는 식입니다. 이런 하이브리드 접근이 단일 전략보다 실전에서 훨씬 좋은 결과를 냅니다.

반드시 평가하고 반복하라

청킹 전략의 효과는 추측이 아니라 측정으로 확인해야 합니다. 다음과 같은 간단한 평가 루프를 권장합니다.

• 테스트 질문 세트 준비: 실제 사용자들이 물어볼 법한 질문 20~50개를 만들고, 각 질문에 대한 정답과 정답이 담긴 원본 문서 위치를 기록합니다.
• 검색 품질 측정: 각 질문에 대해 검색된 청크들이 실제 정답을 포함하고 있는지 확인합니다. 검색 재현율(Recall@K)이 핵심 지표입니다.
• 답변 품질 평가: 최종 답변이 정답과 일치하는지, 환각이 없는지 확인합니다. 소규모 세트라면 사람이 직접 평가하고, 규모가 크면 LLM 기반 자동 평가를 활용합니다.
• 전략 변경 후 비교: 청킹 전략이나 파라미터를 바꾼 뒤 동일한 테스트 세트로 다시 측정하여 개선 여부를 객관적으로 확인합니다.

이 과정을 거치지 않으면 감에 의존하게 되고, 실제로는 성능이 나빠졌는데도 모르고 지나칠 수 있습니다. 체계적인 평가야말로 청킹 최적화의 가장 확실한 도구입니다.

비용과 성능의 균형을 의식하라

시맨틱 청킹, 컨텍스추얼 청킹, 프로포지션 청킹 같은 고급 기법들은 분명 성능이 뛰어나지만 전처리 비용도 상당합니다. 수천 개의 문서를 처리해야 하는 대규모 시스템에서 모든 문서에 최고급 기법을 적용하는 것은 현실적이지 않을 수 있습니다.

실전에서는 문서의 중요도에 따라 청킹 전략의 수준을 차등 적용하는 것이 합리적입니다. 핵심 지식 베이스에는 컨텍스추얼 청킹을, 보조 문서에는 재귀적 청킹을, 로그성 데이터에는 고정 크기 청킹을 적용하는 식으로 비용 대비 효과를 최적화할 수 있습니다.

마무리

RAG 시스템의 성능을 높이기 위해 많은 분들이 임베딩 모델이나 LLM에 집중하지만, 실제로 가장 큰 개선 효과를 가져오는 것은 종종 청킹 전략의 변경입니다. 같은 문서, 같은 모델을 쓰더라도 문서를 어떻게 나누느냐에 따라 검색 결과의 질이 극적으로 달라지니까요.

이 글에서 소개한 다양한 전략 중 어느 것이 정답이라고 단정할 수는 없습니다. 정답은 여러분의 문서와 사용 시나리오에 맞는 전략을 실험과 평가를 통해 찾아가는 과정 속에 있습니다. 다만 한 가지 확실한 것은, 청킹에 신경 쓰는 것만으로도 RAG 시스템의 체감 품질이 눈에 띄게 좋아진다는 사실입니다.

오늘 소개한 내용을 참고하여 여러분의 RAG 파이프라인을 한 단계 업그레이드해 보시기 바랍니다. 재귀적 청킹부터 시작해서 점진적으로 고급 기법을 도입하면 부담 없이 성능을 끌어올릴 수 있을 것입니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.