왜 플래닝 전략이 문제가 되는가
LLM 에이전트를 운영해보면 "어떤 순서로 도구를 부를지" 결정하는 방식이 비용과 안정성을 좌우한다는 걸 곧 알게 된다. 매 스텝마다 LLM에게 다음 행동을 물어보면 유연하지만 토큰이 폭증하고, 중간에 엉뚱한 길로 새면 되돌리기 어렵다. 반대로 처음에 계획을 확정해두면 예측 가능하지만 상황 변화에 둔감하다. 이 트레이드오프의 두 극단이 ReAct와 Plan-Execute다.
ReAct: 생각과 행동을 번갈아
ReAct는 Reasoning과 Acting을 한 루프 안에서 반복한다. 모델이 "생각 → 도구 호출 → 관찰 → 다시 생각"을 필요한 만큼 이어간다. 관찰 결과를 즉시 반영하므로 검색이나 탐색처럼 다음 행동이 이전 결과에 크게 의존하는 작업에 강하다.
while step < MAX_STEPS:
resp = llm.invoke(history) # Thought + Action 생성
if resp.tool_calls:
obs = run_tool(resp.tool_calls[0]) # 도구 실행
history += [resp, tool_msg(obs)] # Observation을 다시 주입
else:
return resp.content # 최종 답
step += 1
raise RuntimeError("스텝 한도 초과")
단점은 명확하다. 매 스텝이 전체 히스토리를 다시 읽으므로 토큰이 스텝 수의 제곱에 가깝게 늘고, 루프가 도구 호출을 무한 반복하는 사례가 흔하다. 그래서 MAX_STEPS 같은 하드 리밋은 선택이 아니라 필수다.
Plan-Execute: 먼저 계획, 나중에 실행
Plan-Execute는 강한 모델이 전체 계획을 한 번에 세우고, 각 단계는 저렴한 모델이나 고정 로직이 실행한다. 계획 수립과 실행이 분리되므로 관측성이 좋고, 실행 단계에서 큰 모델을 부르지 않아 비용이 안정적이다.
goal: "지난 분기 매출 상위 3개 지역 리포트 작성"
plan:
- step: fetch_sales
tool: sql_query
args: { period: "2026-Q2" }
- step: rank_regions
tool: aggregate
args: { by: region, top: 3 }
- step: write_report
tool: llm_summarize
depends_on: [rank_regions]
핵심 보완책은 replan이다. 한 단계가 예상과 다른 결과를 내면 계획 전체를 폐기하지 않고 남은 단계만 다시 세운다. replan 없는 Plan-Execute는 첫 계획이 틀리는 순간 그대로 실패한다.
두 방식 비교
| 항목 | ReAct | Plan-Execute |
|---|---|---|
| 적합 작업 | 탐색적·비결정적 | 구조화·다단계 |
| 토큰 비용 | 높음(스텝마다 추론) | 낮음(계획 1회) |
| 지연 변화 대응 | 즉각적 | replan 필요 |
| 디버깅 | 어려움(경로 매번 달라짐) | 쉬움(계획이 명시적) |
| 실패 모드 | 무한 루프 | 계획 경직 |
실무에서는 하이브리드로
양자택일보다 두 계층을 겹치는 편이 낫다. 바깥은 Plan-Execute로 골격을 잡고, "웹에서 근거를 찾아라" 같은 개별 단계 안에서만 ReAct 루프를 돌린다. 이렇게 하면 전체 흐름은 예측 가능하게 유지하면서 국소적 불확실성만 유연하게 흡수한다.
for step in plan.steps:
if step.tool == "research": # 불확실한 단계만 ReAct
result = react_loop(step.goal, max_steps=6)
else: # 결정적 단계는 그대로 실행
result = run_tool(step)
if not result.ok:
plan = replanner.revise(plan, step, result) # 실패 시 재계획
운영 시 주의점
세 가지를 미리 정해두어야 한다. 첫째, 스텝·토큰·시간 한도를 모두 걸어라. ReAct는 스텝, Plan-Execute는 replan 횟수에 상한이 필요하다. 둘째, 각 단계의 입력·출력·소요 토큰을 구조화 로그로 남겨야 실패를 재현할 수 있다. 셋째, 도구 호출을 신뢰하지 마라. 잘못된 인자나 존재하지 않는 도구를 부르는 경우를 대비해 스키마 검증과 재시도 정책을 실행 계층에 둔다.
정리하면, 작업이 탐색적이고 짧으면 ReAct, 단계가 명확하고 반복되면 Plan-Execute, 둘이 섞여 있으면 계층형 하이브리드가 기본값이다. 전략 선택보다 중요한 건 한도와 로깅이며, 이 둘이 없으면 어느 방식이든 프로덕션에서 통제 불능이 된다.