Claude Opus 4.8: 병렬 서브에이전트 동적 워크플로우 (Parallel-Subagent Dynamic Workflows)

무엇인가 (What): OmniRetrieval 논문은 **소스 네이티브 쿼리 디스패치 (source-native query dispatch)**를 소개합니다. 이는 라우터 (router)가 텍스트, 테이블, 또는 그래프 중 적합한 지식 소스로 자연어 쿼리를 보내고, 모든 데이터를 하나의 벡터 저장소 (vector store)에 임베딩 (embedding)하는 대신 각 소스 고유의 쿼리 엔진을 실행하는 방식입니다.

이유 (Why): 많은 벡터 우선 RAG 스택은 모든 소스를 단일 임베딩 후 ANN (embed-then-ANN) 파이프라인으로 평탄화하며, 이 과정에서 테이블과 그래프를 유용하게 만드는 구조적 정보가 손실됩니다. 각 소스를 네이티브 상태로 유지하면 조인 (JOINs) 및 그래프 엣지 (graph edges)가 검색 과정에서 보존되므로, 생성기 (generator)는 단순한 평탄 유사도 검색으로는 구성할 수 없는 답변을 확인할 수 있습니다.

이전 방식과의 차이 (vs prior): 이전의 기본 방식은 **통합 벡터 인덱스 (unified vector index)**로, 모든 것을 청크 (chunk)화하고 임베딩하여 한데 모아 최근접 이웃 (nearest-neighbour) 검색을 수행하는 방식입니다. 이 방식의 실패 모드는 **구조적 붕괴 (structural collapse)**입니다. 즉, 테이블의 컬럼 관계와 그래프의 엣지가 하나의 벡터로 평균화되어 더 이상 구조로서 쿼리할 수 없게 됩니다.

비유하자면

각 질문을 적절한 전문 직원에게 배정하는 안내 데스크와 같습니다.

                쿼리 (THE QUERY)
                    │
             라우터 (router, 직원)
...

쿼리 (query) = 안내 데스크에 전달된 질문
라우터 (router) = 어느 전문가에게 물어볼지 결정하는 직원
소스 네이티브 쿼리 (source-native query) = 각 전문가에게 그들만의 언어(원장, 기록 보관소, 가계도 등)로 질문하는 것
통합 벡터 인덱스 (unified vector index) = 모든 문서를 동일한 인덱스 카드가 담긴 하나의 통에 갈기갈기 찢어 넣는 것
보존된 구조 (preserved structure) = 원장은 컬럼을 유지하고 가계도는 선을 유지하는 것

빠른 용어 정리

RAG — 검색 증강 생성 (Retrieval-Augmented Generation) — 지식 저장소에서 관련 컨텍스트를 가져온 다음, 이를 바탕으로 모델의 답변을 조건화하는 방식입니다.

벡터 인덱스 (Vector index) — 기본 RAG 저장소: 모든 청크 (chunk)는 고정 차원의 벡터로 임베딩되며, 검색 시 코사인 유사도 (cosine similarity) 또는 내적 유사도 (dot-product similarity)를 기준으로 **상위 k개의 최근접 이웃 (top-k nearest)**을 반환합니다. 청크 내부의 구조는 보존되지 않으며, 임베딩 공간에서의 위치만 보존됩니다.

ANN — 근사 최근접 이웃 (Approximate Nearest Neighbour) — 정확도를 속도와 맞바꿈으로써 벡터 검색을 빠르게 만드는 인덱스 제품군 (HNSW, IVF, FAISS).

소스 네이티브 쿼리 (Source-native query) — 소스를 자체 엔진에서 실행하는 것: 공유된 임베딩 공간에서의 단일 유사도 조회 대신, 구절에 대한 전체 텍스트 검색 (full-text search), 테이블에 대한 (JOIN을 포함한) SQL 스타일 쿼리 (SQL-style query), 그래프에 대한 순회 (traversal) 등을 의미합니다.

이종 소스 검색 (Heterogeneous-source retrieval) — 비정형 텍스트, 관계형 테이블, 그래프와 같이 서로 다른 종류의 소스에 걸친 검색 — 하나의 표현 방식으로 균질화(homogenised)하는 대신 각 소스의 고유한 형태를 유지합니다.

지식 베이스 (Knowledge base, KB) — 시스템이 검색을 수행하는 단일 코퍼스 (corpus). OmniRetrieval 보고서는 13개의 데이터셋에 걸친 309개의 별도 KB를 대상으로 평가했음을 밝힙니다.

뉴스. 2026년 5월 29일, OmniRetrieval 논문 (arXiv:2605.29250)은 자연어 쿼리를 수락하고 이를 적절한 지식 소스(비정형 텍스트, 관계형 테이블 또는 그래프)로 **라우팅 (routing)**하는 검색 프레임워크를 제안했습니다. 이 프레임워크는 모든 것을 단일 임베딩 인덱스로 평탄화(flattening)하는 대신, 각 소스의 **네이티브 쿼리 (native query)**를 해당 실행 엔진으로 전달합니다. 저자들은 13개의 데이터셋과 309개의 별도 지식 베이스를 통해 평가를 진행했으며, 단일 소스 검색 베이스라인을 상회하는 성능을 보고했습니다.

안내 데스크를 다시 상상해 보십시오. 한 질문이 들어옵니다 — "3분기에 베를린 창고로 물품을 보낸 공급업체는 어디이며, 누가 그들을 소개했는가?" **직원 (clerk)**은 이 질문을 하나의 무미건조한 공용 언어로 번역하여 건물 전체에 외치지 않습니다. 대신 질문을 분할합니다. **기록 보관 전문가 (archivist)**는 산문 형태의 계약서를 검색하고, **회계사 (accountant)**는 장부의 수치를 계산하며, **계보학자 (genealogist)**는 인물 관계 그래프를 탐색합니다. 각 전문가는 장부의 열(column)이나 가계도의 선과 같이 자신의 영역을 유용하게 만드는 구조를 유지하며, 자신들만의 언어로 답변합니다.

위의 애니메이션은 그 책상입니다. 첫 번째 비트(beat)에서 쿼리는 **쿼리(query) → 라우터(router) → 하나의 평면 벡터 인덱스(one flat vector index)**로 흐릅니다. 모든 소스는 동일하고 균일한 벡터 그리드로 파쇄되며, 테이블의 JOIN 호(arc)와 그래프의 **에지(edges)**는 점선과 회색으로 변합니다. 즉, 구조를 쿼리할 수 없는 임베딩 공간(embedding space)으로 평탄화(flattened)되는 것입니다. 그 다음 라우터가 _평탄화(flatten)_에서 _배치(dispatch)_로 전환됩니다. 동일한 세 가지 소스가 본래의 형태(native forms)로 불이 들어오며, 세 가지 유형의 쿼리인 텍스트 검색(text search), 테이블 쿼리 · JOIN(table query · JOIN), **그래프 순회(graph traversal)**가 펼쳐지고, JOIN 호와 그래프 에지는 녹색으로 복구됩니다.

이 메커니즘은 **라우터와 소스별 엔진(router plus per-source engines)**의 결합입니다. 하나의 균질화된 저장소(homogenised store)에 대해 임베딩 후 ANN(Approximate Nearest Neighbor) 조회를 수행하는 대신, OmniRetrieval은 각 소스 고유의 언어로 쿼리를 생성하여 해당 소스의 엔진에서 실행한 다음, 생성기(generator)를 위해 이 이질적인(heterogeneous) 결과들을 통합합니다. 테이블이 관계형 형태(relational form)를 벗어나지 않았기 때문에 JOIN은 여전히 키(key)를 통해 행(row)을 구성하며, 그래프가 노드-에지 형태(node-edge form)를 벗어나지 않았기 때문에 **순회(traversal)**는 여전히 에지를 따라갑니다. 이것들이 바로 단일 유사도 벡터(similarity vector)가 지워버리는 **구조적 어포던스(structural affordances)**입니다.

왜 평탄화(flattening)가 정답을 놓치는가

베를린 질문을 고정하고 두 가지 경로를 따라가 봅시다. 답변을 위해 supplier_id를 기준으로 5,000행의 공급업체 (suppliers) 테이블과 40,000행의 배송 (shipments) 테이블을 JOIN해야 한다고 가정해 보겠습니다. 관계형 경로 (relational path)는 키 매칭을 정확하게 (exactly) 평가합니다. 즉, 모든 배송 건이 해당 공급업체로 해결되며, 이후 소개 그래프 (introductions graph)가 두 단계의 홉 (hop)을 거쳐 그들을 소개한 사람들에게 도달합니다. 반면, 평탄 인덱스 (flat-index) 경로는 각 행을 예를 들어 768차원 (768-dimension) 벡터로 임베딩하고, 쿼리에 대해 예를 들어 top-k = 20개의 가장 가까운 청크 (chunks)를 반환합니다. 2억 개의 잠재적인 공급업체-배송 쌍 **(5,000 × 40,000 = 200,000,000, 예시적 수치)**이 코사인 유사도 (cosine distance)에 의해 선택된 **20개의 모호한 이웃 (fuzzy neighbours)**으로 붕괴됩니다. 그리고 "그들을 누가 소개했는가"는 에지 (edge)로서 임베딩된 적이 없는 에지입니다. 평탄 인덱스에서 JOIN과 트래버설 (traversal)이 느린 것이 아닙니다; 그것들이 존재하지 않는 것입니다. 이것이 바로 소스 네이티브 디스패치 (source-native dispatch)가 제거하기 위해 설계된 RAG 실패 모드 (RAG failure mode)의 근원입니다.

평탄 벡터 인덱스 (Flat vector index) vs. 소스 네이티브 디스패치 (Source-native dispatch)

속성 (Property)	통합 벡터 인덱스 (Unified vector index)	소스 네이티브 디스패치 (Source-native dispatch)
사전 구축된 인덱스 (Index built upfront)	모든 소스에 대한 1회의 임베딩 패스 + ANN 인덱스	각 소스가 고유의 엔진(전체 텍스트, SQL, 그래프)을 유지
...

이 표는 임베딩이 쓸모없다는 주장을 뒷받침하는 것이 아닙니다. 산문 (prose)에 대한 모호한 주제적 회상 (fuzzy topical recall)은 벡터 인덱스가 정확히 잘하는 일입니다. 문제는 단일 표현 (single representation)이 텍스트, 테이블, 그리고 그래프 모두에 대해 동시에 적절한 표현이 될 수 없다는 점입니다. **소스 네이티브 쿼리 (source-native query)**로 라우팅하면 각 소스가 실제로 보유한 구조를 사용하여 답변할 수 있고, 그 후에야 통합됩니다. 따라서 생성기 (generator)는 근접 이웃들의 주머니가 아닌, 구성된 관계 (composed relations)를 전달받게 됩니다.

더 자세한 내용: AI 에이전트 (AI Agents) → 검색 및 RAG (Retrieval & RAG) → RAG 실패 모드 (RAG Failure Modes)

FAQ

소스 네이티브 쿼리 디스패치(source-native query dispatch)란 무엇인가요?

이는 라우터(router)가 비정형 텍스트, 관계형 테이블(relational table), 또는 그래프(graph) 등 적합한 지식 소스에 자연어 쿼리를 전달하고, 모든 것을 하나의 공유 벡터 저장소(vector store)에 임베딩(embedding)하는 대신 해당 소스 고유의 쿼리 엔진(전체 텍스트 검색, JOIN을 포함한 SQL 스타일 쿼리, 또는 그래프 순회(graph traversal))을 실행하는 검색 설계 방식입니다. OmniRetrieval은 13개의 데이터셋과 309개의 지식 베이스에 걸쳐 이를 수행했으며, 단일 소스 기준점(baseline)을 상회하는 성능을 보고했습니다.

왜 테이블과 그래프를 동일한 벡터 인덱스에 그냥 임베딩하지 않나요?

임베딩은 구조를 붕괴시키기 때문입니다. 테이블의 열(column)과 그래프의 엣지(edge)는 유사성에 의해 위치가 결정되는 단일 벡터가 되어버리며, 이로 인해 JOIN을 통해 키(key)로 행을 구성하거나 순회를 통해 엣지를 따라가는 것이 더 이상 불가능해집니다. 이러한 관계들은 속도가 느려지는 것이 아니라 평균화되어 사라져 버립니다. 각 소스를 네이티브(native)하게 유지하면 관계형 질문이나 멀티홉(multi-hop) 질문에 답할 수 있는 구조적 기능(structural affordances)을 보존할 수 있으며, 이는 단일 공간에 대한 top-k 최근접 이웃(nearest-neighbour) 조회로는 재구성할 수 없습니다.

이것이 벡터 검색(vector retrieval)이 쓸모없어졌다는 뜻인가요?

아니요. 통합 벡터 인덱스는 의미론적 유사성(semantic similarity)이 핵심적인 역할을 하는 균질한 산문(homogeneous prose)에 대한 퍼지(fuzzy)하고 주제 중심적인 회상(topical recall)에는 여전히 적합한 도구입니다. 소스 네이티브 디스패치가 중요한 경우는 답변이 서로 다른 종류의 소스에 걸쳐 있거나, JOIN해야 할 테이블이나 순회해야 할 그래프와 같이 정확한 관계가 필요할 때입니다. 변화의 핵심은 기본 설정(default)에 있습니다. 먼저 소스의 네이티브 엔진으로 라우팅하고, 공유 임베딩 공간을 유일한 소스가 아닌 여러 소스 중 하나로 취급하십시오.

원문은 Learn AI Visually에 게시되었습니다.