Track 3의 설명인 _"서로 다른 능력을 가진 여러 에이전트(Agents)가 작업 분할, 대화 및 협상을 통해 협업하는 멀티 에이전트 협업 시스템을 설계하십시오"_를 처음 읽었을 때, 저는 일반적인 "AI에게 질문하고 답변을 얻는" 패턴 이상의 무언가를 만들어야 한다는 것을 알았습니다.

만약 에이전트들이 서로 **토론(debate)**할 수 있다면 어떨까요? 만약 그들이 실제 전문가 팀처럼 의견을 달리하고, 협상하며, 합의(consensus)에 도달할 수 있다면 어떨까요?

그것이 바로 Qwen Council이 탄생하게 된 계기입니다.

문제점 (The Problem)

단일 에이전트(Single-agent) AI 코드 리뷰에는 근본적인 한계가 있습니다: 하나의 모델이 하나의 관점만을 가진다는 점입니다. SQL 인젝션은 잡아낼 수 있지만, 아키텍처 부채(architectural debt)는 놓칠 수 있습니다. 성능 문제는 지적할 수 있지만, 접근성(accessibility) 문제는 간과할 수 있습니다.

현실 세계에서 코드 리뷰는 보안 엔지니어, 아키텍트, QA 전문가와 같은 **팀(teams)**에 의해 수행됩니다. 각자는 서로 다른 관점을 제공합니다. AI라고 해서 다를 이유가 있을까요?

아키텍처 (The Architecture)

Qwen Council은 Alibaba Cloud ECS에 배포되어 Qwen Cloud에서 실행되는 **14개의 특화된 에이전트(specialised agents)**를 갖춘 멀티 에이전트 시스템입니다.

두 가지 모드

코드 리뷰 (Code Review) — 서로 다른 전문성을 가진 6개의 에이전트(Security, Architecture, Quality, Performance, UX, Vision)가 4단계의 구조화된 토론 라운드(개별 분석, 교차 토론, 개선, 협상)를 통해 코드를 리뷰합니다.

일반 채팅 (General Chat) — 8개의 성격 기반 에이전트(Feynman, Torvalds, Socrates, Harari, Miyazaki, Jung, Sun Tzu, Franklin에서 영감을 받음)가 어떤 질문에도 답변합니다. 각 에이전트는 엄격한 도메인 경계를 가지고 있으며, 범위를 벗어난 질문은 거절합니다. 라우터(router)가 질문을 분류하고 가장 관련성이 높은 1~3개의 에이전트만 활성화합니다.

통신 프로토콜 (The Communication Protocol)

핵심 혁신은 인지 언어학(cognitive linguistics)에 기반한 에이전트 간 프로토콜입니다:

• 역피라미드 (Inverted Pyramid): 각 발견 사항은 결론부터 시작합니다. 어떤 에이전트라도 1초 안에 파악할 수 있는 한 줄의 문장으로 시작합니다.
• 구정보-신정보 (Given-New): 토론 라운드에서 에이전트들은 새로운 증거를 추가하기 전에 서로의 발견 사항을 명시적으로 참조합니다.

3단계 메모리 (3-Level Memory)

작업 메모리 (Working memory, 휘발성)는 현재 세션을 유지합니다. 에피소드 메모리 (Episodic memory, PostgreSQL)는 사용되지 않는 데이터가 감쇠하는 망각 곡선 (forgetting curve)을 적용하여 과거 세션을 저장합니다. 시맨틱 메모리 (Semantic memory, PostgreSQL + pgvector)는 반복되는 패턴을 벡터 임베딩 (vector embeddings)으로 통합합니다.

결과 (The Results)

동일한 코드에 대해 단일 범용 에이전트 (single generalist agent)와 전체 의회 (full council)를 비교하는 벤치마크를 실행했습니다:

지표 (Metric)	단일 에이전트 (Single-Agent)	멀티 에이전트 (Multi-Agent)	변화량 (Change)
총 발견 사항 (Total findings)	12	127	+958%
...

멀티 에이전트 시스템은 단일 에이전트가 포착한 모든 것을 유지하면서도 10.6배 더 많은 이슈를 찾아냈습니다.

Alibaba Cloud에 배포하기

전체 스택은 싱가포르 리전의 단일 Alibaba Cloud ECS 인스턴스 (2 vCPU, 4 GB RAM)에서 실행됩니다. 세 개의 Docker 컨테이너가 모든 것을 처리합니다:

• Nginx는 React 프론트엔드를 서빙하고 API 호출을 백엔드로 라우팅합니다.
• FastAPI는 에이전트들을 오케스트레이션 (orchestrate)하고 메모리 시스템을 관리합니다.
• pgvector를 사용하는 PostgreSQL은 세션 데이터와 시맨틱 임베딩 (semantic embeddings)을 모두 저장합니다.

백엔드는 OpenAI 호환 API를 통해 Qwen Cloud에 연결되며, 세 가지 모델을 사용합니다: 코드 분석을 위한 qwen3-coder-plus, 시각적 검사를 위한 qwen-vl-plus, 그리고 시맨틱 메모리 임베딩을 위한 text-embedding-v3입니다.

왜 Alibaba Cloud인가요? ECS + Docker Compose 설정은 오케스트레이션 오버헤드 없이 간단하고 프로덕션 준비가 된 (production-ready) 배포 환경을 제공했습니다. Qwen Cloud의 네이티브 통합 덕분에 ECS 인스턴스에서 낮은 지연 시간 (low-latency)의 API 호출이 가능했습니다. 또한 pgvector를 통해 별도의 벡터 DB 없이도 단일 데이터베이스에서 하이브리드 관계형 + 벡터 검색을 실행할 수 있었습니다.

내가 배운 점 (What I Learned)

1. 에이전트에게는 경계가 필요합니다 (Agents need boundaries). 초기에는 모든 에이전트가 모든 질문에 동일한 역량으로 답변했습니다. 명시적인 도메인 제한 (domain restrictions)을 추가함으로써 시스템을 훨씬 더 현실적으로 만들 수 있었습니다.

2. 라우팅 (Routing)이 중요합니다. 키워드 기반 분류기 (keyword-based classifier)가 질문을 1~3개의 관련 에이전트에게 전달합니다. 이를 정확하게 수행하는 것이 매우 중요합니다. 잘못된 라우팅은 토큰을 낭비하고 품질을 저하시킵니다.

3. 메모리 (Memory)는 어렵습니다. 망각 곡선 (forgetting curve)을 위해서는 세심한 튜닝이 필요했습니다. 너무 공격적이면 세션이 사라지고, 너무 관대하면 데이터베이스가 가득 차게 됩니다.

4. SSE 스트리밍 (SSE streaming)은 UX를 변화시킵니다. 에이전트가 실시간으로 응답하는 것을 지켜보는 것은 단일 응답을 기다리는 것보다 훨씬 더 몰입감이 높습니다.

Repository

전체 소스 코드는 MIT 라이선스 하에 오픈 소스로 공개되어 있습니다:

github.com/02NIN20/qwen-council

_ Global AI Hackathon Series with Qwen Cloud — Track 3: Agent Society를 위해 제작되었습니다._