[Agent] Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks

Agentic AI system

 

일반적인 AI 시스템은 사용자의 요청에 단일 응답만을 수동적으로 출력하는 구조이다. Agentic AI는 사용자의 쿼리를 분석해 목표를 이해하고 그 목표를 달성하기 위해 계획을 세우고, 여러 작업을 실행하고 결과를 재평가하는 과정을 스스로 수행하는 시스템을 의미한다. 단일 지시-응답 구조가 아니라 연속적인 의사결정이 필요하다는 점이 큰 포인트이다.

 

이러한 능동적인 AI system에 있어 유연성이 중요한 반면 그만큼 통제가 어렵다는 문제가 있다. 최근에 OpenAI의 agent sdk를 활용하여 간단한 앱을 구성해보았었다. 아주 단순한 작업임에도 오케스트레이션이 적절한 툴을 호출하지 못하거나, 툴만 호출하고 툴 결과를 재조합해서 답변을 하거나 툴을 호출하지 않았음에도 호출했다고 가정하고 답변하는 경우도 많았다. 툴을 여러개 등록하더라도 어떤 툴을 언제 어떻게 호출할지에 대한 결정이 GPT에게 위임이 되어있다. 이 흐름이 전체적으로 자동화되어 있어 예측하기 어려운 방식으로 툴이 호출되거나 의도하지 않은 작업이 실행되는 경우가 많았다. 이를 해결하는 방법은 물론 있다. Guardrails나 Custom Router를 설정하면 되는데, 그렇게 되면 오히려 SDK를 사용하는 것 보다 GPT 호출을 직접 조립하여 여러 호출 단계로 나눠서 시스템을 구성하는 것이 훨씬 명확하고 통제 가능한 구조처럼 보였다.

 

이처럼 툴 호출 흐름이나 작업 전반을 쉽게 제어할 수 없는 상황이 지금 Agentic AI 구조에 어떤 한계점과 맞물려 있는지 궁금했고 다음과 같은 cognition 블로그 글을 발견했다. 

 

 

Don't Build Multi-Agents

 

Agentic system에서 여러 복잡하고 Long-horizon의 작업을 subtask로 나눠 subagent에게 분배하고 각 결과를 취합하는 Multi-agent구조는 Openai (Swarm)와 Microsoft (Autogen)등의 에이전틱 시스템에 널리 사용된다. 

 

cognition에서는 Agentic AI system이 웹 개발 초창기와 닮아 있다고 얘기한다. 과거에는 웹 개발자들이 html과 css를 조합하며 다양한 방식으로 웹을 만들었지만 지금은 리액트와 같은 정형화된 프레임워크가 표준으로 자리잡게 되었다. 리액트는 단순 UI라이브러리가 아닌 반응성과 모듈화라는 철학을 중심으로 하는 시스템이며 이 철학 덕분에 웹/앱이 일관된 방식으로 개발되고 유지보수될 수 있었다. 반면, AI에이전트 개발에는 이런 공통된 철학이 아직 존재하지 않고 대부분 저수준 구성 요소들을 직접 다루며 시행착오를 반복하고 있다.

 

OpenAI의 Swarm이나 Microsoft의 Autogen에서 사용되는 Multi-agent 구조는 다음과 같은 문제들이 있다.

 

 

컨텍스트 공유 부족	에이전트 간 정보 공유가 제한되어 작업 불일치 발생
결정 충돌	각 에이전트가 독립적으로 판단해 논리적 충돌 가능
결합 어려움	최종 결과 통합 시 일관성 없는 결과물 생성 위험
오버헤드	통신과 조율에 과도한 비용 발생, 신뢰성 확보 어려움

 

 

 

예를 들어, 간단한 플래피버드 게임을 만드는 작업에서

• Subagent 1은 배경을 만들고
• Subagent 2는 주인공 캐릭터를 생성

Agent 1이 슈퍼마리오 스타일 배경을 만들었는데, Agent 2는 사실적인 3D 조류 캐릭터를 만든다면, 이 둘을 하나의 게임으로 통합하는 것은 부자연스럽고 부조화가 클 것이다. 모든 에이전트가 공통된 스타일 가이드를 이해하고, 서로의 작업 결과를 인식할 수 있어야만 이런 불일치를 줄일 수 있다.

 

 

 

이를 해결하기 위한 한 가지 접근은 왼쪽 그림처럼 처음 주어진 Task prompt를 모든 에이전트의 중심 문맥으로 고정시키는 것이다. 예를 들어 최초 지시를 모든 sub-agent의 시스템 프롬프트나 메모리로 주입한다. 하지만 이 방식은 병렬성과 확장성의 장점을 포기하게 만든다. 에이전트들이 공통된 컨텍스트를 유지해야 하기 때문에 각 에이전트는 선형 순차적 실행 구조로 설계해야 하고 이는 전체 작업 흐름을 비효율적으로 만든다. 또한 복잡한 멀티턴 작업에서는 단순히 “처음 지시만 기억하고 있으면 충분한가?”라는 문제가 생긴다. 중간중간 생긴 새로운 제약 조건, tool응답의 해석, 사용자 피드백 등은 모두 최초 지시만으로는 설명되지 않는 문맥의 변화를 가져온다. 또 Context overflow문제도 고려해야 한다.

 

그러면 오른쪽 그림처럼 이전 대화나 여러 작업에 대한 기록을 요약하여 하위 에이전트에게 전달하는 방법이 있다. 이는 Context overflow 문제를 해결하면서도 동시에 일정 수준의 병렬처리도 가능할 수 있다. 하지만 결정적으로 어려운 점은 무엇이 중요한 정보이며 이를 어떻게 정의할 것인가에 대한 문제와 요약 자체의 품질 문제가 여전히 존재한다.

 

 

Plan-and-Act: Improving Planning of Agents for Long-Horizon Tasks

 

 

Link : https://arxiv.org/abs/2503.09572

 

 

Multi-agent 구조의 문제를 갖지 않으면서도 효율적인 Agentic system 구조를 찾다가 Plan-and-act라는 논문을 발견하게 되었다. 이 논문은 복잡한 멀티 에이전트 구조 없이도 간단한 2단계 구조(PLANNER + EXECUTOR)로 에이전틱 시스템을 효과적으로 구현한 논문이다.

 

fundamental challenge “Planning : query to action and execute”

 

1. 고수준 목표를 구체적이고 실행 가능한 단계로 잘게 나누는 데 어려움
   “뉴욕행 비행기를 예약해줘” → “항공사 웹사이트 열기”, “여행 날짜 입력하기” …
   
2. complex and long-horizon task 에서 일관된 전략을 유지하기 어려움
   “무엇을 이미 했고, 앞으로 무엇을 해야하는지”
   
3. real-environment is dynamic and unpredictable
   에이전트는 계속해서 계획을 수정해야 함
4. planning strategies에 대한 고품질 데이터 부족

 

 

이전 연구들의 Agentic system은 크게 두 가지 프레임워크로 나눌 수 있다고 한다.

먼저 ReAct 기반 방법들은 사용자의 쿼리를 일련의 action으로 매핑하는 단일 모델 방식이며, LLMCompiler기반은 Planner와 Executor가 나누어져 있다. plan-and-act는 LLMCompiler 구조를 채택한다.

 

• PLANNER: 사용자 목표를 달성하기 위한 고수준 계획을 생성
• EXECUTOR: 생성된 계획을 실제 환경에 맞는 구체적인 행동으로 변환

 

 

 

Plan-and-act는 기존에 Planner-executor 구조에 다음과 같은 기법들을 추가하여 effective & scalable solutions를 제안하였다.

 

• Planner 학습을 위한 synthetic data generation pipeline 제안
• Planner, Executor fine-tuning 학습 방법 도입
• 중간에 계획을 수정하는 Dynamic Replanning 기법으로 문맥 유지력 향상

 

Dynamic Replanning

 

Static planning은 처음 수립한 계획을 실행 과정 내내 고정적으로 따르는 방식이다. 이 방식은 구조가 단순하고 추적이 쉽다는 장점이 있지만, 환경 변화나 예상치 못한 상황에 취약하다. 초기 계획 시점에 알 수 없었던 정보나 조건이 생겼을 때도 계획을 수정하지 않고 그대로 진행하기 때문에 실패 확률이 높다. 예를 들어 검색 결과가 없더라도 기존 계획대로 계속 탐색을 시도하거나 도구 호출실패에도 다음 단계를 무작정 수행해버릴 수 있다.

 

Dynamic replanning은 각 실행 단계(step) 이후 Planner가 현재 상태를 반영해 새로운 계획을 수립하는 방식이다. 단순히 초기 계획만을 따르지 않고 현재 상태와 이전 계획, 그리고 수행된 이전 action들을 종합해 다음 단계를 결정한다. 이는 다음과 같은 특징을 갖는다:

 

 

• 문맥(context)이 유지된다
  중간에 알게 된 정보를 계획에 반영하며, 이전 상태를 단절하지 않는다.
• 명시적인 메모리 없이도 장기 작업에서의 기억 문제가 줄어든다
  Planner가 중요 정보를 반복적으로 반영하면서 암묵적인 기억처럼 기능할 수 있다.
• 예외 상황 대응력이 높다
  예상치 못한 오류나 실패에도, 시스템이 그에 맞게 다음 단계를 수정하며 진행한다.

 

또한 이 구조는 제어실 역할을 하는 Planner (고수준 추론과 전략적 의사결정 담당)과 Executor (실제 환경과 상호작용하며 Planner의 행동을 구체적 행동으로 변환)를 분리하는 시스템 아키텍처 측면에서도 유리하다.

 

 

예시

 

Static Planning

• 사용자 입력: CMU 도서관 검색
• 계획: 검색 → 결과 확인 → 길찾기 실행 → 출발지/목적지 설정 → 도보 시간 분석
• 문제: 검색 결과 없음 → 계획 변경 없이 실패한 흐름 지속

 

Dynamic Replanning

• 사용자 입력: CMU 도서관 검색
• 결과: "결과 없음" 표시
• 재계획:
  1. 검색어를 "CMU 근처 도서관"으로 수정
  2. 검색 결과 재분석
  3. 도보 거리 계산
  4. 가장 가까운 도서관을 선택하여 결과 제공

 

 

Synthetic Data Generation

 

웹 기반 장기 작업(long-horizon web tasks)에 특화된 Plan-and-Act 에이전트를 구축하려 할 때, 기존 LLM들이 갖는 한계는 명확하다. 단순한 프롬프트 엔지니어링으로는 해결되지 않는다. 성능을 높이기 위해서는 구조적인 변화가 필요하고, 그 중 하나가 합성 데이터(synthetic data)를 통한 파인튜닝이다.

 

WebArena-Lite는 웹 탐색 및 작업 수행 능력을 평가하기 위한 벤치마크다. 이 데이터셋으로 시중의 오픈소스 LLM들을 평가한 결과, 기본 성공률은 9.85%에 그쳤다. 여기에 Plan-and-Act 방식을 적용하자 14.21%까지 향상되었고 한다. 하지만 여전히 낮은 수치이며, 모델은 복잡한 질의에 대해 일관된 행동을 내리지 못한다. 이에 대한 이유는:

 

• 기존 LLM은 프리트레이닝 중에 웹 환경에서의 장기 계획(long-horizon planning)을 학습한 적이 없음
• HTML 상태와 사용자 명령어를 받아 구체적인 웹 행동(action)을 생성하는 구조로 학습된 적도 없음

 

즉, 프롬프트 최적화나 인컨텍스트 예시 추가 같은 접근은 단순 질의에는 효과가 있을 수 있지만, 복잡한 작업이나 에이전트 시스템에 바로 적용하는 데에 한계가 있다

 

성능을 높이기 위한 접근은 구조적 분리와 역할에 맞는 학습 데이터 생성이다. Plan-and-Act 구조에서는 두 개의 주요 컴포넌트가 있다:

• Planner: 사용자 질의로부터 단계별 계획(plan breakdown)을 생성
• Executor: 각 계획 단계에 따라 HTML 상태를 받아 구체적인 행동(action)을 수행

 

이 구조에 맞게 데이터를 생성한다:

• Planner용 데이터: 사용자 질의 + 단계별 계획
• Executor용 데이터: HTML 입력 상태 + 해당 단계의 행동 출력

이런 synthetic data를 기반으로 두 모듈을 파인튜닝하면, 단순한 예시 주입보다 훨씬 강력한 계획-실행 연계 능력을 학습할 수 있다.

 

 

 

1. EXECUTOR training data

 

 

 

먼저 EXECUTOR를 학습시키기 위한 데이터는 다양한 trajectories(state and action sequences)를 수집하는 것이다. 웹 환경 내에서 action 데이터를 수집하기 위한 방법은 다음과 같다.

 

• 사용자 질의를 무작위 샘플링하고, 이를 시드 프롬프트로 사용해 LLM이 유사 질의를 생성한다.
• 생성된 질의 중 웹 에이전트가 처리할 수 없는 항목은 LLM을 통해 필터링한다.
• 유효한 질의는 demonstrator agent가 환경에서 수행하고, trajectory)를 기록한다.
• 수집된 traj는 Outcome-supervised Reward Model (ORM)을 통해 성공/실패 여부가 자동 평가된다.

 

 

 

ORM은 LLM이 생성한 action traj가 실제로 사용자 목적을 제대로 달성했는 지 평가하는 판별기이다. Plan-and-act 에서는 학습에 사용할 traj를 자동으로 걸러내기 위한 필수적인 컴포넌트가 된다. LLM이 생성한 queries를 실제 시뮬레이터를 적용하고 결과를 출력하여 합성 데이터를 생성하는 데 이 과정에서 LLM은 수많은 traj를 만들어낸다. ORM은 많은 데이터 중 실패 사례를 자동으로 추출하는 역할을 한다. 

 

ORM은 WebRL이라는 이전 연구에서 사용된 방법인데 SFT 기반으로 학습된다. 학습데이터는 query-action-output 결과 쌍과 그것이 성공인지 실패인지에 대한 레이블로 구성된다. 이 레이블은 사람 또는 고성능 모델이 생성하고 입력 시퀀스는 텍스트 임베딩 후 binary classifier로 학습된다. 

 

이러한 방식으로 고품질의 성공 traj를 자동 필터링할 수 있으며, 사용된 ORM은 WebRL 논문에서 제안된 LLaMA-3.1-8B 기반 모델이다. 사람이 직접 평가하지 않아도 충분한 정확도를 확보할 수 있다.

 

 

 

2. Planner 데이터 생성

 

 

Planner는 사용자 질의에 대응하는 step-by-step 계획을 생성해야 한다. 하지만 LLM은 실제 환경의 DOM 구조, 버튼 위치, 시각적 배치 정보를 인식할 수 없기 때문에 정적 텍스트 기반으로는 정확한 계획 생성을 할 수 없다.

이를 해결하기 위해 trajectory 역설계(reverse engineering) 방식을 사용한다:

• 이미 수집된 traj를 LLM에 입력으로 주고,
• LLM이 이 궤적을 기반으로 현실과 정렬된 고수준 계획을 재구성하게 한다.
• 각 step은 해당 행동들과의 매핑 관계도 포함하며,
• 실행 가능한 grounded plan으로서 유효성을 갖는다.

 

 

3. Dynamic Replanning 데이터 생성

 

웹 상호작용 중에는 종종 예상치 못한 상태 변화나 실패 상황이 발생한다. 이를 처리하기 위해 동적 재계획 데이터도 별도로 생성한다.

• 입력: 원래 질의, HTML 상태, 지금까지의 행동들(prev actions), 정답 행동 시퀀스(future actions)
• 출력: 수정된 고수준 계획 (step-by-step plan)

이 방식은 실행 중 상황 변화에 따라 계획을 재작성할 수 있는 능력을 모델에 학습시킨다.

 

 

4. CoT 데이터 생성

 

(PLANNER CoT data)
## Step 1  
Reasoning: 검색창이 있고, 사용자가 찾고자 하는 장소가 명확하지 않으므로 검색이 필요하다.  
Step: 'Library near CMU'를 검색한다.

(EXECUTOR CoT data)
Reasoning: 이전 단계에서 'Contributors' 링크를 찾았고, 상단에 해당 링크가 id=13인 요소에 있음  
Action: do(action="Click", element="13")

 

PLANNER와 EXECUTOR 모두에 대해 추론 과정(reasoning)을 명시한 CoT 데이터를 생성한다.

• Plan Reasoning Generation:
  사용자 질의 + 초기 HTML + plan → 각 step에 대한 **이유(reasoning)**와 의도된 행동을 출력
• Action Reasoning Generation:
  현재 step + 이전 행동들 + 현재 HTML + 정답 행동 → 행동의 이유와 action do 명령을 생성

 

이러한 reasoning trace는 다음과 같은 이점을 갖는다:

• 행동 일관성과 정확도 향상
• 디버깅 및 분석 용이
• 소량 데이터로도 일반화 가능

사용된 teacher LLM은 DeepSeek-R1-Distill-Llama-70B 모델이다. 이 모델은 안정적으로 CoT 출력을 생성하며 실제 실험에서 성능 향상 효과가 입증되었다.

 

 

5. Plan Data Expansion & Targeted Plan Augmentation (Adaptive curriculum learning)

 

 

Planner 데이터 수급 불균형 문제 : 실행 궤적 수집 기반 방식은 성공 traj 확보에 많은 시간이 걸린다. Executor 데이터는 하나의 traj에서 여러 개 생성 가능하지만, Planner는 평균적으로 1개만 생성되며 데이터 수급 불균형이 발생한다.

이를 해결하기 위해 두 가지 확장 전략을 도입했다.

 

5.1 Plan Data Expansion

기존 query-plan 쌍을 기반으로 유사 계획을 다수 생성한다. LLM이 조건을 바꾸거나 단계 수를 변형해 다양한 변형 샘플을 생성한다.

 

5.2 Targeted Plan Augmentation (Adaptive Curriculum Learning)

• 모델을 검증 세트에 실행하여 자주 실패하는 유형을 분석한다.
• 해당 유형과 관련된 훈련 데이터를 LLM이 분류 및 증식한다.
• 분류된 시드 데이터로부터 유사 계획을 5,000개 이상 추가 생성한다.

이 방식은 모델의 취약점을 중심으로 데이터를 구성하는 적응형 학습 커리큘럼이며, 학습 효과를 극대화할 수 있다.

 

* Adaptive curriculum learning : 모델이 쉬운 문제부터 어려운 문제로 점진적으로 학습하도록 구성하는 전략. 여기서는 단순히 쉬운 → 어려운 흐름이 아니라 모델이 어떤 유형의 문제를 잘 못푸는지 보고 해당 실패 유형과 관련된 데이터를 의도적으로 더 많이 생성해 추가학습 시킨다.

 

[1] 실패 유형 정의 (Failure Class 분류)

먼저 웹사이트 또는 작업 유형별로 자주 발생하는 실패 유형을 정의

예:

• Class A: 너무 구체적인 검색어 사용 → 검색 실패
• Class B: 잘못된 경로로 UI 요소 접근 → 동작 실패
• Class C: 계획에 필요한 중간 단계 생략

이러한 분류는 수작업 분석 또는 로그 기반 자동 분석으로 생성할 수 있다.

 

[2] 기존 학습 데이터와 실패 유형 매핑

LLM 또는 휴리스틱 규칙을 사용해 기존 학습 샘플들이 어떤 실패 유형과 관련 있는지 분류

예:

• "상품명에 'tank'가 들어간 고객 불만 리뷰를 찾아 요약하라" → Class A
• "재고를 삭제하라" + 잘못된 UI 경로 사용 → Class B

이렇게 각 예시는 실패 유형에 따라 라벨링된다.

 

[3] 시드 기반 유사 질의 및 계획 생성

각 실패 유형에 해당하는 기존 예시를 시드(seed)로 사용하여 LLM이 유사한 질의 및 계획 쌍을 생성

예:

• 원본: "상품명에 'Hollister'가 포함된 제품을 할인 처리해줘"
• 생성: "이름에 'Oakley'가 들어간 재고를 품절 상태로 바꿔줘"

이처럼 실패 유형의 다양한 표현, 조건, 맥락을 가진 버전을 생성하여 모델이 유사한 실패를 반복적으로 학습하게 한다.

 

 

 

 

Experiments

 

 

WebArena-Lite는 실제 웹사이트 기반의 환경에서 웹 내비게이션 및 작업 수행 능력을 평가하는 고난이도 벤치마크이다. 사용자는 자연어 질의를 입력하고, 에이전트는 HTML 구조를 기반으로 웹 페이지를 분석하고, 클릭/검색/입력 등의 행동을 통해 정답 상태에 도달해야 한다.

• 단순 버튼 클릭에서 조건 필터링, 동적 UI 탐색, 정보 추출 등 복합적인 작업이 포함된다.
• 메트릭은 작업 단위 성공/실패로, 완전히 완료하면 1점, 실패하면 0점이다.
• 다양한 도메인이 포함된다:
  • GitLab 환경: 이슈/커밋 확인, 기여도 높은 저장소 탐색
  • 쇼핑몰 관리자: 상품 목록 조회, 특정 조건 제품 할인 적용
  • OpenStreetMap: 장소 검색, 도보 경로 탐색, 거리 비교 등

 

Baselines

 

1. No-Planner (ReAct 스타일)

• 단일 LLM이 고수준 reasoning과 실행을 모두 처리하는 구조
• 별도의 Planner 없이 직접 action을 생성
• 대부분 GPT 계열 모델은 이 구조를 사용
• 일반적인 zero-shot 또는 few-shot prompting만으로 수행
• 환경 적응 학습이 없어 정확도 낮음

 

2. AWM (Agent Workflow Memory)

• GPT-4 기반의 상태 추적 강화 에이전트
• 명시적인 memory stack을 사용하여 웹 상호작용 상태를 유지
• 단일 모델로서 실행되나, 다중 문맥 인식 능력이 강화됨

 

3.  WebPilot

• 총 6개의 sub-agent로 구성된 멀티에이전트 기반 탐색 시스템
• 도구 선택과 API 탐색에 특화되어 있음
• 복잡한 구조지만, 플래너 구조는 명시적이지 않음

 

4.  WebRL

• WebArena-Lite의 기존 SOTA
• RL 기반의 커리큘럼 학습을 사용
• 에이전트가 스스로 사용자 질의를 생성하고 (예: “100달러 이하의 노트북을 찾아줘”) trial & error 과정을 통해 성공 traj를 수집
• 성공한 traj를 기반으로 LLM fine-tuning 또는 policy 업데이트 수행
• 점진적으로 쉬운 태스크 → 복잡한 태스크로 확장

 

Plan-and-Act 모델 성능

+ Finetuning	합성 데이터 기반 파인튜닝 적용
+ Synthetic Trajectories	실행된 행동 시퀀스를 활용한 traj 기반 학습
+ Plan Expansion	단일 질의-계획 쌍에서 유사 계획 여러 개 생성
+ Targeted Augmentation	실패 유형 중심 커리큘럼 데이터 생성
+ Dynamic Replanning	Executor 행동 이후 Planner가 매번 계획을 갱신
+ CoT Reasoning	Planner와 Executor 모두에 reasoning trace 포함

 

 

기본적인 오픈소스 LLM은 WebArena-Lite에서 약 9.85%의 성공률을 기록했다. Plan-and-Act는 위 구성 요소를 단계적으로 추가하면서 성능이 꾸준히 향상되었고, 최종 모델은 기존 SOTA였던 WebRL을 뛰어넘는 정확도를 달성했다. 특히 CoT reasoning과 Dynamic Replanning을 포함한 최종 구성은 복잡한 다단계 질의에 대해 안정적으로 대응했다.

 

 

Conclusion & Limitations

 

+ 복잡한 Multi-agent 구조 없이도 간단한 2단계 구조(PLANNER + EXECUTOR)로 agentic system을 효과적으로 구현

+ 스케일링 가능한 합성 데이터 생성 파이프라인 제안

+ Dynamic replanning + CoT 도입

 

- 초기 trajectory 수집이 기존 Baseline성능에 의존함

- Dynamic replanning이 매 step마다 발생 (overhead)

- Web 환경 특화 구조