지난 글에서 검색 전에 쿼리를 손보는 네 단계를 개입 강도 순으로 다뤘다. 그 마지막 자리인 멀티홉에서 검색은 한 번의 전처리를 넘어 앞선 결과가 다음 쿼리를 정하는 루프가 됐다. Agentic RAG는 그 루프를 한 칸 더 연다. 멀티홉은 「다시 검색한다」는 것까지만 정해 놓고 매번 같은 벡터 인덱스를 두드리지만, Agentic RAG는 무엇을 두드릴지까지 실행 중에 정하는 구조다. 벡터 검색·웹 검색·SQL 질의·API 호출 중 지금 무엇이 필요한지를 모델이 판단하고, 결과를 본 뒤 다음 행동을 다시 정한다.
이 글은 그 구조를 쓰는 법보다 어디서 새는가에 무게를 둔다. 자율성은 공짜가 아니라서, 호출 수와 컨텍스트 길이와 실패 양상이 전부 고정 파이프라인과 다르게 움직인다. 언제 멈출지를 정하지 않은 Agentic RAG는 대개 답을 못 찾는 것이 아니라 답을 찾고도 계속 도는 쪽으로 망가진다.
그리고 이 구조가 모든 RAG를 대체하는 것도 아니다. 마지막 절에서 다시 보겠지만, 들어오는 질문이 한 갈래로 거의 다 덮이는 서비스에서는 고정 파이프라인이 더 나은 답을 더 싸게 낸다. 에이전트를 얹을지 말지는 취향이 아니라 질문 로그로 정하는 일이다.
고정 파이프라인의 한계
전통적인 RAG는 쿼리가 들어오면 벡터 검색을 하고, 꺼내 온 조각을 프롬프트에 붙여 LLM에 넘긴다. 단계가 미리 정해져 있어 지연과 비용을 계산할 수 있고, 로그를 보면 어디서 틀어졌는지도 금방 나온다. 그런데 이 예측 가능성은 세 가지를 포기한 대가다.
단일 소스
색인에 넣어 둔 문서 말고는 아무것도 못 본다. 「작년 계약 건수를 지역별로 알려 줘」는 문서가 아니라 테이블에 있는 답이고, 「오늘 환율」은 색인을 만든 시점에 존재하지도 않았다. 벡터 검색은 이런 질문에 빈손으로 오지 않는다 — 비슷하게 생긴 문서를 가져온다. 그래서 파이프라인은 실패한 줄 모르고, 모델은 관련 없는 근거 위에서 그럴듯한 답을 만든다.
고정 홉 수
여기서 홉은 검색을 한 번 하는 것을 말한다. 고정 파이프라인은 질문이 쉽든 어렵든 홉이 하나다. 「휴가 일수는 며칠인가」는 한 홉이면 충분하지만, 「우리 정책이 작년 개정안과 어디가 다른가」는 두 문서를 각각 찾아 견줘야 하므로 최소 두 홉이다. 한 홉으로 잘라 두면 뒤쪽 질문은 항상 반쪽 근거로 답하게 된다.
교정 없는 실패
검색 결과가 나쁘다는 사실을 파이프라인 안에서 아무도 확인하지 않는다. 유사도 상위 다섯 조각은 언제나 나오고, 그중 정답이 없어도 다섯 조각은 그대로 프롬프트로 간다. 사람이라면 「이건 아닌데」 하고 검색어를 바꿀 자리에서 고정 파이프라인은 그대로 생성으로 넘어간다.
셋을 나란히 놓으면 공통점이 보인다. 전부 「다음에 무엇을 할지」를 설계 시점에 정해 버린 데서 온다. 데이터 소스도, 홉 수도, 실패했을 때의 다음 수도 코드에 박혀 있어서 실행 중에 바뀌지 않는다. 질문이 균일하면 이건 장점이지만, 질문이 제각각이면 가장 어려운 질문에 맞춰 파이프라인을 짜야 하고 그러면 쉬운 질문까지 같은 값을 치른다.
에이전트 패러다임은 이 셋을 같은 방식으로 푼다. 다음에 무엇을 할지 정하는 결정을 파이프라인에서 빼내 모델에게 넘기는 것이다.
ReAct 루프
생각·행동·관찰
Agentic RAG의 기본 골격은 ReAct 루프다. 이름이 곧 구조다 — 추론(Reason)과 행동(Act)을 번갈아 놓고, 행동의 결과를 다시 추론의 입력으로 넣는다. 한 바퀴는 생각(Thought)·행동(Action)·관찰(Observation) 셋으로 이루어지고, 관찰이 생각으로 돌아가면서 루프가 닫힌다.
여기서 행동은 곧 도구 호출이다. 도구는 모델이 이름과 인자로 부를 수 있게 등록해 둔 함수이고, 모델은 그 함수를 직접 실행하지 않는다 — 어느 도구를 어떤 인자로 부를지만 내놓고, 실행은 바깥의 실행기가 한다. 실행 결과가 관찰로 되돌아오면 모델은 그것을 읽고 다음 생각을 만든다. 이 분리가 중요한 이유는, 모델이 정하는 것은 의도뿐이고 권한은 언제나 바깥에 남는다는 점 때문이다.
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent
@tool
def vector_search(query: str) -> str:
"""사내 문서와 지식 베이스 검색. 정책, 매뉴얼, 내부 보고서 조회에 사용."""
return format_docs(vectorstore.similarity_search(query, k=5))
@tool
def web_search(query: str) -> str:
"""실시간 인터넷 검색. 최신 뉴스, 현재 가격, 외부 정보 조회에 사용."""
return web_search_fn(query)
@tool
def sql_query(question: str) -> str:
"""사내 데이터베이스 질의. 건수·합계처럼 정형 데이터 집계에 사용."""
return execute_sql(question)
llm = ChatAnthropic(model="claude-sonnet-4-6", temperature=0)
agent = create_react_agent(llm, tools=[vector_search, web_search, sql_query])
result = agent.invoke({
"messages": [("user", "우리 회사의 AI 정책과 최근 EU AI 법을 비교해줘")]
})LangChain 1.0에서 예전의 AgentExecutor 경로는 langchain-classic 패키지로 옮겨졌다. 새로 짜는 코드는 위처럼 LangGraph의 create_react_agent를 쓰는 편이 이후 제어를 붙이기 쉽다 — 아래에서 보듯 정지 조건과 판정 단계를 그래프의 노드로 끼워 넣어야 하기 때문이다.
도구 설명이 곧 라우팅 규칙
위 코드에서 실제로 라우팅을 정하는 것은 함수 본문이 아니라 독스트링이다. 모델은 도구의 구현을 보지 못하고 이름과 설명만 보므로, 설명이 겹치면 라우팅이 흔들린다. 「문서 검색」과 「지식 검색」처럼 사람이 봐도 구별이 안 되는 두 도구를 나란히 두면 모델은 매번 다른 것을 고른다.
설명은 무엇을 하는지가 아니라 언제 쓰는지로 적는 편이 낫다. 「사내 문서를 검색한다」보다 「정책·매뉴얼·내부 보고서를 물을 때 쓴다」가, 「웹을 검색한다」보다 「색인 시점 이후의 정보나 외부 공개 자료를 물을 때 쓴다」가 오분류를 줄인다. 도구가 다섯을 넘어가기 시작하면 설명에 쓰지 말아야 할 경우도 한 줄 넣는다 — 「사내 데이터에는 쓰지 않는다」 한 줄이 웹 검색 오출을 눈에 띄게 줄인다.
상태 그래프
루프가 조금만 복잡해지면 프롬프트 안의 자유 루프로는 제어가 안 된다. 어디까지 돌았는지, 무엇을 이미 검색했는지, 지금 홉이 몇 번째인지가 전부 대화 기록 안에 녹아 있어서 조건을 걸 자리가 없기 때문이다. LangGraph는 그 값들을 상태로 꺼내 노드와 간선으로 그린다.
from langgraph.graph import StateGraph, MessagesState, END
from langgraph.prebuilt import ToolNode
tool_node = ToolNode(tools=[vector_search, web_search, sql_query])
def agent_node(state: MessagesState):
response = llm_with_tools.invoke(state["messages"])
return {"messages": [response]}
def should_continue(state: MessagesState) -> str:
last_msg = state["messages"][-1]
if last_msg.tool_calls:
return "tools"
return END
workflow = StateGraph(MessagesState)
workflow.add_node("agent", agent_node)
workflow.add_node("tools", tool_node)
workflow.set_entry_point("agent")
workflow.add_conditional_edges("agent", should_continue, {"tools": "tools", END: END})
workflow.add_edge("tools", "agent")
app = workflow.compile()should_continue가 이 구조의 핵심이다. 계속할지 멈출지를 프롬프트의 판단에만 맡기지 않고 코드로 꺼내 놓았으므로, 아래에서 다룰 홉 상한과 점수 문턱을 전부 이 함수 하나에 얹을 수 있다.
Self-RAG와 CRAG
루프를 열어 두면 곧바로 다음 문제가 온다 — 무엇을 보고 「이 검색 결과는 못 쓰겠다」고 판정할 것인가. 여기에 서로 다른 두 답이 있다.
반성 토큰
Self-RAG는 판정을 모델 안으로 넣는다. 생성 중에 「지금 검색이 필요한가」, 「이 조각이 질문과 관련 있는가」, 「내가 쓴 이 문장이 조각으로 지지되는가」를 모델이 특수 토큰으로 내놓도록 학습시키는 방식이고, 그 토큰을 반성 토큰이라 부른다. 판정이 생성과 같은 모델 안에서 일어나므로 호출이 늘지 않는다는 것이 이 방식의 이점이다.
대신 제약이 분명하다. 반성 토큰을 내놓게 하려면 그 토큰이 붙은 학습 데이터로 모델을 따로 학습시켜야 한다. 바꿔 말해 원하는 API 모델을 그냥 가져다 쓰는 길이 막힌다. 사내에서 모델을 직접 학습·서빙하는 팀이 아니라면 Self-RAG는 읽어 둘 구조이지 그대로 옮길 구조가 아니다.
세 판정
CRAG는 판정을 바깥에 둔다. 검색 결과를 정확·애매·틀림 셋 중 하나로 매기는 가벼운 판정기를 따로 두고, 그 결과로 다음 행동을 가른다. 정확이면 그대로 생성으로 가고, 틀림이면 색인을 버리고 웹 검색으로 갈아탄다. 애매면 둘을 섞는다 — 꺼내 온 조각에서 쓸 만한 문장만 남기고 웹 결과를 보탠다.
def grade_documents(state):
question, docs = state["question"], state["documents"]
kept, unsure = [], 0
for doc in docs:
grade = grader.invoke(
f"질문: {question}\n문서: {doc.page_content}\n"
f"correct / ambiguous / incorrect 중 하나로만 답하라:"
).content.strip().lower()
if grade == "correct":
kept.append(doc)
elif grade == "ambiguous":
kept.append(doc)
unsure += 1
return {
"documents": kept,
"web_search_needed": len(kept) == 0 or unsure >= len(docs) / 2,
}셋으로 가른 것이 둘보다 나은 이유는 애매한 경우가 실제로 가장 흔하기 때문이다. 관련 있다와 없다만으로 가르면 판정기는 애매한 조각을 관련 있다 쪽으로 밀어 넣게 되고, 그러면 교정이 걸려야 할 자리에서 안 걸린다.
판정기 고르기
판정기는 문서 하나마다 한 번씩 돈다. 상위 열 조각을 매기면 한 질문에 판정 호출만 열 번이라, 생성 모델과 같은 모델을 쓰면 비용이 곧바로 뒤집힌다. 판정은 짧은 분류 작업이므로 작은 모델로 내리고, 출력은 한 낱말로 못 박고, 열 조각을 한 번의 호출에 묶어 배치로 매기는 것이 기본이다.
판정기가 얼마나 맞는지는 반드시 따로 재야 한다. 손으로 라벨을 붙인 조각 백 개쯤을 놓고 판정기의 답과 대조해 보면, 대개 틀림을 정확으로 넘기는 쪽에서 실수가 몰린다. 그 방향의 실수가 교정을 통째로 무력화하므로, 문턱을 조정할 때는 정확으로 판정하는 기준을 조금 빡빡하게 잡는 쪽이 안전하다.
질문 라우팅
네 갈래
라우팅은 질문이 들어온 자리에서 한 번 갈래를 정하는 일이다. 실무에서 갈리는 유형은 대개 넷이다. 단일 조회는 한 문서 안에 답이 있는 질문이고, 비교는 둘 이상의 문서를 각각 찾아 견줘야 하는 질문이다. 집계는 문서가 아니라 테이블에 답이 있는 질문이고, 최신 정보는 색인 밖에 답이 있는 질문이다.
| 갈래 | 신호 | 보낼 곳 | 홉 |
|---|---|---|---|
| 단일 조회 | 한 대상, 사실 확인 | 벡터 검색 | 1 |
| 비교 | 두 대상, 「차이」·「대비」 | 대상마다 검색 후 합치기 | 2 이상 |
| 집계 | 수량·기간·순위 | SQL 질의 | 1 |
| 최신 정보 | 시점 표현, 색인 이후 사건 | 웹 검색 | 1~2 |
이 표가 곧 라우터 프롬프트의 뼈대가 된다. 갈래를 늘리고 싶은 유혹이 늘 있지만, 갈래가 일곱을 넘어가면 분류 정확도가 눈에 띄게 떨어지고 갈래마다 따로 손볼 경로가 생겨 유지 비용이 붙는다.
오분류 회복
분류기는 틀린다. 중요한 것은 틀렸을 때 무엇이 벌어지는가다. 집계 질문을 단일 조회로 보내면 벡터 검색이 비슷한 문서를 가져오고, 모델은 그 문서에서 숫자를 지어낸다 — 조용히 틀린 답이 나가는 최악의 경로다.
그래서 라우팅은 갈래를 정하는 데서 끝나지 않고 되돌아올 길을 함께 만들어 둔다. 갈래마다 「이 경로가 실패했다」는 신호를 정의하고, 신호가 뜨면 다음 갈래로 넘긴다. 집계 경로에서는 SQL이 빈 결과를 돌려주는 것, 조회 경로에서는 판정기가 전부 틀림으로 매기는 것이 그 신호다. 회복 경로는 한 번만 허용한다 — 두 번 이상 갈래를 옮기면 그건 라우팅이 아니라 순회다.
회복 신호를 정의할 때 자주 놓치는 것이 「결과가 있긴 한데 쓸모없는」 경우다. SQL이 0행을 돌려주는 것은 신호로 잡기 쉬운데, 엉뚱한 테이블에서 숫자 하나를 돌려주는 것은 겉보기에 성공이라 안 걸린다. 그래서 집계 경로에는 질의가 실제로 물음의 대상을 담고 있는지 한 줄로 확인하는 단계를 붙인다. 생성한 SQL의 테이블·칼럼 이름이 질문의 낱말과 하나도 겹치지 않으면 그것부터 의심한다.
정지 조건
자율 루프에서 가장 자주 빠뜨리는 것이 멈추는 조건이다. 무한 루프를 막는 안전장치라고만 생각하기 쉬운데, 실제로는 답의 품질과 비용을 함께 정하는 설계값이다. 아래 넷을 전부 걸어 둔다.
홉 상한
가장 단순하고 가장 먼저 걸어야 하는 것이다. 홉을 몇 번까지 허용할지 숫자로 못 박고, 상한에 닿으면 지금까지 모은 근거로 답을 만들게 한다. 상한은 라우팅의 갈래와 함께 정한다 — 단일 조회에 다섯 홉을 허용할 이유가 없고, 비교 질문에 한 홉을 주면 반쪽 답이 나온다. 갈래마다 다른 상한을 주는 것이 하나의 전역 상한보다 낫다.
상한값은 로그에서 고른다. 실제로 답을 찾아낸 질의들의 홉 수 분포를 그려 보면 대개 두세 홉에서 꼬리가 얇아지는데, 그 꼬리 자리가 상한이다. 그보다 크게 잡으면 상한이 아무 일도 안 하고, 작게 잡으면 원래 풀리던 질문이 부분 답변으로 떨어진다.
점수 문턱
근거가 충분해지면 더 돌 이유가 없다. 판정기가 매긴 점수의 상위 몇 개가 문턱을 넘으면 그 자리에서 생성으로 넘어간다. 이 조건이 없으면 에이전트는 답을 이미 찾고도 「더 확인해 보자」로 한두 홉을 더 쓴다 — 비용은 늘고 답은 그대로인 가장 아까운 낭비다.
문턱은 판정기의 점수 분포를 보고 정한다. 정답 조각과 오답 조각의 점수가 겹치는 구간이 넓으면 문턱 하나로는 안 갈리므로, 그때는 문턱을 올리는 대신 상위 몇 개가 동시에 넘어야 한다는 조건으로 바꾼다. 한 조각이 우연히 높게 나오는 것과 세 조각이 함께 높게 나오는 것은 신뢰도가 다르다.
반복 감지
같은 검색어로 두 번 이상 도는 것은 진전이 없다는 가장 확실한 신호다. 지금까지 던진 쿼리를 정규화해 집합으로 들고 있다가 같은 것이 다시 나오면 즉시 끊는다. 검색어가 조금씩만 달라지는 경우도 같은 자리이므로, 문자열 일치 대신 임베딩 유사도로 재서 비슷하면 반복으로 세는 편이 잘 걸린다.
쿼리가 아니라 결과로 재는 방법도 있다. 이번 홉에서 꺼내 온 조각이 직전 홉의 것과 거의 같으면, 검색어가 달라졌더라도 같은 자리를 다시 판 것이다. 문서 id 집합의 겹침을 세는 한 줄이면 되고, 쿼리 유사도보다 오탐이 적다.
부분 답변
예산을 넘겼을 때 빈손으로 끝내지 않는다. 지금까지 확인한 것과 확인하지 못한 것을 갈라 적어 돌려주는 것이 훨씬 쓸모 있다. 「A는 문서에서 확인했고 B는 사내 자료에서 찾지 못했다」는 답은 사용자가 다음 수를 정할 수 있게 하지만, 통째로 지어낸 답은 그럴 수 없다.
부분 답변을 제대로 내려면 루프가 도는 동안 확인한 사실을 따로 모아 둬야 한다. 마지막 컨텍스트만 들고 있다가 예산이 끊긴 자리에서 요약하려 하면, 앞 홉에서 이미 확인한 것이 희석되어 사라진 뒤다. 홉마다 남기는 두세 줄 요약이 여기서도 쓰인다 — 정지 조건과 컨텍스트 관리가 같은 장치를 공유하는 셈이다.
실패 모드
검색 루프
에이전트가 답을 못 찾은 채 검색어만 바꿔 가며 계속 도는 상태다. 위의 반복 감지와 홉 상한이 이걸 막는 장치인데, 실제로 걸려 보면 문제가 검색어가 아니라 색인에 있는 경우가 대부분이다. 애초에 없는 정보를 찾고 있는 것이다. 그래서 루프 로그에서 가장 볼 가치가 있는 값은 시도한 쿼리 목록이다 — 그 목록이 곧 「사용자가 물었는데 우리 색인에 없는 것」의 목록이다. 색인을 넓히는 작업의 우선순위를 이보다 잘 알려 주는 자료는 없다.
컨텍스트 희석
홉마다 꺼내 온 조각이 컨텍스트에 쌓인다. 세 홉이면 상위 다섯 조각이 열다섯 개가 되고, 그중 정말 답에 쓰이는 것은 한둘이다. 나머지는 관련은 있지만 답에는 안 쓰이는 조각이라, 모델이 정답 조각에 주는 무게를 그만큼 깎는다. 이것이 컨텍스트 희석이다.
막는 방법은 쌓지 않는 것이다. 홉이 끝날 때마다 그 홉에서 새로 알게 된 것을 두세 줄로 요약해 남기고 원본 조각은 버린다. 마지막 생성 직전에만 최종 근거를 다시 꺼내 붙인다. 컨텍스트 길이가 홉 수에 비례해 늘지 않고 상수에 가깝게 잡히는 것이 이 방식의 이득이다.
요약을 끼우면 정보가 깎이지 않느냐는 걱정이 늘 따라오는데, 실제로 깎이는 것은 대부분 쓰이지 않던 조각이다. 다만 요약에 출처 식별자를 반드시 남긴다. 최종 답에서 근거를 인용해야 하므로 원본으로 돌아갈 길이 끊기면 안 된다.
판정기 과신
판정기가 자기 검색 결과를 후하게 매기는 경향이 있다. 특히 판정기와 생성 모델이 같은 모델이면 심해진다 — 자기가 고른 조각을 자기가 채점하는 구조라 그렇다. 판정 결과를 사람 라벨과 정기적으로 대조하고, 판정기와 검색 쿼리를 만드는 모델을 갈라 두면 덜하다.
증상은 지표에서 먼저 보인다. 교정이 걸리는 비율이 지나치게 낮은데 최종 답의 정확도는 안 오르는 상태가 그것이다. 루프는 매번 「근거가 충분하다」고 판정하고 한 홉 만에 끝나지만, 실제로는 틀린 근거 위에서 끝난 것이다. 교정 발동률을 별도 지표로 찍어 두면 이 조용한 고장을 볼 수 있다.
비용과 지연
호출 수
Agentic RAG의 비용은 홉 수에 선형으로 붙지 않는다. 한 홉은 다음 행동을 정하는 호출 하나, 판정 호출 하나 이상, 그리고 그 홉까지 쌓인 컨텍스트를 매번 다시 읽는 입력 토큰으로 이루어진다. 컨텍스트가 쌓이는 만큼 입력 토큰은 홉마다 늘어나므로, 세 홉짜리 질의의 입력 토큰은 한 홉짜리의 세 배가 아니라 그 이상이 된다.
| 구성 | 고정 RAG | 3홉 Agentic RAG |
|---|---|---|
| 결정 호출 | 0 | 3 |
| 판정 호출 | 0 | 3 |
| 생성 호출 | 1 | 1 |
| 입력 토큰 | 1배 | 4~6배 |
그래서 비용을 잡는 가장 효과적인 수는 홉 상한이 아니라 컨텍스트 희석을 막는 요약이다. 홉을 줄이면 답이 나빠지지만 쌓인 조각을 요약으로 갈아 끼우는 것은 답을 나쁘게 만들지 않는다.
지연은 더 직접적이다. 홉은 순차이므로 세 홉이면 왕복이 세 번이다. 사용자가 기다리는 화면이라면 진행 상황을 먼저 흘려보내는 것이 유일한 완화책이다 — 지금 무엇을 검색하고 있는지를 보여 주면 같은 시간도 다르게 체감된다.
고정 파이프라인의 자리
질문의 형태가 좁으면 에이전트는 손해다. 사내 FAQ처럼 물어볼 것이 정해져 있고 답이 전부 한 색인에 있으면, 에이전트가 늘리는 것은 유연성이 아니라 호출 수와 예측 불가능성뿐이다. 이런 자리에서는 홉을 하나로 고정하고 리랭킹에 예산을 쓰는 편이 같은 돈으로 더 나은 답을 낸다.
갈림길은 라우팅 표에 이미 나와 있다. 들어오는 질문이 단일 조회 한 갈래로 거의 다 덮이면 고정 파이프라인이고, 비교·집계·최신 정보가 고르게 섞여 있으면 그때부터 에이전트다. 어느 쪽인지는 짐작으로 정할 일이 아니라 지난 한 달의 질문 로그를 갈래별로 세어 보면 나온다. 그 수를 세기 전에 에이전트부터 얹는 것이, Agentic RAG를 도입해 놓고 비용만 늘었다는 결말로 가는 가장 흔한 경로다.
읽어주셔서 감사합니다. 😊