오케스트레이션과 플래닝.

🧵 1. 개요.

• 코딩 에이전트에 "이 기능 만들어줘"만 던지면, 파일은 많이 바뀌는데 방향이 틀린 경우가 있다.

• 원인은 모델이 약해서만이 아니다. 어디까지 할지, 어떤 순서로 할지가 비어 있으면 에이전트가 스스로 길을 고르고, 그 선택이 쌓인다.

• 이 포스팅에서는 오케스트레이션 개념이 왜 필요해졌는지부터 보고, 오케스트레이션(여러 단계, 도구, 에이전트의 일을 맞춰 돌리는 일)과 그 앞의 플래닝이 왜 중요한지 정리해 본다.

  Anthropic, OpenAI, Cursor, ReAct 쪽 문서를 기준으로 본다.

한 줄로 요약하면, 오케스트레이션은 AI에게 맡기기 전에 "무엇을 어떤 순서로"를 먼저 고정하는 일이다.

📜 2. 개념이 생긴 배경.

처음부터 오케스트레이션이라는 말을 쓰던 건 아니다. ChatGPT가 막 나왔을 때는 채팅으로 물어보고 답 받는 게 거의 전부였다.

그다음엔 검색, 코드 실행, API처럼 도구를 부르는 쪽이 늘었다. 한 번에 완벽한 답을 받기보다, 생각하고 → 해보고 → 결과를 보고를 여러 번 도는 그림이 나왔다.

2022년 ReAct 논문이 그 이야기를 정리한 쪽에 가깝다. 추론과 행동을 번갈아 쓰라는 말이다. (ReAct, arXiv:2210.03629)

그런데 이 루프가 길어지면 이야기가 달라진다. 파일 여러 개, 검색 여러 번, 실패하면 다시 시도. 한 모델이 다 들고 가면 컨텍스트가 빨리 차고, 어디서 틀어졌는지도 잘 안 보인다.

Anthropic도 에이전트가 제대로 쓰이려면 복잡한 입력 이해, 추론과 계획, 도구 사용, 오류 복구가 어느 정도 되어야 한다고 적었다. (Building effective agents)

글을 읽다 보니 대략 이렇게 옮겨온 느낌이 들었다.

• 채팅 — 한 번 묻고, 한 번 답 받기. 말이 거의 전부다.

• 도구 호출 — 검색, 실행처럼 바깥 동작을 고르기 시작한다.

• 에이전트 루프 — 끝날 때까지 다음 행동을 스스로 고른다. 비용과 실패가 쌓이기 쉽다.

• 오케스트레이션 — 단계, 역할, 위임을 누가 어떻게 맞출지를 설계하는 쪽.

그래서 오케스트레이션은 유행어라기보다, 한 번의 좋은 답만으로는 안 되는 일을 다루려다 생긴 말에 가깝다.

OpenAI도 모델, 도구, 지시가 갖춰진 뒤에야 오케스트레이션 패턴을 고르라고 한다. 처음부터 에이전트를 여러 개 짜기보다 조금씩 가라는 말도 같은 이야기다. (A practical guide to building agents)

이전 포스팅의 하네스가 "어떤 환경에서 돌릴지"라면, 오케스트레이션은 "여러 스텝을 어떤 순서로 붙일지"다. 둘 다 프롬프트 한 줄 밖의 설계다.

🧭 3. 오케스트레이션이 가리키는 것.

에이전트 글에서 오케스트레이션은 거창한 프레임워크 이름보다, 일을 누가 어떻게 나누고 합치느냐에 가깝다.

Anthropic은 agentic 시스템을 둘로 나눈다. (Building effective agents)

• Workflow — LLM과 도구를 미리 정해 둔 코드 경로로 돌린다.

• Agent — LLM이 과정과 도구 사용을 동적으로 고른다.

OpenAI도 오케스트레이션을 한 덩어리로 보지 않고, 단일 에이전트 루프와 다중 에이전트 조율로 나눈다.

그리고 처음부터 복잡한 다중 에이전트보다 점진적으로 가는 쪽이 성공 사례가 많다고 적는다. (A practical guide to building agents)

내가 쓰는 말로 다시 쓰면 이렇다.

플래닝은 목표와 경계를 정하는 일이다. 오케스트레이션은 그 경계를 따라 단계, 도구, 하위 작업을 맞추는 일이다.

실행만 먼저 열면 플래닝 없이 오케스트레이션이 순서를 대신 발명한다.

📋 4. 왜 플래닝이 먼저인가.

Anthropic은 에이전트 구현 원칙 중 하나로 계획 단계를 드러내 투명하게 둘 것을 적는다.

에이전트는 작업이 분명해지면 스스로 계획하고 움직이되, 사람 피드백 지점과 중단 조건이 필요하다고도 한다. (Building effective agents)

Research 시스템에서는 더 구체적이다. 리드 에이전트가 쿼리를 보고 전략을 짠 뒤 서브에이전트를 만들고, 계획을 Memory에 남겨 컨텍스트가 잘려도 유지한다.

thinking으로 접근을 계획하게 하니 지시 따르기, 추론, 효율이 나아졌다고 적혀 있다. (How we built our multi-agent research system)

OpenAI 가이드는 지시(instructions)를 에이전트에서 특히 중요하다고 본다.

모호함을 줄이고, 작업을 더 작은 단계로 나누라고 한다. 오케스트레이션 패턴을 고르기 전에 모델, 도구, 지시가 먼저다. (practical guide)

Cursor Plan Mode도 같은 축이다. 코드를 쓰기 전에 코드베이스를 조사하고, 질문을 던지고, 검토 가능한 계획을 만든 뒤 Build한다.

복잡한 기능, 여러 파일, 요구가 흐릴 때 쓰라고 한다.

정리하면 플래닝은 문서 취향이 아니다. 경로의 폭을 줄이는 제어다.

🔀 5. Workflow와 Agent, 사람 플래닝의 자리.

Workflow는 경로가 코드에 고정된다. Prompt chaining처럼 "개요 → 검사 → 본문"처럼 분해가 이미 보이는 일에 잘 맞는다.

Anthropic도 chaining 예로 문서 outline을 검사한 뒤 쓰기를 든다.

같은 글에서 orchestrator-workers는 Agent가 아니라 Workflow 패턴이다. 가운데 LLM이 서브태스크를 동적으로 쪼개 worker에 맡기고 결과를 합친다.

코딩처럼 파일 수와 변경 성격이 입력마다 다를 때 쓰기 좋다고 적혀 있다.

Agent 절은 이와 별도로, 모델이 도구 루프 안에서 경로를 스스로 고르는 자율 실행을 말한다.

사람 플래닝은 둘 사이에 끼는 층이다.

• Workflow처럼 해야 할 일, 하지 말 일, 완료 조건을 먼저 글로 고정한다.

• Agent처럼 세부 파일 탐색과 패치는 모델에 맡긴다.

• 계획이 틀리면 코드를 고치기보다 플래닝을 고치고 다시 빌드하는 쪽이 싸다. Cursor도 잘못된 구현은 revert 후 플래닝을 다듬어 다시 돌리라고 한다.

이전 포스팅의 하네스가 환경, 게이트, 피드백이라면, 플래닝은 이번 세션의 작업 계약에 가깝다.

그림으로 보면 Workflow와 Agent의 자리, 그 사이에 사람 플래닝이 어떻게 앉는지 이렇다.

🛠️ 6. 코딩할 때 내가 쓰는 기준.

공식 문서의 말을 일상 작업으로 옮기면 대략 이렇다.

• 한 줄 요청으로 충분한 일 — 오타, 작은 카피, 이미 해본 패턴. Agent에 바로 넘겨도 된다. (Cursor, Claude Code 모두 익숙한 짧은 작업은 바로 실행이 맞다고 한다.)

• 경계가 필요한 일 — 여러 파일, API 모양 변경, 라우팅, 데이터 형식. 먼저 플래닝에 범위, 건드릴 경로, 검증 방법(테스트, lint, 화면)을 적는다.

• 병렬이 필요한 일 — 조사, 여러 독립 검색. Anthropic Research처럼 리드가 나눠 주고, 서브가 각자 컨텍스트를 쓰게 하는 쪽이 맞다.

  다만 코딩은 의존이 많아서 무조건 다중 에이전트가 답은 아니다. Anthropic도 코딩은 연구만큼 병렬화가 쉽지 않다고 명시한다.

• 오케스트레이션을 키울 때 — OpenAI 말대로 단일 에이전트에 도구를 늘려 검증한 뒤, 필요할 때만 manager / handoff로 간다.

실패할 때 자주 보는 패턴은 같다. 플래닝 없이 긴 Agent 세션을 돌리다가, 중간 결과가 목표와 어긋쳐도 이미 쓴 코드에 프롬프트로 덧칠한다.

그때는 실행을 멈추고 플래닝부터 다시 쓰는 편이 빠르다.

🧩 7. 한 줄로 남기는 기준.

• 오케스트레이션은 "에이전트를 여러 개 쓰는 기술"만이 아니다. 일을 나누고 합치는 설계다.

• 플래닝은 그 설계의 입구다. 모델에게 경로 발명을 전부 맡기지 않겠다는 뜻이다.

• 출처가 가리키는 공통점도 비슷하다. 단순하게 시작, 계획을 드러내기, 지시와 도구를 명확히, 복잡도는 이득이 보일 때만.

에이전트가 강해질수록, 대충 시킨 뒤 결과를 청소하는 비용도 커진다. 그래서 나는 요즘 큰 작업일수록 프롬프트 문장보다 플랜 한 장에 시간을 더 쓴다.

🔗 8. 참고 자료.

공식, 1차 자료

• ReAct: Synergizing Reasoning and Acting in Language Models — 추론과 행동을 번갈아 쓰는 에이전트 루프의 대표 축

• Building effective agents (Anthropic) — workflow vs agent, orchestrator-workers, 계획 단계 투명성

• How we built our multi-agent research system (Anthropic) — 리드가 계획 후 서브에이전트 위임, thinking으로 계획

• A practical guide to building agents (OpenAI PDF) — instructions, 점진적 오케스트레이션, single vs multi-agent

• Cursor Plan Mode — 코드 전 계획 검토, 복잡한 변경에 권장

• Claude Code best practices — 작은 수정은 plan 생략, 불확실·다중 파일일 때 plan

이 블로그

• 하네스 엔지니어링. — prompt / context / harness 층

• 에이전트가 읽는 문서. — 바깥 AI가 읽는 입구 파일