ReWOO 완전 정리, 추론을 관찰에서 떼어내면

요약

ReWOO는 도구를 쓰는 에이전트에서 추론(계획)을 중간 관찰과 분리하는 패턴입니다. 도구 호출을 매번 반응하며 하지 않고 처음에 전체 계획을 한 번에 세웁니다.
문제 설정이 날카롭습니다. ReAct처럼 관찰을 끼워 넣으면 관찰이 하나 올 때마다 직전까지의 전체 문맥을 다시 LLM에 밀어 넣어야 해서 토큰이 눈덩이처럼 커집니다.
이걸 가능하게 하는 트릭이 증거 자리표시자 #E1, #E2입니다. 아직 모르는 도구 결과를 변수처럼 두고 뒤 단계가 참조하니, 의존 관계가 있는 다단계 작업도 중간 재호출 없이 이어집니다.
결과적으로 LLM 호출이 도구 개수와 무관하게 계획 1회와 종합 1회, 총 2회로 고정됩니다.
논문 초록 기준으로 HotpotQA에서 토큰 효율 5배, 정확도 4% 향상이고, 175B 모델의 추론을 7B로 오프로딩하는 데 성공했습니다.
대가는 적응력입니다. 미리 다 계획하므로 중간 결과를 보고 경로를 바꾸기 어렵습니다. 분기와 탐색이 많은 과제에는 ReAct가 낫습니다.

1장. 왜 나왔나

1.1 논문 정보

제목   ReWOO: Decoupling Reasoning from Observations
       for Efficient Augmented Language Models
저자   Binfeng Xu, Zhiyuan Peng, Bowen Lei, Subhabrata Mukherjee,
       Yuchen Liu, Dongkuan Xu
출처   arXiv:2305.18323 (2023년 5월)

"도구 쓰는 LLM 에이전트가 왜 이렇게 토큰을 많이 먹는가"를 정면으로 다룬 논문입니다.

1.2 기존 방식의 구조

검색이나 계산기 같은 외부 도구를 붙인 LLM을 Augmented Language Model(ALM)이라 부릅니다. 논문 초록이 기존 방식을 이렇게 서술합니다.

기존 ALM 시스템은
관찰을 끼워 넣는(interleaved) 방식으로 동작한다

   LLM 이 외부 도구를 부르려고 추론하고
   도구 응답을 가져오기 위해 멈추고
   그 앞의 모든 응답 토큰을 근거로 다음 행동을 정한다

   이 방식은 직관적이고 구현이 쉽지만
   중복된 프롬프트와 반복 실행에서 오는
   막대한 계산 복잡도를 낳는다

1.3 왜 토큰이 폭증하나

"중복된 프롬프트"가 정확히 무엇인지 그림으로 보면 분명합니다.

도구를 3번 부르는 과제를 ReAct 로 풀면

   LLM 호출 1   [질문]
   도구 실행 1
   LLM 호출 2   [질문 + 생각1 + 행동1 + 관찰1]
   도구 실행 2
   LLM 호출 3   [질문 + 생각1 + 행동1 + 관찰1 + 생각2 + 행동2 + 관찰2]
   도구 실행 3
   LLM 호출 4   [ ... 전부 다시 ... ]

   매 호출마다 직전까지의 전체 문맥을 통째로 다시 입력한다
   도구 호출이 늘수록 재투입되는 문맥이 누적된다

같은 텍스트를 몇 번이고 다시 밀어 넣는 게 문제입니다. ReWOO는 이 "반복 재투입"을 없애려 합니다.

1.4 흔한 오해 둘

① "도구를 안 쓴다"
   아니다. 도구는 그대로 쓴다
   다만 관찰을 보기 전에 계획을 미리 다 세운다는 뜻이다

② "최종 답에 관찰을 안 쓴다"
   아니다. 계획하는 순간에 중간 관찰이 필요 없게 만든다는 의미다
   관찰은 나중에 Worker 가 채우고 Solver 가 당연히 활용한다

이름이 오해를 부르는 대표 사례입니다. Reasoning WithOut Observation은 "관찰 없이 답한다"가 아니라 "관찰 없이 계획한다"입니다.

2장. 증거 자리표시자

2.1 문제

계획을 미리 다 세우려면
앞 단계의 결과를 모른 채로 뒤 단계를 적어야 한다

   "서울 인구를 검색한 다음, 그 값을 도쿄 인구로 나눈다"

   그런데 서울 인구가 얼마인지 지금은 모른다

2.2 해법

아직 모르는 도구 결과를 변수처럼 #E1, #E2 로 적어 두고
뒤 단계가 이 변수를 참조하게 한다

   #E1 = Search["서울 인구"]
   #E2 = Search["도쿄 인구"]
   #E3 = Calculator[#E1 / #E2]     ← 앞 결과를 변수로 참조

이 한 가지 트릭이 ReWOO 전체를 성립시킵니다. 값을 몰라도 의존 관계를 표현할 수 있으면 계획을 완성할 수 있습니다.

2.3 여기서 두 가지가 따라온다

① 중간 재호출이 사라진다
   의존 관계가 계획 단계에서 이미 변수로 표현돼 있으니
   값을 채우려고 LLM 을 다시 부를 필요가 없다

② 병렬성이 드러난다
   #E1 과 #E2 는 서로 참조하지 않는다
   즉 동시에 실행할 수 있다는 게 계획만 봐도 보인다

두 번째가 나중에 후속 연구로 이어집니다. 5장에서 봅니다.

3장. Planner, Worker, Solver

3.1 전체 흐름

사용자 질의
   │
   ▼
① Planner (계획자)
   도구 호출 계획을 #E1, #E2 로 한 번에 생성
   └──► LLM 호출 1회
   │
   ▼
② Worker (작업자)
   각 도구를 실행해 #En 을 실제 값으로 치환
   └──► LLM 호출 0회. 도구 실행일 뿐이다
   │
   ▼
③ Solver (종합자)
   계획과 채워진 증거로 최종 답 합성
   └──► LLM 호출 1회
   │
   ▼
최종 답

3.2 Planner

질의를 받아 도구 호출 순서 전체를 자리표시자와 함께 생성합니다.

Plan: 서울 인구를 찾는다
#E1 = Search["서울 인구"]

Plan: 도쿄 인구를 찾는다
#E2 = Search["도쿄 인구"]

Plan: 두 값의 비율을 계산한다
#E3 = Calculator[#E1 / #E2]

이 단계에서 LLM을 딱 한 번 부릅니다.

3.3 Worker

계획에 적힌 #En을 순서대로, 서로 의존하지 않으면 병렬로 실행해 실제 값으로 치환합니다.

#E1 = "약 940만"
#E2 = "약 1,400만"
#E3 = "0.67"

여기는 도구 실행이지 LLM 추론이 아닙니다. 이 구분이 비용 구조의 핵심입니다.

3.4 Solver

원래 계획과 채워진 증거를 함께 넣어 최종 답을 만듭니다. 여기서 LLM을 한 번 더 부릅니다.

3.5 호출 수가 고정된다

ReWOO   도구를 몇 번 부르든 LLM 호출은 2회로 고정
        Planner 1회 + Solver 1회

ReAct   관찰마다 다시 부르므로 도구 수에 비례
        O(steps)

이 차이가 토큰과 지연 절감의 전부입니다.

3.6 장보기 비유

ReAct    마트에서 한 칸 옮길 때마다 집에 전화해
         "다음 뭐 사?"라고 묻는다

ReWOO    집에서 장보기 목록을 통째로 적어 가서 (Planner)
         한 번에 다 담고 (Worker)
         돌아와 영수증을 보고 정산한다 (Solver)

   통화 횟수가 "매 칸"에서 "처음과 끝 두 번"으로 준다

4장. 성능과 트레이드오프

4.1 논문이 보고한 것

초록에서 확인되는 수치입니다.

6개 공개 NLP 벤치마크와 자체 구축 데이터셋에서
일관된 성능 향상

특히 HotpotQA (다단계 추론 벤치) 에서
   토큰 효율 5배
   정확도 4% 향상

도구 실패 상황에서의 강건성도 보고

4.2 인용할 때 주의할 것

2차 자료에서 "6개 벤치 평균 토큰 약 64% 절감,
절대 정확도 약 4.4% 향상"으로 인용되기도 한다

   이 구체 수치는 초록에는 없다
   본문 표 기준으로 보이지만 1차 출처로 확인되지 않았다

   확실히 검증된 것은 "HotpotQA 5배와 4%"다

4.3 부가 이득, 모델 경량화

이 부분이 논문의 두 번째 기여입니다.

추론(파라메트릭 능력)과 도구 호출(비파라메트릭 실행)을 분리하면
Planner 만 instruction fine-tuning 으로 작은 모델에 이식할 수 있다

   논문은 175B GPT-3.5 의 추론 능력을
   7B LLaMA 로 오프로딩한 사례를 보인다

"추론과 도구를 분리하면 추론만 따로 경량화할 수 있다"는 게 실증됐습니다. 구조 분리가 모델 경량화의 지렛대가 된 사례입니다.

4.4 핵심 약점, 적응력

미리 전부 계획하므로
중간 결과를 보고 경로를 바꾸기 어렵다

   분기와 예외가 많거나 탐색적인 과제에서는
   계획이 빗나가 오히려 손해다

   이럴 땐 매 스텝 관찰에 반응하는 ReAct 가 유리하다

흥미로운 반전이 하나 있습니다.

도구가 실패해도 계획 전체가 무너지지 않아
도구 실패 강건성은 오히려 좋게 보고된다

   계획이 관찰에 의존하지 않으니
   관찰 하나가 깨져도 나머지 계획이 살아 있다

4.5 Planner 쪽으로 옮겨간 부담

LLM 호출 수는 줄었지만
ReWOO 의 Planner 는 한 번에 더 긴 계획을 만들어야 한다

   단일 호출의 난도가 올라간다
   계획 포맷이 깨지면 Worker 가 #En 변수를 못 찾는
   파싱 문제도 생긴다

비용이 사라진 게 아니라 옮겨간 것입니다.

4.6 대비 정리

	ReAct	ReWOO
LLM 호출 수	단계에 비례	약 2회로 고정
문맥 재투입	매 호출마다 누적	없음
적응력	높음. 관찰마다 경로 조정	낮음. 계획이 굳는다
단일 호출 난도	낮음	높음. 긴 계획을 한 번에
도구 실패	그 자리에서 대응 가능	계획 전체는 안 무너짐
병렬성	표현하기 어려움	계획에서 바로 드러남

5장. 계보

5.1 이후 흐름

시기	발전	요지
2023-05	ReWOO	Planner/Worker/Solver 3모듈과 `#En` 변수 치환
2023-12	LLMCompiler	선계획을 의존 그래프로 확장해 독립 작업을 병렬 실행
2024-02	plan-and-execute 계열 공개	선계획형 에이전트를 프레임워크 레퍼런스로 배포
2024 이후	프로덕션 패턴으로 정착	여러 에이전트 툴킷에 빌트인으로 포함

5.2 LLMCompiler가 밀어붙인 것

2.3에서 본 "병렬성이 드러난다"를 정면으로 활용한 후속 연구입니다.

ReWOO 는 #E1 과 #E2 가 독립이라는 걸 계획에서 알 수 있다
그런데 실행은 순차로 하는 경우가 많았다

LLMCompiler 는 이를 의존 그래프로 명시하고
독립 작업을 실제로 병렬 실행한다

   ReAct 대비 지연과 비용을 크게 줄였다고 보고한다 (저자 보고)

5.3 핵심 대립축

ReAct     적응력, 호출 많음
ReWOO     효율, 선계획

   plan-and-execute   실패 시 재계획을 허용
   LLMCompiler        의존 그래프로 병렬화
   AdaPlanner         피드백으로 계획을 고침

   전부 이 축 위에서 효율과 적응력을 다르게 저울질한 변형이다

6장. 실무

6.1 구현

원 저자 구현
   HotpotQA, TriviaQA, GSM8K, StrategyQA 벤치마크 평가 코드
   Alpaca 기반 7B Planner 와 데모 UI

LangGraph
   ReWOO 를 Planner/Worker/Solver 노드 그래프로 구현한
   공식 튜토리얼과 레퍼런스. #E1 정규식 치환 포함

NVIDIA NeMo Agent Toolkit
   rewoo_agent 를 YAML 로 구성하는 빌트인 에이전트
   planner 프롬프트는 JSON 계획 배열, solver 프롬프트는 종합

6.2 자주 부딪히는 지점 셋

① 도구가 빈 결과나 실패를 돌려줄 때
   재계획 경로가 없으면 Solver 가 근거 없는 답을 지어낼 수 있다
   └──► 실패 시 Planner 재호출이나 ReAct 폴백을 둔다

② 분기와 탐색이 많은 과제에 적용
   선계획이 빗나가 손해다
   └──► 경로가 어느 정도 예측 가능할 때 써야 이득을 본다

③ #En 치환이 계획 텍스트 파싱에 의존
   계획 포맷이 깨지면 변수를 못 찾는다
   └──► 포맷을 엄격히 강제하거나 검증 단계를 둔다

①이 가장 위험합니다. 증거가 비었는데 Solver가 그럴듯한 답을 만들면, 실패가 조용히 오답으로 바뀝니다.

6.3 언제 쓰나

쓸 만한 경우
   도구 호출 경로가 어느 정도 예측 가능하다
   도구 호출 수가 많아 재투입 비용이 크다
   지연이나 비용이 중요하다
   독립 작업이 많아 병렬화 여지가 있다

안 맞는 경우
   중간 결과에 따라 경로가 크게 갈린다
   탐색적이고 예외가 많다
   도구 실패가 잦아 재계획이 자주 필요하다

7장. 정리

7.1 핵심 셋

① "추론을 관찰에서 분리"가 핵심 아이디어다
   계획 단계가 중간 관찰에 의존하지 않게 만들면
   관찰마다 LLM 을 다시 부를 필요가 사라진다

② #En 변수 치환이 이걸 가능하게 하는 트릭이다
   아직 모르는 결과를 변수로 두니
   의존 작업도 중간 재호출 없이 이어진다

③ 효율을 얻는 대가로 적응력을 내준다
   계획이 빗나가는 탐색적 과제에서는 오히려 손해다

7.2 용어 정리

용어	한 줄 뜻
ReWOO	도구 호출을 미리 한 번에 계획하고 실행하고 종합하는 패턴
Planner / Worker / Solver	전체 계획 / 도구 실행 / 최종 답 합성의 세 모듈
증거 자리표시자 (`#E1`, `#E2`)	계획 시 아직 모르는 도구 결과를 가리키는 변수
변수 치환	뒤 단계가 앞 결과를 참조해 중간 재호출 없이 의존 작업을 잇는 것
interleaved	추론과 관찰을 번갈아 섞는 기존 방식
Augmented LM	검색이나 계산기 등 외부 도구를 결합한 LLM
오프로딩	큰 모델의 추론 능력을 작은 모델로 이식해 경량화하는 것
plan-and-execute	전체를 미리 계획한 뒤 실행하고 실패 시 재계획하는 계열

7.3 참고자료

'AI Agent > Patterns' 카테고리의 다른 글

DoT (Division of Thoughts) (0)	2026.08.11
Reflexion (0)	2025.10.19
Plan and Solve (0)	2025.10.05
ReAct (Reasoning + Acting) (0)	2024.02.05

ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models