현장에서 RAG 프로젝트가 막히는 지점은 비슷하다. 임베딩 모델을 바꾸고, chunk 크기를 조정하고, reranker를 붙였는데도 답변은 애매하다. 사용자는 “문서에 있는데 왜 못 찾느냐”고 묻고, 개발팀은 “검색 결과에는 없었다”고 답한다. 문제는 검색 성능만이 아니다. 검색을 한 번 실행하고 끝내는 파이프라인으로 설계한 것이 문제다.
RAG는 검색 절차이고 agentic retrieval은 판단 구조다
전통적 RAG는 질문을 벡터화하고, 관련 문서를 가져오고, 그 문서를 prompt에 넣어 답한다. 이 구조는 단순하고 설명하기 쉽다. 그래서 첫 도입에는 잘 맞는다.
하지만 업무 질문은 단순하지 않다. 같은 질문 안에 정책, 예외, 최신 공지, 고객 조건, 승인 권한이 섞인다. 한 번의 검색으로 충분한지, 키워드 검색이 나은지, SQL이 필요한지, 웹 검색이 필요한지 판단해야 한다.
OpenAI의 현재 Web Search 문서는 Responses API에서 검색을 web_search 도구로 붙이고, tool_choice: auto일 때 검색 실행 여부를 모델이 선택하게 둔다고 설명한다. Chat Completions의 검색 모델은 항상 검색하지만, Responses API의 검색은 에이전트가 선택하는 도구다. (platform.openai.com)
agentic retrieval의 핵심은 “더 좋은 검색기”가 아니라 “검색을 언제 어떻게 쓸지 결정하는 제어권”이다.
검색 도구는 최소 세 가지 결정을 가져야 한다
agentic retrieval을 설계할 때 검색 도구는 단순 API wrapper가 아니다. 에이전트가 판단할 수 있는 선택지를 가져야 한다.
| 설계 질문 | 고정 RAG | agentic retrieval |
|---|---|---|
| 언제 찾는가 | 모든 질문마다 검색 | 질문 유형과 confidence에 따라 결정 |
| 어디서 찾는가 | 하나의 vector store | 문서, DB, SaaS, 웹, 로그를 라우팅 |
| 다시 찾는가 | 보통 없음 | 근거 부족, 충돌, 최신성 이슈 때 재검색 |
| 무엇을 남기는가 | 최종 답변 중심 | query, tool call, 근거, 실패 이유까지 기록 |
MCP 2025-06-18 specification은 tool을 모델이 발견하고 호출할 수 있는 대상으로 정의한다. tool에는 이름, 설명, input schema, 선택적 output schema가 포함되며, 민감한 호출에는 사용자 확인과 audit log가 필요하다고 명시한다. (modelcontextprotocol.io)
이 지점이 중요하다. 검색 도구 설명이 부실하면 에이전트는 검색을 남발한다. input schema가 느슨하면 잘못된 질의가 시스템을 오염시킨다. output schema가 없으면 근거와 추론이 뒤섞인다. 검색 품질은 retriever 이전에 tool contract에서 결정된다.
retrieval도 AgentOps의 관찰 대상이다
RAG 운영에서 자주 빠지는 것이 로그다. “정답을 틀렸다”는 피드백만 남기면 원인을 찾지 못한다. 검색을 안 해서 틀렸는지, 잘못된 저장소를 봐서 틀렸는지, 좋은 근거를 찾고도 생성 단계에서 왜곡했는지 분리해야 한다.
OpenAI Agents SDK 문서는 agent를 계획하고, tool을 호출하고, specialist 간 handoff를 수행하며, 상태를 유지하는 애플리케이션으로 정의한다. 또한 tracing은 LLM generation, tool call, handoff, guardrail, custom event를 기록한다고 설명한다. (platform.openai.com)
retrieval 로그는 최소 네 가지를 남겨야 한다.
- 원 질문과 재작성 query
- 선택된 검색 도구와 선택 이유
- 반환 근거의 source, timestamp, score
- 답변에 실제 사용된 근거와 버려진 근거
이 로그가 있어야 운영자가 “검색기를 바꿀 문제”와 “에이전트 판단을 고칠 문제”를 구분한다.
AX Ops는 검색을 운영 단위로 재설계한다
최근 agent harness 흐름도 같은 방향이다. OpenAI는 2026년 4월 Agents SDK 업데이트에서 configurable memory, sandbox-aware orchestration, file system tools, durable execution을 포함한 harness 강화를 발표했다. Anthropic도 2025년 9월 Claude Code SDK를 Claude Agent SDK로 확장하며, Claude Code의 agent loop를 다른 업무 에이전트에도 적용한다고 밝혔다. (openai.com)
AX LABS가 보는 전환점은 명확하다. RAG를 “문서 검색 기능”으로 두면 PoC에서 끝난다. agentic retrieval을 “업무 판단의 일부”로 설계하면 운영으로 간다.
시작은 크지 않아도 된다. 우선 검색 도구를 세 개로 나눈다. 사내 문서 검색, 업무 시스템 조회, 최신 정보 검색. 각 도구에 사용 조건, 입력 schema, 출력 schema, 실패 처리, human approval 기준을 붙인다. 그 다음 trace를 보고 도구 설명과 routing rule을 고친다.
참고
- OpenAI, “The next evolution of the Agents SDK”, 2026: https://openai.com/index/the-next-evolution-of-the-agents-sdk/
- OpenAI Developers, “Web search”, current API docs: https://developers.openai.com/api/docs/guides/tools-web-search
- OpenAI Developers, “Agents SDK”, current API docs: https://developers.openai.com/api/docs/guides/agents
- OpenAI Agents SDK, “Tracing”, current docs: https://openai.github.io/openai-agents-js/guides/tracing/
- Anthropic, “Building agents with the Claude Agent SDK”, 2025: https://claude.com/blog/building-agents-with-the-claude-agent-sdk
- Model Context Protocol, “Tools specification 2025-06-18”: https://modelcontextprotocol.io/specification/2025-06-18/server/tools
검색을 기능이 아니라 운영 단위로 재설계할 때 agentic retrieval은 실제 업무에 붙는다. AX Ops 관점의 에이전트 설계는 AX Ops 방법론 →에서 이어간다.