7장. 리액트 에이전트를 활용한 RAG

출처: 『RAG 마스터: 랭체인으로 완성하는 LLM 서비스』(브라이스 유·조경아·박수진·김재웅, 프리렉 2025) | 공식: https://www.langchain.com/

LLM이 스스로 '생각→행동→관찰'을 반복하며 복잡한 질문을 단계적으로 해결하는 에이전트 RAG. 탐정처럼 단서를 수집해 가며 추론하는 방식으로, 단일 검색으로는 풀 수 없는 멀티-홉 질문을 가능하게 한다.

실습 — 책 공식 노트북: Ch07. Agent 폴더. 코랩 바로 열기: ReAct Agent — 사고·행동·관찰 루프 + Tavily 검색 도구 연동 종합.

학습 목표

이 장을 끝내면 다음을 할 수 있다.

• ReAct(Reasoning+Acting) 패러다임의 사이클 구조와 CoT와의 관계를 설명한다.
• 일반 RAG와 에이전트 RAG의 차이를 검색 횟수·도구 선택·적합 질문 유형 측면에서 비교한다.
• create_retriever_tool()로 벡터 검색기를 에이전트 도구로 변환하고 name·description을 올바르게 작성한다.
• create_react_agent + AgentExecutor로 ReAct 에이전트를 구현하고 멀티-홉 질문을 처리한다.
• 도구 description·프롬프트 주의사항·temperature 설정을 조합해 에이전트 오류를 예방하는 설계를 선택한다.

전체 흐름도

ReAct 에이전트는 목표가 달성될 때까지 사고-행동-관찰 루프를 반복한다.

[ 사용자 질문 입력 ]
       │
       ▼
[ Thought — 상황 분석 + 다음 행동 추론 ]
       │
       ▼
[ Action — 도구 선택 ]
       │
       ├─ japan_ict (일본 ICT 검색기)
       └─ usa_ict   (미국 ICT 검색기)
       │
       ▼
[ Action Input — 도구에 넘길 구체적 입력값 생성 ]
       │
       ▼
[ Observation — 도구 실행 결과 수신 ]
       │
       ▼
[ 충분한 정보 모임? ]
       │
       ├─ 아니오 → [ Thought ] (루프 재시작)
       │
       └─ 예
              │
              ▼
       [ Final Answer — 최종 답변 생성 ]

0. 사전 필수 용어

• 에이전트(Agent) — 목표 달성을 위해 상황을 인식하고, 다음 행동을 스스로 추론·계획·실행하는 AI 시스템. 단순 체인과 달리 어떤 도구를 언제 쓸지를 스스로 결정한다.
• ReAct — Reasoning(추론)과 Acting(행동)을 결합한 에이전트 방법론(프린스턴·구글 공동 연구). '생각→행동→행동 입력→관찰' 사이클을 목표 달성까지 반복한다.
• 생각의 사슬(CoT, Chain of Thought) — 최종 답 전에 풀이 과정을 먼저 쓰도록 유도하는 기법. ReAct는 CoT를 차용해 매 행동 전 '생각' 단계를 강제한다.
• 도구(Tool) — 에이전트가 외부 세계와 상호작용하는 실행 단위. 벡터 검색기, API 호출, 계산기 등. @tool 데코레이터 또는 create_retriever_tool()로 정의한다.
• 도구 호출(Tool Calling) — LLM이 자연어 추론 결과로 특정 도구를 선택하고 입력값을 생성해 실행하는 과정.
• 관찰(Observation) — 도구 실행 결과. 이 결과를 바탕으로 에이전트는 다음 '생각'을 이어간다.
• AgentExecutor — 에이전트(추론) + 도구(실행)를 감싸 ReAct 루프를 실행하는 런타임. verbose=True로 내부 Thought/Action/Observation 흐름을 볼 수 있다.
• agent_scratchpad — 지금까지의 모든 사이클(Thought/Action/Observation)이 누적되는 임시 메모장. 에이전트는 이를 참고해 다음 행동을 결정한다.

1. 생각의 사슬 — ReAct(Reasoning+Acting)

1.1 ReAct 순환 구조

ReAct는 탐정이 사건을 풀어가는 방식과 같다. 탐정은 현장을 보고(관찰) → 가설을 세우고(생각) → 다음 단서를 찾아 행동하며 → 결과를 다시 관찰한다. LLM이 이 과정을 반복하며 복잡한 질문을 단계별로 풀어낸다.

ReAct 방법론은 프린스턴 대학교와 구글 연구원들이 공동으로 개발했다. Reason(추론)과 Act(행동)을 결합한 용어로, LLM이 추론과 행동을 유기적으로 함께 사용하며 문제를 해결한다. 이전에 경험하지 못한 상황이나 정보가 부족한 상황에서도 스스로 적절한 의사결정을 통해 문제를 해결할 수 있도록 하는 것이 핵심이다.

사이클 1:
  Thought  → 현재 상황 분석 + 다음 행동 추론
  Action   → 사용할 도구 선택 (예: japan_ict)
  Action Input → 도구에 넘길 구체적인 입력값
  Observation → 도구 실행 결과 (검색 결과, API 응답 등)

사이클 2:
  Thought  → 관찰 결과를 반영해 다시 추론
  Action   → 다음 도구 선택 (예: usa_ict)
  ...
  Final Answer → 충분한 정보가 모이면 최종 답변 생성

파스타 요리 비유:

• 첫 번째 Thought: "파스타를 삶아야 한다. 물의 양을 모르겠다. 요리책을 봐야겠다."
• Action: 요리책 펼치기 / Action Input: 목차에서 '파스타' 페이지로 이동
• Observation: "100g당 물 1L가 필요하다"
• 두 번째 Thought: "300g이면 3L가 필요하다. 계량컵을 찾아야겠다."
• Action: 주방 서랍 열기 / Observation: 계량컵 발견

이처럼 관찰이 다음 생각의 출발점이 된다.

1.2 생각의 사슬(CoT)이 정확도를 높이는 이유

CoT(Chain of Thought)는 "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models" 논문에서 제시된 기법이다. 대규모 언어 모델이 답을 결정하기 전에 풀이 과정을 먼저 작성하도록 하면 더 정확한 답에 도달한다는 아이디어다.

단답형 프롬프트와 CoT 프롬프트를 비교하면 차이가 명확하다.

# 단답형 예시 — 예시에서 단답형으로 답했으므로 모델도 단답형으로 흉내냄
질문: 카페에는 원래 23개의 사과가 있었습니다.
      점심을 만들기 위해 20개를 사용하고 6개를 더 구입했다면 몇 개?
정답: 27개 (오답 — 계산 없이 단답형)

# CoT 유도 프롬프트 — 예시에서 풀이 과정을 보여주면 모델도 과정을 먼저 씀
정답: 카페에는 원래 23개의 사과가 있었습니다.
      20개를 사용했으므로 23-20=3개가 남았습니다.
      6개를 추가로 구입했으므로 3+6=9개입니다.
      따라서 답은 9개입니다. (정답)

LLM은 예시를 흉내 내는 특성이 있다. 예시에서 풀이 과정을 보여주면, 실제 질문에서도 과정을 먼저 쓰고 답변한다. 항상 보장되는 것은 아니지만, 풀이 과정을 거치면 성능이 오르는 경우가 많다. ReAct는 이 원리를 에이전트의 도구 선택과 행동에 적용한다.

2. 에이전트 RAG

에이전트 RAG는 RAG에 대규모 언어 모델의 의사결정 능력을 결합한 시스템이다. 단순 RAG는 고정된 검색 → 생성 파이프라인이지만, 에이전트 RAG는 어떤 정보가 필요한지 스스로 판단하고 필요한 검색을 반복한다.

2.1 라이브러리·데이터 준비

실습에서는 두 PDF(일본·미국 ICT 정책 보고서)를 각각 벡터 DB로 만들어 두 개의 검색 도구를 에이전트에 부여한다.

import os
import requests
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.document_loaders import PyMuPDFLoader
from langchain_community.vectorstores import Chroma
from langchain.tools import create_retriever_tool
from langchain import hub
from langchain.agents import AgentExecutor, create_react_agent
from langchain_core.prompts import PromptTemplate

# 실습 PDF 다운로드 (일본·미국 ICT 정책 보고서 2024)
urls = [
    "https://raw.githubusercontent.com/langchain-kr/langchain-tutorial/main/Ch07.%20Agent/ict_japan_2024.pdf",
    "https://raw.githubusercontent.com/langchain-kr/langchain-tutorial/main/Ch07.%20Agent/ict_usa_2024.pdf",
]
for url in urls:
    filename = url.split("/")[-1]
    response = requests.get(url)
    with open(filename, "wb") as f:
        f.write(response.content)
    print(f"{filename} 다운로드 완료")

각 라이브러리의 역할:

2.2 에이전트 도구(tool) 만들기

PDF를 벡터 DB 검색기로 변환하는 함수를 정의하고, 이를 에이전트 도구로 감싼다.

def create_pdf_retriever(
    pdf_path: str,
    persist_directory: str,
    embedding_model: OpenAIEmbeddings,
    chunk_size: int = 512,
    chunk_overlap: int = 0,
):
    """PDF를 로드·청킹·임베딩해 Chroma 검색기를 반환한다."""
    # 1단계: PDF 로드
    loader = PyMuPDFLoader(pdf_path)
    data = loader.load()

    # 2단계: 청킹 (tiktoken 기준)
    splitter = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap,
    )
    doc_splits = splitter.split_documents(data)

    # 3단계: 벡터 저장소 생성 후 검색기 반환
    vectorstore = Chroma.from_documents(
        persist_directory=persist_directory,
        documents=doc_splits,
        embedding=embedding_model,
    )
    return vectorstore.as_retriever()

embd = OpenAIEmbeddings()

# 두 개의 독립 벡터 DB 생성 — persist_directory를 다르게 해야 데이터가 섞이지 않는다
retriever_japan = create_pdf_retriever(
    pdf_path="ict_japan_2024.pdf",
    persist_directory="db_ict_policy_japan_2024",
    embedding_model=embd,
)
retriever_usa = create_pdf_retriever(
    pdf_path="ict_usa_2024.pdf",
    persist_directory="db_ict_policy_usa_2024",
    embedding_model=embd,
)

# 검색기를 에이전트 도구로 변환 — description이 에이전트의 도구 선택 기준!
jp_engine = create_retriever_tool(
    retriever=retriever_japan,
    name="japan_ict",
    description="일본의 ICT 시장 동향 정보를 제공합니다. 일본 ICT와 관련된 질문은 이 도구를 사용하세요.",
)
usa_engine = create_retriever_tool(
    retriever=retriever_usa,
    name="usa_ict",
    description="미국의 ICT 시장 동향 정보를 제공합니다. 미국 ICT와 관련된 질문은 이 도구를 사용하세요.",
)
tools = [jp_engine, usa_engine]

핵심 포인트 — description을 구체적으로 작성할수록 에이전트가 올바른 도구를 선택한다. 설명이 모호하면 에이전트가 잘못된 도구를 고를 수 있다. persist_directory를 다르게 지정해야 두 벡터 DB가 독립 관리된다 — 같은 경로 사용 시 첫 번째 문서 데이터가 덮어써지거나 섞일 수 있다.

2.3 에이전트 프롬프트 설정

랭체인 허브의 기본 ReAct 프롬프트(hwchase17/react)는 영어·단순 구성이다. 실습에서는 한글·상세 주의사항을 추가한 커스텀 프롬프트를 사용한다.

# 기본 프롬프트 확인
prompt_react = hub.pull("hwchase17/react")
# 핵심 변수 4개:
# {tools}            — 도구 이름·설명 목록 (create_retriever_tool의 name+description)
# {tool_names}       — 도구 이름만 리스트 형태 [japan_ict, usa_ict]
# {input}            — 사용자 질문
# {agent_scratchpad} — 지금까지의 Thought/Action/Observation 누적 기록

# 커스텀 한글 프롬프트 — 기본 프롬프트보다 자세한 주의사항 추가
template = """다음 질문에 최선을 다해 답변하세요. 당신은 다음 도구들에 접근할 수 있습니다:

{tools}

다음 형식을 사용하세요:
Question: 답변해야 하는 입력 질문
Thought: 무엇을 할지 항상 생각하세요.
Action: 취해야 할 행동, [{tool_names}] 중 하나여야 합니다.
Action Input: 행동에 대한 입력값
Observation: 행동의 결과
(이 Thought/Action/Action Input/Observation의 과정이 N번 반복될 수 있습니다)
Thought: 이제 최종 답변을 알겠습니다.
Final Answer: 원래 입력된 질문에 대한 최종 답변

## 추가적인 주의사항
반드시 [Thought -> Action -> Action Input] 사이클 순서를 준수하십시오.
- 최종 답변에는 최대한 많은 내용을 포함하십시오.
- 한 번의 검색으로 해결되지 않으면 문제를 분할하여 푸십시오.
- 정보가 취합되었다면 불필요하게 사이클을 반복하지 마십시오.
- 묻지 않은 정보를 찾으려고 도구를 사용하지 마십시오.

시작하세요!
Question: {input}
Thought: {agent_scratchpad}"""

prompt = PromptTemplate.from_template(template)

{agent_scratchpad}가 핵심이다. 에이전트의 모든 이전 사이클이 여기에 쌓이므로, 이를 참고해 다음 행동을 결정할 수 있다. 매 Action 전 Thought를 강제하는 구조가 CoT를 구현한다. Final Answer 전에도 "이제 최종 답을 알겠습니다"라는 명시적 생각 단계를 거쳐 에이전트가 확신이 있을 때만 답변하도록 설계되어 있다.

2.4 에이전트 객체 생성

# LLM: 에이전트는 창의성보다 지시 이행이 중요 → temperature=0
llm = ChatOpenAI(model="gpt-4o", temperature=0)

# ReAct 에이전트 생성 (LLM + 도구 + 프롬프트)
react_agent = create_react_agent(llm=llm, tools=tools, prompt=prompt)

# AgentExecutor: 에이전트를 실행하는 런타임
react_agent_executor = AgentExecutor(
    agent=react_agent,
    tools=tools,
    verbose=True,               # Thought/Action/Observation 과정을 출력
    handle_parsing_errors=True, # LLM이 형식을 잘못 작성해도 자동 복구
)

temperature=0을 쓰는 이유: 에이전트는 '창의적 답변'이 아니라 '지시사항 정확히 따르기'가 목표다. 높은 temperature는 도구 선택 오류·형식 불일치(파싱 오류)를 유발한다. handle_parsing_errors=True는 Thought/Action/Action Input을 작성하는 과정에서 LLM이 형식을 잘못 작성하는 파싱 오류를 자동 처리한다.

LangGraph 대안 — 책의 create_react_agent + AgentExecutor 조합 대신, LangGraph의 create_react_agent() 헬퍼를 써도 동일한 ReAct 루프를 구현할 수 있다. 최신 코드에서는 LangGraph 방식이 권장된다(최신 동향 참조).

2.5 에이전트 RAG 실습

# 단일 도구 호출 — 미국 ICT 질문 (usa_ict 1회)
result = react_agent_executor.invoke({"input": "한국과 미국의 ICT 기관 협력 사례"})

# 실행 흐름 (verbose=True 출력):
# Thought(1): 이 질문은 미국 ICT 관련이므로 usa_ict를 사용해야겠다.
# Action: usa_ict
# Action Input: 한국과 미국의 ICT 기관 협력 사례
# [Observation: 한-미 FTA, 실리콘밸리 MOU 등 검색 결과]
# Thought(2): 충분한 정보를 얻었다. 최종 답변을 작성하겠다.
# Final Answer: 한국과 미국의 ICT 기관 협력 사례로는...

print("최종 답변:", result["output"])

# 멀티-홉 질문 — 두 도구 모두 필요 (usa_ict + japan_ict 각 1회)
result = react_agent_executor.invoke({
    "input": "미국과 일본의 ICT 주요 정책의 공통점과 차이점을 설명해줘."
})

# 실행 흐름:
# Thought(1): 두 나라 모두 조사해야 한다. 먼저 미국 정보를 수집하겠다.
# Action: usa_ict  →  Observation: [미국 ICT 정책 검색 결과]
# Thought(2): 이제 일본 정보도 필요하다.
# Action: japan_ict  →  Observation: [일본 ICT 정책 검색 결과]
# Thought(3): 두 나라 정보가 모두 모였다. 비교 분석한 최종 답변을 작성한다.
# Final Answer: [공통점·차이점 분석]

# 복합 질문 — usa_ict 3번 + japan_ict 1번 호출
result = react_agent_executor.invoke({
    "input": "미국의 ICT 관련 정부 기구, 주요 법령, 국내 기업 진출 사례를 각각 따로 검색해. "
             "그렇게 해서 정보 좀 모아봐. 그리고 나서 일본의 AI 정책도 알려줘."
})
# 에이전트가 스스로 4번의 도구 호출 계획을 세우고 순차 실행한다:
# 1) usa_ict - 미국 ICT 정부 기구
# 2) usa_ict - 미국 ICT 주요 법령
# 3) usa_ict - 미국 ICT 국내 기업 진출 사례
# 4) japan_ict - 일본 AI 정책

에이전트 RAG의 핵심 가치: 일반 RAG는 "하나의 검색 → 하나의 답변" 구조여서 복합 질문에 한계가 있다. 에이전트 RAG는 질문을 자체 분해하고 필요한 도구를 필요한 횟수만큼 호출해 복잡한 멀티-홉 질문도 해결한다.

핵심 개념 정리

한 문장 요약 — 에이전트 RAG는 LLM이 CoT로 상황을 추론하고, 도구를 스스로 선택·호출·관찰하는 ReAct 사이클을 반복해 단일 검색으로는 풀 수 없는 복잡한 질문을 단계적으로 해결하는 시스템이다.

실무 체크리스트

• [ ] 도구의 description을 구체적으로 작성한다 — 에이전트가 description을 보고 도구를 선택하므로, 모호하면 오선택 발생.
• [ ] 에이전트 LLM은 temperature=0으로 설정한다 — 예측 가능한 도구 선택과 형식 준수를 위해.
• [ ] 여러 PDF/데이터소스는 persist_directory를 다르게 지정해 벡터 DB를 독립 관리한다.
• [ ] verbose=True + handle_parsing_errors=True로 디버깅 가시성을 확보한다.
• [ ] 커스텀 프롬프트에 "정보가 충분하면 반복하지 말 것" 주의사항을 명시해 불필요한 루프를 방지한다.
• [ ] 복합 질문은 에이전트가 자체 분해하도록 믿되, 도구 description으로 경계를 명확히 한다.

연습문제

1. 개념. ReAct에서 '생각(Thought)' 단계가 없으면 어떤 문제가 생기는가? CoT와의 관계를 함께 설명하라.
2. 비교. 일반 RAG 파이프라인(prompt | retriever | llm)과 에이전트 RAG의 차이를 세 가지 측면(검색 횟수·도구 선택·적합한 질문 유형)에서 비교하라.
3. 코드. create_retriever_tool()에서 name과 description의 역할 차이를 설명하고, 새로운 도구(예: 뉴스 API 검색기)를 추가하는 코드를 작성하라.
4. 적용. 에이전트가 usa_ict를 3번 호출하는 질문("미국 정부 기구·주요 법령·기업 진출 사례 각각")에서 내부 Thought/Action/Observation 흐름을 단계별로 그려라.
5. 설계. 국내 법률·판례·학술논문 세 개 데이터소스를 검색하는 법률 에이전트를 설계하라. 도구 이름·description·프롬프트 주의사항을 작성하고, 멀티-홉 질문 처리 흐름을 설명하라.

최신 동향 (2026-05 기준)

최신 동향 (검증 2026-05-21) — 책은 2025년(LangChain 0.3) 기준이므로 아래만 보완해 익히면 된다.

• LangGraph create_react_agent() 헬퍼. 책의 수동 구성(create_react_agent + AgentExecutor) 대신 LangGraph의 create_react_agent() 헬퍼를 쓰면 보일러플레이트를 크게 줄일 수 있다. LangGraph 1.0(GA) 이후 복잡한 에이전트의 표준 구현 방식이다. (출처: https://langchain-ai.github.io/langgraph/agents/agents/)
• 에이전트 메모리는 LangGraph checkpointer로. 멀티-턴 대화 에이전트라면 AgentExecutor 대신 LangGraph의 persistence(checkpointer) 기반 에이전트가 권장된다. 상태 유지·중단·재개가 가능하다.
• 모델·가격은 수시 변동. 책의 gpt-4o 표기는 2025년 기준 예시다. 실제 사용 시 공식 모델 목록을 확인하라: OpenAI(https://platform.openai.com/docs/models) · Anthropic(https://docs.anthropic.com/en/docs/about-claude/models).

부록 A. 용어 사전

부록 B. 핵심 비교표

일반 RAG vs 에이전트 RAG

ReAct vs 단순 체인

부록 C. 추천 참고 자료

검증된 외부 자료 (Tier 1 공식, 생존 확인 2026-05-21)

부록 D. 연습문제 풀이

1. (Thought 없이 직접 행동 → 도구 오선택·무한 루프 위험) Thought 단계는 "현재 어떤 도구가 필요한가?"를 추론하는 단계다. 이 단계를 생략하면 에이전트는 맥락 없이 Action을 생성하므로 엉뚱한 도구를 선택하거나, 이전 Observation을 반영하지 못해 동일 도구를 불필요하게 반복 호출한다. CoT는 "답 전에 풀이 과정을 명시"하는 프롬프트 기법이고, ReAct는 CoT를 에이전트의 도구 선택과 행동에 적용한 것이다. 즉, 매 Action 전 Thought를 강제함으로써 CoT가 구현된다.

2. (세 측면 비교: 검색 횟수·도구 선택·적합 질문 유형) 일반 RAG는 단일 검색기를 1회 호출하는 고정 파이프라인(prompt | retriever | llm)이므로 단순 사실 조회에 적합하다. 에이전트 RAG는 ReAct 루프를 통해 검색을 N회 반복할 수 있고, 여러 도구 중 LLM이 매 사이클마다 적합한 도구를 자율 선택한다. 따라서 단일 검색으로는 풀 수 없는 멀티-홉·복합·비교 질문을 처리할 수 있다.

3. (name은 식별자, description은 선택 기준; 뉴스 API 도구 추가 예시) name은 에이전트가 Action 필드에 기입하는 도구 식별자(공백 없는 짧은 문자열)이고, description은 에이전트가 "이 도구를 언제 써야 하는가"를 판단하는 자연어 설명이다. description이 모호하면 에이전트가 잘못된 도구를 고른다.

from langchain.tools import create_retriever_tool

# 예: 뉴스 API 검색기를 이미 retriever 객체로 가지고 있다고 가정
news_engine = create_retriever_tool(
    retriever=news_retriever,
    name="news_search",
    description="최신 뉴스를 검색합니다. ICT 관련 최신 뉴스나 사건이 필요한 질문은 이 도구를 사용하세요.",
)
tools = [jp_engine, usa_engine, news_engine]

1. (usa_ict 3회 + japan_ict 1회 흐름) 질문이 세 가지 미국 정보를 각각 요청하므로 에이전트는 이를 세 개의 독립 서브질문으로 분해한다.

Question: 미국 정부 기구·주요 법령·기업 진출 사례 각각 + 일본 AI 정책

Thought(1): 미국 정보를 각 항목별로 따로 검색하겠다. 먼저 정부 기구부터.
Action: usa_ict  /  Action Input: 미국 ICT 정부 기구
Observation: [FCC, NTIA 등 기관 설명]

Thought(2): 이제 미국 ICT 주요 법령을 검색한다.
Action: usa_ict  /  Action Input: 미국 ICT 주요 법령
Observation: [반도체 과학법(CHIPS Act) 등]

Thought(3): 미국 기업 진출 사례를 검색한다.
Action: usa_ict  /  Action Input: 미국 ICT 국내 기업 진출 사례
Observation: [한-미 FTA, 경북 MOU 등]

Thought(4): 일본 AI 정책도 필요하다.
Action: japan_ict  /  Action Input: 일본 AI 정책
Observation: [경산성 AI 인재 육성 지침 등]

Thought(5): 모든 정보가 모였다. 최종 답변을 정리하겠다.
Final Answer: [4개 항목 종합 답변]

1. (법률 에이전트 설계: 도구 3개 + 프롬프트 주의사항 + 멀티-홉 흐름) 세 데이터소스를 각각 독립 도구로 정의하고, description으로 사용 경계를 명확히 한다.

law_tool = create_retriever_tool(
    retriever=law_retriever,
    name="korean_law",
    description="국내 법령 및 조문 정보를 제공합니다. 특정 법률 조항이 필요한 질문에 사용하세요.",
)
precedent_tool = create_retriever_tool(
    retriever=precedent_retriever,
    name="court_precedent",
    description="국내 법원 판례 정보를 제공합니다. 판례나 판결 내용이 필요한 질문에 사용하세요.",
)
paper_tool = create_retriever_tool(
    retriever=paper_retriever,
    name="legal_paper",
    description="법학 학술논문 정보를 제공합니다. 학술적 해석이나 이론이 필요한 질문에 사용하세요.",
)
tools = [law_tool, precedent_tool, paper_tool]

프롬프트 주의사항: 도구 description 경계를 명확히 해 오선택을 방지하고, "정보가 충분하면 루프를 반복하지 말 것"과 "매 행동 전 Thought를 반드시 작성할 것"을 명시한다. 에이전트 LLM은 temperature=0으로 설정한다. 멀티-홉 흐름 예시: "저작권법 조항 확인(korean_law) → 관련 판례 검색(court_precedent) → 학술논문의 해석 인용(legal_paper) → 세 결과를 종합해 최종 답변 생성"의 3-사이클 루프로 처리된다.