TL;DR

프로덕션 환경의 RAG (Retrieval-Augmented Generation) 시스템은 단순히 벡터 검색 (Vector Search)을 감싼 하나의 모델 호출이 아닙니다. 이는 지식 준비 (Knowledge Preparation)와 런타임 검색 (Runtime Retrieval)이라는 두 가지 파이프라인을 가지며, 여기에 교차적인 평가 (Evaluation), 권한 부여 (Authorization), 관찰 가능성 (Observability), 최신성 (Freshness), 그리고 비용 제어 (Cost Controls)가 더해집니다.

최종 답변이 틀렸다면, 각 단계를 개별적으로 점검하십시오. 근본 원인은 오래된 소스, 손상된 파싱 (Parsing), 잘못된 청크 (Chunk) 경계, 검색 누락, 잘못된 필터 (Filter), 약한 재순위화 (Reranking), 노이즈가 섞인 컨텍스트 (Context), 또는 생성기 (Generator)의 과잉 해석일 수 있습니다.

기본적인 검색 증강 생성 (RAG) 데모는 화이트보드에 다음과 같이 적을 수 있습니다:

로드 (Load) → 청킹 (Chunk) → 임베딩 (Embed) → 검색 (Retrieve) → 생성 (Generate)

이는 유용한 추상화입니다. 하지만 동시에 많은 잘못된 프로덕션 결정이 시작되는 지점이기도 합니다.

한 직원이 다음과 같이 질문한다고 가정해 봅시다:

계약직 직원이 2026년에 해외 출장비를 청구할 수 있나요?

애플리케이션은 정책 단락을 검색하고, 모델은 인용구와 함께 확신에 찬 답변을 반환합니다. 응답은 좋아 보입니다. 하지만 다음과 같은 이유로 여전히 틀렸을 수 있습니다:

• 인덱싱된 정책이 작년에 만료됨;
• PDF 파서 (Parser)가 표를 제목에서 분리함;
• 청크 (Chunk)가 계약직에게 구체적으로 적용되는 문장을 누락함;
• 밀집 검색 (Dense Search)이 정확한 정책 코드를 놓침;
• 권한 필터 (Permissions Filter)가 내부 예외 사항을 노출함;
• 검색된 구절들이 서로 모순됨;
• 답변이 어떤 소스에서도 지원하지 않는 주장을 추가함.

이 모든 실패는 동일한 가시적 증상, 즉 '유창하게 틀린 답변'을 만들어낼 수 있습니다.

이것이 바로 RAG의 숨겨진 복잡성입니다. 모델은 훨씬 더 큰 시스템의 마지막 단계일 뿐입니다. 프로덕션 RAG는 지식 공급망 (Knowledge Supply Chain), 검색 엔진, 컨텍스트 구축 레이어, 평가 프로그램, 그리고 보안 경계입니다.

어려운 점은 파이프라인을 실행하는 것이 아닙니다. 올바른 증거가 모든 단계를 거치며 살아남았는지 아는 것입니다.

Architecture diagram showing an offline knowledge pipeline and a runtime query pipeline, both governed by evaluation, security and permissions, and observability and cost controls.
RAG는 지식 준비 (knowledge preparation)와 런타임 검색 (runtime retrieval)이라는 두 개의 파이프라인으로 이해하는 것이 더 정확하며, 이들은 평가 (evaluation), 보안 (security), 그리고 운영 제어 (operational controls)로 둘러싸여 있습니다.

RAG는 검색 이전에 시작됩니다

사용자가 질문을 하기 전에, 오프라인 파이프라인 (offline pipeline)은 가능한 모든 답변을 제한하는 결정들을 이미 내려놓은 상태입니다.

어떤 소스를 신뢰할지 결정했습니다. 파일을 파싱 (parse)했습니다. 구조를 제거하거나 보존했습니다. 콘텐츠를 청크 (chunks)로 분할하고, 메타데이터 (metadata)를 부착하며, 임베딩 (embeddings)을 생성하고, 인덱스 (index)에 레코드를 기록했습니다. 또한 소스가 변경될 때 해당 레코드를 업데이트하거나 삭제해야 합니다.

이것은 단순한 사무적 전처리 (clerical preprocessing)가 아닙니다. 이는 모델의 효과적인 지식 시스템 (knowledge system)의 일부입니다.

파싱은 정보 손실의 문제입니다

파서 (parser)는 문서에서 보이는 모든 단어를 추출할 수 있지만, 여전히 그 의미를 파괴할 수 있습니다.

다음과 같은 내용이 포함된 정책 PDF를 생각해 보십시오:

• 범위를 정의하는 섹션 제목 (section headings);
• 예외 사항을 나열하는 각주 (footnotes);
• 열 헤더가 다른 페이지에 나타나는 표 (table);
• 스캔된 서명 또는 수기 날짜;
• 반복되는 헤더 및 탐색 텍스트;
• 텍스트 레이어에는 나타나지 않는 라벨이 포함된 다이어그램 (diagrams).

일반 텍스트 추출기 (plain-text extractor)는 해당 구조를 그럴듯해 보이는 단어의 흐름으로 평탄화 (flatten)할 수 있습니다. 파이프라인은 기술적으로는 성공하지만, 단어들 사이의 관계는 사라집니다.

해결책이 항상 더 나은 프롬프트 (prompt)인 것은 아닙니다. 레이아웃 인식 추출 (layout-aware extraction), OCR, 표 처리 (table handling), 미디어 특화 파싱 (media-specific parsing), 또는 품질 검사를 통과하지 못한 문서에 대한 검토 큐 (review queue)가 필요할 수 있습니다.

실질적인 규칙은 간단합니다:

수집 파이프라인 (ingestion pipeline)이 증거를 잃어버리면, 검색기 (retriever)는 나중에 이를 복구할 수 없습니다.

청킹은 검색 정책입니다

청크 크기 (Chunk size)는 종종 튜토리얼에서 복사해 오는 설정 값처럼 취급됩니다. 하지만 실제로 이는 시스템이 하나의 단위로서 무엇을 검색할 수 있는지를 결정합니다.

너무 작은 청크 (Chunks)는 주장(claim)을 그 수식어(qualifier), 제목, 날짜 또는 예외 사항으로부터 분리할 수 있습니다. 반대로 너무 큰 청크는 여러 주제를 뒤섞어 검색 정밀도(retrieval precision)를 약화시키고 컨텍스트 예산(context budget)을 낭비할 수 있습니다.

보편적으로 정답인 토큰(tokens) 수는 존재하지 않습니다. 올바른 전략은 문서 구조, 질의 패턴(query patterns), 검색 방법(retrieval method), 그리고 무엇을 충분한 증거로 간주할 것인지에 따라 달라집니다.

유용한 접근 방식은 다음과 같습니다:

• 헤딩(headings) 및 섹션 경로 보존
• 표(tables)를 해당 제목 및 열 레이블(column labels)과 함께 유지
• 부모-자식 관계(parent-child relationships) 저장
• 아이디어가 경계를 넘나드는 경우 제어된 중첩(controlled overlap) 추가
• 출처, 버전, 날짜, 저자 및 액세스 메타데이터(metadata) 부착
• 고정된 윈도우(fixed windows)가 의미를 잃을 때 구조 인식(structure-aware) 또는 의미론적 분할(semantic splitting) 사용

Microsoft의 현재 RAG 설계 가이드라인은 청킹(chunking)을 관습에 따라 선택하는 것이 아니라, 대표적인 문서와 질의를 바탕으로 평가되어야 하는 실험적 단계로 취급합니다.

Visual comparison of three chunking strategies: chunks that are too small separate a rule from its exception, structure-aware chunks preserve sufficient evidence, and oversized chunks dilute the signal with unrelated material.
청크 경계는 어떤 사실, 수식어, 메타데이터 및 표 레이블이 함께 검색될 수 있는지를 결정합니다.

최신성(Freshness)을 위해서는 삭제 시나리오가 필요합니다

문서를 추가하는 것은 쉽습니다. 현실을 동기화하는 것은 더 어렵습니다.

프로덕션 지식 파이프라인(knowledge pipeline)은 다음 질문에 답할 수 있어야 합니다:

• 변경된 소스가 얼마나 빨리 검색에 나타나야 하는가?
• 이름이 변경되거나 중복된 문서는 어떻게 감지하는가?
• 페이지가 삭제되면 어떤 일이 발생하는가?
• 소스가 취소된 후에도 오래된 임베딩(embedding)이 남아있을 수 있는가?
• 두 버전이 충돌할 때 어떤 소스가 우선하는가?
• 답변이 사용된 버전과 유효 날짜를 표시할 수 있는가?

안정적인 문서 식별자(document identifiers), 버전 관리(versioning), 변경 감지(change detection), 그리고 삭제 전파(deletion propagation)가 없다면, RAG 시스템은 오래된 정보(stale information)를 보여주는 세련된 인터페이스로 전락할 수 있습니다.

시계열 검색(Temporal retrieval)은 단순히 최신 문서를 선호하는 것보다 더 어렵습니다. 질문은 어떤 사건이 발생한 시점, 소스가 게시된 시점, 또는 특정 규칙이 유효했던 시점을 참조할 수 있기 때문입니다. 2024년 TempRALM 연구는 의미론적 관련성(semantic relevance)과 시계열적 관련성(temporal relevance)을 별도로 처리해야 한다는 유용한 근거를 제시하지만, 보고된 성능 향상은 보편적인 운영 레시피가 아닌 특정 시계열 벤치마크에서 얻은 결과입니다.

검색은 데이터베이스 조회(database lookup)가 아니라 랭킹 파이프라인(ranking pipeline)이다

데이터 수집(ingestion) 이후, 온라인 시스템은 다른 역할을 수행합니다. 바로 사용자의 언어를 유용한 증거들의 순위가 매겨진 세트(ranked set)로 변환하는 것입니다.

이는 단순히 최근접 이웃 탐색(nearest-neighbor search) 이상의 작업을 포함합니다.

밀집 검색(Dense retrieval)은 유용하지만 마법은 아니다

임베딩 검색(Embedding search)은 쿼리와 문서가 서로 다른 단어를 사용하더라도 관련된 의미를 매칭하는 데 탁용합니다. 하지만 정확한 식별자(identifiers), 제품명, 약어(acronyms), 날짜, 그리고 희귀 용어(rare terms)는 여전히 놓칠 수 있습니다.

만약 사용자가 정책 TRV-2026-07에 대해 묻는다면, 어휘 검색(lexical search)이 의미론적 벡터(semantic vector)만 사용하는 것보다 해당 문자열을 더 신뢰성 있게 인식할 수 있습니다. 반대로 사용자가 "해외 계약업체 비용 규정"이라고 말한다면, 밀집 검색(dense retrieval)이 더 도움이 될 수 있습니다.

이것이 하이브리드 검색(hybrid retrieval)이 여전히 중요한 이유입니다. 현재 Azure AI Search 문서에서는 전체 텍스트(full-text) 쿼리와 벡터(vector) 쿼리를 병렬로 실행하고, 상호 순위 결합(Reciprocal Rank Fusion)을 통해 그 결과를 병합하는 방식을 설명합니다. 여기서 얻을 수 있는 더 큰 교훈은 특정 벤더에 국한되지 않습니다. 어휘적 신호(lexical signals)와 의미론적 신호(semantic signals)는 서로 다른 방식으로 실패하므로, 하나가 다른 하나를 대체할 것이라고 가정하기보다 이들을 결합하는 것이 더 강력할 수 있습니다.

필터는 관련성(relevance)의 일부이자 보안(security)의 일부이다

메타데이터 필터(Metadata filters)는 지역, 제품, 언어, 문서 유형, 유효 날짜(effective date) 또는 테넌트(tenant)와 같은 속성을 통해 후보군(candidate set)을 좁힙니다.

이러한 필터들은 품질을 향상시킬 수 있지만, 메타데이터(metadata)가 누락되었거나 잘못된 경우 정답을 제거해 버릴 수도 있습니다. 필터 적용 시점—벡터 검색(vector search) 전인지 후인지— 또한 재현율(recall)과 지연 시간(latency)에 영향을 미칠 수 있습니다.

현재의 Azure 벡터 필터 가이드라인은 이러한 트레이드오프(tradeoff)를 명시적으로 설명합니다. 필터 모드, 선택도(selectivity), 인덱스 구조(index structure), 그리고 후보군(candidate count)은 재현율과 성능 모두를 변화시킬 수 있습니다. 이는 구현 방식에 따른 특정 가이드라인이지만, 일반적인 교훈은 유효합니다. 즉, 필터는 애플리케이션 로직(application logic)뿐만 아니라 검색 평가(retrieval evaluation) 단계에 포함되어야 합니다.

권한 필터(Permission filters)는 더욱 심각한 문제입니다. 사용자가 접근할 수 없는 콘텐츠가 검색된 후보군(candidate set)에 포함되지 않도록 반드시 보장해야 합니다. 모델에게 "기밀 정보를 공개하지 마세요"라고 말하는 것은 접근 제어(access control)가 아닙니다.

만약 권한이 없는 청크(chunk)가 프롬프트(prompt)에 도달한다면, 보안 실패는 이미 발생한 것입니다.

리랭킹(Reranking)은 별도의 모델 결정 사항입니다

1단계 검색기(first-stage retriever)는 그럴듯한 후보군을 빠르게 찾는 데 최적화되어 있습니다. 리랭커(reranker)는 더 많은 연산량을 사용하여 쿼리(query)를 더 작은 후보군과 비교하고 해당 결과들의 순서를 재조정합니다.

이는 관련성(relevance)을 높일 수 있지만, 다음과 같은 새로운 선택 사항들을 수반합니다.

• 얼마나 많은 후보군이 리랭커로 들어가는가?
• 리랭커가 어떤 필드(field)를 보는가?
• 지연 시간(latency)과 비용이 얼마나 추가되는가?
• 해당 도메인과 언어에 적합하게 작동하는가?
• 개선된 순위(ranking)가 실제로 최종 답변의 품질을 향상시키는가?

현재의 시맨틱 랭킹(semantic-ranking) 문서는 이러한 제약 사항들을 구체적으로 명시합니다. 리랭킹은 초기 순위가 매겨진 집합을 대상으로 작동하며 입력 제한이 있습니다. 따라서 "리랭커를 추가하는 것"은 공짜로 얻는 품질 업그레이드가 아닙니다. 이는 벤치마크(benchmark)를 수행해야 하는 또 다른 단계입니다.

쿼리 재작성(Query rewriting)은 도움이 될 수도 있지만, 질문을 조용히 바꿀 수도 있습니다

실제 질문은 복잡합니다. 오타, 대명사, 누락된 문맥, 그리고 한 문장 안에 포함된 여러 개의 요청 등을 포함하고 있습니다.

쿼리 레이어 (Query layer)는 유의어를 확장하거나, 질문을 재작성하거나, 이를 하위 쿼리 (subqueries)로 분해하거나, 대화 기록을 사용할 수 있습니다. 이는 다중 부분 (multi-part) 및 멀티홉 (multi-hop) 질문에 대한 커버리지를 개선할 수 있습니다. 하지만 사용자의 의도에서 벗어나거나, 너무 광범위하게 검색하거나, 지연 시간 (latency)과 비용을 증가시킬 수도 있습니다.

현재의 에이전트 기반 검색 가이드 (agentic retrieval guidance)는 분해 (decomposition), 병렬 하위 쿼리 (parallel subqueries), 재순위화 (reranking), 그리고 출처 추적 (source tracking)을 설명합니다. 또한 에이전트 기반 검색은 지연 시간을 추가하며, 일부 기능은 여전히 프리뷰 (preview) 기능으로 남아 있다고 명시합니다.

에이전트 기반 RAG (Agentic RAG)는 단순히 "고급 RAG"가 아닙니다. 이는 트레이드오프 (trade)입니다. 더 많은 계획 (planning), 비결정론 (nondeterminism), 비용, 실패 모드 (failure modes), 그리고 관측성 (observability) 작업과 교환하여 더 적응적인 검색을 얻는 것입니다.

Retrieval-funnel diagram showing an authorized query branching into lexical and vector retrieval, followed by rank fusion, a policy guard, reranking, and a small set of evidence passages entering the context window.
훌륭한 검색은 모든 전환 단계에서 트레이드오프를 측정하면서, 광범위하고 권한이 부여된 후보 세트를 작은 증거 세트로 좁힙니다.

컨텍스트 구성은 모델이 무엇을 볼 수 있는지를 결정합니다

검색은 후보 (candidates)를 생성합니다. 이러한 후보들이 자동으로 프롬프트 (prompt)가 되어서는 안 됩니다.

컨텍스트 구성 레이어 (context-construction layer)는 다음과 같은 작업이 필요할 수 있습니다:

• 중복 및 유사 중복 제거;
• 출처의 다양성 유지;
• 인접 섹션 또는 상위 섹션 첨부;
• 제목, 날짜 및 출처 (provenance) 보존;
• 충돌하는 버전 감지;
• 토큰 예산 (token budget) 내에 증거 맞추기;
• 의도적으로 구절 (passages) 정렬;
• 안정적인 인용 앵커 (citation anchors) 생성;
• 신뢰도가 낮거나 권한이 없는 자료 제외.

이것이 중요한 이유는 더 많은 컨텍스트가 항상 더 좋은 것은 아니기 때문입니다.