결론부터 말씀드리면, RAG에서 진짜 중요한 건 어떤 AI 모델을 쓰느냐가 아니라 문서를 얼마나 잘 나누느냐예요. 아무리 좋은 모델이어도 문서를 이상하게 잘라 넣으면 엉뚱한 답이 나오거든요. 그래서 오늘은 문서 청킹, 그러니까 긴 문서를 검색하기 좋은 크기로 나누는 작업을 어떻게 시작하면 좋을지 정리해볼게요.
왜 문서를 통째로 넣으면 안 될까요
AI는 한 번에 읽을 수 있는 양이 정해져 있고, 그 안에서 질문에 맞는 부분을 골라내야 해요. 50쪽짜리 사내 규정집을 통째로 던져주는 것보다 ‘휴가 신청’ 관련 단락 하나만 딱 찾아서 보여주는 게 훨씬 정확한 답을 얻을 확률이 높아요. 문서를 잘게 나눠서 검색한 다음, 관련 있는 조각만 AI에게 전달하는 게 RAG의 기본 흐름이에요.
문서 종류별로 나누는 방식이 달라요
일반 안내문은 제목과 문단 기준으로 나누되 문단 중간을 자르지 않는 게 기본이에요. FAQ는 질문과 답변을 한 세트로 묶어야 하고, 질문만 따로 떨어뜨리면 안 돼요. 계약서나 규정은 조항 단위로 나누면서 예외 조항은 앞뒤 문맥과 함께 보관하는 게 중요하고요. 표가 많은 문서는 표 제목과 설명을 함께 묶어서 열 이름이 빠지지 않게 해야 해요.
처음 시작할 때 이렇게 해보세요
질문이 자주 나오는 문서부터 골라서 최신본인지 먼저 확인하고, 큰 제목과 문단 기준으로 나눠보세요. 같은 주제의 조각이 너무 멀리 떨어지지 않도록 앞뒤 문장을 살짝 겹치게 두는 것도 방법이에요. 그다음 실제 사용자가 할 법한 질문 10개 정도로 검색 결과를 시험해보세요. 답이 자주 엇나간다면 조각 크기보다 먼저 문서 제목, 날짜, 부서 같은 메타데이터가 함께 들어갔는지부터 확인하는 게 순서예요.
처음부터 완벽한 청크 크기를 찾으려고 애쓸 필요는 없어요. 안내문처럼 문단이 짧고 구조가 분명하면 문단 단위로 시작하고, 기술 문서처럼 한 주제가 여러 문단에 걸쳐 있으면 소제목 단위로 묶어보세요. 청크 하나만 읽어도 ‘이게 뭐에 관한 내용인지’ 바로 알 수 있어야 하고, 청크 앞부분에 문서명과 소제목을 남기면 나중에 사람이 검토하기도 훨씬 편해져요.
검색 결과가 이상할 때 점검하는 순서
답변이 자꾸 틀리게 나오면 무작정 모델부터 의심하지 말고 이 순서로 짚어보세요.
- 질문에 쓴 단어가 문서에 실제로 쓰인 표현과 다른지 확인해요.
- 관련 문서가 색인에 들어갔는지, 최신 버전인지 확인해요.
- 청크가 너무 작아서 조건과 예외가 분리된 건 아닌지 살펴봐요.
- 한 청크에 주제가 너무 많이 섞였다면 소제목 기준으로 다시 나눠요.
예를 들어 ‘환불 기간’을 물었는데 ‘교환 기간’만 인용해서 답한다면, 모델을 바꾸기 전에 문서 제목과 메타데이터, 청크 경계부터 확인해야 해요. 검색 단계 문제인지 생성 단계 문제인지 나눠서 보는 습관이 품질 개선의 출발점이거든요. 청크에는 가능하면 문서 제목, 작성 부서, 적용 날짜, 원문 위치도 함께 기록해두세요. 같은 규정의 예전 버전과 최신 버전이 동시에 검색되면 AI가 내용을 섞어버릴 수 있으니, 폐기된 문서는 색인에서 빼고 새 문서가 올라오면 예전 문서가 계속 검색되지 않는지도 확인하는 운영 규칙이 필요해요.
청킹에 정답은 하나가 아니에요
문서 종류와 질문 형태에 따라 적절한 경계는 달라져요. 사용 설명서는 기능별로, 사규는 조항별로, 회의록은 안건별로 나누는 게 이해하기 쉽고요. 가장 좋은 기준은 정해진 숫자가 아니라 사용자 질문에 필요한 문맥이 함께 검색되는지 여부예요. 문서 전체를 한 번에 바꾸기보다 같은 문서 일부만 여러 방식으로 나눠서 비교해보는 것도 좋은 방법이에요. 질문 다섯 개를 정해두고 방식별로 검색된 원문과 AI 답변을 나란히 기록하면 어떤 방식이 더 안정적인지 눈으로 바로 확인할 수 있어요.
텍스트가 정상적으로 추출되는 PDF는 그대로 넣어도 괜찮지만, 스캔본이라면 OCR 오류가 없는지 먼저 확인하는 게 좋아요. LangChain의 Text Splitter 문서 같은 데도 참고할 게 많고요. 청킹은 한 번 설정하고 끝나는 작업이 아니라 실제 질문으로 계속 확인하면서 다듬어가는 작업이라는 것만 기억해두면 충분해요.
