📌 LLM 어플리케이션 8편: 청킹 - 긴 글을 어떻게 나눌 것인가

BQ개발자입니다.

지난 편에서 임베딩으로 텍스트의 의미를 벡터로 변환할 수 있다고 배웠습니다.
이제 RAG 시스템을 만들어볼까요?

📱 LLM 어플리케이션 7편: 임베딩 - 의미를 숫자로 바꾸는 기술

🔍 RAG의 데이터 흐름

먼저 RAG가 어떻게 작동하는지 봅시다.

1. 문서 저장: "인사규정.pdf" → 임베딩 → 벡터 DB에 저장
2. 질문 처리: "연차 몇 개야?" → 임베딩 → 질문 벡터 생성
3. 검색: 질문 벡터와 가장 유사한 문서 벡터 찾기
4. 답변: 찾은 문서를 LLM에 전달 → 답변 생성

간단해 보이죠?
그런데 1번 단계에서 중요한 결정을 해야 합니다.

"문서를 어떤 단위로 저장할 것인가?"

⚠️ 청킹 없이 그냥 저장하면?

100페이지짜리 인사규정을 통째로 하나의 벡터로 만들었다고 가정해봅시다.

사용자: "신입사원 연차 몇 개야?"

RAG 시스템:
1. 질문을 벡터로 변환
2. 가장 유사한 문서 검색 → "인사규정.pdf" (100페이지 전체)
3. LLM에게 전달: "이 100페이지에서 신입사원 연차를 찾아서 답해줘"

결과:

• LLM이 100페이지를 다 읽어야 함 (비용 폭발)
• 토큰 한계 초과로 처리 불가능

• 설령 처리해도 답변 정확도 떨어짐

이래서는 검색이 무의미합니다.

🤔 청킹(Chunking)이란?

청킹은 긴 문서를 검색 가능한 작은 단위로 나누는 과정입니다.

100페이지를 적절히 나누면:

• 3페이지: 근무시간 규정
• 4페이지: 연차 규정 ← 이것만 검색됨

• 5페이지: 병가 규정

...

이제 질문과 관련된 부분만 정확히 찾을 수 있습니다.

⚡ 정보의 원자성 vs 맥락성

청킹은 두 가지 상충하는 요구사항 사이의 균형입니다.

원자성 (Atomicity)
- 각 청크가 하나의 명확한 정보를 담아야 함

• 작을수록 검색 정확도 향상
• 하지만 맥락 없이는 의미가 불완전

맥락성 (Context)
- 정보를 이해하는 데 필요한 배경 포함

• 클수록 이해도 향상
• 하지만 불필요한 정보로 인한 노이즈 증가

최적의 청킹은 이 둘 사이의 균형점을 찾는 것입니다.

📏 청킹 방법론의 진화

1. 고정 크기 청킹

• 300자, 500자 등 일정 크기로 자르기
• 문제: 문장이나 단어가 중간에 잘림

• "...연차는 15일이며, 2년차부터는 매년 1일씩 추|"

2. 재귀적 청킹

• 우선순위: 문장 → 절 → 단어 경계
• 의미 단위를 최대한 보존

• 크기 제한도 지키면서 가독성 확보

3. 의미 기반 청킹

• 문서의 논리적 구조 활용 (제목, 단락, 섹션)
• 주제가 바뀌는 지점에서 분할

• 자연스러운 의미 단위 유지

🎯 고급 청킹 전략

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

핵심 아이디어: 검색과 제공을 분리

자식 청크 (검색 최적화):

• "신입사원의 연차는 15일입니다."
• 작고 구체적, 정확한 매칭 가능

부모 청크 (답변 최적화):

• 자식 청크 + 주변 맥락
• "신입사원의 연차는 15일입니다. 2년차부터는..."

• 완전한 정보 제공

스몰-투-빅 (Small-to-Big)

검색된 청크의 앞뒤 문맥을 자동 포함:

• 핵심: "연차는 15일입니다."
• 제공: [이전 문장] + 핵심 + [다음 문장]

• 자연스러운 흐름 유지

💡 청킹이 RAG 성능을 좌우하는 이유

임베딩은 의미를 수치화하는 기술이지만,
청킹은 어떤 의미를 수치화할지 결정하는 요소입니다.

같은 정보도 청킹에 따라:

• "15일" → 의미 없는 숫자
• "신입사원 연차 15일" → 명확한 정보

RAG의 품질은 임베딩 모델보다 청킹 전략에 더 의존합니다.
검색의 정밀도와 답변의 완전성이 여기서 결정되기 때문입니다.

정보를 어떻게 구조화하고 보존할 것인가.
이것이 청킹의 본질입니다.

이렇게 오늘은 지식을 효과적으로 저장하고 검색하는 방법을 배웠습니다.
다음은 이 지식을 활용해 능동적으로 사고하는 시스템, 에이전트를 알아보겠습니다!

---

여러분의 좋아요와 공유는 사랑입니다 🥰