핵심 요약
기업 환경에서 RAG 시스템을 구축할 때 가장 큰 난관은 수많은 문서 중에서 정확한 정보를 빠르게 찾아내는 것입니다. 특히 10페이지짜리 간단한 보고서부터 1000페이지가 넘는 기술 매뉴얼까지 다양한 분량의 문서가 섞여 있다면 검색 정확도는 더욱 떨어지게 됩니다. 이 문제를 해결하기 위해 사전에 문서를 체계적으로 요약하고, 이를 쿼리 라우팅에 활용하는 Agentic RAG 접근법이 주목받고 있습니다. 문서 마스터 테이블에 간략 요약과 상세 요약을 저장하고, 청크 단위로도 요약 정보를 포함시켜 카테고리 기반 검색과 문서 범위 좁히기를 수행한 뒤 하이브리드 검색 전략으로 최종 답변을 생성하는 방식입니다.
도입
회사에서 RAG 시스템을 처음 도입했을 때의 기억이 납니다. 수천 개의 PDF 문서를 벡터 데이터베이스에 넣고 “이제 우리도 AI 검색이 가능하다”며 뿌듯해했죠. 그런데 막상 실무자들이 질문을 던지면 엉뚱한 답변이 나오거나, 관련 없는 문서에서 내용을 가져오는 경우가 부지기수였습니다.
문제는 단순했습니다. 시스템이 문서의 맥락을 전혀 이해하지 못하고 있었던 겁니다. 마치 도서관 사서가 책 제목도 모른 채 무작위로 책장을 뒤지는 격이었죠. 그때 깨달았습니다. RAG 시스템에게도 문서에 대한 사전 지식이 필요하다는 것을요.
문서 분량의 다양성이 만드는 검색의 딜레마
실제 기업 환경을 들여다보면 문서의 스펙트럼이 정말 넓습니다. 영업팀의 10페이지짜리 주간 보고서가 있는가 하면, 기술팀의 100페이지 API 문서, 그리고 법무팀의 1000페이지가 넘는 계약서 모음집까지 존재합니다.
10페이지짜리 문서는 한눈에 파악이 가능합니다. LLM에게 전체 내용을 던져도 컨텍스트 윈도우 안에 충분히 들어갑니다. 하지만 100페이지가 넘어가면 이야기가 달라집니다. 한 번에 처리하기엔 부담스럽고, 그렇다고 무작정 쪼개서 임베딩하면 맥락이 끊어져버립니다.
1000페이지짜리 문서는 더 심각합니다. 이런 문서를 청크 단위로만 쪼개서 벡터 검색에 의존하면 정말 필요한 정보를 찾기까지 여러 차례 시도해야 합니다. 사용자는 답답함을 느끼고, 시스템은 불필요한 연산만 반복하게 됩니다.
여기서 근본적인 질문이 생깁니다. 사용자의 질문이 들어왔을 때, 시스템이 어떻게 하면 가장 관련성 높은 문서부터 찾아볼 수 있을까요?
사전 요약이 필요한 이유
사람이 도서관에서 책을 찾을 때를 생각해보세요. 우리는 책 제목, 목차, 서문을 먼저 훑어봅니다. 그리고 “아, 이 책이 내가 찾는 내용을 다루고 있구나”라고 판단한 뒤에야 본문을 자세히 읽기 시작합니다.
RAG 시스템도 마찬가지입니다. 모든 문서에 대해 사전에 요약본을 만들어두면, 사용자의 질문이 들어왔을 때 먼저 요약본을 보고 “이 문서가 관련 있을 것 같은데?”라고 판단할 수 있습니다. 이것이 바로 쿼리 라우팅의 핵심입니다.
사전 요약 방식은 실시간 검색보다 훨씬 효율적입니다. 문서가 업로드되는 시점에 한 번만 요약을 수행하면 되니까요. 이후 수천 번의 검색 요청이 들어와도 이미 만들어진 요약본을 활용하면 됩니다. 배치 작업으로 처리할 수 있어 비용도 절감됩니다.
문서 파싱부터 시작하는 체계적 접근
실무에서 문서 처리는 파싱부터 시작됩니다. PDF, DOCX, PPTX 등 다양한 포맷의 문서가 들어오는데, 이것을 일관된 형태의 텍스트로 변환해야 합니다.
파싱 단계에서 중요한 것은 문서의 구조를 최대한 보존하는 것입니다. 단순히 텍스트만 추출하는 게 아니라, 제목과 본문의 위계, 표와 이미지의 맥락, 페이지 번호와 섹션 정보까지 함께 추출해야 합니다. 이런 메타데이터는 나중에 요약 품질을 높이는 데 큰 역할을 합니다.
10페이지 문서는 비교적 간단합니다. 전체 내용을 한 번에 LLM에 전달해서 요약을 받을 수 있습니다. 100페이지 문서는 챕터별로 나눠서 요약한 뒤, 다시 이 요약들을 종합하는 계층적 접근이 필요합니다. 1000페이지 문서는 더 세밀한 전략이 요구됩니다. 대분류 섹션별로 중간 요약을 만들고, 이를 다시 통합하는 다단계 요약 프로세스를 거쳐야 합니다.
이중 요약 전략의 위력
여기서 핵심 전략이 등장합니다. 바로 summary_brief와 summary_detail을 동시에 생성하는 것입니다.
summary_brief는 말 그대로 간략 요약입니다. 문서의 주제와 핵심 내용을 2~3문장으로 압축합니다. “이 문서는 2024년 3분기 매출 보고서로, 전년 대비 15퍼센트 성장한 실적과 주요 성장 동인을 다룹니다”와 같은 식입니다. 이 정도면 쿼리 라우팅 단계에서 빠르게 문서의 관련성을 판단하기에 충분합니다.
summary_detail은 좀 더 상세한 요약입니다. 주요 섹션별 내용, 다루는 주제의 범위, 포함된 데이터의 종류 등을 한 페이지 분량으로 정리합니다. 문서 범위를 좁힌 뒤, 실제 청크를 검색하기 전에 한 번 더 필터링하는 용도로 사용됩니다.
이 이중 구조가 왜 중요할까요? 검색의 정밀도를 단계적으로 높일 수 있기 때문입니다. 처음엔 brief로 빠르게 후보군을 추리고, 그다음 detail로 정확도를 높이고, 마지막으로 실제 청크 내용으로 최종 답변을 생성하는 3단계 필터링이 가능해집니다.
청크 레벨 요약의 숨은 가치
문서 전체 요약만큼이나 중요한 것이 청크별 요약입니다. 많은 시스템이 이 부분을 간과하는데, 실무에서는 엄청난 차이를 만듭니다.
일반적인 RAG 시스템은 문서를 512토큰이나 1024토큰 단위로 쪼갠 뒤, 그 청크를 그대로 임베딩합니다. 문제는 청크가 문맥에서 떨어져 나온 단편적인 텍스트라는 점입니다. “분기 매출이 전년 대비 15퍼센트 증가했다”는 문장이 있다면, 이것만 봐서는 어느 분기인지, 어떤 제품군인지 알 수 없습니다.
청크에 summary_brief를 추가하면 상황이 달라집니다. 청크 내용 자체는 짧고 구체적이지만, 요약 정보는 이 청크가 문서 전체에서 어떤 맥락에 있는지 알려줍니다. “2024년 3분기 모바일 사업부 매출 분석 섹션 중 일부”라는 메타 정보가 함께 임베딩되는 것입니다.
이렇게 하면 벡터 검색의 품질이 크게 향상됩니다. 유사한 숫자나 표현이 여러 문서에 나와도, 청크 요약 덕분에 맥락에 맞는 검색 결과를 얻을 수 있습니다. 마치 책의 각 페이지마다 “이 페이지는 3장의 일부입니다”라는 안내문이 붙어 있는 것과 같습니다.
카테고리 기반 라우팅의 설계
쿼리 라우팅의 첫 번째 관문은 카테고리 테이블입니다. 여기서 부모 카테고리와 자식 카테고리의 계층 구조를 활용합니다.
예를 들어 회사에 재무, 영업, 기술, 인사라는 부모 카테고리가 있다고 해봅시다. 재무 아래에는 회계보고서, 예산계획서, 감사자료 같은 자식 카테고리가 있습니다. 기술 아래에는 API문서, 시스템아키텍처, 장애대응매뉴얼 등이 있습니다.
사용자가 “지난 분기 매출 증가율이 궁금해요”라고 물으면, Agentic RAG 시스템은 먼저 이 질문을 분석합니다. “매출”이라는 키워드에서 재무 카테고리를, “분기”와 “증가율”에서 회계보고서 서브 카테고리를 추론합니다.
이 과정은 단순한 키워드 매칭이 아닙니다. LLM을 활용해 질문의 의도를 파악하고, 카테고리 테이블에 저장된 각 카테고리의 설명과 매칭시킵니다. 카테고리 정보도 임베딩해두면 의미론적 유사도로 가장 관련성 높은 카테고리를 찾을 수 있습니다.
문서 범위를 좁히는 docs_info 테이블 활용
카테고리 필터링이 끝나면 다음 단계는 docs_info 테이블에서 구체적인 문서를 찾는 것입니다. 이 테이블에는 각 문서의 doc_id와 함께 제목, 작성일, 카테고리, 그리고 우리가 만들어둔 summary_brief와 summary_detail이 저장되어 있습니다.
재무 카테고리에 속한 문서가 100개라면, 일단 검색 범위가 전체 문서의 10분의 1로 줄어든 셈입니다. 여기서 다시 summary_brief를 활용합니다. “지난 분기 매출 증가율”이라는 질문과 각 문서의 간략 요약을 비교해서, 관련성 점수를 매깁니다.
이 과정도 벡터 유사도 검색을 활용할 수 있습니다. 사용자 질문을 임베딩하고, 후보 문서들의 summary_brief 임베딩과 코사인 유사도를 계산합니다. 점수가 높은 상위 3~5개 문서를 선택합니다.
만약 특정 시점의 정보를 묻는 질문이라면, 메타데이터의 작성일 필터를 추가로 적용할 수 있습니다. “2024년 3분기”라는 시간 정보가 질문에 포함되어 있다면, 해당 기간에 작성된 문서들만 대상으로 좁힙니다.
이렇게 카테고리 필터링과 문서 레벨 필터링을 거치면, 원래 수천 개였던 후보가 몇 개의 핵심 문서로 압축됩니다. 이제 진짜 검색을 시작할 준비가 된 것입니다.
하이브리드 검색 전략의 실제 적용
문서 범위가 좁혀졌다면 이제 하이브리드 검색 전략을 펼칠 차례입니다. 하이브리드 검색은 벡터 검색과 키워드 검색을 결합한 방식입니다.
벡터 검색은 의미론적 유사성을 잡아냅니다. “매출 증가”와 “수익 성장”이 같은 의미라는 것을 이해합니다. 하지만 특정 숫자나 고유명사를 찾는 데는 약합니다. “2024년 3분기”라는 정확한 표현이 있는 문장을 찾을 때는 키워드 검색이 더 강력합니다.
실무에서는 두 방식의 장점을 모두 가져갑니다. 선택된 문서들의 청크에 대해 벡터 검색으로 의미적으로 관련된 청크를 찾고, 동시에 BM25 같은 키워드 검색으로 정확한 용어가 포함된 청크를 찾습니다. 그리고 두 결과를 적절한 가중치로 결합합니다.
여기서 청크별 summary_brief가 다시 빛을 발합니다. 벡터 검색할 때 청크 원본만 쓰는 게 아니라, 청크 요약도 함께 고려하면 검색 정확도가 올라갑니다. 짧은 청크는 맥락 정보가 부족해서 벡터 검색 성능이 떨어질 수 있는데, 요약 정보가 이를 보완해줍니다.
실전 구현의 세부 고려사항
이론은 깔끔하지만 실제 구현은 까다롭습니다. 몇 가지 실전 팁을 공유하겠습니다.
먼저 요약 프롬프트 설계가 중요합니다. “이 문서를 요약해줘”라고만 하면 매번 다른 스타일의 요약이 나옵니다. 일관된 포맷을 유지하도록 구조화된 프롬프트를 만들어야 합니다. “문서의 주제, 다루는 주요 내용 3가지, 포함된 데이터 유형”처럼 항목을 명시하는 것이 좋습니다.
배치 처리 전략도 고민해야 합니다. 1000페이지 문서를 한 번에 요약하려면 API 비용이 만만치 않습니다. 섹션별로 나눠서 요약하고, 밤 시간대에 배치로 돌리면 비용을 절감할 수 있습니다. 긴급하지 않은 문서는 큐에 넣어두고 한가한 시간에 처리하는 전략도 유효합니다.
캐싱 전략도 빼놓을 수 없습니다. 같은 문서에 대한 요약을 중복 생성하지 않도록 해시값으로 체크합니다. 문서가 업데이트되면 새로 요약을 생성하되, 변경되지 않은 섹션은 기존 요약을 재사용할 수 있습니다.
성능 모니터링과 지속적인 개선
시스템을 구축한 후에는 성능을 계속 모니터링해야 합니다. 쿼리 라우팅의 정확도를 측정하는 지표가 필요합니다.
가장 직관적인 지표는 정답률입니다. 사용자 질문에 대해 올바른 카테고리를 찾았는지, 관련 문서를 상위에 랭킹했는지 체크합니다. 실무에서는 사용자 피드백을 수집해서 정답 데이터셋을 만듭니다. “이 답변이 도움이 되었나요?” 같은 간단한 피드백 버튼만 있어도 충분합니다.
검색 대기 시간도 중요합니다. 아무리 정확해도 답변이 10초씩 걸리면 사용자는 떠나갑니다. 각 단계별 소요 시간을 로깅해서 병목 지점을 찾아내야 합니다. 카테고리 라우팅에 2초, 문서 선택에 3초, 청크 검색에 2초처럼 세분화된 지표를 추적하세요.
요약 품질도 주기적으로 점검합니다. 랜덤으로 문서를 샘플링해서 사람이 직접 요약을 평가합니다. 요약이 너무 추상적이거나 중요한 정보를 누락했다면 프롬프트를 개선합니다. A/B 테스트로 여러 프롬프트 버전을 비교하는 것도 좋은 방법입니다.
확장성을 고려한 아키텍처
기업 환경에서는 문서가 계속 늘어납니다. 처음엔 1000개였던 문서가 1년 후 10000개가 됩니다. 확장성을 염두에 두고 설계해야 합니다.
데이터베이스 인덱싱이 핵심입니다. doc_id, 카테고리, 작성일 같은 필드에 적절한 인덱스를 걸어야 검색 속도를 유지할 수 있습니다. summary_brief를 자주 검색한다면 full-text 인덱스를 추가하는 것도 고려하세요.
벡터 데이터베이스 선택도 중요합니다. Pinecone, Weaviate, Qdrant 같은 전문 솔루션은 수백만 개의 벡터를 빠르게 검색할 수 있습니다. PostgreSQL의 pgvector 확장도 규모가 크지 않다면 충분히 실용적입니다.
분산 처리 구조를 고려하세요. 문서 파싱, 요약 생성, 임베딩 생성을 각각 독립적인 워커로 분리하면 부하를 분산할 수 있습니다. 메시지 큐를 사용해 작업을 조율하면 안정성도 높아집니다.
실패 사례에서 배우는 교훈
모든 시스템이 처음부터 완벽할 수는 없습니다. 실무에서 겪은 실패 사례를 공유하겠습니다.
한 번은 요약을 너무 짧게 만들었던 적이 있습니다. 토큰 비용을 아끼려고 summary_brief를 한 문장으로 제한했더니, 정보가 너무 부족해서 라우팅 정확도가 떨어졌습니다. 적절한 길이를 찾는 것이 중요합니다. 보통 2~3문장이 최적입니다.
카테고리 분류가 너무 세분화되어 문제가 생긴 적도 있습니다. 50개가 넘는 세부 카테고리를 만들었더니, LLM이 올바른 카테고리를 찾지 못했습니다. 카테고리는 10~15개 정도의 큰 범주로 시작해서, 필요에 따라 서브 카테고리를 추가하는 것이 좋습니다.
청크 크기 설정 실수도 있었습니다. 너무 작은 청크는 맥락을 잃고, 너무 큰 청크는 정밀도가 떨어집니다. 여러 실험 끝에 512~768 토큰이 적당하다는 결론을 냈습니다. 단, 문서 특성에 따라 조정이 필요합니다.
미래를 대비하는 시스템
RAG 기술은 빠르게 진화하고 있습니다. 멀티모달 RAG, 그래프 기반 RAG, 리랭킹 모델의 발전 등 새로운 기법들이 계속 나옵니다.
지금 구축하는 시스템이 미래에도 유연하게 적응하려면 모듈화가 중요합니다. 요약 생성 로직, 임베딩 모델, 검색 알고리즘을 독립적인 컴포넌트로 분리하세요. 새로운 모델이 나오면 해당 부분만 교체할 수 있게 만드는 것입니다.
메타데이터 스키마도 확장 가능하게 설계하세요. 나중에 이미지 설명, 표 데이터 요약 같은 새로운 필드를 추가할 여지를 남겨두는 것입니다. JSON 형태로 유연한 구조를 유지하면 도움이 됩니다.
결론
기업 실무에서 Agentic RAG를 성공적으로 구현하려면 사전 요약과 체계적인 쿼리 라우팅이 필수입니다. 문서를 파싱하고, 이중 요약 구조를 만들고, 카테고리 기반으로 범위를 좁힌 뒤, 하이브리드 검색으로 정확한 답변을 제공하는 이 전체 흐름이 유기적으로 작동해야 합니다.
10페이지든 1000페이지든, 각 문서의 특성에 맞는 처리 전략을 수립하세요. summary_brief와 summary_detail이라는 이중 구조로 검색 정확도를 높이고, 청크 레벨 요약으로 맥락을 보존하세요. 카테고리 테이블과 docs_info 테이블을 활용한 단계적 필터링이 핵심입니다.
완벽한 시스템을 처음부터 만들려 하지 마세요. 작게 시작해서 사용자 피드백을 받으며 개선하는 것이 현실적입니다. 성능 지표를 계속 모니터링하고, 실패에서 배우며, 확장 가능한 아키텍처를 유지하세요.
RAG는 단순히 문서 검색 기술이 아닙니다. 기업의 지식을 체계화하고, 정보 접근성을 높이며, 업무 효율성을 극대화하는 핵심 인프라입니다. 사전 요약 기반의 쿼리 라우팅은 이 목표를 달성하는 강력한 방법입니다.