[주제-1] 멀티 에이전트 입문 — news_editor, wordpress, coding의 역할과 책임

멀티 에이전트 시스템은 각 구성요소가 전문화되어 협업할 때 큰 효과를 냅니다. 다만 역할과 메시지 계약이 불분명하면 중복·누락·장애 대응이 지연될 수 있습니다. 이 글은 중앙 오케스트레이터의 핵심 책임과 실무적 권장 사항을 정리합니다.

문제 요약

  • 에이전트 간 메시지 포맷 불일치로 처리 실패가 발생합니다.
  • 재시도·중복 방지 정책 부재로 작업이 중복되거나 누락됩니다.
  • 장애 발생 시 책임 경계가 불분명해 복구가 지연됩니다.
  • 로그와 추적 정보가 흩어져 원인 분석이 어렵습니다.

핵심 권장 구성

중앙 오케스트레이터(Orchestrator)

워크플로우 조정, run_id/trace 전파, 재시도 규칙 적용, 관찰성 집계 등을 담당합니다. 실패를 감지하면 자동 재시도 또는 수동 개입 등 복구 시나리오를 실행합니다.

news_editor

소스 수집 → 요약 → 초안 생성(톤·페르소나 적용)을 담당합니다. 입력/출력 계약을 엄격히 하여 다운스트림 처리가 예측 가능하도록 보장합니다.

wordpress

포맷 변환·메타(SEO) 적용·게시를 담당합니다. 발행은 idempotent하게 설계하여 게시 상태를 명확히 보고합니다.

coding

자동화 스크립트·테스트·장애복구 루틴을 관리합니다. 에러 핸들러와 롤백 전략을 마련합니다.

실무 작업(바로 할 수 있는 4단계)

  1. 역할·책임 표 작성: 트리거, 입력, 출력, 에러 핸들러, 소유자를 명시합니다.
  2. 메시지 envelope 정의: run_id, trace_id, version, timestamp, payload를 표준화합니다.
  3. Idempotency 키를 도입하고 재시도 정책(횟수·백오프·타임아웃)을 문서화하여 적용합니다.
  4. 구조화 로그(JSON), 분산 트레이스(trace_id), run marker를 도입하여 중앙 대시보드에서 상태를 관찰합니다.
중앙 오케스트레이터 다이어그램
그림: 중앙 오케스트레이터와 주요 에이전트 관계도

기술 부록 (필요 시 펼쳐보기)

메시지 envelope 예시 (펼치기)

run_id: "run-20260412-0001"
trace_id: "4bf92f3577b34da6a3ce929d0e0e4736"
version: "v1"
timestamp: "2026-04-12T06:00:00Z"
payload:
  type: "article_draft"
  source: "news_editor"
  body_ref: "s3://internal/drafts/12345.json"
metadata:
  attempts: 0
  idempotency_key: "draft-12345-clientA"