PLAN-AND-ACT 논문 정리

긴 작업을 더 잘 해내는 LLM 에이전트의 계획 능력은 어떻게 개선되는가?

• 원문 제목: PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks
• 저자: Lutfi Eren Erdogan, Nicholas Lee, Sehoon Kim, Suhong Moon, Hiroki Furuta, Gopala Anumanchipalli, Kurt Keutzer, Amir Gholami
• 학회: ICML 2025
• 한 줄 요약: 이 논문은 LLM 에이전트의 장기 작업(long-horizon task) 성능 병목이 “행동(action)”보다 “계획(plan)”에 있다고 보고, Planner/Executor 분리 + 동적 재계획(dynamic replanning) + 계획용 synthetic data 생성으로 성능을 크게 끌어올린다. (논문 p.1, Table 1, Table 4)

---

1. 먼저 결론부터: 이 논문의 핵심은 무엇인가?

이 논문은 웹 탐색 같은 긴 작업에서 에이전트가 실패하는 이유를 꽤 명확하게 짚는다.

1. 하나의 모델이 계획과 실행을 동시에 맡으면 인지 부하가 너무 크다.
   사용자의 목표를 여러 단계로 쪼개는 일과, 현재 HTML에서 클릭/입력 같은 구체 행동을 고르는 일은 성격이 다르다.
2. LLM은 원래 “좋은 계획”을 만들도록 학습된 모델이 아니다.
   특히 특정 웹사이트 구조를 모르면, 그럴듯하지만 실제로는 실행 불가능한 plan을 만들기 쉽다.
3. 그래서 planning을 별도 모듈로 떼고, 그 planner를 따로 학습시켜야 한다.
   그런데 문제는 plan-supervision 데이터가 거의 없다는 점이다. 논문은 이 빈칸을 trajectory → plan 역추론 방식의 synthetic data pipeline으로 채운다.

이 논문의 메시지는 아주 단순하다. (논문 p.1~2)

에이전트 성능을 높이려면 행동 데이터를 더 모으는 것만으로는 부족하고,
“계획을 잘 세우는 법” 자체를 학습시켜야 한다.

---

2. 왜 이 문제가 중요한가?

ReAct류 방식처럼 하나의 모델이 곧바로 질문 → 연속 행동으로 가는 접근은 단순 작업에는 잘 먹힌다.
하지만 작업이 길어질수록 다음 문제가 생긴다.

• 지금까지 뭘 했는지 잊기 쉽다
• 남은 목표를 구조적으로 관리하기 어렵다
• 검색 결과 해석, 조건 분기, 실패 복구 같은 동적 상황에 약하다
• 계획 없이 액션만 따라가다 보니 목표 정렬(goal alignment)이 흐려진다

이 논문은 이 지점을 planning bottleneck으로 본다.
즉, 실행 모델을 더 강하게 만드는 것만으로는 한계가 있고, 좋은 plan이 있어야 executor도 잘 작동한다는 주장이다.

---

3. 제안 방법: PLAN-AND-ACT

3.1 전체 구조: Planner와 Executor를 분리한다

 

Figure 1. Planner가 고수준 계획을 만들고, Executor가 이를 실제 행동으로 번역한다.

구조는 깔끔하다.

• Planner
  • 사용자 요청을 고수준 단계(step)들로 분해한다.
  • 예: “이 GitHub 프로젝트의 top contributor를 팔로우해줘”
    • Contributors 섹션으로 이동
    • top contributor를 찾고 팔로우
• Executor
  • 현재 HTML과 Planner의 step을 보고
  • 클릭, 입력, 스크롤, 종료 메시지 같은 구체 action을 생성한다

즉, Planner는 무엇을 해야 하는지, Executor는 지금 화면에서 그걸 어떻게 할지를 담당한다.

이 분리는 생각보다 중요하다.
좋은 planner는 executor에게 “도로 지도”를 제공하고, executor는 그 지도를 따라 현재 상태에 맞는 구체 행동만 고르면 된다.

---

3.2 핵심 차별점 1: plan은 정적(static)이어서는 안 된다

 

Figure 2. 실행 도중 새 정보를 얻으면 Planner가 남은 plan을 다시 쓴다.

이 논문의 두 번째 핵심은 dynamic replanning이다.

초기 plan만 한 번 만들고 끝내면 이런 문제가 생긴다.

• 검색 결과가 예상과 다르게 나옴
• 어떤 항목이 실제로 top contributor인지 실행 후에야 알 수 있음
• 특정 검색어가 실패하면 대체 전략이 필요함
• 분석 대상이 여러 페이지에 걸쳐 나타남

논문은 이 문제를 해결하기 위해, 매 action 이후 현재 상태와 이전 plan/action을 보고 남은 계획을 다시 생성한다.

이게 왜 강력하냐면, dynamic replanning이 사실상 두 가지 역할을 같이 하기 때문이다.

1. 실패 복구
   • 예: Library at CMU 검색이 실패하면
     Library near CMU 같은 더 일반적인 질의로 다시 계획을 세움
2. 메모리 압축
   • 예: 처음엔 “top contributor를 찾아라”만 알지만,
   • 실행 후 John Doe를 알게 되면 이후 plan은 “John Doe를 팔로우하라”로 바뀐다

즉, planner가 매번 최신 상태를 반영한 “남은 일 목록”을 유지하는 셈이다. (논문 p.4, Appendix A.5)

---

4. 이 논문의 진짜 기술 포인트: Planner 데이터를 어떻게 만들었나?

이 논문의 가장 흥미로운 부분은 성능 숫자만이 아니라,
“Planner를 학습시킬 데이터가 없는데 그걸 어떻게 만들었나?”에 대한 답이다.

4.1 문제: plan 데이터는 만들기 비싸다

Executor용 데이터는 상대적으로 익숙하다.

• 현재 HTML
• 정답 action

이런 형태의 trajectory를 모으면 된다.

하지만 Planner용 데이터는 다르다.

• 사용자 질의
• 질의를 여러 단계로 분해한 좋은 high-level plan

이건 사람이 직접 달아줘야 하는데 비용이 매우 크다.
논문은 이 부분을 synthetic pipeline으로 해결한다.

---

4.2 Synthetic Data Pipeline

 

Figure 3. 쿼리 생성 → trajectory 수집 → grounded plan 생성 → plan expansion 순으로 Planner 데이터를 확장한다.

이 파이프라인은 3단계로 이해하면 쉽다.

(1) Synthetic Query + Trajectory 생성

기존 training query를 seed로 삼아, LLM이 비슷한 새 query를 만든다.
그 다음 demonstrator agent가 웹 환경에서 이 query를 실제로 수행해 trajectory를 만들고, ORM(outcome reward model)으로 성공 trajectory를 필터링한다.

핵심은 실행 가능한 action sequence를 먼저 확보하는 것이다.

---

(2) Grounded Plan Generation

이 단계가 매우 중요하다.

논문은 단순히 teacher LLM에게
“이 query의 plan을 만들어봐”
라고 시키지 않는다.

그렇게 하면 teacher가 실제 웹 구조를 모르기 때문에 그럴듯하지만 환경에 안 맞는 plan을 만들기 쉽다.

대신 성공 trajectory를 보여주고,
“이 action sequence를 설명하는 high-level plan을 역으로 복원해라”
라고 시킨다.

그리고 각 high-level step이 어떤 low-level actions에 대응하는지까지 연결하게 만든다.

이게 왜 중요하냐면, plan이 실제 행동 위에 grounded되기 때문이다.
즉, 실행 가능한 계획만 planner 학습에 들어간다. (논문 p.6)

---

(3) Synthetic Plan Expansion

여기서 끝나지 않는다.

trajectory에서 복원한 plan만으로는 planner 데이터가 부족하다.
논문은 이를 보완하기 위해:

• 10,000개의 synthetic query-plan pair를 추가 생성하고
• 실패 분석을 바탕으로
• 5,000개의 targeted synthetic plan을 더 만든다

이 부분이 논문의 실전감 있는 포인트다.

단순히 대량 생성으로 끝나는 게 아니라,
모델이 자주 틀리는 failure pattern을 찾아 그 주변 데이터를 더 만들어 넣는다.

즉, synthetic data를 양으로만 늘리는 게 아니라 curriculum처럼 조절한 셈이다. (논문 p.7)

---

5. 왜 이 방법이 효과적인가?

이 방법이 잘 되는 이유는 세 가지로 정리할 수 있다.

5.1 Plan quality가 executor quality보다 더 큰 병목이었다

논문 결과를 보면, action trajectory를 조금 더 모으는 것만으로는 큰 개선이 안 난다.
반대로 planner 데이터가 좋아지면 성능이 꾸준히 오른다.

즉, 긴 작업에서는
“어떤 행동을 할 줄 아느냐”보다 “지금 무슨 단계에 있는지 아느냐”가 더 중요하다는 뜻이다. (Table 1, 논문 p.8~9)

---

5.2 Dynamic replanning이 analysis-heavy task에 특히 강하다

정적 plan은 “검색 결과를 해석해서 다음 행동을 결정해야 하는 상황”에 약하다.
반면 replanning은 새로 관찰한 정보를 plan에 다시 반영할 수 있다.

그래서 이 구조는 단순 클릭 automation보다,

• 검색 결과 해석
• 조건 기반 선택
• 실패 후 대체 경로 탐색
• 여러 페이지에 걸친 정보 수집

같은 작업에 더 잘 맞는다.

---

5.3 Trajectory supervision을 plan supervision으로 바꿔냈다

이 논문의 데이터 아이디어는 꽤 예쁘다.

• 직접 plan을 라벨링하기는 비싸다
• 하지만 trajectory는 상대적으로 만들 수 있다
• 그러면 trajectory를 보고 plan을 역주석(reverse annotation) 하면 된다

즉, 싼 supervision으로 비싼 supervision을 만들어낸다는 발상이다. (논문 p.5~7)

---

6. 실험 결과: 얼마나 좋아졌나?

6.1 WebArena-Lite에서의 성능 상승

아래 표는 논문의 Table 1 중, 가장 잘 학습된 executor column(+Synthetic Traj.) 기준으로 planner 개선 효과를 요약한 것이다.

설정	WebArena-Lite 성공률 (%)
No Planner (ReAct-style)	36.97
+ Base Planner	23.63
+ Planner Finetuning	20.60
+ Synthetic Trajectories	30.30
+ Plan Expansion	39.40
+ Targeted Augmentation	43.63
+ Dynamic Replanning	53.94
+ CoT (최종 PLAN-AND-ACT)	57.58

이 표가 보여주는 포인트는 아주 분명하다.

• 대충 만든 planner는 오히려 독이 될 수 있다
  • Base Planner, naive finetuning은 성능이 떨어진다
  • 이유: grounding이 부족하거나 overfitting이 생김
• 좋은 plan 데이터가 들어가면 planner가 진짜 도움이 된다
• 가장 큰 점프는 dynamic replanning
• CoT reasoning까지 붙이면 최종적으로 57.58%

즉, 이 논문의 메시지는 “planner를 붙이는 것”이 아니라
“잘 학습된 planner + dynamic replanning”이 중요하다는 것이다.

---

6.2 추가 benchmark 결과

벤치마크	결과
WebArena-Lite (최종, +CoT)	57.58
WebArena (QWQ-32B)	48.15
WebVoyager text-only (QWQ-32B)	81.36

특히 WebVoyager에서의 81.36%는 이 논문이 주장하는 중요한 결과다.
실험 환경이 simulator인 WebArena 계열을 넘어서, 실제 웹 환경에서도 planning 중심 접근이 강하다는 메시지를 준다. (Table 3, Table 4)

---

6.3 웹사이트별 breakdown

 

Figure 4. 사이트별 성공률과 평균 step 수. Reddit는 강하지만 Multi-website는 여전히 어렵다.

Figure 4를 보면 사이트별 난이도 차이도 드러난다.

• Reddit: 84.2%
  • 비교적 구조가 단순하고 흐름이 익숙한 편
• Shopping / GitLab: 50%대
  • 탐색과 조작이 적절히 섞인 중간 난이도
• Map: 46.2%
  • 검색, 해석, 경로 선택이 섞여 있어 어렵다
• Multiple Websites: 30.0%
  • 멀티-도메인 전환은 아직 매우 어렵다

이건 곧, planning을 개선해도 cross-site orchestration은 여전히 남은 과제라는 뜻이다.

---

6.4 CoT는 생각보다 큰 역할을 한다

논문 부록의 Table 2는 CoT의 효과를 따로 보여준다.

모델	CoT 사용	성능 (%)
Llama-3.3-70B	✗	53.94
Llama-3.1-8B	✓	53.33
QWQ-32B	✓	54.88
Llama-3.3-70B	✓	57.58

해석 포인트는 이렇다.

• CoT를 붙인 8B 모델이 비-CoT 70B와 거의 비슷한 수준까지 올라온다
• 즉, 이 논문에서는 reasoning trace도 planner/executor 학습 신호로 꽤 중요하다

---

7. 이 논문의 기여를 한 문장씩 정리하면

기여 1. Planning과 execution을 분리한 모듈형 에이전트 설계

Planner는 전략, Executor는 행동에 집중하도록 역할을 나눴다.

기여 2. Plan-supervision scarcity를 해결하는 synthetic data pipeline

성공 trajectory에서 grounded plan을 역생성하고, 이를 다시 대규모로 확장했다.

기여 3. Static planning이 아니라 dynamic replanning을 전면에 둠

계획을 한 번 세우고 끝내지 않고, 관찰에 맞춰 계속 업데이트했다.

기여 4. “계획 품질이 에이전트 성능의 병목”이라는 점을 실험으로 설득

단순 executor 강화보다 planner 학습이 더 결정적일 수 있음을 보여줬다.

---

8. 이 논문에서 읽히는 더 큰 인사이트

이 논문은 겉으로는 web agent 논문이지만, 더 일반화하면 이런 이야기다.

에이전트 문제는 종종 “행동 생성” 문제가 아니라
“상태를 요약하고, 남은 목표를 재구성하는 문제”다.

 

그래서 이 논문은 사실상 planning을 이렇게 다시 정의한다.

• 미래 행동을 미리 다 써놓는 것
• → 가 아니라,
• 현재까지의 정보로 “남은 목표를 가장 잘 표현한 중간 표현(intermediate representation)”을 계속 유지하는 것

이 관점은 웹 탐색뿐 아니라

• 소프트웨어 에이전트
• 로봇 태스크
• 멀티툴 에이전트
• 비서형 워크플로 자동화

에도 꽤 넓게 적용될 수 있다.

---

9. 한계도 분명하다

논문이 솔직하게 인정하는 한계는 다음과 같다.

9.1 초기 trajectory 수집은 여전히 “어느 정도 되는 base model”이 필요하다

즉, 아무것도 없는 완전 제로 상태에서 synthetic pipeline만으로 시작하기는 어렵다.

9.2 WebVoyager처럼 training data가 없는 환경에서는 결국 base model 의존이 남는다

trajectory를 모으려면 최소한 돌아가는 demonstrator가 필요하다.

9.3 매 action마다 replanning하는 방식은 비효율적일 수 있다

실시간 시스템에서는 latency와 비용이 커질 수 있다.
논문도 future work로

• executor가 replanning 필요 여부를 판단하거나
• planner가 sub-agent에 일부를 위임하는 구조
  를 제안한다.

---

10. 핵심 포인트

짧은 요약 버전

• 긴 작업에서 에이전트가 실패하는 핵심 이유는 실행보다 계획의 품질에 있다.
• PLAN-AND-ACT는 Planner/Executor 분리와 dynamic replanning으로 이 문제를 해결한다.
• 가장 큰 기술 포인트는 trajectory에서 grounded plan을 역생성하는 synthetic data pipeline이다.
• 결과적으로 WebArena-Lite에서 57.58%, WebVoyager text-only에서 81.36%를 달성한다.

조금 더 강한 메시지 버전

• 좋은 action model보다 좋은 planner가 더 중요할 수 있다.
• 계획은 한 번 세우는 문서가 아니라, 관찰에 따라 계속 갱신되는 작업 메모리다.
• Synthetic data는 단순 증강이 아니라, 부족한 supervision 형태를 변환하는 도구가 될 수 있다.

---

11. 읽고 남기는 포인트

이 논문에서 특히 눈에 띄는 포인트는 세 가지다.

1. Base Planner가 성능을 떨어뜨리는 구간을 숨기지 않았다
   → planner라는 아이디어 자체가 아니라, grounded planner 학습이 중요하다는 걸 더 설득력 있게 보여준다.
2. Dynamic replanning을 “메모리 없는 memory”처럼 썼다
   → 별도 memory module 없이도, plan이 최신 상태를 계속 들고 가게 만든다.
3. Trajectory → Plan 역주석이 아주 실용적이다
   → 실제 시스템을 만들 때도 충분히 응용 가능한 아이디어다.

---

12. 부록: 논문 속 재현 관련 figure

 

Figure 5. 재현 관점에서 참고할 수 있는 학습/추론 하이퍼파라미터. 핵심 아이디어 자체보다 reproduction에 더 유용한 figure다.

간단히 보면:

• 학습
  • LR 2e-5, AdamW, cosine scheduler
  • batch size 32, epoch 1
  • 8×A100
• 추론
  • temperature 0
  • max generated tokens 4196
  • max sequence length 32000

---

13. 마무리

이 논문은 “LLM agent를 더 똑똑하게 만드는 방법”을 묻기보다,
“에이전트가 긴 작업에서 무엇을 잊고, 어디서 흔들리는가?”를 잘 파고든 논문이다.

그리고 그 해답을

• 역할 분리(Planner / Executor),
• 계획의 지속적 갱신(dynamic replanning),
• 계획 데이터의 합성(synthetic planner data)

으로 제시한다.

실전적으로 보자면, 이 논문은 단순한 benchmark 개선을 넘어서
“long-horizon agent를 만들 때 planner를 별도 학습 대상으로 다뤄야 한다”는 설계 원칙을 꽤 강하게 남긴다.

---

참고문헌

Erdogan, L. E., Lee, N., Kim, S., Moon, S., Furuta, H., Anumanchipalli, G., Keutzer, K., & Gholami, A.
PLAN-AND-ACT: Improving Planning of Agents for Long-Horizon Tasks.
Proceedings of the 42nd International Conference on Machine Learning (ICML 2025).