에이전트 planning은 단순히 더 오래 생각하는 기능이 아닙니다. ReAct 이후 흐름을 따라가 보면 planning은 작업 분해, 실행 분리, 결과 기반 재조정이라는 구조적 문제로 점점 선명해집니다.
이 글은 ReAct를 출발점으로 두고, 그 다음 planning 논의가 왜 decomposition, planner-executor separation, replanning, cost·latency trade-off 쪽으로 이동했는지 정리합니다.
먼저 결론: planning은 구조 문제다
- 긴 작업을 어떻게 하위 작업으로 나눌까
- 계획을 세우는 역할과 실행하는 역할을 왜 분리할까
- 도구 결과가 나오면 언제 다시 계획을 고쳐야 할까
- 늘어나는 비용과 지연을 감수할 가치가 있을까
ReAct가 보여준 것은 생각과 행동을 번갈아 연결하는 루프였습니다. 그 다음 단계에서 planning 논의가 커진 이유는, 루프가 있다는 사실만으로는 긴 작업의 단계 누락과 순서 문제를 막기 어렵기 때문입니다.
즉 planning은 reasoning의 장식이 아니라, 긴 작업을 다루기 위한 제어 구조로 읽는 편이 더 정확합니다.
ReAct가 출발점인 이유
ReAct 논문은 reasoning과 acting을 한 루프로 묶으면서 에이전트 연구의 중요한 전환점을 만들었습니다. 생각만 하면 환각과 오류 전파가 커질 수 있고, 행동만 하면 왜 그 행동을 하는지 기준이 약해질 수 있다는 점을 같이 보여줬기 때문입니다.
논문을 실무적으로 번역하면, 모델은 중간 추론으로 다음 행동의 방향을 잡고 실제 action은 외부 정보원과 상호작용해 답을 현실에 붙잡아 둡니다. 이 지점부터 순서, 검증, 예외 처리 문제가 본격적으로 등장합니다.
그래서 ReAct는 planning의 완성형이라기보다, planning이 왜 필요한지 보여주는 출발점에 더 가깝습니다.
왜 decomposition이 중요해졌을까
ReAct만으로도 생각과 행동의 교차는 설명할 수 있습니다. 하지만 작업이 길어지면 무엇을 먼저 해야 하는지, 몇 단계로 나눠야 하는지, 중간 단계가 빠지지 않았는지, 도구를 어떤 순서로 호출해야 하는지가 여전히 불안정합니다.
Plan-and-Solve Prompting은 zero-shot chain-of-thought가 자주 내는 missing-step errors를 줄이기 위해 먼저 계획을 세우고 그 계획에 따라 subtasks를 수행하는 구성을 제안합니다.
핵심은 화려하지 않습니다. 좋은 planning은 정답을 한 번에 맞히는 마법이 아니라, 단계 누락을 줄이는 장치라는 점입니다.
planner-executor 분리가 필요한 이유
planning 논의가 더 발전하면 결국 역할 분리 문제로 들어갑니다. 무엇을 할지 정하는 일과 실제로 해보는 일을 한 모델 응답 안에 몰아넣을지, 아니면 구조적으로 나눌지가 핵심입니다.
- planner는 전체 목표를 읽고 지금 필요한 하위 작업을 고른다
- executor는 그 하위 작업을 실제로 수행한다
- 실행 결과가 돌아오면 planner가 다음 단계를 다시 정한다
이 구조의 장점은 더 똑똑한 한 번의 답을 기대하지 않아도 된다는 데 있습니다. 대신 계획 실패, 실행 실패, 도구 결과 해석 실패를 더 잘 구분할 수 있습니다.
실무적으로는 Anthropic의 orchestrator-workers 설명이 이 역할 분리를 운영 관점에서 잘 풀어줍니다. 다만 이 글에서는 그것을 논문 자체가 아니라 planning 논의를 실무 구조로 번역한 보조 자료로 사용합니다.
replanning이 핵심이 된 이유
planning을 처음 계획 문서처럼 이해하면 자주 오해하게 됩니다. 실제 에이전트에서 중요한 것은 처음 계획의 아름다움이 아니라, 실행 결과를 보고 다음 단계를 바꾸는 능력입니다.
특히 도구 호출이 끼는 순간부터는 모델 내부 추론보다 바깥의 결과가 더 강한 근거가 됩니다. 검색 결과가 비어 있거나, 테스트가 예상과 다르게 실패하거나, 외부 API 응답이 계획과 다르면 처음 계획을 그대로 밀어붙이는 쪽이 더 위험합니다.
그래서 좋은 planning은 처음부터 완벽한 경로를 쓰는 것이 아니라, ground truth를 계속 읽고 경로를 고치는 흐름으로 이해해야 합니다. 이 점이 ReAct의 action loop와도 자연스럽게 이어집니다.
논문 흐름을 실무로 옮기면
- 목표를 해석한다
- 작업을 하위 단위로 나눈다
- 각 단위를 실행 가능한 형태로 넘긴다
- 실행 결과를 읽는다
- 필요하면 계획을 수정한다
- 멈출 조건을 확인한다
이 구조는 ReAct, Plan-and-Solve, 그리고 실제 agent workflow 가이드가 만나는 지점입니다. 한쪽은 reasoning과 action의 연결을 보여줬고, 다른 쪽은 missing-step error를 줄이기 위한 explicit plan을 강조했으며, 실무 가이드는 이를 feedback loop와 orchestrator-workers 형태로 더 운영적으로 풀어냈습니다.
도구 연결 관점은 MCP 글, 상태 실패 관점은 tool use 실패 글과 함께 보면 더 잘 이어집니다.
planning이 항상 유리하지 않은 이유
- 계획을 세우는 호출이 추가된다
- 하위 작업 실행 호출이 늘어난다
- 중간 결과를 읽는 호출이 필요하다
- 재계획과 검토 호출이 붙을 수 있다
planning은 보통 성능을 얻는 대신 비용과 지연을 늘립니다. 그래서 정확도만 볼 것이 아니라 응답 시간 예산과 실패 비용을 함께 봐야 합니다.
짧은 질의응답이나 형식화된 변환 작업은 단일 호출이 더 나을 때가 많습니다. 반대로 긴 조사, 여러 도구 호출, 상태 변화, 예외 처리까지 들어오면 planning의 오버헤드를 감수할 이유가 생깁니다.
planning 실패 패턴
- 계획이 너무 커서 executor가 바로 움직이기 어렵다
- 겉보기에는 독립적이지만 실제로는 묶여 움직여야 하는 단계를 잘못 분해한다
- 도구 결과보다 처음 계획을 더 믿는다
- 작은 일에도 과한 오버헤드를 붙인다
planning을 다룬 논문과 사례를 읽을 때는 성공 구조만 보지 말고 실패 패턴도 같이 봐야 균형이 잡힙니다. 복잡성은 품질을 올릴 수도 있지만, 잘못 쓰면 새로운 실패 원인이 되기 때문입니다.
언제 planning 구조를 쓸까
- 이 작업은 단계 누락이 자주 나는가
- 외부 도구 결과를 중간에 다시 읽어야 하는가
- 하위 작업 수가 입력마다 달라지는가
- 실패하면 경로를 바꿔야 하는가
- 느려져도 괜찮을 만큼 실패 비용이 큰가
이 질문에 여러 개가 예라면 planning 구조가 유리할 가능성이 큽니다. 반대로 대부분이 아니오라면 좋은 단일 호출이나 짧은 workflow가 더 효율적일 수 있습니다.
정리
에이전트 논문에서 planning은 점점 더 구조적인 문제로 다뤄집니다. ReAct가 생각과 행동의 교차를 보여줬다면, 그 다음 단계에서는 작업 분해, 역할 분리, 결과 기반 재조정이 planning의 핵심 축으로 올라옵니다.
planning을 이해할 때 가장 중요한 질문은 얼마나 많이 생각하느냐가 아니라, 긴 작업을 더 작은 실행 단위로 쪼개고 실행 결과를 보고 다시 방향을 고칠 수 있느냐입니다.
공식·1차 자료는 ReAct 논문, Plan-and-Solve Prompting 논문, 그리고 실무 설계 보조 자료로 Anthropic의 Building effective agents를 참고했습니다.
