# Agent 미팅: InsuWiki AI 노드 자동 연결 기능 구현

**날짜**: 2026-03-22
**소집 이유**: InsuWiki에 AI 기반 노드 자동 연결 기능 추가 — B안(기존 도구 검증 → 이식), 아누 서버 AI 백엔드. Lv.3 작업으로 에이전트 미팅 필수.
**참여 페르소나**: 오딘(아키텍처), 불칸(API), 토르(성능), 미미르(UX), 로키(보안/DA)
**미팅 모드**: hybrid
**토론 깊이**: thorough
**총 사이클 수**: 2

---

## Cycle 1 (Independent)

### 아누 분석
InsuWiki 코드베이스 탐색 완료. 기존 인프라: Next.js + Firebase Firestore + Vercel, Gemini 2.5 Pro, embeddings 서브컬렉션(768-dim), insurance_terms 컬렉션, links 컬렉션, WikiLink [[]] Cloud Functions. 3단계 로드맵(용어 사전 매칭 → 임베딩 유사도 → 지식 그래프) 검토 필요.

### 페르소나 의견

**오딘 (아키텍처)**:
- Phase 재구조: 1-A(정적 매칭, AI 불필요) → 1-B(의미적) → 2(유사도) → 3(지식 그래프)
- 3-layer 아키텍처: Runtime/Service/Data Access
- Firestore 이벤트 큐 통신 제안
- links 스키마 확장: createdBy, confidence 필드 Phase 1부터 필수

**불칸 (API)**:
- Cloud Function → 아누 REST 직접 호출 권장
- 비동기 fire-and-forget + 실시간 업데이트
- API Key + HMAC 인증
- 에러 격리: 저장 ≠ AI (완전 분리)
- 3-tier rate limiting: debounce 30s + concurrency 3 + daily cap 500
- Gemini/Claude 공존: 전용 파이프라인 (라우터 아님)

**토르 (성능)**:
- Claude에 embedding API 없음 → Gemini 임베딩 유지 필수
- Firestore onWrite 트리거로 비동기 임베딩 생성
- Firestore Vector Search 주 검색 엔진
- 스케일링: 카테고리 사전 필터링 (500→5000)
- 임베딩 메타데이터: model, dimension, content_hash

**미미르 (UX)**:
- 우측 사이드바 + 인라인 하이브리드
- 신뢰도 임계값: 95%+ 자동, 70-95% 추천, <70% 숨김
- 3-layer 신뢰 방어
- 시각 코딩: 실선/점선 밑줄 + 색상 + 아이콘
- 2-level 설명 필수, 기본 추천 최대 5개

**로키 (보안)**:
- Vercel→아누 경로 MITM 위험
- 금소법 오연결 비즈니스 리스크 (핵심!)
- 프롬프트 인젝션 체인 중독 시나리오
- Claude API 최소 데이터 원칙
- 감사 추적 5-10년 보존 필수
- Phase 0 보안 기반 선행 권고

### 합의/결론
- Gemini 임베딩 + Claude 의미 분석 역할 분리: 합의
- 비동기 패턴: 합의
- links 스키마 확장: 합의
- Audit trail: 합의
- UX 하이브리드: 합의

### 미해결 항목
1. Phase 0 보안 선행 vs Phase 1-A 직접 시작
2. 통신: Cloud Function REST vs Firestore 이벤트 큐
3. 신뢰도 임계값 95/70 검증

---

## Cycle 2 (Sequential)

### 아누 분석
Cycle 1 합의를 기반으로 3개 핵심 쟁점 재논의. 순서: 오딘→불칸→토르(비관습적 대안)→로키(DA).

### 페르소나 의견

**오딘 (아키텍처 재검토)**:
- Phase 0 보안 축소: Firestore Rules + links 스키마 validation만 선행 (0.5일). 본격 보안은 Phase 2 직전.
- 통신 확정: Cloud Function → 아누 REST 직접 호출. Firestore 이벤트 큐 기각 (500문서에서 과잉).
- 확장 전환점: 동시 50+/분 넘으면 큐 전환 검토.
- 신뢰도: 95/70 채택, config 외부화, 50건 실측 후 조정.

**불칸 (API 구체 설계)**:
- 단일 엔드포인트: `POST /api/v1/insuwiki/recommend` (type 파라미터로 분기)
- HMAC-SHA256 인증 (API Key 단독 거부 — 탈취 시 무방비)
- Timeout: Cloud Function 30초, 아누 호출 10초
- 아누 다운 시: graceful degradation (정적 매칭만 + aiStatus: unavailable). 재시도 금지.
- 정적 매칭: Cloud Function 내부 실행, insurance_terms 메모리 캐싱 TTL 1h
- links 스키마: `method: "static"|"embedding"|"semantic"` 추가. Phase 간 마이그레이션 불필요.
- Phase 0에 스키마 validation rule 필수 (confidence 범위, method 허용값)

**토르 (성능 보강)**:
- 임베딩 업데이트: content_hash(SHA-256) 비교 + lazy 재생성 (요청 블로킹 없음)
- Vector Search latency: 500문서 50-150ms, 5000문서 80-200ms. 병목은 Claude 호출(1-3초).
- 한국어 형태소 분석: ROI 안 맞음. 정규화 테이블(50-100개)로 대체. Phase 1-B 임베딩이 의미적 매칭 자동 해결.
- **비관습적 대안**: "LLM-only 추천" (임베딩 제거, Claude 직접) — 500문서까지 가능, 인프라 절반 감소. 단 확장성 한계.

### Devil's Advocate (로키)
**지정**: 로키 (레드팀)

1. **실패 시나리오**: Claude가 **관계 환각** 생성. 수치가 아닌 "노드 간 관계"의 환각은 fact_guard로 못 잡음. confidence 70 오답이 가장 위험. 금소법 리스크.
2. **후회 이유**: 이중 AI 의존(Gemini+Claude). Gemini 768-dim deprecated 시 전체 벡터 재생성. Phase 1-A가 90% 커버하는데 나머지 10%에 인프라 복잡도 80%. 운영자(제이회장님) 1인인데 AI 파이프라인 2개 관리 가능?
3. **더 단순한 대안**: Phase 1-A만 출시하고 멈춰라. 사전 매칭 80% + 수동 링크 20%. AI는 실측 데이터 본 후 판단.

**보안 취약점 TOP 3:**
1. HMAC 키 로테이션 메커니즘 부재
2. 사용자(uid) 기반 rate limit 없음 (GCP IP 고정이라 IP 기반 무의미)
3. AI 대량 오염 시 Firestore 롤백 불가

**반박**:
1. 관계 환각 → Phase 2에서 Claude에 "왜 관련되는지" 설명 강제 + 설명 불충분 시 추천 제외. 95% 미만 전부 사용자 승인 필요. AI 링크는 `status: "pending"`으로 관리, 승인 전 미반영.
2. 이중 AI → Phase 1-A 실측 게이트 추가. 50건 정확도 측정 → Phase 1-B Go/No-Go. 임베딩 모델 교체 시 벡터만 재생성, links 데이터 유지.
3. Phase 1-A만 → 계획서에 전체 Phase 포함하되, Phase 1-A 이후 반드시 Go/No-Go 게이트. 실측 없이 다음 Phase 금지.
4. HMAC 로테이션 → Cloud Secret Manager, 90일 자동 로테이션 추가.
5. Rate limit → uid 기반 분당 5건 추가.
6. 대량 오염 → AI 링크 pending 상태 + Firestore 주기적 export 백업.

**판정**: 반박 수용. 설계에 6건 보강 반영. DA 우려 해소.

### 비관습적 대안 평가
**제시자**: 토르
**대안**: LLM-only 추천 (임베딩 제거)
- 최강 지지: 500문서에서 인프라 절반 감소, Claude가 벡터보다 정확한 의미 연결 가능
- 최강 반론: 5000문서 이상 컨텍스트 한계, 토큰 비용 선형 증가 (월 $30-90)
- 이상적 시나리오: 1000문서 미만 확정, 인프라 운영 인력 제한
- 노력: 낮음 (구현량 40% 감소)
- 리스크: 중간 (1000문서 초과 시 재설계)

**판정**: 기각. 확장성 한계. Phase 1-A 실측 시 소규모 비교 테스트로 참고 가능.

### 합의/결론
전원 합의. 핵심 쟁점 3건 + 보안 3건 모두 해결.

### 미해결 항목
없음. (Phase 1-A 실측 후 Go/No-Go 게이트에서 Phase 1-B 이후 결정)

---

## Temporal Interrogation

### [HOUR 1] 작업 시작
- [RESOLVED] Firestore Rules 수정 — links 컬렉션 스키마 validation (confidence 0-100, method 허용값)
- [RESOLVED] insurance_terms 컬렉션 데이터 확인 — commonAliases 완비 여부
- [OPEN] 정규화 테이블(normalizeMap) 초기 데이터 — 제이회장님 검수 필요 (보험 용어 50-100개)

### [HOUR 2-3] 핵심 구현
- [RESOLVED] Cloud Function 정적 매칭 로직 — insurance_terms Set lookup + substring
- [RESOLVED] 사이드바 추천 UI 컴포넌트 구조 — 기존 InsuWiki 레이아웃에 맞춤
- [OPEN] confidence 점수 산정 로직 — 정적 매칭의 confidence 기준 (exact=100, alias=90, substring=70)

### [HOUR 4-5] 구현 후반 + 통합
- [RESOLVED] links 스키마 마이그레이션 — 기존 links에 method/confidence/createdBy 필드 추가
- [RESOLVED] 기존 WikiLink [[]] 기능과의 공존 — 기존은 method: "manual", 새로운 것은 method: "static"
- [OPEN] 기존 문서 대상 일괄 정적 매칭 실행 여부 — 신규 문서만? 기존 500개 전부?

### [HOUR 6+] 마무리 + QC
- [RESOLVED] 테스트: 기존 문서 10건 대상 정확도 90%+ 확인
- [RESOLVED] 배포: Cloud Function + Firestore Rules
- [OPEN] Phase 1-B 진행 판단 기준서 — 50건 실측 후 precision/recall 기준 명시 필요

---

## 최종 합의 사항

1. **Phase 구조**: 0(보안 기초) → 1-A(정적 매칭) → [Go/No-Go 게이트] → 1-B(임베딩) → 2(Claude 의미 분석) → 3(지식 그래프)
2. **통신**: Cloud Function → 아누 REST 직접 호출 (HMAC-SHA256, timeout 10초)
3. **역할 분리**: Gemini = 임베딩, Claude = 의미 분석/추천
4. **보안**: Phase 0 Firestore Rules + 스키마 validation, Phase 2에서 HMAC + uid rate limit + Secret Manager
5. **UX**: 사이드바 + 인라인 하이브리드, 신뢰도 기반 (config 외부화)
6. **관계 환각 방어**: AI 링크 pending 상태, 설명 강제, 95% 미만 사용자 승인 필수
7. **Go/No-Go 게이트**: Phase 1-A 완료 후 50건 실측 → Phase 1-B 진행 여부 결정
8. **한국어 매칭**: 정규화 테이블 (형태소 분석기 불필요)
9. **links 스키마**: method, confidence, createdBy, status 필드. Phase 간 마이그레이션 불필요 설계
10. **비관습적 대안(LLM-only)**: 기각. 확장성 한계.

## 다음 단계
- 3문서(계획서/맥락노트/체크리스트) 생성 → 1팀에 Phase 0 + Phase 1-A 위임
- Phase 1-A 실측 완료 후 Go/No-Go 게이트에서 Phase 1-B 결정