RAG를 만들어 보았지만, 답변이 미묘하게 빗나간다. 임베딩 모델(Embedding Model)을 바꾸거나 프롬프트(Prompt)를 수정해 보았지만, 별로 변하지 않는다. 그럴 때 가장 먼저 재검토해야 할 것이 바로 **청킹 (Chunking, 문장을 나누는 방법)**입니다.

청킹은 눈에 띄지 않고 기사에서도 대충 지나치기 쉽습니다. 하지만 실제로 품질을 좌우하는 비율은 상당히 크며, 이 부분을 수정하는 것만으로도 체감 성능이 달라질 수 있습니다. 이 기사에서는 코드를 거의 사용하지 않고 「왜 나누는지」, 「어떻게 나누면 망가지는지」를 정리합니다.

왜 문장을 나눌 필요가 있는가

RAG는 「관련 자료를 검색하여 생성 AI에게 전달해 답하게 하는」 구조입니다. 이때 자료를 통째로 한 권 다 전달할 수는 없습니다. 이유는 두 가지가 있습니다.

첫 번째는, 전달할 수 있는 양에 상한선이 있다는 것입니다. 생성 AI (LLM)가 한 번에 받아들일 수 있는 문장량에는 한계가 있습니다. 100페이지짜리 매뉴얼을 그대로 전달할 수는 없습니다.

두 번째는, 검색의 정밀도가 떨어진다는 것입니다. 이 점이 간과되기 쉽습니다. 벡터 검색 (Vector Search)은 문장을 「의미를 나타내는 좌표」로 변환하여 유사도를 측정하지만, 긴 문장을 하나의 좌표로 묶어버리면 다양한 화제가 평균화되어 특징 없는 좌표가 되어버립니다.

예를 들어 「반품 정책」, 「배송비」, 「영업시간」, 「회사 개요」가 모두 포함된 하나의 문서를 1개의 벡터로 만들면, 그 좌표는 「어렴풋이 회사 안내 근처」라는 모호한 위치에 머물게 됩니다. 이용자가 「반품하고 싶다」라고 물어도 정확하게 맞지 않습니다.

그래서 자료를 의미의 덩어리 단위로 작게 나누어 각각을 벡터로 만듭니다. 이 나누는 작업이 청킹입니다.

너무 클 때 / 너무 작을 때 발생하는 일

청크(Chunk)의 사이즈는 「크면 좋다」 혹은 「작으면 좋다」가 아니라, 양쪽 모두에 실패 사례가 있습니다.

너무 작은 쪽의 실패는 처음 접했을 때 알아차리기 어렵기 때문에 예를 들어보겠습니다. 원래 문장이 다음과 같다고 가정합니다.

반품은 상품 도착 후 7일 이내에 접수합니다. 단, 세일 상품은 제외됩니다.

이를 한 문장씩 나누면, 두 번째 청크는 「단, 세일 상품은 제외됩니다」만 남게 됩니다. 무엇이 제외 대상인지가 사라집니다. 이 청크만 검색에서 히트하여 생성 AI에게 전달되면, AI는 무엇에 관한 이야기인지 몰라 그럴듯한 답변을 만들어 버립니다.

실용적인 출발점

엄격한 정답은 없으며, 다루는 문서에 따라 달라집니다. 다만 아무 준비 없이 시작할 수는 없으므로, 자주 사용되는 출발점을 제시합니다. 어디까지나 가이드라인으로 삼고, 후술할 검증을 통해 조정한다는 전제입니다.

• 1청크는 일본어 기준으로 수백 자 정도부터 시작한다
• 청크끼리 약간 겹치게 한다 (오버랩, Overlap). 경계에서 문맥이 끊기는 사고를 줄일 수 있다
• 겹치는 양은 1청크의 1~2할 정도부터 시도한다

오버랩의 이미지는 다음과 같습니다.

청크A: [ 반품은 상품 도착 후 7일 이내에 접수합니다. 단 ]
청크B: [ 접수합니다. 단 세일 상품은 제외됩니다. ]
↑ 겹치는 부분이 문맥의 가교 역할을 함

겹치면 저장하는 데이터 양은 늘어나지만, 경계에서 의미가 깨지는 사고를 줄일 수 있습니다.

글자 수로 나누기보다 구조로 나누기

이 부분이 가장 효과적인 포인트입니다. 「300자마다 기계적으로 나누기」보다, 원문 문서의 구조를 따라 나누는 것이 대개 훨씬 효과적으로 정밀도를 높여줍니다.

구체적으로는 다음과 같은 단위입니다.

• Markdown의 헤더 ( ## ) 단위로
• FAQ라면 「하나의 질문과 답변」으로 1청크
• 표라면 하나의 표를 쪼개지 않음
• 불렛 포인트(글머리 기호)는 중간에 끊지 않음

이는 당연하게 들리지만, 실제로는 기성 도구에 맡겨 글자 수로 나누고 있는 경우가 많습니다. 문서가 본래 의미의 덩어리를 가지고 있다면, 그것을 깨뜨리지 않는 것이 유리합니다. 사람이 「이 절을 읽으면 답을 알 수 있다」라고 느끼는 단위가 대개 좋은 청크가 됩니다.

반대로 구조가 없는 문서 (회의록 녹취록, 잡다한 메모)는 구조로 나눌 수 없으므로, 글자 수와 오버랩으로 타협하게 됩니다. 그런 경우에는 정밀도가 나오기 어렵다고 처음부터 예상하는 것이 건강한 접근입니다.

메타데이터를 함께 포함시키기

청크를 저장할 때, 본문뿐만 아니라 어디에서 왔는지도 함께 저장해 둡니다.

• 원래 파일명 또는 문서명
• 헤더의 계층 (예: 「반품에 대하여 > 기한」)
• 업데이트 날짜

이것이 효과를 발휘하는 상황은 두 가지가 있습니다. 하나는 답변에 출처를 덧붙일 수 있다는 점입니다. 이용자가 "정말로?"라고 생각했을 때 원래 자료를 확인할 수 있습니다. 또 다른 하나는 오래된 정보를 제외할 수 있다는 점입니다. 업데이트 날짜를 가지고 있으면 "1년 이상 된 문서는 사용하지 않는다"와 같은 필터링이 가능합니다.

헤더의 계층을 청크(Chunk) 본문의 앞부분에 추가해 두는 것도 실용적입니다. "단, 세일 상품은 제외됩니다"라는 문구 앞에 "반품에 대하여 > 기한"이 붙어 있는 것만으로도, 해당 청크 단독의 의미가 훨씬 명확해집니다.

나누는 방법을 바꿨다면, 반드시 비교할 것

청킹(Chunking)은 "시도하고 비교하기" 외에는 결정 방법이 없습니다. 감각으로 조정하다 보면, 고쳤다고 생각했는데 오히려 악화되는 일이 흔히 발생합니다.

최소한의 진행 방식은 다음과 같습니다.

• 실제로 물어볼 법한 질문을 10~20문항 리스트로 만든다 (만든 사람이 떠올리는 질문이 아니라, 이용자가 쓸 법한 말투로)
• 각각에 대해 "이 문서의 이 부분이 정답"이라는 정답을 미리 정해둔다
• 나누는 방법을 바꿀 때마다, 검색 결과 상위에 정답 문서가 포함되어 있는지 확인한다
• 생성된 답변의 품질은 검색이 제대로 이루어졌는지 확인한 뒤에 판단한다

3번과 4번을 분리하는 것이 중요합니다. 검색에서 정답을 찾아내지 못하고 있는데 생성 측을 조정해 봤자 해결되지 않습니다. 순서만 지켜도 불필요한 작업이 상당히 줄어듭니다.

질문 리스트는 한 번 만들어 두면 재사용할 수 있습니다. 수십 문항 정도만 되어도 충분히 기능하므로, 처음에 만들어 둘 가치가 있습니다.

요약

• 자료를 나누는 것은 전달할 수 있는 양의 상한선 때문만이 아니라, **검색의 정밀도 (Precision)**를 위해서이기도 하다. 긴 문장은 좌표가 흐릿해진다 - 너무 크면 답이 묻히고, 너무 작으면 문맥이 끊긴다. 실패는 양쪽 모두에 있다.
• 출발점은 수백 자 + 1~2할의 오버랩 (Overlap). 단, 이는 가이드라인일 뿐 정답은 아니다.
• 글자 수로 기계적으로 나누기보다, 헤더나 FAQ 단위 등 원래의 구조에 따라 나누는 것이 유리하다 - 파일명, 헤더 계층, 업데이트 날짜를 메타데이터 (Metadata)로 포함하면 출처 표시와 오래된 정보의 제외가 가능하다.
• 변경했다면 반드시 질문 리스트로 비교한다. 검색이 제대로 작동하는지 먼저 확인하고, 생성 조정은 그 다음에 한다.

청킹은 화려함이 없어서 뒤로 미뤄지기 쉽지만, RAG의 재작업(Rework)을 가장 많이 줄일 수 있는 부분입니다. 모델을 바꾸기 전에, 먼저 나누는 방법을 의심해 보세요.

―――――――――――――――――

📕 실전편 → 실무에서 무너지지 않는 AI 자동화 설계 입문 (¥1,500)
🔗 ITProDX.com → https://itprodx.com/?utm_source=zenn&utm_medium=article_footer&utm_campaign=revenue_funnel_2026q3

―――――――――――――――――

Discussion