여덟 편에 걸쳐 2026년 하반기 RAG의 변화를 따라왔다. 검색은 파이프라인에서 에이전트가 되었고, 검색의 목표는 청크의 관련성에서 부족한 증거 집합으로, 라우터는 분류기에서 예산 배분기로, 인덱스는 산출물에서 운영 대상으로, 그래프는 하나에서 넷으로, 멀티모달은 페이지에서 토큰으로, 한국어는 한 점에서 토큰 단위 비교로, 보안은 명령문 검사에서 출처 신뢰도로 옮겨 갔다. 이 총정리는 그 여덟 갈래를 한 장의 참조 아키텍처와 한 장의 의사결정표로 접는다. 시리즈가 인용한 논문 18편을 근거 수준 세 층으로 나눠 무엇을 결정의 근거로 삼을 수 있는지 가르고, Docling·OpenSearch·Qwen3·KURE-v2·LightRAG·RAGFlow 같은 오픈소스를 2026년 9월 기준으로 어디에 쓰고 어디에 종속되면 안 되는지 판단하고, 지금 당장·3개월·6개월의 도입 순서와 하지 말아야 할 것 12가지를 적는다. 마지막으로 공고·보도자료·행정·의정·고객지원 티켓·키오스크 장애라는 우리 문서군에 이 구조를 대입해 본다. 인터랙티브 위젯 5종.
이 시리즈는 한 문장에서 출발했다. 최신 RAG의 핵심은 더 좋은 벡터 임베딩 하나를 고르는 것이 아니다. 사용자 질문과 현재 에이전트 상태를 보고, 필요한 증거를 탐색하고, 문서 내부를 이동하고, 증거가 충분한지 판단하고, 부족하면 다시 검색하며, 비용 한도 안에서 중단하는 시스템으로 바뀌고 있다. 2024~2025년의 RAG가 검색 파이프라인이었다면, 2026년 9월의 RAG는 검색을 수행하는 에이전트와 증거 관리 시스템에 가까워지고 있다.
여덟 편은 그 문장의 각 부분을 하나씩 열었다. 이 글은 그것을 다시 접는다. 시리즈를 다 읽은 사람에게는 색인이고, 읽지 않은 사람에게는 어디부터 읽을지 고르는 지도이며, 다음 분기에 무엇을 할지 정해야 하는 팀에게는 의사결정표다.
1장 — 여덟 줄의 변화, 여덟 개의 결론 (시리즈 지도 위젯)
2장 — 무엇을 근거로 결정할 것인가: 논문 18편의 세 층 (논문 지도 위젯)
3장 — 2026년 9월의 오픈소스 선택 기준 (스택 빌더 위젯)
4장 — 참조 아키텍처: 파싱에서 평가까지 여덟 단계 (아키텍처 위젯)
5장 — 도입 순서와 하지 말아야 할 것 (로드맵 플래너 위젯)
6장 — 우리 문서군에 대입해 보면
마무리 — 검색기를 고르는 일에서 검색하는 시스템을 운영하는 일로
1. 여덟 줄의 변화, 여덟 개의 결론
1편 2장에 실었던 변화 요약표 여덟 줄이 각각 한 편이 되었다. 표를 다시 싣되 이번에는 오른쪽 열에 각 편이 도달한 결론을 붙인다.
편
2026년 7월까지
2026년 9월
각 편의 결론
1 검색 실행
질의 변환 후 top-k 검색
에이전트가 검색·열기·이동·읽기·재검색
도구는 세트로 준다. 검색 도구 하나만 주면 토큰이 4~10배 폭발한다. Agentic Search는 기본 RAG의 대체가 아니라 실패한 질의를 받는 상위 경로다.
2 검색 목표
개별 청크의 관련성
현재 상태에 부족한 최소 충분 증거 집합
Recall@k 옆에 증거 완전성을 잰다. 검색 결과 한 줄에 네 필드를 더한다. 출처 책임이 큰 업무는 출처 찾기와 답변 생성을 분리한다.
3 질의 처리
고정 검색기·고정 LLM
질문별 검색기·생성기·예산 동적 선택
라우터는 분류기가 아니라 예산 배분기. 추론은 나쁜 검색을 보상하지 못하니 모델보다 검색기를 먼저 고른다. 추론형 부품은 맨 위 한 단.
4 인덱스
사람이 설계한 정적 인덱스
검색 실패를 진단해 인덱스를 수정
인덱스는 산출물이 아니라 운영 대상. 파서 → 문서 객체 보존 → 실패 문서만 수정 → 회귀 게이트. 검증 없는 자가 수정은 인덱스를 망가뜨린다.
5 GraphRAG
LLM으로 엔티티·관계 전부 추출
문서 그래프·동적 SQL 조인·위키 구조로 다변화
“GraphRAG를 도입하자”에 되묻는다 — 어느 그래프를? 노드가 무엇이고, 엣지는 누가 만들고, 새 문서 100건이 들어오면 무슨 일이 생기나. 답이 없으면 메타데이터 엣지부터.
6 멀티모달
관련 페이지 이미지 검색
여러 페이지의 시각 토큰 압축·선택·계층 보존
페이지는 검색의 단위이지 전달의 단위가 아니다. 적게 넣되 구조를 잃지 않는다. 텍스트 인덱스와 시각 인덱스를 같은 열쇠로 묶는다.
7 한국어 검색
Dense 단일 벡터 중심
KURE-v2 한·영 late interaction 등장
평균 1위 뒤에 과제별 승패가 있다. 기본은 하이브리드 단일 벡터, late interaction은 고가치 한국어 질의에만. 경계선은 리더보드가 아니라 우리 질의 200문항이 긋는다.
8 보안
프롬프트 인젝션·일반적 지식 오염
단일 문서·분산 다중 홉·코드 예제 오염
문서 안에 잡을 것이 없는 공격은 문서 밖에서 막는다. 관련성 점수와 출처 신뢰도 점수를 분리하고, 다수결의 단위를 출처로, 새 문서는 검역 인덱스부터.
여덟 결론을 겹쳐 놓으면 한 가지 모양이 반복된다. 새 기술은 새 기본값이 아니라 새 선택지다. Agentic Search도, late interaction도, 추론형 재랭커도, 그래프도, 시각 토큰 선택도 — 전부 기본 경로 위에 얹는 상위 경로이거나 라우터가 고를 수 있는 항목 하나가 늘어난 것이다. 시리즈의 어느 편도 "전부 이걸로 바꾸라"고 말하지 않았다. 그래서 총정리의 중심은 개별 기술이 아니라 그것들을 배치하는 구조와 그 구조를 운영하는 순서다.
세 층 가운데 시리즈가 아직 따로 소개하지 않은 논문이 하나 있다. 2026년 3월 arXiv에 올라온 「SoK: Agentic Retrieval-Augmented Generation (RAG): Taxonomy, Architectures, Evaluation, and Research Directions」(Mishra, Niroula, Yadav, Thakur, Gyawali, Gaire)다. Systematization of Knowledge, 즉 한 분야의 지식을 체계화하는 논문으로, 이 시리즈가 개별 논문에서 귀납한 것을 연역적으로 정리해 둔 셈이다.
이 논문은 에이전트형 RAG의 검색-생성 루프를 유한 시야의 부분 관측 마르코프 결정 과정(POMDP) 으로 형식화하고, 시스템을 네 축으로 분류한다.
SoK의 네 분류 축
계획 메커니즘 — 질문을 어떻게 하위 과제로 나누고 순서를 정하는가 (3편의 라우터, 2편의 보완 집합)
검색 오케스트레이션 — 언제·무엇을·어떤 도구로 검색하는가 (1편의 다섯 도구, 6편의 토큰 선택)
메모리 패러다임 — 이미 본 것과 상태를 어떻게 유지하는가 (2편의 already_seen, RAFT의 상태 사슬)
도구 호출 행동 — 도구를 어떤 정책으로 부르고 멈추는가 (1편 9장의 예산·중단 규칙)
SoK가 짚은 네 가지 체계적 리스크
누적되는 환각 전파 — 한 스텝의 환각이 다음 검색어가 된다
메모리 오염 — 상태에 들어온 잘못된 사실이 이후 모든 결정을 물들인다 (8편)
검색 불일치 — 계획과 실제 검색 결과가 어긋난 채 진행된다 (2편의 충분성 판정이 막는 것)
연쇄적 도구 실행 취약점 — 도구 결과가 다음 도구 호출을 조종한다 (1편 11.2절, 8편 8장)
SoK의 결론 하나가 이 시리즈의 2편·3편과 정확히 포개진다. 초록의 표현으로, 이런 아키텍처를 평가하려면 "정적인 최종 지표에서 중간 논리와 도구 사용의 정확성을 감사할 수 있는 다차원 궤적 평가로의 패러다임 전환"이 필요하다. 2편이 말한 증거 완전성, 3편이 말한 router regret, 1편이 말한 질의당 스텝·토큰·지연 기록은 전부 궤적 평가의 부분집합이다. 다만 SoK는 분류와 방향 제시가 목적이라 정량 벤치마크를 제공하지 않는다. 사고틀로 쓰되 수치의 출처는 각 편의 논문이다.
고가치 한국어 질의용 late-interaction 후보. 우리 데이터로 같은 조건 비교 후
2026-08-29, 154M, 토큰당 128차원 MaxSim, 8,192토큰, MTEB 한국어 검색 9과제 평균 nDCG@10 0.8160(Qwen3-8B 0.7826) — 단 4과제는 Qwen3-8B 승. 다중 벡터 인덱스는 PLAID/BinaryIVF 권고. 라이선스 표기가 저장소(MIT)와 모델 카드(Apache-2.0)에서 다름
전부 사전 공개 단계. 코드 공개 여부가 다르다(A-RAG·RAFT·G³RAG 공개, CoFree 미공개, MSS-Complement 코드는 공개·인증서 비공개)
표의 두 판단에 근거를 붙인다.
RAGFlow를 실험·관리 UI로 쓰되 플랫폼을 종속시키지 않는 이유. RAGFlow는 완성형이다. 템플릿 청킹, 청크 시각화, 인용, 다중 검색과 융합 재랭킹, 에이전트 워크플로가 한 번에 온다. 2주 안에 고객사에 무언가를 보여야 하면 이보다 빠른 길이 없다. 그러나 이 시리즈가 설계한 구조 — 문서 객체 필드를 우리가 정하고(4편), 라우터가 8경로 8결정을 내리고(3편), 인덱스를 실패 피드백으로 고치고(4편), 검역 인덱스와 출처 신뢰도를 두는(8편) — 는 플랫폼 바깥에서 제어해야 하는 것들이다. 장기 멀티테넌트 플랫폼의 파싱·인덱스·라우팅·보안이 특정 도구의 내부 구조에 묶이면, 그 도구가 지원하지 않는 순간 여덟 단계 중 하나가 막힌다. 그래서 RAGFlow는 실험과 관리 UI, 또는 별도 워크스페이스다.
OpenSearch를 AWS 중심 운영의 주 검색 계층으로 보는 이유. 3편의 결론은 "모든 질의가 BM25 + Dense 하이브리드를 지나고, 대부분 거기서 끝나야 한다"였다. 그 하이브리드 계층이 갖춰야 할 것은 어휘 검색, 벡터 검색, 메타데이터 필터(ACL·버전·날짜), 융합, 재랭킹 훅이다. OpenSearch는 이것을 한 엔진에서 처리하고, 공식 문서가 하이브리드·리랭킹·RAG·대화형 검색·에이전트·LLM-as-a-Judge 평가 흐름을 함께 제공한다. 8편의 "ACL을 검색 전에 적용"과 2편의 "평가를 검색 계층 옆에" 요구가 같은 자리에서 충족된다. AWS 밖에서 운영한다면 자체 호스팅 OpenSearch 또는 PostgreSQL(pgvector + 전문 검색 + 5편의 관계 조인)이 대안이다.
⑦이 ⑥ 뒤에 그려져 있지만 실제로는 ①(수집 시점)과 ④(검색 시점)에도 걸쳐 있다. 8편의 방어 구조가 수집·검색·생성·운영 평가 네 시점으로 나뉘어 있던 이유다. 그리고 ⑧은 마지막 단계가 아니라 나머지 일곱을 감싸는 층이다. 평가가 없으면 ③의 승격 비율도, ⑤의 평균 스텝도, ⑦의 레드팀 통과율도 없고, 그러면 어느 단계의 판단도 근거가 없다.
위젯의 "이 단계가 빠지면" 칸을 순서대로 읽으면 이 아키텍처의 요점이 드러난다. 각 단계는 앞 단계의 실패를 가정하지 않는다. 라우터는 인덱스가 올바른 표현을 담고 있다고 가정하고, 충분성 판정은 검색 경로가 위치를 돌려준다고 가정하고, 보안 게이트는 문서 객체에 source_hash와 acl이 있다고 가정한다. 그래서 순서가 있다. ①②가 없는 ③④는 잘못된 표현 위에서 라우팅하는 것이고, ⑤가 없는 ④는 비용 상한이 없는 시스템이며, ⑧이 없는 전부는 측정되지 않는 시스템이다.
이 구조에서 "검색 파이프라인"이라 부를 수 있는 것은 ④의 첫 상자 하나뿐이다. 나머지 일곱 단계와 ④의 다섯 상자는 전부 시리즈가 새로 더한 것이다. 1편의 한 문장 — 검색 파이프라인을 만드는 일이 검색하는 에이전트와 증거 관리 시스템을 만드는 일이 되었다 — 이 그림으로는 이렇게 생겼다.
여덟 단계를 한꺼번에 세울 수는 없다. 기존 파이프라인 RAG가 돌고 있는 팀 하나를 가정하고 순서를 정한다. 기간은 눈대중이고 핵심은 순서다.
지금 당장기반. 파서가 표·절 제목·좌표를 보존하는지 확인하고 원문·페이지 이미지·JSON·청크를 전부 남긴다(4편). BM25 + Dense 하이브리드에 RRF를 켠다(3편). 우리 질의 100~300건에 ‘정답 문서’가 아니라 결정별 요건 목록을 단다(2편). 질의마다 검색기·후보 수·스텝·토큰·지연을 기록한다(1편). 이 넷이 없으면 아래의 어느 것도 측정되지 않는다.
3개월승격 구조. 실패 질의를 5분류로 태깅한다(4편). 라우터를 기본 경로 → 승격으로 배선하고 승격 비율을 본다(3편). 에이전트 경로에 검색·열기·이동·읽기·grep을 세트로 주고 충분성 판정과 스텝 예산을 도구보다 먼저 넣는다(1편). 새 문서는 검역 인덱스를 거치고 출처 신뢰도를 관련성과 분리한다(8편).
6개월운영 자동화. 검색 결과에 네 필드를 붙인다(2편). 실패 문서만 검색 표현을 재생성하고 회귀 게이트를 통과한 것만 교체한다(4편). 스캔·표 문서에 이중 인덱스를 세운다(6편). router regret을 잰다(3편). 오염 6시나리오를 정기 레드팀한다(8편). 한국어 고가치 질의에 late interaction 경로를 시험한다(7편).
연구 실험군분리된 환경. A-RAG·LLM-Wiki·G³RAG·SELF-INDEX·MSS-Complement를 우리 데이터로 재본다. 확인된 것만 라우터의 선택지로 옮긴다. 운영 인덱스에 직접 붙이지 않는다.
4편의 실패 5분류 중 ‘최신 버전 미선택’ — 개정 이력이 많은 문서군이라 version_id와 기준일 표시가 핵심
의정 기록
하이브리드 → 인물 × 발언 × 회의 × 조례는 SQL 조인 → 출처 책임이 큰 질의는 출처 발견 → 사람 검토 → 승인된 출처로만 생성(TRACE 구조)
발언 단위 문서 객체, 회의록 페이지·발언자 메타데이터
2편의 TRACE 3단계 — 답을 생성하는 RAG보다 출처를 찾는 RAG가 안전한 대표 사례. 7편의 late interaction은 긴 회의록의 정확 매칭에 시험할 가치
고객지원 티켓
Stateful Case Route(RAFT) — 현재 티켓의 상태와 맞는 과거 엔트리를 찾고 그 이후의 해결 경로를 돌려준다
케이스를 증상 → 환경 확인 → 시도한 조치 → 새 관찰 → 해결 → outcome(원인·최종 조치·재발 방지)의 상태 사슬로 색인
티켓 전문을 벡터화하지 않는다. 엔트리 단위 임베딩 + 부모 케이스 승격. 무관한 대화 한 턴에 무너지지 않는 구조
키오스크·장비 장애
Stateful Case Route + 오류 코드는 BM25 → 매뉴얼 도면·표는 멀티모달
상태 케이스 인덱스 + 매뉴얼의 텍스트·시각 이중 인덱스(Chapter → Section → 그림·캡션·경고 박스 계층 보존)
6편의 HAM-RAG 교훈 — 그림과 경고 박스를 같은 페이지라는 이유로 묶지 않는다. 장비 × 증상 × 조치 × 결과 조인(5편)
이 표에서 눈에 띄는 것은 여섯 문서군 중 어느 것도 경로를 하나만 타지 않는다는 점이다. 공고 하나가 하이브리드로 시작해 Agentic Navigation을 거쳐 증거 집합 관리로 끝난다. 그것이 3편이 라우터를 분류기가 아니라 예산 배분기라고 부른 이유이고, 1편이 다섯 경로를 배타적 선택지가 아니라 조합 가능한 부품이라고 부른 이유다.
그리고 여섯 문서군 전부에 공통으로 들어가는 것이 있다. 문서 객체의 version_id·effective_date·source_hash·acl(4편), 검색 결과의 already_seen(2편), 출처 신뢰도 점수(8편), 그리고 질의당 스텝·토큰·지연 기록(1편). 문서군마다 경로는 다르지만 기반은 같다. 5장의 "지금 당장" 항목이 그것이다.
마무리 — 검색기를 고르는 일에서 검색하는 시스템을 운영하는 일로
시리즈는 1953년 국방비 열두 개의 숫자로 시작해, 자격 다섯 장으로 만점을 받는 검색, 모든 질문을 같은 기차에 태우는 라우터, 어느 날 안 되는 검색, 저장소에 적힌 유지보수 모드 한 문장, 37.4장, 154M이 7.6B를 이긴 표, 정정 공지 한 장을 지나 여기 왔다. 아홉 글의 결론을 한 줄로 접으면 이렇다.
🧭
RAG 설계의 질문이 바뀌었다. “어떤 임베딩과 어떤 k를 쓸 것인가”에서 — “어느 질의를 어느 경로로 보내고, 무엇을 충분하다고 판정하고, 몇 스텝에서 멈추고, 인덱스가 틀렸을 때 무엇을 고치고, 찾아온 것을 믿기 전에 무엇을 확인하고, 이 모든 것을 무슨 눈금으로 잴 것인가”로.
그 질문은 검색기를 고르는 일이 아니라 검색하는 시스템을 운영하는 일이다. 인덱스는 배포하고 고치는 대상이 되었고, 라우터는 예산을 배분하며, 에이전트는 예산 안에서 멈추고, 평가는 최종 정확도가 아니라 궤적을 본다. 2026년 9월의 논문 열여덟 편은 그 운영의 각 부분을 한 조각씩 보였다. 채택된 네 편은 결정의 근거로, 사전 공개 열한 편은 우리 데이터로 다시 잴 방향으로, 기반 세 편은 사고틀로.
다음 분기에 이 시리즈를 다시 읽을 때 수치 몇 개는 낡아 있을 것이다. 사전 공개 논문이 채택되거나 반박되고, KURE-v3가 나오고, Mistral의 다섯 도구가 여섯이 될 것이다. 낡지 않기를 바라는 것은 4장의 여덟 단계와 5장의 순서다. 부품은 갈아 끼우되 구조는 남는다 — 그것이 파이프라인이 아니라 시스템을 만든다는 말의 뜻이다.
참고자료
이 글에서 새로 소개한 것
Mishra, S., Niroula, S., Yadav, U., Thakur, D., Gyawali, S. & Gaire, S. SoK: Agentic Retrieval-Augmented Generation (RAG): Taxonomy, Architectures, Evaluation, and Research Directions.arXiv:2603.07379 (2026년 3월 7일)
RAGFlow (Apache 2.0) — README 셀프호스팅 예시 v0.27.2, 최소 4코어·16GB·50GB
수치와 판단에 대하여. 이 글의 수치는 전부 시리즈 각 편이 논문·공식 저장소·문서에서 검증한 것을 옮겼으며 조건과 단서는 해당 편에 있다. 오픈소스 구성 요소의 사실(버전·사양·라이선스·지원 리전·유지보수 상태)은 2026년 9월 열람 기준이다. 논문의 세 층 배정, 오픈소스 판단, 참조 아키텍처, 로드맵, 하지 말아야 할 것 목록, 문서군 대입은 코어닷투데이의 판단이다. 위젯의 추천 규칙은 본문 판단표를 옮긴 것이며 팀의 코퍼스 규모·지연 요구·역량을 반영하지 못한다. 삽화는 코어닷투데이가 생성했다.
