AI 에이전트를 구축하는 모든 팀은 결국 동일한 벽에 부딪힙니다. 첫 번째 에이전트는 아주 잘 작동합니다. 두 번째 에이전트도 아주 잘 작동합니다. 그러다 누군가 두 에이전트가 서로 대화하고, 상태를 공유하며, 워크플로 중간에 발생하는 실패를 견뎌내도록 요청하면 전체 시스템이 무너져 버립니다.

이것은 아무도 데모에서 보여주지 않는 부분인 오케스트레이션 (Orchestration)입니다. "LLM이 도구를 호출할 수 있는가"의 문제가 아니라, "4개의 서로 다른 팀이 3개의 서로 다른 프레임워크로 구축한 12개의 에이전트가 의존성, 재시도 (Retries), 롤백 (Rollback), 그리고 컴플라이언스 팀이 실제로 수용할 수 있는 감사 추적 (Audit trail)을 갖춘 비즈니스 프로세스를 신뢰성 있게 실행할 수 있는가"의 문제입니다.

이 포스트에서는 멀티 에이전트 시스템을 단순한 프로토타입 수준이 아닌 프로덕션 등급으로 만드는 아키텍처 패턴을 살펴봅니다.

문제점: 에이전트 확산 (Agent sprawl)

대부분의 조직은 에이전트를 구축하는 데 실패하는 것이 아닙니다. 에이전트가 몇 개 이상 늘어났을 때 이를 관리하는 데 실패하는 것입니다.

전형적인 증상:

• 에이전트들이 사일로 (Silos) 형태로 구축되어, 각자 고유한 재시도 로직을 갖거나 혹은 아예 없음
• 공유된 카탈로그가 없어 어떤 에이전트가 존재하며 무엇에 의존하는지 아무도 모름
• 생명주기 가시성(Lifecycle visibility) 부재로 에이전트가 조용히 작동을 멈춰도 며칠 동안 아무도 알아차리지 못함
• 에이전트가 특정 행동을 취했을 때 감사 추적 (Audit trail)이 없어 왜 그런 행동을 했는지 아무도 설명할 수 없음

해결책은 "더 나은 에이전트를 작성하는 것"이 아닙니다. 에이전트와 비즈니스 프로세스 사이에 위치하며, 의존성 해결, 장애 처리, 그리고 거버넌스 (Governance)를 사후에 덧붙이는 고려 사항이 아닌 일급 시민 (First-class concerns)으로 취급하는 오케스트레이션 레이어를 도입하는 것입니다.

참조 아키텍처 (Reference architecture)

다음은 프로덕션 오케스트레이션 레이어의 형태입니다:

실질적인 작업을 수행하는 5가지 구성 요소

에이전트 레지스트리 (Agent registry) — 모든 에이전트의 버전, 입력/출력, 소유자를 담은 단일 카탈로그입니다. 등록되지 않은 에이전트는 실행되지 않습니다.

의존성 그래프 해결사 (Dependency graph resolver) — 실행 순서를 결정합니다. 일부 에이전트는 병렬로 실행될 수 있지만, 어떤 에이전트는 다른 에이전트가 완료될 때까지 시작할 수 없습니다.

실행 엔진 (Execution engine) — 실제로 에이전트를 호출하고, 타임아웃 (timeout)을 관리하며, 실패 시 오류 처리기 (error handler)로 넘깁니다.

오류 처리기 (Error handler) — 재시도 (retry)를 할지, 보상 (compensate)을 할지, 아니면 즉시 실패 (fail-fast)할지를 결정합니다.

거버넌스 레이어 (Governance layer) — 모든 것을 기록하고, 액세스 제어 (access control)를 강제하며, 테넌트 (tenant)당 에이전트별 비용을 할당합니다.

의존성 관리: 스크립트가 아닌 DAG로 취급하세요

**

가장 흔한 실수는 애플리케이션 코드에 에이전트 실행 순서를 하드코딩하는 것입니다. 이는 에이전트 #7이 에이전트 #3의 출력에 따라 조건부로 실행되어야 하는 상황이 오기 전까지는 잘 작동하지만, 그 시점이 되면 복잡하게 얽힌 if/else 체인을 유지보수해야 하는 상황에 직면하게 됩니다.

대신 이를 방향성 비순환 그래프 (DAG, Directed Acyclic Graph)로 모델링하세요:

단순화된 의존성 그래프 정의

workflow = {  
"extract_data": {"depends_on": []},  
"validate_data": {"depends_on": ["extract_data"]},  
"risk_score": {"depends_on": ["validate_data"]},  
"compliance_check": {"depends_on": ["validate_data"]},  
"final_decision": {"depends_on": ["risk_score", "compliance_check"]},  
}

def resolve_execution_order(workflow):  
    """위상 정렬 (Topological sort) — 병렬로 실행 가능한 배치 (batch)를 반환합니다."""
    completed = set()  
    batches = []

while len(completed) < len(workflow):
    ready = [
        agent for agent, meta in workflow.items()
... 

Output: [['extract_data'], ['validate_data'], ['risk_score', 'compliance_check'], ['final_decision']]

_risk_score_와 _compliance_check_는 서로에게 의존하지 않으므로 병렬로 실행됩니다. 이는 단순한 오케스트레이션 스크립트들이 완전히 놓치기 쉬운, 성능을 높일 수 있는 기회입니다.

오류 복구: 재시도는 전략이 아니라 하나의 도구일 뿐입니다

**

에이전트(Agents)는 전통적인 서비스와는 다르게 실패합니다. LLM 호출은 "성공" (200 OK)할 수 있지만, 환각(hallucination)이 발생하거나 잘못된 형식의 결과를 반환할 수 있습니다. 도구 호출(tool call)은 트랜잭션 중간에 타임아웃이 발생하여 외부 상태(external state)를 절반만 변경된 상태로 남겨둘 수 있습니다. 단순한 try/retry 로직은 두 경우 모두 제대로 처리하지 못합니다.

더욱 견고한 오류 처리 흐름:

첫날부터 구축할 가치가 있는 세 가지 패턴:

백오프(backoff)를 포함한 제한된 재시도(Bounded retries) — 무한히 재시도하지 마세요. 횟수를 제한하고 모든 시도를 로그로 남겨야 합니다.

예외 처리뿐만 아니라 출력 검증(Output validation) — 확신을 가지고 잘못된 데이터를 반환하는 에이전트는 에러를 던지는 에이전트보다 더 위험합니다. 단계를 완료로 표시하기 전에 스키마(schema), 신뢰도 점수(confidence scores), 그리고 타당성 범위(sanity bounds)를 검증하세요.

침묵하는 실패가 아닌 보상 작업(Compensating actions) — 만약 4번 에이전트가 실패하기 전에 다운스트림 시스템을 부분적으로 업데이트했다면, 그것이 멱등성(idempotent)을 가질 것이라고 희망하는 대신 명시적인 롤백(rollback) 단계가 필요합니다.

**거버넌스(Governance): 모든 결정을 사후에 설명 가능하게 만드세요

**

이것은 감사자(auditor), 보안 검토, 또는 고객이 "시스템이 왜 그렇게 동작했나요?"라고 물을 때까지 팀들이 건너뛰는 계층입니다. 적절한 거버넌스 및 제어 레이어(governance and control layer)는 실시간 감독을 제공하고, 가드레일(guardrails)을 강제하며, 프로덕션에서 실행되는 모든 에이전트에 대해 킬 스위치(kill switch)를 제공해야 합니다.

최소한, 거버넌스 레이어는 에이전트 호출당 다음 사항을 캡처해야 합니다:

• 누가/무엇이 트리거했는가 (사용자, 시스템, 상위 에이전트)
• 입력 및 출력 (필요한 경우 개인정보(PII) 마스킹 포함)
• 사용된 모델/버전 및 신뢰도 점수
• 테넌트(Tenant) 및 역할(role) 컨텍스트 (멀티 테넌트 시스템의 경우)
• 특정 에이전트 및 워크플로우에 할당된 비용 및 토큰 사용량

audit_entry = {
"trace_id": "wf-8842-a1",
"agent": "risk_score",
"version": "2.3.1",
"tenant_id": "acme-corp",
"triggered_by": "compliance_check_workflow",
"input_hash": "sha256:...",
"output": {"score": 0.82, "confidence": 0.91},
"tokens_used": 1240,
"cost_usd": 0.0186,
"timestamp": "2026-07-14T09:12:03Z",
"status": "completed"
}

이 로그를 위한 불변(Immutable) 및 추가 전용(append-only) 저장소(나중에 수정할 수 있는 가변적인 데이터베이스 행이 아닌 방식)는 "우리는 로깅을 하고 있다"라는 상태를 "우리는 감사를 통과할 수 있다"라는 상태로 바꾸어 놓습니다.

종합하기 (Putting it together)

여기 다루는 내용 중 이례적인 것은 없습니다. 이는 분산 시스템 엔지니어들이 수년간 마이크로서비스(Microservices)에 적용해 온 엄격함(서킷 브레이커 (Circuit breakers), DAG 기반 워크플로우 엔진 (DAG-based workflow engines), 감사 로깅 (Audit logging))을 새로운 종류의 비결정론적(Non-deterministic) "서비스"인 AI 에이전트에 적용한 것뿐입니다.

핵심 요약 (Takeaways)

실행 순서를 모델에 하드코딩하지 마세요 — 의존성을 DAG(유향 비순환 그래프, Directed Acyclic Graph)로 관리하여 독립적인 에이전트들이 병렬로 실행되게 하고, 에이전트가 추가되더라도 그래프의 유지보수성을 유지하세요.

재시도 로직(Retry logic)만으로는 오류 처리가 되지 않습니다 — 출력을 검증하고, 부분적인 실패에 대비한 명시적인 보상 작업(Compensating actions)을 구축하세요.

거버넌스(Governance)는 단순한 컴플라이언스(Compliance) 체크리스트가 아닙니다 — 에이전트별 비용 귀속(Cost attribution) 정보가 포함된 불변의 감사 로그(Immutable audit logs)가 있어야 운영 환경의 장애를 디버깅하고 보안 검토를 통과할 수 있습니다.

에이전트 레지스트리(Agent registry)를 단일 진실 공급원(Single source of truth)으로 취급하세요. 에이전트가 등록되어 있지 않다면, 실행될 수 없어야 합니다.

멀티 에이전트 AI를 실제 운영 환경에 도입하는 팀은 가장 영리한 프롬프트를 가진 팀이 아니라, 오케스트레이션(Orchestration)을 다른 모든 분산 시스템과 마찬가지로 진지하게 다루는 팀입니다.

여러분의 오케스트레이션 레이어는 어떤 모습인가요? 다른 분들은 멀티 에이전트 워크플로우의 의존성 관리와 롤백(Rollback)을 어떻게 처리하고 있는지 궁금합니다. 여러분의 방식을 댓글로 남겨주세요.