AI Agent Architecture에서 Planning이 중요해진 이유

AI Agent 아키텍처의 Planning 구조

---

 

 

 

최근 등장한 거의 모든 고급 에이전트 시스템을 관통하는 공통 키워드는 Planning이다.
Manus는 컨텍스트 엔지니어링의 핵심으로 Todo list를 활용한 Planning을 흡수했고, Claude는 Plan Mode와 Research 시스템을 통해 계획과 실행을 분리했다. Gemini Deep Research는 Research 전용 Planning 파이프라인을 공식 기능으로 도입했고, Open Deep Research와 Perplexity는 Plan-and-Execute를 서비스 수준에서 채택했다.

 

Planning은 “더 똑똑해지기 위해”가 아니라, “서비스 가능한 에이전트를 만들기 위해” 필연적으로 등장한 구조다.

이 글에서는 AI Agent에서 Planning이 왜 필요해졌는지, ReAct류의 자율 추론 방식과 무엇이 다른지, 그리고 실제 프로덕션 시스템에서 Planning이 어떤 형태로 구현되고 있는지를 하나의 흐름으로 정리한다.

 

 

 

ReAct가 보여준 가능성과 한계

---

 

초기 에이전트 연구에서 ReAct는 매우 강력한 개념이었다.
모델이 스스로 생각하고(Thought), 행동하고(Action), 관찰하고(Observation) 이를 반복하며 문제를 해결하는 방식은 인간 문제 해결 과정과 유사했고, 연구·추론·에세이 작성과 같은 열린 문제에서 특히 뛰어난 성능을 보였다.

그러나 ReAct는 두 가지 치명적인 문제를 안고 있다.

 

1. 첫째, 실행 경로가 사전에 예측되지 않는다.
   LLM의 추론 궤적(reasoning trajectory)은 입력마다, 심지어 동일 입력에서도 달라질 수 있다.
   이는 곧 쿼리당 소요 시간, 토큰 수, 도구 호출 횟수가 안정적으로 예측되지 않는다는 의미다.
   
   
2. 둘째, 비용과 안정성이 스케일하지 않는다.
   ReAct 에이전트는 작은 실험 환경에서는 훌륭하지만, 수십만·수백만 사용자를 상대하는 서비스 환경에서는 치명적이다.
   쿼리 하나가 언제 끝날지 알 수 없고, 언제 폭주할지 알 수 없는 시스템은 SLA를 보장할 수 없다.

 

 이처럼 reasoning trajectory를 예측할 수 없는 구조는 대규모 워크로드에 적합하지 않다.

“얼마나 똑똑한가”보다 “얼마나 예측 가능한가”가 더 중요해지는 순간, ReAct는 한계에 부딪힌다.

 

 

 

Planning Agent의 핵심 동기

---

 

Planning이 도입된 가장 큰 이유는 에이전트를 더 똑똑하게 만들기 위함이 아니다. 오히려 그 반대에 가깝다.

Planning은 에이전트의 자율성을 제한하기 위한 구조다.

여러 시스템에서 반복적으로 등장하는 Planning의 동기를 요약하면 다음과 같다.

 

첫째, 실행 경로를 사전에 고정하기 위해
Perplexity는 사용자의 질의를 받은 뒤, 즉시 여러 개의 서브 태스크로 구성된 계획을 먼저 세운다.
이 계획은 “무엇을 언제 어떤 순서로 실행할지”를 명시하며, 이후 실행은 이 계획을 그대로 따라간다.

이는 reasoning을 없애기 위함이 아니라, reasoning을 한 번으로 몰아넣기 위함이다.
즉, 매 스텝마다 생각하지 않고, 처음에만 생각한다.

 

둘째, 비용을 통제하기 위해
Plan-and-Execute 구조에서는 플래너가 한 번만 고급 추론을 수행한다.
이후의 실행 단계는 저비용 모델, 도메인 특화 모델, 혹은 단순한 도구 호출로 대체될 수 있다.

ReAct가 “생각 → 행동 → 생각 → 행동”을 반복하며 비용을 누적시키는 구조라면,
Planning 기반 시스템은 “한 번 생각 → 많이 실행”하는 구조다.

 

셋째, 대규모 서비스에서 안정성을 확보하기 위해
Claude Research, Gemini Deep Research, Perplexity 모두 공통적으로 “얼마나 많은 단계가 필요한지”를 예측 가능하게 만든다. 이는 단순한 성능 문제가 아니라, 사용자 경험과 운영 안정성의 문제와 연결된다.

 

 

 

 

Planning은 전체 아키텍처의 형태로 흡수되고 있다

---

중요한 점은 Planning이 더 이상 하나의 독립된 Stage가 아니라는 것이다.
최신 에이전트 시스템에서 Planning은 전체 아키텍처의 형태로 흡수되고 있다.

즉, Planning은 더 이상 전처리 단계가 아니라, 에이전트가 어떻게 기억하고, 어떻게 실행하며, 어떻게 길을 잃지 않는지를 규정하는 아키텍처 그 자체가 된다.

 

 

Manus

---

Manus의 Todo list 전략. Context 끝에 자신의 목표를 recite하여 중간에서 길을 잃지 않도록 한다.

 

Manus 사례를 보면, Planning은 명시적인 plan 문서로 존재하지 않는다.
대신 에이전트는 작업을 시작할 때 todo.md 파일을 생성하고, 작업이 진행됨에 따라 이 파일을 지속적으로 갱신한다.

Task를 진행하면서 완료된 항목은 체크되고, 남은 항목은 다시 수행된다.

 

이 전략의 핵심은 목표를 “저장”하는 것이 아니라 “낭송(recitation)”하는 데 있다.
Manus는 매 스텝마다 자신의 목표를 다시 쓰고, 다시 읽는다.

그 결과 전체 계획이 항상 모델의 최근 어텐션 범위 안에 위치하게 된다.

긴 루프를 도는 동안 초기 목표가 희석되거나, 중간 관찰에 끌려 표류하는 문제를 자연어 수준에서 해결하는 방식이다.

 

이는 명시적인 Planner 모듈 없이도, 컨텍스트 배치와 파일 갱신이라는 수단을 통해 Planning을 구현한 사례다.

Planning이 문서가 아니라, Plan을 Context 끝부분에 계속 위치시키기 위한 어텐션 조작으로 구현된 셈이다.

 

 

 

Anthropic Claude Code

---

Claude Plan Mode에서는

 

 

Claude Plan Mode에서는 Planning이 보다 제도적인 형태를 띤다.
여기서는 Planning과 Execution이 시스템 차원에서 강제로 분리된다.

Plan Mode에 들어가면 Claude는 파일을 수정하거나 명령을 실행할 수 없고, 오직 계획만을 생성한다.

이 계획은 plan.md라는 명시적인 산출물로 남으며, 작업 분해, 의존성, 실행 순서가 구조화된 형태로 기록된다.

 

중요한 점은, 이 계획이 단순한 참고용이 아니라는 것이다. 사용자는 실행 전에 이 plan.md를 검토하고 수정할 수 있으며, 승인된 계획만이 이후 실행의 기준이 된다. 즉, Planning은 내부 추론이 아니라 외부 검증 가능한 아티팩트가 된다.

여기서 Planning은 “모델이 생각한 내용”이 아니라, “시스템이 따라야 할 제약”에 가깝다.

 

 

 

Google Gemini Deep Research

---

 

 

Gemini Deep Research에서는 Planning이 조사 파이프라인 전체를 규정하는 상위 구조로 확장된다.
사용자가 입력한 프롬프트는 곧바로 검색으로 이어지지 않는다.

먼저 Research Plan으로 변환되며, 이 Plan에는 어떤 관점에서, 어떤 축으로, 어떤 순서로 조사를 진행할지가 포함된다.

이후 검색, 추론, 보고 단계는 이 계획을 기준으로 수행된다.

 

더 중요한 것은, 이 계획이 고정되지 않는다는 점이다.

Deep Research는 각 단계에서 수집된 정보를 바탕으로 누락된 정보나 불일치를 감지하고, 필요하면 계획을 갱신한다.

즉, Planning은 일회성 사전 설계가 아니라, 실행 중에도 지속적으로 유지·갱신되는 상태다.

이 경우 Planning은 자연어 출력이 아니라 실행 가능한 그래프다.

즉, Planning은 “계획을 생성한다”기보다, “시스템을 계획형으로 만든다”는 의미에 가깝다.

 

 

Planning은 곧 Delegation Specifiction으로 이어진다

---

 

Planning은 아키텍처에서 Sub Agent로의 Task Delegation으로 이어진다.
Anthropic의 Multi-Agent Research 시스템에서 이 점은 매우 명확하게 드러난다.

이 시스템에서 주 Agent의 역할은 단순히 전체 답변을 잘 쓰는 것이 아니다.

주 Agent는 먼저 사용자의 질의를 해석하고, Research 전략을 수립한 뒤, 이를 여러 개의 Sub Task로 분해한다.

그리고 각 Sub Agent에게 단순한 요청이 아니라, 매우 구체적인 Task specification을 전달한다.

이 Specification에는 최소한 네 가지가 포함된다.

1. 해당 서브에이전트가 달성해야 할 목표
2. 결과를 어떤 형식으로 반환해야 하는지에 대한 출력 규격
3. 사용할 수 있는 도구와 우선해야 할 정보 출처
4. 넷째, 작업의 범위와 경계, 즉 어디까지 조사하고 어디서 멈춰야 하는지

 

결국 AI Agent 아키텍처에서 Planning은 더 이상 선택적 기능이 아니다.
Planning은 자율 추론을 대체하기 위한 장치가 아니라, 자율성을 서비스 가능한 형태로 제약하기 위한 구조적 해법이다.
Manus, Claude, Gemini, Perplexity, Open Deep Research는 서로 다른 구현을 택했지만, 모두 “Agent는 먼저 Planning을 수행한다”는 결론에 도달했다. 앞으로의 Agent 설계에서 경쟁력의 핵심은 모델의 지능이 아니라, Planning을 어떻게 아키텍처로 흡수하느냐에 달려 있다.