✂️ 검색 품질의 첫 단추: '청킹(Chunking)' 완벽 이해하기

문서를 임베딩(벡터화)과 검색에 알맞은 크기로 나눠, 
AI 검색이 제대로 작동하도록 데이터를 준비하는 출발점

 

 

벡터 검색(의미 검색)은 보통 문서 전체가 아니라, 

**문서를 쪼갠 '청크 단위'**로 임베딩을 만들고 검색합니다. 

 

그래서 청킹은 검색 품질을 좌우하는 첫 단계가 됩니다.

[원본 문서] → [🧩청킹] → [임베딩 생성] → [검색] → [LLM 답변]

 

🤔 같은 문서인데도 "어디서 어떻게 잘랐는지"에 따라 왜 결과가 달라질까요 ❓

---

🧩 청킹이란?

우왕 문서가 갈리고 이써

 

청킹(Chunking)은

큰 텍스트 덩어리를 작고 관리 가능한 조각(chunk) 으로 나누는 과정입니다.

목표는 단순합니다.

컴퓨터가 문장을 의미 벡터(숫자 목록) 로 바꾸고(임베딩),

검색에 쓰기 좋은 단위로 만드는 것.

 

예를 들어

50페이지 문서를 통째로 다루는 대신,

의미 있는 단위로 쪼개서

각 조각을 따로 저장/검색할 수 있게 만드는 작업입니다.

 

❓ 그렇다면 “나누기만 하면” 무조건 좋아질까요 ❓ 

---

🔍 왜 청킹이 필요할까?

청킹은 선택 옵션처럼 보이지만, 

실제로는 검색 품질을 위해 꼭 짚고 넘어가는 이유가 있습니다.

 

1. 모델의 입력 한계 (Model Input Limits)
   • 임베딩 모델과 LLM은 한 번에 처리할 수 있는 텍스트 양(토큰)에 한계가 있습니다.
        예를 들어 e5-small 계열은 512 토큰을 넘으면 입력이 잘리거나 제한될 수 있고,
        ELSER 계열은 설정/방식에 따라 반영 가능한 토큰 범위가 정해지는 경우가 있습니다.
   • 청킹은 긴 문서가 그대로 들어가면서 뒷부분이 누락되는 상황을 줄이는 안전장치가 됩니다.
   • 또한 긴 글을 다룰 때,
        모델이 중간 정보에 상대적으로 약해질 수 있다는 관찰(일명 "Lost in the Middle")이 알려져 있습니다.
        청킹은 "관련 있는 부분만 짧게" 가져오는 데 도움이 될 수 있습니다.
2. (b) 정보의 희석 방지 (Preventing Information Dilution)
   • 아주 긴 문서 전체를 하나의 임베딩으로 만들면,
        의미가 넓게 퍼져서(희석돼서) 특정 주제를 또렷하게 잡기 어려울 수 있습니다.
   • 반대로 작은 청크는
        주제가 더 집중돼서, 임베딩도 더 선명해지고 검색도 더 정밀해질 수 있습니다.
3. (c) 사람이 읽기 좋은 결과 (Human-Readable Results)
   • 사용자 입장에서도
         문서 전체보다 질문과 직접 관련 있는 단락이 바로 나오면 훨씬 편합니다.
   • 청킹이 잘 되어 있으면
         시스템이 "정답 후보"를 줄 때도 읽기 좋은 단위로 보여줄 수 있습니다.

❓ 그렇다면 성공적인 청킹을 위해 우리는 무엇을 결정해야 할까요 ?

---

⚖️ 청킹에서 결정해야 하는 3가지

마치 요리사가 재료를 다듬는 방법을 정하듯, 

이 선택들은 AI가 정보를 더 잘 '맛볼' 수 있게 만듭니다.

 

1. 단위(Unit): 어떤 기준으로 나눌까?
   • 문장, 단어(길이), 혹은 마크다운 제목 같은 구조를 기준으로 나눌 수 있습니다.
   • 👍 좋을 때: 문장 단위는 의미가 자연스럽게 유지될 때 유리합니다.
   • ⚠️ 나쁠 때: 단어/길이만 보고 자르면 문맥이 "딱 중간에서" 끊길 수 있습니다.
2. 크기(Size): 얼마나 크게 자를까?
   • 청크 크기는 정밀도 vs 문맥의 균형입니다.
   • 👍 좋을 때: 큰 청크는 앞뒤 문맥을 함께 담아 설명형 질문에 유리할 수 있습니다.
   • ⚠️ 나쁠 때: 너무 크면 여러 주제가 섞여 검색이 뭉개질 수 있습니다.
3. 겹침(Overlap): 얼마나 이어 붙일까?
   • 다음 청크를 만들 때 이전 청크의 일부를 포함시키는 방식입니다(문맥 연속성 유지).
   • 👍 좋을 때: 겹침이 있으면 경계에서 문맥 손실을 줄여 품질이 좋아질 수 있습니다.
   • ⚠️ 나쁠 때: 커질수록 중복 데이터가 늘어 처리량/비용이 증가할 수 있습니다.

❓ 이제 대표 전략을 보면 "내 문서에 뭐가 맞는지" 감이 더 빨리 옵니다.

---

🧩 대표 전략 4종 비교

문서 성격과 질문 유형에 따라 최적은 달라집니다. 아래는 많이 쓰는 네 가지입니다.

1️⃣ Sentence (문장 단위) : 문장 경계를 기준으로 나눠 문맥 손실을 줄이는 전략.

 

👍 좋은 경우

문맥 보존이 중요할 때
일반적인 서술형 문서(문장 단위로 의미가 완결되는 글)

 

⚠️ 흔한 함정

문장 경계를 우선하다 보니 청크 수가 늘 수 있습니다(관리/비용 증가).

 

✅ 기본 설정 예시(특정 환경 기준)

예: inference endpoint에서 chunking 설정을 생략했을 때
      sentence 기반 기본값이 잡히는 경우가 있습니다.
단, "기본값"은 버전/엔드포인트/설정에 따라 달라질 수 있어,
      실제 사용 환경에서 확인이 필요합니다.

---

 

2️⃣ Word (단어/길이 기반) : 청크 크기를 단어 수(또는 길이)로 맞춰 규격을 일정하게 만드는 전략.

👍 좋은 경우

청크 크기를 균일하게 관리하고 싶을 때
처리 효율(일정한 크기, 예측 가능한 처리량)이 중요할 때

 

⚠️ 흔한 함정

문맥이 중간에서 끊기기 쉽습니다(특히 정의/조건/예외가 이어지는 문장).

---

3️⃣ Recursive (구조 기반 단위) : 마크다운 제목, 문단 구분 등 문서 구조를 따라 계층적으로 나누는 전략.

 

👍 좋은 경우

마크다운/위키 문서처럼 구조가 잘 잡힌 문서
"섹션 단위로 의미가 완결"되는 자료

 

⚠️ 흔한 함정

문서 구조가 들쑥날쑥하면, 오히려 청크 품질이 흔들릴 수 있습니다.

---

 

4️⃣ None (나누지 않음) : 문서 전체를 한 덩어리로 취급해 청킹을 하지 않는 방식.

 

👍 좋은 경우

문서 자체가 짧아서 입력 한계에 걸리지 않을 때
문서 전체가 항상 함께 필요할 때(아주 짧은 안내문 등)

⚠️ 흔한 함정

모델/설정에 따라 입력 한계를 넘는 부분이 잘려(트렁케이션)
검색에서 반영되지 않을 수 있습니다.

즉, "없던 일"이 될 수 있습니다.

---

🧪 "내 서비스에 맞는 청킹" 찾는 방법

"정답 청킹"은 없습니다.

대신 내 문서 + 내 질문에 맞는 최적점이 있습니다.

 

작은 실험 설계 (가볍게, 하지만 확실하게)

1. 샘플 준비: 실제 문서 몇 개(대표 유형 위주)
2. 질문 5~10개 만들기: 사용자가 실제로 할 만한 질문(팩트/요약/비교 등 섞기)
3. 전략 2~3개 적용: 예) Sentence vs Word vs None
4. 같은 조건으로 검색: top-k 결과를 비교
5. 판단하기: 결과가 너무 넓은지(too broad), 너무 좁은지(too narrow) 확인

 

"좋아졌는지"는 뭘로 증명할까?

아래 3가지만 봐도 방향이 잡힙니다.

1. 정확성: 상위 결과가 질문과 관련 있는가?
2. 구체성: 상위 결과(청크)를 읽으면 “왜 답인지” 바로 이해되는가?
3. 안정성: 질문을 조금 바꿔도(표현 변경) 결과가 크게 흔들리지 않는가?

❓ 여기까지 실험을 했다면, 이제 마지막은 "빠진 게 없는지" 점검입니다.

---

✅ 청킹 체크리스트

• 문서 형태는 무엇인가? ( 마크다운 / 일반 텍스트 / PDF 등 )
• 질문 유형은 주로 무엇인가? ( 팩트 / 요약 / 설명 / 비교 )
• 청크 크기는 어느 정도로 잡을 것인가?
• overlap은 어느 정도가 적당한가? ( 품질 vs 비용 )
• 메타데이터( 출처 / 날짜 / 카테고리 )를 붙일 수 있는가?
• 검색 결과가 비슷비슷하게 나오면 리랭킹까지 고려할 것인가?
• “좋아졌는지” 비교할 작은 평가 질문셋을 갖췄는가?

---

 

좋은 답변을 만들기 위한 '재료 손질'

 

청킹은 좋은 답변을 만들기 위한 재료 손질에 가깝습니다.

같은 재료라도

어떻게 손질하느냐에 따라 맛이 달라지듯,

 

같은 문서도

청킹에 따라 검색 품질이 달라질 수 있습니다.

---

요약의 레퍼런스: 

청킹의 근거:

https://arxiv.org/abs/2307.03172

Lost in the Middle: How Language Models Use Long Contexts

 

청킹이 일어나는 위치:

https://www.elastic.co/docs/explore-analyze/elastic-inference/inference-api
https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/semantic-text-reference

Inference integrations | Elastic Docs

Semantic text field type reference | Reference

 

튜닝 방법: 

https://www.elastic.co/search-labs/blog/elasticsearch-chunking-inference-api-endpoints

Elasticsearch chunking: Set up chunking for inference endpoints - Elasticsearch Labs

 

청킹 예:

https://reference.langchain.com/python/langchain_text_splitters/
https://developers.llamaindex.ai/python/framework/optimizing/basic_strategies/basic_strategies/

Text Splitters | LangChain Reference

Basic Strategies

 

청킹과 품질의 관계: 

https://www.elastic.co/docs/solutions/search/hybrid-search
https://www.elastic.co/search-labs/blog/hybrid-search-multi-field-query-retrievers-elasticsearch

Hybrid search | Elastic Docs

Hybrid search simplified: Multi-field queries in Elasticsearch - Elasticsearch Labs

 

대표전략: 

https://www.elastic.co/search-labs/blog/chunking-strategies-elasticsearch

Chunking strategies: Elasticsearch chunking & its strategies - Elasticsearch Labs

---

 

해당 글은 AI 어시스턴트로 작성되었습니다.

NotebookLM과 Chat GPT를 사용하여 작성되었습니다.

---