에이전트 오케스트레이션 운영 기준
에이전트 오케스트레이션은 LLM이 도구와 상태를 사용해 다음 행동을 자율적으로 정하게 만드는 구조다. 핵심은 workflow를 기본값으로 두고, 비용과 실패 모드가 정당화되는 비정형 작업에만 agent와 multi-agent를 신중히 쓰는 것이다.
Script Companion
오디오와 함께 스크립트 보기
- 01
에이전트 오케스트레이션은 단순한 chat이나 RAG, 한 번의 tool calling을 넘어선 문제에서 등장한다. 버그 리포트를 읽고, 관련 파일을 찾고, 수정하고, 테스트를 다시 돌리는 작업처럼 필요한 단계 수를 미리 알기 어려운 경우가 대표적이다. 한 번의 LLM 호출은 입력과 출력을 보강할 수는 있지만, 중간 결과를 보고 다음 행동을 계속 정하는 주체가 되기 어렵다. 그래서 에이전트는 결정, 행동, 관찰, 상태 갱신을 반복하는 루프로 문제를 푼다.
- 02
여기서 가장 먼저 나눠야 할 것은 workflow와 agent다. Anthropic의 Building effective agents 분류에서 workflow는 LLM과 tools를 사전에 정의된 코드 경로로 오케스트레이션하는 방식이다. 결정성과 재현성이 좋고, 디버깅도 쉽기 때문에 대부분의 production 작업에는 workflow가 충분하다. 반대로 agent는 LLM이 다음 행동과 도구 사용을 자율적으로 정한다. 유연하지만 호출 횟수와 실패 가능성이 같이 늘어나므로, open-ended problem일 때만 신중하게 고려한다.
- 03
workflow라는 말도 층을 구분해서 들어야 한다. Temporal, Step Functions, Airflow 같은 일반 workflow engine은 오래 걸리는 업무 절차를 실행하고 복구하는 인프라 계층에 가깝다. durable execution은 worker crash 뒤 어디서 재개할지를 다루는 실행 의미론이다. LLM workflow pattern은 chaining, routing, evaluator loop처럼 정해진 LLM과 tool 단계를 조합하는 방식이고, agent orchestration은 그 위나 옆에서 LLM이 어떤 step, tool, worker를 고를지 정하는 문제다. 같은 오케스트레이션이라도 관심사가 다르다.
- 04
Anthropic 분류의 workflow 패턴은 다섯 가지로 정리된다. Prompt Chaining은 작업을 여러 단계로 나누고 앞 단계 결과를 다음 입력으로 넘긴다. Routing은 입력을 분류해 알맞은 핸들러로 보낸다. Parallelization은 독립 sub-task로 나누거나 같은 작업을 여러 번 실행해 voting으로 합친다. Orchestrator-Workers는 중앙 LLM이 sub-task를 동적으로 정해 worker LLM에 맡긴다. Evaluator-Optimizer는 생성한 응답을 다른 LLM이 평가하고 피드백해 반복 개선한다.
- 05
Evaluator-Optimizer는 넓게 보면 critic loop다. generator가 초안을 만들고, critic 또는 evaluator가 기준에 맞춰 결함을 찾고, optimizer 또는 reviser가 다시 고친다. Debate, Review, Revise나 Self-Refine, Cross-Model Critic도 같은 계열로 볼 수 있다. 다만 critic loop가 의미 있으려면 비평 기준이 코드나 체크리스트로 표현 가능해야 한다. 기준이 모호하면 critic은 실제 품질보다 말투, 길이, 자신감 같은 표면 신호에 끌릴 수 있다.
- 06
agent의 자율 루프는 LLM, Tools, Memory, Planning, Termination으로 구성된다. LLM은 사고와 결정 엔진이고, Tools는 외부 세계에 영향을 주는 액션이다. Memory는 현재 대화와 도구 호출 history를 담는 short-term memory와, 여러 session 사이에 유지되는 long-term memory로 나뉜다. short-term memory는 context window 안에 있으므로 길어지면 비용과 lost-in-middle 문제가 생긴다. long-term memory는 vector DB나 key-value store 같은 외부 store에 맡기며, Mem0, Letta, Zep 같은 도구가 언급된다.
- 07
Planning 전략도 작업 성격에 맞춰 골라야 한다. Plan-and-Execute는 먼저 계획을 세우고 실행하는 방식이고, ReAct는 생각, 행동, 관찰을 명시적으로 반복한다. Tree-of-Thoughts는 여러 경로를 동시에 탐색하고 평가하며, Self-Reflect는 작업 뒤 자기 비판을 통해 개선한다. 하지만 이런 전략은 공짜가 아니다. 단발 답변에 ReAct를 쓰면 오버헤드가 커지고, 계획 변경이 잦으면 Plan-and-Execute는 replanning 비용이 커진다. 복잡 puzzle에는 Tree-of-Thoughts가 맞을 수 있지만 단순 작업에는 과하다.
- 08
multi-agent는 더 조심스럽게 봐야 한다. Supervisor 패턴은 supervisor가 작업을 나누고 통합하는 가장 일반적인 방식이고, Swarm은 여러 agent가 동등하게 통신하며, Sequential Pipeline은 agent A에서 B, C로 단방향 흐름을 만든다. Anthropic과 OpenAI 모두 먼저 single agent를 시도하고 부족하면 multi-agent를 쓰라고 권한다. multi-agent를 고려할 조건은 역할별 산출물이 자연스럽게 분리되고, 병렬 탐색 이득이 크며, 단일 context window에 모든 근거가 안정적으로 들어가지 않는 경우다.
- 09
multi-agent의 장점은 정량 수치와 함께 봐야 한다. Anthropic 자체 research system 보고에서는 agent가 chat 대비 약 4배, multi-agent가 약 15배 토큰을 쓸 수 있다고 설명한다. 같은 multi-agent 구성이 single-agent Opus 4 대비 breadth-first 연구 query에서 90.2% 성능 향상을 보였다는 결과도 있다. 하지만 Cognition의 Flappy Bird 사례처럼 subagent가 서로의 암묵적 결정을 보지 못하면 결과물이 충돌한다. 그래서 코딩처럼 공유 컨텍스트와 의존 관계가 큰 작업에서는 single-threaded linear agent가 더 낫다는 판단이 나온다.
- 10
production agent를 만들 때는 프레임워크 이름보다 선택 기준이 중요하다. agent loop를 graph나 state machine으로 볼 수 있는지, tool 권한과 격리를 넣기 쉬운지, step trace와 token, latency, retry를 남길 수 있는지를 확인해야 한다. LangGraph, CrewAI, AutoGen, OpenAI와 Claude SDK, Pydantic AI, Mastra, Vercel AI SDK, DSPy 같은 이름은 참고 대상이다. 운영 패턴으로는 state machine, event-driven step 발행, human-in-the-loop, checkpointing이 중요하다. 특히 이메일, 결제, 배포, DB write 같은 비가역 action은 사용자 승인 지점을 둬야 한다.
- 11
비용과 latency는 agent loop의 가장 큰 함정이다. max_iter가 없으면 루프가 끝나지 않고, 같은 tool을 반복 호출하면 context와 비용이 같이 커진다. workflow로 충분한데 agent를 쓰거나, reasoning 모델과 multi-agent를 함께 쓰면 비용 자릿수가 급격히 커질 수 있다. 절감의 기본은 workflow 우선, 단순 단계에는 smaller model routing, 시스템 prompt와 tool definition의 prompt caching, 큰 tool output의 summarization, 명확한 termination 조건이다. 빈번하고 입출력이 안정된 작업은 fine-tune, workflow, cache를 먼저 검토한다.
- 12
평가도 최종 답만 보면 부족하다. 표준 벤치마크로는 GitHub 이슈 해결을 보는 SWE-Bench Verified, multi-turn tool agent를 보는 τ-bench 또는 tau-bench, tool calling 정확도를 보는 BFCL v3가 언급된다. WebArena, OSWorld, GAIA, AgentBench도 web, OS 자동화와 다양한 도메인을 다룬다. production에서는 trajectory eval로 step-by-step trace를 보고, LangSmith, Langfuse, Arize, OpenLLMetry, Weights & Biases 같은 trace observability를 붙인다. 평균 step 수, 평균 비용, latency, success rate, recovery rate도 dashboard로 봐야 한다.
- 13
silent failure는 조용히 품질과 비용을 망가뜨린다. Stuck loop는 같은 tool 반복으로 나타나며 max_iter와 scratchpad history로 막는다. Wrong tool 선택은 tool description과 schema를 강화해야 한다. Memory contamination은 long-term memory에 잘못된 정보가 들어가 반복되는 문제라서 검증과 삭제 정책이 필요하다. Goal drift는 처음 목표에서 멀어지는 현상이므로 주기적으로 원본 query를 재확인한다. Cost runaway는 호출당, 요청당 budget과 alert로 제한하고, Permission abuse는 allowlist와 confirmation으로 피해 범위를 줄인다.
- 14
reasoning 모델은 agent 설계에서 별도의 선택지다. o1, DeepSeek-R1, Claude 4 thinking 같은 reasoning 모델은 자체 CoT가 내장되어 planning에 강할 수 있다. 문서에서는 token 비용이 5배에서 20배 비쌀 수 있지만 step 수가 줄어 합산 비용이 더 싸지는 경우도 있다고 본다. 결국 결정은 빈번한 정형 작업이면 workflow나 fine-tune 쪽으로, 비정형 작업이면 reasoning model 단발 또는 agent 쪽으로 간다. 정리하면 LLM agent는 state, tool, LLM 결정 loop이며, 일반 공식은 결정, 행동, 관찰, 갱신의 control loop다. 운영에서는 이 루프를 명시하고, 비용과 권한과 평가를 함께 묶어야 한다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 에이전틱 LLM의 컨텍스트 파이프라인 길이 미정
- 상태 머신으로 LLM 워크플로를 다루기 길이 미정
- AI 워크플로를 위한 Temporal Durable Execution 길이 미정
- Human-in-the-loop AI 워크플로 설계 길이 미정
- AI 앱의 온톨로지와 역량 모델링 길이 미정
- 심리측정으로 설계하는 SJT와 LLM 평가 길이 미정