ReAct vs Tool Calling: 왜 당신의 LLM은 결정해야 하지만 절대 실행해서는 안 되는가

Source: Dev.to

Introduction

LangChain을 배우거나 AI 에이전트를 구축할 때 흔히 떠오르는 질문이 있습니다:

LLM이 어떤 도구를 사용할지 결정할 수 있다면, 왜 우리는 여전히 코드에서 직접 도구를 실행해야 할까요?

겉보기엔 중복처럼 보이지만, 결정과 실행 사이의 차이를 이해하는 것이 프로덕션 수준 에이전트 시스템에 있어 매우 중요합니다.

ReAct Pattern

ReAct (Reason + Act) 패턴에서는 LLM이 순수 텍스트 형태의 추론을 생성합니다. 예시:

Thought: I need the length of the word "LangChain"

ReAct에서 개발자의 역할

1. 텍스트 출력을 파싱한다.
2. 제안된 행동이 유효한지 판단한다.
3. 도구를 실행한다(예: 함수 호출 또는 API 호출).
4. 결과를 모델에 다시 전달해 추가 추론을 수행한다.

ReAct의 문제점

• 취약한 텍스트 파싱 – 자유 형식 텍스트에서 구조화된 의도를 추출하는 것이 오류가 발생하기 쉽다.
• 검증·감사가 어려움 – 행동이 명시적으로 선언되지 않는다.
• 환상적인 행동 – 모델이 존재하지 않는 도구를 제안할 수 있다.
• 확장성 문제 – 신뢰할 수 없는 파싱은 대규모 배포를 불안정하게 만든다.

ReAct는 프로토타이핑에 강력했지만, 프로덕션에 필요한 안전성과 구조를 제공하지 못합니다.

Tool Calling

Tool calling은 LLM이 원시 텍스트 대신 구조화된 의도를 반환하도록 하여 ReAct을 개선합니다. 일반적인 응답 예시:

{
  "tool": "get_word_length",
  "arguments": {
    "word": "LangChain"
  }
}

핵심 변화

• LLM은 무엇을 할지 결정하지만, 도구를 실행하지는 않는다.
• 실행은 여러분의 코드(에이전트 런타임)에서 담당한다.

이는 제한이 아니라 의도적인 설계 선택입니다.

왜 실행을 LLM 밖에 두는가

LLM이 코드를 직접 실행하거나 되돌릴 수 없는 행동을 수행해서는 안 되는 이유는 다음과 같습니다:

• 안전성 – 임의의 코드를 안전하게 실행한다는 보장이 없다.
• 보안 – 데이터베이스, 외부 API, 결제 시스템 등에 직접 접근하는 것은 위험하다.
• 규정 준수 – 감사 로그와 규제 요구사항은 명확한 분리를 요구한다.
• 신뢰성 – 도구 호출 주위에 재시도, 타임아웃, 샌드박싱을 추가할 수 있다.
• 관측 가능성 – LangSmith 같은 플랫폼이 모델과 별도로 실행을 추적할 수 있다.
• 결정론적 동작 – 런타임이 일관된 결과를 강제할 수 있다.

올바른 실행 모델

❌ 잘못된 모델:  LLM이 **결정하고** 도구를 실행
✅ 올바른 모델: LLM이 결정 → 시스템이 실행 → LLM이 추론

이 패턴은 다음에서 사용됩니다:

• LangGraph
• 다중 에이전트 워크플로우
• 프로덕션 AI 시스템
• 실제 에이전트 플랫폼

언제 실행을 모델 밖에 유지해야 하는가

다음과 같은 시스템을 구축한다면, 위와 같은 분리를 유지하세요:

• AI 에이전트(챗봇, 어시스턴트)
• 검색 기반 생성(RAG) 파이프라인
• 외부 행동을 수행하는 대화형 봇
• 외부 호출 에이전트
• 워크플로 자동화 시스템

핵심 요점: LLM은 추론하고, 주변 시스템이 실행한다.

Closing Thoughts

ReAct는 에이전트가 어떻게 생각하는지를 알려주었습니다. 결정‑실행 분리를 내면화하면 에이전트 아키텍처가 훨씬 명확해집니다.

---

Discussion prompt: LangChain을 배우거나 에이전트 시스템을 구축할 때, 처음에 가장 혼란스러웠던 부분은 무엇인가요?