청킹(Chunking)이란? AI가 긴 문서를 나눠 이해하는 방법

TL;DR

청킹(Chunking)은 긴 문서를 AI가 검색하고 답변에 활용하기 좋도록 의미 있는 작은 조각으로 나누는 작업입니다. RAG나 사내 문서 검색에서는 질문과 가장 관련 있는 조각을 찾아 모델에 전달합니다. 너무 크게 나누면 핵심이 묻히고, 너무 작게 나누면 문맥이 끊길 수 있어 작업 목적에 맞는 크기와 겹침을 정하는 일이 중요합니다.

핵심 3줄 요약

• 핵심 1
  청킹은 PDF, 매뉴얼, 회의록처럼 긴 자료를 검색과 AI 답변에 쓸 수 있는 작은 단위로 나누는 전처리 방식입니다.
• 핵심 2
  좋은 청크는 문장의 중간을 무작정 자르기보다 제목, 문단, 목록, 표의 의미 단위를 가능한 한 유지합니다.
• 핵심 3
  청크 크기와 오버랩에는 정답이 하나가 없으므로 실제 질문으로 검색 정확도와 답변 품질을 함께 테스트해야 합니다.

이 글에서 다룰 내용

한 문장 정의: 청킹은 무엇인가요?

청킹(Chunking)은 긴 문서나 데이터를 검색·처리하기 쉬운 작은 조각, 즉 청크로 나누는 작업입니다.

생성형 AI에서 청킹은 특히 문서 검색과 RAG(Retrieval-Augmented Generation, 검색 증강 생성)에 자주 등장합니다. 사내 규정집 전체를 매번 모델에 넣는 대신, 먼저 문서를 여러 청크로 나눈 뒤 질문과 가까운 청크만 찾아 AI에 제공합니다.

Google Cloud의 Vertex AI RAG 문서는 문서가 인덱스에 들어갈 때 청크로 분할되며, chunk_size는 청크의 토큰 크기를, chunk_overlap은 인접 청크 사이에 겹쳐 둘 토큰 수를 뜻한다고 설명합니다. OpenAI의 벡터 스토어 API도 자동 청킹과 크기·겹침을 지정하는 정적 청킹 전략을 구분합니다.

한 줄 정리: 청킹은 긴 자료를 ‘AI가 필요한 부분만 찾아 쓸 수 있는 조각’으로 바꾸는 준비 작업입니다.

AI는 왜 긴 문서를 청크로 나누나요?

필요한 부분을 더 정확히 찾기 위해서입니다

긴 취업 규정집에서 “연차 이월 기준”을 묻는 질문이 들어왔다고 해 보겠습니다. 규정집 전체를 한 덩어리로 검색하면 연차와 관계없는 복리후생, 출퇴근, 평가 규칙도 함께 섞일 수 있습니다. 반면 연차 규정이 담긴 문단 단위 청크를 만들면 질문과 가까운 조각을 우선 찾기 쉬워집니다.

Google Cloud는 작은 청크일수록 임베딩이 더 정밀해질 수 있고, 큰 청크는 더 일반적인 표현을 담는 대신 특정 세부 사항을 놓칠 수 있다고 안내합니다. 여기서 임베딩은 텍스트의 의미를 숫자 배열로 바꿔 유사한 내용을 찾는 기술입니다.

모델에 넣을 문맥을 관리하기 위해서입니다

AI 모델은 한 번에 읽을 수 있는 입력량에 한계가 있습니다. 문서가 길수록 모든 내용을 넣는 방식은 비용과 응답 시간을 키우고, 필요한 근거가 다른 정보에 묻힐 가능성도 높입니다. 청킹과 검색을 함께 쓰면 관련 청크 몇 개만 골라 문맥으로 제공할 수 있습니다.

다만 청킹이 문서를 ‘완전히 이해’하게 해 주는 기능은 아닙니다. 잘린 조각이 질문에 정말 맞는지, 그 조각만으로 예외 조건을 놓치지 않는지, 원문 출처가 최신인지도 별도로 확인해야 합니다.

핵심 인사이트: 청킹의 목표는 문서를 많이 넣는 일이 아니라, 질문에 필요한 문맥을 잃지 않으면서 찾아낼 수 있게 만드는 일입니다.

쉬운 예시: 고객 안내문을 어떻게 나누나요?

온라인 쇼핑몰의 고객 안내 문서가 있다고 가정해 보겠습니다. 문서에는 배송, 교환·반품, 결제, 회원 계정, 개인정보 문의가 함께 들어 있습니다.

좋지 않은 예: 글자 수만 맞춰 중간에서 자르기

문장 중간이나 표의 가운데를 무조건 자르면 “교환 신청은 상품 수령 후 7일 이내”라는 문장과 “단, 냉장 상품은 예외”라는 조건이 서로 다른 청크에 갈 수 있습니다. AI가 첫 청크만 찾아 답하면 예외를 빼먹을 위험이 있습니다.

더 나은 예: 제목과 규칙 묶음을 기준으로 나누기

배송 안내, 교환·반품, 결제 오류, 개인정보 문의처럼 제목 아래의 문단과 예외 규칙을 한 묶음으로 둡니다. 교환·반품 항목이 너무 길다면 ‘신청 기한’, ‘비용 부담’, ‘예외 상품’처럼 하위 주제 단위로 다시 나눌 수 있습니다.

오버랩은 경계의 문맥을 잇는 장치입니다

인접 청크 일부를 겹쳐 두는 방식을 오버랩(overlap)이라고 합니다. 예를 들어 한 청크 마지막에 “해외 배송 상품은…”이 있고 다음 청크에 예외 조건이 이어진다면, 경계 주변 문장을 일부 겹쳐 두어 검색 결과가 문맥을 덜 잃게 할 수 있습니다.

Google Cloud의 RAG 예시는 청크 크기와 오버랩을 별도 설정으로 제공합니다. 다만 오버랩을 크게 하면 같은 내용이 여러 청크에 반복되어 저장량과 검색 후보가 늘 수 있습니다.

예시 정리: 청킹은 글자 수 자르기가 아니라, 질문에 답하는 데 필요한 규칙과 예외를 함께 남기는 문서 구조화 작업입니다.

청킹과 비슷한 용어는 어떻게 다른가요?

청킹과 토큰화(Tokenization)의 차이

토큰화는 텍스트를 모델이 처리하는 작은 단위인 토큰으로 나누는 과정입니다. 단어 하나가 토큰 하나와 정확히 일치하지는 않을 수 있습니다. 청킹은 이런 토큰 수를 참고할 수 있지만, 보통 검색·문맥 제공을 위해 여러 문장이나 문단을 한 조각으로 묶는 더 큰 작업입니다.

즉 토큰화가 모델이 글을 세고 읽는 기본 단위를 만드는 과정이라면, 청킹은 문서를 검색 가능한 의미 단위로 묶는 설계에 가깝습니다.

청킹과 임베딩(Embedding)의 차이

청크를 만들었다고 자동으로 비슷한 내용을 찾는 것은 아닙니다. 많은 RAG 시스템은 각 청크를 임베딩으로 바꿔 벡터 데이터베이스나 검색 인덱스에 저장합니다. 사용자가 질문하면 질문도 비슷한 방식으로 표현해, 의미가 가까운 청크를 찾습니다.

청킹은 ‘무엇을 한 조각으로 둘지’ 정하고, 임베딩은 그 조각의 의미를 비교할 수 있게 숫자로 표현합니다. 둘은 이어서 쓰이지만 같은 기술은 아닙니다.

청킹과 RAG의 차이

RAG는 외부 문서나 데이터에서 관련 정보를 검색해 모델의 답변에 활용하는 전체 방식입니다. 청킹은 그 RAG 과정 안에서 문서를 준비하는 단계입니다. 문서 수집, 청킹, 임베딩, 인덱싱, 검색, 답변 생성, 출처 표시와 평가가 함께 있어야 RAG 시스템이 됩니다.

비교 정리: 토큰화는 모델 입력 단위를 나누는 일, 청킹은 문서를 의미 있는 검색 조각으로 나누는 일, 임베딩은 조각의 의미를 수치화하는 일, RAG는 그 조각을 찾아 답변에 쓰는 전체 구조입니다.

챗GPT와 AI 자동화에서는 언제 청킹을 생각해야 하나요?

개인이 챗GPT에 짧은 문서 한두 개를 올려 요약할 때는 청크 크기를 직접 설정할 일이 많지 않습니다. 하지만 사내 매뉴얼, 고객센터 문서, 제품 카탈로그, 계약서 모음처럼 자료가 늘어나고 질문도 반복되면 청킹 방식이 결과에 영향을 줍니다.

첫째, 문서 검색 챗봇을 만들 때 중요합니다. 질문에 맞는 규정 조항을 찾고 싶다면 제목·문단·예외 규정이 함께 남도록 나누는 편이 좋습니다.

둘째, 업무 자동화에서 근거를 붙일 때 씁니다. 예를 들어 AI가 상품 정책을 바탕으로 고객 답변 초안을 쓴다면, 답변에 사용한 청크의 원문 제목·링크·갱신일을 같이 기록해 두는 것이 좋습니다.

셋째, 문서 형식이 복잡할 때 더 신경 써야 합니다. PDF의 표, 두 단 편집, 스캔 이미지, 각주, 머리글·바닥글이 섞인 문서는 텍스트 추출 자체가 틀어질 수 있습니다. 이 경우에는 청킹 설정을 바꾸기 전에 추출된 원문이 정상인지 먼저 확인해야 합니다.

실전 팁: 처음에는 실제 사용자 질문 20개 정도를 모아, 각 질문에 필요한 조항과 예외가 같은 검색 결과에 들어오는지 확인해 보세요. 청크 크기부터 정하기보다 ‘정답 근거가 잘 찾아지는가’를 기준으로 조정하는 편이 안전합니다.

청크 크기와 오버랩은 어떻게 정하나요?

먼저 문서의 성격을 봐야 합니다. FAQ처럼 질문과 답이 짧게 끊기는 문서는 질문·답변 한 쌍을 하나의 청크로 둘 수 있습니다. 규정집처럼 본문과 단서가 길게 이어지는 문서는 조항과 예외를 함께 묶고, 필요한 경우 인접 문단을 조금 겹치게 둘 수 있습니다.

크기 숫자 하나를 모든 문서에 적용하면 편하지만, 검색 의도와 문서 구조가 다르면 결과도 달라집니다. Google Cloud는 작은 청크가 더 정밀한 임베딩에 도움이 될 수 있지만 큰 청크는 더 일반적인 의미를 담는다고 설명합니다. 따라서 ‘작을수록 좋다’ 또는 ‘클수록 문맥이 좋다’로 단정할 수 없습니다.

운영할 때는 다음 질문으로 점검해 보세요.

• 한 청크 안에 질문의 답과 중요한 예외 조건이 함께 있는가?
• 비슷한 문구가 다른 청크에 흩어져 있어 검색이 엉뚱한 곳을 고르지 않는가?
• 같은 문장이 과도하게 반복되어 검색 결과가 비슷한 청크로만 채워지지 않는가?
• 문서가 업데이트되면 이전 청크와 인덱스도 함께 교체되는가?
• 답변에 사용한 청크의 원문 위치를 사람이 확인할 수 있는가?

한 줄 정리: 청크 크기는 기술 설정값이지만, 실제로는 ‘사용자가 묻는 질문에 필요한 근거와 예외를 함께 찾는가’로 판단해야 합니다.

사용할 때 주의할 점

첫째, 청킹만 잘해도 답변이 사실이 된다고 생각하면 안 됩니다. 검색된 청크가 오래된 정책일 수 있고, AI가 근거에 없는 내용을 덧붙일 수도 있습니다. 중요한 답변에는 원문 링크, 갱신일, 사람 검토 기준을 함께 둬야 합니다.

둘째, 개인 정보나 비공개 문서는 청킹 전에 접근 권한부터 설계해야 합니다. 문서를 작은 조각으로 나눠 저장하면 검색은 편해지지만, 권한 없는 사람이 관련 청크를 찾게 되면 문제가 될 수 있습니다. 사용자·부서별 검색 범위와 보존 정책을 먼저 확인하세요.

셋째, 표·코드·계약 조항을 일반 문단처럼 잘라서는 안 됩니다. 표의 열 제목과 값, 코드 블록의 앞뒤 맥락, 조항의 예외와 정의가 떨어지면 검색 결과가 오해를 부를 수 있습니다. 구조를 보존하는 파서나 문서별 분할 규칙이 필요할 수 있습니다.

넷째, 벤더의 기본값을 보편적인 정답으로 받아들이지 마세요. OpenAI와 Google Cloud도 자동 전략 또는 조정 가능한 청크 크기·오버랩 옵션을 제공하지만, 적절한 값은 문서·언어·질문·모델·검색 방식에 따라 달라집니다.

주의: 청킹은 검색 품질을 돕는 장치이지, 보안 통제·최신성 검증·사실 확인·권한 관리를 대신하지 않습니다.

자주 묻는 질문

Q1. 청킹은 RAG를 만들 때만 필요한가요?

주로 RAG와 문서 검색에서 많이 쓰이지만, 긴 텍스트를 요약·분류·번역·배치 처리할 때도 입력을 관리하기 위해 쓰일 수 있습니다. 다만 목적이 검색인지, 처리 한도 관리인지에 따라 나누는 기준은 달라집니다.

Q2. 청크는 작을수록 검색이 좋아지나요?

항상 그렇지는 않습니다. 너무 작으면 답과 조건이 갈라져 문맥이 부족해질 수 있습니다. 반대로 너무 크면 검색 결과가 넓어져 필요한 문장이 묻힐 수 있습니다. 실제 질문으로 정확도와 빠진 예외를 확인해야 합니다.

Q3. 오버랩은 반드시 넣어야 하나요?

반드시 필요한 것은 아닙니다. 문서가 독립적인 FAQ 항목처럼 잘 나뉘어 있다면 오버랩이 거의 필요하지 않을 수 있습니다. 반면 문단 경계에서 정의·예외가 이어지는 문서라면 일부 겹침이 도움이 될 수 있습니다.

Q4. 토큰 수와 글자 수 중 무엇을 기준으로 나누나요?

AI API와 임베딩 모델은 보통 토큰 한도를 사용하므로 실제 설정에서는 토큰 수가 중요합니다. 그러나 사람이 읽는 문서 구조도 함께 봐야 합니다. 제목, 문단, 목록, 조항 경계를 먼저 살피고 그 안에서 토큰 한도를 맞추는 편이 좋습니다.

Q5. 청킹을 하면 원문 출처도 보여 줄 수 있나요?

가능합니다. 청크를 만들 때 문서 제목, URL, 페이지, 조항 번호, 갱신일 같은 메타데이터를 함께 저장하면 답변에 사용한 근거를 표시하거나 검토 화면으로 연결하는 데 도움이 됩니다. 다만 실제 표시 방식과 권한 처리는 사용하는 서비스의 구현에 따라 달라집니다.

출처

마무리

청킹은 긴 문서를 작게 자르는 단순한 기술처럼 보이지만, 실제로는 AI가 어떤 근거를 찾아 답하게 할지 정하는 문서 설계입니다. 감자나라ai님이 AI 문서 검색이나 자동 답변을 준비한다면, 먼저 문서를 제목·규칙·예외가 함께 남는 단위로 나눈 뒤 실제 질문으로 검색 결과를 확인해 보세요. 좋은 청킹은 문서를 더 많이 넣는 방식이 아니라, 필요한 근거를 더 정확히 꺼내는 방식입니다.