RUDA DIRECTOR · AI Agent — 30 DAYS / 90 ARTICLES · Day 03 · Build 02
30초 답변: AI Agent의 Planning은 Goal·Constraint·현재 State를 실행 가능한 Step, dependency, 검증 evidence, stop condition으로 바꾸는 과정이다. Plan은 미래를 확정하는 약속이 아니라 검증 가능한 가설이다. Observation이 예상과 같으면 계속 실행하고, 국소 실패는 해당 Step만 복구하며, 핵심 가정이나 제약이 바뀔 때만 영향 범위를 다시 계산해야 한다.
Planning은 긴 할 일 목록이 아니다
OpenAI의 Agents 안내는 Agent를 Tool과 State를 사용해 multi-step work를 계획하고 완료하는 application으로 설명한다. 여기서 Planning의 산출물은 멋진 서술이 아니라 다음 Action을 안전하게 선택할 수 있는 외부화된 실행 구조다. 최소 Plan에는 Goal, 변하지 않는 Constraint, 현재 State, Step 간 dependency, 각 Step의 expected evidence, 다음 Action, Replan 이유가 들어간다.
| 이웃 개념 | Planning과의 경계 | 핵심 질문 |
|---|---|---|
| Agent Loop | Action → Observation → Decision을 반복하는 제어 구조 | 다음 Turn을 어떻게 진행할까? |
| Plan | Goal을 Step·dependency·evidence로 표현한 수정 가능한 상태 | 무엇을 어떤 순서와 조건으로 끝낼까? |
| Workflow | 경로와 전이가 주로 code에 미리 정의된 실행 그래프 | 정해진 조건에서 어느 경로로 갈까? |
| Reasoning | Model 내부의 판단 과정 | 왜 이 결정을 내릴까? |
Plan을 private chain-of-thought와 같은 것으로 취급해서는 안 된다. 운영에 필요한 것은 장문의 내적 독백이 아니라 사람이 검토하고 Runtime이 추적할 수 있는 Step, 상태, 근거, 예외다. 반대로 경로가 이미 결정된 Workflow에 매 Turn 새 Plan을 만들면 결정이 늘지 않고 Token과 Latency만 늘어난다.
Planning은 State를 읽고 Plan을 수정하는 loop다
GOAL + CONSTRAINTS + CURRENT STATE
↓
PLAN
Step · dependency · expected evidence · stop condition
↓
EXECUTE ONE SAFE STEP
↓
OBSERVE ENVIRONMENT
Tool Result · artifact · test · approval state
↓
CLASSIFY THE DELTA
예상 일치 / 국소 실패 / 가정 변경 / 권한·안전 문제
↓
CONTINUE / REPAIR / PARTIAL REPLAN / PAUSE
↺
핵심은 “무언가 달라졌다”가 아니라 달라진 사실이 어느 dependency를 무효화했는가를 계산하는 것이다. OpenAI의 long-horizon Codex 사례는 목표와 non-goal을 고정하고, milestone마다 acceptance criteria와 validation을 두며, 실패하면 다음 단계로 넘어가기 전에 고치는 구조를 사용했다. OpenAI가 명시했듯 이 사례는 production rollout이 아니라 experiment이므로, 여기서는 성능 결과가 아니라 Plan을 inspectable artifact로 다룬 설계 원칙만 가져온다.
| Observation | 판단 | Plan 처리 |
|---|---|---|
| Expected evidence가 확인됨 | 가정이 유지됨 | 현재 Step을 완료하고 다음 Step으로 이동 |
| 같은 Step 안의 일시적·국소 실패 | Plan 전체는 유효 | Retry 또는 Step-level repair |
| 한 dependency나 입력만 변경됨 | 영향 범위가 제한됨 | 해당 branch만 partial Replan |
| Goal 또는 핵심 Constraint가 승인된 방식으로 변경됨 | 완료 정의가 바뀜 | 영향 받는 Plan을 전면 재작성하고 재승인 |
| Permission 부족, 위험한 Action, 승인 없음 | 실행 권한이 없음 | 우회하지 말고 Pause / Approval |
| 완료 evidence가 없음 | 진행 보고만 존재 | 완료 처리하지 않고 검증 Step 유지 |
가장 작은 Plan State는 무엇을 담아야 하는가
작은 competent architecture는 별도의 Planner Agent가 아니라 하나의 구조화 record로 시작할 수 있다.
{
"goal": "검증 가능한 완료 상태",
"constraints": ["범위", "권한", "시간", "비가역 조건"],
"steps": [
{
"id": "P1",
"status": "ready",
"depends_on": [],
"expected_evidence": "확인할 artifact 또는 state"
}
],
"next_action": "P1",
"replan_reason": null
}Step 설명보다 expected_evidence가 중요하다. “문서를 완성한다”는 Model이 스스로 완료를 선언할 수 있지만, “12개 문서 쌍이 inventory에 있고 link check가 통과한다”는 환경에서 확인할 수 있다. Anthropic도 Agent가 각 Step에서 Tool Result나 code execution 같은 environment의 ground truth를 얻어 진행 상태를 판단해야 한다고 설명한다.
Worked Example: 다국어 도움말 사이트를 공개한다면
아래는 Planning mechanism을 설명하기 위한 가상 Trace다. 실제 운영 기록이나 고객 사례가 아니다. Goal은 “한국어·영어 도움말 12개 문서를 staging에서 검증한 뒤 승인받아 공개한다”다. Constraint는 production publish 전에 staging 확인과 명시적 Approval이 필요하다는 것이다.
| 시점 | State / Evidence | Decision | Plan 변화 |
|---|---|---|---|
| 초기 | 12개 문서 쌍이 있다고 알려짐 | inventory → link check → staging → Approval → publish | 5개 milestone 생성 |
| Inventory 후 | 영문 1개가 실제로 없음 | 전체를 폐기할 필요는 없지만 link check의 dependency가 깨짐 | 번역·검수 Step을 삽입하는 partial Replan |
| Staging 후 | build는 통과했으나 새 security header 정책이 적용됨 | 배포 branch와 검증 기준만 영향 | 관련 build·smoke test만 다시 실행 |
| Approval 전 | 승인 record가 없음 | Permission 문제를 Planning으로 우회할 수 없음 | Pause, 승인 요청; publish Step은 blocked |
| 승인 후 | 승인과 최종 build hash가 확인됨 | production publish 가능 | publish 뒤 live link check 실행 |
이 Trace의 포인트는 매 Observation마다 처음부터 다시 생각하지 않는 것이다. 누락된 번역은 해당 dependency만 바꾸고, security policy 변화는 관련 검증만 무효화한다. Approval이 없을 때는 더 영리한 경로를 만드는 것이 아니라 멈춘다. 마지막으로 “배포 요청을 보냈다”가 아니라 live URL과 link check가 있어야 완료다.
Planning이 실패하는 6가지 방식
1. Plan을 가설이 아니라 예언으로 만든다
초기 정보가 불완전한데 세부 구현 순서를 모두 고정하면 첫 가정이 틀렸을 때 뒤 Step도 연쇄적으로 틀어진다. Anthropic의 2026년 long-running harness 사례도 Planner가 granular implementation detail을 미리 잘못 정하면 오류가 downstream으로 전파될 수 있어 deliverable과 high-level design에 집중했다고 설명한다.
2. Observation마다 전면 Replan한다
사소한 경고와 예상 가능한 변동까지 전체 Plan을 다시 만들면 Step ID와 완료 기준이 흔들린다. 진행 비교가 어려워지고 Token·Latency가 증가하며, 같은 선택을 번갈아 고르는 oscillation이 생긴다. 먼저 local repair, partial Replan, full Replan을 분리해야 한다.
3. 진행 서술을 완료 evidence로 믿는다
“대부분 구현됐다”는 문장은 환경 상태가 아니다. Anthropic의 long-running agent 연구에서도 일부 기능이 구현된 뒤 Agent가 작업이 끝났다고 성급히 선언하는 실패가 관찰됐다. 완료는 test, artifact, external state, Approval처럼 독립적으로 읽을 수 있는 evidence에 묶어야 한다.
4. Permission 문제를 다른 경로로 우회한다
승인이나 권한이 없다는 Observation은 “더 나은 Plan이 필요하다”는 뜻이 아니다. Planning은 Authorization을 만들지 않는다. 해당 Step을 blocked로 두고 Human-in-the-loop Approval을 기다려야 한다.
5. Plan과 현재 State를 한 문단에 섞는다
완료된 Step, 추정, 다음 Action, 실패 이유가 자연어 한 덩어리에 있으면 어떤 dependency가 유효한지 계산하기 어렵다. Plan revision과 execution State를 분리하고, 변경 이유와 영향을 남겨야 Tracing과 복구가 가능하다.
6. Planner Agent를 기본값으로 추가한다
별도 Planner, Executor, Reviewer가 도움이 되는 경우도 있지만 Agent가 늘면 handoff Context, coordination cost, Latency, Token, Permission surface, 부분 실패 지점이 함께 늘어난다. 먼저 단일 Agent와 구조화 Plan으로 실패를 관찰하고, 독립적인 계획 검토가 품질을 실제로 올릴 때만 역할을 분리한다.
세 가지 Planning 전략의 Trade-off
| 전략 | 장점 | 대가와 적합 조건 |
|---|---|---|
| No explicit Plan | Token·Latency·구현 복잡성이 가장 낮음 | 한두 Step, 저비용·가역 Action에 적합; 진행 복구와 감사성은 낮음 |
| Checkpoint Plan | dependency와 완료 evidence를 추적하면서 필요한 branch만 수정 | State 관리 비용이 들지만 대부분의 multi-step task에 균형이 좋음 |
| Planner / Executor 분리 | 계획 검토와 실행 Context를 분리할 수 있음 | 추가 Tool Call, handoff, Latency, Permission·failure surface가 정당화되는 고복잡도 작업에만 적합 |
Anthropic은 잘 정의된 작업에는 predictable Workflow가, 경로를 미리 hardcode하기 어려운 open-ended problem에는 Agent가 더 적합하다고 구분한다. 따라서 Planning의 깊이도 과업의 불확실성과 실패 비용에 비례해야 한다. 복잡한 Plan이 더 좋은 Plan은 아니다.
언제 Planning을 쓰지 말아야 하는가
- 한 번의 Tool Call이나 답변으로 끝나는 작업
- 경로가 명확하고 code로 검증 가능한 deterministic Workflow
- 다음 Action이 싸고 가역적이며 즉시 ground truth를 얻을 수 있는 경우
- Plan을 저장·갱신·검증할 State mechanism이 없는 prototype
- Plan 작성 비용이 실제 실행 비용보다 큰 짧은 작업
이 경우에는 간단한 stop condition과 Tool Result 검증이면 충분하다. Planning이 없는 것이 아니라, 별도의 Plan artifact가 이익을 만들지 않는다는 뜻이다.
실무 적용 원칙
복잡한 실행 시스템에서는 거대한 계획서를 계속 넘기기보다 Goal·Constraint·Current State·Next Action·Expected Evidence·Open Blocker를 최소 단위로 유지하는 편이 낫다. 검토 결과가 Plan을 바꾸면 변경 이유와 영향 범위를 남기고, 실행 권한이 없으면 Planning으로 우회하지 않는다.
실무 Planning Checklist
- Goal과 non-goal, 변경할 수 없는 Constraint가 분리되어 있는가?
- 각 Step이 한 loop 안에서 실행·검증할 만큼 작은가?
- Step마다 dependency와 expected evidence가 있는가?
- progress report가 아니라 environment State로 완료를 판정하는가?
- local repair, partial Replan, full Replan의 trigger가 구분되는가?
- Permission·Approval 문제를 Replan으로 우회하지 않는가?
- Plan revision과 execution State, 변경 이유를 Trace할 수 있는가?
- 작업이 단순해지면 explicit Plan을 제거할 수 있는가?
- 별도 Planner Agent의 품질 이익이 coordination cost보다 큰가?
Design Rule: Plan은 미래를 고정하지 않는다. 다음 Action과 검증 evidence를 명확히 하고, 핵심 가정이 깨진 범위만 다시 계산한다.
이전 / 다음 / 관련 글
- Previous: AI Agent Memory와 Session의 차이: 무엇을 기억하고 무엇을 잊어야 하는가
- Next: AI Agent Routing이란 무엇인가: Model·Tool·Workflow를 어떻게 선택해야 하는가
- Related: Agent Loop란 무엇인가: AI Agent가 한 번의 답변으로 끝나지 않는 이유
- Related: AI Agent와 Workflow의 차이: 언제 Agent가 필요한가
공식 참고 자료
- OpenAI — Agents: multi-step work와 runtime 선택
- OpenAI — Run long horizon tasks with Codex
- Anthropic — Building effective agents
- Anthropic — Effective harnesses for long-running agents
- Anthropic — Harness design for long-running application development
문서 확인일: 2026-09-29. 위 long-running harness 사례는 coding domain의 실험·설계 보고이며 일반 production 성능을 보증하지 않는다. 구현 시 사용 중인 Model·SDK·Runtime의 최신 문서를 다시 확인해야 한다.