에이전틱 워크플로 (Agentic Workflows)의 4가지 설계 차원

AI 에이전트 (AI agent), AI 워크플로 (AI workflow), 그리고 에이전틱 워크플로 (agentic workflow)는 자주 혼용되는 용어들입니다. 어떤 사람들은 도구를 사용할 수 있는 모든 LLM을 에이전트라고 부릅니다. 다른 이들은 시스템이 스스로 오랫동안 실행될 수 있어야만 에이전트로 간주합니다. 정의가 일치하지 않을 때, "이것이 에이전틱한가 아닌가?"라고 묻는 것은 대개 아무런 도움이 되지 않습니다.

더 실용적인 접근 방식은 시스템을 몇 가지 관찰 가능한 설계 선택 사항으로 나누는 것입니다: 누가 다음 단계를 결정하는가, 실행 경로가 얼마나 고정되어 있는가, 여러 에이전트가 어떻게 협력하는가, 그리고 인간이 어디에서 개입하는가 하는 점들입니다.

아래의 네 가지 차원은 업계 표준이 아니며, 서로 배타적인 네 개의 사분면도 아닙니다. 이것은 단지 제가 에이전틱 워크플로 (agentic workflows)를 이해하기 위해 사용하는 좌표 세트일 뿐입니다. 동일한 시스템이라도 수준에 따라 다른 위치에 놓일 수 있으며, 작업의 성격과 관련된 리스크에 따라 변화할 것입니다.

첫째, 워크플로 (Workflow)와 에이전트 (Agent)를 분리해 봅시다

Anthropic의 분류는 좋은 시작점입니다:

워크플로 (Workflow): LLM과 도구들이 미리 정의된 코드 경로를 따라 실행됩니다.
에이전트 (Agent): LLM이 자신의 실행 프로세스와 도구 사용 방법을 동적으로 결정합니다.

이것이 유일한 정의는 아닙니다. 커뮤니티는 여전히 에이전트와 워크플로 사이의 경계가 어디인지에 대해 논쟁 중이며, 실제 세계의 시스템은 거의 항상 이 둘의 혼합 형태입니다. 예를 들어, 코드가 연구 프로세스의 대략적인 구조를 고정하는 동안, LLM은 각 단계에서 무엇을 검색할지 그리고 어떤 도구를 호출할지를 결정할 수 있습니다.

따라서 시스템 전체에 하나의 라벨을 붙이는 대신, 시스템이 어떻게 제어되는지를 명확하게 설명하는 것이 더 유용합니다.

차원 1: 누가 오케스트레이션 (Orchestration)을 제어하는가?

첫 번째 질문은 이것입니다: 다음에 무엇이 일어날지를 누가 결정하는가?

모드 (Mode)	설명 (Description)	적합한 경우 (Best for)
코드 주도형 (Code-driven)	코드가 시퀀스 (Sequence), 분기 (Branching), 재시도 (Retries), 중단 조건 (Stop conditions)을 제어하며, LLM은 특정 노드 (Nodes)만 처리합니다	명확한 규칙이 필요한 경우, 오류 발생 비용이 높은 경우, 안정적인 재현성 (Reproducibility)이 필요한 경우
...

OpenAI Agents SDK 또한 오케스트레이션 (Orchestration)을 LLM 주도형 (LLM-driven)과 코드 주도형 (Code-driven) 모드로 분리하며, 두 방식 모두 함께 사용될 수 있음을 명시적으로 언급합니다.

이 차원은 어떤 프레임워크를 사용하는지와는 무관하다는 점에 유의하세요. LangGraph, AutoGen, CrewAI 모두 여러 가지 오케스트레이션 스타일을 만들어낼 수 있습니다. 단순히 프레임워크를 안다고 해서 아키텍처를 결정할 수는 없습니다.

차원 2: 실행 경로 (Execution Path)는 얼마나 고정되어 있는가?

두 번째 질문은 이것입니다: 모든 실행이 동일한 경로를 따르는가?

모드 (Mode)	설명 (Description)	예시 (Example)
고정형 (Fixed)	단계와 순서가 사전에 정의됨	데이터 가져오기 (Fetch data) → 요약 (Summarize) → 검토 (Review) → 게시 (Publish)
...

조건부 분기 (Conditional branching)에는 LLM이 필요하지 않습니다. 일반적인 if-else 문으로도 충분히 작동합니다. 적응형 (Adaptive)이 통제되지 않는다는 의미는 아닙니다. 훌륭한 적응형 시스템은 여전히 예산 (Budgets), 권한 (Permissions), 중단 조건 (Stop conditions), 그리고 도구 경계 (Tool boundaries)를 갖추어 시스템을 제어 범위 내에 유지합니다.

한 가지 더: 고정형 (Fixed)이 곧 DAG (Directed Acyclic Graph)를 의미하는 것은 아닙니다. 재시도 (Retries), 수정 (Corrections), 또는 평가자-최적화 루프 (Evaluator-optimizer loop)가 발생하는 즉시 경로는 다시 순환할 수 있습니다. 진짜 질문은 "누가, 언제 경로를 결정하는가?"이지, "이것이 DAG인가?"가 아닙니다.

차원 3: 에이전트들은 어떻게 협업하는가?

세 번째 질문은 실제로는 두 가지를 다룹니다: 시스템 내에 얼마나 많은 독립적인 에이전트 (Independent agents)가 있는지, 그리고 그들이 서로에게 어떻게 업무를 전달하는지입니다.

모드 (Mode)	설명 (Description)	주요 비용 (Main cost)
단일 에이전트 (Single Agent)	하나의 에이전트가 동일한 작업 상태 (Task state) 내에서 여러 도구를 사용하거나 서로 다른 기술을 로드함	컨텍스트 (Context)가 너무 커질 수 있음; 역할 경계가 약함
...

멀티 에이전트 (Multi-agent)가 "LLM을 여러 번 호출하는 것"을 의미하지는 않습니다. 단일 에이전트도 많은 모델 호출을 수행할 수 있습니다. 어떤 시스템이 멀티 에이전트인지 결정하는 기준은 각 단위가 자신만의 고유한 지침 (Instructions), 컨텍스트 (Context), 도구 (Tools), 상태 (State) 또는 책임 경계 (Responsibility boundary)를 가지고 있는지 여부입니다.

프레임워크가 토폴로지 (Topology)와 일대일로 대응되는 것도 아닙니다. 예를 들어, AutoGen Teams는 라운드 로빈 (Round-robin), 모델 선택기 (Model selector), 스웜 (Swarm), 그래프 플로우 (Graph flow)를 모두 동시에 제공합니다. AutoGen이나 CrewAI를 사용한다고 해서 "중앙 통제가 없고 행동이 자연스럽게 창발 (Emergence)된다"고 가정하는 것은 단순히 잘못된 생각입니다.

차원 4: 인간은 어디에서 개입하는가? (Where Do Humans Step In?)

자율성 (Autonomy)은 에이전트가 연속해서 얼마나 많은 단계를 수행할 수 있는지로 측정해서는 안 됩니다. 세 번의 도구 호출 (Tool calls)이 운영 데이터를 삭제할 수도 있는 반면, 30번의 읽기 전용 검색은 거의 위험이 없을 수도 있습니다. 더 나은 측정 기준은 다음과 같습니다: 어떤 작업에 승인이 필요하며, 실수가 발생했을 때 얼마나 복구 가능한가?

모드 (Mode)	설명 (Description)	일반적인 제어 수단 (Common controls)
인간 트리거 방식 (Human-triggered)	인간이 각 주요 작업을 결정하며, AI는 제안이나 초안을 제공함	미리보기 (Preview), 단계별 확인 (Step-by-step confirmation)
...

고도로 자율적인 시스템이라 할지라도 "책임질 사람이 없다"는 뜻은 아닙니다. 프로덕션 환경에서는 관측 가능성 (Observability), 장애 처리 (Failure handling), 권한 격리 (Permission isolation), 그리고 실행 후 감사 (Post-run auditing)가 여전히 필요합니다.

네 가지 일반적인 조합

네 가지 차원을 모두 결합해 보면, 실제 현장에서 나타나는 모습은 단일한 성숙도 사다리가 아니라, 서로 다른 작업 유형에 맞춰진 몇 가지 조합이라는 것을 알게 될 것입니다.

1. 검토 가능한 연구 파이프라인 (Reviewable Research Pipeline)

단일 에이전트 (Single Agent) × 하이브리드 (Hybrid) × 대부분 고정됨 (Mostly Fixed) × 체크포인트 방식 (Checkpointed)

코드 또는 문서가 연구 단계를 정의합니다. LLM은 각 단계에서 검색, 분석 및 작성을 처리합니다. 인간은 출처, 결론 및 게시를 검토합니다. 이 설계는 최대의 자율성을 목표로 하지는 않지만, 재현이 쉽고 버전 관리가 가능하며 중단 후 재개하기 용이합니다.

2. 결정론적 배치 처리 (Deterministic Batch Processing)

Single Agent × Code-driven × Conditional × Goal-driven within guardrails

코드가 스케줄링, 재시도 및 데이터 흐름을 처리합니다. LLM은 분류, 추출 또는 텍스트 판단만을 수행합니다. 고객 서비스 라우팅, 문서 분류 및 계약 필드 추출에 적합합니다.

3. 단일 적응형 에이전트 (Single Adaptive Agent)

Single Agent × Model-driven × Adaptive × Checkpointed

에이전트는 오류 메시지를 읽고, 코드를 수정하며, 테스트를 실행하고, 결과에 따라 다음 단계를 결정합니다. 이는 탐색 및 디버깅 (Debugging)에 효과적이지만, 파괴적인 작업, 외부 게시 또는 민감한 데이터 처리 전에는 여전히 인간의 확인을 위해 일시 중지해야 합니다.

4. 매니저-워커 병렬 연구 (Manager-Worker Parallel Research)

Multi-Agent × Model-driven Manager × Adaptive × Checkpointed

중앙 에이전트가 연구 질문을 여러 부분으로 나누어 여러 워커 (Worker)에게 병렬로 처리하도록 보내고, 이후 이를 통합하고 공백을 채웁니다. Anthropic의 공개 멀티 에이전트 연구 시스템은 완전히 분산된 스웜 (Swarm) 방식이 아니라, 정확히 이러한 오케스트레이터-워커 (Orchestrator-worker) 아키텍처를 사용합니다.

커뮤니티와 연구계의 의견은 어떠한가?

"멀티 에이전트 (Multi-agent)가 항상 더 낫다"라는 합의된 의견은 없지만, 공식 문서, 연구 논문 및 개발자 토론 전반에서 몇 가지 신호가 지속적으로 나타나고 있습니다.

가장 단순한 아키텍처부터 시작하라

Anthropic은 먼저 작동 가능한 가장 단순한 솔루션을 찾고, 실제로 필요할 때만 에이전틱 복잡성 (Agentic complexity)을 추가할 것을 권장합니다. AutoGen의 문서 또한 먼저 단일 에이전트를 최적화하고, 단일 에이전트만으로는 충분하지 않다는 것이 확인된 후에만 팀 단위로 이동할 것을 제안합니다.

Anthropic의 기사에 대한 The Hacker News의 토론은 대체로 단순하고 결합 가능한 (composable) 워크플로에 동의했지만, 두 가지 사항을 추가했습니다. 첫째, 인간 참여형 (Human-in-the-Loop) 방식은 긴 대기 시간, 재시도, 반복 실행을 초래한다는 점입니다. 둘째, 프로덕션 시스템은 단순히 프롬프트와 모델 루프 (model loop)에만 의존할 수 없으며, 내구성이 있는 실행 (durable execution), 상태 관리 (state management), 그리고 관찰 가능성 (observability)이 필수적이라는 점입니다.

멀티 에이전트에는 조정 비용 (Coordination Tax)이 따른다

에이전트를 하나 더 추가하는 것은 단순히 모델 호출을 한 번 더 하는 것이 아닙니다. 이는 컨텍스트 전달 (context transfer), 결과 통합 (result integration), 오류 전파 (error propagation), 지연 시간 (latency), 그리고 더 높은 디버깅 비용을 수반합니다. 멀티 에이전트가 실제로 이득을 주는 경우는 대개 다음과 같습니다:

작업을 명확하게 분할하여 병렬로 실행할 수 있는 경우.
각 하위 작업이 크고 격리된 컨텍스트 블록을 필요로 하는 경우.
서로 다른 에이전트가 서로 다른 도구 (tools), 권한, 또는 책임 경계가 필요한 경우.
단일 에이전트가 너무 많은 도구를 가지거나 컨텍스트가 너무 길어져 성능 저하가 이미 시작된 경우.

2025년 논문인 Towards a Science of Scaling Agent Systems는 260개의 구성을 비교하였으며, 멀티 에이전트 설정이 병렬화 가능한 작업에는 도움이 될 수 있지만, 조정 오버헤드 (coordination overhead)로 인해 순차적 추론 (sequential reasoning) 작업에서는 실제로 성능이 퇴보할 수 있음을 발견했습니다. 이는 고정된 컴퓨팅 예산 내에서 6개의 에이전틱 벤치마크를 통해 얻은 통제된 결과이며, 모든 제품에 적용되는 보편적인 규칙으로 받아들여져서는 안 됩니다. 더 신뢰할 수 있는 교훈은 다음과 같습니다: 아키텍처를 작업의 성격에 맞추십시오. 에이전트의 수가 곧 능력의 척도는 아닙니다.

"완전 자동화"가 유일한 목표는 아니다

금융, 의료, 법률, 결제, 그리고 공식적인 데이터 수정 시나리오에서 체크포인트가 설정된 (Checkpointed) 방식은 종종 일시적인 타협안이 아닙니다. 그것은 처음부터 올바른 제품 선택입니다. 적절한 자율성 수준은 자율성 점수가 얼마나 높은가가 아니라, 리스크, 가역성 (reversibility), 그리고 책임이 어디에 있는가에 따라 결정되어야 합니다.

실제 사례: 나의 투자 조사 리포지토리 (Repo)

저의 개인적인 tw-stock-researcher가 이러한 조합에 가장 가깝습니다:

Single Agent × Hybrid × Mostly Fixed × Checkpointed

기술(Skills)은 마크다운(Markdown) 문서로 정의되며, LLM은 작업에 필요한 능력만을 로드합니다.
전체적인 방향은 고정되어 있습니다: 사례 초기화(case init) → 데이터 가져오기(data fetching) → 분석(analysis) → 결론(conclusions) → 시장 관찰(market observation) 순서로 진행됩니다.
각 단계 내에서 LLM은 데이터 품질에 따라 어떤 도구를 사용할지, 얼마나 깊게 파고들지를 여전히 결정할 수 있습니다.
출력물은 사람이 검토하기 쉽고, 버전 관리(version control)가 가능하며, 세션 간 재개가 용이하도록 구조화된 마크다운(Markdown) 형식으로 저장됩니다.

저는 원래 이를 LLM-as-Orchestrator × Fixed DAG라고 설명했으나, 이는 정확하지 않았습니다. 더 정확한 설명은 다음과 같습니다: 매크로 흐름(macro flow)은 고정되어 있고, 로컬 경로(local paths)는 LLM에게 맡깁니다. 문서는 제약 조건(constraints)을 처리하고, 코드와 인간이 경계(boundaries)를 지킵니다. 이러한 하이브리드(hybrid) 설계는 연구 작업에 유효한데, 그 이유는 보통 "완전 자동화"보다 "검토 가능성(reviewable)"이 더 중요하기 때문입니다.

어떻게 선택해야 할까요?

에이전틱 워크플로(agentic workflow)를 설계할 때, 다음 여섯 가지 질문을 순서대로 검토할 수 있습니다:

이 문제를 일반적인 코드로 안정적으로 해결할 수 있는가? 결정론적인(deterministic) 부분은 먼저 결정론적인 코드에 맡기십시오.
입력과 경로의 변동성이 얼마나 큰가? 변동성이 낮으면 고정된 흐름(fixed flow)을 의미하며, 변동성이 높으면 모델이 동적으로 계획(plan)하도록 합니다.
작업을 실제로 분할할 수 있는가? 멀티 에이전트(multi-agent)를 사용할 때 발생하는 추가 비용은 작업이 병렬로 실행될 수 있거나, 격리(isolation)가 필요하거나, 서로 다른 권한(permissions)을 요구할 때만 의미가 있습니다.
실패 비용은 얼마이며, 얼마나 되돌릴 수 있는가(reversible)? 위험도가 높거나 되돌릴 수 없는 작업은 반드시 승인 체크포인트(approval checkpoints)와 권한 제한이 있어야 합니다.
문제가 발생했을 때 어디인지 파악할 수 있는가? 모든 단계는 가시적인 입력(inputs), 출력(outputs), 상태(state), 그리고 중단 이유(stop reasons)를 가져야 합니다.
복잡성을 감수할 만큼의 가치가 있다는 것을 보여주는 평가(eval)가 있는가? 성공률, 비용, 지연 시간(latency), 그리고 수동 수정 노력(manual correction effort)을 비교하십시오. 데모가 얼마나 인상적으로 보이는가로 판단하지 마십시오.

결론 (Conclusion)

"에이전틱 (Agentic)"은 아키텍처의 이름이 아니며, 시스템에 붙이는 성숙도의 배지도 아닙니다. 실제로 정보를 담고 있는 네 가지 질문은 다음과 같습니다:

다음 단계가 코드(code)에 의해 결정되는가, 모델(model)에 의해 결정되는가, 아니면 둘 다 함께 결정되는가?
경로가 고정되어 있는가, 조건부인가, 아니면 런타임(runtime)에 동적으로 생성되는가?
단일 에이전트(single agent)인가, 관리자-작업자(manager-worker) 구조인가, 핸드오프(handoff) 방식인가, 아니면 분산형 협업(decentralized collaboration) 방식인가?
어떤 위험 지점에서 인간이 개입하며, 시스템은 어떤 가드레일(guardrails)을 갖추고 있는가?

이 질문들에 명확히 답할 수 있을 때, 시스템의 비용, 위험, 그리고 유지보수성(maintainability)을 파악할 수 있습니다. 훌륭한 에이전틱 워크플로 (Agentic workflow)는 가장 많은 자율성이나 가장 많은 에이전트를 가진 것이 아닙니다. 작업이 유연성을 필요로 하는 곳에서는 유연성을 유지하고, 그렇지 않은 곳에서는 결정론적 (deterministic)인 상태를 유지하는 워크플로입니다.