# 에이전트 미팅: 팀 단톡 기능 설계

- **일시**: 2026-03-05
- **작업 레벨**: Lv.3 (복합 기능)
- **안건**: AI 페르소나들이 Telegram에서 실시간으로 대화하는 "팀 단톡" 기능 설계
- **참석**: 헤르메스, 토르, 아테나, 아르고스

---

## Cycle 1

### 아누 분석
- cokacdir 아키텍처 조사: 4개 봇(A~D)이 동일 채팅(6937032012)에 메시지 전송 가능
- cokacdir `--cron`은 Claude 세션 생성 → 실시간에 부적합 (5~10초 지연)
- `--sendtext` 미존재, `--sendfile`은 파일 전송만 가능
- bot_settings.json에 실제 Telegram 봇 토큰 존재 → Python 직접 API 호출 가능

### 페르소나 의견
**헤르메스**: 설계 방향 동의. Claude API 호출 시 시스템 프롬프트 캐싱(cache_control) 활용으로 토큰 90% 절감 가능. MAX_AUTO_TURNS=6으로 무한루프 방지 필수. 모델은 claude-sonnet-4-6으로 비용 절감. max_tokens=300 제한.

**토르**: 옵션 B(백그라운드 데몬 + 트리거 파일) 권장. 세션이 아누 응답 사이클과 독립적으로 존재 가능. MVP 200줄 이내 구현 가능. 트리거 파일 인터페이스: `memory/events/group_chat_trigger.json`.

**아테나**: 단일 봇 포맷 시 HTML parse_mode 사용 권장 (MarkdownV2는 이스케이프 이슈). 페르소나별 이모지 아이콘 부여로 시각 구분. 입장/퇴장 시퀀스 필수 (몰입감). 종료 시 요약 한 줄 포함.

**아르고스**: 전반적 동의, 아래 우려 제기.

### Devil's Advocate (아르고스)
**지정**: 아르고스 (Cycle 1)

1. **실패 시나리오**: 복수 봇 동시 응답 시 Telegram 메시지 순서 보장 불가. Race condition 발생.
2. **후회 이유**: 봇 추가 시 오케스트레이터 복잡도 선형 증가. 확장성 문제.
3. **더 단순한 대안**: 단일 오케스트레이터가 각 봇 API를 순차 호출, 결과를 하나의 Telegram 채널에 포맷해서 전송. Telegram은 "출력 채널"일 뿐.

**반박**:
- 우려 1: 오케스트레이터가 순차 제어. 한 번에 한 페르소나만 발화 → race condition 원천 차단. ✅ 수용
- 우려 2: 봇 최대 4개, config dict 하나로 관리. O(4) 수준. ✅ 수용
- 우려 3: **부분 수용**. Phase 1은 DA 제안대로 단일 봇(Bot A) 출력. Telegram API 직접 호출로 개별 메시지 전송. Phase 2에서 Telegram 그룹 + 멀티봇 검토. ⚠️ 설계 수정

**판정**: 우려 3에 의해 설계 수정 — 단일 봇 출력으로 변경

### 합의/결론
- 단일 봇(Bot A) 출력, HTML 포맷 `<b>⚡ [헤르메스]</b> 메시지`
- 백그라운드 데몬 방식 (트리거 파일 인터페이스)
- Claude Sonnet 4.6, max_tokens=300, 캐싱 적용
- Phase 2에서 멀티봇/그룹 전환 검토

### 미해결 항목
- 세션 중 유저 메시지 수신 경로 상세화 → Cycle 2

---

## Cycle 2

### 아누 분석
- bot_settings.json에서 4개 봇 Telegram 토큰 확인 → 직접 API 호출 가능
- sendMessage는 getUpdates에 안 잡힘 → cokacdir 폴링과 간섭 없음
- 연동 방식: 옵션 B(데몬) 확정. 아누가 트리거 파일 생성 → 데몬이 처리

### 페르소나 의견
**헤르메스**: API 비용 구조 정리 — 프롬프트 캐싱 + Sonnet + max_tokens=300으로 턴당 ~$0.003. 에러 핸들링 필수: RateLimitError → 2초 대기 재시도, APITimeoutError → 스킵, 3회 연속 실패 → 세션 종료.

**아테나**: 입장 시퀀스("잠깐요, 모을게요" → 각 페르소나 입장) + 퇴장 시퀀스(각자 인사 → 아누 요약) 필수. 발화자 균형 — 직전 발화자 제외 + 덜 말한 페르소나에 가중치. 메시지 간 0.5초 딜레이 (Telegram 레이트리밋 + 자연스러움).

**토르**: MVP 코드 구조 제안 — group_chat.py 약 200줄. 트리거 파일 JSON 인터페이스 확정. 엣지 케이스: (1) 세션 중 아누 재시작 → 세션 상태 파일 덤프, (2) Telegram 레이트리밋 → sleep(0.5), (3) 3회 API 실패 → 강제 종료, (4) 동시 세션 → 하나만 허용.

### Devil's Advocate (토르) — Cycle 2
**지정**: 토르

1. **실패 시나리오**: 데몬 프로세스가 죽으면 세션 복구 불가. systemd 등 프로세스 관리 없이 운영 위험.
2. **후회 이유**: 트리거 파일 폴링(1초)은 원시적. 추후 WebSocket이나 IPC로 변경 시 대규모 리팩토링 필요.
3. **더 단순한 대안**: 데몬 대신 아누가 직접 subprocess로 실행. 세션 = subprocess 수명. 프로세스 관리 불필요.

**반박**:
- 우려 1: Phase 1은 수동 실행(`python3 group_chat.py &`), 안정화 후 systemd 등록. 세션 상태 파일 덤프로 복구 가능. ✅ 수용 + 로드맵 반영
- 우려 2: 트리거 파일은 Phase 1 MVP. 향후 변경 시 인터페이스 레이어만 교체. 코어 로직(세션/페르소나)은 독립적. ✅ 수용
- 우려 3: subprocess 방식은 아누 세션이 끝나면 같이 죽음. 장시간 대화 불가. 데몬이 맞음. ✅ 반박 수용

**판정**: 반박 수용. 데몬 방식 유지, 단 Phase 1은 수동 실행.

### 합의/결론 (최종)
- **출력**: Bot A 단일, HTML parse_mode, 페르소나별 이모지
- **아키텍처**: 백그라운드 데몬 (`group_chat.py`), 트리거 파일 인터페이스
- **모델**: claude-sonnet-4-6, max_tokens=300, 캐싱 적용
- **세션**: 인메모리 + 주기적 파일 덤프, 5분 타임아웃, MAX_AUTO_TURNS=6
- **UX**: 입장/퇴장 시퀀스, 0.5초 딜레이, 종료 시 요약
- **트리거**: 자연어 감지 (Claude 판단), 시작/종료/유저입력 3종 액션
- **Phase 2**: Telegram 그룹 + 멀티봇, systemd 등록

### 미해결 항목
- 없음 (모든 쟁점 합의 완료)

---

## 결정 사항 요약

- 출력 채널: Bot A 단일 (Telegram sendMessage API 직접)
- 토큰 소스: `/home/jay/.cokacdir/bot_settings.json`
- 포맷: `<b>⚡ [헤르메스]</b> 메시지` (HTML parse_mode)
- API: claude-sonnet-4-6, max_tokens=300, cache_control
- 연동: 트리거 파일 → 데몬 → Telegram API
- 세션: 5분 타임아웃, MAX_AUTO_TURNS=6
- 입장/퇴장 시퀀스 포함
- 자연어 start/end 트리거 (Claude 판단)