8.2.2 청킹(Chunking) 전략이 오라클 정확도에 미치는 영향

골든 문서(Golden Document)가 인간의 눈에 아무리 완벽하게 클렌징(Cleaning)되어 있다 한들, 수백 페이지에 달하는 이 거대한 텍스트 덩어리를 통째로 Vector DB 인덱스에 밀어 넣거나 모델의 프롬프트로 한 번에 전송할 수는 없다. 수학적으로 변환을 수행하는 임베딩 모델(Embedding Model)과 텍스트를 생성하는 타겟 LLM 모두, 어텐션(Attention) 연산 과정에서 메모리 한계로 인해 각자 한 번에 처리할 수 있는 최대 컨텍스트 윈도우 길이(Max Token Limit)라는 물리적 허들을 지니고 있기 때문이다.

따라서 문서를 수십, 수백 개의 쪼개진 작은 조각으로 강제로 절단해 내는 전처리 작업이 필수적인데, MLOps 엔지니어링에서는 이를 **청킹(Chunking)**이라고 명명한다. 초보자들은 청킹을 단순히 .split() 함수를 써서 글자 수를 나누는 1차원적 행위로 치부하기 쉽지만, 이 청킹 알고리즘의 전략적 파라미터 설계(Size, Overlap Boundary, Meta-data Injection)야말로 향후 RAG 파이프라인 전체의 쿼리 검색 품질(Recall)과 오라클 심판관의 교차 검증 정확도를 근본적으로 좌우하는 가장 치명적이고 핵심적인 하이퍼파라미터(Hyperparameter)다.

1. 청크 크기(Chunk Size)와 의미론적 텐서 밀도(Semantic Density)의 딜레마 극복

청크의 최적 크기를 결정하는 것은 ’노이즈 난입(Noise)’과 ‘컨텍스트 손실(Context Loss)’ 사이에서 벌어지는 살벌하고 지독한 트레이드오프(Trade-off) 줄다리기다.

• 극소형 단위 조각 (예: 100 Tokens 미만): 청크 페이로드가 너무 작게 파편화되면 수학적인 벡터 고차원 공간에서 질문과 청크 사이의 핀셋 검색 일치율(Hit Rate)은 극단적으로 우상향한다. 하지만 시스템적인 치명적 에러가 터진다. 대명사인 ‘그 이사(He)’, ’이 결제 모듈(It)’이 가리키는 원래 주어 명사가 앞선 청크에 무참히 잘려버려 증발(Evaporate)하기 때문에, 나중에 이를 건네받은 오라클 판사는 이 찢겨진 고아 문맥(Orphaned Context)만을 쥐고 “주어가 없으므로 이 응답 노드의 근거를 증명할 수 없다“며 시스템에 기계적인 Fail 에러 코드를 무한 남발하게 된다.
• 거대 단위 조각 (예: 2000 Tokens 이상): 반대로 문맥 단절을 두려워하여 챕터 내용 전체를 하나로 무식하게 뭉쳐버리면, 하나의 긴 청크 벡터 안에는 유저 질문과 직결된 정답 단 한 줄과, 질문과 전혀 상관없는 오염된 쓰레기 정보 1999줄이 불협화음을 내며 압축 공존하게 된다. 이렇게 되면 임베딩 모델이 뽑아낸 평균 다차원 벡터 값이 무의미하게 중화(Vector Dilution)되어, 정작 꼭 가져와야 할 위급한 문서를 엉뚱한 벡터 좌표 구석에 박아버리고 찾지 못하게 되는 끔찍한 검색 실패(Retrieval Failure)를 런타임에 야기한다.

2. 오버랩(Overlap Sliding Window)을 통한 문맥 절단 방어망 구동

이러한 물리적 텍스트 절단 방식이 야기하는 치명적인 정보의 엣지(Edge) 부작용을 막기 위해 고안된 수학적 꼼수가 바로 오버랩(Overlap) 파라미터다. 이는 앞 청크 블록의 꼬리 부분 일부 텍스트를, 다음 이어질 청크 블록의 머리 부분에 의도적으로 중복해서 붙여 넣는(Sliding Window) 중첩 기법이다.

• 동작 메커니즘: 예를 들어 개발자가 Chunk Size를 500 토큰으로, Overlap을 50 토큰으로 설정했다면, 두 번째 텍스트 청크는 501번째 토큰부터 시작하는 것이 아니라, 뒤로 후진하여 첫 번째 청크의 450번째 토큰부터 시작하여 950번째 토큰까지를 그릇에 담게 된다.
• 오라클 방어 기제: 이 겹침(Overlap) 보호 구역이 시스템에 존재해야만, 문장 중간이 알고리즘에 의해 날카롭게 토막 났을 때 발생하는 앞뒤 지식 간의 논리적 인과관계(Causality) 단절을 접착테이프처럼 이어 붙여 복원할 수 있다. 훗날 RAG 오라클 모듈이 생성된 정답의 ’충실성(Faithfulness)’을 교차 검증하려고 대조할 때, 이 오버랩 구역은 판사 모델이 잘려 나간 문맥의 뉘앙스를 온전히 복구하고 부드럽게 이어가는 데 절대적으로 필수적인 다리(Bridge) 인프라 역할을 수행한다.

3. 평가 오라클을 위한 청킹 추적성(Traceability Lineage)의 강제 확보

데이터 아키텍트가 저지르는 가장 치명적인 파이프라인 설계 결함은, 쪼개져서 Vector DB에 기계적으로 흩뿌려진 암호화된 ’검색용 청크 배열’과, 오라클이 정답 채점용으로 가지고 있는 ‘완전한 골든 문서 원본’ 사이의 매핑 계보(Data Lineage)가 런타임 쿼리 중에 영구히 끊어져 버리는 현상이다.

이 거대한 백엔드 파이프라인이 제어 가능한 상태로 정상 구축(Orchestration)되기 위해서는, 파이썬 청킹 파서(Parser)가 원본 텍스트를 무자비하게 조각낼 때마다, 각 청크 타일(Tile)에 발급된 UUID(고유 식별자 해시)와 ‘원본 문서를 칭하는 PK ID, 페이지 번호, 부모 물리적 헤딩(Heading) 계층’ 정보를 JSON 메타데이터 필드 안에 끈질기고 독하게 하드코딩 기록(Trace Logging)해 두어야만 한다.

그래야만 나중에 오라클 심판관이 “타겟 언어 모델이 방금 뱉은 이 위험한 발언은, Document ID DOC-405번의 두 번째 단락에서 가져온 Chunk_ID: CHK-1024를 수학적으로 기반하여 연역되었음을 완벽히 증명(Attribution)한다“라는 무결하고 안전한 서버 결정론적 역추적 증명(Deterministic Backtracking Proof)을 로그 파일 상에 확실하게 성립시킬 수 있는 것이다.