# Agent 미팅: InsuWiki 아키텍처 심층 비교 (LLM Wiki vs Firestore+Next.js)

**날짜**: 2026-04-11
**소집 이유**: 제이회장님 지시 — "어떤 방안이 더 고도화된 방안인지, 비용/확장/SaaS화까지 고려했을 때 더 유리한지 심층적 검토 필요"
**참여 페르소나**: 오딘(아키텍처), 토르(백엔드/스케일링), 미미르(정보아키텍처/UX), 로키(레드팀/보안), 야누스(DevOps/인프라)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2
**작업 ID**: task-1641.1

---

## Cycle 1 (Independent Round)

### 헤르메스 분석
기존 리서치(마르둑, task-1482.1)에서 Option B(Firestore 기반 LLM Wiki 하이브리드)를 추천했으나, 제이회장님의 5개 축 심층 비교 요청에 따라 에이전트 미팅을 소집함. 참조: InsuWiki PRD v3, Firestore 타입 정의, LLM Wiki 원문 분석, 카파시 LLM Wiki 적용 리서치.

### 페르소나 의견

**오딘**: 방향 A 추천. Firestore가 비용 최적(100K건까지 월 $31), 확장성 내장(O(log n) 인덱스), SaaS화 즉시 가능. LLM Wiki의 검색/발견 장점은 Firestore 위에서도 구현 가능. "지금 아키텍처를 바꾸는 것은 premature optimization."

**토르**: 방향 C(현행 기반 진화형) 추천. LLM Wiki 1,000건+ 시 index.md 토큰 한계 도달로 B 기각. "LLM의 사전 컴파일 철학을 취하되, 런타임 인프라는 Firestore 유지"가 확장성+비용 양면 최적. 비관습적 대안: SQLite+FTS5+LLM 요약.

**미미르**: 방향 C(현행 기반 점진적 진화) 추천. 현행 5탭 카테고리의 한계(평면적 분류 vs 개념 네트워크) 지적. 엔티티 그래프 + LLM 종합이 FA의 실제 사고 흐름과 정렬. "현행 인프라 위에 엔티티 그래프와 LLM 종합을 점진적으로 적층하는 C가 위험 대비 효과 최적."

**로키**: 방향 A 추천. 할루시네이션의 영속화+증폭이 LLM Wiki의 구조적 위험. 금소법 제19조 위반 리스크. Cascade update가 공격 증폭기로 작동. "느리지만 정확한 시스템이 빠르지만 오염 가능한 시스템보다 법적·사업적 리스크가 현저히 낮다."

**야누스**: 방향 A 추천. 현행 Firestore 무료~$31/월로 100K건까지 커버. LLM Wiki 전환 시 초기 Ingest $10,000+. 운영 복잡도 증가 대비 절감 미미. 비관습적 대안: LLM을 인프라 전환이 아닌 기능 레이어로 활용.

### 합의/결론
- B(LLM Wiki 전환) **전원 기각**
- A(현행+흡수) vs C(현행 기반 진화형): 실질 동일 범위로 수렴
- 방향 A의 원칙 채택: "LLM을 인프라가 아닌 기능 레이어로 활용" (야누스)

### 미해결 항목
- A/C 경계 정리
- 3가지 흡수 기능 구체적 설계

---

## Cycle 2 (Sequential Round)

### 헤르메스 분석
Cycle 1에서 방향 A에 강한 합의 형성. 남은 쟁점: A/C 경계 판정, 3가지 흡수 기능의 구체적 Firestore 스키마/파이프라인 설계.

### 페르소나 의견

**오딘** (Sequential 1st):
A/C 판정: "C는 A의 구체적 구현이다. 별도 방향이 아니다." 토르/미미르 제안에 데이터 모델 근본 재설계가 없으므로 A 범위 내.

3가지 기능 구체 설계:
1. **엔티티 추출**: documents.extractedEntities 인라인 + entities 컬렉션 이중 구조. CF onDocumentWritten → Claude API. insurance_terms에 insurance_term_id 매핑. links에 method: 'entity_match' 자동 생성. 5일.
2. **/lint**: 4항목(중복/모순/고아/최신성). Scheduled Function 주 1회. lint_reports 컬렉션. 6일.
3. **/query**: 검색어 → 키워드 매칭 → extractedEntities 확장 → "종합 정리 보기" 버튼 → Claude 종합. /api/wiki/synthesize. query_cache TTL 1시간. 7일.
Phase 3에 통합, 총 추가 18일.

### Devil's Advocate
**지정**: 로키 (Cycle 2)

1. **실패 시나리오**: Claude API SPOF — 3기능 모두 Claude 의존. API 장애/비용 인상 시 전체 무력화. 비용 상한선 부재.
2. **후회 이유**: entities 컬렉션이 쓰레기 데이터 무덤. LLM 추출 비결정적 → 중복/불일치 누적. entities 자체가 lint 대상이 되는 재귀 문제.
3. **더 단순한 대안**: 수동 태그 5개 강제 + 전문검색 = 80% 해결, 7일이면 끝남.

추가 도전:
4. **PII 유출**: CF 자동 트리거 → 고객 개인정보가 Claude API에 자동 전송 → 개인정보보호법 위반.
5. **lint 할루시네이션**: LLM 모순 판정의 false positive → 사용자가 lint 무시.
6. **Prompt Injection**: 검색어가 프롬프트에 삽입 → 권한 밖 문서 노출 + cache 오염.

**반박**: 미미르

| 도전 | 판정 | 수정안 |
|------|------|--------|
| ① SPOF | 수용 | 큐 기반 비동기 + 3회 재시도 + pending 마킹 |
| ② 쓰레기 데이터 | 수용 | suggestedEntities 임시 저장 → 사용자 확인 → entities 승격 |
| ③ 수동 태그 | 부분 수용 | 자동 추출 초안 + 사용자 확인 하이브리드 (순수 수동 태그는 업로드 마찰 높음) |
| ④ PII | 수용 | 자동 트리거 제거 → 명시적 버튼 + PII 마스킹 레이어 |
| ⑤ lint 할루시네이션 | 부분 수용 | 모순 감지만 LLM, 나머지 3항목 규칙 기반 + confidence score |
| ⑥ Injection | 수용 | system/user 역할 분리 + 사후 권한 필터링 + tenant_id cache 바인딩 |

**판정**: 반박 수용. 설계 수정 5건 반영으로 합의.

### 비관습적 대안
**미미르 — 역방향 위키**: 문서 분류 대신 사용자 질문 등록 → 시스템이 관련 문서 역 매핑. 사용 패턴 자체가 정보 구조가 됨.
- **최강 지지 논거**: 실제 업무 맥락이 IA를 만들어 분류 체계 오류 제거
- **최강 반론**: 5~8명 사용자로는 패턴 축적 데이터 부족
- **이상적 사용 시나리오**: 사용자 50명+, query_logs 1,000건+ 축적 시
- **노력 수준**: 중간
- **리스크 등급**: 중간

**판정**: 현 단계에서 기각. Phase 3 이후 사용 패턴 축적 시 재검토. 맥락노트에 기록.

### 합의/결론
1. 방향 A 확정 (전원합의)
2. C는 A의 구현 세부사항으로 흡수
3. 3가지 흡수 기능: 오딘 원안 + 미미르 수정 5건
4. Phase 3에 통합 (총 추가 22일)
5. 핵심 원칙: "자동 추출은 초안, 사람이 확정, PII는 전송 전 마스킹"

### 미해결 항목
없음 (Cycle 2에서 전부 해소)

---

## 최종 합의 사항

1. **방향 A (현행 Firestore+Next.js 유지 + LLM Wiki 3가지 흡수)** 전원합의
2. B(LLM Wiki 전환) 전원 기각 — 확장성, 보안, SaaS, 비용, UX 전 축 열세
3. C는 A의 구현으로 흡수 — 별도 아키텍처 재설계 불필요
4. 3-1. 엔티티 추출: suggestedEntities(임시) → 사용자 확인 → entities(확정). 명시적 버튼 트리거 + PII 마스킹
5. 3-2. lint: 중복/고아/최신성은 규칙 기반, 모순만 LLM(confidence score 포함). 주 1회 Scheduled Function
6. 3-3. query 종합: 엔티티 기반 확장 검색 + "종합 정리 보기" 버튼. Prompt Injection 방어 3중
7. Phase 3에 통합 (총 추가 22일, 기존 Phase 3 항목과 합산 시 8~10주)
8. Phase 1 Week 3에 extractedEntities/entityLinks 필드 예약 추가
9. 보안 전제조건: PII 마스킹, Prompt Injection 방어, Claude API 비동기 큐
10. 핵심 원칙: "LLM은 기능 레이어, 인프라는 Firestore. 자동 추출은 초안, 사람이 확정"

## 기각된 대안
1. **B (LLM Wiki 전환)**: 5개 축 전 열세. 할루시네이션 영속화, Prompt Injection cascade, 멀티테넌시 부재
2. **토르의 SQLite+FTS5**: Firestore 이미 충분, 마이그레이션 불필요
3. **로키의 수동 태그 5개 강제**: 업로드 마찰 높음, 태그 품질 관리 비용. 하이브리드(자동 초안+수동 확인)로 부분 반영
4. **미미르의 역방향 위키**: 현 단계 데이터 부족(5~8명). Phase 3 이후 재검토

## Temporal Interrogation 결정사항
- [RESOLVED] Claude API 호출: 큐 기반 비동기 + 재시도
- [RESOLVED] PII 마스킹: 정규식 기반 (주민번호/전화번호/계좌번호)
- [RESOLVED] entities 승격: suggestedEntities → 사용자 확인 → entities
- [RESOLVED] lint: 모순만 LLM, 나머지 규칙 기반
- [RESOLVED] Prompt Injection: system/user 분리 + 사후 권한 필터링
- [OPEN] Claude API 키 관리 방식 (환경 변수 vs Secret Manager)
- [OPEN] 엔티티 카테고리 분류 체계 상세 확정
- [OPEN] 엔티티 추출 프롬프트 템플릿 설계

## 다음 단계
합의 결과를 3문서(계획서/맥락노트/체크리스트)에 반영 완료.
- 계획서: `/home/jay/workspace/memory/plans/insuwiki/llm-wiki-absorption/plan.md`
- 맥락노트: `/home/jay/workspace/memory/plans/insuwiki/llm-wiki-absorption/context-notes.md`
- 체크리스트: `/home/jay/workspace/memory/plans/insuwiki/llm-wiki-absorption/checklist.md`