개념
청킹(chunking)은 원본 문서를 여러 개의 조각, 즉 청크로 나누는 작업이다. RAG(검색 증강 생성) 시스템은 사용자의 질문과 관련된 문서를 찾아 모델에게 함께 넘겨 주는데, 수백 쪽짜리 문서를 통째로 넘길 수는 없다. 컨텍스트 윈도우에 담기는 양에 한계가 있고, 설령 담긴다 해도 질문과 무관한 내용까지 섞여 답변 품질이 떨어지기 때문이다. 그래서 문서를 미리 적당한 크기로 잘라 두고, 질문이 들어오면 그중 관련 있는 조각만 골라 쓴다.
잘라 낸 조각은 각각 임베딩 벡터로 변환되어 벡터 데이터베이스에 저장된다. 검색 단위가 곧 청크이므로, 어떻게 자르느냐가 무엇이 검색되는가를 결정한다. 한 청크가 너무 크면 관련 없는 문장이 함께 딸려 와 검색 신호가 흐려지고, 너무 작으면 문맥이 잘려 조각만 봐서는 무슨 말인지 알 수 없게 된다.
자르는 방식은 크게 세 갈래다. 글자 수나 토큰 수를 기준으로 기계적으로 자르는 고정 길이 방식, 문단·제목·표 같은 문서 구조를 따라 자르는 구조 기반 방식, 문장 사이의 의미가 끊기는 지점을 찾아 자르는 의미 기반 방식이다. 조각끼리 일부 문장을 겹쳐 두는 오버랩을 함께 쓰면 경계에서 문맥이 잘리는 문제를 어느 정도 줄일 수 있다.
표나 코드 블록처럼 중간에서 끊기면 의미가 무너지는 요소는 따로 다루는 편이 안전하다. 표의 머리글이 한 청크에 들어가고 데이터 행이 다른 청크로 넘어가면 두 조각 모두 쓸모없어진다. 각 청크 앞에 그 문서의 제목이나 상위 섹션명을 짧게 붙여 두는 방법도 자주 쓰인다. 조각만 떼어 놓아도 어느 문서의 어느 대목인지 알 수 있게 만드는 장치다.
쓰임새
사내 문서 검색, 고객 지원 봇, 논문·매뉴얼 질의응답처럼 자체 문서를 근거로 답하게 만드는 시스템에서는 거의 예외 없이 청킹이 먼저 필요하다. 실무에서는 문서 성격에 따라 전략을 달리 가져간다. 규정집이나 매뉴얼처럼 제목 체계가 뚜렷한 문서는 구조를 따라 자르는 편이 자연스럽고, 회의록이나 채팅 로그처럼 구조가 약한 문서는 길이 기준에 오버랩을 더하는 쪽이 무난하다.
청크마다 출처 문서명, 작성일, 섹션 제목 같은 메타데이터를 함께 저장해 두는 것도 중요하다. 검색 결과를 걸러 내거나 리랭킹 단계에서 순위를 조정할 때, 그리고 답변에 근거 링크를 붙일 때 이 정보가 쓰인다.
적정 크기를 정하는 데 일반해는 없지만 접근 방식은 대체로 비슷하다. 실제로 들어올 법한 질문을 스무 개쯤 모아 두고, 청크 설정을 바꿔 가며 정답이 담긴 문단이 상위에 걸리는지 확인하는 식이다. 이때 검색 순위만 보지 말고 그 조각을 사람이 읽었을 때 질문에 답할 수 있는지까지 확인해야 한다. 사람이 읽어도 무슨 말인지 모르는 조각이라면 모델에게 넘겨도 결과는 같다.
자주 하는 오해
청크는 작게 자를수록 정확한 것 아닌가?
지나치게 작은 청크는 대명사나 생략된 주어를 해석할 문맥을 잃어버린다. 그러면 검색에는 걸리는데 읽어도 답이 나오지 않는 조각이 된다.
컨텍스트 윈도우가 커지면 청킹은 필요 없어지지 않나?
넣을 수 있는 양과 모델이 잘 활용하는 양은 다르다. 관련 없는 내용이 길게 섞이면 정확도가 떨어지고 토큰 비용도 그만큼 늘어난다.
청크 크기는 한 번 정해 두면 끝나는 설정 아닌가?
문서 종류와 질문 유형에 따라 적정 크기가 달라진다. 검색 결과를 보며 조정해 나가야 하는 튜닝 대상에 가깝다.
직접 실험해 보기: RAG 청킹 시뮬레이터에 문서를 붙여넣으면 청크 크기·오버랩에 따라 어떻게 잘리는지 바로 보인다.