업무 자동화 시스템을 만들 때 가장 먼저 드는 질문이 있다. "에이전트 하나면 안 되나?" 단일 에이전트로 시작하면 구조가 단순하고 디버깅도 쉽다. 그런데 실제 업무 맥락에서는 단일 에이전트가 빠르게 벽에 부딪힌다. 이 글은 왜 여러 에이전트가 협업하는 구조가 필요한지, 그리고 그 구조를 실제로 어떻게 설계하는지를 기술적으로 짚는다.
단일 에이전트로 충분하지 않은 이유
단일 에이전트가 실패하는 지점은 복잡한 기능 탓이 아니라 컨텍스트 길이와 직렬 실행의 구조적 한계 때문이다.
LLM 기반 에이전트에 하나의 긴 작업을 맡기면 세 가지 문제가 동시에 발생한다. 첫째, 컨텍스트 창이 소진된다. 데이터 수집, 변환, 검증, 발행을 하나의 루프에서 처리하면 중간 상태가 프롬프트에 누적되고, 모델은 앞부분 지시를 잊는다. 둘째, 직렬 실행은 병목을 만든다. API 호출이 5개 있고 각각 2초라면, 단일 에이전트는 10초를 기다린다. 셋째, 에러 격리가 불가능하다. 한 단계가 실패하면 전체 루프를 재시작해야 한다.
반면 여러 에이전트가 협업하는 구조에서는 각 에이전트가 명확한 책임 경계를 갖는다. 한 에이전트가 데이터를 수집하고, 다른 에이전트가 변환하고, 또 다른 에이전트가 검증한다. 에러는 해당 에이전트 범위 안에서 처리되고, 독립된 작업은 병렬로 돌린다.
에이전트 협업 구조를 어떻게 설계할까?
나무숲이 실제 자동화 프로젝트에서 가져가는 구조는 오케스트레이터-워커(Orchestrator-Worker) 패턴이다. 이 패턴은 Anthropic이 공개한 에이전트 설계 가이드라인에서도 다루는 구조로, 책임 분리가 명확하다는 점이 핵심이다.
| 역할 | 책임 범위 | 주요 판단 |
|---|---|---|
| 오케스트레이터 | 전체 작업 계획, 워커 배정 | 어떤 워커를 호출할지, 순서와 병렬 여부 |
| 워커 에이전트 | 단일 도메인 작업 실행 | 도구 호출, 결과 반환 |
| 검증 에이전트 | 출력 품질 검사 | 재시도 요청 또는 다음 단계 진행 |
| 상태 관리 | 에이전트 간 공유 컨텍스트 보존 | 어떤 정보가 다음 에이전트에 전달되는지 |
예를 들어 콘텐츠 자동 발행 파이프라인이라면, 오케스트레이터가 "오늘 발행할 항목 목록"을 받아 수집 워커, 요약 워커, 포맷 워커를 순서대로 호출한다. 검증 에이전트는 포맷 워커 출력을 보고 발행 가능 여부를 판단한다.
에이전트 간 데이터 흐름과 오케스트레이션 설계
오케스트레이터는 각 워커를 직접 호출하고, 그 결과를 다음 워커의 입력으로 넘긴다. 이때 중요한 설계 결정이 두 가지다.
메시지 구조를 명시적으로 정의한다. 에이전트 간 데이터는 자유형 텍스트가 아니라 스키마가 있는 구조로 전달해야 한다. JSON 스키마나 Pydantic 모델을 쓰면 에이전트 출력이 다음 에이전트의 입력 형식을 충족하는지 런타임 전에 검사할 수 있다.
오케스트레이터는 작업의 의미를 이해하지 않는다. 좋은 오케스트레이터는 라우터에 가깝다. "이 입력은 A 워커에게, 그 결과는 B 워커에게"를 결정할 뿐, 각 작업의 도메인 로직에 관여하지 않는다. 이 원칙을 지키면 워커를 교체하거나 추가할 때 오케스트레이터 코드를 손댈 필요가 없다.
간단한 파이썬 예시로 구조를 보면 이렇다:
from anthropic import Anthropic
from pydantic import BaseModel
client = Anthropic()
class WorkerOutput(BaseModel):
status: str # "success" | "retry" | "failed"
payload: dict
error_message: str | None = None
def call_worker(system_prompt: str, user_input: str) -> WorkerOutput:
response = client.messages.create(
model="claude-opus-4-5",
max_tokens=1024,
system=system_prompt,
messages=[{"role": "user", "content": user_input}],
)
# 실제 구현에서는 tool_use 결과를 파싱
raw = response.content[0].text
return WorkerOutput(status="success", payload={"result": raw})
def orchestrate(task: dict) -> dict:
# 1단계: 수집 워커
collected = call_worker(COLLECTOR_SYSTEM, str(task))
if collected.status != "success":
return {"error": collected.error_message}
# 2단계: 변환 워커 (수집 결과를 입력으로)
transformed = call_worker(TRANSFORMER_SYSTEM, str(collected.payload))
if transformed.status != "success":
return {"error": transformed.error_message}
# 3단계: 검증 에이전트
validated = call_worker(VALIDATOR_SYSTEM, str(transformed.payload))
return validated.payload
이 구조에서 각 call_worker 호출은 독립된 LLM 호출이다. 오케스트레이터는 반환값의 status 필드를 보고 다음 단계 진행 여부를 결정한다.
병렬 실행이 필요한 경우, 독립된 워커는 asyncio.gather로 묶는다:
import asyncio
async def orchestrate_parallel(items: list[dict]) -> list[dict]:
tasks = [call_worker_async(PROCESSOR_SYSTEM, str(item)) for item in items]
results = await asyncio.gather(*tasks, return_exceptions=True)
return [r.payload if isinstance(r, WorkerOutput) else {"error": str(r)} for r in results]
기술적 난제: 상태 공유, 충돌 해결, 에러 복구
이 세 가지는 다중 에이전트 시스템에서 실제로 가장 많이 틀리는 지점이다.
상태 공유를 어떻게 다룰까?
에이전트 간 상태를 LLM 컨텍스트 안에서만 유지하면 컨텍스트가 늘어날수록 비용이 증가하고 정보가 유실된다. 실용적인 방법은 외부 상태 저장소를 두는 것이다. Redis나 간단한 PostgreSQL 테이블로 작업 상태를 기록하고, 각 에이전트는 시작 시 상태를 읽고 종료 시 갱신한다.
# 상태를 외부 저장소에서 읽고 쓰는 패턴
def get_task_state(task_id: str) -> dict:
return redis_client.hgetall(f"task:{task_id}")
def update_task_state(task_id: str, updates: dict) -> None:
redis_client.hset(f"task:{task_id}", mapping=updates)
redis_client.expire(f"task:{task_id}", 86400) # 24시간 TTL
충돌 해결
여러 워커가 동일한 리소스를 동시에 수정할 가능성이 있으면, 낙관적 잠금(optimistic locking)이나 단순한 큐 기반 직렬화로 처리한다. 에이전트가 AI 모델이라는 사실이 이 문제를 특별하게 만들지 않는다. 동시성 제어는 일반 분산 시스템과 같은 방식으로 접근한다.
에러 복구 전략
에러 복구는 재시도 정책을 명시적으로 설계해야 한다. 세 가지 수준으로 나눠 생각한다:
- 즉시 재시도: 일시적 네트워크 오류. 지수 백오프(exponential backoff)로 최대 3회.
- 대체 경로: 워커 출력이 스키마를 충족하지 못하면 검증 에이전트가 재생성을 요청.
- 인간 개입: 특정 횟수 이상 실패하거나 불확실성이 높은 판단이 필요한 경우, 슬랙 알림 등으로 사람에게 넘긴다.
마지막 지점이 중요하다. 완전 자동화를 목표로 하되, 시스템이 스스로 모른다고 판단하는 상황에서 자동으로 사람을 개입시키는 경로를 설계해두지 않으면 조용히 틀린 결과가 발행된다.
CTO가 납득할 수 있는 성능 지표와 안정성 검증
"AI가 잘 한다"는 말은 CTO에게 아무 정보도 주지 않는다. 측정 가능한 지표로 시스템을 평가해야 한다.
다중 에이전트 시스템에서 의미 있는 지표는 다음과 같다:
| 지표 | 측정 방법 | 판단 기준 |
|---|---|---|
| 태스크 완료율 | 성공 상태로 종료된 작업 / 전체 작업 | 팀이 수용 가능한 임계값을 사전 정의 |
| 워커별 실패율 | 워커 단위로 오류 로그 집계 | 특정 워커 집중 실패 시 프롬프트 또는 도구 점검 |
| 평균 작업 시간 | 오케스트레이터 시작~종료 타임스탬프 | SLA 요구사항에 맞게 조정 |
| 재시도 비율 | 1회 이상 재시도한 작업 / 전체 작업 | 높으면 워커 출력 스키마 또는 프롬프트 불안정 신호 |
| 비용 per task | LLM API 호출 토큰 합산 | 규모 확장 시 비용 예측 가능성 확보 |
안정성 검증에서 빠져서는 안 되는 것이 하나 있다. 골든 셋 테스트다. 실제 운영 전 입력값과 기대 출력값의 쌍을 수십 건 만들어두고, 프롬프트나 모델 버전이 바뀔 때마다 이 셋에 대해 자동으로 회귀 테스트를 돌린다. LLM 출력은 비결정적이므로, 정확한 텍스트 매칭이 아니라 구조적 조건(필드 존재 여부, 값 범위, 포맷)으로 검증한다.
모니터링은 LangSmith, LangFuse 같은 LLM 옵저버빌리티 도구를 쓰거나, 자체 로깅 파이프라인을 OpenTelemetry 형식으로 구축하면 각 에이전트 호출의 입력, 출력, 토큰, 지연 시간을 추적할 수 있다.
자주 묻는 질문
에이전트 수가 많아질수록 비용이 선형으로 늘어나지 않나?
LLM 호출 비용은 토큰 기준이다. 단일 에이전트에 모든 맥락을 넣으면 프롬프트가 비대해지고 오히려 비용이 높아진다. 각 워커가 자신의 역할에 필요한 컨텍스트만 받으면 워커 수가 늘어도 전체 토큰 사용량은 단일 에이전트 대비 비슷하거나 낮아지는 경우가 많다.
프롬프트 엔지니어링만으로 단일 에이전트를 개선하면 안 되나?
단순한 작업에서는 그 편이 낫다. 다중 에이전트 구조가 필요한 기준은 명확하다. 작업 단계가 독립적으로 병렬 처리 가능하거나, 한 단계 실패가 전체 재시작을 유발하거나, 작업 유형마다 다른 도구 집합이 필요하면 구조를 나눠야 한다.
오케스트레이터 자체가 LLM이어야 하나?
반드시 그럴 필요는 없다. 작업 흐름이 사전에 결정 가능하면 오케스트레이터는 일반 파이썬 코드로 구현하는 편이 더 예측 가능하고 빠르다. LLM 오케스트레이터는 실행 중 상황을 보고 다음 워커를 동적으로 결정해야 할 때만 도입한다.
에이전트 간 통신 방식으로 어떤 걸 쓸까?
함수 호출(직접 호출), 메시지 큐(RabbitMQ, Kafka), REST/gRPC 세 가지 중 팀 규모와 에이전트 수에 맞게 고른다. 에이전트가 5개 이하이고 동일 프로세스에 있으면 함수 호출이 가장 단순하다. 에이전트가 별도 서비스로 분리되면 메시지 큐가 에러 격리와 재처리에 유리하다.
골든 셋 테스트의 적정 규모는?
도메인에 따라 다르지만 최소 30~50건이 실용적인 출발점이다. 엣지 케이스와 실패 케이스를 의도적으로 포함시켜야 한다. 100건을 넘기면 테스트 실행 비용이 높아지므로, 핵심 경로를 커버하는 케이스를 선별해 관리하는 것이 현실적이다.
에이전트 협업 시스템은 구조 설계 단계에서 방향이 거의 결정된다. 오케스트레이터와 워커의 책임 경계, 상태 관리 방식, 에러 복구 경로를 처음부터 명시적으로 설계하면 나중에 구조를 뜯어고치는 일을 피할 수 있다. 나무숲은 이 구조를 자체 자동화 파이프라인에 직접 적용해 운영하고 있다. 특정 구조나 코드 수준의 기술 검토가 필요하다면 포텐랩 기술 상담에서 구체적인 논의를 시작할 수 있다.
더 보기: treesoop.com