제3장 — 고급 청킹 프레임워크

LLM Primer III: RAG로 강화하는 엔터프라이즈 AI를 챕터별로 소개하는 시리즈의 세 번째 글입니다. 순진한 선택이 뒤에 오는 모든 것을 가장 조용히 갉아먹는 자리이자 — 최근의 두 기법이 무엇이 가능한지를 다시 그린 최전선의 자리입니다.

이 장이 존재하는 이유

문서가 파싱되고 나면, 다음 결정은 동시에 가장 무거운 결정이기도 합니다. 임베드할 만큼 작고 그 자체로 의미를 지킬 만큼 큰 조각으로 어떻게 쪼갤 것인가. 이것이 청킹입니다. 정의에서 단서를 잘라 낸 청크는 자신만만하게 검색되어 자신만만하게 틀립니다. 무관한 다섯 주제를 한데 묶은 청크는 자신이 닿는 모든 임베딩을 희석합니다. 그 위에 올리는 검색 시스템은, 청킹 단계가 보존한 것만을 회복할 수 있습니다. 그리고 이 자리의 실패 모드는 조용합니다 — 리트리버는 여전히 후보를 돌려주고, 모델은 여전히 유창한 답을 만들어 내며, 답이 미묘하게 틀렸음은 오직 사용자만 알아챕니다.

3.1 청킹 스펙트럼

전략을, 문서에 대해 얼마나 알고 있느냐의 순서로 늘어놓는 편이 도움이 됩니다. 한쪽 끝에 있는 고정 크기 청킹은 아무것도 모릅니다 — 토큰을 세고 자릅니다. 빠르고 결정론적이며, 양식이 균일한 짧은 텍스트(채팅 로그, FAQ 항목, 고객 리뷰)에는 받아들일 만합니다. 구조화된 기술 문서 위에서는 조용한 재앙입니다. 재귀적 청킹은 우선순위가 있는 구분자 목록 — 단락, 줄바꿈, 문장, 단어 — 을 적용해, 목표 크기 안에 들어가는 가장 높은 우선순위 경계에서 자릅니다. 고정 크기만큼 싸면서 훨씬 낫습니다. 대부분의 팀에게 옳은 기본값입니다.

의미적 청킹은 결정을 구문에서 의미로 옮깁니다: 문장을 임베드하고 시퀀스를 따라 걸으며, 인접 문장 유사도가 임계 아래로 떨어지는 자리에서 주제 경계를 찍습니다. 구조 단서가 약한 장문(애널리스트 리포트, 인터뷰 스크립트)에는 잘 통하고, 빽빽한 상호 참조와 반복되는 상투구가 문장 임베딩을 헷갈리게 하는 구조화된 기술 문서에는 잘 통하지 않습니다. 구조 인지 청킹은 파싱된 문서를 트리로 보고 그 위에서 청킹합니다 — 섹션 단위, 헤더 레벨 단위, 코드 함수 단위. 잘 하면 가장 충실한 청킹이고, 상류에 레이아웃 인지 파서 없이 하면 재귀적 청킹과 다를 바 없습니다 — 구조가 애초에 추출되지 않았기 때문입니다. 이 넷은 함께 배치할 스택이 아니라 서로의 대안입니다.

3.2 오버랩 미신과 컨텍스트 클리프

거의 모든 튜토리얼이 청크 오버랩 15~20%를 권합니다. 직관은 그 정도에서는 맞습니다 — 오버랩은 경계 손실을 막아 줍니다 — 그러나 곡선은 빨리 평평해집니다. 첫 10%가 이득의 대부분을 회수합니다. 25%를 넘으면 정확도는 사실상 평평한 채로 비용이 세 축에서 올라갑니다: 임베딩 청구액은 청크 수에 선형으로 늘고, 인덱스 크기와 쿼리 지연도 늘며, 리트리버 상위 결과들이 서로의 거의 중복이 되기 시작합니다. 사용자 쿼리가 A, B, C 청크에서 같은 구절에 매치되고, 컨텍스트 윈도우는 새로운 정보 없이 소진되며, 리랭커는 같은 내용의 변형을 다시 정렬하는 데 예산을 씁니다. 30~40% 오버랩으로 손을 뻗고 있는 팀은, 그것을 오버랩이 너무 낮다는 신호가 아니라 청커가 틀렸다는 신호로 받아들여야 합니다.

관련되지만 구별되는 것이 컨텍스트 클리프입니다: 청크가 자신을 찾히게 했던 앵커 용어를 잃을 때 검색 품질이 가파르게 떨어지는 자리. 「2023년의 정책 47-B 개정은 모든 지점에 …을 요구했다」로 시작해 이후 문장들에서 요구 사항을 서술하는 단락. 도입부 다음에서 자르면, 요구 사항을 서술하는 청크는 더 이상 정책도, 개정도, 연도도 언급하지 않습니다. 그 청크는 무관한 쿼리에 자신만만하게 검색되고, 정작 핵심 쿼리는 놓칩니다. 검색은 top-k입니다 — 청크는 표면화되거나 그렇지 않거나이며, 점진적인 퇴화는 없습니다. 클리프는 기술 코퍼스의 지배적 실패 모드인데, 그곳에서는 대명사와 축약형이 한 섹션에 걸쳐 선행어를 이어 가기 때문입니다.

3.3 청크 크기를 쿼리 유형에 맞추기

청크 크기는 마치 단 하나의 옳은 답이 있는 것처럼 자주 논쟁됩니다. 단 하나의 옳은 답은 없습니다. 옳은 답은 시스템이 받을 쿼리에 따라 달라지기 때문입니다. 사실 조회 쿼리 — 「2024년 정책 47-B의 공제액은?」 — 는 150~300 토큰을 원합니다, 정확할 만큼 좁고 모호하지 않을 만큼 넓게. 추론 쿼리 — 「2023년 판과 2024년 판 사이 변화를 요약하고, 갱신에 어떻게 영향을 주는지 설명하라」 — 는 섹션 내 연결 조직을 보존하기 위해 800~1,200 토큰을 원합니다. 최적 크기는 둘 사이에서 4~8배 차이가 나고, 프로덕션 트래픽은 보통 둘이 섞인 형태입니다.

생산적인 응답이 둘 있습니다. 다중 그래뉼래리티 인덱싱은 같은 코퍼스를 여러 청크 크기로 저장하고, 의도 분류로 쿼리를 라우팅합니다. 계층적 검색은 정밀도를 위해 작은 청크를 인덱싱하지만 맥락을 위해 그 부모 섹션을 돌려줍니다 — 인덱스는 하나, 쿼리 시점에 조건이 붙고, 의도 분류가 틀려도 부드럽게 퇴화하기에 프로덕션에서 더 흔합니다. 부모-문서 패턴은 프로덕션 검색 문헌에서 가치가 가장 높은 기법 중 하나입니다.

3.4 컨텍스추얼 리트리벌과 레이트 청킹

최전선은 청크와 임베딩이 분리 가능한 관심사라는 인식입니다. 최근의 두 기법은 그 분리를 반대 방향으로 활용합니다. 2024년 Anthropic이 대중화한 컨텍스추얼 리트리벌은, 각 청크와 함께 전체 문서를 값싼 LLM에 보내 청크가 어디에 자리하는지에 대한 한두 문장 설명을 요청합니다 — 「이 청크는 2024년 정책 47-B 개정에서 도입된 공제 계산 변경을 다룬다」 — 그리고 그것을 청크 텍스트 앞에 붙여 임베드합니다. 청크는 원문이 결코 명명하지 않았던 쿼리에도 찾히게 됩니다. Anthropic의 평가에서 검색 실패가 약 49% 줄었고, 하이브리드 검색과 리랭킹이 위에 얹히면 더 줄어듭니다. 이것을 경제적으로 만드는 비결은 프롬프트 캐싱입니다: 문서를 한 번만 보내고, 각 청크는 캐시된 버전에 대해 처리합니다.

2024년 Jina AI가 도입한 레이트 청킹은 같은 문제를 반대편에서 공격합니다. 전체 문서를 긴 컨텍스트 임베딩 모델에 한 번에 통과시켜, 이미 문서 전체에 대해 맥락화된 토큰 단위 임베딩을 만듭니다. 그제야 문서를 청크로 나누고, 각 청크의 임베딩은 이제 맥락화된 토큰에서 풀링됩니다. 추가 LLM 호출 없이, 임베딩이 문서 수준 맥락을 암묵적으로 물려받습니다. 제약은 임베딩 모델이 이를 기본 지원해야 한다는 점(jina-embeddings-v3/v4와 일부 연구 모델이 지원)과 문서가 모델 윈도우에 들어가야 한다는 점입니다. 들어가는 문서에 대해서는 레이트 청킹이 인덱싱 비용의 한 자락으로 컨텍스추얼 리트리벌을 따라잡습니다. 들어가지 않는 문서에 대해서는 컨텍스추얼 리트리벌이 더 일반적입니다. 둘은 서로 배타적이지 않고, 진지한 프로덕션 시스템은 위에 중복 제거를 얹어 둘을 함께 돌리는 경우가 많습니다.

제3장이 준비하는 것

청킹은 파싱된 문서를 검색 가능한 단위들의 집단으로 바꿉니다. 각 단위는 살 자리가 필요합니다 — 저장되고, 인덱싱되고, 낮은 지연으로 질의되며, 코퍼스가 바뀌면 갱신되는 자리. 그 자리가 벡터 데이터베이스이고, 벡터 데이터베이스의 선택은 청킹 결정과 다른 종류의 결정입니다. 청킹은 소프트웨어 비용을 가진 소프트웨어 문제입니다. 데이터베이스 선택은 인프라, 운영, 규제적 귀결을 가진 소프트웨어 문제이고, 잘못된 선택은 되돌리는 데 여섯 달이 걸릴 수 있습니다.

다음 → 제4장: 올바른 벡터 데이터베이스 선택. 목적별 설계와 확장 아키텍처, 매니지드의 선두, 오픈소스의 진영, 그리고 실제 선택을 가르는 세 축 — 데이터 거주성, 운영, 총 비용.