청크 분할 전략(chunking strategy), 임베딩 전략(embedding strategy)

잘난 척을 위한 한 줄 요약

청크 분할 전략이 “문서를 어떻게 잘라 검색 가능한 단위로 만들 것인가”의 문제라면, 임베딩 전략은 그 조각들을 AI가 의미적으로 찾을 수 있는 좌표로 어떻게 바꿀 것인가의 문제다.

 

청크 분할 전략과 임베딩 전략, RAG 품질은 왜 문서 자르는 방식에서 갈릴까?

먼저, 청크 분할과 임베딩이 뭔지부터

RAG 시스템을 만들 때 가장 먼저 부딪히는 문제가 있다.

 

문서가 너무 길다는 것이다.

 

PDF 한 권, 사내 매뉴얼, 회의록 묶음, 법령집, 논문, 고객 상담 기록을 그대로 LLM에게 넣기는 어렵다. 넣을 수 있다고 해도 비용이 많이 들고, 검색 정확도도 떨어질 수 있다.

 

그래서 문서를 작은 단위로 나눈다.

 

이 작은 단위를 청크(chunk)라고 한다.

 

청크 분할 전략(chunking strategy)은 긴 문서를 어떤 기준으로 잘라 검색하기 좋은 조각으로 만들 것인지 정하는 방법이다.

 

그다음 각 청크를 숫자 벡터로 바꾼다.

 

이 과정을 임베딩(embedding)이라고 한다.

 

임베딩은 텍스트의 의미를 숫자 좌표로 바꾸는 작업이다. 비슷한 의미의 문장은 벡터 공간에서 가까운 위치에 놓이게 된다.

 

흐름은 이렇다.

원본 문서
→ 청크로 분할
→ 각 청크를 임베딩
→ 벡터DB에 저장
→ 사용자 질문도 임베딩
→ 의미가 가까운 청크 검색
→ LLM이 검색 결과를 참고해 답변

 

쉽게 말하면 이렇다.

 

청크 분할은 문서를 검색 가능한 조각으로 자르는 일이고, 임베딩은 그 조각에 의미 좌표를 붙이는 일이다.

 

왜 청크 분할이 중요할까

RAG에서 청크 분할은 생각보다 훨씬 중요하다.

 

많은 사람은 RAG 품질이 LLM 성능이나 벡터DB 성능에서 결정된다고 생각한다.

 

물론 중요하다.

 

하지만 문서를 잘못 자르면 좋은 모델도 엉뚱한 답을 한다.

 

예를 들어 이런 문장이 있다고 해보자.

계약 해지는 계약 만료 30일 전까지 서면으로 통보해야 한다.
다만 서비스 장애가 7일 이상 지속된 경우에는 즉시 해지할 수 있다.

 

 

그런데 청크가 이렇게 잘렸다고 하자.

청크 1: 계약 해지는 계약 만료 30일 전까지 서면으로 통보해야 한다.
청크 2: 다만 서비스 장애가 7일 이상 지속된 경우에는 즉시 해지할 수 있다.

 

질문이 “장애가 계속되면 계약을 바로 해지할 수 있나요?”라면 청크 2만 검색될 수 있다.

 

그 자체로는 답이 가능해 보이지만, 이 조항이 계약 해지 조건의 예외라는 맥락은 약해질 수 있다.

 

반대로 청크가 너무 크면 문제가 생긴다.

 

관련 없는 내용이 너무 많이 들어가 검색 정확도가 떨어진다.

 

즉, 청크는 너무 작아도 안 되고, 너무 커도 안 된다.

 

청크 분할 전략의 핵심은 검색에 필요한 의미 단위를 잃지 않으면서도, 너무 많은 잡음을 넣지 않는 것이다.

 

LangChain 문서도 텍스트에는 문단, 문장, 단어 같은 자연스러운 구조가 있으므로, 이 구조를 활용하면 자연스러운 흐름과 의미적 일관성을 유지하는 분할을 만들 수 있다고 설명한다.

 

청크가 너무 작으면 생기는 문제

청크가 너무 작으면 문맥이 사라진다.

 

예를 들어 문서를 문장 하나씩만 자른다고 해보자.

청크 1: 이 제도는 2026년부터 시행된다.
청크 2: 대상자는 일정 요건을 충족한 중소기업이다.
청크 3: 신청은 온라인 시스템을 통해 가능하다.

 

각 문장은 짧고 깔끔하다.

 

하지만 문제는 “이 제도”가 무엇인지, “대상자”가 누구인지, “신청”이 무엇에 대한 신청인지 모호해진다는 점이다.

 

짧은 청크는 검색에는 잘 걸릴 수 있지만, 답변에 필요한 맥락이 부족할 수 있다.

 

이럴 때 LLM은 검색된 조각을 과하게 해석하거나, 앞뒤 문맥을 상상으로 메울 수 있다.

 

청크가 너무 크면 생기는 문제

반대로 청크가 너무 크면 검색이 흐려진다.

 

하나의 청크에 여러 주제가 섞인다.

 

예를 들어 3,000토큰짜리 청크 안에 다음 내용이 모두 들어 있다고 해보자.

 

계약 해지
환불 조건
개인정보 처리
서비스 장애
위약금
고객지원 절차

 

사용자가 “서비스 장애 시 환불 조건”을 물으면 이 큰 청크가 검색될 수 있다.

 

하지만 LLM에게 전달되는 정보 안에는 관련 없는 내용도 많다.

 

이러면 답변이 길어지고, 핵심 근거를 놓치거나, 관련 없는 조항을 섞을 수 있다.

 

큰 청크의 문제는 검색된 것 같지만 정확히 검색된 것은 아닌 상태를 만든다는 점이다.

 

좋은 청크의 조건

좋은 청크는 다음 조건을 만족해야 한다.

 

첫째, 하나의 주제를 중심으로 한다.

 

둘째, 질문에 답할 만큼 충분한 맥락을 가진다.

 

셋째, 불필요하게 긴 잡음을 포함하지 않는다.

 

넷째, 출처와 위치를 추적할 수 있다.

 

다섯째, 표·목록·코드·제목 같은 구조를 깨지 않는다.

 

여섯째, 임베딩 모델의 입력 길이를 넘지 않는다.

 

좋은 청크는 “작은 문서”처럼 읽혀야 한다.

 

문서의 파편이 아니라, 독립적으로 어느 정도 의미가 통해야 한다.

 

대표적인 청크 분할 전략

청크 분할 전략은 여러 가지가 있다.

 

1. 고정 길이 분할

가장 단순한 방식이다.

 

예를 들어 500토큰마다 자른다.

0~500토큰
501~1000토큰
1001~1500토큰

 

장점은 구현이 쉽고 빠르다는 것이다.

 

단점은 문장이나 문단 중간이 잘릴 수 있다는 것이다.

 

특히 법률 문서, 매뉴얼, 논문처럼 문맥이 중요한 문서에서는 의미가 끊길 수 있다.

 

고정 길이 분할은 실험용이나 아주 단순한 문서에는 괜찮지만, 실무에서는 단독으로 쓰기보다 다른 전략과 결합하는 편이 좋다.

 

2. 오버랩 분할

오버랩은 청크 사이에 일부 문맥을 겹치게 넣는 방식이다.

 

예를 들어 청크 크기를 500토큰, 오버랩을 100토큰으로 잡으면 이렇게 된다.

청크 1: 0~500토큰
청크 2: 400~900토큰
청크 3: 800~1300토큰

 

이렇게 하면 경계 부분에서 중요한 문장이 잘려도 다음 청크에 일부 남는다.

 

오버랩은 문맥 손실을 줄이는 데 도움이 된다.

 

하지만 오버랩이 너무 크면 중복 저장이 많아진다.

 

벡터DB 비용이 늘고, 검색 결과가 비슷한 청크로 도배될 수 있다.

 

보통 오버랩은 “문맥 보존”과 “중복 비용” 사이의 타협이다.

 

3. 문단 기준 분할

문단을 기준으로 자르는 방식이다.

 

블로그 글, 보고서, 정책 문서처럼 문단 단위가 의미를 갖는 문서에 잘 맞는다.

 

문단은 보통 하나의 생각 단위를 담고 있다.

 

그래서 문단을 유지하면 의미가 덜 깨진다.

 

다만 문단 길이가 들쭉날쭉할 수 있다.

 

어떤 문단은 너무 짧고, 어떤 문단은 너무 길다.

 

그래서 문단 기준 분할도 보통 최대 토큰 길이 제한과 함께 쓴다.

 

4. 제목·섹션 기준 분할

문서의 제목, 소제목, 장, 절 구조를 활용하는 방식이다.

 

예를 들어 Markdown 문서라면 #, ##, ### 같은 헤더를 기준으로 나눌 수 있다.

## 환불 정책
## 계약 해지
## 개인정보 처리
## 장애 대응 절차

 

이 방식은 구조화된 문서에 강하다.

 

청크에 제목 정보를 메타데이터로 넣으면 검색 품질도 좋아진다.

 

예를 들어 청크 본문만 보면 “30일 전 서면 통보”라고 되어 있어도, 메타데이터에 “계약 해지”가 있으면 의미가 더 명확해진다.

 

LangChain은 Markdown, HTML, JSON, 코드 등 다양한 문서 구조에 맞춘 text splitter를 제공하며, 문서 구조를 유지하는 분할이 가능하다.

 

5. 재귀적 분할

실무에서 가장 많이 쓰는 기본 전략 중 하나가 재귀적 분할(recursive splitting)이다.

 

재귀적 분할은 큰 단위부터 작은 단위로 차례대로 나눈다.

 

예를 들어 이런 순서다.

문단 기준으로 나눔
→ 너무 길면 문장 기준으로 나눔
→ 그래도 길면 단어 기준으로 나눔
→ 그래도 길면 문자 기준으로 나눔

 

이 방식의 장점은 가능한 한 자연스러운 경계를 유지하려고 한다는 점이다.

 

LangChain의 RecursiveCharacterTextSplitter는 대표적인 재귀적 분할 도구이며, 문서를 분할해 downstream 작업에 쓸 수 있는 Document 객체를 만들거나 문자열 목록으로 나눌 수 있다.

 

쉽게 말하면 재귀적 분할은 “일단 문단 단위로 자르고, 안 되면 문장 단위로 더 잘게 자르는 방식”이다.

 

초기 RAG를 만들 때 가장 무난한 출발점이다.

 

6. 의미 기반 분할

의미 기반 분할(semantic chunking)은 문장 사이의 의미 변화가 큰 지점을 찾아 청크를 나누는 방식이다.

 

예를 들어 앞부분은 “계약 해지”를 설명하고, 중간부터 “환불 조건”으로 주제가 바뀐다면 그 지점에서 자르는 것이다.

 

이 방식은 단순 길이 기준보다 더 자연스러울 수 있다.

 

하지만 단점도 있다.

 

문장 임베딩을 추가로 계산해야 하므로 비용이 든다.
구현이 더 복잡하다.
모든 문서에서 항상 더 좋은 것은 아니다.

 

LlamaIndex 문서는 semantic splitter가 고정된 청크 크기 대신 문장 사이의 임베딩 유사도를 활용해 의미 변화 지점에서 분할한다고 설명한다.

 

최근 연구에서도 의미 기반 청킹이 항상 단순 전략보다 우월한 것은 아니라는 결과가 있다. 2026년 학술 텍스트 대상 평가에서는 클러스터 기반 semantic chunking이 고정 크기나 recursive chunking보다 일관되게 더 좋은 성능을 보이지는 않았다고 보고했다.

 

즉, semantic chunking은 멋있지만 만능키는 아니다.

 

7. 구조 인식 분할

구조 인식 분할(structure-aware chunking)은 문서의 실제 구조를 최대한 보존하는 방식이다.

 

특히 다음 문서에서 중요하다.

 

PDF
논문
법령
계약서
매뉴얼
표가 많은 문서
코드 문서
프레젠테이션
기술 명세서

 

예를 들어 표를 중간에 잘라버리면 의미가 망가진다.

항목 | 금액 | 조건
A | 100만 원 | 30일 이내
B | 200만 원 | 60일 이내

 

이 표를 행과 열이 깨지게 자르면 검색해도 답변이 어려워진다.

 

2026년 오일·가스 기업 문서 대상 연구는 고정 크기, 재귀적 분할, 의미 기반 분할, 구조 인식 분할을 비교했고, 구조 인식 청킹이 전체 검색 성능과 top-K 지표에서 더 좋은 결과를 보였다고 보고했다. 특히 표가 많거나 전문 구조가 있는 문서에서는 구조 보존이 중요하다고 결론냈다.

 

문서가 복잡할수록 “몇 토큰마다 자를까?”보다 “문서 구조를 어떻게 살릴까?”가 더 중요해진다.

 

청크 크기는 몇 토큰이 좋을까

정답은 없다.

 

문서 유형, 질문 유형, 임베딩 모델, 검색 방식, LLM 컨텍스트, 비용에 따라 달라진다.

 

그래도 감각적으로는 이렇게 볼 수 있다.

문서 유형	추천 출발점
FAQ, 짧은 지식문서	200~500토큰
블로그, 설명문, 일반 보고서	500~1,000토큰
법률·계약·규정 문서	조항 단위 + 300~800토큰
논문·기술문서	섹션 단위 + 500~1,200토큰
코드	함수·클래스 단위
표 중심 문서	표 단위 보존 + 설명 메타데이터
회의록	발언 주제·안건 단위

중요한 것은 처음부터 완벽한 숫자를 찾으려 하지 않는 것이다.

 

일단 기준값으로 시작하고, 실제 질문 세트로 평가하면서 조정해야 한다.

 

청크 오버랩은 얼마나 줘야 할까

오버랩도 정답은 없다.

 

하지만 일반적으로는 청크 크기의 10~20% 정도에서 시작할 수 있다.

 

예를 들어 청크가 800토큰이면 오버랩은 80~160토큰 정도를 실험해볼 수 있다.

 

오버랩이 필요한 경우는 다음과 같다.

 

문장 경계가 자주 끊긴다.
앞뒤 문맥 의존이 크다.
계약서나 규정처럼 예외 조항이 중요하다.
답변에 근거 문맥이 필요하다.

 

오버랩을 줄여도 되는 경우는 다음과 같다.

 

FAQ처럼 항목이 독립적이다.
문서가 제목별로 잘 구조화되어 있다.
각 청크가 독립적인 Q&A 단위다.
중복 검색이 너무 많이 나온다.

 

오버랩은 보험이다.

 

하지만 보험료가 너무 비싸지면 안 된다.

 

메타데이터가 중요한 이유

청크를 만들 때 본문만 저장하면 아쉽다.

 

반드시 메타데이터를 함께 저장하는 것이 좋다.

 

예를 들면 다음과 같다.

 

문서명
작성일
수정일
작성자
부서
페이지 번호
장·절 제목
문서 유형
버전
권한 등급
표 번호
원본 URL
언어
유효 기간

 

메타데이터는 검색 품질을 크게 높인다.

 

예를 들어 사용자가 “2025년 규정 기준으로 알려줘”라고 물으면 작성일이나 버전 메타데이터가 필요하다.

 

“인사팀 문서에서 찾아줘”라고 하면 부서 메타데이터가 필요하다.

 

“최신 문서만 참고해줘”라고 하면 수정일이 필요하다.

 

즉, 청크는 본문만으로 검색되는 것이 아니라, 메타데이터와 함께 검색될 때 훨씬 강해진다.

 

임베딩 전략이란 무엇일까

청크를 만들었다면 이제 임베딩해야 한다.

 

임베딩 전략(embedding strategy)은 어떤 텍스트를, 어떤 모델로, 어떤 단위로, 어떤 방식으로 벡터화해 저장하고 검색할지 정하는 전략이다.

 

질문은 꽤 많다.

 

어떤 임베딩 모델을 쓸 것인가?
청크 본문만 임베딩할 것인가?
제목과 메타데이터도 포함할 것인가?
한국어 문서에 맞는 모델인가?
다국어 문서도 처리해야 하는가?
질문과 문서에 같은 임베딩 모델을 쓸 것인가?
임베딩 차원은 몇인가?
비용과 속도는 어떤가?
재임베딩 정책은 어떻게 할 것인가?

 

임베딩은 RAG의 검색 엔진이다.

 

LLM이 아무리 좋아도, 검색이 잘못되면 답변도 흔들린다.

 

임베딩은 무엇을 저장하는가

임베딩은 텍스트를 숫자 배열로 바꾼 것이다.

 

예를 들어 다음 두 문장을 보자.

계약 해지는 만료 30일 전 서면 통보가 필요하다.
계약을 끝내려면 종료 30일 전에 문서로 알려야 한다.

 

단어는 다르지만 의미는 비슷하다.

 

좋은 임베딩 모델은 이 두 문장을 벡터 공간에서 가깝게 배치한다.

 

반면 다음 문장은 멀리 배치해야 한다.

신규 장비 구매 비용은 다음 분기 예산에 반영한다.

 

즉, 임베딩의 핵심은 문자 그대로의 일치가 아니라 의미적 가까움이다.

 

임베딩 모델 선택 기준

임베딩 모델을 고를 때는 다음 기준을 봐야 한다.

 

1. 언어 지원

한국어 문서라면 한국어 검색 성능이 중요하다.

 

영어 모델이 한국어도 어느 정도 처리할 수 있지만, 실제 도메인 문서에서는 성능 차이가 날 수 있다.

 

다국어 문서라면 multilingual embedding 모델을 검토해야 한다.

 

2. 도메인 적합성

일반 문서인지, 법률인지, 의료인지, 금융인지, 코드인지에 따라 좋은 모델이 다르다.

 

법률 문서에서는 조항과 예외 조건을 잘 잡아야 한다.
코드 문서에서는 함수명과 의미를 잘 연결해야 한다.
고객 상담 문서에서는 유사 표현을 잘 잡아야 한다.

 

3. 입력 길이

임베딩 모델마다 한 번에 받을 수 있는 토큰 길이가 다르다.

 

청크가 모델 입력 길이를 넘으면 잘리거나 오류가 날 수 있다.

 

따라서 청크 크기와 임베딩 모델의 입력 제한은 함께 설계해야 한다.

 

4. 비용

임베딩은 한 번만 하는 것처럼 보이지만, 문서가 계속 추가되면 비용이 쌓인다.

 

대규모 문서 저장소라면 임베딩 비용과 재임베딩 비용을 고려해야 한다.

 

5. 속도

실시간 업로드, 대량 문서 처리, 자주 바뀌는 지식베이스에서는 임베딩 속도도 중요하다.

 

6. 검색 성능

최종적으로는 실제 질문 세트에서 얼마나 관련 문서를 잘 찾는지가 중요하다.

 

벤치마크 점수보다 내 문서와 내 질문에서의 성능이 더 중요하다.

 

청크 본문만 임베딩하면 충분할까

항상 그렇지는 않다.

 

청크 본문만 임베딩하면 문맥이 부족할 수 있다.

 

예를 들어 본문이 이렇게 되어 있다고 하자.

30일 전까지 서면으로 통보해야 한다.

 

이 문장만 보면 무엇을 30일 전까지 통보해야 하는지 알기 어렵다.

 

하지만 제목을 함께 붙이면 의미가 명확해진다.

[계약 해지 절차]
30일 전까지 서면으로 통보해야 한다.

 

 

그래서 실무에서는 임베딩할 텍스트를 이렇게 구성하는 경우가 많다.

문서명: 서비스 이용계약서
섹션: 계약 해지
본문: 30일 전까지 서면으로 통보해야 한다.

 

이렇게 하면 검색할 때 “계약 해지 통보” 질문과 더 잘 연결될 수 있다.

 

다만 모든 메타데이터를 본문에 넣으면 잡음이 생길 수 있다.

 

임베딩에 넣을 메타데이터와 필터용으로만 쓸 메타데이터를 구분해야 한다.

 

임베딩에 넣을 것과 필터로 둘 것

메타데이터는 두 가지 방식으로 활용할 수 있다.

 

첫째, 임베딩 텍스트에 포함한다.

 

둘째, 벡터DB의 필터 조건으로 저장한다.

 

예를 들어 “계약 해지”라는 섹션 제목은 의미 검색에 도움이 되므로 임베딩 텍스트에 포함하는 것이 좋다.

 

반면 “문서 ID: DOC-2025-0007” 같은 값은 의미 검색에는 큰 도움이 되지 않는다. 이런 것은 필터용 메타데이터로 두면 된다.

정보	임베딩 포함	필터 메타데이터
제목	좋음	좋음
섹션명	좋음	좋음
문서 유형	경우에 따라 좋음	좋음
작성일	보통 불필요	매우 중요
부서	경우에 따라 좋음	중요
페이지 번호	보통 불필요	중요
권한 등급	불필요	필수
문서 ID	불필요	필수
버전	경우에 따라	중요

핵심은 이렇다.

 

의미 검색에 도움이 되는 정보는 임베딩에 넣고, 검색 범위를 제한하는 정보는 메타데이터 필터로 둔다.

 

질문 임베딩과 문서 임베딩

RAG에서는 사용자 질문도 임베딩한다.

 

그리고 질문 벡터와 문서 청크 벡터의 유사도를 비교한다.

 

여기서 중요한 점은 질문과 문서가 표현 방식이 다르다는 것이다.

 

질문은 짧고 의도 중심이다.

계약 중도 해지 가능한가요?

 

 

문서는 길고 규정 중심이다.

서비스 장애가 7일 이상 지속되는 경우 이용자는 즉시 계약을 해지할 수 있다.

 

좋은 임베딩 모델은 이 둘을 연결해야 한다.

 

만약 질문과 문서의 표현 차이가 크다면, 단순 임베딩 검색만으로는 부족할 수 있다.

 

이때는 다음 전략을 쓸 수 있다.

 

질문 재작성
HyDE
하이브리드 검색
리랭킹
쿼리 확장
도메인 용어 사전
동의어 처리

 

하이브리드 검색이 필요한 이유

임베딩 검색은 의미 유사도에 강하다.

 

하지만 정확한 키워드에는 약할 수 있다.

 

예를 들어 다음 질문을 보자.

제382조의2 집중투표제 요건 알려줘.

 

이 질문에는 “제382조의2”라는 정확한 조문 번호가 중요하다.

 

임베딩 검색만 쓰면 의미적으로 비슷한 회사법 문서를 찾을 수는 있지만, 정확한 조문 번호 매칭이 약할 수 있다.

 

이럴 때는 키워드 검색과 벡터 검색을 결합하는 하이브리드 검색이 좋다.

 

키워드 검색은 정확한 단어, 숫자, 코드, 조항, 제품명에 강하다.

 

벡터 검색은 의미가 비슷한 표현에 강하다.

 

둘을 결합하면 더 안정적이다.

벡터 검색: 의미적으로 관련된 청크 찾기
키워드 검색: 정확한 용어·번호·고유명사 찾기
리랭커: 최종 순서 재정렬

 

실무 RAG에서는 벡터 검색만 믿는 것보다 하이브리드 검색이 더 안전한 경우가 많다.

 

리랭킹 전략

검색 결과를 바로 LLM에게 넣지 않고, 한 번 더 정렬하는 과정을 리랭킹(reranking)이라고 한다.

 

예를 들어 벡터DB에서 top 20개 청크를 가져온다.

 

그다음 리랭커 모델이 질문과 각 청크의 관련성을 더 정밀하게 평가한다.

 

최종적으로 top 5개만 LLM에게 넣는다.

 

이 방식은 검색 품질을 높이는 데 효과적이다.

 

임베딩 검색은 빠르지만 거칠다.

 

리랭커는 느리지만 정밀하다.

 

그래서 둘을 조합한다.

1차 검색: 빠르게 후보 20~50개 확보
2차 리랭킹: 정밀하게 상위 3~10개 선택

 

청크 분할과 임베딩이 아무리 좋아도, 비슷한 청크가 많거나 질문이 복잡하면 리랭킹이 큰 차이를 만들 수 있다.

 

문서 유형별 청크 분할 전략

문서마다 좋은 청크 방식은 다르다.

 

1. FAQ

FAQ는 질문과 답변 한 쌍이 자연스러운 청크다.

Q: 환불은 언제 되나요?
A: 결제 취소 후 영업일 기준 3~5일 이내 환불됩니다.

 

FAQ를 억지로 500토큰 단위로 자를 필요가 없다.

 

Q&A 한 쌍을 유지하는 것이 가장 중요하다.

 

2. 계약서·약관

계약서는 조항 단위가 중요하다.

 

제1조, 제2조, 제3조 같은 조항 구조를 유지해야 한다.

 

특히 단서 조항, 예외, 정의 조항이 중요하다.

 

계약서에서는 청크 본문에 조항 번호와 제목을 포함하는 것이 좋다.

제7조 계약 해지
...

 

 

3. 논문

논문은 섹션 구조가 중요하다.

 

초록, 서론, 방법론, 실험, 결과, 한계, 참고문헌을 구분해야 한다.

 

질문 유형에 따라 검색할 섹션이 다르다.

 

“이 논문의 핵심 기여는?”은 초록·서론·결론이 중요하다.

“실험 설정은?”은 방법론과 실험 섹션이 중요하다.

 

4. 회의록

회의록은 발언자보다 안건 중심으로 자르는 것이 유리한 경우가 많다.

 

안건
결정사항
액션아이템
담당자
기한
리스크

 

이런 구조를 메타데이터로 보존하면 좋다.

 

5. 코드

코드는 함수, 클래스, 파일, 모듈 단위가 중요하다.

 

문자 수 기준으로 자르면 함수가 중간에 잘릴 수 있다.

 

코드 RAG에서는 함수 전체, docstring, import, class context를 잘 유지해야 한다.

 

LangChain reference에는 PythonCodeTextSplitter, JSFrameworkTextSplitter 등 코드와 프레임워크 구조에 맞춘 splitter도 제공된다.

 

6. 표가 많은 문서

표는 절대 함부로 자르면 안 된다.

 

표 제목, 열 이름, 행 정보가 함께 있어야 한다.

 

가능하면 표 전체를 하나의 청크로 유지하고, 너무 크면 의미 있는 행 그룹으로 나누어야 한다.

 

또 표를 자연어 설명으로 변환해 함께 임베딩하는 것도 도움이 된다.

 

임베딩 전략의 대표 패턴

1. 기본 임베딩

가장 단순한 방식이다.

 

청크 본문을 그대로 임베딩한다.

embedding(chunk_text)

 

초기 실험에 좋다.

 

하지만 제목, 섹션, 문서 맥락이 부족할 수 있다.

 

2. 제목 포함 임베딩

청크 본문 앞에 문서명과 섹션명을 붙인다.

문서명: 환불 정책 가이드
섹션: 장애 발생 시 환불
본문: ...

 

검색 정확도가 좋아지는 경우가 많다.

 

3. 요약 임베딩

청크가 너무 길거나 복잡할 때, 청크 요약을 만들어 요약문을 임베딩한다.

 

장점은 검색이 깔끔해질 수 있다는 것이다.

 

단점은 요약 과정에서 세부 정보가 사라질 수 있다는 것이다.

 

그래서 원문 청크와 요약 청크를 함께 저장하는 방식도 쓴다.

 

4. 다중 벡터 임베딩

하나의 문서나 청크에 여러 벡터를 붙인다.

 

예를 들어 하나의 문서에 대해 다음을 각각 임베딩한다.

 

제목
요약
본문 청크
키워드
가상 질문

 

이 방식은 검색 진입점을 늘린다.

 

사용자가 어떤 표현으로 물어도 관련 문서에 닿을 가능성이 커진다.

 

5. 가상 질문 임베딩

문서 청크에서 나올 법한 질문을 미리 생성하고, 그 질문을 임베딩해 저장하는 방식이다.

 

예를 들어 청크 내용이 환불 정책이라면 다음 가상 질문을 만든다.

환불은 며칠 걸리나요?
결제 취소 후 언제 돈이 들어오나요?
카드 환불 처리 기간은 얼마인가요?

 

사용자 질문은 문서 본문보다 질문 형태와 더 비슷하기 때문에 검색 성능이 좋아질 수 있다.

 

다만 생성 비용과 관리 비용이 늘어난다.

 

6. HyDE

HyDE는 Hypothetical Document Embeddings의 약자다.

 

사용자 질문에 대해 LLM이 가상의 답변 문서를 먼저 만들고, 그 가상 문서를 임베딩해 검색하는 방식이다.

 

질문이 너무 짧거나 애매할 때 도움이 될 수 있다.

 

예를 들어 사용자가 “집중투표제”라고만 물으면 질문이 너무 짧다.

 

LLM이 “집중투표제는 소수주주가 이사 선임 시 표를 몰아 행사할 수 있는 제도...” 같은 가상 설명문을 만든 뒤 검색하면, 관련 문서와 더 잘 연결될 수 있다.

 

단점은 LLM 호출 비용이 늘고, 가상 답변이 잘못되면 검색도 흔들릴 수 있다는 점이다.

 

청크 분할과 임베딩은 따로 설계하면 안 된다

청크 분할과 임베딩은 서로 연결되어 있다.

 

청크가 너무 크면 임베딩이 뭉개진다.

 

하나의 벡터가 너무 많은 의미를 담게 되기 때문이다.

 

청크가 너무 작으면 임베딩은 정확해 보이지만 문맥이 부족하다.

 

그래서 좋은 전략은 두 가지를 함께 맞추는 것이다.

질문이 구체적이면 → 작은 청크 + 정밀 검색
질문이 넓으면 → 큰 청크 또는 요약 청크 + 리랭킹
문서 구조가 중요하면 → 구조 인식 청킹 + 메타데이터
고유명사가 중요하면 → 하이브리드 검색
긴 문맥이 필요하면 → 작은 검색 청크 + 주변 청크 확장

 

특히 “검색용 청크”와 “생성용 문맥”을 분리하는 전략이 유용하다.

 

검색은 작은 청크로 정확히 찾고, 답변에는 그 청크의 앞뒤 문맥까지 확장해 넣는 방식이다.

 

이를 small-to-big retrieval 또는 parent-child chunking이라고 부르기도 한다.

 

Parent-Child Chunking

Parent-Child Chunking은 작은 청크와 큰 청크를 함께 쓰는 방식이다.

 

작은 청크는 검색용이다.

큰 청크는 답변용이다.

 

예를 들어 문서를 섹션 단위 parent로 나누고, 그 안을 문단 단위 child로 나눈다.

Parent: 제7조 계약 해지 전체
Child 1: 일반 해지 조건
Child 2: 장애 발생 시 즉시 해지
Child 3: 해지 통보 방식

 

사용자 질문은 Child 청크에서 정확히 검색한다.

 

하지만 LLM에게는 해당 Child가 속한 Parent 전체를 넣어준다.

 

이렇게 하면 검색 정확도와 문맥 보존을 동시에 잡을 수 있다.

 

주변 청크 확장 전략

검색된 청크만 넣지 않고 앞뒤 청크를 함께 넣는 방식도 있다.

 

예를 들어 청크 5가 검색되면, 청크 4와 청크 6도 함께 가져온다.

검색 결과: 청크 5
LLM 입력: 청크 4 + 청크 5 + 청크 6

 

이 방식은 문맥 복원에 도움이 된다.

 

하지만 관련 없는 주변 청크가 많으면 잡음이 늘 수 있다.

 

따라서 섹션 안에서만 확장하거나, 같은 문서·같은 제목 아래에서만 확장하는 식으로 제한하는 것이 좋다.

 

청크 분할 전략의 실패 사례

실패 1. 문장 중간 절단

계약 해지는 서비스 장애가 7일 이상 지속되는 경우

 

여기서 청크가 끝나버리면 조건이 불완전하다.

 

실패 2. 표 헤더 분리

청크 1: 항목 | 금액 | 조건
청크 2: A | 100만 원 | 30일 이내

 

청크 2만 검색되면 열의 의미가 사라진다.

 

실패 3. 정의 조항 분리

계약서에서 “서비스”의 정의가 앞에 있고, 권리·의무가 뒤에 있으면 정의 조항을 놓치기 쉽다.

 

실패 4. 버전 섞임

2024년 정책과 2026년 정책이 같은 벡터DB에 섞였는데 메타데이터 필터가 없으면 오래된 문서가 검색될 수 있다.

 

실패 5. 중복 청크 과다

오버랩을 너무 크게 주면 비슷한 청크가 top-K를 모두 차지한다.

 

그 결과 다양한 근거를 찾지 못한다.

 

임베딩 전략의 실패 사례

실패 1. 한국어 성능이 낮은 모델 사용

한국어 문서인데 영어 중심 임베딩 모델을 쓰면 유사 표현을 잘 못 잡을 수 있다.

 

실패 2. 고유명사 검색 실패

제품명, 조항번호, 사람 이름, 코드명은 임베딩 검색만으로 놓칠 수 있다.

 

이 경우 키워드 검색과 하이브리드 검색이 필요하다.

 

실패 3. 메타데이터 미활용

최신 문서를 찾아야 하는데 작성일을 저장하지 않으면 오래된 문서가 답변에 섞인다.

 

실패 4. 재임베딩 정책 없음

임베딩 모델을 바꾸거나 문서가 수정됐는데 기존 벡터를 그대로 두면 검색 품질이 흔들린다.

 

실패 5. 질문 유형을 고려하지 않음

사실 확인 질문, 비교 질문, 요약 질문, 절차 질문은 필요한 청크가 다르다.

 

질문 유형별 검색 전략이 없으면 답변 품질이 일정하지 않다.

 

평가가 중요한 이유

청크 분할과 임베딩 전략은 감으로 정하면 안 된다.

 

반드시 평가해야 한다.

평가용 질문 세트를 만든다.

 

예를 들어 사내 문서 RAG라면 이런 질문을 준비한다.

환불 조건은?
계약 해지 예외는?
교육과정 수료 기준은?
프로젝트 평가 방식은?
2026년 기준 지원금 조건은?

 

각 질문에 대해 정답 근거 문서를 정한다.

 

그다음 검색 결과를 본다.

 

정답 청크가 top 3 안에 나오는가?
정답 청크가 top 5 안에 나오는가?
검색된 청크가 답변에 충분한가?
오래된 문서가 섞이지 않는가?
표와 조항이 깨지지 않는가?
LLM이 근거를 정확히 인용하는가?

 

최근 연구들도 청킹 전략의 성능은 문서 형식과 질문 유형, 전처리 상태에 크게 달라질 수 있음을 보여준다. 학술 텍스트 대상 평가에서는 질문 유형과 문서 포맷에 따라 고정형, 재귀형, 의미 기반 청킹의 성능이 달라졌다고 보고했다.

 

즉, 좋은 전략은 정해져 있는 것이 아니라, 내 데이터에서 검증해야 한다.

 

실무용 기본 조합

처음 RAG를 만든다면 다음 조합으로 시작할 수 있다.

1. 문서 구조 보존
2. Recursive splitting
3. 500~1,000토큰 청크
4. 10~20% 오버랩
5. 제목·섹션명 포함 임베딩
6. 문서명·날짜·페이지·버전 메타데이터 저장
7. 벡터 검색 + 키워드 검색 하이브리드
8. top 20 검색 후 top 5 리랭킹
9. 검색된 청크의 주변 문맥 확장
10. 평가 질문 세트로 반복 튜닝

 

이 조합은 만능은 아니지만 출발점으로는 무난하다.

 

그다음 문서 유형에 따라 조정하면 된다.

 

계약서는 조항 단위로.
코드는 함수 단위로.
표는 표 단위로.
회의록은 안건 단위로.
FAQ는 Q&A 단위로.
논문은 섹션 단위로.

 

비유로 이해해보자

청크 분할과 임베딩은 도서관 정리와 비슷하다.

 

책 한 권을 통째로 서가에 꽂아두면 찾기 어렵다.

 

그렇다고 문장을 하나씩 찢어 카드로 만들면 맥락이 사라진다.

 

좋은 도서관은 책을 장, 절, 주제, 키워드, 색인, 분류번호로 정리한다.

 

청크 분할은 책을 적당한 장·절 단위로 나누는 일이다.

 

임베딩은 각 장·절에 “이 내용은 어떤 의미를 가진다”는 좌표를 붙이는 일이다.

 

메타데이터는 도서관의 분류번호다.

 

리랭킹은 사서가 “이 질문에는 이 자료가 더 정확합니다”라고 다시 골라주는 과정이다.

 

즉, RAG는 단순히 문서를 넣는 기술이 아니라, AI가 찾기 좋은 도서관을 설계하는 일이다.

 

자주 헷갈리는 포인트

1. 청크는 작을수록 좋은가?

아니다. 작으면 검색은 날카로울 수 있지만 문맥이 부족해진다. 질문에 답할 만큼의 의미 단위는 유지해야 한다.

 

2. 청크는 클수록 좋은가?

아니다. 크면 문맥은 많지만 검색이 흐려지고 잡음이 늘어난다.

 

3. 오버랩은 많이 줄수록 좋은가?

아니다. 오버랩은 문맥 손실을 줄이지만 중복 저장과 중복 검색을 늘린다.

 

4. 임베딩 검색만으로 충분한가?

항상 그렇지는 않다. 조항번호, 제품명, 날짜, 코드, 고유명사가 중요한 경우 키워드 검색과 하이브리드 검색이 필요하다.

 

5. semantic chunking이 항상 최고인가?

아니다. 의미 기반 분할은 비용이 더 들고, 문서 유형에 따라 단순 재귀 분할이나 구조 인식 분할보다 나을 수도, 그렇지 않을 수도 있다. 최근 평가 연구에서도 semantic chunking이 항상 단순 전략을 이기지는 않았다.

 

결국 핵심은 이것이다

청크 분할 전략과 임베딩 전략은 RAG의 기초공사다.

 

청크 분할은 문서를 검색 가능한 의미 단위로 자르는 일이다.
임베딩은 그 의미 단위를 벡터 공간의 좌표로 바꾸는 일이다.

 

한마디로 정리하면 이렇다.

 

청크 분할이 잘못되면 찾을 조각이 망가지고, 임베딩 전략이 잘못되면 좋은 조각도 엉뚱한 위치에 저장된다.

 

그래서 RAG 품질은 LLM만으로 결정되지 않는다.

 

문서를 어떻게 자르는지,
제목과 메타데이터를 어떻게 붙이는지,
어떤 임베딩 모델을 쓰는지,
키워드 검색과 벡터 검색을 어떻게 섞는지,
리랭킹을 하는지,

평가 질문으로 검증하는지가 모두 중요하다.

 

처음부터 복잡한 전략을 쓸 필요는 없다.

 

하지만 최소한 이것만은 기억해야 한다.

 

RAG에서 검색 품질은 답변 품질의 천장이다.

 

LLM은 검색된 근거 안에서 답한다.

 

그러니 좋은 RAG를 만들고 싶다면, 모델보다 먼저 문서를 잘라야 한다.

 

참고 자료

1. LangChain / Text splitters
   https://docs.langchain.com/oss/python/integrations/splitters/index
   문단·문장·단어 같은 자연스러운 텍스트 구조를 활용해 의미적 일관성을 유지하는 분할 전략을 설명한 공식 문서다.
2. LangChain / Recursive text splitter
   https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter
   RecursiveCharacterTextSplitter를 사용해 문서를 재귀적으로 분할하는 방법을 설명한 공식 문서다.
3. LangChain Reference / Text splitter classes
   https://reference.langchain.com/python/langchain-text-splitters/langchain_text_splitters
   Markdown, HTML, JSON, 코드, LaTeX 등 문서 유형별 splitter 클래스를 확인할 수 있는 공식 reference 자료다.
4. LlamaIndex / Node Parser Modules
   https://docs.llamaindex.ai/en/v0.10.22/module_guides/loading/node_parsers/modules/
   LlamaIndex에서 문서를 node 단위로 나누는 parser와 semantic splitter 개념을 확인할 수 있는 문서다.
5. LlamaIndex / SemanticSplitterNodeParser
   https://llamaindexxx.readthedocs.io/en/latest/api/llama_index.core.node_parser.SemanticSplitterNodeParser.html
   문장을 의미적으로 관련된 그룹으로 묶어 node를 만드는 semantic node parser의 구조를 설명한 자료다.
6. Kreileder et al. / Evaluating Chunking Strategies for Retrieval-Augmented Generation on Academic Texts
   https://arxiv.org/abs/2607.01852
   학술 텍스트에서 고정형, 재귀형, 클러스터 기반 semantic chunking을 비교하고, semantic chunking이 항상 우월하지 않다는 점을 보여준 최신 연구다.
7. Taiwo & Yusoff / Evaluating Chunking Strategies for RAG in Oil and Gas Enterprise Documents
   https://arxiv.org/abs/2603.24556
   기업 문서에서 고정 크기, 재귀적, 의미 기반, 구조 인식 청킹을 비교하고, 구조 보존의 중요성을 강조한 연구다.
8. A Systematic Investigation of Document Chunking Strategies and Embedding Sensitivity
   https://arxiv.org/abs/2603.06976
   문서 청킹 전략과 임베딩 모델 민감도를 대규모로 평가하려는 연구로, RAG 검색 품질이 청킹과 임베딩 선택에 크게 좌우됨을 다룬다.

 

참고 영상

1. LangChain Text Splitters & Chunking
   https://www.youtube.com/watch?v=Cbor7impJ60
   RAG에서 문서 분할이 왜 중요한지, Recursive Character Splitter와 토큰·의미·섹션 기반 청킹을 어떻게 이해해야 하는지 설명하는 영상이다.
2. LangChain Text Splitters for Beginners
   https://www.youtube.com/watch?v=Io43kf0hYn4
   Character splitter, recursive splitter, token-based splitter, Markdown·HTML·코드 분할 등 여러 청킹 방식을 예제로 설명하는 영상이다.
3. RAG Chunking Strategies Explained
   https://www.youtube.com/results?search_query=RAG+chunking+strategies+explained
   RAG에서 청크 크기, 오버랩, semantic chunking, recursive splitting을 비교하는 영상을 찾을 수 있는 검색 링크다.
4. Embeddings for Retrieval Augmented Generation
   https://www.youtube.com/results?search_query=embeddings+for+retrieval+augmented+generation+explained
   임베딩이 텍스트 의미를 벡터로 바꾸고, 벡터 검색이 RAG에서 어떻게 작동하는지 설명하는 영상을 찾을 수 있다.
5. Hybrid Search and Reranking for RAG
   https://www.youtube.com/results?search_query=hybrid+search+reranking+RAG+explained
   벡터 검색, 키워드 검색, 리랭킹을 결합해 RAG 검색 품질을 높이는 방법을 설명하는 영상을 찾을 수 있다.