[AI] Chunking Strategy - 청크 전략과 크기 최적화, RAG 품질의 출발점

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

Embedding 글을 정리하면서 자연스럽게 다음 질문에 도달했다.

  “그래서, 우리는 무엇을 벡터로 저장하는가?”

 

Embedding은 의미를 벡터로 만든다.
  하지만 Chunking은 그 이전 단계다.

  Chunking은 단순히 텍스트를 자르는 기술이 아니라,
  LLM이 이해할 수 있는 의미 단위를 설계하는 작업이다.

RAG 품질을 이야기할 때 Retriever나 모델 성능을 먼저 떠올리기 쉽지만,
  실제로는 Chunking 단계에서 이미 상당 부분이 결정된다.

 

 

ㅁ Chunking이 RAG 품질을 좌우하는 이유

VectorDB는 문서를 검색하지 않는다.
Chunk 단위의 의미 벡터를 검색한다.

 

즉,

• Chunk는 검색의 최소 단위이고
• Chunk는 LLM이 다시 읽게 될 지식 조각이다.

RAG 파이프라인을 단순화하면 이렇게 된다.

Chunk → Embedding → Vector Similarity → Retriever → Prompt Context → LLM

 

이 흐름의 출발점이 바로 Chunking이다.

그래서 나는 이렇게 정리하게 되었다.

  RAG 품질은 Retriever가 아니라, Chunking에서 이미 방향이 정해진다.

 

 

ㅁ Chunk Size Trade-off - 크기 최적화의 본질

Chunk 크기를 정할 때 항상 마주치는 딜레마다.

Chunk가 너무 크면:

• 하나의 벡터 안에 여러 의미가 섞이고
• cosine similarity가 희석되며
• 검색 정확도가 떨어진다.

Chunk가 너무 작으면:

• 특정 키워드는 잘 잡히지만
• 문맥이 끊기고
• LLM이 전체 흐름을 복원하기 어려워진다.

결국 Chunk size는 단순한 성능 옵션이 아니라,
  의미 해상도를 조절하는 문제에 가깝다.

  사람이 글을 읽을 때도 문장 하나씩이 아니라
  문단 단위로 이해하듯,
  LLM에게도 적절한 의미 덩어리가 필요하다.

 

 

ㅁ 대표적인 Chunking 전략

실무에서 자주 사용하는 방식은 크게 세 가지다.

1. Fixed-size Chunking
   N 토큰 단위로 기계적으로 자르는 방식이다.
   가장 단순하지만 의미 경계를 무시하기 때문에 가장 위험하다.
   PoC 단계에서는 빠르지만, 프로덕션에서는 한계가 명확하다.
2. Overlap Chunking
   이전 Chunk 일부를 다음 Chunk에 포함시켜 문맥 손실을 완화한다.
   다만 중복 Embedding 비용이 발생한다.
   Overlap은 보험이지 해결책은 아니다.
3. 구조 기반 Chunking (문단 / 섹션)
   사람이 읽는 구조 그대로 나누는 방식이다.
   대부분의 문서에서 가장 자연스럽고 안정적이다.

 

중요한 점은 이것이다.

최적의 Chunking은 항상 콘텐츠 구조에 의존한다.

기술 문서, 블로그 글, API 스펙, Q&A 데이터는
각각 다른 Chunk 전략이 필요하다.

 

 

ㅁ Chunking과 Embedding은 하나의 문제다

Embedding 모델이 아무리 좋아도 Chunk가 엉망이면 RAG는 실패한다.

Chunking과 Embedding은 항상 함께 설계해야 한다.

• Chunk는 의미 단위를 정의하고
• Embedding은 그 의미를 벡터로 고정한다.

그래서 Chunking은 RAG 파이프라인의 첫 설계 포인트다.

  모델 튜닝 전에,
  VectorDB 전에,
반드시 먼저 고민해야 할 영역이다.

 

 

ㅁ 실무 기준 Chunk 설계 시작점

완벽한 정답은 없다. 항상 실측이다.

다만 경험적으로 다음 정도에서 시작하는 경우가 많다.

• 기술 문서: 300~500 tokens + overlap 50~100
• 블로그 / 에세이: 문단 기반
• API 문서: 섹션 단위
• Q&A 데이터: 질문과 답변을 하나의 Chunk로 묶기

그리고 반드시 확인해야 할 것은:

• 실제 검색 결과가 의미적으로 맞는지
• LLM이 Chunk를 읽고 충분한 컨텍스트를 복원하는지

Chunking은 설정이 아니라 실험이다.

 

 

ㅁ Chunking은 지식 모델링이다

점점 느끼게 된 건 이것이다.

  Chunking은 텍스트 분할이 아니라,
  지식을 어떻게 나눌지 결정하는 작업이다.

사람도 책을 읽을 때:

• 목차
• 문단
• 문맥

단위로 사고한다.

RAG도 결국 같은 구조를 요구한다.

Chunking은
“이 시스템이 지식을 어떤 형태로 기억할 것인가”에 대한 설계다.

 

 

ㅁ 마무리

Embedding에서 배운 것은:

  의미는 벡터라는 사실이다.

Chunking에서 깨닫는 것은:

  벡터 이전에 의미 단위가 존재한다는 점이다.

 

Transformer가 실시간 사고라면,
Embedding은 기억이고,
Chunking은 그 기억의 구조다.