14개의 AI 에이전트를 협업시키는 멀티 에이전트 아키텍처 설계

AI 에이전트 하나를 만드는 것은 이제 흔한 일이 아닙니다. 하지만 여러 에이전트를 협업시키고 하나의 개발 파이프라인으로 구동하려면 어떤 설계가 필요할까요?

본 기사에서는 14개의 전문 AI 에이전트가 6단계의 개발 파이프라인을 자율적으로 실행하는 멀티 에이전트 프레임워크(NexusCore)의 설계를 소개합니다.

에이전트	역할	담당 단계
Orchestrator	전체 제어 및 파이프라인 관리	모든 단계
...
각 단계는 독립적인 에이전트가 담당하고, Orchestrator가 전체 진행을 관리합니다.

Orchestrator는 각 에이전트를 직접 호출하는 중앙 제어 구성입니다. 이벤트 기반(Event-driven) 방식이나 블랙보드(Blackboard) 방식을 채택하지 않고, 명시적인 파이프라인 제어를 채택했습니다.

선택 이유:

모든 에이전트는 BaseAgent를 상속받아 LLM 호출, 재시도(Retry), 오류 처리 등의 공통 로직을 공유합니다.

class BaseAgent:
def execute_llm_task(self, prompt, system_prompt=None, as_json=False, temperature=0.2):
...

각 에이전트는 execute_llm_task를 호출하는 것만으로 LLM과 통신할 수 있으며, 프로바이더의 차이를 의식하지 않습니다.

단계 간 데이터는 파일 시스템과 데이터베이스를 통해 주고받습니다.

파일과 데이터베이스의 2계층으로 나눈 이유:

실제 6단계 실행에 더하여, 구현 → 테스트 → 수정 사이클만을 빠르게 돌리는 FastLane 모드를 구현했습니다.

요구사항이나 설계가 확정된 경우, 구현과 테스트만 반복하는 것이 더 효율적입니다.

CoderAgent는 LLM이 생성한 코드를 AST(추상 구문 트리, Abstract Syntax Tree)로 검증한 후에 출력합니다. 이를 통해 문법 오류의 코드가 후속 단계에 전달되는 것을 방지합니다.

GuardianAgent의 리뷰 결과는 3가지 상태를 가집니다:

PostmortemAgent는 오류 발생 시 3가지 출력을 생성합니다:

생성된 지식은 JSON 형식으로 저장되어, 다음 DebuggerAgent가 참조합니다.

항목	Orchestrator 방식 (채택)	이벤트 기반 방식
제어의 명확성	높음 (코드로 추적 가능)	낮음 (이벤트 흐름을 추적해야 함)
...
개발 파이프라인이라는 특성상, 실행 순서 보장과 디버깅성을 우선했습니다.

항목	파일 방식 (채택)	메시지 큐
구현의 단순성	높음	중간 (인프라 필요)
...
개인 개발 규모에서는, 파일 방식이 가장 간단하고 실용적입니다.

Orchestrator가 단일 장애점(Single Point of Failure): 중앙 제어이므로 Orchestrator의 버그는 전체에 영향을 줍니다.
순차 실행의 오버헤드: 병렬 가능한 처리도 순차적으로 실행됩니다.
에이전트 간의 강한 결합 (Tight Coupling): 각 에이전트가 전제하는 데이터 형식에 의존합니다.

멀티 에이전트 시스템 설계에서 가장 중요한 것은, '각 에이전트의 책무를 명확히 하는 것'과 '에이전트 간 인터페이스를 고정하는 것'이었습니다.

14개의 에이전트가 협력하여 작동하는 시스템을 설계할 때, 처음부터 모든 것을 가정하기보다는 Orchestrator → 개별 에이전트 → 에이전트 간 연계 → 품질 관리 순서로 단계적으로 구축하는 것이 실제로 작동하는 시스템을 만드는 요령입니다.

본 기사는 개인 Zenn에서도 공개되었습니다.

요약