에이전틱 리트리벌 (agentic retrieval)
모델 자신이 '언제·어떻게·몇 번' 검색할지 결정하는, workflow 내 도구형 retrieval.
1줄 정의
모델 자신이 ‘언제·어떻게·몇 번’ 검색할지 결정하는, workflow 내부의 도구형 retrieval.
전체 시스템에서 맡는 역할
retrieval (검색) 은 오랫동안 “질문이 오면 한 번 관련 문서를 가져와서 프롬프트에 붙이는” 공정으로 다뤄져 왔다. agentic retrieval 은 이 “한 번으로 끝나는 고정된 공정” 을 workflow 내부에서 몇 번이고 호출할 수 있는 도구의 한 종류 로 재배치하는 층을 가리킨다.
역할 차이를 펴 보면 이렇다.
- 기존형 (static retrieval): 개발자가 “이 질문에는 이걸 검색한다” 를 사전에 고정해 두고, 가져온 결과를 프롬프트에 고정으로 붙인다. 모델은 받은 조각만 쓸 수 있다.
- agentic retrieval: 모델에게 검색 도구를 쥐어 준다. 모델이 상황을 읽고 “지금 검색해야 하나”, “뭘 검색할까”, “결과를 보고 더 파 볼까” 를 스스로 판단한다.
즉 agentic retrieval 은 검색 엔진의 성능을 올리는 이야기가 아니라, 검색을 누가 부를지의 주체를 사람에서 모델로 옮기는 이야기 다. 병목의 위치가 “어떻게 검색하느냐” 에서 “어떻게 검색하게 하느냐” 로 이동한다.
RAG 라는 큰 틀에서 보면, agentic retrieval 은 “static retrieval 의 개선” 이 아니라 “retrieval layer 의 자리 바꿈” 으로 읽는 편이 설계 판단이 덜 흔들린다. 호출의 주어가 사람에서 모델로 바뀌는 것뿐이지만, 이 “주어의 이동” 이 workflow 전체의 설계를 다시 칠하게 만든다.
이 층이 빠지면 어떻게 되는지로 확인해도 된다. agentic retrieval 이 없는 RAG 구성에서는 검색 타이밍, 쿼리 구성, 깊이 파기 판단이 모두 사전에 고정되어 있어서, 예상 밖의 질문에는 응답이 쉽게 깨진다.
흔한 오해
agentic retrieval 은 용어의 새로움과 추상도 때문에 받아들여지는 방식이 엇갈리기 쉽다. 실무에서 자주 생기는 오차 3개.
- 오해 1: agentic retrieval 은 RAG 의 대체재다, 라고 받아들여지기 쉽다.
– 실제로는 RAG 라는 큰 틀 안에서 retrieval 의 호출 방식 을 바꾸는 층에 가깝다. embedding 이나 GraphRAG 를 없애는 게 아니라, 그것들을 도구로 다시 포장해서 모델이 부를 수 있게 한다. 대체라기보다 재배치 로 받아들이는 편이 구현 판단이 안정된다.
- 오해 2: agentic retrieval 로 바꾸면 검색 품질이 자동으로 올라간다고 여겨지기 쉽다.
– 실제로는 검색 자체의 똑똑함이 오르는 게 아니라, “언제 검색할지” 를 판단하는 주체가 모델 쪽으로 옮겨갈 뿐이다. 바탕에 있는 1층 (embedding) 이나 2층 (GraphRAG) 의 검색 품질이 낮으면 agentic 으로 불러도 결과는 개선되지 않는다. 기초층과 세트로 봐야 한다.
- 오해 3: agentic retrieval 과 agentic search 는 다른 것이다, 라고 분리해서 말해지는 경우가 있다.
– 실제로는 화자와 자료에 따라 용어 구분이 흔들리는 영역이고, 엄밀한 경계는 그리기 어렵다. retrieval layer 4층 지도의 맥락에서는 양쪽 모두 “검색을 workflow 내 도구로 바꾸는 층” 으로 다뤄도 큰 지장이 없다.
이 용어가 중요한 이유
이 층을 이해하고 있는지 아닌지가, 새로 나오는 AI 도구나 제품을 평가하는 해상도를 크게 바꾼다.
새 에이전트형 제품이 등장할 때 자주 나오는 질문은 “이거 RAG 인가요, 아니면 RAG 안 쓰는 건가요” 다. agentic retrieval 이라는 층을 모르면, 이 질문에 Yes/No 단답으로밖에 답할 수 없다.
알면 질문이 자연스럽게 이렇게 바뀐다.
- retrieval 을 어느 층에서 갖고 있는가 (embedding 만? GraphRAG 도?)
- retrieval 의 호출 주체는 누구인가 (사전 고정? 모델?)
- 호출은 몇 번 일어날 수 있는가 (1회? 루프?)
이 3개 축만 보이면 도구 선정, 설계 리뷰, 팀 내 합의 형성의 속도가 달라진다. 반대로 agentic retrieval 의 개념이 흐릿한 사람들끼리 설계 회의를 하면 “RAG 쓰느냐 마느냐” 같은 해상도 낮은 논쟁으로 쉽게 돌아간다.
Claude 나 Codex 같은 에이전트형 도구를 업무에 이미 쓰고 있는 독자에게 이 용어는 “내가 매일 만지는 도구 안쪽에서 어떻게 검색이 일어나고 있는가” 를 언어화하는 열쇠가 된다.
이 용어가 나오는 기사
- 당신의 병목은 RAG 가 아니라, retrieval 의 어느 층에 있는가 (※ 발행 후 실제 URL 로 교체)
다음에 읽을 용어 3개
- RAG — agentic retrieval 의 부모가 되는 틀. 여기서 시작.
- GraphRAG — retrieval 의 구조층. agentic retrieval 이 도구로 감싸서 호출하는 대상 중 하나.
- tool use — agentic retrieval 을 떠받치는 기반 메커니즘. 모델이 외부 함수를 부르는 방식 전반.