# 보고서: task-141.1 — YouTube 3-Layer 아키텍처 방안 B vs 대안 C 분석

> **작성자**: 헤르메스 (개발1팀장)
> **작성일**: 2026-03-03
> **팀원**: 불칸(백엔드), 아테나(UX/UI), 아르고스(테스터)
> **작업 성격**: 분석/보고 (코딩 없음)

---

## 1. 분석 대상 정의

### 방안 B: 신규 컬렉션 완전 분리 (불칸 계획서 추천)
- 신규 컬렉션 2개: `youtube_transcripts` (L3 자막 청크), `youtube_summaries` (L1 채널 통합 + L2 영상 요약)
- 기존 `youtube_knowledge`, `insurance_chunks` (sourceType: 'youtube') 유지
- L2 = 기존 6섹션 프롬프트를 **개선** (자막 근거 인용 추가)
- L1 = **채널별** 통합 인사이트 (별도 배치 Cloud Function)
- 요약 결과를 youtube_knowledge + youtube_summaries **양쪽에 이중 저장**
- 구현 공수: 약 2~3주

### 대안 C: 하이브리드 (아테나 맥락노트 추천)
- 기존 6섹션 요약(youtube_knowledge) **완전 무변경**
- 별도 3-Layer를 병렬 생성: `youtube_summaries` (L1 영상 핵심 + L2 4항목 구조)
- L3 자막 청크를 `insurance_chunks`에 pageNumber를 시간대로 대체하여 저장
- L1 = **영상별** 핵심 요약 (200~300자)
- 6섹션(실무 활용)과 3-Layer(약관 비교)가 **공존**
- 구현 공수: 약 1~1.5주

---

## 2. 5가지 비교 기준 분석 결과

### 2-1. 확장성

- **방안 B 우위**: Level/Function/컬렉션 단위로 독립 확장 가능. 채널 10개 이상 확장 시 각 레이어를 독립적으로 스케일링하고 교체할 수 있음.
- **대안 C 한계**: `insurance_chunks`에 유튜브 L3를 혼합 저장하므로, 약관 도메인의 스키마 변경 시 유튜브 L3 데이터도 영향 받음. 도메인 분리 원칙 위배.

### 2-2. 쿼리 성능

- **대안 C 표면상 우위**: 기존 RAG 파이프라인의 단일 벡터 검색(`insurance_chunks.findNearest()`)이 유튜브 L3 청크도 자동 포함하여 추가 쿼리 불필요.
- **그러나 치명적 결함 발견** (아르고스 분석): 현재 `vector-search/route.ts`는 `sourceType` 필터 **없이** `insurance_chunks` 전체를 검색함. L3 자막 청크가 대량 추가되면(30분 영상당 60~90개 청크, 누적 시 수천 개) 약관 청크 비중이 20% 이하로 떨어지며, **약관 질의 응답에 유튜브 자막이 상위 검색 결과로 노출되는 품질 오염이 발생함**.
- **방안 B**: `youtube_transcripts`가 별도 컬렉션이므로 기존 RAG 검색 경로를 전혀 오염시키지 않음.

### 2-3. 마이그레이션 비용

- **대안 C 우위**: 기존 코드/데이터 무변경 원칙으로 마이그레이션 불필요. 구현 공수 1~1.5주.
- **방안 B**: `crawlYoutubeChannels.ts` 수정 + 신규 Cloud Function 개발 필요. 구현 공수 2~3주. 기존 `youtube_knowledge` 데이터와 신규 `youtube_summaries` 간 스키마 버전 불일치 관리 필요.

### 2-4. 데이터 일관성

- **대안 C 우위**: 6섹션과 3-Layer가 서로 다른 목적의 독립 데이터로 SSOT 충돌 없음.
- **방안 B 약점**: 이중 저장(youtube_knowledge + youtube_summaries)으로 SSOT 부재. L2 프롬프트 개선 시 양쪽 데이터 동기화 실패 위험. Firestore 배치 쓰기 시 부분 커밋(partial commit) 가능성.

### 2-5. 운영 복잡도

- **대안 C 표면상 우위**: Cloud Function 1개, 컬렉션 4개, 기존 인덱스 재사용.
- **방안 B**: Cloud Function 2개, 컬렉션 5개, 신규 인덱스 다수.
- **그러나**: 대안 C의 `insurance_chunks` 혼합 저장은 운영 중 벡터 검색 노이즈가 점진적으로 축적되며, 이는 기능 테스트로 탐지되지 않는 "무증상 품질 저하"를 유발함 (아르고스 분석).

---

## 3. 기준별 우위 종합표

| 기준 | 방안 B | 대안 C | 최종 판정 |
|------|--------|--------|-----------|
| 확장성 | ★★★ 독립 확장 가능 | ★★ 도메인 혼재 | 방안 B 우위 |
| 쿼리 성능 | ★★ 다중 컬렉션 조회 필요 | ★ 표면상 유리하나 RAG 오염 치명적 | 방안 B 우위 |
| 마이그레이션 비용 | ★★ 2~3주 | ★★★ 1~1.5주 | 대안 C 우위 |
| 데이터 일관성 | ★★ 이중 저장 문제 | ★★★ SSOT 충돌 없음 | 대안 C 우위 |
| 운영 복잡도 | ★★ Function/인덱스 다수 | ★★ 무증상 품질 저하 위험 | 비등 |

---

## 4. 팀원별 분석 핵심 요약

### 불칸 (백엔드 기술 분석)
- 5개 기준 중 4개에서 대안 C 우위 판정
- 단기(~6개월) 대안 C 채택 → 중장기(채널 10개+) 방안 B 이행 제안
- **핵심 지적**: 방안 B의 이중 저장은 설계 결함이며, `youtube_knowledge`와 `youtube_summaries`를 각각 독립 소비자에게 할당하면 해결 가능

### 아테나 (UX/UI 분석)
- 7개 UX 기준 중 5개에서 대안 C 우위 판정 (방안 B는 "상담 준비 시나리오"와 "신뢰도 표현"에서만 우위)
- 대안 C의 Level 1(영상별 200~300자)이 설계사의 탐색-선택 멘탈 모델과 일치
- **핵심 지적**: 방안 B의 채널 단위 Level 1은 영상 리스트 탐색 흐름과 불일치. 대안 C의 탭 분리(실무 활용/약관 비교)가 점진적 노출 UX 패턴에 적합

### 아르고스 (QA/테스트 분석)
- 8개 리스크 기준 중 4개에서 방안 B 명확 우위 판정 (나머지 2개 비등, 2개 대안 C 우위)
- **핵심 발견 (게임 체인저)**: `vector-search/route.ts`가 `sourceType` 필터 없이 `insurance_chunks` 전체를 검색함. 대안 C의 L3 자막 청크 대량 추가는 **기존 약관 RAG 검색 품질을 직접적으로 훼손**하는 구조적 결함
- 이 결함은 점진적이고 무증상으로 발현되어, 프로덕션에서 사용자 불만으로만 인지 가능
- 임베딩 모델 혼재(text-embedding-004 vs gemini-embedding-001)도 확인됨

---

## 5. 최종 추천안

### 추천: 방안 B 개선안 (방안 B 기반 + 대안 C의 장점 흡수)

단순히 방안 B 또는 대안 C 중 하나를 선택하는 것이 아니라, 양쪽의 강점을 결합한 **방안 B 개선안**을 추천한다.

#### 채택하는 것 (방안 B에서)
1. **신규 컬렉션 완전 분리**: `youtube_transcripts` (L3), `youtube_summaries` (L1/L2) → `insurance_chunks` 오염 방지
2. **도메인 분리 원칙**: 유튜브 전용 컬렉션으로 약관 시스템과 명확 분리
3. **Level 1 = 채널별 통합 인사이트**: 별도 배치 Cloud Function

#### 채택하는 것 (대안 C에서)
1. **기존 6섹션 유지**: `youtube_knowledge`의 기존 6섹션 요약을 그대로 유지 → "영상 상세" 뷰에서 사용
2. **이중 저장 제거**: `youtube_summaries`에만 3-Layer 데이터 저장. `youtube_knowledge`는 기존 방식 그대로 유지하되 신규 요약을 중복 저장하지 않음
3. **탭 분리 UX**: 6섹션(실무 활용) 탭 + 3-Layer(약관 비교) 탭으로 공존

#### 구체적 구조
```
[기존 유지 — 변경 없음]
crawlYoutubeChannels.ts 기존 흐름:
  자막추출 → 6섹션 요약 → Drive 업로드 → insurance_chunks → youtube_knowledge

[신규 추가 — 확장]
crawlYoutubeChannels.ts에 단계 추가:
  자막추출 후 → youtube_transcripts 청크 저장 (L3)
  6섹션 요약 완료 후 → youtube_summaries 저장 (L2, 개선된 프롬프트)
  ※ youtube_knowledge에 이중 저장하지 않음

[별도 배치 — 신규]
generateYoutubeChannelInsight:
  youtube_summaries L2 집약 → youtube_summaries L1 저장
```

#### 추천 근거

1. **RAG 품질 보호 (최우선)**: `insurance_chunks`에 유튜브 L3를 추가하지 않으므로, 기존 약관 기반 벡터 검색의 품질이 보장됨. InsuWiki의 핵심 가치("약관 원문 기반 신뢰할 수 있는 답변")를 구조적으로 보호.

2. **이중 저장 제거**: 방안 B의 핵심 결함이었던 이중 저장을 제거. `youtube_knowledge`는 기존 6섹션 전용, `youtube_summaries`는 3-Layer 전용으로 SSOT 보장.

3. **UX 최적화**: 대안 C의 "탭 분리" 개념을 수용하여 기존 사용자 경험을 유지하면서 3-Layer 기능을 점진적으로 노출.

4. **확장성 확보**: 도메인별 컬렉션 분리로 향후 채널 증가, 새로운 Level 추가에 대응 가능.

#### 구현 공수 예상
- Phase 0 (PoC): 1~2일
- Phase 1 (L3 저장): 2~3일
- Phase 2 (L2 프롬프트 + youtube_summaries): 3~4일
- Phase 3 (L1 배치 + 통합 테스트): 4~5일
- **총 예상: 약 2~3주**

---

## 6. 검토한 대안과 기각 사유

| 대안 | 기각 사유 |
|------|-----------|
| 대안 C 원안 (insurance_chunks에 L3 저장) | `vector-search/route.ts`의 sourceType 필터 부재로 RAG 검색 품질 오염 불가피. 핵심 서비스 가치 훼손. |
| 방안 B 원안 (이중 저장) | youtube_knowledge + youtube_summaries 이중 저장은 SSOT 위반이며, 프롬프트 개선 시 버전 불일치 발생. 불필요한 복잡도 추가. |
| 대안 C + sourceType 필터 추가 | "기존 코드 무변경"이라는 대안 C의 핵심 전제가 깨짐. 기존 RAG 코드 수정이 필요하면 방안 B와 구현 비용 차이가 줄어듦. |
| 대안 A (6섹션 그대로 L2 매핑) | 약관 구조와 정렬 부재로 비교 UI 불가. 검색 정밀도 개선 효과 제한적. |

---

## 7. 팀장 검토 결과

- **불칸 (백엔드)**: 1차 검토 통과. 5가지 기준별 기술 분석이 상세하고 근거가 명확. "단기 대안 C → 중장기 방안 B 이행" 제안을 수용하되, 아르고스의 `insurance_chunks` 오염 분석을 반영하여 최종 추천에서 방안 B 기반으로 조정.
- **아테나 (UX/UI)**: 1차 검토 통과. 시나리오별 분석과 인지 부하 비교가 설계사 관점에서 실용적. "탭 분리" 제안과 "영상 단위 Level 1"의 탐색 패턴 적합성 분석을 최종 추천안에 반영.
- **아르고스 (테스터)**: 1차 검토 통과. **가장 중요한 발견**: `vector-search/route.ts`의 sourceType 필터 부재 확인과 이로 인한 대안 C의 구조적 결함 식별. 이 발견이 최종 추천을 방안 B 기반으로 전환하는 핵심 근거가 됨. 코드 레벨 분석의 품질이 우수.

---

## 8. 셀프 QC

### 8-1. 이 변경이 다른 파일에 영향을 미치는가?
본 작업은 분석/보고서만 생성하며 코드 변경 없음. 다른 파일에 영향 없음. 추후 구현 시 영향 범위는 보고서 내 Phase별로 명시.

### 8-2. 이 로직의 엣지 케이스는 무엇인가?
분석 과정의 엣지 케이스로, 두 방안의 용어 불일치(방안 B의 L1=채널 통합 vs 대안 C의 L1=영상 핵심)를 §1에서 명확히 정의하여 혼동 방지. 각 팀원 분석에서 서로 다른 결론이 나온 경우 근거를 비교하여 종합 판단.

### 8-3. 이 구현이 작업 지시와 정확히 일치하는가?
작업 지시: "방안 B vs 대안 C 장단점 분석, 5가지 비교 기준, 최종 추천안과 근거". 5가지 비교 기준(확장성, 쿼리 성능, 마이그레이션 비용, 데이터 일관성, 운영 복잡도)에 대해 각각 분석 완료. 최종 추천안(방안 B 개선안)을 근거와 함께 제시.

### 8-4. 에러 처리와 보안은 확인했는가?
분석 작업으로 직접적 에러 처리/보안 이슈 없음. 다만 보고서 내에서 `insurance_chunks` 벡터 검색의 보안/품질 리스크(4순위 정보가 1순위로 노출되는 정보 권위 역전)를 핵심 발견으로 기록함.

### 8-5. 테스트가 모든 경로를 커버하는가?
분석 작업이므로 코드 테스트 없음. 3명의 팀원이 각각 독립적으로 기술/UX/QA 관점에서 분석하여 교차 검증 역할을 수행. 팀원 간 의견 불일치(불칸 vs 아르고스의 최종 추천 차이)는 §5에서 통합 판단.

---

## 9. 생성/수정 파일 목록

| 파일 | 작업 | 사유 |
|------|------|------|
| `/home/jay/projects/insuwiki/plans/plan-task-141.1.md` | 신규 생성 | 작업 계획서 |
| `/home/jay/projects/insuwiki/memory/reports/task-141.1.md` | 신규 생성 | 분석 보고서 (본 파일) |

---

*작성: 헤르메스 (개발1팀장) / 2026-03-03*
*팀원 분석: 불칸(백엔드), 아테나(UX/UI), 아르고스(테스터)*