작업분해 – Tokamoda

AI 에이전트의 능력은 개별 작업 처리에서 멈추지 않는다. 복잡한 목표를 여러 단계의 작업으로 분해하고, 각 단계의 결과를 다음 단계로 연결하며, 예상치 못한 상황에서도 적응적으로 대응해야 한다. 이것이 바로 ‘워크플로’의 영역이다. 에이전트 워크플로는 단순한 순차 실행(sequential execution)이 아니다. 병렬 처리, 조건부 분기, 오류 복구, 상태 기억, 비용 최적화가 모두 어우러져야 한다.

Traditional workflow engines were built for humans: schedule → execute → monitor. But AI agents need something different: goal → decompose → coordinate → adapt. The workflow is not a pipe; it is a decision tree made executable.

이 글에서는 AI 에이전트의 워크플로를 어떻게 설계하고 운영할 것인가를 다룬다. 특히 멀티에이전트 환경에서 여러 에이전트가 하나의 목표를 위해 협력하는 상황을 중심으로 본다.

1. 에이전트 워크플로의 본질: 순차 실행에서 적응적 조율로
1. 목표 분해: 하나의 요청을 에이전트 태스크로 변환
1. 에이전트 조율: 병렬 처리와 의존성 관리
1. 상태 관리와 Context Window: 워크플로 메모리
1. 오류 복구와 Retry 전략
1. 비용 최적화: Context, API Calls, Model Selection
1. 모니터링과 관찰성: 지금 무슨 일이 일어나고 있나?
1. 실제 구현: Multi-Agent Workflow Framework
1. 프로덕션 운영: 장애 대응과 롤백
1. 결론: 에이전트 워크플로의 미래

1. 에이전트 워크플로의 본질: 순차 실행에서 적응적 조율로

기존 워크플로 엔진은 DAG(Directed Acyclic Graph) 기반이다: Task A → Task B → Task C. 각 태스크는 명확한 입출력을 가지고, 결과는 예측 가능하다. 하지만 에이전트 워크플로는 다르다.

불확실성: 에이전트의 행동 결과가 확률적이다
적응성: 중간 결과에 따라 다음 단계를 동적으로 결정해야 한다
조율: 여러 에이전트가 동시에 작동하며 서로를 대기해야 할 수 있다
비용 민감성: 각 API 호출, 각 모델 추론이 비용이다

예를 들어, 여행 계획 에이전트를 생각해보자. "3월에 서울에서 도쿄로 여행하는 일정을 짜달라"는 요청이 들어온다. 단순 DAG라면:

항공편 검색
숙박시설 검색
관광지 정보 수집
일정 작성

하지만 실제로는:

항공편 검색 중 비용이 높으면 날짜 변경 검토 (피드백 루프)
특정 숙박시설이 만석이면 대체 지역 재검토
여행자 선호도에 따라 관광지 선택 기준 동적 변경
전체 비용 초과 시 우선순위 재조정

이것이 에이전트 워크플로의 실상이다.

In the world of agents, a workflow is a conversation between intelligent actors, not a conveyor belt. Each step is negotiation: "I have data; what should we do next?"

2. 목표 분해: 하나의 요청을 에이전트 태스크로 변환

에이전트 워크플로의 첫 단계는 ‘목표 분해'(Goal Decomposition)다. 사용자의 고수준 요청을 에이전트가 실행할 수 있는 구체적 태스크로 쪼개는 과정이다.

원래 요청: "우리 팀의 분기별 성과를 분석하고, 문제점을 파악하고, 개선 방안을 제시해줄래?"

분해된 태스크:

데이터 수집 에이전트: 분기 데이터 모두 가져오기 (매출, KPI, 팀 목표 등)
분석 에이전트: 수집된 데이터를 기반으로 성과 지표 계산
인사이트 에이전트: 성과와 목표를 비교하여 갭 분석
제안 에이전트: 갭을 좁힐 수 있는 구체적 개선안 도출
리포트 에이전트: 종합 결과를 읽기 좋은 형식으로 정리

각 에이전트는 독립적으로 실행될 수 있지만, 순서와 의존성이 있다. 데이터 수집 없이 분석이 일어날 수 없고, 분석 없이 인사이트를 얻을 수 없다.

Decomposition is not about dividing equally; it is about finding natural seams. 어떤 부분은 병렬로 실행 가능하고(데이터 수집과 배경 분석), 어떤 부분은 순차적이어야 한다(인사이트 도출 후 제안 생성). 이 구조를 명확히 정의하는 것이 워크플로 설계의 핵심이다.

분해 규칙:

의존성이 없는 태스크는 병렬 실행 가능해야 한다
의존성이 있다면 대기 메커니즘이 필요하다
각 태스크는 정의된 입출력을 가져야 한다
실패 모드를 미리 상정해야 한다

3. 에이전트 조율: 병렬 처리와 의존성 관리

여러 에이전트가 동시에 움직인다면, 누가 언제 시작하고 언제 멈플 것인가? 이것이 조율(Coordination) 문제다.

병렬 실행 패턴:

패턴 1) Fan-out: 하나의 에이전트가 여러 서브 태스크를 병렬로 분산

마스터 에이전트가 "데이터 수집, 경쟁사 분석, 시장 트렌드 조사"를 동시에 실행
모든 결과가 돌아올 때까지 대기 (fan-in)

패턴 2) Pipeline: 에이전트 A의 출력이 B의 입력이 되고, B의 출력이 C의 입력

A (데이터 수집) → B (데이터 정제) → C (분석) 순차 실행
각 단계가 완료되어야 다음 단계 시작

패턴 3) Conditional Fork: 중간 결과에 따라 다른 경로로 분기

데이터 품질 검사 결과 → 좋음(바로 분석) / 나쁨(데이터 재수집)

동기화 메커니즘:

병렬 작업을 조율하려면 동기화 지점(synchronization point)이 필요하다. 예를 들어:

Semaphore: "3개의 에이전트 작업이 모두 완료될 때까지 다음 진행 금지"
Callback: "작업 완료 시 알려줘, 그럼 내가 다음 할 일을 시작할게"
Event Loop: "특정 이벤트 발생 시 트리거되는 작업들"

Coordination is cheap when explicit. 동기화를 코드로 명확히 표현하는 것이 암묵적 대기보다 훨씬 낫다.

실제 구현 예:

tasks = [
  fetch_data(),
  fetch_market_trends(),
  fetch_competitor_analysis()
]
results = await gather(*tasks)
next_agent_input = combine_results(results)
await next_agent(next_agent_input)

이렇게 구조화하면 언제 어디서 대기가 일어나는지 명확하고, 타임아웃이나 실패 처리도 간단해진다.

4. 상태 관리와 Context Window: 워크플로 메모리

에이전트는 이전 단계의 결과를 기억해야 한다. "우리가 지금까지 뭘 했나?"라는 상태를 추적하지 못하면, 각 에이전트는 처음부터 모든 정보를 다시 처리해야 한다.

상태의 세 가지 층:

전역 상태 (Global State): 전체 워크플로가 알아야 하는 정보
- 사용자 요청의 원본 텍스트
- 지금까지 수집된 데이터
- 완료된 단계들의 요약
에이전트 로컬 상태 (Agent Local State): 특정 에이전트만 필요한 정보
- API 호출 시의 마지막 캐시 상태
- 이전 시도에서 실패한 쿼리들
- 임시 변수들
컨텍스트 윈도우 (Context Window): LLM의 입력으로 전달되는 정보
- 모든 LLM 모델은 토큰 제한이 있다
- 무한정 상태를 넘길 수 없다
- "지금 이 에이전트가 알아야 할 것"을 선별해야 한다

Context Window 최적화:

Context window는 비용이다. GPT-4를 사용하면 input token도 비용인데, 불필요한 정보를 넘기면 낭비된다. 따라서:

중요한 정보만 선별: "우리가 찾던 게 뭐였지?" → 원본 요청 + 이전 단계 결과만
정보 압축: 긴 데이터셋은 요약본으로
다중 턴 활용: 동일 에이전트라면 메시지 히스토리 활용해서 반복 사용 최소화

상태 저장소:

상태를 어디에 저장할 것인가?

메모리: 빠르지만, 프로세스 재시작 시 손실
DB: 느리지만, 영구 보관 + 쿼리 가능
분산 캐시 (Redis): 빠르고 비교적 안전

대부분의 실시간 워크플로는 Redis + DB 조합을 사용한다: 핫 데이터는 Redis, 최종 결과는 DB에 저장.

In a multi-step workflow, state management is often more important than individual step quality. 한 단계에서 좋은 결과를 얻어도 상태를 잃으면, 다음 단계는 처음부터 시작해야 한다.

5. 오류 복구와 Retry 전략

모든 에이전트 호출이 성공하는 것은 아니다. 네트워크 오류, API 한계, 모델 혼동 등 다양한 이유로 실패한다. 워크플로가 견고하려면 오류 복구 전략이 필수다.

실패 유형:

일시적 실패 (Transient Failure): 다시 시도하면 성공할 가능성 있음
- API rate limit 초과 → 대기 후 재시도
- 네트워크 타임아웃 → 재접속
영구적 실패 (Permanent Failure): 다시 시도해도 절대 성공 불가
- 권한 없음 (401 오류)
- 잘못된 요청 형식 (400 오류)
부분 실패 (Partial Failure): 일부는 성공, 일부는 실패
- 10개의 데이터 소스 중 8개만 응답
- 3개의 병렬 작업 중 1개만 실패

Retry 전략:

for attempt in range(max_retries):
    try:
        result = await agent.execute(input)
        return result
    except TransientError as e:
        wait_time = min(300, 2 ** attempt)  # exponential backoff
        await sleep(wait_time)
    except PermanentError as e:
        raise  # 바로 실패로 처리
    except PartialError as e:
        return e.partial_result  # 부분 결과라도 사용

오류 격리 (Error Isolation):

한 에이전트의 실패가 전체 워크플로를 죽여서는 안 된다. 특히 병렬 실행할 때:

results = []
for agent in agents:
    try:
        r = await agent.run()
        results.append(r)
    except Exception as e:
        log_error(e)
        results.append(None)  # 또는 기본값

# 일부 실패해도 진행
if len([r for r in results if r is not None]) >= MIN_REQUIRED:
    proceed_with_results(results)
else:
    abort_workflow()

Graceful Degradation:

모든 정보가 필요한 건 아니다. 80%만으로도 진행할 수 있다면:

3개의 데이터 소스 중 2개만 응답해도 진행
우선순위가 낮은 분석은 스킵
대신 결과에 "이건 완전하지 않습니다"라는 주석 추가

This is the difference between fragile and robust systems. 모든 상황을 처리하려다 보면 복잡해지지만, "언제 실패할 수 있고 그때 어떻게 할 것인가"를 미리 정하면 훨씬 안정적이다.

6. 비용 최적화: Context, API Calls, Model Selection

에이전트 워크플로가 정말 ‘실제’ 운영에서 쓰이려면, 비용이 문제가 아니어야 한다. 각 에이전트의 각 단계가 비용을 소비한다.

비용 폭파 지점 (Cost Explosion Points):

불필요한 Context 전달
- "여행 일정 짜기" 작업에 회사의 전체 HR 데이터를 넘기기
- 솔루션: 필요한 정보만 추출해서 전달
중복 API 호출
- 데이터 수집 에이전트가 같은 API를 반복 호출
- 솔루션: 요청 캐싱, 배치 호출
무분별한 모델 사용
- 간단한 데이터 정제에 GPT-4 사용
- 솔루션: 작업 복잡도에 따라 모델 선택

모델 선택 프레임워크:

작업	추천 모델	이유
단순 분류	Haiku	빠르고 싸고 충분
데이터 추출	GPT-4o	일관성 좋음
창의적 제안	GPT-4	깊이 있음
복잡 추론	Opus	최고의 성능

응답 캐싱:

동일한 요청에 동일한 응답이 예상되면, 캐시하자:

"서울의 날씨" → 1시간은 캐시 유효
"Python 문법 설명" → 거의 영구적으로 캐시 가능
"실시간 주식 가격" → 캐시 금지

배치 처리:

여러 개의 작은 요청을 한 번에 처리:

# 비효율: 10개의 개별 호출
for item in items:
    await model.process(item)  # 10번 호출

# 효율: 1번의 배치 호출
result = await model.batch_process(items)

If you are not tracking cost per workflow run, you will be surprised by your bill. 비용을 명시적으로 측정하고, 각 결정이 비용에 미치는 영향을 이해해야 한다.

7. 모니터링과 관찰성: "지금 무슨 일이 일어나고 있나?"

워크플로가 돌아가는 동안, 무슨 일이 일어나고 있는가? 제시간에 완료될 것인가? 어디서 병목이 생기나?

추적할 메트릭:

지연 (Latency)
- 전체 워크플로 시간
- 각 에이전트별 실행 시간
- 대기 시간 (다른 에이전트를 기다리는 시간)
성공률 (Success Rate)
- 전체 워크플로 성공률
- 각 에이전트별 성공률
- 재시도 횟수
비용 (Cost)
- 전체 워크플로 비용
- 각 에이전트별 비용
- Token 사용량
품질 (Quality)
- 출력 결과 만족도 (사용자 피드백)
- 검증 실패율
- 재작업 요청률

로깅 전략:

{
  "workflow_id": "wf_20260304_001",
  "start_time": "2026-03-04T20:04:00Z",
  "steps": [
    {
      "agent": "DataCollector",
      "status": "completed",
      "duration_ms": 1234,
      "tokens_used": {"input": 150, "output": 320},
      "cost_usd": 0.045,
      "retry_count": 0
    }
  ],
  "total_cost_usd": 0.123,
  "total_duration_ms": 3690
}

알람 설정:

단일 에이전트가 30초 이상 걸리면 알림
전체 워크플로가 5분 이상 걸리면 알림
비용이 예상의 2배를 넘으면 알림

분석:

주간/월간으로 다음을 분석하자:

어느 에이전트가 가장 느린가?
재시도가 자주 발생하는 단계는?
비용 대비 성공률은?

These insights guide optimization. 데이터 없이는 추측만 한다. Observability가 없으면 개선도 없다.

8. 실제 구현: Multi-Agent Workflow Framework

이론을 코드로 옮기는 방법. 기본 구조부터 실행까지 체계적으로 설계하면, 대부분의 에이전트 워크플로를 표현할 수 있다.

class WorkflowEngine:
    def __init__(self):
        self.agents = {}
        self.state = {}
        self.log = []

    async def register_agent(self, name, agent):
        self.agents[name] = agent

    async def execute(self, initial_input):
        self.state['input'] = initial_input

        # Step 1: Decompose
        tasks = await self.decompose(initial_input)

        # Step 2: Execute with coordination
        results = {}
        for step in tasks:
            if step.dependencies:
                await self.wait_for(step.dependencies)

            result = await self.agents[step.agent_name].run(
                input=step.input,
                context=self.build_context(step)
            )
            results[step.name] = result
            self.state[step.name] = result

        # Step 3: Combine and return
        return await self.combine_results(results)

에이전트 정의도 명확해야 한다. 각 에이전트는 독립적으로 테스트 가능하고, 입출력이 명시적이어야 한다. 이렇게 구축된 시스템은 유지보수가 쉽고, 확장도 간단하다.

9. 프로덕션 운영: 장애 대응과 롤백

워크플로가 실제로 운영되면, 예상 밖의 상황이 자주 발생한다. 외부 API 장애, LLM API 오류, 상태 불일치, 예상 밖의 입력 등 다양한 문제가 발생할 수 있다.

각 문제에 대한 대응 전략을 미리 정의해야 한다. Checkpoint를 설정해서 실패 시 그곳부터 복구할 수 있도록 하고, Rollback 계획을 세워서 외부 시스템에 미친 영향을 되돌릴 수 있게 해야 한다.

모니터링과 알림도 중요하다. 워크플로가 느려지면, 비용이 초과하면, 오류율이 높아지면 즉시 알아야 한다. Production systems must be pessimistic. 실패할 것을 전제하고, 그 때를 대비하자.

10. 결론: 에이전트 워크플로의 미래

에이전트가 복잡한 일을 하려면, 워크플로가 필요하다. 단순한 순차 실행이 아니라, 적응적이고 견고하며 비용 효율적인 조율 체계.

핵심 원칙:

명확성: 각 단계, 각 의존성, 각 오류 처리 경로를 명시적으로 정의
복원력: 부분 실패를 견딜 수 있고, 빠르게 복구 가능해야 함
관찰성: 무엇이 일어나고 있는지 항상 추적 가능해야 함
비용 의식: 각 결정이 비용에 미치는 영향을 고려
사용자 중심: 결국 사람을 위한 결과를 만들어야 함

The future belongs to systems that can orchestrate intelligence at scale. 단일 에이전트의 능력은 제한적이지만, 잘 조직된 다중 에이전트는 인간 팀이 하는 일을 대체할 수 있다. 그 대체의 핵심이 바로 워크플로다.

Build workflows not as pipes, but as thinking systems. 입력을 받아서 출력을 내는 것이 아니라, 중간에 판단하고, 배우고, 적응하는 워크플로를 설계하자. 그것이 진정한 에이전트 워크플로다.

Tags: AI워크플로, 워크플로오토메이션, 에이전트조율, 상태관리, context-window, 작업분해, 병렬처리, workflow-orchestration, autonomous-coordination, decision-tree

[태그:] 작업분해

AI 에이전트 워크플로 설계: 멀티에이전트 조율에서 비용 최적화까지

목차