오픈 소스 멀티 에이전트 오케스트레이션 (Multi-Agent Orchestration): AgentForge를 통해 배운 교훈

우리는 우리 자신의 문제를 해결하기 위해 AgentForge를 구축했습니다. 6개월간의 프로덕션 멀티 에이전트 배포를 통해 배운 점은 다음과 같습니다.

교훈 1: 성공 사례가 아닌 실패 모드 (Failure Modes)부터 시작하라

모두가 해피 패스 (Happy Path)를 위해 설계합니다. 하지만 멀티 에이전트 시스템에서는 실패 모드가 기하급수적으로 늘어납니다:

• 에이전트 A는 성공했지만 30초가 걸림 → 에이전트 B가 기다리다 타임아웃 (Timeout) 발생
• 에이전트 A가 잘못된 형식의 JSON을 반환 → 에이전트 B가 파싱 (Parsing) 중 충돌
• 두 에이전트가 동일한 파일에 쓰기를 시도 → 레이스 컨디션 (Race condition)

"무엇이 망가지는가"를 중심으로 오케스트레이션 (Orchestration)을 설계하십시오.

교훈 2: 관찰 가능성 (Observability)은 선택이 아닌 필수다

에이전트별 실행 트레이스 (Execution Traces)가 필요합니다. 단순한 로그가 아니라 다음과 같은 내용을 보여주는 구조화된 트레이스가 필요합니다:

• 입력 파라미터 (요약이 아닌 정확한 값)
• 후처리 (Post-processing) 전의 출력값
• 백오프 (Backoffs)를 포함한 재시도 (Retry) 시도
• 서킷 브레이커 (Circuit breaker) 상태 전환

우리는 이를 AgentForge의 실행 엔진에 구축했습니다. 모든 실행은 디버깅을 위해 다시 재생 (Replay)할 수 있는 JSON 트레이스를 생성합니다.

교훈 3: 에이전트에게는 메모리 (Memory)가 필요하지만, 무한한 메모리는 아니다

제한 없는 대화 기록은 성능을 저하시킵니다. 우리는 슬라이딩 윈도우 (Sliding window) + 요약 전략을 사용합니다:

• 마지막 N개의 턴 (Turns)은 원문 그대로 유지
• 오래된 턴은 구조화된 컨텍스트 (Context)로 요약
• 메모리 스토어 (Memory store)를 통해 에이전트가 핵심 사실을 명시적으로 "기억"하도록 함

교훈 4: 비용 최적화는 아키텍처 (Architecture)다

5개의 에이전트 × 4K 토큰 × GPT-4를 실행하면 비용이 빠르게 상승합니다. 우리의 접근 방식은 다음과 같습니다:

• 라우터 (Router) 에이전트가 어떤 전문가 (Specialist)를 호출할지 결정 (더 저렴한 모델 사용)
• 전문가 에이전트는 필요할 때만 더 큰 모델을 사용
• 결정론적 (Deterministic) 쿼리에 대한 응답 캐싱 (Response caching)

결과: 단순 구현 대비 비용 60% 절감.

스택 (The Stack)

• Python 3.11+
• 스키마 검증 (Schema validation)을 위한 Pydantic
• 동시 에이전트 실행을 위한 AsyncIO
• 상태 지속성 (State persistence)을 위한 SQLite/Redis
• 실시간 모니터링 UI를 위한 WebSocket

오픈 소스. VC 피칭 없음. 그저 작동하는 코드뿐입니다.

https://github.com/agentforge-cyber/agentforge-mvp

함께하기: https://discord.gg/Qy6HKHsqP

2026-05-31에 AgentForge 팀이 게시함.