L22 — Planning: 단계를 미리 못 정할 때, 에이전트가 스스로 쪼개게 하기 (수정중)

이 강의는 Antonio Gulli,「Agentic Design Patterns」 6장 Planning 을 우리 standarda 스택에 비춰 읽는다. 앞 강의 L21 Prompt Chaining과 한 쌍 — chaining 은 내가 미리 정한 고정 분해, planning 은 에이전트가 런타임에 하는 동적 분해.

1. 책의 개념과 예시 (Agentic Design Patterns 6장)

정의: Planning 은 에이전트(Agent)(L12) 하나(또는 여럿)가 초기 상태에서 목표 상태로 가기 위한 행동의 순서(sequence of actions)를 스스로 짜는 능력이다. 여기서 에이전트란 한 가지 일을 맡아 스스로 판단하며 도는 작은 프로그램을 말한다. 책의 정의 그대로:

"At its core, planning is the ability for an agent or a system of agents to formulate a sequence of actions to move from an initial state towards a goal state."

핵심 동작은 task decomposition(작업 쪼개기) — 복잡한 목표를 다루기 쉬운 하위문제로 잘게 나눈다. 단, 그 나눔을 내가 미리 코드에 박아두는 게 아니라 에이전트가 런타임에(=돌리는 바로 그 순간에) 정한다**는 점이 L21 chaining 과 갈리는 지점이다.

책의 대표 예시 — "팀 오프사이트를 준비해줘" (텍스트 사례)

책이 이 패턴을 소개하며 드는 예시다. "organize a team offsite(팀 워크숍을 준비해줘)" 라고 시키면, 당신은 무엇(what) — 목표와 제약 — 만 정한 것이지 어떻게(how) 는 안 정했다. 장소 물색·일정 조율·예산·초대… 어떤 단계를 어떤 순서로 밟을지는 에이전트가 스스로 정한다.

책: "When you ask it to 'organize a team offsite,' you are defining the what—the objective and its constraints—but not the how."

미리 단계를 못 박는다는 점에서, 이건 우리가 늘 만나는 "golden 에 최신 standarda-template 적용하려면 어떻게 해야 할까", "이 주제로 리서치해서 보고서 만들어줘" 와 같은 종류다.

책의 코드 예시 — plan-then-write 에이전트 (CrewAI)

6장 hands-on 예시는 먼저 계획을 짜고, 그 계획대로 실행하는 단일 에이전트다(plan-and-execute):

# 책 6장 (planning_crewai.py) — 발췌
planner_writer_agent = Agent(
    role="Article Planner and Writer",
    goal="Plan and then write a concise, engaging summary on a specified topic.",
    backstory="...먼저 명확한 실행 계획을 세운 뒤 글을 쓰는 전문가...",
    llm=llm,
)
task = Task(
    description=(
        "1. Create a bullet-point plan for a summary on the topic: '{topic}'.\n"
        "2. Write the summary based on your plan, keeping it around 200 words."
    ),
    expected_output="### Plan\n- ...불릿 계획...\n\n### Summary\n- ...계획대로 쓴 요약...",
    agent=planner_writer_agent,
)
Crew(agents=[planner_writer_agent], tasks=[task], process=Process.sequential).kickoff()

눈여겨볼 점: 한 task 안에서 ① 계획(bullet plan) → ② 그 계획대로 작성 순서로 일어나고, 산출물도 ### Plan / ### Summary 로 갈린다. 계획이 먼저 나오고 눈에 보이는 게 plan-and-execute 의 특징이다(§3).

책이 드는 활용처 4가지

1. 절차적 작업 자동화(예: 직원 온보딩 — 계정 생성 + 교육 일정 조율) · 2. 로보틱스·자율주행(장애물 회피 경로 계획) · 3. 구조화된 정보 합성(리서치 보고서 — 정보 수집 → 요약 → 정제) · 4. 고객 지원(다단계 문제 해결 — 진단 + 에스컬레이션)

책의 단서 둘: "An initial plan is merely a starting point, not a rigid script"(초기 계획은 대본이 아니라 출발점 — 결과를 보며 조정된다) / "dynamic planning is a specific tool, not a universal solution"(만능이 아니다). 이 둘이 뒤(§2·§6)의 핵심이다.

2. 언제 planning 인가 — 고정 체인의 한계

L21의 prompt chain(미리 정한 순서대로 단계를 하나씩 밟는 방식)은 강력하지만 전제가 하나 있다 — 단계를 내가 미리 안다. 추출 → LLM → 파싱, spec → code → verify 처럼 순서가 고정돼 있다. 그런데 §1 의 "팀 오프사이트"·"golden template 적용"·"리서치 보고서" 엔 정해진 단계가 없다. template 의 어떤 파일이 다른지, 어떤 게 위험한지는 열어보기 전엔 모른다. 리서치도 어떤 하위주제를 팔지는 첫 검색 결과를 봐야 안다. 단계를 미리 못 박는다 — 이게 chaining 의 한계선이고 Planning 이 시작되는 지점이다.

§1 의 책 정의로 돌아가면 — 이런 작업은 목표(what) 만 주어지고 방법(how) 은 안 정해진 경우다. 밟을 단계를 미리 못 박으므로, 고정 chain 이 아니라 에이전트가 런타임에 스스로 분해하는 Planning 이 필요하다.

L21 과의 차이가 한 줄로 갈린다:

그래서 책은 Planning 을 양날의 검으로 본다:

책(Gulli 6장) 그대로: "dynamic planning is a specific tool, not a universal solution" — 만능이 아니다. 해법을 이미 잘 아는 작업엔 고정 워크플로가 더 낫다. 에이전트의 자율성을 제한해 불확실성과 예측 불가 행동의 위험(uncertainty and the risk of unpredictable behavior) 을 줄이기 때문이다.

이 "강력하지만 자율성이 곧 예측 불가" 라는 긴장이 이 강의의 나머지 절반(4~6절: 어떻게 길들이나)을 끌고 간다.

3. 두 가지 Planning — Plan-and-Execute vs ReAct (그리고 우리 도구)

책은 Planning 을 두 갈래로 나눈다. 우리가 매일 쓰는 Claude Code 도구에 정확히 매핑된다:

• Plan 모드 = 교과서적 plan-and-execute 다. Claude 가 코드를 조사한 뒤 전체 계획을 먼저 내놓고, 사람이 승인(ExitPlanMode)하면 그때 실행에 들어간다. "실행 전 검토가 싸다" 가 plan 모드의 존재 이유.
• 평범한 에이전트 작업(파일 읽고→판단하고→다음 도구) 은 ReAct 다 — 다음 단계를 미리 정하지 않고 매 스텝 결정한다. L12의 서브에이전트가 자기 창에서 도는 게 이 모양.

L16의 "어떻게 해야 할까 / 제안해줘" 프롬프트가 바로 Planning 을 유도하는 발화다. 해결책을 안 박았기에 Claude 가 조사 후 스스로 단계를 설계한다. L16 의 케이스 A(golden template)·D(카드 레이블링 P0~P4)가 plan-and-execute 의 실사례다.

4. 자율성을 길들이는 장치 ① — 계획을 산출물로 고정

"예측 어렵다" 를 그냥 두면 위험하다. 우리 워크플로우의 첫 번째 안전장치는 계획을 그때 쓰고 버리지 않고 문서로 남겨 박는 것이다.

CLAUDE.md (241-243행):

docs/plans/ — 구현 계획. plan 모드 종료 후 반드시 docs/plans/{slug}.md 에
최종 계획을 복사/저장할 것 (.claude/plans/ 는 세션용이므로 별도 보존 필요)

/develop 도 이를 강제한다 (.claude/skills/develop/SKILL.md): plan 모드를 거쳤으면 .claude/plans/{plan-file}.md 를 docs/plans/{slug}.md 로 복사한다. 왜? 에이전트가 스스로 만든 분해(계획)를 사람이 읽고·리뷰하고·나중에 대조할 수 있게. plan-and-execute 의 "검토가 싸다" 는 장점은 계획이 남아 있을 때만 실현된다.

5. 길들이는 장치 ② — 계획대로 했는지 검증(머지 차단)

두 번째 안전장치는 더 세다 — 계획에서 벗어나면 머지(코드 합치기)를 막는다. /develop 의 계획 게이트들:

• Stage 5 (Plan): Claude 가 변경 목록·접근·영향범위를 제시. 사용자 승인 전엔 다음으로 못 감. 거부되면 5단계로 복귀(계획 루프).
• Stage 5.5 (Spec 작성): docs/specs/{app}.md 를 이번 사이클의 Source of Truth(계획 산출물) 로 확정. 역시 명시적 승인 게이트.
• Stage 7 (Verify): spec-verifier (.claude/agents/spec-verifier.md)가 5.5 의 스펙 ↔ 6 단계 코드를 절별 1:1 대조. 불일치면 BLOCKED. 스펙 문서가 곧 계획 준수 게이트다.
• Stage 9 (merge-master): .claude/agents/merge-master.md 가 머지 전 문서 체크리스트를 확인 — plan 모드를 거친 작업이면 docs/plans/{slug}.md 존재를 요구.

즉 우리는 에이전트에게 계획 자율성을 주되(Stage 5에서 스스로 분해), 그 계획을 문서로 못 박고(5.5) → 코드가 계획을 지켰는지 기계가 검증하고(7) → 안 지키면 머지를 막는다(9). "강력하지만 예측 불가" 의 예측 불가 쪽을 사람 승인 + 자동 검증으로 덮는 구조다.

6. 길들이는 장치 ③ — 과거 계획에서 배우기, 그리고 Planning 의 함정

세 번째 — 매번 백지에서 계획하지 않게 한다. /develop Stage 3 은 lesson-finder (.claude/agents/lesson-finder.md)로 wiki/lessons/INDEX.md 에서 이번 task 에 맞는 과거 교훈을 끌어와 계획 단계(5)의 입력으로 주입한다. 다른 프로젝트가 이미 밟은 잘못된 분해를 반복하지 않게 — 일종의 planning-as-learning(지난 계획에서 배워 다음 계획을 짜는 것).

그래도 Planning 엔 책이 경고하는 고질적 함정이 있다. 우리 장치는 이것들을 겨냥한 것이다:

마지막 줄이 두 강의를 닫는 결론이다 — Planning 을 남발하지 마라. 책(6장) 그대로:

"dynamic planning is a specific tool, not a universal solution." — 해법을 이미 잘 아는 일엔 고정 워크플로가 더 낫다(단계를 아니까).

단계를 알면 chain(L21), 모르면 plan(L22). golden template 반영처럼 열어보기 전엔 모르는 일엔 plan, 추출→LLM→파싱처럼 매번 같은 일엔 chain. 둘을 섞는 게 /develop 다 — plan(5·5.5) 으로 분해를 정하고, 그 다음을 code→verify→merge 의 고정 chain(6~9)으로 굴린다.

오늘 정리 + 다음

• 정리: Planning 은 단계를 미리 못 정하는 작업에서 에이전트가 스스로 목표를 하위작업으로 분해하는 패턴이다(책 6장). 강력하지만 그만큼 결과 예측이 어렵다(책: 자율성이 곧 unpredictable behavior 의 위험). 두 갈래 — plan-and-execute(우리 plan 모드: 계획 먼저, 검토 쌈, 취약) vs ReAct(우리 tool-loop: 적응, 비쌈). 우리는 자율성을 ① 계획을 docs/plans/ 에 산출물로 고정 ② spec-verifier 로 계획 준수를 머지 차단 게이트화 ③ lesson-finder 로 과거 교훈 주입 — 세 장치로 길들인다. 단계를 알면 chain(L21), 모르면 plan(L22).
• 흔한 함정: ① 단계를 아는 일에 planning 을 씀 — 매번 같은 작업이면 고정 chain 이 더 싸고 안정적이다. ② 계획을 안 남김 — plan 모드를 거쳐놓고 docs/plans/ 에 저장 안 하면, plan-and-execute 의 "검토가 싸다" 장점이 통째로 사라진다(merge-master 가 막는 이유). ③ 승인 없이 자율 실행 — "예측 불가" 를 사람 게이트 없이 두면 과분해·drift 가 그대로 머지된다.
• 다음 시간: M3 의 나머지 — 에이전틱 마인드셋 정리, 그리고 이 패턴들을 실제로 굴리는 도구 복습(L11 Skills·L12 Agents·L13 Hooks, 한 사이클 L03).
• 자습 권장: 최근 자기 세션에서 Claude 가 plan 모드로 계획을 내놓은 적이 있다면, 그 계획이 docs/plans/ 에 남았는지 확인해 보라. 없다면 왜 안 남겼는지 — 그게 "검토 가능한 planning" 과 "그냥 실행해버린 planning" 의 차이다.