# Agent 미팅: 약관AI 심층 검증 (유료 서비스 출시 전 리스크 발굴)

**날짜**: 2026-03-03
**소집 이유**: InsuWiki 약관AI를 보험설계사 대상 유료 서비스로 출시하기 전, 기술·법적·사업적·운영적 리스크를 100% 발굴하고 대응 방안 수립
**참여 페르소나**: 헤르메스, 오딘, 아르고스, 로키, 비너스, 김현장, 박신입, 강베테, 이심사, 정검사, 최변호 (11명)
**총 라운드**: 5
**진행자**: 아누 (개발실장)

---

## 라운드 1: 현황 브리핑 + 자유 질의 (탐색) — "지금 뭘 만들었나"

### 기술팀 반응

**헤르메스**: 자, 다들 아키텍처 문서 봤지? 내가 만든 파이프라인이니까 솔직하게 얘기할게. 3중 할루시네이션 방지 체계... 구조적으로는 나름 탄탄하게 잡았어. Layer 1 유사도 게이트, Layer 2 시스템 프롬프트, Layer 3 답변 검증 필터. 근데 솔직히, 이걸 보험 약관에 걸고 유료 서비스로 나간다? 밤에 잠이 안 와.

**오딘**: 잠이 안 온다니, 무슨 얘기야?

**헤르메스**: 유사도 임계값 0.85가 TRUST, 0.70~0.85가 AMBIGUOUS잖아. 근데 이 숫자의 근거가... 경험적 튜닝이야. 보험 약관 도메인에서 체계적으로 검증한 적이 없어. 100건, 1000건의 실제 보험 질의로 precision-recall 곡선을 그려본 적이 없단 말이지. "이 임계값이면 안전합니다"라고 제이회장님께 자신 있게 말할 수 있냐? 나는 못 해.

**오딘**: 그 부분 나도 동의해. 근데 나는 더 근본적인 걸 걱정하고 있어. Firestore 벡터 검색... 이거 native 벡터 검색이 FLAT 인덱스거든. 지금 약관 몇 개 올려놓고 테스트하는 건 괜찮아. 근데 보험사 30개, 상품 1,500개, 상품당 평균 청크 수백 개면? 수십만 청크에 대해 FLAT 벡터 검색? 선형 스캔이야, 이건. 100명이 동시에 쿼리 날리면 Firestore가 버텨?

**헤르메스**: FLAT 인덱스 성능 문제는 맞는데, 그 전에 더 무서운 게 있어. 청크 경계 문제. 500~800자로 자르잖아. overlap 100자 줬지만... 보험 약관이 뭔지 알아? "제15조 보험금의 지급 사유" 다음에 "다만, 다음 각 호에 해당하는 경우에는 보장하지 아니합니다"가 오는데, 이 "다만" 이하가 다음 청크로 넘어가면? AI가 "보장됩니다"라고 답변하고, 면책 사유를 통째로 씹어버리는 거지.

**아르고스**: 거기. 그 얘기 나올 줄 알았어. 내가 테스트 91건 돌렸잖아? 솔직히 말할게. 청크 경계에서 면책 조항이 잘리는 케이스, 테스트에 없어. 왜냐면 실제 약관 PDF로 인덱싱하고 그 결과물로 검증하는 end-to-end 테스트가 빠져 있거든. 단위 테스트는 많아. 함수 레벨에서는 꽤 촘촘해. 근데 "실제 약관을 넣고, 실제 질문을 하고, 답변이 맞는지 사람이 확인하는" 골든 테스트셋? 그거 제로야.

**비너스**: 잠깐, 내가 좀 다른 관점에서 볼게. 지금 Gemini 2.0 Flash 하나에 생성이랑 용어 추출이랑 쿼리 라우팅까지 다 몰아넣은 거잖아. Flash가 빠르고 싸긴 한데, 보험 약관 해석이라는 도메인 특화 태스크에 Flash가 최적인지 검증을 했어?

**헤르메스**: 안 했어. 비용 때문에 Flash로 간 거지.

**비너스**: 그렇지. 그리고 사용자 경험 측면에서 하나만 더. 설계사 80%가 모바일이야. 근데 현재 UI가 모바일 최적화가 되어 있는지... admin 페이지는 봤는데 설계사용 클라이언트 UX는 아직 설계도 안 된 거 아니야?

**오딘**: 맞아. admin 쪽만 있어. 설계사향 프론트엔드는 사실상 미착수야. 근데 비용 구조가 더 걱정이야. 지금 비용 시뮬레이션이 백지잖아. 설계사 100명이면 월 쿼리 3,000건... Gemini API 임베딩 비용, 생성 비용, Firestore 읽기 비용 합산해서 설계사 1인당 월 인프라 비용이 얼마인지 아무도 몰라. 구독료를 매길 수가 없어.

**아르고스**: 재인덱싱 문제도 있어. 지금 재인덱싱 로직이 기존 chunks 삭제 → 새 chunks 생성 순서거든. 그 사이에 검색 요청이 들어오면? 유료 고객이 검색했는데 "결과 없음"이 뜨는 거야.

**헤르메스**: 아르고스 말 맞아. blue-green 방식으로 가야 해. 새 chunks를 다른 컬렉션에 먼저 쓰고, 준비 완료되면 스위칭.

**비너스**: 비판만 하면 균형이 안 맞으니까. 3중 할루시네이션 방지 구조 자체는 아키텍처적으로 좋아. 대부분의 RAG 시스템이 Layer 2까지만 하거든. Layer 3 답변 검증 필터까지 넣은 건 의식적인 설계야. 면책 문구 자동 삽입도 좋아. 문제는 각 레이어의 정밀도지, 구조 자체가 나쁜 건 아니야.

**아르고스**: 유료 출시 전에 반드시 해결해야 할 것. 첫째, 골든 테스트셋 구축. 실제 약관 기반 질의-응답 쌍 최소 500개. 이거 없으면 정확도 주장 자체가 근거 없어.

**헤르메스**: 둘째, 유사도 임계값 캘리브레이션. 0.85가 맞는지 0.80이 맞는지, 보험 도메인에서 검증해야 해.

**오딘**: 셋째, 비용 시뮬레이션 완료. 넷째, Firestore 벡터 검색 스케일링 테스트.

**비너스**: 다섯째, 설계사향 클라이언트 UX 설계. 여섯째, Flash vs Pro 정확도 비교.

### 로키 (Devil's Advocate) 반응

**로키**: 좋아, 다들 모였으니까 내가 먼저 입 열겠다. 브리핑 잘 들었어. 깔끔하게 정리해온 건 인정해. 근데 그게 문제야. 너무 깔끔해. 깔끔하다는 건 뭔가 숨기고 있거나, 아니면 진짜 위험한 걸 아직 모른다는 뜻이야.

**로키**: 3중 할루시네이션 방지부터 가자. Layer 1이 유사도 임계값 게이트라고? 0.85 이상이면 TRUST? 누가 이 숫자를 정한 거야? 근거 데이터 없이 잡은 임계값은 방어선이 아니라 자기 위안이야.

**로키**: 0.70~0.85 구간. AMBIGUOUS라고 이름 붙이고 "후보 제시"를 한다고? 설계사가 고객 앞에서 "AI가 애매하답니다, 이 중에 고르세요"라고 하는 장면을 상상해봐. 그게 서비스야? 그건 책임 떠넘기기지.

**로키**: Layer 2, 시스템 프롬프트. "원문 근거만 답변, 추정 금지, 출처 필수." 이거 프롬프트 한 줄이잖아. LLM이 시스템 프롬프트를 위반하는 건 기능이 아니라 본성이야. 600페이지짜리 종신보험 약관에서 5개 청크 모아서 프롬프트에 넣으면, 시스템 프롬프트가 뒤로 밀려나면서 모델이 자기 맘대로 "추정" 시작하는 게 시간문제야.

**로키**: Layer 3, 답변 검증 필터. 정규식으로 "아마도", "것 같습니다" 잡는 거야? 할루시네이션의 진짜 무서운 점은 자신 있게 틀린다는 거야. "제15조에 의거하여 보장됩니다"라고 당당하게 말하는데 제15조 내용이 완전 다른 얘기면? Layer 3가 잡아? 잡을 수가 없잖아. 3중 방지가 아니라 2.5중 방지고, 그마저도 구멍 투성이야.

**로키**: 보안. 가장 취약한 3곳. 첫째, vector-search API. Bearer 토큰 하나로 인증하는데 Rate limiting 없어. 자동화 스크립트 돌리면 30분 안에 전체 약관 데이터 추출 가능. 둘째, admin 업로드. Magic Bytes 검증? PDF Magic Bytes 붙여놓고 내용에 프롬프트 인젝션 페이로드를 넣으면 RAG Poisoning. 셋째, Firestore insurance_metadata가 "공개 읽기". driveFileId면 Drive 공유 설정에 따라 원본 PDF 직접 접근 가능.

**로키**: 서비스 폐업 시나리오 세 가지. 하나, 할루시네이션 → 설계사 오안내 → 고객 피해 → 금감원 행정지도. 둘, 보험사 법무팀 소송 — 소송 건다는 것 자체가 리스크, 자금이 먼저 바닥나. 셋, 프롬프트 인젝션 → 스크린샷 → SNS → 신뢰 즉사.

**로키**: 비용? Firestore FLAT 인덱스. 30만 청크에서 벡터 검색 1회면 전체 스캔. 하루 1만 쿼리면 30억 읽기. 월 900억 읽기. 비용 폭탄. 캐싱 없이 유료 서비스 런칭하면 수익이 API 비용에 잡아먹히는 구조야.

**로키**: 미구현 항목. TABLE_QUERY 미구현, 3단계 요약 미구현, OCR 미구현, COMPLEX 쿼리 분해 미구현, 캐싱 미구현. 핵심 기능의 절반이 TODO. 이걸 팔겠다고?

**로키**: Gemini 2.0 Flash. 가장 빠르고 가장 싼 모델이야. 가장 정확한 모델이 아니라. 보험 약관처럼 한 글자가 수천만 원을 가르는 도메인에서 비용 절감 때문에 Flash를 쓴다고? 이건 정확도를 비용에 팔아넘긴 거야.

**로키**: 인정하기 싫지만, 파이프라인 구조 자체는 나쁘지 않아. 그래도 이건 걱정된다 — 방어 체계가 너무 얇아. 유사도 임계값은 근거 없고, 시스템 프롬프트는 LLM한테 "부탁"하는 수준이고, 답변 필터는 자신만만한 오답을 못 잡아.

### 외부 이해관계자 반응

**김현장**: 설계사 15년 해온 사람 입장에서 솔직하게 말할게요. 첫인상은 나쁘지 않아요. 지금 약관 찾을 때 진짜 고역이거든요. 보험사 앱 들어가서, 상품 찾고, PDF 열고, Ctrl+F 누르고... 고객 앞에서 이러고 있으면 "이 사람 전문가 맞아?" 소리 듣습니다. 검색 한 번에 원하는 조항 딱 나온다? 그건 매력적이에요.

**김현장**: 근데 제가 제일 걱정되는 건 면책사유 누락. 이거 진짜 현장에서 무서운 겁니다. 고객한테 "보장됩니다" 했는데 나중에 보험사에서 "면책이요" 하면? 나는 그 고객 영원히 잃어요.

**박신입**: 솔직히 저는 이런 서비스가 너무 필요해요. 200페이지짜리 종신보험 약관을 펼치면 어디서부터 봐야 하는지도 모르겠고. 근데 저같은 신입이 이거 너무 믿으면 안 되잖아요? AI가 척척 답해주면 아예 약관을 안 읽게 될 것 같아요.

**강베테**: 잠깐. 다들 너무 긍정적으로 가는 것 같아서 한마디 할게요. 나 15년 했어. MDRT 세 번 했고. 솔직히 말하면, 나는 이 서비스가 왜 필요한지 모르겠어요. 내가 약관 못 찾아서 설계를 못 한 적이 한 번도 없어. 자주 보는 약관은 어느 페이지에 뭐가 있는지 기억하고, 모르면 보험사 FC 지원팀에 전화하면 5분 안에 답 나와요.

**김현장**: 강 선배님 말씀도 맞는데, 그건 본인이 생보 전속이시니까 그런 거예요. 나는 GA에서 생보 손보 다 취급하는데, 손보만 해도 회사가 열몇 개야. 실손의료보험 2세대, 3세대, 4세대 다 다르잖아요. 비교할 때는 이런 도구가 시간 절약이 확실히 돼요.

**이심사**: 보험협회 입장에서 볼게요. 가장 우려되는 건, 이 서비스가 약관을 "해석"하는 거냐 "검색"하는 거냐예요. 원문 검색이면 문제없어요. 근데 AI가 원문을 바탕으로 "보장됩니다" "면책입니다"라고 판단을 내리는 순간, 이건 해석이 되는 거고, 보험사들이 가만 안 있을 가능성이 있어요.

**정검사**: 금감원 입장에서 말씀드리겠습니다. 첫인상은 "여기서 사고 나면 복잡하겠다"입니다. 보험업법 제95조, 설명의무가 우려됩니다. 설계사가 보험계약의 중요한 사항을 직접 설명해야 하는데, AI 답변을 읽어주는 것이 "직접 설명"에 해당하는가? 그리고 이 서비스가 "설계사 전용"이라고 하셨는데, 설계사가 AI 답변 화면을 캡처해서 고객한테 카톡으로 보내는 건 어떻게 막을 건가요?

**김현장**: ...못 막죠. 솔직히.

**정검사**: 결국 소비자한테도 도달하는 서비스가 되는 겁니다. "설계사 전용"이라는 것은 법적 방어선에 불과해요.

**최변호**: 변호사 입장에서 정리하겠습니다. 법적 지뢰밭이에요. 다만 지뢰를 피해갈 수 있는 길이 있느냐가 중요하겠죠. AI가 "보장됩니다" 같은 판단성 답변을 하는 경우가 있나요? 아니면 원문을 보여주고 "관련 조항은 이것입니다"까지만 하나요? 이 경계선이 법적 리스크의 80%를 결정합니다.

**김현장**: 원문만 보여주면 쓸모가 확 줄어드는데요? 지금이랑 뭐가 다른 거예요?

**강베테**: 그치. 원문 검색만 하면 검색엔진이지, 무슨 AI야.

**최변호**: 현실적인 타협점은 있어요. "구조화된 원문 제시"라는 중간 영역. "면책사유만 모아서 보여줘" → 원문 중 면책 조항을 추출해서 나열. 이건 해석이 아니라 필터링이에요. 법적으로.

**김현장**: 오, 그거면 쓸 만하겠는데요? "이 상품 면책사유 목록 보여줘" 하면 관련 조항이 쫙 나오는 거? 그거면 내가 직접 읽을 수 있어요.

**강베테**: 흠... 그 정도면 써볼 만은 하겠네. 근데 가격에 따라 다르지. 월 1만원이면 써볼 수 있어. 월 5만원이면 안 써.

**최변호**: 약관은 공시 의무가 있고, 보험업법 제124조에 의해 누구든 열람 가능합니다. 저작권도 공시 문서에는 사실상 적용이 안 돼요. 검색 기능만 놓고 보면 합법이에요.

### 라운드 1 요약

**핵심 발견 — 4대 관문:**
1. **실전 검증 부재**: 구조는 좋으나 실제 약관 기반 골든 테스트셋 0건. 정확도 주장 근거 없음.
2. **비용 모델 백지**: 설계사 1인당 인프라 비용 미산정, 구독료 책정 불가.
3. **설계사향 UX 미착수**: admin만 존재, 모바일 퍼스트 클라이언트 없음.
4. **법적 방어선 미확보**: 검색 vs 해석 경계 미정의, 면책 문구 유효성 미검증.

**핵심 딜레마:**
> "원문 검색만 하면 법적으로 안전하지만 상업적 가치가 낮고, 해석까지 하면 가치는 높지만 법적 리스크가 크다."

**중간 해법 후보**: 최변호 제안 "구조화된 원문 제시" (필터링 방식)

**로키 주요 공격:**
- 3중 방지 = 실질 2.5중, 자신만만한 오답 감지 불가
- 보안 취약점 3곳: Rate limiting 없음, RAG Poisoning, metadata 공개 읽기
- 서비스 폐업 시나리오 3개: 금감원 행정지도, 보험사 소송, 프롬프트 인젝션 SNS
- Firestore FLAT 인덱스 비용 폭탄 (월 900억 읽기 가능)

---

## 라운드 2: 150+ 시나리오 도출 (발산) — "뭐가 터질 수 있나"


(라운드 2 시나리오는 별도 파일로 분할 저장)
- scenarios-AB.md: A 할루시네이션 25개 + B 검색품질 25개
- scenarios-CDF.md: C 법적 10개 + D UX 10개 + F 데이터 10개
- scenarios-E.md: E 기술인프라 25개
- scenarios-GHI.md: G 비용 10개 + H 보안 10개 + I 운영 10개

## 라운드 3: 우선순위 매트릭스 → round3-priority-matrix.md
## 라운드 4: 대응 방안 수립 → round4-response-plans.md
## 라운드 5: 최종 합의 → round5-final-consensus.md
## Executive Summary → executive-summary.md