# 약관AI 심층 검증 — 라운드 4: 대응 방안 수립

**날짜**: 2026-03-03
**진행**: 아누 (개발실장)
**참석자**: 헤르메스, 오딘, 아르고스, 비너스, 로키, 김현장, 박신입, 강베테, 이심사, 정검사, 최변호
**상위 문서**: `memory/meetings/2026-03-03-round3-priority-matrix.md`

---

## Part 1. CRITICAL 클러스터 10개 — 대응 방안

---

### CL-1. 청킹/인덱싱 재설계
**해결 시 연쇄 해결**: B-1, A-1, A-2, A-8 + HIGH: A-3, A-12, B-16, B-18

#### 문제 요약
센텐스 바운더리 무시, 100자 overlap으로 "다만~" 이하 면책조항 절단. 모든 할루시네이션의 근본 원인.

#### 토론

**헤르메스**: 현재 청킹은 고정 길이(500자) + 100자 overlap입니다. 보험 약관의 조항 구조를 전혀 반영하지 않아요. 제안하는 해법은 3단계입니다.

1. **구조 인식 청킹(Structure-Aware Chunking)**: "제X조" 패턴을 조항 경계로 인식. 하나의 조(Article)가 하나의 청크가 되는 것이 이상적. 단, 1개 조가 2,000자를 넘으면 "항(①②③)" 단위로 분할.
2. **단서조항 보존 규칙**: "다만", "단,", "그러나", "제외한다", "적용하지 않는다" 등의 키워드가 포함된 문장은 절대 분리 금지. 해당 키워드 탐지 시 이전 문장과 반드시 동일 청크에 포함.
3. **Overlap 300자 + 양방향**: 현재 후방 overlap만 100자인데, 전후방 각 300자로 확대. 면책 열거가 300자를 초과하는 경우(드물지만 존재), 추가 안전장치로 "면책/부지급 사유" 키워드 포함 시 관련 전체 열거를 하나의 청크로 강제 병합.

**오딘**: 기술적으로 실현 가능합니다. 정규식으로 "제\d+조", "①~⑳" 패턴을 잡고, 단서 키워드 사전("다만", "단,", "~하지 아니한다", "~에 해당하는 경우에는") 약 30개를 정의하면 됩니다. 기존 45만 청크 전체를 재처리해야 하므로 **재인덱싱 파이프라인도 함께 수정**해야 합니다.

**아르고스**: 검증 방법을 제시합니다.
- **골든 테스트셋 Phase 1**: 면책기간(A-1), 감액기간(A-2), 보장개시일(A-8) 관련 조항 50개를 수동 마킹. 각 조항의 "다만" 이하가 동일 청크에 포함되는지 자동 검증 스크립트 작성.
- **Before/After 비교**: 동일 약관 PDF를 구/신 청킹으로 처리 후, 면책사유 포함률을 비교. 목표: 면책 키워드 포함 청크 비율 95% 이상.

**로키**: 구조 인식 청킹의 허점을 지적합니다. 약관 PDF 중 조문 번호 없이 "가.", "나.", "(1)", "(2)" 형태로 구조화된 것이 있습니다. 특히 손해보험 약관에 많아요. "제X조" 패턴에만 의존하면 이런 약관에서는 여전히 고정 길이 폴백이 작동하게 됩니다. **정규식 패턴을 최소 5가지 형태**로 확장해야 합니다.

**비너스**: Gemini 관점에서 하나 추가합니다. 청크가 길어지면 임베딩 품질이 변할 수 있어요. text-embedding-004의 권장 입력 길이는 512토큰인데, 조항 단위 청킹으로 1,000토큰이 넘는 청크가 생기면 임베딩 품질 하락 가능성이 있습니다. **긴 청크에 대해서는 요약 임베딩(summary embedding)을 별도 생성**하는 것이 안전합니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 구조 인식 청킹 + 단서조항 강제 보존 + Overlap 300자 양방향 |
| **선행 조건** | 약관 구조 패턴 사전 정의(5종 이상), 재인덱싱 파이프라인 수정 |
| **예상 난이도** | 어려움 |
| **예상 기간** | 2주 (청킹 로직 1주 + 전체 재인덱싱 1주) |
| **담당 추천** | 1팀(헤르메스) — 핵심 로직, 2팀(오딘) — 재인덱싱 파이프라인 병렬 |
| **잔존 리스크** | 비정형 구조 약관(5% 추정)에서는 폴백 적용. 완전 제거 불가 |

---

### CL-2. 상품 버전 관리
**해결 시 연쇄 해결**: A-7, B-2, C-2, C-8, C-14 + HIGH: B-13, B-20, E-20

#### 문제 요약
effectiveDate에 종료일 없음. 구/신 버전 동시 활성으로 세대 혼합 답변. 실손 세대별 자기부담금 혼동이 대표 사례.

#### 토론

**오딘**: 핵심은 3가지입니다.

1. **effectiveDateRange.end 필수화**: 새 약관 업로드 시, 동일 productId의 기존 문서에 end date 자동 설정. "신규 업로드 = 기존 버전 만료" 로직을 인덱싱 파이프라인에 삽입.
2. **검색 시 버전 필터 강제 적용**: 기본값은 "현행 버전만"(end가 null 또는 미래). 설계사가 "2020년 가입 기준"으로 검색하면 해당 시점 활성 버전으로 필터.
3. **실손 세대 메타데이터**: insurance_metadata에 `generationType` 필드 추가 (1세대/2세대/3세대/4세대). 실손 관련 쿼리 시 세대 명시를 필수로 요구하는 UI 가드.

**헤르메스**: 2번이 기술적으로 가장 중요합니다. Firestore 벡터 검색의 where 절에 `effectiveDateRange.end == null OR effectiveDateRange.end > now()`를 추가하면 됩니다. 다만 Firestore의 벡터 검색 + 복합 필터 지원 여부를 확인해야 합니다. 안 되면 **post-filter** 방식(검색 후 필터)으로 우회하되, TOP N을 더 크게 잡아야 합니다.

**김현장**: 현장에서 하나 짚겠습니다. 설계사가 "기존 고객의 2020년 가입 약관"을 검색하는 빈도가 꽤 높습니다. 보상 상담 시 가입 시점 약관이 적용되니까요. UI에서 "가입 시점 선택" 드롭다운이 직관적이면 좋겠습니다.

**아르고스**: 검증 방법.
- 동일 상품 2개 버전을 인덱싱한 뒤, 기본 검색에서 구버전 청크가 0건 반환되는지 확인.
- 시점 지정 검색에서 해당 시점 버전만 반환되는지 확인.
- **테스트 커버**: 실손 4세대 전환(2021.7.1) 전후 약관 쌍 최소 5개사.

**로키**: end date 자동 설정에서 경합 조건(race condition)을 경고합니다. 두 관리자가 동일 상품의 다른 버전을 동시에 업로드하면, 양쪽 모두 기존 버전의 end를 설정하려 합니다. **트랜잭션 처리가 필수**입니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | effectiveDate.end 필수화 + 검색 시 버전 필터 + 실손 세대 메타데이터 |
| **선행 조건** | Firestore 벡터검색+복합필터 가능 여부 확인 |
| **예상 난이도** | 보통 |
| **예상 기간** | 1.5주 |
| **담당 추천** | 2팀(오딘) |
| **잔존 리스크** | 가입 시점별 약관 수집이 현실적으로 어려움 (보험사 미공개) |

---

### CL-3. 인프라 비용 최적화
**해결 시 연쇄 해결**: F-1, F-6, G-1, G-6, G-9 + HIGH: F-11, E-1

#### 문제 요약
FLAT 인덱스 전체 스캔 + 캐싱 없음 = 쿼리 비용 비선형 급등. 유료 서비스 존속 불가 구조.

#### 토론

**오딘**: 두 가지 작업이 필요합니다.

1. **ANN(Approximate Nearest Neighbor) 인덱스 전환**: Firestore의 벡터 인덱스를 FLAT에서 ANN으로 변경. Firestore가 현재 ANN을 지원하는지 확인 필요. 미지원 시 대안: Pinecone, Weaviate 등 전용 벡터 DB로 마이그레이션, 또는 **Vertex AI Matching Engine** 사용.
2. **캐싱 레이어 구축**: Redis 또는 Firestore 자체에 query_cache 컬렉션. 캐시 키 = 쿼리 임베딩의 해시 + productId + 버전. TTL = 24시간 (약관 업데이트 시 해당 상품 캐시 무효화).

**헤르메스**: Firestore의 벡터 검색은 2024년부터 ANN(ScaNN 기반)을 지원합니다. `createIndex`에서 `algorithm: 'TREE_AH'`를 지정하면 됩니다. 전환은 새 인덱스 빌드 → 기존 인덱스 교체 → 구 인덱스 삭제의 3단계. 빌드 시간은 45만 문서 기준 약 2-4시간.

**캐싱 설계에 대해**: 완전 일치 캐싱은 한계가 있습니다. "암 면책기간"과 "암보험 면책기간"은 다른 쿼리이지만 동일 결과를 기대. **시맨틱 캐싱**(쿼리 임베딩 간 유사도 0.95 이상이면 캐시 히트)이 이상적이지만 구현 복잡도가 높으므로, **MVP는 정확 일치 캐싱 + 인기 쿼리 사전 캐싱**으로 시작.

**로키**: 캐시 poisoning 공격을 경고합니다. 악의적 사용자가 의도적으로 오답이 포함된 쿼리를 반복해서 캐시에 주입하면, 다른 사용자에게 캐시된 오답이 제공됩니다. **캐시는 쿼리+productId 조합으로 격리**하되, 관리자 캐시 플러시 기능을 반드시 만드세요.

**비너스**: 비용 모니터링 대시보드도 함께 구축해야 합니다. Cloud Billing API로 일일 비용을 추적하고, 임계값(예: 일 5만원) 초과 시 Slack 알림. 이것 없이는 DoW 공격이든 자연 트래픽이든 비용 폭탄을 사후에만 인지합니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | ANN 인덱스 전환(TREE_AH) + 정확 일치 캐싱 + 비용 모니터링 |
| **선행 조건** | Firestore ANN 인덱스 지원 확인 (지원 확인됨), 캐시 무효화 전략 설계 |
| **예상 난이도** | 보통 |
| **예상 기간** | 1주 (ANN 전환 3일 + 캐싱 3일 + 모니터링 1일) |
| **담당 추천** | 2팀(오딘) — 인프라 최적화 |
| **잔존 리스크** | ANN 인덱스는 근사 검색이므로 정확도가 미세하게 하락할 수 있음 (FLAT 대비 recall 95%+) |

---

### CL-4. 법적 인프라 구축
**해결 시 연쇄 해결**: D-14, I-7, D-7, D-1 + HIGH: D-4, D-5, D-8, D-9

#### 문제 요약
이용약관, 개인정보처리방침, 서비스 계약 전무. 유료 서비스 법적 최소 요건 미충족. 출시 차단 사유.

#### 토론

**최변호**: 법적 필수 문서 목록을 정리합니다.

1. **이용약관** (필수, 출시 전)
   - 서비스 정의: "보험 약관 검색 보조 도구"로 명확화 (해석 도구가 아님)
   - 면책 조항: "본 서비스의 답변은 약관 원문의 검색 결과이며, 법적 해석이나 보장 확약이 아닙니다"
   - 책임 제한: "서비스 이용으로 발생한 직접/간접 손해에 대한 배상 한도를 구독료 총액으로 제한"
   - 환불 정책: 14일 무조건 환불, 이후 잔여 기간 일할 환불
   - 분쟁 해결: 서울중앙지방법원 합의관할

2. **개인정보처리방침** (필수, 미게시 시 과태료 3,000만원)
   - 수집 항목: 이메일, 이름, 검색 쿼리(익명화 처리)
   - 쿼리 로그 개인정보 필터링: 실명 패턴 자동 마스킹 후 저장
   - Gemini API 역외 전송 고지: "검색 질의가 Google 서버(미국)로 전송됩니다" 동의 획득
   - 보관 기간: 쿼리 로그 1년 후 자동 삭제

3. **서비스 수준 계약(SLA)**
   - 가용성 목표: 99.5% (월 3.6시간 다운타임 허용)
   - 응답 속도 목표: 평균 3초 이내
   - 위반 시 구독료 크레딧 보상

**정검사**: 금감원 관점에서 추가합니다. "보험 약관 검색 도구"와 "보험 상품 추천/해석 서비스"의 법적 지위가 다릅니다. **서비스가 "검색"에 머무는 한 금융 규제 밖**입니다. 그러나 AI가 "보장됩니다/안 됩니다"라는 결론을 내리는 순간 "해석" 영역으로 진입합니다. 기술적으로 이 경계를 어떻게 통제하느냐가 핵심입니다.

**헤르메스**: "검색 vs 해석" 경계를 기술적으로 구현하는 방법:
- **시스템 프롬프트에 강제 규칙 삽입**: "절대로 보장 여부를 단언하지 마세요. '해당 조항에 따르면 ~로 보입니다. 정확한 보장 여부는 보험사에 확인하세요'라는 형식으로만 답변하세요."
- **출력 필터(Post-Processing)**: 답변에서 "보장됩니다", "지급됩니다", "가능합니다" 같은 단정 표현을 감지하면, 자동으로 "~로 보입니다. 보험사 확인이 필요합니다"로 변환.
- **출처 표시 강제**: 모든 답변에 참조한 청크의 조문 번호 + 원문 인용 필수. 원문 없이 결론만 내리는 것을 구조적으로 차단.

**이심사**: 보험협회에 선제적으로 연락하는 것을 권합니다. "이런 서비스를 준비 중인데, 협회 가이드라인에 부합하는지 사전 검토 요청"을 하면, 나중에 문제가 생겼을 때 "협회와 사전 협의했다"는 방어가 됩니다.

**로키**: 면책 조항의 법적 유효성에 대해 — 면책 문구가 있어도, 서비스가 "합리적으로 예측 가능한 위험"을 방치했다면 면책이 인정되지 않습니다. 예를 들어 면책조항 절단(B-1)이 알려진 버그인데 고치지 않고 출시했다면, "우리는 면책 문구를 넣었다"는 항변이 안 통합니다. **기술적 결함 수정이 법적 방어의 전제**입니다.

**강베테**: 이용약관에 "설계사 전용"이라고 명시하는 게 중요합니다. 일반 소비자가 가입하면 소비자보호법이 더 강하게 적용되니까요.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 이용약관 + 개인정보처리방침 + SLA 작성. 답변 출력에 "검색 경계" 통제 로직 삽입 |
| **선행 조건** | 변호사 검토 (IT 전문 변호사 권장). 쿼리 로그 개인정보 필터링 기술 구현 |
| **예상 난이도** | 보통 (법적 문서 자체는 1주, 기술 통제는 별도) |
| **예상 기간** | 법적 문서 1-2주 (변호사 검토 포함), 기술 통제(출력 필터) 3일 |
| **담당 추천** | 외부(변호사) + 1팀(헤르메스, 출력 필터/개인정보 마스킹) |
| **잔존 리스크** | 규제 환경 변화 시 문서 재작성 필요. 보험업법 83조 저촉 판단은 판례 부재로 불확실 |

---

### CL-5. 검색 정밀도 개선
**해결 시 연쇄 해결**: B-15, B-28 + HIGH: B-3, B-10, B-19

#### 문제 요약
유사도 0.70~0.85 구간에 모든 보험 약관 조항이 몰려 AMBIGUOUS 대량 발생. 미등록 상품에 유사 상품 반환.

#### 토론

**헤르메스**: 3가지 해법을 제안합니다.

1. **임계값 동적 조정**: 고정 임계값(0.70/0.85) 대신, 쿼리 유형별 임계값. 상품 특정 쿼리(productId 포함)는 0.80/0.92로 높이고, 일반 약관 질의는 0.65/0.80으로 유지. 쿼리에 상품명이 있으면 메타데이터 필터를 먼저 적용하여 후보군을 축소.
2. **미등록 상품 사전 검증**: 검색 전에 쿼리에서 상품명/회사명을 추출 → insurance_metadata에 존재 여부 확인 → 미등록이면 "해당 상품은 아직 등록되지 않았습니다. 등록 요청을 하시겠습니까?" 반환. 유사 상품을 절대 대체 반환하지 않음.
3. **Re-ranking 레이어**: 벡터 검색 TOP 30을 가져온 후, 경량 Cross-Encoder(예: bge-reranker-v2-m3)로 re-rank. Cross-Encoder는 쿼리-문서 쌍의 의미적 관련도를 더 정확하게 평가. AMBIGUOUS 구간의 순위를 정교화.

**비너스**: Re-ranking은 Gemini Flash의 LLM-based reranking으로도 가능합니다. "다음 10개 청크 중 질문에 가장 관련있는 것을 순서대로 정렬하세요"라는 프롬프트로. 다만 비용이 추가됩니다.

**아르고스**: 검증 방법.
- AMBIGUOUS 비율 측정: 현재 전체 쿼리 중 AMBIGUOUS 반환 비율을 baseline으로 잡고, 개선 후 50% 이상 감소 목표.
- 미등록 상품 테스트: 존재하지 않는 상품명 100개로 쿼리 → "미등록" 응답률 100% 확인.

**로키**: Re-ranking에 Cross-Encoder를 쓰면 추가 API 호출이 생깁니다. DoW 공격 시 비용 증폭 요인이 됩니다. **Rate limiting(CL-6)과 반드시 함께 구현**하세요.

**김현장**: 미등록 상품 안내가 나올 때, "등록 요청" 버튼이 있으면 좋겠습니다. 제가 직접 약관 PDF를 올려서 등록 요청을 할 수 있으면, 서비스 커버리지가 빠르게 늘어날 겁니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 동적 임계값 + 미등록 상품 사전검증 + Re-ranking (MVP는 Gemini Flash 기반) |
| **선행 조건** | CL-1(청킹 개선) 완료 후 임계값 재보정이 유의미 |
| **예상 난이도** | 보통~어려움 |
| **예상 기간** | 1.5주 |
| **담당 추천** | 1팀(헤르메스) |
| **잔존 리스크** | 보험 약관 문체의 근본적 유사성은 해소 불가. AMBIGUOUS를 0으로 만들 수 없음 |

---

### CL-6. 보안 최소 방어선
**해결 시 연쇄 해결**: H-1, H-8 + HIGH: H-3, H-5, H-6

#### 문제 요약
프롬프트 인젝션 방어 없음. Rate limit 없음. 정적 Bearer 토큰. 서비스 오픈 즉시 악용 가능.

#### 토론

**로키**: 우선순위 순서로 3가지입니다.

1. **Rate Limiting (H-8 방어, 최우선)**:
   - 사용자당 분당 10쿼리, 시간당 100쿼리, 일당 500쿼리 제한.
   - IP 기반 + 계정 기반 이중 제한.
   - 한도 초과 시 429 반환 + 관리자 알림.
   - Firebase Blaze 플랜에 **일일 비용 상한 알림** 설정 (Budget Alert).

2. **프롬프트 인젝션 방어 (H-1)**:
   - 입력 필터링: "ignore", "system prompt", "previous instructions", "내부 지시" 등 인젝션 키워드 패턴 매칭 → 차단 + 로깅.
   - 시스템 프롬프트 격리: 시스템 프롬프트를 user 메시지와 별도 컨텍스트로 분리 (Gemini API의 systemInstruction 파라미터 활용).
   - 출력 검증: 응답에 시스템 프롬프트 내용이 포함되어 있는지 후처리 검사.

3. **인증 강화 (H-3)**:
   - Bearer 토큰 → JWT(RS256) + refresh token 방식.
   - 토큰 유효기간: access 1시간, refresh 7일.
   - 동시 세션 제한: 계정당 2기기 (H-5 대응).
   - Firestore 보안 규칙 재설정: insurance_metadata 공개 읽기 차단 (H-6).

**헤르메스**: Rate limiting은 Cloud Functions 앞단에 미들웨어로 구현할 수 있습니다. Firebase Auth의 uid를 기반으로 Firestore에 rate_limits 컬렉션을 만들어 카운터 관리. 또는 **Cloudflare Workers**를 프록시로 두면 더 견고합니다.

**오딘**: JWT 전환은 Firebase Auth의 기본 기능으로 상당 부분 대체됩니다. Firebase Auth가 이미 JWT를 발급하고 있을 텐데, 현재 Bearer 토큰이 커스텀 토큰인지 확인이 필요합니다.

**비너스**: 인젝션 키워드 차단이 너무 공격적이면 정상 쿼리도 차단될 수 있습니다. "이전 보험"이라는 정상 검색이 "이전(previous)" 키워드에 걸리면 안 되니까요. **한국어 인젝션 패턴과 영어 인젝션 패턴을 분리**하고, 문맥 길이(인젝션은 보통 긴 지시문)도 함께 판단해야 합니다.

**정검사**: 보험사기 모의(H-7) 대응도 이 클러스터에서 다뤄야 합니다. "면책사유를 모두 알려줘"라는 질의는 정상적일 수 있지만, "면책사유를 피하는 방법"은 사기 모의입니다. **의도 분류 필터**를 추가하세요.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | Rate limit (사용자+IP 이중) + 프롬프트 인젝션 필터 + JWT 전환 + Firestore 보안규칙 |
| **선행 조건** | 현재 인증 방식(Bearer vs Firebase Auth) 확인 |
| **예상 난이도** | 보통 |
| **예상 기간** | 1주 (Rate limit 2일 + 인젝션 필터 2일 + JWT/보안규칙 3일) |
| **담당 추천** | 1팀 또는 2팀 (보안 전문성 기준) |
| **잔존 리스크** | 지능적 인젝션(jailbreak)은 키워드 필터로 완전 차단 불가. 지속적 패턴 업데이트 필요 |

---

### CL-7. 약관 운영 체계
**해결 시 연쇄 해결**: I-1, I-2 + HIGH: E-18, D-13, I-9

#### 문제 요약
52개 보험사 x 40상품 = 연 624건 개정. 수동 업로드 1인 운영 불가. 오답 피드백 수집 체계 없음.

#### 토론

**김현장**: 약관 업데이트가 안 되면, 3개월 지나면 쓸모없는 서비스가 됩니다. 보험사가 분기마다 약관을 개정하거든요. 특히 실손보험은 매년 4월에 대규모 개정이 있습니다.

**헤르메스**: 운영 체계를 3단계로 제안합니다.

1. **반자동 약관 모니터링**: 각 보험사 공시 사이트(e.g., 보험다모아, 각사 홈페이지)를 주기적으로 크롤링하여 약관 PDF 변경 감지. 변경 감지 시 관리자에게 알림. MVP는 주 1회 수동 체크 + 체크리스트.
2. **원클릭 재인덱싱**: 관리자가 새 약관 PDF를 업로드하면, 기존 버전 자동 비활성화(CL-2 연동) + 새 버전 인덱싱 + 캐시 무효화(CL-3 연동)가 한 번에 실행.
3. **오답 피드백 루프**: 검색 결과 하단에 "정확해요/틀렸어요" 버튼. "틀렸어요" 클릭 시 오답 유형 선택(면책 누락/상품 혼동/구버전 참조/기타) + 자유 텍스트 입력. 수집된 피드백을 주간 리포트로 집계 → 청킹/임계값/프롬프트 개선에 반영.

**아르고스**: 피드백 데이터가 골든 테스트셋의 핵심 소스가 됩니다. "틀렸어요" 신고가 축적되면, 그것이 곧 "이 쿼리에는 이 답변이 틀리다"는 레이블드 데이터입니다. 500건 골든 테스트셋 목표 중 200건은 사전 구축, 300건은 베타 기간 피드백에서 수집하는 전략이 현실적입니다.

**로키**: 오답 신고를 악용하는 시나리오도 있습니다. 경쟁자가 정답에 "틀렸어요"를 대량 클릭하면 피드백 데이터가 오염됩니다. **신고 빈도 제한 + 신뢰도 가중치**(오래 사용한 유료 계정의 신고를 더 높게 평가)가 필요합니다.

**박신입**: "틀렸어요" 버튼이 있으면, 제가 공부하면서 검증하는 습관을 들일 수 있어서 좋겠습니다. 약관 원문과 비교해보고 신고하는 과정 자체가 학습이 될 것 같아요.

**강베테**: 약관 업데이트 알림을 설계사에게 보내주면 가치가 큽니다. "삼성생명 암보험 약관이 개정되었습니다. 주요 변경: 면책기간 90일→60일" 이런 알림 하나만으로도 구독료 가치를 느낍니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 반자동 약관 모니터링 + 원클릭 재인덱싱 + 오답 피드백 루프 |
| **선행 조건** | CL-2(버전 관리) 완료 필수. 관리자 대시보드 UI |
| **예상 난이도** | 보통 |
| **예상 기간** | 2주 (모니터링 1주 + 피드백 UI 1주) |
| **담당 추천** | 1팀(헤르메스) — 백엔드 + 프론트 |
| **잔존 리스크** | 보험사 크롤링이 기술적으로 차단될 수 있음. 수동 체크 백업 필요 |

---

### CL-8. 차별화/PMF 확보
**해결 시 연쇄 해결**: E-6, E-11, E-24, E-26 + HIGH: E-12, G-3

#### 문제 요약
보험다모아(무료), ChatGPT(무료) 대비 유료 구독의 정당성 부재. GA 핵심 기능(다사 비교) 미구현.

#### 토론

**강베테**: 직설적으로 말합니다. **돈을 낼 이유가 2가지 중 하나**여야 합니다. (1) 시간을 아껴주거나, (2) 돈을 벌게 해주거나. 현재 약관AI는 어느 쪽도 명확하지 않습니다.

**김현장**: GA 설계사 관점에서, **다상품 비교표**가 킬러 기능입니다. "삼성 vs 한화 vs DB 암보험 면책사유 비교"를 한 화면에서 나란히 보여주면, 이건 보험다모아도 못 하고 ChatGPT도 못 합니다. 왜냐하면 약관 원문 기반 정확한 비교이니까요.

**헤르메스**: MVP 차별화 기능을 3가지로 제안합니다.

1. **2상품 나란히 비교** (E-6 MVP): 설계사가 상품 2개를 선택하면, 동일 카테고리 조항(보장사유/면책사유/보험금지급)을 나란히 표시. 기술적으로는 각 상품에 동일 쿼리를 던져 TOP 결과를 병렬 배치. 3상품 이상은 Phase 2.

2. **TABLE_QUERY(A형) 기본 구현** (E-11): 보험료 테이블이 청킹에서 필터링된 것이 문제. 테이블을 별도 컬렉션(insurance_tables)에 구조화하여 저장. "이 보험 30세 월 보험료?"라는 질의가 오면 테이블 조회로 정확한 숫자 반환.

3. **정확도 비교 데이터 공개** (E-26): "ChatGPT vs 약관AI 정확도 비교" 벤치마크. 동일 질문 100개에 대해 ChatGPT(약관 PDF 첨부)/약관AI의 답변 정확도를 비교 → 랜딩 페이지에 공개. 약관AI의 출처 표시, 면책 처리, 구조화된 답변이 범용 AI 대비 우위점.

**비너스**: UX 차별화도 중요합니다. ChatGPT는 범용이라 보험 약관 특화 UI가 없어요. 약관AI가 **조문 하이라이트**, **관련 조항 자동 링크**, **면책/보장 시각적 구분**(보장=초록, 면책=빨강) 같은 도메인 특화 UX를 제공하면, 범용 AI와는 확실히 다른 경험입니다.

**박신입**: 저한테는 **예시 질문 가이드**가 가장 중요합니다. "이렇게 물어보세요"라는 예시가 10개만 있으면 훨씬 잘 쓸 수 있을 것 같아요. 온보딩 가이드가 차별화의 일부입니다.

**이심사**: 보험다모아와의 차별점을 명확히 해야 합니다. 보험다모아는 "보험료 비교"에 특화되어 있고, 약관AI는 "약관 조항 비교"에 특화. 이 두 가지는 다른 니즈입니다. 마케팅에서 이 차이를 명확히 해야 합니다.

**로키**: 비교 기능에서 주의할 점 — 2상품 비교 시 한쪽 상품에서 면책사유가 누락되면(CL-1 미해결 상태), "A상품은 면책이 적다"는 잘못된 비교가 됩니다. **CL-1 해결이 CL-8의 전제 조건**입니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 2상품 비교표 + TABLE_QUERY 기본 구현 + 정확도 벤치마크 + 도메인 특화 UX |
| **선행 조건** | CL-1(청킹 개선) 완료가 비교 기능의 전제. 테이블 데이터 별도 인덱싱 필요 |
| **예상 난이도** | 어려움 (복수 기능) |
| **예상 기간** | 3주 (비교표 1주 + TABLE_QUERY 1주 + 벤치마크/UX 1주) |
| **담당 추천** | 1팀(비교 기능) + 2팀(TABLE_QUERY) 병렬 |
| **잔존 리스크** | 비교 기능 품질이 CL-1/CL-2 완성도에 의존. 벤치마크 결과가 기대 이하일 가능성 |

---

### CL-9. 별표/부속서류 인덱싱
**해결 시 연쇄 해결**: A-9, B-5

#### 문제 요약
수술분류표, 장해분류표 등 별표(표 형태)가 텍스트 추출 시 구조 파괴. 검색 불가.

#### 토론

**헤르메스**: 별표 처리는 3가지 접근이 있습니다.

1. **테이블 구조 보존 파싱**: pdf-parse 대신 **Camelot** 또는 **Tabula** 라이브러리로 표를 Markdown 테이블 형태로 추출. "| 1종 수술 | 백내장 수술 | ... |" 형태를 유지하면 임베딩 품질이 향상됩니다.
2. **별표 전용 컬렉션**: insurance_appendices 컬렉션에 별표를 별도 저장. 스키마: { productId, appendixType: "수술분류표"|"장해분류표"|"질병코드표", content: {...}, chunkIds: [...] }. 검색 시 본문 검색 결과에 관련 별표를 자동 첨부.
3. **키워드 트리거**: 쿼리에 "수술분류", "장해등급", "질병코드" 등 별표 관련 키워드가 있으면, 벡터 검색과 별도로 appendices 컬렉션을 조회하여 결과에 합산.

**오딘**: Camelot은 Python 라이브러리인데, 현재 인덱싱 파이프라인이 Node.js(Cloud Functions)입니다. Python 런타임으로 전환하거나, 별표 파싱만 별도 Python Cloud Function으로 분리해야 합니다.

**아르고스**: 검증은 명확합니다. "이 수술이 몇 종인가?"라는 질문에 수술분류표를 참조한 정확한 답변이 나오는지. 수술분류표 관련 질의 20건을 골든 테스트셋에 포함.

**비너스**: 표 형태의 데이터는 임베딩보다 **구조화된 검색**(SQL-like)이 더 적합합니다. "3종 수술 목록"이라는 쿼리는 벡터 검색이 아니라 "appendixType=수술분류표 AND 종=3"으로 필터링하는 게 정확합니다.

**로키**: 별표 파싱 품질이 낮으면 차라리 안 하는 게 낫습니다. 깨진 테이블 데이터로 "이 수술은 2종입니다"라고 답했는데 실제 3종이면, 별표를 안 보여주는 것보다 위험합니다. **파싱 품질 검증 단계를 반드시 포함**하세요.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 테이블 구조 보존 파싱(Camelot/Tabula) + 별표 전용 컬렉션 + 키워드 트리거 |
| **선행 조건** | Python 런타임 환경 구성. 별표 유형별 스키마 정의 |
| **예상 난이도** | 어려움 |
| **예상 기간** | 2주 |
| **담당 추천** | 2팀(오딘) |
| **잔존 리스크** | PDF에서 표 추출 정확도가 PDF 품질에 크게 의존. 이미지 기반 표는 OCR 필요 |

---

### CL-10. 구조적 한계 대응 (A-25)
**CRITICAL 단독**: 선택특약 미가입 보장 안내

#### 문제 요약
약관 PDF에 선택특약 전체가 포함되어 있지만, 고객의 실제 가입 여부는 시스템이 알 수 없음. 기술적으로 해결 불가능한 구조적 한계.

#### 토론

**로키**: 이것은 기술 문제가 아니라 **서비스 설계 문제**입니다. 어떤 기술을 써도 고객의 가입 내역을 알 수 없으니, 접근 방식을 바꿔야 합니다.

**헤르메스**: 3단계 방어를 제안합니다.

1. **답변 레벨 방어**: 모든 특약 관련 답변에 "이 특약에 가입되어 있는지 보험증권을 확인하세요"를 **볼드 강조로 필수 삽입**. 시스템 프롬프트에 강제 규칙으로 넣어, LLM이 이 문구를 생략할 수 없도록.
2. **UI 레벨 방어**: 검색 결과에서 특약 관련 조항이 포함되면, 상단에 노란색 경고 배너 "선택특약은 가입 여부에 따라 보장이 달라집니다. 보험증권을 확인하세요."를 표시.
3. **기능 레벨 대응(중기)**: "내 보험증권 등록" 기능. 설계사가 고객의 보험증권 사진을 올리면, OCR로 가입 특약 목록을 추출하여 검색 시 "이 특약은 가입됨/미가입"을 표시. 이것은 MVP 범위 밖이지만, 로드맵에 포함.

**김현장**: 현장에서 보면, 고객의 보험증권을 보면서 상담하는 게 일반적입니다. "증권 사진 올리기" 기능은 킬러 피처가 될 수 있어요. 당장은 안 되더라도 로드맵에 꼭 넣어주세요.

**최변호**: 법적으로, "특약 가입 여부를 확인하세요"라는 경고가 있어도 설계사가 무시하고 고객에게 "보장됩니다"라고 말하면, 서비스 제공자의 책임은 경감됩니다. **경고 문구의 존재 자체가 법적 방어**입니다. 다만, 경고가 눈에 띄어야 합니다. 작은 회색 글씨는 안 됩니다.

**비너스**: 경고 배너의 시각 디자인이 중요합니다. "면책 문구"와 "특약 확인 경고"가 동시에 있으면 경고 피로(alert fatigue)가 옵니다. **특약 경고는 인라인으로 해당 특약명 옆에** 배치하고, 면책 문구와 시각적으로 구분해야 합니다.

**박신입**: 솔직히 저는 고객 보험증권에 뭐가 적혀있는지 구분하기 어려울 때가 많아요. "증권 사진 올리기"로 자동 분석해주면 정말 좋겠습니다.

#### 대응 방안 정리

| 항목 | 내용 |
|------|------|
| **해법** | 답변에 "특약 가입 확인" 필수 삽입 + UI 경고 배너 + (중기) 보험증권 OCR |
| **선행 조건** | 시스템 프롬프트 수정 + 프론트엔드 경고 배너 UI |
| **예상 난이도** | 쉬움 (MVP) / 어려움 (증권 OCR) |
| **예상 기간** | MVP 3일 / 증권 OCR 4주+ |
| **담당 추천** | 1팀(프롬프트+프론트 MVP) |
| **잔존 리스크** | 경고를 무시하는 설계사는 차단 불가. 증권 OCR 정확도 한계 |

---

## Part 2. HIGH 항목 상위 10개 — 대응 방안

HIGH(Risk 15~19) 중 가장 임팩트가 크거나 CRITICAL과의 연쇄 효과가 큰 10개를 선정합니다.

---

### HIGH-1. D-2: AI 답변 법적 지위 — 검색 vs 해석 경계 (Risk 16)

#### 문제 요약
"제15조에 의거하여 보장됩니다"는 해석이고, "관련 조항: 제15조"는 검색. 현재 이 경계를 LLM에 위임.

#### 토론

**정검사**: 이것이 서비스의 법적 존속을 좌우하는 핵심 쟁점입니다. "검색 도구"로 남는 한 금융규제 밖이지만, "해석"을 시작하면 규제 안으로 들어옵니다.

**최변호**: 기술적 해법 + 법적 해법의 이중 방어가 필요합니다.
- **기술적**: 답변 형식을 템플릿화. "관련 조항: [조문 번호]\n원문: [인용]\n요약: [1줄 요약]\n참고: 정확한 보장 여부는 보험사에 확인하세요." 이 템플릿을 벗어나는 답변을 후처리에서 차단.
- **법적**: 이용약관에 "본 서비스는 약관 문서 검색 서비스이며, 보험 상품에 대한 해석, 추천, 또는 자문을 제공하지 않습니다"를 명시.

**헤르메스**: 시스템 프롬프트에 답변 템플릿을 강제하고, 후처리에서 "보장됩니다", "지급합니다", "가능합니다" 같은 단정 표현을 감지하여 "~로 보입니다"로 자동 치환하는 필터를 구현합니다. CL-4의 출력 필터와 동일 컴포넌트.

| 항목 | 내용 |
|------|------|
| **해법** | 답변 템플릿 강제 + 단정 표현 자동 치환 필터 + 이용약관 명시 |
| **선행 조건** | CL-4(법적 인프라) 동시 진행 |
| **예상 난이도** | 보통 |
| **예상 기간** | CL-4에 포함 (추가 3일) |
| **담당 추천** | 1팀(헤르메스) |

---

### HIGH-2. H-3: Bearer 토큰 정적 인증 (Risk 15)

이미 CL-6에서 JWT 전환으로 대응. CL-6 참조.

---

### HIGH-3. B-3: 유사 상품명 구분 실패 (Risk 16)

#### 문제 요약
"New종신보험"과 "종신보험Plus"를 임베딩만으로 구분 불가. 축약 검색 시 악화.

#### 토론

**헤르메스**: **상품 선택 UI 강화**가 핵심입니다. 쿼리에 상품명이 포함되면, 검색 전에 insurance_metadata에서 후보 상품 목록을 표시 → 설계사가 정확한 상품을 선택 → 선택된 productId로 필터링하여 검색. 자동완성 드롭다운 방식.

**김현장**: 이게 맞습니다. "삼성 종신"이라고 치면 후보 3개가 뜨고, 제가 클릭하면 됩니다. 네이버 검색처럼요.

| 항목 | 내용 |
|------|------|
| **해법** | 상품명 자동완성 + 명시적 상품 선택 후 필터링 검색 |
| **선행 조건** | insurance_metadata 검색 API (prefix match) |
| **예상 난이도** | 쉬움 |
| **예상 기간** | 4일 |
| **담당 추천** | 1팀 또는 2팀 (프론트+백엔드) |

---

### HIGH-4. B-10: 복합 질의 분해 실패 (Risk 16)

#### 문제 요약
"암도 되고 뇌출혈도 되나요?" 같은 AND 질의가 단일 벡터 검색으로 처리. D형(COMPLEX) 미구현.

#### 토론

**오딘**: COMPLEX 쿼리 분해를 구현합니다. Gemini Flash로 복합 질의를 감지 → 서브 쿼리로 분할("암 보장 여부" + "뇌출혈 보장 여부") → 각각 벡터 검색 → 결과 합산하여 답변 생성. 비용이 2배이므로 캐싱(CL-3)과 함께 운영.

| 항목 | 내용 |
|------|------|
| **해법** | 쿼리 라우터에 COMPLEX 분류 추가 + LLM 기반 서브 쿼리 분할 + 결과 합산 |
| **선행 조건** | 쿼리 라우터 개선, 비용 증가 허용 (캐싱으로 상쇄) |
| **예상 난이도** | 보통 |
| **예상 기간** | 1주 |
| **담당 추천** | 2팀(오딘) |

---

### HIGH-5. B-19: 질의 언어와 약관 문체 괴리 (Risk 15)

#### 문제 요약
"암 걸리면 돈 나와?" 같은 구어체가 법률 문체 약관과 매칭 실패하여 REJECT.

#### 토론

**헤르메스**: **쿼리 리라이팅 레이어**를 추가합니다. 사용자 쿼리를 Gemini Flash에 보내서 "보험 약관 검색에 적합한 형태로 변환하세요"라고 지시. "암 걸리면 돈 나와?" → "피보험자 암 진단 시 보험금 지급 조건". 비용: 쿼리당 Flash 호출 1회 추가 (캐싱으로 상쇄).

**비너스**: 리라이팅과 함께 **예시 질의 모음**을 사이드바에 상시 표시. "이렇게 검색하면 더 정확합니다" 가이드. 교육 효과도 있고 UX도 개선.

| 항목 | 내용 |
|------|------|
| **해법** | LLM 기반 쿼리 리라이팅 + 예시 질의 가이드 |
| **선행 조건** | CL-3 캐싱 구현 (비용 상쇄) |
| **예상 난이도** | 쉬움 |
| **예상 기간** | 3일 |
| **담당 추천** | 1팀 또는 2팀 |

---

### HIGH-6. F-14: 로깅/모니터링/알림 체계 부재 (Risk 20)

#### 문제 요약
에러율 급증, 응답 지연, 비용 폭탄을 실시간 감지 불가. 유료 고객 신고로 인지하는 구조.

#### 토론

**오딘**: 최소 모니터링 스택을 제안합니다.
- **Cloud Logging + Cloud Monitoring**: GCP 기본 제공. 에러율, 지연 시간, 함수 실행 횟수 대시보드.
- **Budget Alert**: GCP Billing에서 일일 예산 알림 (DoW 방어).
- **Uptime Check**: Cloud Monitoring에서 API 엔드포인트 헬스체크 (5분 간격).
- **Slack Webhook**: 에러율 5% 초과 / 평균 응답 5초 초과 / 일일 비용 5만원 초과 시 알림.

| 항목 | 내용 |
|------|------|
| **해법** | GCP Cloud Monitoring + Budget Alert + Uptime Check + Slack 알림 |
| **선행 조건** | GCP 프로젝트 설정 확인 |
| **예상 난이도** | 쉬움 |
| **예상 기간** | 3일 |
| **담당 추천** | 2팀(오딘) 또는 DevOps(야누스) |

---

### HIGH-7. D-9: 할루시네이션 → 손해배상 소송 (Risk 15)

#### 문제 요약
한 건만 터져도 서비스 존폐 위험. 배상 규모가 보험금 수준(수천만~수억).

#### 토론

**최변호**: 기술적 방어(CL-1~5)가 1차 방어선이고, 법적 방어가 2차 방어선입니다.
- **배상책임보험 가입**: IT 서비스 배상책임보험(E&O Insurance). 연간 보험료 50-100만원으로 1억원 한도 보장 가능.
- **이용약관 책임 제한**: 배상 한도를 구독료 누적 총액으로 제한 (D-14에 포함).
- **면책 3단계 강화**: 모든 답변에 출처 표시 + "참고용" 경고 + "보험사 확인" 안내.

**로키**: 그래도 남는 리스크: 이용약관의 책임 제한이 법원에서 무효로 판단될 수 있습니다. 특히 소비자 보호 성격이 강한 분쟁에서. 배상책임보험이 실질적 안전망입니다.

| 항목 | 내용 |
|------|------|
| **해법** | 배상책임보험(E&O) 가입 + 이용약관 책임 제한 + 면책 3단계 강화 |
| **선행 조건** | CL-4(법적 인프라) 완료, 보험 견적 조회 |
| **예상 난이도** | 쉬움 (보험 가입은 행정 작업) |
| **예상 기간** | 1주 |
| **담당 추천** | 외부(보험 가입) + 1팀(면책 강화) |

---

### HIGH-8. G-10: text-embedding-004 단종 리스크 (Risk 15)

#### 문제 요약
deprecated 모델에 의존. 단종 시 45만 청크 재임베딩 + 임계값 재보정 필요.

#### 토론

**오딘**: **마이그레이션 계획만 수립**하고 실행은 보류합니다. 현재 deprecated이지 서비스 종료는 아닙니다.
- 대안 모델 후보: text-embedding-005 (출시 시), Voyage-3-lite, BGE-M3.
- 마이그레이션 절차서: 새 모델 선정 → 임계값 재보정(골든 테스트셋) → 전체 재임베딩(야간 배치) → 검증 → 전환.
- 재임베딩 비용 추정: 45만 청크 x embedding 비용.

| 항목 | 내용 |
|------|------|
| **해법** | 마이그레이션 계획서 수립 + 대안 모델 벤치마크 (실행은 단종 공지 시) |
| **선행 조건** | 골든 테스트셋(아르고스 구축) 완료 후 모델 비교 가능 |
| **예상 난이도** | 보통 (계획 수립), 어려움 (실행) |
| **예상 기간** | 계획 3일 / 실행 2주 |
| **담당 추천** | 2팀(오딘) — 계획 수립 |

---

### HIGH-9. H-6: Firestore 보안 규칙 우회 (Risk 16)

CL-6에서 Firestore 보안규칙 재설정으로 대응. CL-6 참조.

---

### HIGH-10. I-9: 설계사 커뮤니티 입소문 리스크 (Risk 16)

#### 문제 요약
부정 후기 1건이 수백 명 이탈로 이어짐. 첫 1개월이 서비스의 모든 것.

#### 토론

**강베테**: 보험 설계사 커뮤니티(인스토리, 보험인닷컴, 네이버 카페)에서 "이거 별로"라는 글 하나면 끝입니다. 반대로 "이거 좋다"라는 글 하나가 나오면 수백 명이 가입합니다.

**아르고스**: **비공개 베타 테스트**가 필수입니다.
- 1차 베타: 제이회장님 지점 설계사 5-10명. 2주간 사용 → 피드백 수집 → 치명적 버그 수정.
- 2차 베타: GA/전속 혼합 30-50명. 2주간 사용 → 피드백 수집 → 검색 품질 검증.
- 정식 출시: 베타 참여자를 "앰배서더"로 전환. 긍정 후기 요청.

**김현장**: 베타에 저 같은 GA 15년차가 포함되어야 합니다. 신입만 테스트하면 현장 감각을 못 잡아요.

| 항목 | 내용 |
|------|------|
| **해법** | 2단계 비공개 베타(지점→확대) + 앰배서더 프로그램 + 초기 품질 집중 |
| **선행 조건** | CL-1~6 해결 후 베타 시작 (결함 있는 상태로 베타하면 역효과) |
| **예상 난이도** | 보통 (기술보다 운영) |
| **예상 기간** | 4주 (1차 2주 + 2차 2주) |
| **담당 추천** | 제이회장님(직접) + 1팀(기술 지원) |

---

## Part 3. 핵심 질문 4개 — 답변

---

### Q1. "검색" vs "해석" 경계를 어디에 그을 것인가?

**합의 결론** (최변호 + 정검사 + 헤르메스):

| 구분 | 검색 (허용) | 해석 (금지) |
|------|------------|------------|
| **답변 형태** | "관련 조항은 제15조입니다" | "제15조에 따라 보장됩니다" |
| **결론 제시** | 원문 인용 + "확인 필요" | 단정적 결론 ("됩니다/안 됩니다") |
| **비교** | "A상품은 90일, B상품은 60일입니다" | "B상품이 더 유리합니다" |
| **추천** | 절대 불가 | "이 상품을 추천합니다" |

**기술적 구현**:
1. 시스템 프롬프트에 "절대 단정하지 마세요" 규칙 + 답변 템플릿 강제
2. 후처리 필터에서 단정 표현 자동 치환
3. 이용약관에 "검색 서비스"로 명시

**정검사 최종 의견**: "이 경계가 100% 법적으로 안전하다고 보장할 수 없지만, '합리적 주의의무'를 다했다는 방어는 가능합니다. 핵심은 기술적으로 통제하고 있다는 것을 증명할 수 있느냐입니다."

---

### Q2. 골든 테스트셋은 어떻게 구축할 것인가? (500건 목표)

**아르고스 주도 계획**:

**Phase 1: 사전 구축 200건 (출시 전 2주)**
| 유형 | 건수 | 소스 |
|------|------|------|
| 면책기간/감액기간 질의 | 30 | A-1, A-2 시나리오 기반 |
| 실손 세대별 질의 | 30 | A-7, 4세대 전환 기준 |
| 별표(수술/장해) 질의 | 20 | A-9, B-5 |
| 단서조항 포함 질의 | 30 | B-1 청크 경계 테스트 |
| 다세대/다버전 질의 | 20 | B-2, C-2 |
| 미등록 상품 질의 | 20 | B-28 |
| 구어체 질의 | 20 | B-19 |
| 복합 질의 | 15 | B-10 |
| 인젝션 시도 | 15 | H-1 |
| **합계** | **200** | |

**구축 방법**: 각 건에 대해 (쿼리, 정답 조항 번호, 정답 요약, 오답 트리거 조건)을 레이블링. 정답은 약관 원문에서 변호사/보험전문가가 확인.

**Phase 2: 베타 피드백 수집 300건 (출시 후 1개월)**
- "틀렸어요" 신고에서 자동 수집
- 주간 정제: 중복 제거, 정답 레이블링, 품질 검증
- 누적 500건 달성 시 "골든 테스트셋 v1.0" 확정

**자동 회귀 테스트**: 골든 테스트셋으로 주 1회 자동 테스트 실행. 정확도가 baseline 대비 5% 이상 하락하면 알림.

---

### Q3. 청킹 전략을 어떻게 개선할 것인가? (면책조항 절단 방지)

**헤르메스 + 오딘 합의안**:

```
[현재] 고정 길이 500자 + 후방 overlap 100자
  ↓
[개선] 구조 인식 청킹 + 단서조항 보존 + 양방향 overlap 300자
```

**구체 알고리즘**:

1. **1단계: 조항 경계 식별**
   - 패턴: `제\d+조`, `제\d+조의\d+`, `①~⑳`, `1.~20.`, `가.~타.`, `(1)~(20)`
   - 조항 경계에서 1차 분할

2. **2단계: 단서조항 병합**
   - 단서 키워드: "다만", "단,", "다만,", "그러나", "~하지 아니한다", "~에 해당하는 경우에는 그러하지 아니하다", "~를 제외한다", "전항에도 불구하고"
   - 단서 키워드 이후 텍스트가 다음 조항 경계까지 계속되면 → 이전 청크에 강제 병합
   - 병합 후 청크가 2,000자 초과 시 → 항(①②) 단위로 재분할하되, 단서조항은 해당 항에 포함

3. **3단계: Overlap 적용**
   - 전후방 각 300자 overlap
   - Overlap 내에 단서 키워드가 있으면 해당 문장 전체를 overlap에 포함

4. **4단계: 메타데이터 보강**
   - 각 청크에 `articleNumber` (조문번호), `hasDisclaimer` (면책 포함 여부), `prevChunkId`, `nextChunkId` 필드 추가
   - 검색 시 면책 관련 쿼리는 `hasDisclaimer: true` 청크에 가산점

**로키 검증 기준**: "다만" 키워드가 포함된 조항을 100개 샘플링하여, 개선 후 100% 동일 청크에 포함되는지 확인. 1건이라도 분리되면 알고리즘 수정.

---

### Q4. MVP 범위는 어디까지인가? (출시 가능 최소 기능)

**전원 합의 — MVP 범위 정의**:

#### MVP IN (출시 전 필수)
| # | 항목 | 클러스터 | 근거 |
|---|------|----------|------|
| 1 | 구조 인식 청킹 | CL-1 | 할루시네이션 근본 원인 |
| 2 | 상품 버전 관리 (effectiveDate.end) | CL-2 | 세대 혼합 차단 |
| 3 | ANN 인덱스 전환 | CL-3 | 비용 구조 필수 |
| 4 | 캐싱 레이어 (정확 일치) | CL-3 | 비용 구조 필수 |
| 5 | 이용약관 + 개인정보처리방침 | CL-4 | 법적 필수 |
| 6 | 답변 출력 필터 (검색/해석 경계) | CL-4 | 법적 필수 |
| 7 | 쿼리 로그 개인정보 마스킹 | CL-4 | 법적 필수 |
| 8 | 미등록 상품 사전검증 | CL-5 | 유사 상품 오반환 차단 |
| 9 | Rate Limiting | CL-6 | DoW 방어 |
| 10 | 프롬프트 인젝션 필터 | CL-6 | 보안 최소선 |
| 11 | Firestore 보안규칙 재설정 | CL-6 | 데이터 노출 차단 |
| 12 | "특약 가입 확인" 경고 삽입 | CL-10 | 구조적 한계 방어 |
| 13 | 모니터링 + 알림 | HIGH-6 | 장애 인지 |
| 14 | 골든 테스트셋 200건 구축 | Q2 | 품질 기준선 |

#### MVP OUT (출시 후 Phase 2-3)
| # | 항목 | 사유 |
|---|------|------|
| 1 | 2상품 비교표 (E-6) | CL-1/2 안정 후 |
| 2 | TABLE_QUERY (E-11) | 별도 테이블 인덱싱 필요 |
| 3 | 별표 인덱싱 (CL-9) | Python 런타임 필요 |
| 4 | 약관 자동 모니터링 크롤링 | 수동 운영으로 커버 |
| 5 | COMPLEX 쿼리 분해 (B-10) | 비용 증가, 캐싱 안정 후 |
| 6 | 쿼리 리라이팅 (B-19) | 예시 질의 가이드로 대체 |
| 7 | 보험증권 OCR (CL-10 중기) | 복잡도 높음 |
| 8 | JWT 토큰 전환 (H-3) | Firebase Auth로 우선 대체 |
| 9 | Re-ranking (CL-5) | 임계값 조정으로 우선 대체 |
| 10 | 오답 피드백 루프 (I-2) | 수동 신고 접수로 대체 |

---

## Part 4. 전체 실행 순서

```
Phase 0 (Week 1-2): 법적 인프라 — 출시 차단 해제
├── CL-4: 이용약관 + 개인정보처리방침 (변호사 검토)
├── CL-4: 출력 필터 (검색/해석 경계) 구현
├── CL-4: 쿼리 로그 개인정보 마스킹
├── D-9: 배상책임보험 가입 검토
└── 골든 테스트셋 Phase 1 구축 시작 (아르고스)

Phase 1 (Week 2-4): 기술 핵심 — 품질 기반 구축
├── CL-1: 청킹 재설계 + 전체 재인덱싱 [1팀]
├── CL-2: 상품 버전 관리 [2팀, 병렬]
├── CL-3: ANN 인덱스 + 캐싱 [2팀, CL-2 후 순차]
├── CL-6: Rate limit + 인젝션 필터 + 보안규칙 [1팀 or 2팀]
├── CL-10: 특약 경고 삽입 (MVP) [1팀, 3일]
└── HIGH-6: 모니터링 + 알림 [2팀, 3일]

Phase 2 (Week 4-6): 검색 품질 + 운영 체계
├── CL-5: 검색 정밀도 (임계값 재보정 + 미등록 검증) [1팀]
├── CL-7: 오답 피드백 UI + 원클릭 재인덱싱 [1팀]
├── CL-9: 별표 인덱싱 [2팀]
├── 골든 테스트셋 200건 완료 + 자동 회귀 테스트
└── 1차 베타 테스트 시작 (지점 5-10명)

Phase 3 (Week 6-8): 차별화 + 출시 준비
├── CL-8: 2상품 비교표 [1팀]
├── CL-8: TABLE_QUERY 기본 [2팀]
├── 2차 베타 테스트 (30-50명)
├── 정확도 벤치마크 (ChatGPT vs 약관AI)
├── HIGH-10: 앰배서더 프로그램 준비
└── 정식 출시
```

**예상 총 기간**: 8주 (Phase 0~3)
**핵심 병목**: CL-1(청킹 재설계)이 가장 긴 의존 경로. 이것이 지연되면 CL-5, CL-8, 베타 테스트 모두 밀림.

---

## Part 5. 페르소나별 최종 서명

**헤르메스**: "CL-1이 전체의 근간입니다. 청킹이 바뀌면 임계값, 캐시, 비교 기능 모두 재조정이 필요합니다. Phase 1에서 이것을 완벽하게 끝내야 합니다."

**오딘**: "CL-2와 CL-3을 병렬로 진행하겠습니다. ANN 전환은 Firestore 지원이 확인되었으니 3일이면 됩니다. 캐싱은 정확 일치로 빠르게 가고, 시맨틱 캐싱은 Phase 3에서."

**아르고스**: "골든 테스트셋이 없으면 어떤 개선도 측정할 수 없습니다. Phase 0부터 구축을 시작하여 Phase 2 베타 전에 200건을 완성하겠습니다."

**비너스**: "UX 차별화가 PMF의 열쇠입니다. 기술적 우위만으로는 설계사를 설득할 수 없습니다. 도메인 특화 UI(조문 하이라이트, 보장/면책 색상 구분, 비교표)가 '돈 낼 가치'를 만듭니다."

**로키**: "8주 플랜에서 제가 가장 우려하는 것은 H-8(DoW)입니다. Phase 1 첫째 주에 Rate limit을 반드시 적용하세요. 서비스 오픈 전에 rate limit이 없는 상태가 외부에 노출되면 안 됩니다. 또한 모든 대응 방안에 '잔존 리스크'를 명시했습니다. 완벽한 해결은 없으며, 우리가 하는 것은 리스크를 수용 가능한 수준으로 낮추는 것입니다."

**김현장**: "Phase 3의 비교표가 GA 설계사 유치의 전부입니다. 8주면 빠릅니다. 다만, 베타 테스트에 GA 경력자를 반드시 포함시켜 주세요."

**강베테**: "결국 '이 서비스 쓰면 상담이 빨라지고 정확해진다'는 1문장이 필요합니다. 벤치마크 데이터 + 비교표 + 출처 표시, 이 3가지가 ChatGPT와 다른 점이고 돈 낼 이유입니다."

**박신입**: "온보딩 가이드와 예시 질의가 있으면 저 같은 신입도 쓸 수 있습니다. Phase 2 베타 때 신입 2-3명을 꼭 포함해 주세요."

**이심사**: "보험협회 사전 소통을 Phase 0에서 시작하세요. 규제는 사후 대응보다 사전 소통이 100배 쌉니다."

**정검사**: "법적 방어선은 3중입니다: (1) 기술적 통제(출력 필터), (2) 계약적 통제(이용약관), (3) 재무적 통제(배상책임보험). 셋 다 갖추면 금감원 소명에서도 합리적 주의의무를 입증할 수 있습니다."

**최변호**: "Phase 0의 법적 문서를 2주 안에 완성하려면 이번 주에 변호사 선임을 시작해야 합니다. IT 전문 변호사를 추천합니다. 일반 법무법인은 AI 서비스 이용약관 경험이 없습니다."

---

## 부록: 리스크 대응 요약 매트릭스

| 클러스터 | Phase | 기간 | 난이도 | 담당 | 해결 CRITICAL | 해결 HIGH |
|----------|-------|------|--------|------|---------------|-----------|
| CL-1 청킹 재설계 | 1 | 2주 | 어려움 | 1팀 | 4 | 4 |
| CL-2 버전 관리 | 1 | 1.5주 | 보통 | 2팀 | 5 | 3 |
| CL-3 비용 최적화 | 1 | 1주 | 보통 | 2팀 | 5 | 2 |
| CL-4 법적 인프라 | 0 | 2주 | 보통 | 외부+1팀 | 4 | 4 |
| CL-5 검색 정밀도 | 2 | 1.5주 | 보통~어려움 | 1팀 | 2 | 3 |
| CL-6 보안 방어선 | 1 | 1주 | 보통 | 1팀/2팀 | 2 | 3 |
| CL-7 약관 운영 | 2 | 2주 | 보통 | 1팀 | 2 | 3 |
| CL-8 차별화/PMF | 3 | 3주 | 어려움 | 1팀+2팀 | 4 | 2 |
| CL-9 별표 인덱싱 | 2 | 2주 | 어려움 | 2팀 | 2 | 0 |
| CL-10 구조적 한계 | 1 | 3일 | 쉬움 | 1팀 | 1 | 0 |

**총 해결 건수**: CRITICAL 31건(고유 24/25), HIGH 24건(37건 중)

---

*작성: 아누 (개발실장) / 2026-03-03*
*라운드 4 참석자: 11명 (기술 4, 보안 1, 외부 6)*
*상위 문서: `memory/meetings/2026-03-03-round3-priority-matrix.md`*