CH06-스스로 길을 그리는 AI — 플래닝(Planning) 패턴 완벽 정리

AGENTIC AI DESIGN PATTERNS · 06

스스로 길을 그리는 AI — 플래닝(Planning) 패턴 완벽 정리

반응형을 넘어 목표를 스스로 단계로 쪼개는 법 — Plan-and-Execute 아키텍처, 적응적 재계획, LangGraph·CrewAI·Google ADK 3프레임워크, Deep Research, CRM·ERP·Groupware 적용까지

🟢 입문~중급⏱️ 약 20분🧭 LangGraph·CrewAI·ADK🏢 엔터프라이즈

TL;DR — 플래닝(Planning)은 에이전트가 복잡한 목표를 실행 가능한 단계의 시퀀스로 스스로 분해하는 패턴입니다. 핵심 질문은 하나 — “방법(HOW)이 이미 알려져 있는가?” 알려져 있으면 고정 워크플로우(Task Execution), 모르면 플래닝입니다. 구조는 Plan-and-Execute — Planner(목표→계획) → Executor(단계 실행) → Replanner(평가→계속/완료). 진짜 힘은 적응성에 있습니다. 계획은 고정 스크립트가 아니라 시작점일 뿐, 실패하면 재계획(Replanning)하죠 — “에이전트는 실패하지 않고 적응한다.” LangGraph(StateGraph)·CrewAI(planning=True)·Google ADK(Sequential/Parallel/Loop)로 구현하고, 킬러 앱은 Deep Research입니다. 엔터프라이즈(CRM·ERP·Groupware)에 적용하면 연간 순효과 $840K·ROI 280% — 단, Human-in-the-Loop(HITL)과 롤백 전략이 필수입니다.

목 차

1. 왜 플래닝인가2. Planning vs 작업 실행3. 적응성과 재계획4. Plan-and-Execute5. LangGraph6. CrewAI7. Google ADK8. 프레임워크 비교9. Deep Research10. 엔터프라이즈11. 케이스 & 안전장치12. 베스트 프랙티스

1. 왜 플래닝인가 — 도구를 줬는데 순서를 모른다

앞선 다섯 편을 빠르게 되짚어 봅시다. 1편 프롬프트 체이닝은 작업을 순서대로 쪼갰고, 2편 라우팅은 입력에 따라 길을 나눴으며, 3편 병렬화는 독립 작업을 동시에 던졌고, 4편 리플렉션은 쓴 결과를 다시 읽고 고쳤습니다. 그리고 5편 도구 사용은 LLM에게 손과 발을 달아 바깥세상과 연결했죠. 그런데 여기서 결정적인 질문이 하나 남습니다 — “도구를 줬는데, 그걸 언제·어떤 순서로 쓸지는 누가 정하지?”

사용자가 “신규 직원 온보딩 끝내줘” 한마디를 던졌다고 합시다. 여기엔 정답 레시피가 없습니다. 계정을 먼저 만들지 권한부터 줄지, 장비는 언제 신청하고 교육은 어느 시점에 배정할지 — 목표(WHAT)는 명확하지만 방법(HOW)은 비어 있습니다. 플래닝은 바로 이 빈칸을 에이전트가 스스로 채우게 하는 패턴입니다. 형식적으로는 초기 상태(Initial State)에서 목표 상태(Goal State)까지 도달하는 행동의 시퀀스를 자율적으로 설계하는 것이죠.

🔁 반응형(Reactive) — 단일 행동

입력 → LLM → 한 번의 응답(끝)

“지금 무엇을 답할까?”만 판단

다단계 의존성·장기 목표엔 취약

🧭 플래닝(Planning) — 목표 지향

목표 → 단계로 분해 → 실행 → 평가

“목표까지 어떤 순서로 갈까?”를 설계

실패 시 재계획으로 적응

그림 1. 한 번 답하고 끝나는 반응형과, 목표를 단계로 쪼개 끝까지 끌고 가는 플래닝

비유하자면 이렇습니다. 레시피를 그대로 따라 하는 건 요리(실행)지만, “냉장고 재료로 손님 4명 코스를 차려줘”는 메뉴를 먼저 짜는 일(계획)입니다. 재료를 확인하고, 코스 순서를 정하고, 조리 시간을 역산하고, 빠진 재료가 있으면 대체하죠. 플래닝 에이전트가 하는 일이 정확히 이것 — 생각(Reasoning)을 행동의 청사진으로 바꾸는 것입니다.

💡

지금 기업들이 주목하는 이유. 사내 업무의 대부분은 “여러 시스템을 넘나드는 다단계 프로세스”입니다. 온보딩·주문 처리·결재·정산은 모두 순서와 의존성이 있는 절차죠. 기존 RPA는 이걸 사람이 일일이 규칙으로 박아 넣어야 했지만, 플래닝은 목표만 주면 절차를 스스로 설계하고, 예외가 터지면 스스로 고쳐 갑니다. 자동화가 “규칙”에서 “목표”로 올라서는 전환점입니다.

2. Planning vs 작업 실행 — 단 하나의 질문

모든 작업에 플래닝이 필요한 건 아닙니다. 오히려 대부분의 작업엔 과합니다. 플래닝을 쓸지 말지는 단 하나의 질문으로 갈립니다 — “방법(HOW)이 이미 알려져 있는가?” 답이 “예”면 굳이 계획을 세울 필요 없이 정해진 절차를 실행(Task Execution)하면 되고, “아니오”면 방법을 발견(Planning)해야 합니다.

❓ “HOW(방법)가 이미 정의되어 있는가?”

YES → 작업 실행

고정 워크플로우 · RPA

✅ 예측 가능한 결과

⚡ 빠른 실행 속도

🛡️ 낮은 위험성

NO → 플래닝 에이전트

동적 계획 수립

🔄 적응적 실행

🧩 복잡한 문제 해결

🆕 새로운 정보 반영

그림 2. “방법을 아는가?” 하나로 갈리는 두 갈래 — 아는 길은 실행, 모르는 길은 계획

이 차이를 기존 RPA/규칙 기반 자동화와 견주면 더 선명해집니다. RPA는 IF 불만유형=배송지연 THEN 사과메시지 발송처럼 모든 분기를 사람이 미리 정의해야 합니다. 정의되지 않은 상황이 오면 그대로 멈춥니다. 플래닝은 “VIP 불만을 해결하라”는 목표를 받아 고객 특성·이력·불만 유형을 고려해 해결 계획을 그때그때 생성합니다.

항목	기존 RPA / 워크플로우	Planning Pattern
유연성	낮음	높음
예외 처리	수동 정의	자동 적응
복잡한 작업	제한적	우수
유지보수	규칙 업데이트	자가 학습 가능
초기 구현 비용	낮음	중간
장기 TCO	중간	낮음 (적응성으로 절감)

정리하면 — 이미 길이 닦여 있으면 RPA가 빠르고 싸고 안전합니다. 플래닝은 길이 없거나, 매번 길이 바뀌거나, 길 위에서 돌발 상황이 생기는 문제에서 비로소 값을 합니다. 초기 비용은 조금 더 들지만, 규칙을 끝없이 손보지 않아도 되니 장기 TCO는 오히려 낮아집니다.

3. 적응성과 재계획 — “에이전트는 실패하지 않는다”

플래닝에서 가장 흔한 오해가 “계획을 한 번 세우고 그대로 따른다”는 것입니다. 진짜 힘은 정반대에 있습니다. 초기 계획은 고정된 스크립트가 아니라 ‘시작점’일 뿐이고, 실행 중 새로운 정보가 나오면 계획을 다시 짭니다(Replanning). 이 적응성(Adaptability)이야말로 플래닝을 RPA와 가르는 본질입니다.

예를 들어 “팀 오프사이트 행사를 준비하라”는 목표를 받았다고 합시다. 첫 단계가 “A 호텔 예약 확인”인데 막상 예약이 불가하다면? RPA라면 여기서 멈추거나 오류를 던집니다. 플래닝 에이전트는 다릅니다 — 제약을 새 정보로 등록하고, 옵션을 재평가해 B 호텔로 경로를 갈아탑니다.

📋 초기 계획

1. A 호텔 예약 확인 ❌ 불가!
2. 케이터링 업체 연락 (대기)
3. 참가자 확정 (대기)

⟳

🔄 적응적 재계획

NEW B 호텔로 대안 검색
NEW B 호텔 예약 진행
3. 케이터링 연락 (B 기준 조정)
4. 참가자 확정 및 일정 안내

새 제약을 등록 → 옵션 재평가 → 새 계획 수립 · 목표는 그대로, 경로만 바뀐다

그림 3. 실패는 종료가 아니라 재계획의 트리거 — 에이전트는 멈추지 않고 길을 바꾼다

🧭

핵심 멘탈 모델 — “에이전트는 실패하지 않고 적응한다.” 한 단계가 막혔다는 건 경로 하나가 막혔다는 뜻이지 목표가 무너졌다는 뜻이 아닙니다. 그래서 잘 만든 플래닝 에이전트는 실패를 예외(Exception)가 아니라 입력(Signal)으로 받아들이고, 그걸 근거로 계획을 갱신합니다. 이 ‘실패 → 재계획’ 루프가 뒤에서 볼 Replanner의 존재 이유입니다.

4. Plan-and-Execute — 플래닝의 표준 아키텍처

플래닝을 구현하는 가장 널리 쓰이는 구조가 Plan-and-Execute입니다. 역할이 셋으로 나뉩니다 — 목표를 계획으로 바꾸는 Planner, 계획의 한 단계를 실행하는 Executor, 결과를 보고 계속할지 끝낼지 정하는 Replanner. 이 셋이 루프를 이루는 게 핵심입니다.

🧠

Planner

계획 생성

목표 분석 → 단계 분해
의존성 정렬

→

⚙️

Executor

단계 실행

현재 단계 실행
도구 호출 · 결과 수집

→

🔁

Replanner

평가 · 재계획

결과 평가
계속 / 완료 결정

↺ continue — 남은 단계 있음 → Executor로 되돌아감

✓ complete — 목표 달성 → 최종 응답 후 종료

그림 4. Plan-and-Execute의 세 역할과 루프 — Replanner가 매 단계 “더 갈까, 멈출까”를 가른다

컴포넌트	역할	입력	출력
Planner	목표를 분석해 실행 계획 생성	사용자 목표	Plan (단계 목록)
Executor	현재 단계를 실행하고 결과 수집	현재 단계, 컨텍스트	실행 결과
Replanner	결과 평가 및 계획 조정/완료 판단	실행 결과, 남은 계획	계속/완료 결정

왜 Planner와 Executor를 분리할까요? 한 모델이 “생각하면서 동시에 실행”하면 긴 작업에서 길을 잃기 쉽습니다. 계획을 먼저 통째로 세워 두면 전체 그림을 잃지 않고, 각 단계는 작고 검증 가능한 단위가 되며, 실패해도 그 단계만 다시 짜면 됩니다. “설계도와 시공을 나누는” 셈이죠.

⚡

고급 변형 — LLMCompiler. 단계들이 꼭 일렬일 필요는 없습니다. “검색하고 요약하되, 날씨는 따로 확인”처럼 서로 독립인 단계는 DAG(방향성 비순환 그래프)로 묶어 병렬로 실행할 수 있습니다. Plan-and-Execute가 순차라면, LLMCompiler는 의존성 없는 가지를 동시에 처리해 전체 시간을 크게 단축합니다(3편 병렬화 패턴과 만나는 지점입니다).

5. 구현 ① LangGraph — StateGraph로 짓는 Plan-and-Execute

LangGraph는 플래닝을 상태 그래프(StateGraph)로 표현합니다. 노드 셋(planner · executor · replanner)을 만들고, Replanner 뒤에 조건부 엣지를 달아 “Executor로 되돌릴지, 끝낼지”를 가릅니다. 가장 먼저 볼 것은 상태 정의입니다.

PYTHON · PlanExecuteState + Annotated 리듀서

class PlanExecuteState(TypedDict): input: str # 사용자 목표 plan: List[str] # 현재 남은 계획(단계 목록) past_steps: Annotated[List[Tuple[str, str]], lambda x, y: x + y] # 실행 이력(누적) response: str # 최종 응답(설정되면 종료)

한 줄이 마법입니다. Annotated[..., lambda x, y: x + y]는 리듀서(Reducer)입니다 — past_steps에 새 값이 들어오면 덮어쓰지 않고 기존 리스트에 이어 붙여 실행 이력을 자동 누적합니다. 덕분에 노드는 “이번에 한 일”만 반환하면 됩니다. 이제 노드 세 개를 봅시다.

PYTHON · Planner · Executor · Replanner 노드

def plan_step(state): # 🧠 Planner — 목표를 단계로 분해 result = (PLANNER_PROMPT | llm | StrOutputParser()).invoke({"input": state["input"]}) return {"plan": parse_plan(result)} # ["단계1", "단계2", ...] def execute_step(state): # ⚙️ Executor — 첫 단계만 실행 current = state["plan"][0] result = chain.invoke({"past_steps": ..., "current_step": current}) return {"past_steps": [(current, result)], # 리듀서가 누적 "plan": state["plan"][1:]} # 실행한 단계는 제거 def replan_step(state): # 🔁 Replanner — 계속? 완료? result = chain.invoke({"input": ..., "past_steps": ..., "remaining_plan": ...}) if "ACTION: complete" in result: # 키워드로 완료 판정 return {"response": final_response} return {} # 계속 진행

마지막 퍼즐은 종료 판정입니다. should_end가 조건부 엣지로 들어가 response가 채워졌거나 plan이 비면 끝내고, 아니면 Executor로 되돌립니다.

PYTHON · should_end + StateGraph 조립

def should_end(state) -> str: if state.get("response"): return "end" # 최종 응답 있으면 종료 if not state.get("plan"): return "end" # 남은 단계 없으면 종료 return "continue" # 그 외 → 다음 단계로 workflow = StateGraph(PlanExecuteState) workflow.add_node("planner", plan_step) workflow.add_node("executor", execute_step) workflow.add_node("replanner", replan_step) workflow.add_edge(START, "planner") workflow.add_edge("planner", "executor") workflow.add_edge("executor", "replanner") workflow.add_conditional_edges("replanner", should_end, {"continue": "executor", "end": END}) # 동적 분기 agent = workflow.compile()

상태가 TypedDict로 명시되고 흐름이 그래프로 보여 디버깅·시각화가 쉽고, 조건부 엣지로 재계획 루프를 자유롭게 그릴 수 있습니다. 복잡한 조건부 로직과 프로덕션급 제어가 필요할 때 LangGraph가 빛납니다. 단, should_end의 종료 조건을 분명히 두지 않으면 무한 루프에 빠지니, 반복 횟수 상한도 함께 거는 게 정석입니다.

6. 구현 ② CrewAI — 역할 기반 협업과 자동 계획(planning=True)

CrewAI는 발상이 다릅니다. 그래프를 그리는 대신 “전문가 팀을 꾸린다”는 메타포로 접근하죠. Agent(역할 전문가)와 Task(작업)를 정의해 Crew로 묶으면 됩니다. 그리고 옵션 한 줄이 플래닝을 켭니다 — planning=True.

PYTHON · Agent · Task(context) · Crew(planning=True)

planner = Agent( role="프로젝트 플래너", # 직책 goal="상세한 실행 계획 수립", # 목표 backstory="20년 경력의 프로젝트 관리 전문가...", # 페르소나(구체적일수록 ↑) allow_delegation=False) plan_task = Task( description="신제품 출시 계획을 수립하세요...", expected_output="구조화된 프로젝트 계획서", # 기대 결과 형식 agent=planner) exec_task = Task(description="계획을 실행하세요...", agent=executor, context=[plan_task]) # ← 이전 Task 결과를 입력으로 crew = Crew( agents=[planner, executor], tasks=[plan_task, exec_task], process=Process.sequential, # 또는 Process.hierarchical planning=True) # ⭐ CrewPlanner가 실행 전 자동 계획 result = crew.kickoff()

두 가지가 핵심입니다. 첫째, context=[plan_task] — 이전 Task의 결과를 다음 Task로 명시적으로 흘려보내 정보 흐름을 코드로 박습니다. 둘째, planning=True — 켜는 순간 CrewPlanner가 실행 전에 Task들의 의존성을 분석해 전체 실행 계획을 미리 생성합니다. 실행 방식은 둘 중 하나를 고릅니다.

➡️ Process.sequential

Task 1 → Task 2 → Task 3 → 완료
정해진 순서대로, 이전 완료 후 다음 시작

✓ 예측 가능 · 안정적 · 단순 파이프라인

🪜 Process.hierarchical

Manager Agent가 작업을 위임·조율
manager_llm이 적절한 Agent에게 배분

✓ 복잡한 프로젝트 · 동적 위임 · 팀 협업

그림 5. 순서대로 가는 Sequential, 매니저가 지휘하는 Hierarchical

Process.hierarchical에 manager_llm을 주면 매니저 에이전트가 전체를 조율하며 하위 Agent에게 일을 나눠 줍니다(7편 멀티 에이전트의 계층 구조와 직결됩니다). 학습 곡선이 가장 낮고 역할 기반 분업이 네이티브라, “사람 팀이 일하듯” 협업 시뮬레이션을 빠르게 만들 때 제격입니다. 대신 LangGraph만큼 정교한 조건부 분기·재계획 제어는 제한적입니다.

7. 구현 ③ Google ADK — Sequential·Parallel·Loop Agent

Google ADK는 워크플로우 에이전트를 조립식 블록으로 제공합니다. 개별 LlmAgent를 만든 뒤 SequentialAgent·ParallelAgent·LoopAgent로 감싸 순차·병렬·반복을 표현하죠. 상태 전달의 핵심은 output_key 단 하나입니다.

PYTHON · output_key 상태 자동 전달 + 워크플로우 에이전트

analyzer = LlmAgent(name="Analyzer", model="gemini-2.0-flash", instruction="요구사항을 분석하세요: {user_input}", output_key="analysis_result") # 결과 → session.state["analysis_result"] planner = LlmAgent(name="Planner", model="gemini-2.0-flash", instruction="분석 결과 {analysis_result}를 기반으로 계획을 수립하세요.", # 자동 치환! output_key="execution_plan") executor = LlmAgent(name="Executor", model="gemini-2.0-flash", instruction="계획 {execution_plan}을 실행하세요.", output_key="execution_result") planning_workflow = SequentialAgent( # 순차 — output_key로 상태 자동 연결 name="PlanningWorkflow", sub_agents=[analyzer, planner, executor])

진짜 일은 output_key가 합니다. Agent 결과가 세션 상태에 자동 저장되고, 다음 Agent의 instruction에서 {변수}로 쓰면 알아서 치환됩니다 — 상태를 손으로 넘기는 코드가 사라지죠. 나머지 두 블록도 직관적입니다.

PYTHON · ParallelAgent(동시 분석) · LoopAgent(반복 개선)

parallel_analysis = ParallelAgent( # 독립 분석을 동시에 실행(asyncio.gather) name="ParallelAnalysis", sub_agents=[technical_analyzer, business_analyzer, risk_analyzer]) iterative_planner = LoopAgent( # 조건 충족까지 반복 name="IterativePlanner", sub_agents=[plan_and_validate], max_iterations=5) # 무한 루프 방지 상한

ParallelAgent는 기술·비즈니스·리스크 분석을 동시에 돌려 시간을 줄이고, LoopAgent는 max_iterations 한도 안에서 품질 기준이 충족될 때까지 같은 단계를 반복합니다(4편 리플렉션의 LoopAgent와 같은 부품). 세 블록은 서로 중첩할 수 있어 — Sequential 안에 Parallel을, 그 안에 Loop를 — 복잡한 오케스트레이션을 레고처럼 쌓습니다. Gemini 네이티브 통합과 표준화된 워크플로우 블록이 ADK의 매력입니다.

8. 세 프레임워크 — 같은 계획, 다른 철학

셋 다 “목표를 단계로 쪼개 실행한다”는 본질은 같습니다. 다른 건 무엇을 일급 시민으로 보느냐입니다 — LangGraph는 그래프(상태·흐름), CrewAI는 에이전트(역할), ADK는 워크플로우 블록이 주인공입니다.

LangGraph

StateGraph + 조건부 엣지

주인공: 그래프·상태
계획: Planner 노드
재계획: Replanner 노드
유연성 최고 · 프로덕션

CrewAI

Crew + planning=True

주인공: 역할 Agent
계획: planning=True 자동
재계획: 제한적
학습 쉬움 · 팀 협업

Google ADK

Sequential/Parallel/Loop

주인공: 워크플로우 블록
계획: LlmAgent 수동
상태: output_key 자동
Gemini 네이티브 · 표준화

그림 6. 같은 플래닝, 세 가지 철학 — 그래프 중심 / 역할 중심 / 블록 중심

특성	LangGraph	CrewAI	Google ADK
상태 관리	TypedDict + 리듀서	Task Context	output_key 자동
계획 생성	Planner 노드	planning=True 자동	LlmAgent 수동
병렬 실행	수동 구현	제한적	ParallelAgent
반복 실행	조건부 엣지	제한적	LoopAgent
재계획 지원	Replanner 노드	제한적	수동 구현
역할 기반 분업	수동 구현	네이티브 지원	수동 구현
학습 곡선	중간	낮음	낮음
유연성	매우 높음	중간	높음
추천 환경	복잡한 워크플로우	팀 협업 시뮬레이션	표준 오케스트레이션

고르는 법은 간단합니다. 복잡한 조건부 로직·세밀한 재계획이 필요하면 LangGraph, 역할을 나눈 팀 협업을 빠르게 시뮬레이션하려면 CrewAI, 순차·병렬·반복을 표준 블록으로 쌓고 Gemini를 쓰면 Google ADK. 그리고 “웹을 뒤져 보고서를 쓰는” 딥 리서치라면 별도의 길이 있습니다 — 바로 다음 장입니다.

9. Deep Research — 플래닝의 킬러 앱

플래닝이 가장 화려하게 빛나는 실제 제품이 Deep Research입니다(Google Gemini DeepResearch, OpenAI Deep Research API). 사용자가 “유럽 VC 투자 현황과 성장 국가를 분석해줘” 한 줄을 던지면, 에이전트가 연구 계획을 먼저 세우고 수백 개 소스를 오가며 검색-분석을 반복해 인용이 달린 보고서를 내놓습니다. Plan-and-Execute에 리플렉션(지식 갭 식별)이 결합된 형태죠.

① 연구 계획

사용자 쿼리를 하위 질문들로 분해 (투자 규모 · 국가별 순위 · 성장률 · 가속화 국가 · 섹터 트렌드)

↓

② 반복 검색

Search → Analyze → 지식 갭 식별 → Search Again 루프 (수백 개 소스 분석)

↓

③ 갭 보완

빠진 정보를 스스로 발견해 추가 검색 — 충분해질 때까지 (비동기 장시간 실행)

↓

④ 보고서

Executive Summary · 데이터 분석 · 인라인 인용/출처 · 시각화로 구조화

그림 7. Deep Research 파이프라인 — 계획 → 반복 검색·분석 → 지식 갭 보완 → 인용 보고서

OpenAI는 이걸 API로 열어 두어 코드로 호출할 수 있습니다. 모델에 web_search_preview 도구를 주면, 모델이 알아서 검색 쿼리를 만들고 추론하며 인용 보고서를 작성합니다.

PYTHON · OpenAI Deep Research API

response = client.responses.create( model="o3-deep-research-2025-06-26", input=[ {"role": "developer", "content": [{"type": "input_text", "text": system_msg}]}, {"role": "user", "content": [{"type": "input_text", "text": user_query}]}, ], reasoning={"summary": "auto"}, tools=[{"type": "web_search_preview"}]) # 내장 웹 검색 final_report = response.output[-1].content[0].text # 최종 보고서 for c in response.output[-1].content[0].annotations: # 인용 메타데이터 print(c.title, c.url)

🔬

왜 ‘킬러 앱’인가. Deep Research는 플래닝의 세 가지 강점을 한 번에 보여 줍니다 — ① 목표 분해(거대한 질문 → 하위 질문), ② 적응적 재계획(지식 갭을 발견하면 검색을 더 함), ③ 투명성(추론·검색 쿼리·인용이 모두 노출). MCP로 사내 데이터 소스까지 붙이면, 공개 웹을 넘어 우리 회사 지식으로 리서치하는 에이전트가 됩니다.

10. 엔터프라이즈 적용 — CRM · ERP · Groupware

기업 업무의 대부분은 여러 시스템을 넘나드는 다단계 절차입니다 — 정확히 플래닝이 노리는 지점이죠. 고정 규칙으로 박아 둔 RPA를 목표 기반 플래닝 에이전트로 바꾸면, 효과는 숫자로 분명해집니다.

CRM고객 관계 관리

VIP 불만응대 시간 -70%

캠페인 기획기획 시간 -50%

이탈 방지이탈률 -25%

ERP전사 자원 관리

대량 주문처리 시간 -60%

긴급 발주대응력 +80%

월말 결산결산 기간 -40%

Groupware협업 시스템

프로젝트 승인승인 시간 -50%

회의 후속누락 -90%

킥오프 준비준비 시간 -70%

연간 ROI 분석 (도입 효과)

$840K

연간 순효과

절감 $1.14M − 비용 $300K

280%

ROI

투자 대비 회수율

+30%

직원 생산성

반복 업무 자동화

10개+

자동화 프로세스

확장 단계 기준

그림 8. 시스템별 플래닝 적용 효과와 연간 ROI — 목표 한 줄로 다단계 절차를 압축한다

기술적으로는 레거시를 그대로 두고 위에 얹는 계층 구조가 정석입니다. 모든 요청은 API Gateway(인증·라우팅·속도 제한·로깅)를 지나, Orchestration(요청 파싱 → 계획 생성 → 실행 관리)이 지휘하고, Domain Agent(CRM/ERP/GW)가 Integration Adapter(Salesforce·SAP·MS365·Legacy)를 통해 실제 시스템을 두드립니다. 상태·이력·감사 로그는 Data & State Layer가 보관하죠.

① API Gateway — 인증/인가 · 라우팅 · 속도 제한 · 로깅

↓

② Orchestration — Request Parser → Plan Generator → Execute Manager

↓

③ Domain Agent — CRM · ERP · Groupware · Custom Agent

↓

④ Integration Adapter — Salesforce · SAP · MS365 · Legacy

↓

⑤ Data & State — Session State · Execution History · Audit Logs

11. 케이스 스터디 — Cross-Domain 온보딩과 안전장치

하나의 목표가 세 시스템에 걸치는 실제 시나리오를 봅시다. “신규 VIP 고객을 온보딩하라” — 플래너는 이 한 줄을 CRM·ERP·Groupware를 가로지르는 통합 계획으로 펼칩니다.

TEXT · 목표 한 줄 → Cross-Domain 통합 계획

목표: "신규 VIP 고객 온보딩 — 등록·계약·킥오프까지" Planner가 생성한 통합 계획 → 1. [CRM ·Salesforce] 고객 마스터 데이터 생성 2. [CRM ·Salesforce] 담당 영업/CS 배정 3. [ERP ·SAP] 고객 계정 생성 4. [ERP ·SAP] 초기 계약 조건 설정 5. [GW ·MS365] 킥오프 미팅 일정 조회 6. [GW ·MS365] 참석자 일정 조율 7. [GW ·MS365] 미팅 초대 발송 8. [CRM ·Salesforce] 온보딩 체크리스트 생성 9. [ALL ·Custom] 온보딩 대시보드 업데이트 # 4번 "계약 조건"은 금액 임계값 → Human-in-the-Loop 승인으로 전환

안전장치 ① Human-in-the-Loop — 어디까지 자동인가

자율성이 높을수록 고삐가 중요합니다. 무엇을 자동으로 하고, 무엇을 사람이 승인하고, 언제 사람을 부를지(에스컬레이션)를 임계값으로 못 박습니다.

🟢 자동 실행

정보 조회·분석
계획 초안 생성
저위험·되돌릴 수 있는 작업

🟡 승인 필요

금액 $10,000 이상 결정
고객 데이터 수정/삭제
외부 시스템 데이터 변경

🔴 에스컬레이션

계획 신뢰도 < 70%
영향 범위 > 100 고객/거래
재계획 3회 이상 발생

안전장치 ② 실패는 어떻게 되돌리나 — 5단계 롤백

다단계 작업은 3번 단계에서 터지면 1~2번을 어떻게 되돌릴지가 관건입니다. 각 단계마다 Savepoint를 찍어 두고, 실패 시 점진적으로 대응합니다.

1단계 · 재시도 (max 3회) — 네트워크·타임아웃 같은 일시적 오류

2단계 · 대안 실행 — 같은 목표를 위한 다른 경로 탐색(재계획)

3단계 · 부분 롤백 — 실패 지점 이전 Savepoint로 복원

4단계 · 전체 롤백 — 보상 트랜잭션 실행(Saga Pattern)

5단계 · 수동 개입 — 담당자 알림 + 수동 처리 가이드 제공

도입은 한 번에 하지 않는다 — 3단계 로드맵

Phase 1 · 파일럿 (3개월)

단일 도메인 1개 프로세스 · LangGraph+Gemini · 읽기 전용 연동
→ 처리 -50% · 만족도 4.0/5.0 · 가용성 99.5%

Phase 2 · 확장 (6개월)

다중 도메인 통합 · CrewAI+ADK · Redis/PG · K8s
→ 프로세스 10개+ · 월 $50K+ 절감 · 생산성 +30%

Phase 3 · 최적화 (지속)

예측적 Planning · 자가 학습 · MLOps·Fine-tuned·RAG
→ 계획 품질 모니터링 · 선제적 실행

12. 베스트 프랙티스 & 트레이드오프

플래닝을 쓸지 말지 — 의사결정

✅ 쓰면 좋은 곳

• 복잡한 다단계·의존성 있는 작업
• 동적 환경(실행 중 새 정보 발생)
• 연구/분석(Deep Research·경쟁사 분석)
• 비즈니스 프로세스 자동화(온보딩·주문)
• 목표는 명확하나 방법이 불명확할 때

❌ 피해야 할 곳

• 단순 Q&A (오버헤드가 가치보다 큼)
• 고정 워크플로우가 이미 정의된 경우
• 실시간 응답이 필수인 경우
• 비용에 매우 민감한 대용량 처리

트레이드오프 — 자율성엔 대가가 따른다

플래닝은 복잡한 목표를 풀어 주는 대신 계획 생성 오버헤드(지연), 다단계 LLM 호출 비용, 계획 품질 변동(할루시네이션), 무한 루프 위험, 다단계 추적의 디버깅 복잡성을 떠안깁니다. 그래서 “계획할 수 있다”가 아니라 “이 작업에 계획이 정말 필요한가”를 먼저 물어야 합니다. 무한 루프는 max_iterations와 명확한 종료 조건으로, 품질 변동은 리플렉션(Critic)으로 막는 게 정석입니다.

다른 패턴과의 조합

플래닝은 단독으로 쓰이기보다 다섯 패턴의 지휘자로 작동할 때 가장 강합니다. 계획을 세우고, 각 단계에서 도구를 부르고, 독립 단계는 병렬로, 결과는 리플렉션으로 검증하죠.

조합	활용
Planning + 라우팅(2편)	라우터가 복잡한 작업만 Planning Agent로 전달
Planning + 병렬화(3편)	독립 단계를 병렬 실행(LLMCompiler 아키텍처)
Planning + 리플렉션(4편)	Critic이 계획 품질을 검증 후 개선
Planning + 도구 사용(5편)	각 단계에서 적절한 도구 호출
Planning + 멀티 에이전트(7편)	각 단계를 전문 Agent가 담당(Hierarchical)

체크리스트

• ✅ 각 단계는 독립 실행·검증 가능하게 · 단계 간 의존성과 완료 기준을 명확히
• ✅ 재계획 판정을 키워드로 — ACTION: complete / continue + max_iterations로 무한 루프 차단
• ✅ 실행 이력(past_steps) 축적 + output_key 명명 일관성 · 컨텍스트 압박 시 요약
• ✅ 에러 처리 — 단계 실패 시 대안 경로 + 롤백 전략(Saga) + 에스컬레이션
• ✅ Human-in-the-Loop — 신뢰도 < 70%·금액 임계값 초과 시 사람 승인

★ 마치며

체이닝(1편)이 “순서대로 쪼개기”, 라우팅(2편)이 “입력에 따라 길 나누기”, 병렬화(3편)가 “독립 작업 동시에”, 리플렉션(4편)이 “쓴 다음 읽고 고치기”, 도구 사용(5편)이 “못 하면 도구를 써라”였다면, 플래닝은 “목표만 주면 길은 내가 그린다”입니다. 여기서 에이전트는 비로소 반응형을 넘어 목표 지향적으로 행동하죠. 핵심은 셋 — 목표를 검증 가능한 단계로 분해하고, 실패를 재계획의 신호로 삼으며(에이전트는 실패하지 않고 적응한다), 자율성이 커진 만큼 Human-in-the-Loop(HITL)과 롤백을 처음부터 설계하는 것. 그리고 플래닝의 진짜 위력은 다른 패턴을 지휘할 때 나옵니다 — 계획의 각 단계에서 도구를 부르고, 독립 단계는 병렬로, 결과는 리플렉션으로 검증합니다. 다음 7편에서는 한 발 더 나아가, 계획의 각 단계를 서로 다른 전문 에이전트들이 나눠 맡는 멀티 에이전트 협업(Multi-Agent Collaboration)을 다룹니다 — 플래너가 그린 청사진을, 한 팀이 함께 짓는 이야기입니다.

#플래닝#Planning#PlanAndExecute#재계획#LangGraph#CrewAI#GoogleADK#DeepResearch#AgenticAI

시리즈: 01 Prompt Chaining → 02 Routing → 03 Parallelization → 04 Reflection → 05 Tool Use → 06 Planning → (다음) 07 Multi-Agent