# Agent 미팅: AI집단지성 그룹챗 대화 메모리 지능화 체계 설계

**날짜**: 2026-03-15
**소집 이유**: 제이회장님이 현재 1팀에 위임된 Phase 1/2 계획보다 더 체계적이고 지능적인 시스템을 요구. 주제별 분할, 목차화, 요약, 검색 체계에 대한 다각적 검토 필요.
**참여 페르소나**: 헤르메스(설계), 프레이야(UX), 아르고스(테스터), 프로메테우스(전략), 로키(레드팀/DA)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2

---

## Cycle 1 (Independent)

### 아누 분석

현재 conversation_memory.py가 기본 영속화(JSONL+자동요약)를 갖추었으나, 제이회장님이 원하는 수준과 큰 갭:
- 주제 전환 감지/분리 미구현
- 목차/인덱스 미구현
- 검색 미구현
- 아누 시스템 연동 미흡

근거: conversation_memory.py 코드 분석, dispatch-groupchat-memory-intelligence.md 태스크 파일

### 페르소나 의견

**헤르메스 (설계)**:
- 주제 감지: 하이브리드 (규칙 기반 프리필터 + 10-15메시지 LLM 배치 판정)
- 저장: 4계층 구조 (raw/topics/index/search)
- 목차: 일간 인덱스 JSON + 주간 인덱스
- 검색: 키워드 역인덱스 + fulltext + LLM 시맨틱(Phase 2)
- 비용: Haiku/Sonnet 티어링, 월 ~$7
- 아누 연동: AncGroupChatBridge 전용 인터페이스
- 4 Phase 로드맵: P1(구조+규칙) → P2(LLM분류+요약) → P3(검색+명령어) → P4(아누연동)

**프레이야 (UX)**:
- 2채널 전략: Telegram-First + 대시보드 보완
- 목차: 2축 (주제축+시간축) + 계층적 펼치기
- 검색: 3단계 (키워드매칭 → 자연어질의 → 맥락적연결)
- 실시간 피드백: 사일런트 태깅 기본 (알림 없이 내부 처리)
- Telegram 진입점 `/메모리` 하나로 통일 + InlineKeyboard 네비게이션
- 비관습적: Telegram WebApp 미니앱으로 리치 UI 제공

**아르고스 (테스터)**:
- P0 버그 발견: _summary_counter 재시작 시 리셋 → 요약 파일 덮어쓰기!
- P0 버그: 날짜 전환 경계 시간순 역전
- 단일 Writer 원칙: conversation_memory.py vs group_chat.py 이중 쓰기 해소 필요
- 한국어: 주제 "경계" 잡기 어려움 → 키워드 클라우드 + 시맨틱 검색 권장
- 핵심 제안: JSONL에 topic_tag 필드 추가 (별도 파일 = 동기화 지옥)
- 별도 인덱스 파일 만들지 말 것 (요약 파일 자체가 인덱스)

**프로메테우스 (전략)**:
- ROI: 주제별 분할 > 목차 > 검색 (우선순위)
- 비관습적: "분할하지 말고 태깅하라" — 멀티태그 시스템
- 확장 로드맵: 지식 카드(Phase 4) → RAG(데이터 쌓인 후, Phase 5) → 의사결정 레지스트리(Phase 6)
- 아누 연동: 공통 메타데이터 스키마(느슨한 결합)
- 운영 비용 월 ~$2.50 추정, 진짜 비용은 구현 공수
- 현재 수준 A(검색가능)+B(재활용) 적정
- **절대 원칙**: 대화 자체에 제약 걸지 않음. 구조화는 사후 처리만.

**로키 (레드팀)**:
- P0: 파일 퍼미션 775→700 (보험업 민감정보!)
- P0: LLM 프롬프트 인젝션 — 요약 프롬프트에 XML 태그 분리
- P0: 비용 DoS — 레이트 리밋 + 일일 LLM 예산
- P0: PII 필터링 (주민번호, 전화번호, 계좌번호 패턴 마스킹)
- P0: 아누 참조 시 REFERENCE_ONLY 태그 + 그룹챗 결정 기반 자율위임 금지
- 아누 연동 시 쓰기 방향 차단 (아누→그룹챗 삽입 금지)
- 비관습적: SQLite WAL 모드 또는 파일 저장 자체 없애기

### Cycle 1 합의

합의점:
1. 사후 처리 원칙 (대화에 제약 없음)
2. 비용 Haiku/Sonnet 티어링
3. 파일 퍼미션 즉시 수정 (P0)
4. _summary_counter 버그 즉시 수정 (P0)
5. Phase 분리 필수

쟁점:
1. 분할(별도 파일) vs 태깅(필드 추가) vs 최소(키워드 추출만)
2. 별도 인덱스 파일 필요성
3. 주제 감지 타이밍 (10-15개 배치 vs 50개 요약 시점)

---

## Cycle 2 (Sequential — DA 검증)

### 아누 분석 (잠정 결론)

Cycle 1의 합의와 쟁점을 종합하여 다음 잠정안 도출:
- JSONL 단일 소스 + topic_tag 필드 (아르고스+프로메테우스 합의)
- 요약 파일 메타데이터 기반 동적 인덱스 (별도 인덱스 미생성)
- 규칙 기반 프리필터 + 요약 시점 LLM 배치 분류

### Devil's Advocate

**지정**: 로키 (Cycle 2)

**1. 실패 시나리오**: JSONL 파일 비대화로 검색 성능 저하 + topic_tag 오분류 누적으로 3개월 차에 검색 기능을 아무도 안 쓰게 됨
**2. 후회 이유**: "별도 파일 미생성" 결정으로 주제별 회고/연동 시 매번 JSONL grep 필요. "Phase 2 LLM 검색"은 사실상 미구현 선언.
**3. 더 단순한 대안**: SQLite — 인덱스/검색/스키마변경이 자연스럽고, Python 표준 라이브러리에 포함.

**비관습적 대안**: "Event Sourcing + Materialized View" 아키텍처
- 원본(events.jsonl)은 append-only, 파생 데이터(주제별/날짜별/요약)는 독립 view 파일
- 평가: (1)단일소스+접근편의 동시달성 (2)과잉엔지니어링 위험 (3)월 1만건+ 시 적합 (4)노력 중상 (5)리스크 중

### 반박 (아누 + 헤르메스)

1. **스케일**: 날짜별 JSONL 분리로 개별 파일 ~100KB/일. 5만줄 초과 시 rotation 정책 추가.
2. **접근성**: "주제별 뷰 파일은 캐시이지 중복이 아니다" 원칙 채택. 향후 Materialized View 형태 추가 가능.
3. **Phase 2 검색**: Phase 1에 `/기억 <키워드>` 기본 검색 반드시 포함하도록 수정.

헤르메스 추가:
- 파일명 규칙이 곧 1차 인덱스: `{날짜}_{주요주제slug}.md`
- 요약 메타데이터 스키마 확정 필수 (date, msg_range, topic_tags, participants)
- 지연 인덱싱 트리거: 요약 파일 200개 초과 시 인덱스 파일 자동 생성

**판정**: 반박 수용. 설계 3건 수정 반영 (rotation, 기본검색 포함, 지연 인덱싱).
**비관습적 대안 판정**: 현재 미채택. 원칙("뷰=캐시") 반영. 규모 성장 시 재검토.

---

## 최종 합의 사항

### 1. 저장 구조
- **JSONL 날짜별 파일 유지** (현행). 각 레코드에 `topic_tag` 필드 추가
- 별도 주제 파일 미생성 (향후 "뷰/캐시" 형태 추가 가능성 열어둠)
- raw JSONL 경로: `memory/groupchat/raw/{날짜}.jsonl` (현행 경로에서 raw/ 하위로 이동)
- JSONL rotation: 단일 파일 5만줄 초과 시 자동 분할

### 2. 주제 감지
- **규칙 기반 프리필터**: 침묵 갭(5분) + 명시적 전환 키워드
- **요약 시점 LLM 배치 분류**: 50개 요약 시 topic_tags도 함께 추출 (추가 LLM 호출 없음)
- topic_tags: 사전 정의 태그 셋 + 자유 태그 허용
- 한국어 특성 대응 프롬프트 포함 (주어 생략, 감탄사 무시 등)

### 3. 요약/메타데이터
- 요약 파일명: `{날짜}_{주요주제slug}.md` (파일명 = 1차 인덱스)
- 요약 메타데이터 스키마:
  ```yaml
  date: 2026-03-15
  msg_range: [1201, 1250]
  topic_tags: ["insuwiki", "firebase"]
  participants: ["제이회장님", "잼민이", "코덱스", "클로디"]
  key_decisions: ["Firebase Auth 방식 결정"]
  action_items: []
  consensus_level: exploratory | tentative | agreed | decided
  ```

### 4. 인덱스
- Phase 1: 파일명 기반 1차 인덱스 + 요약 메타데이터 glob 검색
- 지연 인덱싱: 요약 파일 200개 초과 시 캐시 인덱스 파일 자동 생성
- 인덱스는 항상 재구축 가능 (원본 JSONL에서)

### 5. 검색
- Phase 1: `/메모리` 진입점 + `/기억 <키워드>` + `/목차` + InlineKeyboard
- Phase 2: LLM 자연어 검색 (`/스마트검색`)
- 검색 대상: 요약 메타데이터(topic_tags, key_decisions) → 요약 본문 → JSONL 원본(fallback)

### 6. UX
- Telegram-First + 대시보드 보완 (2채널)
- 목차: 2축 (주제축+시간축)
- 사일런트 태깅 기본 (주제 전환 시 사용자 알림 없음)
- 진입점 `/메모리` 하나로 통일

### 7. 아누 시스템 연동
- 읽기 전용 인터페이스 (직접 파일 읽기가 아닌 전용 함수)
- `REFERENCE_ONLY` 태그 — 그룹챗 데이터 기반 자율위임 금지
- 쓰기 방향 차단 (아누→그룹챗 삽입 금지)
- `consensus_level` 메타데이터로 참조 수준 필터링

### 8. 보안 (즉시 조치)
- 파일 퍼미션 700 (P0)
- PII 기본 필터 (주민번호/전화번호/계좌번호 패턴 마스킹) (P0)
- LLM 프롬프트에 XML 태그 분리 (P0)
- 레이트 리밋 + 일일 LLM 호출 예산 (P1)

### 9. 즉시 버그 수정
- `_summary_counter` 재시작 시 기존 파일 수 기반 복구 (P0)
- 날짜 전환: 메시지 timestamp 기준 파일 결정 (P0)
- 요약 중복 실행 방지 세마포어 (P1)

### 10. 대화 원칙 (절대 규칙)
- 대화 자체에 어떤 제약도 걸지 않음
- 구조화는 사후 처리(post-processing)로만 수행
- 주제별 뷰 파일은 "캐시"이지 "중복"이 아님

---

## Temporal Interrogation (시간대별 결정사항)

### [HOUR 1] 작업 시작
- [RESOLVED] conversation_memory.py에 topic_tag 필드 추가
- [RESOLVED] _summary_counter 버그 수정 (Path.glob 기반 복구)
- [RESOLVED] 파일 퍼미션 chmod 700
- [OPEN] raw/ 하위 디렉토리 이동 — 기존 경로 참조하는 코드 전체 탐색 필요

### [HOUR 2-3] 핵심 구현
- [RESOLVED] 요약 프롬프트에 topic_tags 추출 지시 추가 (1줄 추가)
- [RESOLVED] 요약 파일명 규칙: {날짜}_{slug}.md
- [OPEN] 사전 정의 태그 셋 초안 — 팀장이 결정 (보험/연금/개발/출판/운영/기타?)
- [OPEN] TopicDetector 클래스 — 규칙 기반 프리필터의 정확한 임계값 (침묵 갭 5분? 10분?)
- [OPEN] PII 필터 — 어디까지 마스킹할 것인가? (전화번호만? 주민번호도?)

### [HOUR 4-5] 구현 후반 + 통합
- [RESOLVED] Telegram 명령어: /메모리, /기억, /목차
- [OPEN] InlineKeyboard 페이지네이션 — Telegram callback_data 구조 설계
- [OPEN] 요약 메타데이터 파싱 — YAML front matter vs JSON 상단 블록?
- [RESOLVED] LLM 프롬프트 XML 태그 분리

### [HOUR 6+] 마무리 + QC
- [RESOLVED] 테스트: 요약 생성 → 파일명 확인 → 검색 동작 확인
- [OPEN] group_chat.py vs conversation_memory.py 이중 쓰기 통합 시점
- [OPEN] 봇 재시작 후 주제 컨텍스트 복원 테스트 시나리오

---

## 미해결 항목
1. SQLite 전환 여부 — 데이터 규모 성장 시 재검토 (6개월 후)
2. Telegram WebApp 미니앱 도입 — Phase 3 이후 UX 고도화 시점
3. 대시보드 메모리 탭 — Phase 2 이후
4. 지식 카드/RAG — Phase 4-5, 데이터 축적 후
5. group_chat.py와 conversation_memory.py 쓰기 통합 — 아키텍처 리팩토링 필요

---

## 다음 단계

### 합의 사항 → 작업 매핑

1. **즉시 수정 (P0)**: _summary_counter 버그 + 파일 퍼미션 + PII 기본 필터 → 1팀에 긴급 패치 위임
2. **Phase 1 재설계**: 현재 task-596.1(1팀)의 Phase 1 스펙을 이 미팅 합의로 업데이트
   - topic_tag 필드 추가
   - 요약 파일명 규칙 + 메타데이터 스키마
   - TopicDetector 규칙 기반 프리필터
   - /메모리, /기억 Telegram 명령어
3. **Phase 2**: LLM 배치 분류 + 자연어 검색 + 아누 연동
4. 3문서 불필요 (기능/옵션 단위 작업, 프로젝트 시작 아님)

### 기각된 대안 기록
- 4계층 별도 파일 구조 (헤르메스 원안) → 동기화 불일치 위험으로 기각. "뷰=캐시" 원칙으로 대체
- 매 메시지 실시간 LLM 분류 → 비용 폭발로 기각
- 별도 인덱스 파일 상시 관리 → 불일치 위험으로 기각. 지연 인덱싱으로 대체
- SQLite 즉시 전환 → 현재 JSONL 구조와의 호환성 + 기존 코드 변경 규모 고려. 6개월 후 재검토
- Event Sourcing 아키텍처 → 과잉 엔지니어링. 원칙(뷰=캐시)만 채택