실무AI 기초 및 활용 6회 — 문서는 어디서 잘라야 할까? — 청킹 비교
실무AI 기초 및 활용 · 6회 / 전체 12회
실무자도 놓치기 쉬운 AI 원리를 질문과 실험으로 확인합니다.
AI를 업무에 사용해본 분을 위한 강의입니다. 아래 실습은 독자 재현을 위한 절차이며 이 글에서 실행한 측정 결과를 뜻하지 않습니다.
정답 문장이 있는데도 답을 못 찾습니다
검색 결과에 ‘이번 주부터 변경’이라는 문장만 나오고 무엇이 바뀌었는지는 빠질 수 있습니다. 문서 분할이 문맥을 끊었기 때문일 수 있습니다. 검색 모델을 바꾸기 전에 청크에 필요한 조건이 함께 있는지 확인합니다.
이번 강의의 목표
고정 길이와 의미 단위 분할을 같은 자료에서 비교합니다. 청크 크기를 외우는 대신 질문에 필요한 근거를 보존하는 기준을 만듭니다. 작은 자료에서 결과를 확인하고 자신의 문서 구조에 맞게 조정합니다.
청크는 검색과 전달의 단위입니다
청크는 긴 문서를 처리하기 위해 나눈 조각입니다. 저장 단위, 검색 단위, 모델에 전달할 단위를 같게 만들 수도 있고 분리할 수도 있습니다. 무엇을 단위로 점수화하는지 명확히 해야 비교가 가능합니다.
고정 길이 분할
글자나 토큰 수에 따라 일정한 길이로 자르는 방법은 구현과 크기 관리가 쉽습니다. 다만 문장, 표, 조건이 중간에서 나뉠 수 있습니다. 단순함이 장점인 만큼 경계에서 생기는 실패를 평가해야 합니다.
문단과 제목 기준 분할
제목이나 문단을 경계로 쓰면 문서 구조를 보존하기 쉽습니다. 그러나 짧은 문단과 매우 긴 문단이 섞이면 크기가 불균일해집니다. 제목만 남은 조각이나 너무 긴 절을 어떻게 처리할지도 정해야 합니다.
작업 단위 분할
작업 로그는 목적, 수행 내용, 결과, 남은 일을 한 사건으로 묶을 수 있습니다. 이런 조각은 ‘왜 실패했나’ 같은 질문의 문맥을 보존하는 데 유리할 수 있습니다. 다만 사건 구분이 잘못되면 다른 작업이 섞일 수 있습니다.
문서 유형에 맞추기
매뉴얼, 회의록, 코드, 표는 구조가 다릅니다. 회의록은 발언 한 문장보다 결정과 근거를 함께 묶어야 할 수 있습니다. 모든 문서를 같은 문자 수로 자르는 정책은 출발점일 뿐입니다.
작은 청크의 교환
작은 조각은 질문 관련 부분을 좁게 찾는 데 도움이 될 수 있습니다. 반대로 대명사의 대상이나 예외 조건을 잃기 쉽습니다. 검색 점수가 높아져도 답변에 필요한 맥락이 줄었다면 성공으로 볼 수 없습니다.
큰 청크의 교환
큰 조각은 전후 문맥을 보존하지만 관련 없는 내용도 함께 들어갑니다. 입력 비용이 늘고 핵심 문장이 묻힐 수 있습니다. 크게 만드는 것만으로 모든 질문의 검색 품질이 좋아지지는 않습니다.
겹침을 두는 이유
인접 청크에 일부 내용을 겹치면 경계에서 잘린 문맥을 보완할 수 있습니다. 대신 저장량과 중복 검색이 늘어납니다. 겹침 비율은 문서 유형과 질문으로 비교하고, 정답 문장을 반복해 점수를 부풀리지 않게 주의합니다.
제목 경로와 메타데이터
상위 제목, 문서명, 개정일, 원문 식별자를 청크와 연결합니다. ‘적용 대상’ 같은 짧은 제목만으로는 의미가 부족할 수 있습니다. 사람이 읽을 문맥과 필터에 쓸 구조화된 메타데이터를 구분합니다.
문맥을 덧붙이는 접근
청크가 전체 문서에서 어떤 역할인지 짧은 설명을 붙여 검색 표현을 보완할 수 있습니다. 이 설명이 잘못 생성되면 검색을 오염시킬 수도 있습니다. 생성한 보조 문맥과 원문은 구분해 저장하고 검증합니다.
검색은 작게, 전달은 넓게
작은 청크를 검색한 뒤 같은 문서의 주변 문단이나 상위 절을 함께 전달할 수 있습니다. 검색 단위와 응답 근거의 단위를 분리하는 접근입니다. 주변 문단 확장에도 길이 한도와 권한 검사가 필요합니다.
표와 목록 다루기
표를 행만 잘라 보내면 열 제목과 단위가 사라질 수 있습니다. 각 조각에 필요한 머리글을 유지하거나 표 전체를 별도로 다룹니다. 항목 목록에서도 적용 조건을 떼어내면 사실과 의미가 달라질 수 있습니다.
코드와 오류 로그 다루기
코드 조각에는 함수 이름, 파일 위치, 주변 설정이 필요할 수 있습니다. 오류 메시지 한 줄만으로 원인을 확정하지 않습니다. 실행 환경과 관련 호출을 함께 찾을 수 있도록 구조와 메타데이터를 보존합니다.
실무 예시: 예외가 다음 문단에 있을 때
가상 규정의 첫 문단은 ‘모든 배포는 목요일’, 다음 문단은 ‘긴급 수정은 승인 후 즉시’라고 해봅니다. 첫 문단만 검색되면 긴급 수정 질문에 잘못 답할 수 있습니다. 예외 질문을 평가에 반드시 넣어야 합니다.
실습 준비
이후는 측정 안내입니다. 규정, 작업 로그, 표가 포함된 작은 문서 묶음을 준비합니다. 정답 문단과 필요한 주변 조건을 사람이 지정하고, 문서 원본은 바꾸지 않은 채 두 분할 방식을 만듭니다.
방법 A: 일정 길이
같은 토크나이저 기준의 고정 길이로 자릅니다. 길이와 겹침 값을 기록하고 마지막 조각도 보존합니다. 빈 조각, 지나치게 짧은 조각, 문장이 중간에서 끊긴 조각의 수를 확인합니다.
실험 기록 양식
| 조건 | 입력·설정 | 판정·측정값 |
|---|---|---|
| 변경 전 기준선 | 실행 전 기록 | 실행 후 기록 |
| 한 조건 변경 | 바꾼 항목만 기록 | 실행 후 기록 |
| 반복·확인 문제 | 버전과 반복 횟수 기록 | 실패 사례까지 기록 |
이 표는 빈 양식이며 측정값이나 성능 개선을 보고하는 자료가 아닙니다.
방법 B: 제목과 작업 경계
제목·문단·작업 경계로 분할하고 너무 긴 절만 추가로 나눕니다. 각 조각에 상위 제목과 원문 위치를 연결합니다. 사람이 손으로 정답이 있는 부분만 유리하게 나누지 않도록 규칙을 먼저 정합니다.
같게 유지할 조건
임베딩 모델, 질문, 필터, 후보 수는 고정합니다. 청킹 외의 설정을 함께 바꾸면 차이의 원인을 설명하기 어렵습니다. 검색 결과 수가 같아도 토큰 양이 다를 수 있으므로 전달 분량도 기록합니다.
평가할 세 가지
정답 근거 회수, 필요한 조건의 보존, 불필요하게 전달된 분량을 따로 봅니다. 한 점수로 합치기 전에 실패 유형을 읽습니다. 예외를 잃은 사례와 비용만 커진 사례는 개선 방법이 다릅니다.
버전과 재색인
분할 규칙이 바뀌면 청크 식별자와 인덱스가 달라질 수 있습니다. 이전 인용 링크가 새 원문을 정확히 가리키는지 확인합니다. 이전·새 인덱스를 구분하고 검증 후 전환하면 혼합 상태의 오류를 줄일 수 있습니다.
최적 크기는 고정 답이 아닙니다
문서 구조, 질문, 임베딩 모델, 답변 모델이 바뀌면 적절한 크기도 달라질 수 있습니다. 공개된 권장 숫자는 시작점으로 사용합니다. 실제 실패 사례로 조정하고 별도 확인 문제에서 개선이 유지되는지 봅니다.
핵심 정리
청킹은 길이 조절이면서 동시에 의미 보존 설계입니다. 목표는 작은 조각이나 큰 조각 자체가 아니라 정답과 조건을 함께 찾는 것입니다. 다음 회차에서는 검색 결과를 답변 생성으로 연결합니다.
출처
공식 문서·원 논문을 참고한 원리 설명입니다. 제품별 지원 범위는 실행 시점의 문서로 재확인하며, 실습 설계와 가상 사례는 이 강의의 예시입니다.
AI 도구의 도움으로 작성하고 공식 자료와 발행 규격을 확인했습니다. 삽화는 SVIL 로컬 AI 워크스테이션에서 생성한 신규·기존 개념 자산을 사용했습니다.
협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/