내 RAG가 고장 난 줄 알았다. 진짜 문제는 청킹(Chunking)이었다.

RAG를 배우기 시작했을 때, 나는 어려운 부분이 다음과 같을 것이라고 가정했다:

• 임베딩 (Embeddings)
• 벡터 데이터베이스 (Vector databases)
• LLM (Large Language Models)

내가 틀렸다.

내 임베딩은 잘 작동하고 있었다.

내 벡터 데이터베이스는 결과를 반환하고 있었다.

LLM은 답변을 생성하고 있었다.

하지만 답변은 종종 불완전하거나, 관련이 없거나, 중요한 문맥 (Context)이 누락되어 있었다.

몇 시간 동안의 디버깅 끝에, 나는 문제가 모델에 있지 않다는 것을 발견했다.

그것은 바로 내가 문서를 분할하는 방식이었다.

청킹 (Chunking)이 대부분의 사람들이 생각하는 것보다 더 중요한 이유

RAG 시스템은 찾을 수 있는 것만을 검색할 수 있다.

그리고 무엇을 찾을 수 있는지는 문서가 어떻게 청킹 (Chunking)되느냐에 크게 좌우된다.

잘못된 청킹은 다음과 같은 결과를 초래한다:

• 문맥 (Context) 누락
• 저조한 검색 (Retrieval) 성능
• 관련 없는 답변
• 환각 (Hallucinations)

다른 모든 것이 올바르게 설정되어 있을 때조차 말이다.

그림 1: 좋은 청킹은 검색 품질을 향상시키지만, 나쁜 청킹은 문맥을 파편화하고 답변 품질을 저하시킨다.

많은 경우, 답변의 품질은 LLM이 단 하나의 토큰 (Token)을 생성하기도 전에 결정된다.

실수 #1: 너무 큰 청크 (Chunks)

한 장의 챕터 전체를 하나의 청크로 저장한다고 상상해 보자.

20페이지 분량의 챕터
        ↓
      1개의 청크

이제 사용자가 한 단락에 대해 질문을 한다.

검색 시스템은 챕터 전체를 가져와야 한다.

이는 많은 관련 없는 문맥 (Context)을 도입하게 만들며 검색의 정밀도를 떨어뜨린다.

청크가 크다고 해서 항상 더 나은 답변을 의미하는 것은 아니다.

실수 #2: 너무 작은 청크 (Chunks)

그다음 나는 정반대의 접근 방식을 시도했다.

아주 작은 청크들.

예를 들면 다음과 같다:

청크 1:
프랑스의 수도는

...

문제는 무엇인가?

문맥 (Context)이 파괴된다.

검색 시스템은 답변의 일부만을 찾을 수도 있다.

정보는 존재하지만, 그 의미가 파편화되어 있다.

그림 2: 효과적인 청킹 (Chunking)은 균형을 맞추는 것이다. 너무 큰 청크는 노이즈 (Noise)를 유발하고, 너무 작은 청크는 문맥 (Context)을 잃게 만든다.

이것은 청크 크기 (Chunk size)가 단순한 전처리 (Preprocessing) 설정이 아니라, 검색 품질 (Retrieval quality)에 직접적인 영향을 미친다는 것을 깨달은 첫 번째 순간이었다.

실수 #3: 청크 중첩 (Chunk Overlap) 부재

이것은 가장 놀라운 교훈 중 하나였다.

중첩이 없다면:

청크 1
--------
임베딩 (Embeddings)
...

만약 중요한 개념이 두 청크의 경계 사이에 걸쳐 있다면 어떤 일이 벌어질까?

문맥 (Context)을 잃게 된다.

중첩 (Overlap)을 추가하면 자연스럽게 여러 청크에 걸쳐 있는 정보를 보존하는 데 도움이 된다.

실수 #4: 단순히 글자 수로만 나누기

많은 튜토리얼이 다음과 같이 작성하고 끝난다:

chunk_size = 500

문제는 텍스트가 자연스럽게 500자 단위의 블록으로 구성되지 않는다는 점이다.

자칫하면 다음과 같이 나누어질 수 있다:

벡터 데이터베이스 (Vector database)는 ...를 위해 사용되는 임베딩을 저장합니다

그리고

...문서 전반에 걸친 의미론적 검색 (Semantic search).

문장은 살아남을지 모른다.

하지만 의미는 사라진다.

실수 #5: 모든 곳에 동일한 전략 사용하기

모든 문서를 동일한 방식으로 청킹 (Chunking)해서는 안 된다.

문서 (Documentation), 코드베이스 (Codebases), 계약서 (Contracts), 연구 논문 (Research papers)은 모두 구조가 다르다.

예를 들어:

• 문서 (Documentation) → 섹션 기반 청크 (Section-based chunks)
• 코드 (Code) → 함수 또는 클래스 기반 청크 (Function or class-based chunks)
• 연구 논문 (Research papers) → 섹션 기반 청크 (Section-based chunks)
• 계약서 (Contracts) → 조항 기반 청크 (Clause-based chunks)

문서의 구조는 임의의 토큰 수 (Token counts)보다 더 나은 청크 경계 (Chunk boundaries)를 제공하는 경우가 많다.

나의 생각을 바꾼 교훈

RAG를 처음 배우기 시작했을 때, 나는 청킹 (Chunking)을 단순한 전처리 (Preprocessing) 단계로 보았다.

이제 나는 다르게 본다.

청킹 (Chunking)은 검색 엔지니어링 (Retrieval engineering)이다.

왜냐하면 검색 품질 (Retrieval quality)이 답변 품질 (Answer quality)에 직접적인 영향을 미치기 때문이다.

더 나은 청크는 다음과 같은 결과를 가져온다:

• 더 나은 검색 (Retrieval)
• 더 나은 문맥 (Context)
• 더 나은 답변 (Answers)

LLM을 전혀 변경하지 않고도 말이죠.

마치며

저의 RAG 여정에서 가장 놀라웠던 점은 임베딩 (Embeddings)이나 벡터 데이터베이스 (Vector Databases)가 아니었습니다.

문서 분할 (Document Splitting)이 검색 (Retrieval)에 얼마나 큰 영향을 미치는지 발견한 것이었습니다.

만약 여러분의 RAG 시스템이 제대로 작동하지 않는다면, 즉시 모델을 탓하지 마세요.

먼저 여러분의 청크 (Chunks)를 살펴보세요.

문제는 LLM이 질문을 확인하기도 전에 이미 존재하고 있을지도 모릅니다.

💡 RAG 시스템을 구축할 때 여러분이 선호하는 청킹 (Chunking) 전략은 무엇인가요?