Semantic Chunking과 Fixed Chunking의 개념 정의
RAG(Retrieval-Augmented Generation) 시스템이나 AI 자동화 파이프라인을 구축할 때 대규모 문서를 적절한 크기로 나누는 텍스트 청킹(Text Chunking)은 매우 중요한 단계입니다. 텍스트를 어떻게 나누느냐에 따라 AI가 맥락을 이해하는 정확도와 임베딩의 품질이 결정됩니다.
- Fixed-size Chunking (고정 크기 청킹): 글자 수, 단어 수, 또는 토큰 수를 기준으로 텍스트를 일정한 크기로 기계적으로 분할하는 방식입니다. 문맥의 흐름과 상관없이 사전에 설정한 고정된 크기(예: 500토큰)로 텍스트를 자르며, 정보의 단절을 막기 위해 일정 부분(예: 100토큰)을 겹치게 설정하는 오버랩(Overlap) 방식을 주로 활용합니다.
- Semantic Chunking (의미론적 청킹): 텍스트의 구조와 의미적 결합도를 분석하여 의미가 전환되는 지점을 찾아 동적으로 분할하는 방식입니다. 문장 간의 임베딩 유사도를 계산하여 두 문장 사이의 의미적 거리가 일정 기준(Threshold)을 넘어설 때 청크를 분리하므로, 하나의 청크 안에 온전한 하나의 아이디어나 맥락이 보존됩니다.
Fixed Chunking을 선택해야 하는 경우
고정 크기 청킹은 단순하지만 강력하며 특정 비즈니스 환경과 데이터 구조에서 매우 효율적으로 작동합니다. 다음과 같은 상황에서는 Fixed Chunking을 선택하는 것이 유리합니다.
- 데이터의 구조가 정형화되어 있고 규칙적인 경우
- 소스 데이터가 일정한 길이의 리포트, 규격화된 로그 데이터, 혹은 행과 열이 명확한 텍스트 배열일 때는 고정 크기 분할만으로도 충분한 효과를 낼 수 있습니다.
- 컴퓨팅 자원이 제한적이거나 빠른 처리 속도가 필요한 경우
- 고정 크기 분할은 복잡한 AI 모델 연산이나 문장 간 유사도 계산이 필요 없으므로 연산 속도가 극도로 빠릅니다. 대용량의 문서를 실시간으로 처리해야 하거나, 인프라 비용을 최소화해야 하는 대규모 자동화 파이프라인에 적합합니다.
- 토큰 한도가 엄격한 LLM 또는 임베딩 모델을 사용할 경우
- 특정 임베딩 모델이나 소형 LLM(sLLM)을 사용할 때 청크의 크기가 모델의 최대 컨텍스트 윈도우를 초과하면 오류가 발생하거나 텍스트가 잘려 나갑니다. Fixed Chunking은 각 청크의 토큰 크기를 완벽하게 제어할 수 있어 모델의 한계 스펙 안에서 안정적으로 구동됩니다.
Semantic Chunking을 선택해야 하는 경우
문서의 깊은 맥락을 보존하고 생성형 AI의 답변 정확도를 극대화해야 할 때는 의미론적 청킹을 도입해야 합니다. 다음과 같은 조건일 때 Semantic Chunking이 권장됩니다.
- 문서의 주제 전환이 잦고 형식이 자유로운 경우
- 소설, 긴 에세이, 회의록, 종합 정보 안내서와 같이 하나의 문서 안에서 다양한 소주제가 복합적으로 다루어지는 텍스트는 기계적으로 자를 경우 핵심 정보가 두 청크로 쪼개져 의미가 왜설될 수 있습니다. 의미론적 청킹을 통해 주제가 완전히 바뀔 때만 청크를 나누어야 합니다.
- RAG 시스템의 검색 정확도(Retrieval Precision)가 최우선일 경우
- 사용자의 질문에 대해 가장 완벽한 맥락을 가진 청크를 찾아내야 하는 고성능 QA 시스템이나 상담 챗봇의 경우, 의미 단위로 완결성 있게 묶인 청크가 벡터 공간에서 훨씬 더 정확하게 검색됩니다.
- 법률, 의료, 복잡한 정책 지침서 문서를 다룰 경우
- 단어 하나나 문맥의 누락이 결과의 왜곡을 초래할 수 있는 전문 도메인 데이터의 경우, 인과관계가 담긴 전후 문장이 하나의 청크에 묶여 있어야 AI가 오답(Hallucination)을 내지 않고 올바른 답변을 생성할 수 있습니다.
두 방식의 핵심 비교 및 선택 기준
적절한 청킹 전략을 선택하기 위해 두 방식의 기술적, 운영적 차이점을 직관적으로 비교할 수 있습니다.
| 비교 항목 | Fixed-size Chunking | Semantic Chunking |
| 분할 기준 | 설정된 토큰/글자 수 및 오버랩 크기 | 문장 간 임베딩 유사도 및 의미 변화 지점 |
| 연산 비용 | 매우 낮음 (단순 문자열/토큰 분할) | 높음 (문장별 임베딩 생성 및 유사도 계산 필요) |
| 맥락 보존력 | 낮음 (문장 중간이나 단어 내부에서 잘릴 위험 존재) | 높음 (하나의 완결된 아이디어가 한 청크에 보존) |
| 처리 속도 | 밀리초(ms) 단위의 즉각적인 분할 가능 | 모델 연산으로 인해 문서 크기에 비례하여 시간 소요 |
| 적합한 도메인 | 정형 데이터, 로그, 대량의 단순 텍스트 아카이빙 | 법률, 학술 논문, 심층 분석 리포트, 복잡한 QA 시스템 |
최종 선택을 위한 가이드라인
최적의 청킹 방식을 결정할 때는 데이터의 특성, 예산, 목표 성능을 종합적으로 고려해야 합니다.
- 비용과 속도가 중요하다면 Fixed Chunking으로 시작: 초기 RAG 프로토타입을 구축하거나 API 호출 비용을 아끼고 싶다면, 512토큰 크기에 10%~20% 수준의 오버랩을 설정한 Fixed Chunking을 먼저 적용해 본 뒤 성능을 측정하는 것이 좋습니다.
- 답변의 질과 컨텍스트 매칭이 최우선이라면 Semantic Chunking 도입: 시스템 성능 테스트 중 AI가 쪼개진 정보 때문에 엉뚱한 대답을 하거나 문맥을 놓치는 현상이 자주 발생한다면, 비용과 속도를 다소 타협하더라도 Semantic Chunking을 적용하여 데이터의 품질을 높여야 합니다.
- 하이브리드 접근법 고려: 제목, 소제목, 문단 태그가 잘 갖춰진 마크다운(Markdown)이나 HTML 문서라면, 1차적으로 문서의 구조적 태그를 기준으로 나눈 뒤(Recursive/Structural Chunking) 그 내부에서 고정 크기나 의미론적 청킹을 결합하는 방식도 훌륭한 대안이 됩니다.