RAG를 '한 번 찾기'에서 '따져 보며 찾기'로: Foundry IQ

한 번 찾고 끝나는 RAG의 한계

일반적인 RAG는 이렇게 동작합니다. 질문을 임베딩하고, 비슷한 청크를 몇 개 찾고, 그걸 프롬프트에 붙여 답을 만듭니다.

간단한 질문에는 잘 맞습니다. 그런데 "작년 대비 올해 유럽 매출이 줄어든 이유를 내부 보고서와 회의록에서 찾아 줘" 같은 질문에서는 자주 무너집니다. 한 번의 검색으로는 필요한 조각이 다 모이지 않기 때문입니다.

사람이라면 이렇게 하겠죠. 먼저 매출 보고서를 찾고, 거기서 언급된 원인을 보고, 그 원인에 대한 회의록을 다시 찾습니다. 찾고, 읽고, 다시 찾습니다.

Foundry IQ의 정의

Asha Sharma의 발표 글은 Foundry IQ를 이렇게 소개합니다. RAG를 일회성 조회가 아니라 동적인 추론 과정으로 다시 그린 것.

구체적으로는 이런 기능이 들어 있습니다.

• 여러 출처 중 어디를 볼지 고르기
• 한 번에 끝내지 않고 반복해서 검색하기
• 찾은 결과를 되돌아보며 부족한 부분을 판단하기
• 출처마다 미리 인덱스를 만들지 않아도 여러 출처를 묶어 근거 찾기

바탕은 Azure AI Search입니다. RAG 흐름을 위한 단일 근거 API를 제공하고, Foundry Agent Service와 붙습니다. Foundry는 이미 하루 30억 건이 넘는 검색 질의를 처리한다고 합니다.

권한을 지키는 검색

실무에서 더 중요한 문장은 따로 있습니다. 사용자 권한과 데이터 분류를 존중하면서 동작한다는 부분입니다.

RAG를 사내에 붙일 때 가장 골치 아픈 문제가 권한입니다. 인사 문서가 인덱스에 들어가면, 권한 없는 사람도 질문 한 번으로 그 내용을 볼 수 있습니다. 그래서 많은 팀이 공개 문서만 인덱싱하거나, 권한별로 인덱스를 따로 만듭니다.

Azure 블로그는 Foundry IQ가 SharePoint, Fabric IQ, 웹 같은 출처를 묶으면서 사용자 권한을 지킨다고 설명합니다. 이게 실제로 문서 단위까지 정확하게 동작한다면, RAG 구축에서 가장 큰 숙제 하나를 플랫폼이 가져가는 셈입니다.

함께 나온 개발 도구들

Foundry IQ는 혼자가 아니라 에이전트 개발 흐름의 한 조각으로 나왔습니다.

Hosted Agents가 흥미롭습니다. 마이크로소프트 프레임워크든 다른 프레임워크든, 만든 에이전트를 완전 관리형 환경에서 돌려 준다는 설명입니다. LangGraph로 만든 에이전트도 Foundry 위에서 돌릴 수 있다는 뜻으로 읽힙니다.

Control Plane에는 기본 제공 평가, OpenTelemetry 기반 추적, 지속적인 레드팀 테스트가 들어 있습니다. API Management를 통해 어떤 API든 MCP 도구로 노출할 수 있다는 점도 실용적입니다.

반복 검색의 비용

반복해서 찾는다는 건 LLM을 여러 번 부른다는 뜻이기도 합니다. 어디를 볼지 고르고, 결과를 평가하고, 다시 검색어를 만드는 매 단계가 모델 호출입니다.

그러니 지연 시간과 비용이 단순 RAG보다 늘어날 수밖에 없습니다. 발표 글에는 이 비용에 대한 숫자가 없습니다. 쓸 때는 질문의 성격을 나눠서, 간단한 질문은 단순 검색으로, 여러 출처를 엮어야 하는 질문만 Foundry IQ로 보내는 식의 분기가 필요할 것 같습니다.

함께 읽을 개념 정리

• RAG와 하이브리드 검색을 한 장으로: RAG가 풀려던 문제와 키워드·벡터 검색을 섞는 법

영상으로 더 보기

Foundry IQ의 에이전틱 검색을 다룬 마이크로소프트 세션입니다.

그 뒤의 소식

반년 뒤 Build 2026에서 Foundry IQ의 지식 베이스가 정식 출시됐습니다. 그 이야기는 Build 2026 시리즈에서 이어서 다룹니다.

검색을 한 번에서 여러 번으로 바꾸는 흐름은 Foundry만의 이야기가 아닙니다. 구글도, 스노우플레이크도, 데이터브릭스도 같은 방향으로 가고 있습니다. 결국 차이는 어떤 출처를 권한까지 지키며 묶을 수 있느냐에서 날 것 같습니다.