[자문] Pantheon 대화 상태 관리 모델 — DB/Redis 도입 여부

TL;DR

SQLite 도입은 면접(2026-05-26) 후로 보류. 면접 전에는 sessions.json JSONL 이벤트 로깅 1-2h 패치만. 도입 여부는 로그 실측 기반 재진단 후 결정.

질문 / 결정 사항

Pantheon(Slack 멀티 페르소나 AI 시스템)에서 대화 상태를 SQLite/Redis 등 자체 영속 저장소로 관리할지. 사용자가 호소한 증상 3가지:

1. AI 응답 누락 / 사용자 미응답 추적 어려움

2. 같은 문제에 여러 페르소나 중복 접근

3. 현재 작업 진행량 가시성 부족

현재 구조: sessions.json (68KB) 전역 lock + 통파일 read/write. 매 turn Slack API로 thread fetch. 봇 4-5개 동시 동작.

옵션 비교

Option A: SQLite conversations 테이블 도입 (Minimum)

장점

증상 1·3 즉시 해소 (state + last_activity_at + persona별 open count)
Asurada Inbox DM으로 awaiting_user 가시성 확보

단점

TOCTOU race: read-then-write 구조로 sessions.json과 동일한 동시성 취약점. processing 점유 상태 없이는 봇 중복 응답 미해결
orphan 레코드: Slack 메시지 삭제·90일 보존 만료·Socket Mode reconnect gap → SoT 분리 동기화 손실
마이그레이션 비용: sessions.json → SQLite 변환 + WAL 설정 + 검증. "1-2일" 추정은 낙관적
D-4 타이밍 위험: launchd 환경에서 DB lock 사고 → 면접 기간 시스템 중단 가능

트레이드오프

증상 3(가시성)은 해소되나 증상 1·2의 근본 원인은 데이터 모델 바깥일 가능성

---

Option B: 풀세트 (SQLite + dedupe pre-check)

장점

증상 1·2·3 모두 커버 의도

단점

topic_hint substring 매칭은 false positive/negative 높음
Option A 단점 + 1주 구현 비용
dedupe의 근본이 라우팅 레이어 문제라면 데이터 모델로 해결 불가

트레이드오프

가장 위험한 옵션. D-4 전 시작 시 리스크 최대

---

Option C: Spike 티켓만, 면접 후 시작 (원안)

장점

면접 기간 시스템 안정성 보장

단점

면접 기간(D-4 ~ D+0) 운영 불편 지속
"미루기"에 그치면 재진단 없이 동일 결정 반복

트레이드오프

그 사이 증상 1·3 가시성 확보 방법 없음

---

Option C+: JSONL 이벤트 로깅 (권장)

장점

구현 1-2h. sessions.json R/W 로직 그대로 유지
state transition 이벤트를 append-only JSONL로 기록 → jq로 즉시 가시성 (증상 1·3)
SQLite lock·마이그레이션·orphan 문제 없음
D-4 제약 내 유일하게 안전한 변경

단점

GC 미포함 (파일 무제한 증가 — 주기적 rotation 필요)
증상 2 dedupe 미해결 (별도 spike)

트레이드오프

완전 해결이 아니라 *진단을 위한 데이터 수집*. 면접 후 재진단 재료가 됨.

권장안

선택: Option C+ (JSONL 이벤트 로깅 + 면접 후 재진단)

근거:

D-4 타이밍: SQLite 도입은 Gemini·Manus 두 채널 모두 극도로 위험 지적. 1-2h 패치만이 안전 범위
재진단 우선: 증상 1의 근본 원인이 확정되지 않음. 후보 3가지 — silent fail(오류 처리 부재), Slack reaction race, Claude SDK timeout. 로그 grep 한 사이클이 자문 1회보다 진단 가치 높음
HAN-124 worktree에 thread_owner + Haiku router 이미 구현 중 → 라우팅 레이어 일부 구현됨. 증상 2는 HAN-124 머지 후 평가가 선행

면접 후 재진단 분기:

silent fail 확인 시 → 재시도/로깅 레이어가 본진. SQLite 도입 재검토
reaction race 확인 시 → atomic claim 패턴(UPDATE WHERE state='open' affected rows 0 체크). SQLite 도입 정당
timeout 확인 시 → Claude SDK 설정 본진. 데이터 모델 변경 보류

외부 자문 합산 신뢰도 주석:

자문 prompt를 "blind spot·비판 우선"으로 prefix하여 LLM 비판 모드 유도. 두 채널의 "잠정안 기각" 수렴이 진짜 다양한 시각인지 비판 echo인지 미확정. 사용자 본인 판단(직관)을 자문 위에 두는 것이 원칙.

참고 자료

Gemini 자문: ~/Workspace/consults/2026-05-22-pantheon-conversation-state/ (Gemini 응답 — Append-only JSONL, Master-Worker, Rate limit 위험)
Manus 자문: ~/Workspace/consults/2026-05-22-pantheon-conversation-state/manus-result.md (벡터 상태 모델, TOCTOU atomic claim, silent fail 가설, goal_summary 누락)
HAN-124 worktree: ~/Workspace/pantheon-worktrees/work-HAN-124/ (Codex quota fallback + thread_owner routing 구현)
HAN-280: Pantheon 대화 상태 관리 SQLite 이슈