개요

블로그 시스템 구축을 위해 14명의 AI 전문가, 5개 팀, 4개 LLM 모델로 구성된 멀티모델 에이전트 팀을 설계했습니다. 핵심은 두 가지입니다.

1. 조합형 에이전트(Composed Agent): 역할 정의와 실행 프로필을 분리해 재사용성 극대화
2. 계층형 브릿지 리더십: 상위팀-하위팀 간 기술 리드의 이중 소속으로 소통 병목 해결

이 글에서는 최종 구조, 모델 배분 전략, 조합형 아키텍처 설계 과정을 공유합니다.

배경: 왜 멀티모델인가

하나의 LLM으로 모든 작업을 처리하면 두 가지 문제가 발생합니다.

• 비용: Claude Opus 수준의 모델로 14명 전문가를 실행하면 비용이 통제 불가능
• 적합성: 설계에는 빠른 추론이, 보안 분석에는 깊은 논리가, 구현에는 안정적인 코딩이 필요

그래서 작업 성격에 맞춰 모델을 분배했습니다.

최종 팀 구조

5개 팀, 14명 전문가, 4개 모델로 구성됩니다.

graph TD
    subgraph UPPER["상위팀 — 조정 팀 (steering-team) · consensus"]
        ORC["오케스트레이터
relay:steering-orchestrator"]
        DES["설계자
gemini:gemini-2.5-flash"]
        SEC["보안 검토자
codex:gpt-4o"]
        STL["백엔드 기술 리드
relay:developer-zai"]
        FTL["프론트엔드 기술 리드
relay:developer-zai"]
        DTL["데스크탑 기술 리드
relay:developer-zai"]
        INF["인프라 네트워크
gemini:gemini-2.5-flash"]
        SAD["서버 관리자
relay:developer-zai"]
    end

    subgraph LOWER_BE["백엔드 팀 · leader_decides"]
        BTL["백엔드 기술 리드"]
        BDEV["백엔드 개발자"]
    end

    subgraph LOWER_FE["프론트엔드 팀 · leader_decides"]
        FTL2["프론트엔드 기술 리드"]
        FDEV["프론트엔드 개발자"]
        FUX["UX 디자이너"]
    end

    subgraph LOWER_DT["데스크탑 팀 · leader_decides"]
        DTL2["데스크탑 기술 리드"]
        DDEV["데스크탑 개발자"]
        DUX["UX 디자이너"]
    end

    subgraph LOWER_INFRA["인프라 팀 · leader_decides"]
        SAD2["서버 관리자 (리더)"]
        INET["클라우드 네트워크"]
        DBA["DB 아키텍트"]
    end

    UPPER -.->|bridge| LOWER_BE
    UPPER -.->|bridge| LOWER_FE
    UPPER -.->|bridge| LOWER_DT
    UPPER -.->|bridge| LOWER_INFRA

    BTL --> BDEV
    FTL2 --> FDEV
    FTL2 --> FUX
    DTL2 --> DDEV
    DTL2 --> DUX
    SAD2 --> INET
    SAD2 --> DBA

팀별 상세

인프라 팀 분리 결정

초기 설계에서는 DB 아키텍트와 서버 관리자가 백엔드 팀에 포함되어 있었습니다. 하지만 작업 공간(Workspace) 기준으로 분리했습니다.

graph LR
    subgraph 백엔드팀
        B["API 코드 작성
FastAPI, Python
workspace: VS Code / SSH"]
    end

    subgraph 인프라팀
        S["서버 관리
Docker, Ubuntu, Nginx
workspace: SSH 터미널"]
        N["클라우드 네트워크
Cloudflare Dashboard
workspace: 웹 콘솔"]
        D["DB 관리
PostgreSQL, 마이그레이션
workspace: psql / SSH"]
    end

    B -.->|API 배포| S
    B -.->|쿼리 최적화| D

분리 이유: 작업 공간이 다르면 같은 팀에 두는 것보다 분리하는 것이 자연스럽습니다.

모델 배분 전략

pie title 모델별 전문가 수
    "relay:developer-zai (GLM)" : 10
    "gemini:gemini-2.5-flash" : 2
    "codex:gpt-4o" : 1
    "zai:glm-4" : 1

10명의 구현 전문가를 GLM(저비용 모델)에 배정하여 전체 비용의 60-70%를 절감했습니다.

조합형 에이전트 아키텍처 (Composed Agent Pattern)

이번 설계의 핵심 혁신은 역할 정의(Expert)와 실행 프로필(Definition)의 분리입니다.

기존 방식의 문제

기존에는 역할과 실행 로직이 결합되어 변경 시 전체 재작성이 필요하고 재사용이 불가능했습니다.

조합형 방식

graph TD
    DEF["Definition
백엔드 개발자"]
    DEF --> BASE["Base: backend-core"]
    DEF --> CAP["Capabilities:
rest-api, crud, auth-jwt"]
    DEF --> PLAT["Platform: fastapi"]
    DEF --> POL["Policy: blog-default"]

    BASE --> |"조합"| RUN["런타임 에이전트"]
    CAP --> |"조합"| RUN
    PLAT --> |"조합"| RUN
    POL --> |"조합"| RUN

모듈 구조

agent-library/
├── definitions/        ← 14개 에이전트 정의
├── modules/
│   ├── base/           ← 6개 기본 모듈
│   ├── capabilities/   ← 15개 역량 모듈
│   ├── platforms/      ← 5개 플랫폼 모듈
│   └── policies/       ← 1개 정책
└── runs/               ← 실행 이력

장점

1. 재사용성: rest-api 역량 모듈은 백엔드 개발자와 기술 리드가 공유
2. 플랫폼 교체: platform: fastapi를 platform: django로 변경하면 즉시 전환
3. 역량 확장: 새 역량 모듈을 추가하고 Definition에 연결만 하면 됨
4. 정책 통일: 모든 에이전트가 동일한 blog-default 정책을 따름

전문가-Definition 매핑

TLS 인증서 전략: Cloudflare Origin CA

프로덕션 환경의 TLS 인증서로 Let’s Encrypt 대신 Cloudflare Origin CA를 선택했습니다.

sequenceDiagram
    participant Client as 방문자
    participant CF as Cloudflare (Proxy)
    participant Nginx as Nginx (Origin)
    participant API as FastAPI

    Client->>CF: HTTPS 요청
    CF->>CF: Cloudflare 관리 인증서로 종료
    CF->>Nginx: Origin CA 인증서로 암호화
    Nginx->>API: HTTP (로컬)
    API-->>Nginx: 응답
    Nginx-->>CF: Origin CA로 암호화
    CF-->>Client: 응답

프로덕션 아키텍처:

Oracle Cloud ARM (4 OCPU, 24GB)
├── PostgreSQL (호스트 직접 설치)
├── Docker Compose
│   ├── blog-api (FastAPI)
│   ├── blog-frontend (Next.js standalone)
│   ├── MinIO (S3 호환 스토리지)
│   └── Nginx (Cloudflare Origin CA)
└── Cloudflare Proxy (Full Strict SSL)

Relay 플러그인: 에이전트 호출 메커니즘

팀 구조는 Relay 플러그인을 통해 Claude Code에서 실행됩니다.

sequenceDiagram
    participant User as 사용자
    participant Claude as Claude Code
    participant Plugin as Relay Plugin
    participant MCP as MCP 서버
    participant LLM as 외부 LLM

    User->>Claude: /relay:invoke-agent
    Claude->>Plugin: 전문가 slug로 정의 로드
    Plugin->>Plugin: Definition 조합 (base + capabilities + platform + policy)
    Plugin->>Plugin: backed_by 확인

    alt relay:developer-zai
        Plugin->>Claude: 내부 에이전트 실행
    else gemini:*
        Plugin->>MCP: gemini_mcp 서버 호출
        MCP->>LLM: Gemini API
        LLM-->>MCP: 응답
        MCP-->>Plugin: 결과
    else codex:*
        Plugin->>MCP: codex_mcp 서버 호출
        MCP->>LLM: OpenAI API
        LLM-->>MCP: 응답
        MCP-->>Plugin: 결과
    end

    Plugin-->>Claude: 최종 결과
    Claude-->>User: 응답

backed_by 네임스페이스

설계 결정 이력

회고: 설계하며 배운 것

1. “완벽한 구조"보다 “실행 가능한 구조”

팀 구조, 모델 배정, 인프라 설정을 완벽하게 설계하려다 보면 시작조차 못 합니다.

2. 작업 공간이 곧 팀 경계

코드를 작성하는 사람과 서버를 관리하는 사람은 물리적 작업 환경이 다르고, 그것이 자연스러운 팀 경계가 됩니다.

3. 조합형 아키텍처의 가치

14명의 전문가, 5개 팀, 4개 모델이 얽히는 환경에서는 모듈 분리가 필수적입니다.

4. 비용은 설계 단계에서 결정된다

“이 작업에 꼭 고비용 모델이 필요한가?“를 매번 물어보면 자연스럽게 비용이 최적화됩니다.

다음 단계

• Phase 1 구현 착수: DB, Auth, Post/Category CRUD, Docker
• 팀 운영 경험 공유: 실제 실행 중 겪은 문제와 해결 과정
• 성능 모니터링: 모델별 응답 시간, 비용 대비 품질 분석

이 글은 Claude Code + Relay 플러그인을 활용한 AI 에이전트 팀 구성 경험을 정리한 것입니다.