AI 오케스트레이션 조사 보고서 | Agent & Workflow Orchestration

Research Report · AI Agent & Workflow Orchestration

AI 오케스트레이션 조사 보고서

LLM, 도구, 메모리, 워크플로우, 여러 에이전트를 하나의 서비스로 묶어 안정적으로 실행하기 위한 설계 개념과 구현 전략을 정리한 문서입니다. 특히 FastAPI 서버, Flutter 클라이언트, SSE/JSON Patch 스트리밍, 로컬 vLLM, 브라우저 자동화, 코드 실행기 같은 시스템을 만드는 상황에 맞춰 설명합니다.

최종 업데이트: 2026-04-25 대상: AI 서비스/에이전트 시스템 개발자 형식: 단일 HTML 문서

1. 핵심 요약

AI 오케스트레이션은 단순히 “LLM에게 프롬프트를 보내는 것”이 아니라, 여러 모델·도구·데이터·에이전트·상태를 조합해 하나의 안정적인 업무 흐름으로 실행하는 기술입니다.

핵심 개념

누가, 언제, 무엇을 실행할지 결정

어떤 에이전트가 실행되는지, 어떤 도구를 호출하는지, 실패하면 어떻게 복구하는지, 중간 상태를 어떻게 저장하는지를 관리합니다.

핵심 목표

자동화 + 통제 + 관찰 가능성

AI가 유연하게 판단하게 하되, 비용·보안·무한 루프·잘못된 도구 호출을 막기 위해 코드 기반 제어와 로그 추적이 필요합니다.

실무 결론

처음부터 완전 자율 에이전트로 만들지 않기

초기에는 결정론적 라우터와 명확한 도구 스키마로 시작하고, 이후 필요한 부분만 LLM 주도 의사결정으로 확장하는 방식이 안전합니다.

2. AI 오케스트레이션이란?

오케스트레이션은 원래 여러 서비스, 작업, 컨테이너, 데이터 파이프라인을 순서와 조건에 따라 실행하는 개념입니다. AI 시스템에서는 여기에 LLM의 추론, 도구 호출, 메모리, 사람 승인, 멀티 에이전트 협업이 추가됩니다.

OpenAI Agents SDK 문서에서는 에이전트 오케스트레이션을 “앱에서 어떤 에이전트가 어떤 순서로 실행되고, 다음에 무엇을 할지 어떻게 결정하는가”의 문제로 설명합니다. 실무적으로는 크게 두 방식이 있습니다.

LLM 주도

모델이 다음 행동을 결정

모델이 상황을 판단해 검색, 코드 실행, 브라우저 조작, 다른 에이전트 위임 등을 선택합니다. 유연하지만 예측 가능성이 낮고 검증 장치가 필요합니다.

코드 주도

개발자가 흐름을 결정

상태 머신, 그래프, if/else, 큐, 워크플로우 엔진으로 실행 순서를 통제합니다. 안정적이지만 복잡한 예외 상황에서는 유연성이 떨어질 수 있습니다.

추천 접근: 중요한 업무 흐름은 코드로 통제하고, 분류·요약·도구 선택·계획 수립처럼 모호성이 큰 부분만 LLM에게 맡기는 하이브리드 구조가 가장 현실적입니다.

3. AI 오케스트레이션의 핵심 구성 요소

구성 요소	역할	실무 예시
입력 분석기	사용자의 의도를 분류하고 필요한 작업 유형을 결정합니다.	일반 대화, 코드 실행, 웹 검색, DB 조회, 브라우저 자동화, 이미지 분석 등으로 라우팅
오케스트레이터	전체 실행 흐름을 지휘합니다.	라우터, 플래너, 상태 머신, LangGraph 그래프, CrewAI Flow, Microsoft Agent Framework Workflow
에이전트	특정 역할과 지시문, 사용할 수 있는 도구를 가진 LLM 실행 단위입니다.	검색 에이전트, 코드 리뷰 에이전트, 블로그 작성 에이전트, 주문 조회 에이전트
도구 레지스트리	LLM이 호출할 수 있는 함수와 스키마를 관리합니다.	브라우저 열기, 파일 읽기, SQL 실행, Python 코드 실행, 상품 API 조회
상태·메모리	진행 상황, 중간 결과, 대화 문맥, 장기 기억을 저장합니다.	thread_id, session_id, checkpoint, vector memory, Redis, PostgreSQL
가드레일	위험한 요청, 잘못된 도구 호출, 민감 정보 노출, 형식 오류를 차단합니다.	입력 검증, 출력 검증, tool approval, 관리자 승인, JSON schema validation
관측성	각 단계의 모델 호출, 도구 호출, 오류, 비용, 지연 시간을 추적합니다.	OpenTelemetry, LangSmith, OpenAI tracing, Logfire, 자체 trace 테이블
스트리밍 계층	실행 중인 진행 상황과 결과를 클라이언트에 실시간 전달합니다.	SSE, WebSocket, JSON Patch, token stream, tool event stream

4. 대표 설계 패턴

1) Router Pattern

사용자 요청을 분류해 적절한 에이전트나 도구로 보냅니다. “URL 접속해줘”는 브라우저 에이전트, “코드 실행해줘”는 코드 실행기로 보내는 식입니다.

2) Planner → Executor

플래너가 작업 계획을 만들고, 실행자가 각 단계를 수행합니다. 웹 조사, 블로그 자동 작성, 데이터 수집 파이프라인에 적합합니다.

3) Supervisor → Worker

상위 감독 에이전트가 여러 전문 에이전트에게 업무를 분배하고 결과를 취합합니다. 멀티 에이전트 시스템의 기본 구조입니다.

4) Handoff Pattern

한 에이전트가 자신보다 적합한 다른 에이전트에게 작업을 넘깁니다. 고객지원에서 환불, 주문조회, 기술지원 담당을 나누는 방식입니다.

5) Fan-out / Fan-in

여러 에이전트가 병렬로 조사하거나 답변을 만들고, 마지막에 하나의 결과로 합칩니다. 리서치, 코드 리뷰, 비교 분석에 유용합니다.

6) Human-in-the-loop

위험하거나 비용이 큰 행동 전에 사람 승인을 받습니다. 결제, 파일 삭제, 서버 명령 실행, 외부 서비스 변경 작업에 필수입니다.

5. 주요 프레임워크 비교

아래 표는 2026년 기준으로 많이 언급되는 AI 에이전트/오케스트레이션 프레임워크의 특징을 정리한 것입니다. 실제 선택은 언어 스택, 배포 환경, 필요한 통제 수준에 따라 달라집니다.

프레임워크	강점	적합한 경우	주의점
OpenAI Agents SDK	Agent, Tool, Handoff, Guardrail, Tracing 중심의 단순한 추상화	OpenAI 기반 에이전트 앱, 빠른 프로토타입, 도구 호출/위임 구조	OpenAI 생태계에 강하게 맞춰져 있으므로 로컬 LLM만 사용할 때는 별도 어댑터 설계 필요
LangGraph	상태 기반 그래프, durable execution, checkpoint, human-in-the-loop	장시간 실행, 복잡한 분기, 재시작 가능한 에이전트, 정확한 상태 제어	초기 학습 비용이 있고, 단순 챗봇에는 과할 수 있음
Microsoft Agent Framework	.NET/Python 지원, AutoGen+Semantic Kernel 계열의 통합 방향, 엔터프라이즈 기능	Microsoft/Azure/.NET 생태계, 기업용 멀티 에이전트, 관측성·보안이 중요한 서비스	버전 변화가 빠르므로 공식 문서 기준으로 API 확인 필요
AutoGen	대화형 멀티 에이전트, AgentChat, event-driven Core, 연구/실험에 강함	여러 에이전트가 토론하거나 협업하는 구조, 연구용 멀티 에이전트 실험	프로덕션 통제는 별도 설계가 필요할 수 있음
CrewAI	역할 기반 Agent, Crew, Flow 구조가 직관적	블로그 작성, 리서치, 영업/마케팅 자동화처럼 역할 분담이 명확한 업무	복잡한 상태 머신이나 낮은 수준 제어가 필요한 경우 보완 필요
Google ADK	프롬프트+도구에서 멀티 에이전트, 그래프 워크플로우, 평가·배포까지 확장	Gemini/Google Cloud 기반 에이전트, 엔터프라이즈 배포, 평가 파이프라인	Google 생태계 외부에서 쓸 경우 통합 비용 검토 필요
LlamaIndex Workflows	이벤트 기반 workflow, RAG·문서 처리와 결합이 쉬움	문서 검색, 지식 기반 자동화, RAG 에이전트, 비동기 이벤트 처리	범용 멀티 에이전트보다 문서/RAG 중심 워크플로우에서 강점
Pydantic AI	타입 안정성, 구조화 출력, 도구 파라미터 검증, Python 친화성	FastAPI/Pydantic 기반 백엔드, JSON 출력 검증이 중요한 업무	대형 멀티 에이전트 그래프 자체보다는 안전한 agent 단위 구현에 강점

6. FastAPI·Flutter·SSE 기반 실제 시스템 아키텍처

사용자가 만들고 있는 구조를 기준으로 보면, AI 오케스트레이션은 아래와 같은 파이프라인으로 설계하는 것이 좋습니다.

Flutter Client
사용자 입력

→

FastAPI Gateway
세션·권한 확인

→

Intent Router
작업 유형 분류

Tool Registry
브라우저·코드·DB·검색

↔

Orchestrator
상태 머신·그래프

↔

LLM Runtime
vLLM·OpenAI·기타 모델

Guardrails
승인·검증·제한

→

Event Stream
SSE / JSON Patch

→

UI Rendering
메시지·도구 결과 표시

권장 서버 모듈 구조

디렉터리	역할
`routes/ai_chat.py`	SSE 엔드포인트, 요청 검증, 응답 스트리밍
`orchestration/router.py`	사용자 의도 분류, 카테고리 선택, fallback 처리
`orchestration/engine.py`	각 단계 실행, 상태 관리, 도구 호출 순서 제어
`tools/registry.py`	도구 목록, JSON schema, 권한 요구사항, timeout 관리
`tools/browser.py`	Selenium/Playwright 기반 브라우저 자동화
`tools/code_runner.py`	Docker 기반 격리 코드 실행
`memory/checkpoint.py`	thread_id 기준 checkpoint 저장·복구
`observability/tracing.py`	모델 호출, 도구 호출, 오류, 비용, 지연 시간 기록

7. 구현 로드맵

1단계

결정론적 라우터부터 만들기

처음에는 LLM이 모든 것을 마음대로 고르게 하지 말고, 카테고리를 제한합니다. 예: chat, web_search, browser, code, database, file.

2단계

도구 스키마 고정

각 도구는 이름, 설명, 입력 JSON schema, 출력 schema, timeout, 권한 등급을 가져야 합니다. LLM에게 실제 함수 전체가 아니라 요약된 도구 정보만 전달합니다.

3단계

상태와 이벤트 분리

사용자에게 보여줄 메시지 이벤트와 서버 내부 상태를 분리합니다. UI는 /message, /tool_output, /status 같은 JSON Patch 이벤트만 받게 합니다.

4단계

승인 게이트 추가

파일 삭제, 결제, 서버 명령, 외부 글 등록, 브라우저 클릭 같은 작업은 사람 승인 또는 명시적 확인 후 실행합니다.

5단계

관측성 추가

모델 입력/출력, 도구 호출, 오류, token 사용량, 실행 시간, final answer를 trace_id로 연결해야 디버깅이 가능합니다.

6단계

평가 세트 구축

“URL 접속해줘”, “코드 실행해줘”, “블로그 글 작성해줘” 같은 대표 프롬프트를 테스트 세트로 만들어 라우팅 정확도를 지속적으로 측정합니다.

8. 예시 코드 구조

아래는 실제 구현 방향을 이해하기 위한 간단한 예시입니다. 핵심은 “LLM이 자유롭게 서버 함수를 직접 실행하는 것”이 아니라, 오케스트레이터가 검증된 도구만 실행하도록 만드는 것입니다.

8-1. 도구 정의 예시

from pydantic import BaseModel, Field
from typing import Literal, Any

class ToolSpec(BaseModel):
    name: str
    description: str
    category: Literal["browser", "code", "search", "database", "file"]
    input_schema: dict[str, Any]
    requires_approval: bool = False
    timeout_seconds: int = 30

TOOLS = [
    ToolSpec(
        name="open_browser_url",
        category="browser",
        description="격리된 브라우저에서 URL을 열고 페이지 정보를 반환한다.",
        input_schema={"type": "object", "properties": {"url": {"type": "string"}}, "required": ["url"]},
        requires_approval=False,
        timeout_seconds=20,
    ),
    ToolSpec(
        name="run_python_code",
        category="code",
        description="Docker 샌드박스에서 Python 코드를 실행하고 stdout/stderr를 반환한다.",
        input_schema={"type": "object", "properties": {"code": {"type": "string"}}, "required": ["code"]},
        requires_approval=True,
        timeout_seconds=15,
    ),
]

8-2. 라우팅 결과 DTO 예시

class RouteDecision(BaseModel):
    category: Literal["chat", "browser", "code", "search", "database", "file"]
    confidence: float = Field(ge=0, le=1)
    reason: str
    selected_tool: str | None = None

# LLM 또는 규칙 기반 분류기가 반드시 위 구조로만 응답하게 만든다.

8-3. SSE / JSON Patch 이벤트 예시

event: patch
data: {"op":"add","path":"/status","value":"라우팅 중"}

event: patch
data: {"op":"add","path":"/tool_calls/-","value":{"name":"open_browser_url","status":"running"}}

event: patch
data: {"op":"add","path":"/tool_output/-","value":{"summary":"페이지 제목과 주요 링크를 추출했습니다."}}

event: patch
data: {"op":"add","path":"/message","value":"요청한 페이지를 확인했습니다..."}

중요: 클라이언트에는 내부 stack trace, 서버 파일 경로, secret, raw prompt 전체를 보내지 않는 것이 좋습니다. 사용자 UI에는 요약된 진행 상태와 안전한 결과만 표시하세요.

9. 위험 요소와 대응 전략

위험	문제	대응 전략
무한 루프	모델이 계속 도구를 호출하거나 계획을 수정함	max_turns, max_tool_calls, timeout, 비용 제한 설정
잘못된 도구 호출	엉뚱한 API 호출, 잘못된 파라미터 생성	JSON schema 검증, enum 제한, 도구별 validator 추가
보안 위험	파일 접근, 서버 명령 실행, 브라우저 자동화 악용	Docker sandbox, 권한 등급, 승인 게이트, 네트워크 제한
환각	확인하지 않은 정보를 사실처럼 생성	검색/RAG 결과와 답변 근거 연결, 출처 표시, 불확실성 표현
상태 손실	장시간 작업 중 서버 재시작 시 진행 상황 유실	checkpoint, thread_id, idempotency key, resume 지원
디버깅 어려움	왜 그런 답을 했는지 추적이 안 됨	trace_id, 단계별 로그, 모델 입력/출력 요약, 도구 실행 기록 저장

10. 실무 체크리스트

요청 카테고리를 제한했는가? 예: chat, search, browser, code, database, file
LLM 라우팅 결과를 Pydantic/JSON Schema로 검증하는가?
도구마다 timeout, retry, permission level, output schema가 있는가?
위험 작업에 human approval 단계가 있는가?
모든 실행에 session_id, message_id, run_id, trace_id가 연결되는가?
SSE 스트리밍 이벤트와 내부 상태 저장 구조가 분리되어 있는가?
도구 결과를 그대로 사용자에게 노출하지 않고 요약·필터링하는가?
브라우저/코드 실행은 Docker 또는 별도 격리 환경에서 수행하는가?
장시간 작업을 checkpoint로 복구할 수 있는가?
대표 프롬프트 테스트 세트로 라우터와 오케스트레이터를 평가하는가?

11. 참고 자료

아래 자료를 기준으로 개념과 프레임워크 특징을 조사했습니다. 실제 구현 시에는 각 공식 문서의 최신 API를 다시 확인하세요.

'AI' 카테고리의 다른 글

Hermes WebUI 설치 및 사용법 총정리: Hermes Agent를 웹 브라우저와 모바일에서 사용하는 방법 (0)	2026.04.29
UI-TARS란? ByteDance가 공개한 GUI 자동화 AI 에이전트 모델 완벽 분석 (1)	2026.04.25
클로드 디자인 설치 및 사용법 완벽 가이드: Claude Design으로 UI·프로토타입·프레젠테이션 만드는 방법 (0)	2026.04.21
Hermes Agent 사용법 완벽 가이드: 설치부터 로컬 vLLM 연결까지 (3)	2026.04.20
PersonaPlex 7B 분석: NVIDIA의 풀듀플렉스 음성 AI, 강점과 한계 정리 (1)	2026.04.11

민서의 개발 블로그

AI 오케스트레이션 완벽 가이드: 멀티 에이전트, 워크플로우, 도구 라우팅, LangGraph·CrewAI·OpenAI Agents SDK 비교분석

AI 오케스트레이션 조사 보고서

1. 핵심 요약

누가, 언제, 무엇을 실행할지 결정

자동화 + 통제 + 관찰 가능성

처음부터 완전 자율 에이전트로 만들지 않기

2. AI 오케스트레이션이란?

모델이 다음 행동을 결정

개발자가 흐름을 결정

3. AI 오케스트레이션의 핵심 구성 요소

4. 대표 설계 패턴

1) Router Pattern

2) Planner → Executor

3) Supervisor → Worker

4) Handoff Pattern

5) Fan-out / Fan-in

6) Human-in-the-loop

5. 주요 프레임워크 비교

6. FastAPI·Flutter·SSE 기반 실제 시스템 아키텍처

권장 서버 모듈 구조

7. 구현 로드맵

결정론적 라우터부터 만들기

도구 스키마 고정

상태와 이벤트 분리

승인 게이트 추가

관측성 추가

평가 세트 구축

8. 예시 코드 구조

8-1. 도구 정의 예시

8-2. 라우팅 결과 DTO 예시

8-3. SSE / JSON Patch 이벤트 예시

9. 위험 요소와 대응 전략

10. 실무 체크리스트

11. 참고 자료

'AI' 카테고리의 다른 글

티스토리툴바

AI 오케스트레이션 완벽 가이드: 멀티 에이전트, 워크플로우, 도구 라우팅, LangGraph·CrewAI·OpenAI Agents SDK 비교분석

1. 핵심 요약

누가, 언제, 무엇을 실행할지 결정

자동화 + 통제 + 관찰 가능성

처음부터 완전 자율 에이전트로 만들지 않기

2. AI 오케스트레이션이란?

모델이 다음 행동을 결정

개발자가 흐름을 결정

3. AI 오케스트레이션의 핵심 구성 요소

4. 대표 설계 패턴

1) Router Pattern

2) Planner → Executor

3) Supervisor → Worker

4) Handoff Pattern

5) Fan-out / Fan-in

6) Human-in-the-loop

5. 주요 프레임워크 비교

6. FastAPI·Flutter·SSE 기반 실제 시스템 아키텍처

권장 서버 모듈 구조

7. 구현 로드맵

결정론적 라우터부터 만들기

도구 스키마 고정

상태와 이벤트 분리

승인 게이트 추가

관측성 추가

평가 세트 구축

8. 예시 코드 구조

8-1. 도구 정의 예시

8-2. 라우팅 결과 DTO 예시

8-3. SSE / JSON Patch 이벤트 예시

9. 위험 요소와 대응 전략

10. 실무 체크리스트

11. 참고 자료

'AI' 카테고리의 다른 글

'AI' Related Articles

티스토리툴바