# 약관AI 심층 검증 — 라운드 2 시나리오 (C / D / F)

**날짜**: 2026-03-03
**카테고리**: C(약관 데이터 관리), D(법적/규제 리스크), F(기술/인프라/성능)
**기반 문서**: yakgwan-ai-architecture.md + 라운드 1 미팅 결과

---

## C. 약관 데이터 관리 (15개)

**C-1. 재인덱싱 중 서비스 공백** — 기존 chunks 삭제 → 새 chunks 생성 사이에 검색 요청이 들어오면 "결과 없음" 반환. 유료 고객이 빈 결과를 받는 서비스 장애.

**C-2. 약관 버전 충돌 — 동일 상품 복수 버전 공존** — 삼성생명_종신보험_2401.pdf와 삼성생명_종신보험_2407.pdf가 모두 인덱싱되면, 검색 시 구버전 청크와 신버전 청크가 뒤섞여 답변. 설계사가 폐지된 조항을 현행으로 오인.

**C-3. 파일명 파싱 실패로 메타데이터 오염** — {회사}_{상품}_{YYMM}.pdf 규칙을 벗어난 파일명(예: "삼성생명 종신보험 개정.pdf")이 업로드되면 companyId/productId/effectiveDate가 잘못 생성되어 검색 결과 정합성 파괴.

**C-4. 회사명 정규화 누락 — 동일 회사 복수 엔트리** — company_aliases에 등록 안 된 변형 회사명("삼성생명보험" vs "삼성생명" vs "Samsung Life")이 들어오면 같은 회사 상품이 분산 저장되어 크로스 검색 불가.

**C-5. 대용량 PDF 분할 처리 시 청크 ID 충돌** — 500페이지 이상 PDF를 200페이지 단위로 분할 처리할 때, 분할 경계에서 chunk_N 번호가 리셋되면 동일 productId 내 chunk ID가 중복되어 기존 데이터 덮어쓰기.

**C-6. 약관 삭제 시 잔류 데이터** — 상품 폐지로 metadata를 비활성화(isActive: false)해도 insurance_chunks와 insurance_terms에 해당 청크/용어가 잔류. 검색 시 폐지 상품 조항이 계속 노출.

**C-7. 보험료/환급금 테이블 필터링 오판** — 정규식 패턴으로 테이블을 필터링하지만, 약관 본문에 포함된 "보험료 예시" 설명 문단까지 필터링되어 유의미한 약관 내용 유실. 반대로 테이블을 놓쳐 숫자 나열이 청크에 포함되어 임베딩 품질 저하.

**C-8. effectiveDate 기반 버전 관리 부재** — effectiveDateRange에 end가 optional이라 만료일이 없는 약관이 영구히 "현행"으로 취급. 신규 약관 업로드 시 구버전의 end를 자동 설정하는 로직이 없으면 모든 버전이 동시에 활성 상태.

**C-9. 배치 커밋 중 부분 실패** — Firestore 배치 커밋(400문서 단위)에서 중간 배치가 실패하면, 일부 청크만 저장되고 나머지는 누락. jobs 상태가 complete로 표시되면 누락을 인지 못하는 사일런트 데이터 손실.

**C-10. 분산 락 만료 후 동시 업로드** — productId 단위 분산 락 TTL이 30분인데, 대용량 PDF 인덱싱이 30분 초과 시 락 해제 → 동일 상품 중복 업로드 가능 → 청크 중복 생성.

**C-11. 용어 자동 추출 품질 — verified: false의 축적** — Gemini가 추출한 용어(verified: false)가 관리자 승인 없이 쿼리 확장에 사용되면, 잘못된 별칭이 검색을 오염. 관리자 벌크 승인 UI 미구현으로 미승인 용어가 무한 축적.

**C-12. 카테고리 자동분류 오류** — 키워드 기반 분류("화재/손보→손해보험, 변액→변액보험")가 "화재 면책" 같은 생명보험 약관 문구에 반응하여 잘못된 카테고리로 분류. 설계사가 카테고리 필터로 검색 시 해당 상품 누락.

**C-13. Drive 원본 PDF와 Firestore 청크 간 정합성 깨짐** — Drive에서 PDF가 수동 삭제/이동되면 driveFileId가 무효화. 재인덱싱이나 원본 확인이 불가능해지지만, metadata/chunks에는 유효한 것처럼 남아 있음.

**C-14. 동일 상품 상이한 약관 버전 혼합 답변** — 설계사가 "A상품 수술비 보장 범위"를 물었을 때, 2024년 1월판과 2024년 7월판 청크가 유사도 순으로 혼합 반환되어 서로 다른 버전의 조항을 짜깁기한 답변 생성.

**C-15. 스캔 PDF 거부 기준의 경계값 문제** — 페이지당 평균 50자 미만을 스캔 PDF로 판단하지만, 표/그림이 많은 정상 약관도 텍스트 밀도가 낮아 거부될 수 있음. 반대로 OCR 처리된 저품질 스캔은 50자 이상이지만 텍스트가 깨져서 의미 없는 청크 생성.

---

## D. 법적/규제 리스크 (16개)

**D-1. 보험업법 제95조 설명의무 위반 유도** — 설계사가 AI 답변에 의존하여 약관의 중요 사항을 "직접 설명"하지 않을 경우, 설명의무 위반으로 불완전판매 성립. 서비스가 설명의무 해태를 구조적으로 유도한다는 금감원 판단 리스크.

**D-2. AI 답변의 법적 지위 — 검색 vs 해석 경계 불명확** — "제15조에 의거하여 보장됩니다"는 해석이고, "관련 조항: 제15조"는 검색. 현재 시스템 프롬프트가 이 경계를 LLM에 위임하고 있어, 답변이 해석 영역에 진입하는 것을 기술적으로 차단 불가.

**D-3. 면책 문구의 법적 유효성 미검증** — "실제 보험금 지급은 보험사 심사 기준에 따릅니다" 면책 문구가 소비자 보호 관점에서 법적 방어력이 있는지 변호사 검토 없음. 약관 제3자 불이익 변경 금지 원칙 등과 충돌 가능성.

**D-4. 불완전판매 책임 전가 논란** — AI가 면책사유를 누락한 답변을 제공 → 설계사가 이를 근거로 고객에게 설명 → 보험금 분쟁 발생 시, 책임 소재가 서비스 제공자/설계사/보험사 3자 간 불명확. 서비스 이용약관에 책임 범위 미정의.

**D-5. 금감원 행정지도 트리거** — 금감원이 AI 기반 보험 서비스에 대해 "혁신금융서비스" 지정 없이 운영하는 것을 문제삼을 수 있음. 규제 샌드박스 미신청 시 사업 중단 명령 가능성.

**D-6. 보험사 법무팀의 약관 데이터 사용 이의** — 약관은 공시 문서이지만, 보험사가 "약관 전문을 DB화하여 상업적 서비스에 이용"하는 것에 대해 데이터베이스 저작권(편집저작물)이나 부정경쟁방지법 위반을 주장할 가능성. 소송 자체의 비용이 스타트업에 치명적.

**D-7. 개인정보보호법 — 쿼리 로그에 개인정보 포함** — 설계사가 "김철수 고객의 삼성생명 종신보험 면책사유" 처럼 고객 실명을 포함한 질의를 하면 query_logs에 개인정보가 저장. 개인정보처리방침 미수립, 동의 절차 부재.

**D-8. 설계사 → 고객 답변 전달 시 소비자 보호 이슈** — "설계사 전용" 서비스이지만, 설계사가 AI 답변을 캡처/복사하여 고객 카톡으로 전송하는 것을 기술적으로 차단 불가. 사실상 소비자 대면 서비스가 되며, 소비자 보호 규정 적용 대상화.

**D-9. 할루시네이션 답변으로 인한 금전적 손해배상** — AI가 "보장됩니다"라고 답변 → 설계사가 고객에게 전달 → 실제로 면책 → 고객이 설계사와 서비스 제공자를 상대로 손해배상 소송. 배상 규모가 보험금 수준(수천만~수억)이 될 수 있음.

**D-10. 보험업법 제83조 모집 규제 저촉** — AI 서비스가 보험 모집 보조 도구를 넘어 "보험 모집" 자체에 해당한다고 해석될 경우, 보험모집인 등록 없는 서비스 운영은 무등록 모집에 해당. 벌금 또는 사업 정지.

**D-11. 전자금융거래법 또는 핀테크 규제 적용 가능성** — 보험 관련 정보 서비스가 "전자금융보조업"으로 분류될 경우, 금융위 등록 의무 발생. 미등록 운영 시 과태료 및 시정 명령.

**D-12. 보험협회 공식 견해 미확인** — 보험협회가 "AI 기반 약관 검색 서비스"에 대해 가이드라인을 발표하면, 이에 부합하지 않는 기능은 즉시 비활성화해야 할 수 있음. 협회 동향 모니터링 체계 부재.

**D-13. 약관 변경 시 실시간 반영 의무** — 보험사가 약관을 개정하면, 서비스에 구버전이 남아있는 동안 설계사가 구조항 기반 답변을 받음. 이로 인한 오안내 발생 시 "최신 약관 미반영"이 서비스 제공자 과실로 인정될 가능성.

**D-14. 이용약관 및 서비스 계약 법적 요건 미비** — 유료 서비스 출시 전 필수: 이용약관, 환불 정책, SLA(서비스 수준 계약), 책임 제한 조항, 분쟁 해결 절차. 현재 전무.

**D-15. 금감원 빅데이터·AI 가이드라인 준수 여부** — 금감원 "금융분야 AI 가이드라인"이 발표될 경우(또는 이미 존재 시) 설명 가능성(Explainability), 공정성, 투명성 요건 충족 여부 검토 필요. RAG 기반 답변의 "왜 이 답변인지" 설명 체계 부재.

**D-16. 크로스보더 데이터 이슈 — Gemini API 호출 시 데이터 역외 전송** — 설계사 질의 + 약관 청크가 Gemini API(미국 서버)로 전송됨. 약관 자체는 공시 문서이나, 질의에 포함된 고객 정보가 역외 전송될 경우 개인정보 국외 이전 동의 미취득 문제.

---

## F. 기술/인프라/성능 (15개)

**F-1. Firestore FLAT 벡터 인덱스 선형 스캔 병목** — FLAT 인덱스는 전체 문서를 스캔하는 brute-force 방식. 30만 청크 규모에서 쿼리 1회당 전체 스캔 발생, 동시 100명 이상 검색 시 Firestore 읽기 쿼터 초과 및 응답 지연 급증.

**F-2. Gemini API 단일 의존점 장애** — 생성(Flash), 임베딩(text-embedding-004), 용어 추출, 쿼리 라우팅 모두 Google Gemini에 의존. Gemini API 장애 시 전체 서비스 불능. 폴백 모델 없음.

**F-3. Cloud Function 540초 타임아웃 — 대용량 PDF 처리 실패** — 600페이지 이상 약관의 경우 PDF 파싱 + 임베딩 생성이 540초(9분) 내 완료되지 않을 가능성. 200페이지 분할로 완화했으나, 분할 자체 + 재조립 오버헤드 미검증.

**F-4. 임베딩 모델 변경 시 전체 재인덱싱 필요** — text-embedding-004에서 신규 모델로 변경 시, 기존 768차원 벡터와 호환 불가. 수십만 청크 전체 재임베딩에 수일 소요 + 비용 폭증. 마이그레이션 전략 부재.

**F-5. Firestore 동시 쓰기 제한 — 대량 업로드 병목** — 초기 약관 일괄 등록(30개 보험사 x 50개 상품) 시 Firestore 쓰기 제한(초당 10,000회)에 도달 가능. 배치 커밋 400문서 단위이지만, 동시 인덱싱 작업이 충돌 가능.

**F-6. 캐싱 미구현으로 인한 비용 폭발** — 동일 질의("실손의료보험 면책사유")가 반복 요청되어도 매번 임베딩 생성 + 벡터 검색 + LLM 생성 수행. 인기 질의 캐싱 없이 유료 서비스 운영 시 API 비용이 구독 수익 초과.

**F-7. Vercel 서버리스 Cold Start + API Route 타임아웃** — Vercel의 서버리스 함수 cold start(수초)가 벡터 검색 응답 시간에 가산. Vercel Hobby/Pro 플랜 API Route 타임아웃(10초/60초)이 복잡한 검색 + LLM 생성에 부족할 수 있음.

**F-8. 벡터 검색 정확도 — 코사인 유사도의 도메인 한계** — 보험 약관 특유의 법률 문체("~하지 아니합니다", "전항에도 불구하고")에서 코사인 유사도가 의미적 유사성을 정확히 반영하지 못할 가능성. 부정문/이중부정문에서 의미 반전을 임베딩이 포착 못함.

**F-9. 메모리 1GB 제한 — PDF 파싱 OOM** — Cloud Function 메모리 1GB에서 pdf-parse가 대용량 PDF(이미지 포함 100MB+)를 처리할 때 OOM(Out of Memory) 발생 가능. 50MB 업로드 제한이 있지만, 텍스트 추출 중 메모리 사용량은 파일 크기의 수배.

**F-10. 쿼리 라우터 오분류** — queryRouter가 TABLE_QUERY/VECTOR_SEARCH/DEEP_QUERY/COMPLEX를 잘못 분류할 경우: 보험료 질의가 VECTOR_SEARCH로 라우팅되어 의미 없는 답변, 단순 질의가 DEEP_QUERY로 라우팅되어 불필요한 Cloud Function 호출 + 비용.

**F-11. Firestore 읽기 비용 누적 — 예측 불가능한 과금** — 벡터 검색 TOP 10 + 메타데이터 조회 + 용어 확장 쿼리가 검색 1회당 수십 건의 Firestore 읽기 발생. 월간 비용이 사용량에 비례하여 비선형 증가 가능성이 있으나 비용 모니터링/알림 미구축.

**F-12. Google Drive API 쿼터 제한** — 대량 업로드 시 Drive API 호출 쿼터(일 1만~10만 건)에 도달 가능. 초기 약관 일괄 업로드 + 재인덱싱(Drive 다운로드) 동시 발생 시 429 에러로 파이프라인 중단.

**F-13. 무중단 배포 미보장 — Vercel + Cloud Functions 동시 배포** — Next.js(Vercel)와 Cloud Functions(Firebase)의 배포 주기가 독립적. API 인터페이스 변경 시 Vercel은 신규 코드, Functions는 구 코드인 상태가 발생하여 런타임 에러.

**F-14. 로깅/모니터링/알림 체계 부재** — query_logs에 쿼리를 저장하지만, 에러율 급증/응답 지연/할루시네이션 비율 등을 실시간 감지하는 모니터링 없음. 장애 발생 시 유료 고객 신고로 인지하게 되는 구조.

**F-15. 지수 백오프 재시도의 한계 — 임베딩 배치 전체 실패** — 임베딩 API 호출에 지수 백오프 재시도가 있지만, 최대 재시도 횟수 초과 시 해당 배치 전체 실패. 부분 실패 복구 로직 없이 전체 인덱싱 작업이 중단되면, 재시작 시 처음부터 다시 시작해야 하는 비효율.