3.5RAG 파이프라인과 청킹 설계

RAG 파이프라인은 사슬입니다. 앞 단계가 놓친 것은 뒤 단계가 복구하지 못합니다.

수집 → 파싱 → 청킹 → 임베딩/인덱싱 → 검색 → 재순위 → 컨텍스트 조립 → 생성

이 구조에서 중요한 함의는 생성 단계의 프롬프트를 아무리 다듬어도 검색이 못 가져온 정보는 답에 담기지 않는다는 것입니다. RAG 품질 문제를 프롬프트 문제로 진단하는 것이 실무에서 가장 흔한 오진입니다.

진단할 때는 사슬을 거꾸로 따라가며 각 단계를 분리해 봅니다.

증상	확인할 단계	확인 방법
답에 근거가 없거나 지어냄	검색	정답 청크가 결과에 있었는가
결과에는 있는데 답에 반영 안 됨	컨텍스트 조립·생성	순서·분량·프롬프트 확인
정답 청크가 애초에 없음	청킹·인덱싱	그 내용이 어느 청크에 들어갔는가
문서에 있는데 청크에 없음	파싱	표·이미지·각주가 유실됐는가

이 표에서 세 번째와 네 번째가 이 수업의 주제입니다. 그리고 파싱 유실은 과소평가되는 원인입니다. PDF의 표가 텍스트로 뭉개지거나 각주가 본문 중간에 끼어들면, 그 내용은 이후 어느 단계에서도 복구되지 않습니다.

공식 요강의 예시 문항이 짚는 지점도 여기입니다. 문서 갱신 직후 자신 있게 틀린 답이 나오고 지연시간과 모델 버전은 그대로라면, 원인은 검색이 낡거나 관련 없는 청크를 주고 있는 쪽입니다. 재색인이 깨졌거나 임베딩 공간이 어긋난 경우가 대표적입니다.

청킹 논의는 대개 "몇 토큰으로 자를까"로 시작하는데, 이것은 부차적인 질문입니다. 진짜 문제는 경계를 어디에 두는가입니다.

고정 길이로 기계적으로 자르면 문장이나 표가 중간에서 끊깁니다. 끊긴 청크는 두 가지로 나쁩니다. 임베딩이 어중간해져 검색이 안 되고, 검색되더라도 모델이 잘린 내용을 근거로 삼습니다.

실무에서 쓰는 원칙은 문서의 자연스러운 구조를 경계로 삼는 것입니다.

문서 유형	좋은 경계
기술 문서·매뉴얼	제목 계층 (섹션·하위 섹션)
법령·약관	조·항 단위
FAQ	질문 하나 = 청크 하나
회의록·대화	화제 전환 지점
코드	함수·클래스 단위
표	표 전체를 하나로, 행 단위로 쪼개지 않음

크기는 이 경계를 지킨 뒤에 조정하는 값입니다. 너무 작으면 맥락이 잘려 검색은 되는데 답하기에 부족하고, 너무 크면 한 청크에 여러 주제가 섞여 임베딩이 흐려집니다.

겹침(overlap) 은 경계 부근의 정보 유실을 완화하는 장치입니다. 앞 청크의 끝부분을 다음 청크 앞에 조금 포함시키면, 경계에 걸친 문장이 어느 한쪽에서는 온전히 남습니다. 다만 겹침은 저장량과 중복 검색을 늘리므로 무한정 키울 수 없습니다.

맥락 보강이 겹침보다 효과가 큰 경우가 많습니다. 각 청크 앞에 그 청크가 속한 문서 제목과 섹션 경로를 붙여두는 방식입니다.

[원본 청크]
"이 경우 환불은 영업일 기준 7일 이내에 처리된다."

[보강된 청크]
"문서: 2026 서비스 이용약관 > 제4장 결제 > 제12조 환불 절차
이 경우 환불은 영업일 기준 7일 이내에 처리된다."

보강 전 청크는 "이 경우"가 무엇인지 알 수 없어 검색에서도 걸리지 않고 근거로도 약합니다. 보강 후에는 무엇에 대한 규정인지가 청크 안에서 자립합니다.

인덱싱 단계에서 벡터만 저장하면 나중에 할 수 있는 일이 크게 줄어듭니다. 청크마다 메타데이터를 함께 저장해야 검색을 좁히고 인가를 적용하고 신선도를 판단할 수 있습니다.

최소한 함께 저장할 것:

• 출처 식별자 — 문서 ID, 청크 인덱스, 원문 위치. 인용과 사후 추적에 필요합니다.
• 접근 제어 정보 — 3.2에서 다룬 인가 필터의 근거가 됩니다.
• 시점 정보 — 문서 작성일과 인덱싱 시각. 오래된 내용을 걸러내거나 낮은 순위로 밀 수 있습니다.
• 문서 유형·부서 같은 분류 축 — 질의 유형에 따라 검색 범위를 좁힙니다.

임베딩 공간의 일관성은 조용히 무너지는 지점입니다. 인덱스를 만든 모델과 질의를 임베딩하는 모델이 다르면 유사도가 의미를 잃습니다. 임베딩 모델을 교체하면 인덱스 전체를 다시 만들어야 하고, 부분적으로만 재색인하면 새 청크와 옛 청크가 다른 좌표계에 놓여 검색 결과가 뒤섞입니다. 갱신 직후 품질이 무너지는 사고의 흔한 원인입니다.

갱신 전략도 설계 항목입니다. 문서가 바뀌었을 때 어떻게 반영할지 정해두지 않으면 인덱스가 서서히 원본과 어긋납니다.

전략	특징
전체 재색인	단순하고 확실하지만 비용이 크고 그동안 서비스 품질이 흔들림
증분 갱신	변경된 문서만 재처리. 삭제 반영을 빠뜨리기 쉬움
이중 인덱스 전환	새 인덱스를 만든 뒤 전환. 안전하지만 저장량이 두 배

증분 갱신에서 가장 자주 나오는 버그는 삭제된 문서의 청크가 인덱스에 남는 것입니다. 원본에서는 사라졌는데 검색에는 계속 잡혀 모델이 없는 규정을 근거로 답하게 됩니다. 이 실패는 오류를 내지 않아 발견이 늦습니다.

검색이 잘 되어도 조립이 나쁘면 답이 나빠집니다.

개수와 순서. 상위 몇 개를 넣을지는 트레이드오프입니다. 적게 넣으면 필요한 근거가 빠지고, 많이 넣으면 관련 없는 청크가 섞여 모델을 흐트러뜨리고 비용이 늘어납니다. 실무에서는 재순위(rerank)를 한 단계 더 두어 후보를 넓게 뽑은 뒤 정밀하게 좁히는 구성을 자주 씁니다.

근거 강제. 각 청크에 식별자를 붙여 넣고 답변에 인용을 요구하면, 모델이 근거 없이 말하는 빈도가 줄고 사후 검증이 가능해집니다. 인용이 붙으면 틀린 답이 나왔을 때 어느 청크를 잘못 읽었는지 바로 확인됩니다.

캐싱과의 관계. 검색 결과는 질의마다 달라지므로 프리픽스 앞쪽에 두면 안 됩니다. 안정적인 시스템 프롬프트와 지침을 앞에, 검색된 청크와 사용자 질문을 뒤에 배치해야 앞부분 캐시가 유지됩니다. 이 순서를 반대로 잡으면 캐시가 전혀 걸리지 않습니다.

[프롬프트 조립 순서]
1. 시스템 지침 (고정)          ← 캐시 경계
2. 검색된 청크 (질의마다 변함)
3. 사용자 질문 (질의마다 변함)

빈 결과 처리. 검색이 아무것도 못 찾았을 때의 동작을 정의해야 합니다. 정의하지 않으면 모델은 자기 사전 지식으로 답하고, 그것이 가장 위험한 형태의 오답입니다 — 근거가 없는데 자신 있게 말합니다. "제공된 자료에서 답을 찾을 수 없으면 그렇게 말하라"는 지침과, 빈 결과를 명시적으로 전달하는 구조가 함께 필요합니다.