# task-10.2 보고서: 멀티봇 아키텍처 개선 방안 팀 미팅

- **팀**: dev2-team (오딘)
- **작업**: 멀티봇 아키텍처 개선 방안 팀 미팅
- **참석**: 오딘(팀장), 토르(시니어), 프레이야(미들), 미미르(미들), 헤임달(주니어)
- **날짜**: 2026-03-01

---

## 1. 현재 아키텍처 분석

### 현행 흐름
```
제이회장님 → 아누(dispatch) → [헤르메스|오딘|라] → 작업 수행 → 보고서 파일 저장 → 아누가 파일 읽기
```

### 확인된 문제점
- **P1**: 아누가 팀 작업 완료를 실시간 감지 못함 (orchestrator.py로 해결 예정)
- **P2**: 봇 간 직접 메시지 불가 — 보고서 파일이 유일한 소통 수단
- **P3**: 봇D(라)의 GLM 코딩은 z.ai rate limit으로 병렬 불가
- **P4**: cokacdir --cron 최소 대기 1분 (즉시 실행 불가)

---

## 2. 팀 논의 결과

### 2-1. 워크플로우 개선

**토르 의견 — "이벤트 드리븐으로 전환"**
> 현재 orchestrator.py가 20초 폴링으로 완료를 감지하는데, 이건 리소스 낭비. 작업 완료 시 task-timer.py의 `end` 명령이 직접 시그널을 보내는 방식이 더 효율적.

**구체적 제안:**
1. `task-timer.py end` 실행 시 **완료 이벤트 파일** 생성 (예: `memory/events/task-9.2.done`)
2. orchestrator.py는 inotify 또는 watchdog으로 events/ 디렉토리 감시 → 폴링 제거
3. 폴링 대신 이벤트 기반이면 감지 지연 20초 → 1초 이하로 단축

**프레이야 의견 — "작업 체이닝 지원"**
> 현재 모든 작업이 독립적인데, 실제로는 A 결과를 B가 쓰는 경우가 있음. tasks.json에 `depends_on` 필드를 추가하면 orchestrator가 의존성을 자동 관리 가능.

```json
{
  "id": "task-10.3",
  "desc": "API 테스트 작성",
  "depends_on": "task-10.1"
}
```

**합의된 개선안:**
- **(A1)** task-timer.py end에 이벤트 파일 생성 로직 추가 — **우선순위: 높음**
- **(A2)** orchestrator.py에 inotify 기반 감시 추가 (watchdog 라이브러리) — **우선순위: 높음**
- **(A3)** tasks.json에 depends_on 필드 지원 — **우선순위: 중간**

---

### 2-2. 품질 관리

**헤임달 의견 — "자동 테스트 게이트"**
> task-9.3에서 라 팀이 GLM 코드에서 논리 버그를 발견했는데, GLM이 작성한 테스트가 assert 없이 출력만 하는 구조라 버그를 못 잡았음. 모든 작업에 테스트 통과를 완료 조건으로 강제해야 함.

**미미르 의견 — "코드 리뷰 체크리스트"**
> 보고서에 테스트 결과만 넣지 말고, 코드 품질 메트릭도 포함하자.

**구체적 제안:**
1. 보고서 템플릿에 필수 항목 추가:
   - 테스트 수 / 통과 수 / 실패 수
   - assert 기반 테스트 여부 (출력만 하는 테스트 불가)
   - 코드 라인 수
   - 외부 의존성 목록
2. orchestrator.py가 보고서 파싱 시 테스트 실패가 있으면 아누에게 경고 플래그 전달
3. GLM 코딩 시 라 팀장이 반드시 assert 기반 테스트를 추가 지시

**합의된 개선안:**
- **(B1)** 보고서 템플릿 표준화 (필수 필드 정의) — **우선순위: 높음**
- **(B2)** 테스트 실패 시 보고서에 WARNING 플래그 — **우선순위: 중간**
- **(B3)** GLM 프롬프트에 assert 기반 테스트 작성 명시 — **우선순위: 높음**

---

### 2-3. 커뮤니케이션 (봇 간 소통)

**프레이야 의견 — "공유 메시지 큐"**
> 현재 봇 간 소통이 파일뿐인데, 가벼운 메시지 교환용 공유 큐를 만들자.

**토르 의견 — "파일 기반으로 충분, 구조만 잡자"**
> 새로운 메시지 큐 시스템보다는 기존 파일 기반을 구조화하는 게 현실적. 복잡한 인프라 추가는 유지보수 부담.

**합의된 방안 — 구조화된 파일 기반 소통:**

```
memory/
  inbox/
    dev1-team/    ← 1팀에게 보내는 메시지
    dev2-team/    ← 2팀에게 보내는 메시지
    dev3-team/    ← 3팀에게 보내는 메시지
    anu/          ← 아누에게 보내는 메시지
```

- 각 메시지는 타임스탬프 파일명의 JSON (예: `2026-03-01T05-30-00_from-dev2.json`)
- 팀장 봇이 작업 시작 시 자기 inbox를 확인
- 즉시성이 필요한 메시지는 cokacdir --cron으로 알림

**합의된 개선안:**
- **(C1)** memory/inbox/ 디렉토리 구조 생성 — **우선순위: 중간**
- **(C2)** 메시지 읽기/쓰기 유틸리티 함수 (inbox_utils.py) — **우선순위: 중간**
- **(C3)** orchestrator.py가 작업 배치 시 inbox에 컨텍스트 메시지 전달 — **우선순위: 낮음**

---

### 2-4. 효율성 (작업 배분/병렬 처리)

**토르 의견 — "팀 역량 기반 배분"**
> 현재 orchestrator가 순서대로 빈 팀에 배치하는데, 작업 난이도와 팀 특성을 매칭하면 효율이 오름.

| 팀 | 특성 | 적합 작업 |
|---|---|---|
| dev1 (헤르메스/Opus) | 빠르고 정확 | 단순~중간 난이도 |
| dev2 (오딘/Opus) | 아키텍처 강점 | 설계 필요한 복잡 작업 |
| dev3 (라/Opus+GLM) | GLM 위임, 검토 시간 필요 | 단순 반복, 템플릿 작업 |

**미미르 의견 — "작업 시간 통계 활용"**
> task-timer 데이터가 쌓이고 있으니, 팀별 평균 작업 시간을 분석해서 배치 최적화에 활용 가능.

**합의된 개선안:**
- **(D1)** tasks.json에 `level` 필드 활용 강화 (easy/normal/hard) — **우선순위: 중간**
- **(D2)** 팀별 작업 시간 통계 집계 스크립트 — **우선순위: 낮음**
- **(D3)** GLM rate limit 대응: dev3에 2개 작업 연속 배치 금지 (쿨다운) — **우선순위: 중간**

---

### 2-5. 제이회장님 모니터링 경험

**프레이야 의견 — "대시보드 개선"**
> 현재 대시보드(http://100.76.130.39:8000/dashboard/)가 있지만, 실시간 업데이트와 알림이 부족.

**미미르 의견 — "텔레그램 요약 보고"**
> 제이회장님은 텔레그램으로 소통하시니까, 대시보드보다 텔레그램 내 요약이 더 접근성 높음.

**합의된 개선안:**
- **(E1)** 작업 배치/완료 시 텔레그램 원라인 요약 전송 (아누 경유) — **우선순위: 높음**
  - 예: `✅ task-9.2 완료 (dev2, 52초) | 🔄 task-9.4 시작 (dev2) | 진행: 4/8`
- **(E2)** `/status` 명령어로 현재 전체 진행 상황 즉시 조회 — **우선순위: 높음**
- **(E3)** 대시보드에 WebSocket 실시간 업데이트 추가 — **우선순위: 낮음**
- **(E4)** 일일 종합 보고서 자동 생성 (cron, 매일 18:00) — **우선순위: 중간**

---

## 3. 우선순위 정리 (실현 가능한 순서)

### 즉시 적용 가능 (코드 변경 최소)
1. **(B3)** GLM 프롬프트에 assert 기반 테스트 명시 — orchestrator.py의 build_prompt 수정만으로 가능
2. **(B1)** 보고서 템플릿 표준화 — 프롬프트에 템플릿 포함
3. **(E1)** 텔레그램 원라인 요약 — report_to_anu 메시지 포맷 개선

### 단기 (1-2 스프린트)
4. **(A1)** task-timer.py에 이벤트 파일 생성 추가
5. **(A2)** orchestrator.py inotify 전환 (watchdog)
6. **(D1)** tasks.json level 필드 활용 강화
7. **(E2)** /status 명령어 구현

### 중기 (3-4 스프린트)
8. **(A3)** 작업 의존성(depends_on) 지원
9. **(C1-C2)** inbox 기반 봇 간 소통
10. **(E4)** 일일 종합 보고서

### 장기 (백로그)
11. **(D2)** 팀별 통계 분석
12. **(E3)** 대시보드 실시간 업데이트

---

## 4. 핵심 제안 요약

### 가장 임팩트 큰 3가지

1. **이벤트 드리븐 전환 (A1+A2)**: 폴링 20초 → 즉시 감지. orchestrator의 핵심 개선.
2. **보고서 표준화 + 텔레그램 요약 (B1+E1)**: 제이회장님 모니터링 편의성 대폭 향상. 아누가 핵심 정보만 간결하게 전달.
3. **GLM 품질 강화 (B3)**: task-9.3에서 확인된 문제. 프롬프트 한 줄 수정으로 즉시 개선 가능.

### 주의사항
- 과도한 인프라 추가 지양 — 현재 파일 기반 구조가 단순하고 디버깅 쉬움
- 봇 간 직접 메시지(cokacdir --cron 경유)는 비용 발생 → 꼭 필요한 경우만 사용
- orchestrator.py는 1팀이 개발 중이므로, 개선 제안은 아누를 통해 1팀과 조율 필요

---

## 5. 비고
- 이 보고서는 2팀 내부 미팅 결과이며, 실제 구현은 아누(개발실장)의 판단에 따름
- orchestrator.py 관련 제안(A1, A2, A3)은 1팀(헤르메스)과 협의 필요
- 즉시 적용 가능한 항목(B3, B1, E1)은 아누 승인 시 다음 작업 배치부터 반영 가능