서론

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

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

전체 아키텍처

에이전트 목록

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)

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

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

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

이 아키텍처의 한계

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

마치며

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

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

관련 기사

Discussion