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

서론

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

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

전체 아키텍처

에이전트 목록

에이전트	역할	담당 페이즈
Orchestrator	전체 제어·파이프라인 관리	모든 페이즈
...

6단계 파이프라인

Phase 1: REQUIREMENTS
↓
Phase 2: PLAN
...

각 페이즈는 독립된 에이전트가 담당하며, Orchestrator가 전체 진행을 관리합니다.

설계상의 포인트

1. Orchestrator 패턴

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

이유:

실행 순서 보장: 개발 파이프라인은 순서가 중요함 (테스트 전에 구현이 필요함 등)
에러 전파의 명확화: 어느 페이즈에서 실패했는지 즉시 특정 가능
디버깅의 용이성: 파이프라인의 흐름을 코드상에서 추적 가능

2. BaseAgent를 통한 공통 인터페이스

모든 에이전트는 BaseAgent를 상속받아, LLM 호출·재시도(Retry)·에러 핸들링(Error handling)의 공통 로직을 공유합니다.

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

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

3. 에이전트 간의 데이터 전달

페이즈 간의 데이터는 파일 시스템과 데이터베이스를 통해 전달합니다.

요구사항 정의서: 파일로 저장 → ArchitectAgent가 읽음
아키텍처 설계서: 파일로 저장 → CoderAgent가 읽음
테스트 결과: 데이터베이스에 기록 → DebuggerAgent가 참조
리뷰 결과: 데이터베이스에 기록 → Orchestrator가 판단

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

문서류는 사람이 확인하기 때문에 파일 형식이 적합함
실행 결과는 검색·집계하기 때문에 데이터베이스가 적합함

4. FastLane: 고속 반복 모드

본래의 6단계 실행에 더해, 구현→테스트→수정 사이클만을 고속으로 돌리는 FastLane 모드를 구현했습니다.

통상 모드: REQUIREMENTS → PLAN → ARCHITECTURE → IMPLEMENTATION → TESTING → REVIEW
FastLane: IMPLEMENTATION → TESTING → (에러 발생 시: DEBUG → IMPLEMENTATION) → REVIEW

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

에이전트 설계의 구체적인 예시

CoderAgent: AST 검증을 포함한 코드 생성

CoderAgent는 LLM이 생성한 코드를 AST(추상 구문 트리, Abstract Syntax Tree)로 검증한 후 출력합니다. 이를 통해 구문 에러가 있는 코드가 후속 페이즈로 넘어가는 것을 방지합니다.

GuardianAgent: 3상태 리뷰

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

APPROVE: 품질 게이트 통과, 커밋 가능
REJECT: 수정 필요, 이전 페이즈로 되돌림
MANUAL_REVIEW: 사람의 판단 필요

PostmortemAgent: 실패로부터의 학습

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

에러 시그니처 (Error Signature): 동일 유형 에러의 패턴 매칭용
근본 원인 분석 (Root Cause Analysis): 왜 에러가 발생했는가
해결 패턴 (Resolution Pattern): 차후의 해결책

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

설계 판단과 트레이드오프 (Trade-off)

Orchestrator 방식 vs 이벤트 주도 방식 (Event-driven)

항목	Orchestrator 방식 (채택)	이벤트 주도 방식
제어의 명확성	높음 (코드로 추적 가능)	낮음 (이벤트의 흐름을 추적해야 함)
...	...

개발 파이프라인이라는 특성상, 실행 순서의 보장과 디버깅성 (Debuggability)을 우선시했습니다.

파일에 의한 전달 vs 메시지 큐 (Message Queue)

항목	파일 방식 (채택)	메시지 큐
구현의 단순함	높음	중간 (인프라가 필요함)
...	...

개인 개발 규모에서는 파일 방식이 가장 단순하고 실용적입니다.

이 아키텍처의 한계

Orchestrator가 단일 장애점 (Single Point of Failure): 중앙 제어 방식이므로, Orchestrator의 버그는 전체에 영향을 미침
순차 실행의 오버헤드 (Overhead): 병렬 처리가 가능한 프로세스도 순차적으로 실행됨
에이전트 간의 밀결합 (Tight Coupling): 각 에이전트가 전제로 하는 데이터 형식에 의존

마치며

멀티 에이전트 시스템 (Multi-agent System) 설계에서 가장 중요한 것은 "각 에이전트의 책임을 명확히 하는 것"과 "에이전트 간의 인터페이스 (Interface)를 고정하는 것"이었습니다.

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

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

요약

핵심 포인트

서론

전체 아키텍처

에이전트 목록

6단계 파이프라인

설계상의 포인트

1. Orchestrator 패턴

2. BaseAgent를 통한 공통 인터페이스

3. 에이전트 간의 데이터 전달

4. FastLane: 고속 반복 모드

에이전트 설계의 구체적인 예시

CoderAgent: AST 검증을 포함한 코드 생성

GuardianAgent: 3상태 리뷰

PostmortemAgent: 실패로부터의 학습

설계 판단과 트레이드오프 (Trade-off)

Orchestrator 방식 vs 이벤트 주도 방식 (Event-driven)

파일에 의한 전달 vs 메시지 큐 (Message Queue)

이 아키텍처의 한계

마치며

관련 기사

Discussion

댓글

서론

전체 아키텍처

에이전트 목록

6단계 파이프라인

설계상의 포인트

1. Orchestrator 패턴

2. BaseAgent를 통한 공통 인터페이스

3. 에이전트 간의 데이터 전달

4. FastLane: 고속 반복 모드

에이전트 설계의 구체적인 예시

CoderAgent: AST 검증을 포함한 코드 생성

GuardianAgent: 3상태 리뷰

PostmortemAgent: 실패로부터의 학습

설계 판단과 트레이드오프 (Trade-off)

Orchestrator 방식 vs 이벤트 주도 방식 (Event-driven)

파일에 의한 전달 vs 메시지 큐 (Message Queue)

이 아키텍처의 한계

마치며

관련 기사

Discussion