# 계획서: task-146.1 — 약관 PDF 업로드 아키텍처 미팅

## 작업 개요
약관 PDF 업로드 파이프라인의 현재 아키텍처를 팀원 전원이 다각도로 분석하고, 개선 방안을 도출하는 아키텍처 미팅을 수행한다. 코딩 작업 없이 분석/토론/보고만 진행.

## 서브태스크 분해 및 팀원 배정

### 토르 (백엔드) — 업로드 파이프라인 & 인덱싱 아키텍처 분석
- 현재 업로드 흐름 (drive-upload API → Google Drive → jobs 생성 → pdfIndexing 트리거) 분석
- Cloud Functions pdfIndexing.ts의 성능/안정성/확장성 평가
- PDF 파싱(pdf-parse) → 청킹 → 임베딩 → Firestore 저장 파이프라인 병목 분석
- 대용량 PDF/동시 업로드 처리 능력 평가
- Google Drive 의존성에 대한 대안 검토 (Firebase Storage, Cloud Storage 등)
- 개선 제안 도출

### 프레이야 (프론트엔드) — 업로드 UI/UX 및 상태 관리 분석
- /admin/upload 페이지의 현재 UX 분석
- 파일 검증(파일명 패턴), 드래그앤드롭, 다중 업로드 UX 평가
- 업로드 진행률/상태 추적 (uploading/success/error) 개선점 파악
- 업로드 후 인덱싱 작업 진행 상황 표시 방안
- 에러 핸들링 및 사용자 피드백 개선 제안

### 미미르 (UX/UI) — 전체 워크플로우 설계 및 사용자 경험 평가
- 관리자의 PDF 업로드 → 인덱싱 → 검색 가능 전체 워크플로우 분석
- 파일명 규칙({회사}_{상품}_{YYMM}.pdf) 사용성 평가
- 카테고리 자동 분류 로직(생명/손해/변액) 사용자 경험 분석
- 재업로드/업데이트 시 기존 데이터 처리 워크플로우 분석
- UX 관점 개선 제안서 작성

### 헤임달 (테스터) — 품질/안정성/보안 관점 분석
- 현재 파이프라인의 에러 핸들링 완전성 검증 분석
- 대용량 파일, 깨진 PDF, 중복 업로드 등 엣지 케이스 시나리오 도출
- 보안 취약점 분석 (파일 검증, 접근 제어, 인젝션 가능성)
- 인덱싱 실패 시 복구 메커니즘 분석
- 테스트 전략 제안서 작성

## 실행 순서
1. 팀원 4명 병렬 분석 (독립 작업이므로 동시 실행)
2. 팀장(오딘) 결과 통합 및 최적안 도출
3. 보고서 작성

## 예상 위험/대안
- **위험**: 기존 코드 파악 부족 시 분석이 피상적일 수 있음
  → **대안**: 각 팀원에게 관련 소스 코드를 직접 읽도록 지시
- **위험**: 팀원 간 분석 중복
  → **대안**: 역할별 분석 범위를 명확히 분리 (백엔드/프론트/UX/QA)

## 실패 시나리오 체크리스트

### 1. 비정상 입력/상태
- 해당 작업은 미팅/분석이므로 코드 비정상 입력은 없음
- 다만 분석 대상 소스 파일이 없거나 변경된 경우 → 탐색 에이전트로 최신 코드 확인

### 2. 동시성/경쟁 조건
- 분석 전용 작업이므로 코드 변경 없음 → 동시성 이슈 해당 없음
- 다만 PDF 업로드 아키텍처 자체의 동시성 문제는 분석 대상에 포함

### 3. 비정상 종료/타임아웃
- 서브에이전트 타임아웃 시 → 결과 부분만으로 보고서 작성 가능
- 분석 중 에이전트 실패 시 → 재실행 또는 팀장이 직접 분석 보완

### 4. 스테일 데이터
- 코드가 최근 변경되었을 수 있음 → 서브에이전트가 직접 파일을 읽어 최신 상태 확인
- 이전 태스크 보고서의 정보가 오래되었을 수 있음 → 소스 코드 우선 참조

### 5. 통합 시 충돌
- 코드 수정 없으므로 파일 충돌 없음
- 팀원 간 분석 의견 충돌 시 → 팀장이 근거 기반으로 최적안 결정