# Synode (Council of AI Agents) vs 아누 시스템 심층 비교분석

**작업 ID**: task-344.1 (원래 task-343.1 사양)
**작성일**: 2026-03-06
**작성자**: 아누 (Anu), 개발실장 — GLM-5 컨텍스트 초과로 직접 수행
**참조**: Superpowers 비교분석 (task-328.1, 오딘 작성)

---

## 0. Synode 프로젝트 개요

- **GitHub**: https://github.com/mahatab/synode-council-of-ai-agents
- **Stars**: 23 / **Forks**: 4 / **Commits**: 56 / **버전**: 0.1.5
- **라이선스**: MIT
- **핵심 컨셉**: 여러 AI 모델을 "의회(Council)"로 구성, 질문에 대해 토론 후 Master 모델이 종합 판결
- **기술스택**: React 19/TypeScript 5.9 (프론트) + Rust/Tauri v2 (백엔드)
- **플랫폼**: macOS/Windows 데스크톱 앱
- **지원 프로바이더**: 8개 (Anthropic, OpenAI, Google, xAI, DeepSeek, Mistral, Together AI, Cohere)
- **지원 모델**: 30+ 모델

---

## 1. 아키텍처 비교

### 1.1 Synode 아키텍처

- **구조**: 단일 데스크톱 앱. React WebView + Rust(Tauri) 백엔드
- **실행 환경**: 로컬 데스크톱 (macOS/Windows)
- **모델 연동**: 각 프로바이더 API를 Rust 백엔드에서 직접 호출 (reqwest + tokio-stream SSE)
- **상태 관리**: Zustand (프론트), Rust 세션 영속화 (백엔드)
- **보안**: API 키를 OS 키체인에 저장 (macOS Keychain / Windows Credential Manager)
- **핵심 패턴**: "Council" — 여러 모델이 동일 주제에 대해 의견을 내고, Master 모델이 종합

### 1.2 아누 시스템 아키텍처

- **구조**: 멀티봇(4개 독립 Telegram 봇) + 팀 내 서브에이전트(Task tool) 2-레이어
- **실행 환경**: Linux 서버 (cokacdir 프레임워크)
- **모델 연동**: Anthropic API (Opus/Sonnet/Haiku), Z.AI (GLM-5), Google (Gemini CLI)
- **상태 관리**: 파일 기반 (.done 프로토콜, task-timers.json, pipeline-status.json 등)
- **보안**: 환경변수 기반 API 키, 봇별 독립 세션 격리
- **핵심 패턴**: "매트릭스 조직" — 수직조직(개발팀) + 횡단조직(QC/DevOps/디자인) 교차

### 1.3 아키텍처 핵심 차이

**목적의 근본적 차이**:
- Synode = **의사결정 보조 도구**. "여러 AI에게 물어보고 종합 답변을 얻자"
- 아누 시스템 = **프로덕션 소프트웨어 개발 시스템**. "AI 조직으로 실제 코드를 만들자"

**운영 모드**:
- Synode: 사용자가 질문 → 모델들이 답변 → Master가 종합 → 끝. **1회성 Q&A 사이클**
- 아누: 지시 → 분석/미팅/설계 → 위임 → 코딩 → QC → 보고. **연속적 개발 파이프라인**

**실행 범위**:
- Synode: 텍스트 응답만 생성. 코드 실행, 파일 조작, 테스트 수행 없음
- 아누: 코드 생성 + 파일 조작 + 테스트 실행 + 배포까지. 전체 소프트웨어 개발 라이프사이클

**확장성**:
- Synode: 모델 추가 = API 키 입력 1개. 사용자 1명용 로컬 앱
- 아누: 팀원 추가 = organization-structure.json + team_prompts.py + dispatch.py 수정. 프로덕션 서버

---

## 2. 토론 방식 비교 (핵심)

### 2.1 Synode의 Council 토론

**Sequential 모드**:
- 각 모델이 이전 모델의 응답 전체를 보고 답변
- 후순위 모델이 앞선 의견을 참고하여 보완/반박
- **장점**: 논의가 점진적으로 깊어짐, 이전 의견의 약점을 보완
- **단점**: 앵커링 효과 — 첫 번째 모델의 답변에 후속 모델이 영향받아 동일 방향으로 수렴할 위험

**Independent 모드**:
- 각 모델이 원본 질문만 보고 독립 답변
- 그룹싱크(Groupthink) 방지가 핵심 목적
- **장점**: 다양한 관점 확보, 편향 최소화
- **단점**: 중복 답변 가능, 상호 보완 없음

**Master Verdict**:
- 지정된 모델이 모든 의견을 통합하여 최종 결론
- 1회성 종합 — 추가 반복 없음

**@Mention 후속 대화**:
- 판결 후 특정 모델에 추가 질문 가능
- 해당 모델은 전체 토론 히스토리를 컨텍스트로 수신

### 2.2 아누 시스템의 에이전트 미팅

**병렬 소집 (Independent에 대응)**:
- Task tool로 여러 페르소나를 병렬 소집
- 각 페르소나는 독립적으로 전문 의견 제시
- Synode의 Independent 모드와 동일한 그룹싱크 방지 효과

**보리스 워크플로우 (Annotation Cycle)**:
- 최대 6사이클 반복 (Synode는 1회 종합)
- 매 사이클: 아누 분석 → 페르소나 의견 → 통합 → 미해결 항목 재논의
- **핵심 차이: 반복적 심화**. Synode의 단발성 종합과 근본적으로 다름

**Devil's Advocate (Lv.3+ 필수)**:
- 매 사이클 1명을 반대 입장 지정
- 3대 질문: 실패 시나리오 / 후회 이유 / 더 단순한 대안
- 반박 없으면 합의 불성립
- **Synode에 없는 기능**: Synode는 모델 간 직접 반박/견제 메커니즘 없음

**비관습적 대안 의무 (Lv.3+ 필수)**:
- 매 사이클 1명이 채택 확률 <10% 수준의 비전형적 접근법 제시
- 5개 항목 평가: 지지 논거, 반론, 이상적 시나리오, 노력 수준, 리스크 등급
- 탐색 공간 의도적 확장
- **Synode에 없는 기능**: Synode는 모델이 기존 방향의 연장선에서만 답변

### 2.3 토론 방식 비교 판정

**Synode 우위 영역**:
- **Sequential 모드**: 이전 답변을 참조한 점진적 논의 깊화. 아누의 에이전트 미팅은 각 사이클 내에서는 Independent(병렬) 방식만 사용
- **모델 다양성**: 8개 프로바이더 30+ 모델을 자유롭게 조합. 아누는 5개 모델/3개 엔진에 고정
- **사용자 접근성**: GUI에서 드래그앤드롭으로 Council 구성 변경. 아누는 organization-structure.json 수정 필요
- **Discussion Depth 토글**: Thorough/Concise를 UI에서 즉시 전환. 아누는 작업 레벨로 간접 제어

**아누 우위 영역**:
- **반복 심화**: 최대 6사이클 반복으로 미해결 항목까지 추적. Synode는 1회 종합
- **구조적 견제**: DA + 비관습적 대안으로 체계적 반대 입장 강제. Synode는 모델 간 견제 없음
- **역할 특화**: 백엔드/프론트/UX/QA 등 전문 역할. Synode는 모델 고유 특성에만 의존
- **합의 기준**: Lv.4 만장일치, DA 반박 통과 등 명시적 합의 기준. Synode는 Master 단독 판단
- **환각 방지**: 근거 인용 필수 게이트. Synode에는 근거 검증 메커니즘 없음
- **실행 연결**: 미팅 결과가 3문서 → 코딩 → QC로 직결. Synode는 텍스트 답변에서 종료

---

## 3. 프롬프트 엔지니어링 비교

### 3.1 Synode의 프롬프트 모드

**Upfront 모드**:
- Master가 토론 시작 전 각 멤버에게 맞춤 시스템 프롬프트 생성
- "이 주제에 대해 너는 보안 관점에서 분석해라" 식의 역할 부여
- **장점**: 토론 전 역할 명확화
- **단점**: 대화 흐름에 따른 동적 조정 불가

**Dynamic 모드**:
- 각 차례 직전에 축적된 맥락을 반영한 동적 프롬프트 생성
- 이전 모델 응답에서 부족한 관점을 다음 모델에게 보완 요청
- **장점**: 맥락 적응적
- **단점**: Master 모델의 추가 API 호출 비용

### 3.2 아누 시스템의 프롬프트 방식

**구조적 프롬프트 (team_prompts.py)**:
- 팀별 프롬프트 생성기가 역할/워크플로우/변수를 구조적으로 조합
- "목차→요약→상세" 3-Tier로 토큰 효율 최적화
- 작업 파일 경로만 전달, 상세는 팀장이 직접 Read

**페르소나 기반 역할 부여**:
- 각 에이전트에 신화 기반 페르소나 + 전문성 프로필 부여
- 조직도(organization-structure.json)에 고정된 역할
- Synode의 Upfront 모드와 유사하나 더 깊은 역할 정의

**동적 프롬프트의 부재**:
- 아누 시스템은 Synode의 Dynamic 모드에 대응하는 메커니즘이 없음
- 각 사이클에서 아누가 수동으로 쟁점을 재정리하여 전달 (자동 아님)

### 3.3 비교 판정

**Synode 우위**: Dynamic Prompt Engineering은 아누에 없는 고유 기능. 자동으로 맥락 적응적 프롬프트를 생성하는 것은 토론 품질 향상에 기여.

**아누 우위**: 구조적 프롬프트 생성 (토큰 효율 40-60% 절감 목표), 팀/역할별 세분화된 프롬프트 템플릿.

---

## 4. 멀티모델 활용 비교

### 4.1 Synode의 멀티모델

- **8개 프로바이더**: Anthropic, OpenAI, Google, xAI, DeepSeek, Mistral, Together AI, Cohere
- **30+ 모델**: Claude, GPT-5.2, Gemini 2.5, Grok-4, DeepSeek V3/R1, Llama 4 등
- **활용 방식**: 동일 주제에 대해 서로 다른 모델의 관점 비교
- **장점**: 모델 특성(추론형/생성형/특화형) 활용, 가격대 다양
- **한계**: 모델을 "의견 제시자"로만 사용. 코드 실행, 파일 조작 등 실행 역량 없음

### 4.2 아누 시스템의 멀티모델

- **3개 엔진**: Anthropic, Z.AI, Google
- **5개 모델**: Opus 4.6, Sonnet 4.6, Haiku 4.5, GLM-5, Gemini
- **활용 방식**: 역할별 최적 모델 배치 (의사결정=Opus, 코딩=Sonnet, 테스트=Haiku, 비용최적화=GLM, 세컨드오피니언=Gemini)
- **장점**: 모델 특성을 역할에 매핑. 비용 최적화 (단순 작업에 Haiku/GLM)
- **한계**: 5개 모델에 고정. 새 프로바이더 추가 시 인프라 수정 필요

### 4.3 비교 판정

**Synode 우위**: 프로바이더/모델 수 압도적 (8/30+ vs 3/5). 새 모델 추가가 API 키 입력만으로 가능.

**아누 우위**: 모델을 역할별로 목적 배치. "동일 질문에 다른 답변"이 아니라 "다른 역할에 최적 모델". 실제 실행 역량(코딩/테스트/배포)이 있음.

---

## 5. Synode에서 아누 시스템에 도입 가능한 아이디어

### 5.1 Sequential 토론 모드 → 에이전트 미팅 적용

**현재 아누**: 에이전트 미팅에서 페르소나를 병렬(Independent) 소집만 사용.

**Synode 아이디어**: Sequential 모드 — 이전 페르소나의 의견을 다음 페르소나에게 전달하여 점진적 심화.

**적용 방안**:
- 에이전트 미팅 스킬에 "토론 모드" 파라미터 추가: `--mode sequential` / `--mode independent` / `--mode hybrid`
- Hybrid 모드: 1차 라운드는 Independent(다양성 확보) → 2차부터 Sequential(심화)
- Sequential 시 페르소나 순서에 의미 부여: 일반론→전문→비판→종합

**기대 효과**: 중간 (다양성은 유지하면서 논의 깊이 향상)
**구현 난이도**: 낮음 (Task tool 호출 순서 변경 + 이전 결과 전달)

### 5.2 Dynamic Prompt Engineering → 위임 시 동적 프롬프트 생성

**현재 아누**: team_prompts.py로 정적 프롬프트 생성. 팀원별 맥락 적응 없음.

**Synode 아이디어**: Dynamic 모드 — 각 팀원 위임 직전에 축적된 맥락을 반영한 맞춤 프롬프트 자동 생성.

**적용 방안**:
- 팀장이 서브태스크 병렬 위임 시, 이전 팀원 결과나 미팅 쟁점을 자동 요약하여 각 팀원 프롬프트에 삽입
- 예: 백엔드 팀원이 먼저 완료 → 그 결과를 프론트엔드 팀원 프롬프트에 "백엔드 API가 이렇게 구현됨" 컨텍스트로 추가
- team_prompts.py에 `dynamic_context` 파라미터 추가

**기대 효과**: 중상 (팀원 간 정보 연결성 향상, 통합 오류 감소)
**구현 난이도**: 중간 (팀장 워크플로우 수정 + 결과 요약 로직 필요)

### 5.3 Discussion Depth 조절 → 작업 레벨과 연동

**현재 아누**: 작업 레벨(Lv.1~4)로 계획 깊이는 차등화되지만, 에이전트 미팅 자체의 "깊이"는 조절하지 않음.

**Synode 아이디어**: Thorough/Concise 토글 — 토론 깊이를 상황에 맞게 조절.

**적용 방안**:
- 에이전트 미팅 스킬에 `--depth thorough` / `--depth concise` 파라미터 추가
- Lv.2: concise (핵심 포인트 2-3개씩, 비용/시간 절약)
- Lv.3: thorough (종합적 추론 + DA + 비관습적 대안)
- Lv.4: thorough + 만장일치 (현행 유지)
- 작업 레벨 판정 시 자동으로 depth 결정

**기대 효과**: 중간 (Lv.2 작업에서 미팅 비용 30-50% 절감 추정)
**구현 난이도**: 낮음 (페르소나 프롬프트에 깊이 지시 추가)

### 5.4 @Mention 후속 대화 → 팀장 간 크로스 리뷰

**현재 아누**: 팀 간 크로스 리뷰 메커니즘 없음. 1팀이 만든 코드를 2팀이 리뷰하는 구조 없음 (마아트 QC가 독립 검증하지만 "다른 개발팀"의 관점은 아님).

**Synode 아이디어**: @Mention으로 특정 모델에 후속 질문 — 전체 컨텍스트를 유지한 채 추가 논의.

**적용 방안**:
- 아누가 1팀 결과물을 2팀장에게 "세컨드 오피니언" 요청하는 워크플로우
- critical/security 작업에서: 코딩팀 ≠ 리뷰팀 원칙 강화
- dispatch.py에 `--cross-review <other_team_id>` 옵션 추가
- 리뷰 팀장은 원팀의 보고서 + 코드를 읽고 의견 제시

**기대 효과**: 중상 (교차 검증 깊이 향상, 단일 팀 편향 방지)
**구현 난이도**: 중간 (dispatch.py 수정 + 리뷰 프롬프트 템플릿 필요)

### 5.5 토큰 사용량 투명 추적 → 비용 최적화

**현재 아누**: task-timer.py로 작업 시간은 추적하지만, 토큰 사용량(= 비용)은 추적하지 않음.

**Synode 아이디어**: 모델별 input/output 토큰 개별 추적, 시스템 프롬프트 생성 비용 별도 추적.

**적용 방안**:
- cokacdir 봇 실행 시 토큰 사용량을 memory/metrics/token-usage.jsonl에 기록
- 팀별/모델별/작업별 토큰 사용량 집계
- 대시보드에 비용 시각화 추가
- 비용 이상치 알림 (예: 단순 Lv.1 작업에 Opus 10만 토큰 사용 시 경고)

**기대 효과**: 높음 (비용 가시성 → 최적화 기회 발견)
**구현 난이도**: 중간 (API 응답에서 usage 추출 + 집계 로직)

### 5.6 그룹싱크 방지 메커니즘 → 미팅 품질 향상

**현재 아누**: DA와 비관습적 대안 의무로 일부 대응하지만, Synode의 Independent 모드처럼 "이전 의견을 아예 안 보여주는" 구조적 방지는 없음.

**Synode 아이디어**: Independent 모드 — 각 모델이 원본 질문만 보고 답변하여 앵커링 효과 원천 차단.

**적용 방안**:
- 에이전트 미팅 1차 라운드를 반드시 Independent 모드로 실행 (이미 병렬 소집으로 부분적 구현)
- 핵심: Task tool 프롬프트에 "다른 페르소나의 의견은 제공하지 않음" 명시적 선언
- 2차 라운드부터 이전 의견 공유 (Hybrid 방식)

**기대 효과**: 중간 (이미 병렬 소집으로 일부 달성, 명시적 선언으로 강화)
**구현 난이도**: 낮음 (프롬프트 문구 추가)

---

## 6. 아누 시스템만의 강점 (Synode에 없는 것)

### 6.1 실제 프로덕션 코딩 시스템
- Synode는 "AI에게 질문하고 답변 받는" 의사결정 보조 도구
- 아누는 코드 생성 → 테스트 → 배포까지 실행하는 **프로덕션 개발 시스템**
- Synode의 Council 토론은 텍스트 답변에서 끝남. 아누의 미팅은 3문서 → 코딩 → QC → 보고로 직결

### 6.2 조직적 품질 보증 (QC 파이프라인)
- 8개 verifier 자동 검증 (api_health, file_check, data_integrity, test_runner 등)
- 마아트(QC): "개발자 보고를 절대 신뢰하지 않음. 직접 재실행"
- 로키(레드팀): OWASP Top 10 + 보안 감사
- 위험도별 3단계 분기 (normal/critical/security)
- **Synode에 없는 이유**: Synode는 코드를 생성하지 않으므로 QC 자체가 불필요

### 6.3 비동기 오케스트레이션 (컨텍스트 격리)
- 멀티봇 독립 세션으로 오케스트레이터(아누) 컨텍스트 보호
- cokacdir --cron 비동기 위임으로 아누 컨텍스트 점유 없이 팀장 작업 가능
- **Synode**: 단일 세션 내에서 모든 모델 호출. Master 모델의 컨텍스트가 모든 답변으로 가득 참

### 6.4 작업 레벨 기반 차등 프로세스
- Lv.1~4 판정 → 계획 깊이/미팅 요건/DA 요건 자동 차등
- "단순 오타 수정에 6사이클 미팅" 같은 과잉 프로세스 방지
- **Synode**: 모든 질문에 동일한 Council 프로세스 적용 (차등화 없음)

### 6.5 환각 방지 게이트 + 핵미사일 발사코드
- "계획서의 모든 결정은 근거(코드 위치, 문서, 테스트 결과)를 인용해야 함"
- Context Purge + Checkpointing → 깨끗한 세션에서 재시작
- 제이회장님 승인 게이트
- **Synode**: 모델 답변의 사실 확인 메커니즘 없음

### 6.6 운영 인프라
- 대시보드 모니터링 (8개 API + SSE 실시간 갱신)
- Audit Trail (파일 변경 자동 JSONL 기록)
- 일일 업무일지 자동 생성
- task-timer 라이프사이클 관리
- 이벤트 큐 + 미이행 약속 추적
- **Synode**: 세션 히스토리와 토큰 추적만 제공

### 6.7 멀티모델 역할 배치 (vs 멀티모델 의견 수집)
- Synode: "같은 질문을 여러 모델에게" → 의견 다양성
- 아누: "다른 역할에 최적 모델을" → 비용 효율 + 역량 최적화
  - Opus = 의사결정, Sonnet = 코딩, Haiku = 테스트, Gemini = 세컨드 오피니언
- 근본적으로 다른 멀티모델 철학

### 6.8 Devil's Advocate + 비관습적 대안
- 체계적 반대 입장 강제 (매 사이클 순환)
- 비전형적 접근법 탐색 의무화
- **Synode**: 모델 간 자연스러운 의견 차이에만 의존, 구조적 반대 없음

---

## 7. TOP 5 도입 제안

### TOP 1: Sequential+Independent Hybrid 토론 모드 도입
- **개요**: 에이전트 미팅에 Sequential/Independent/Hybrid 모드 선택 가능하도록 확장
- **구현 난이도**: 낮음 (Task tool 호출 순서 변경 + 결과 전달 로직)
- **기대 효과**: 높음 — 현재 Independent 전용 미팅에 Sequential 심화 옵션 추가로 토론 품질 향상
- **적용 위치**: `.claude/skills/agent-meeting/SKILL.md` 수정 + 미팅 실행 로직
- **근거**: Synode의 Sequential 모드는 이전 의견을 참조한 점진적 논의 깊화라는 독자적 가치가 있음. 현재 아누 미팅은 병렬 소집 후 아누가 수동 통합하는데, Sequential을 2차 라운드부터 적용하면 페르소나 간 직접 대화 효과를 얻을 수 있음

### TOP 2: 토큰 사용량 투명 추적 + 비용 대시보드
- **개요**: 모든 API 호출의 토큰 사용량을 팀/모델/작업별로 추적, 대시보드에 비용 시각화
- **구현 난이도**: 중간 (API 응답 usage 추출 + JSONL 기록 + 대시보드 API 추가)
- **기대 효과**: 높음 — 비용 가시성 확보 → 낭비 포인트 발견 → 모델 배치 최적화
- **적용 위치**: dispatch.py + task-timer.py (usage 기록), dashboard/server.py (시각화)
- **근거**: Synode의 모델별 토큰 추적은 간결하지만 핵심적. 아누는 20명 규모 조직으로 비용 최적화 여지가 훨씬 큼. 현재는 "어떤 작업이 비용을 많이 쓰는지" 파악 불가

### TOP 3: Discussion Depth 토글 (작업 레벨 연동)
- **개요**: 에이전트 미팅에 thorough/concise 모드 추가, 작업 레벨과 자동 연동
- **구현 난이도**: 낮음 (페르소나 프롬프트에 깊이 지시 추가)
- **기대 효과**: 중간 — Lv.2 미팅에서 비용/시간 30-50% 절감 추정
- **적용 위치**: `.claude/skills/agent-meeting/SKILL.md` 수정
- **근거**: Synode의 Thorough/Concise 토글을 아누의 작업 레벨과 연동하면, 레벨에 맞는 적정 깊이로 미팅 효율 개선. 현재 모든 미팅이 thorough 수준

### TOP 4: Dynamic Context 주입 (팀원 간 맥락 연결)
- **개요**: 팀장이 서브태스크 위임 시, 이전 팀원 결과를 동적으로 요약하여 다음 팀원 프롬프트에 삽입
- **구현 난이도**: 중간 (결과 요약 로직 + team_prompts.py dynamic_context 파라미터)
- **기대 효과**: 중상 — 백엔드↔프론트엔드 간 인터페이스 불일치 감소
- **적용 위치**: team_prompts.py + DIRECT-WORKFLOW.md
- **근거**: Synode의 Dynamic Prompt Engineering에서 착안. 현재 팀원들은 독립적으로 작업한 후 팀장이 통합하는데, 동적 맥락 주입으로 팀원 간 연결성 향상

### TOP 5: 크로스팀 리뷰 (@Mention 모델)
- **개요**: critical/security 작업에서 다른 팀 팀장에게 세컨드 오피니언 리뷰 요청
- **구현 난이도**: 중간 (dispatch.py --cross-review 옵션 + 리뷰 프롬프트 템플릿)
- **기대 효과**: 중간 — 교차 검증 깊이 향상, 단일 팀 관점 편향 방지
- **적용 위치**: dispatch.py + team_prompts.py
- **근거**: Synode의 @Mention 후속 대화에서 착안. 마아트(QC)가 독립 검증하지만 "다른 개발팀의 개발자 관점" 리뷰는 현재 없음. 1팀의 코드를 2팀장이 아키텍처 관점에서 리뷰하면 품질 향상

---

## 8. 결론

### Synode의 본질
Synode는 **멀티모델 의사결정 보조 도구**로서 우아하게 설계되었다. Council 패턴, Sequential/Independent 모드, Dynamic Prompt Engineering 등 "여러 AI의 의견을 어떻게 효과적으로 모을 것인가"에 집중한 솔루션이다.

### 아누 시스템의 본질
아누 시스템은 **AI 소프트웨어 개발 조직**이다. 의사결정을 넘어 실행(코딩/테스트/배포)까지 포괄하며, 품질 보증(QC/레드팀), 운영 인프라(대시보드/Audit Trail), 프로세스 관리(작업 레벨/Phase 체이닝)까지 갖춘 엔터프라이즈급 시스템이다.

### 핵심 교훈
Synode에서 가져올 가장 가치 있는 것은 **토론 방법론**이다:
- Sequential+Independent Hybrid로 미팅 품질 향상
- Discussion Depth로 미팅 효율 최적화
- Dynamic Context로 팀원 간 연결성 강화

아누가 Synode보다 압도적으로 우월한 영역은 **실행 역량**과 **조직적 품질 보증**이다. Synode가 "답변을 만드는 곳"이라면, 아누는 "소프트웨어를 만드는 곳"이다.

### 이전 비교분석과의 관계 (Superpowers vs 아누)
- Superpowers: 코딩 워크플로우 도구 (TDD, Git Worktree 등 실행 단계 강점)
- Synode: 의사결정 토론 도구 (Council 패턴, 토론 모드 등 기획 단계 강점)
- 아누: 기획 + 실행 + 검증 전체 라이프사이클 (두 도구의 강점을 선별 흡수 가능)

---

**참조 소스**:
- Synode GitHub: https://github.com/mahatab/synode-council-of-ai-agents (MIT, 23 stars, v0.1.5)
- 아누 가이드: `memory/specs/anu-guide.md` v1.1
- 작업 레벨 시스템: `memory/specs/work-level-system.md` v1.0
- 에이전트 미팅 스킬: `.claude/skills/agent-meeting/SKILL.md` v1.3
- 조직도: `memory/organization-structure.json` v2.0
- Superpowers 비교분석: `memory/research/superpowers-vs-anu-comparison.md` (task-328.1)
- 팀 프롬프트: `prompts/team_prompts.py`
- 워크플로우: `prompts/DIRECT-WORKFLOW.md`, `teams/dev3/GLM-WORKFLOW.md`