# RAG 평가 시각화 구현 계획 (전문가 종합 관점)

> **목적**: Phoenix와 Frontend의 역할 분담을 명확히 하고, 다양한 전문가 관점을 종합한 시각화 구현 계획 수립
> **작성일**: 2026-01-10
> **참고**: Phoenix 12.27.0 기능, 인지과학/시각화/UX 최신 연구

---

## 0. 현행 시스템 적합성 점검 (EvalVault 기준)

### ✅ 이미 충족되는 기반
- **Frontend 스택**: React 19 + Vite + Tailwind v4 + Recharts 구성이라 기본 차트 구현은 바로 착수 가능
- **Phoenix 링크/메타데이터**: `RunDetails`/`EvaluationStudio`/`Settings`에 Phoenix UI 링크/Endpoint 입력 UI가 이미 존재
- **Stage 데이터 저장소**: `stage_events`, `stage_metrics` 테이블 및 CLI 저장 경로가 마련되어 있음

### ⚠️ 보완이 필요한 부분
- **Web UI 실행 경로**에서는 `StageEvent` 저장이 기본값으로 존재하지 않음 (CLI 옵션 기반)
- **API 조회 경로 부재**: `/runs/{id}`에 stage 이벤트/메트릭을 조회하는 전용 API가 없음
- **임베딩 벡터 가용성**: Query/Context/Answer 임베딩을 UI에서 직접 비교할 데이터가 저장/노출되지 않음
- **라이브러리 불일치**: React Query/Zustand/Plotly는 현재 미도입 → 도입 시 비용/로드맵 명시 필요

### 결론
- **계획 방향성은 유효**하지만, **데이터/계측 기반(Phase 0)** 없이 바로 Phase 2 착수는 리스크가 큼
- Phoenix 중심의 고급 시각화는 유지하되, EvalVault UI는 **요약 + 진입점** 중심으로 얇게 설계하는 것이 현실적

## 1. 전문가 관점별 핵심 요구사항 정의

### 1.1 인지심리학자 관점

**핵심 원칙**:
- **인지 부하 최소화**: 한 화면에 7±2개 정보 청크 유지
- **패턴 인식 촉진**: 유사한 패턴을 시각적으로 그룹화
- **주의 집중 유도**: 중요한 정보를 시각적 계층으로 강조
- **작업 기억 보조**: 컨텍스트 전환 최소화 (모달/탭 최소화)

**구체적 요구사항**:
1. **점진적 정보 공개 (Progressive Disclosure)**
   - 기본: 요약 메트릭 + 핵심 인사이트
   - 확장: 클릭/호버로 상세 정보 표시
   - 심화: Phoenix 링크로 전문 분석

2. **시각적 그룹핑**
   - 성공/실패 케이스를 색상으로 즉시 구분
   - 클러스터별로 공간적으로 그룹화
   - 단계별로 시각적 구분 (Retrieval → Rerank → Generation)

3. **인지 부하 관리**
   - 복잡한 차트는 Phoenix로 위임
   - Frontend는 핵심 인사이트만 표시
   - 필터/검색으로 정보 범위 제한

### 1.2 시각 정보 전문가 관점

**핵심 원칙**:
- **정보 계층 구조**: 중요도에 따른 시각적 강조
- **시각적 인코딩 일관성**: 색상/크기/형태의 의미 일관성
- **공간 활용**: 2D/3D 공간을 의미 있게 활용
- **비교 용이성**: 비교해야 할 항목을 인접 배치

**구체적 요구사항**:
1. **색상 인코딩 체계**
   - 성공: 녹색 계열 (Green 500-600)
   - 경고: 노란색 계열 (Yellow 400-500)
   - 실패: 빨간색 계열 (Red 500-600)
   - 정보: 파란색 계열 (Blue 500-600)
   - 중립: 회색 계열 (Gray 400-500)

2. **크기 인코딩**
   - 메트릭 점수 → 점 크기 (높을수록 큰 점)
   - 중요도 → 폰트 크기/두께

3. **공간 배치**
   - 시간 축: 왼쪽 → 오른쪽
   - 계층 구조: 위 → 아래
   - 비교: 나란히 배치

### 1.3 UI/UX 전문가 관점

**핵심 원칙**:
- **사용자 워크플로우 최적화**: 자주 하는 작업을 빠르게
- **피드백 제공**: 모든 액션에 즉각적 피드백
- **에러 방지**: 잘못된 입력 사전 차단
- **접근성**: 키보드 네비게이션, 스크린 리더 지원

**구체적 요구사항**:
1. **워크플로우 최적화**
   - 평가 실행 → 결과 확인 → Phoenix 분석 → 개선 가이드
   - 각 단계에서 다음 액션을 명확히 제시
   - Phoenix 링크를 적절한 시점에 표시

2. **인터랙션 디자인**
   - 호버: 상세 정보 미리보기
   - 클릭: 상세 페이지/모달
   - 드래그: 비교할 Run 선택

3. **피드백 메커니즘**
   - 로딩 상태: 스켈레톤 UI
   - 성공/실패: 토스트 알림
   - 진행 상황: 프로그레스 바

### 1.4 뇌과학자 관점

**핵심 원칙**:
- **시각 처리 최적화**: 뇌가 빠르게 인식하는 패턴 활용
   - 대비: 명확한 경계
   - 대칭: 균형 잡힌 레이아웃
   - 패턴: 반복되는 구조
- **인지 편향 활용**:
   - Anchoring: 기준선 명시
   - Framing: 긍정적 프레이밍 (개선 여지 vs 실패)

**구체적 요구사항**:
1. **시각적 대비**
   - 배경과 전경의 명확한 구분
   - 중요한 정보는 고대비 색상

2. **패턴 인식 촉진**
   - 반복되는 레이아웃 구조
   - 일관된 아이콘/심볼 사용

3. **인지 편향 활용**
   - 기준선(threshold) 명시로 anchoring
   - "개선 여지" vs "실패" 프레이밍

### 1.5 정보공학 전문가 관점

**핵심 원칙**:
- **정보 아키텍처**: 논리적 그룹핑과 계층 구조
- **데이터 구조화**: 일관된 데이터 모델
- **확장성**: 새로운 메트릭/단계 추가 용이
- **재사용성**: 컴포넌트 기반 설계

**구체적 요구사항**:
1. **정보 구조**
   - Run → Test Case → Stage → Metric 계층
   - 각 레벨에서 적절한 집계/상세 정보 제공

2. **데이터 모델**
   - StageMetric, EvaluationResult 등 일관된 엔티티
   - API 응답 구조 표준화

3. **확장성**
   - 새로운 메트릭 타입 추가 시 최소 변경
   - 플러그인 방식의 시각화 컴포넌트

### 1.6 교육공학 전문가 관점

**핵심 원칙**:
- **학습 효과 극대화**: 정보를 이해하기 쉽게 전달
- **점진적 학습**: 기본 → 고급 순서로 정보 제공
- **피드백 루프**: 즉각적 피드백으로 학습 촉진

**구체적 요구사항**:
1. **점진적 정보 제공**
   - 초보자: 요약 + 간단한 설명
   - 중급자: 상세 메트릭 + 비교
   - 고급자: Phoenix 링크 + 원시 데이터

2. **학습 지원**
   - 툴팁으로 용어 설명
   - 예시 케이스 제공
   - 개선 가이드 연결

### 1.7 색채 전문가 관점

**핵심 원칙**:
- **색상 의미론**: 문화적/보편적 색상 의미 활용
- **색맹 접근성**: 색상만으로 정보 전달하지 않음
- **색상 조화**: 조화로운 색상 팔레트 사용

**구체적 요구사항**:
1. **색상 의미**
   - 성공: 녹색 (Green)
   - 경고: 노란색 (Yellow/Amber)
   - 실패: 빨간색 (Red)
   - 정보: 파란색 (Blue)
   - 중립: 회색 (Gray)

2. **접근성**
   - 색상 + 아이콘/패턴으로 정보 전달
   - WCAG 2.1 AA 기준 준수 (대비율 4.5:1 이상)

3. **색상 팔레트**
   - Tailwind CSS 기본 팔레트 활용
   - 다크 모드 지원

### 1.8 컴퓨터 공학 전문가 관점

**핵심 원칙**:
- **성능**: 렌더링 최적화, 가상화, 지연 로딩
- **확장성**: 대용량 데이터 처리
- **유지보수성**: 모듈화, 테스트 가능성
- **표준 준수**: 웹 표준, 접근성 표준

**구체적 요구사항**:
1. **성능 최적화**
   - 대용량 데이터셋: 가상 스크롤
   - 복잡한 차트: Web Workers 활용
   - 이미지/차트: 지연 로딩

2. **아키텍처**
   - 컴포넌트 기반 (React)
   - 상태 관리: React Query + Zustand
   - API: RESTful, 표준 응답 형식

3. **표준 준수**
   - HTML5 시맨틱 태그
   - ARIA 속성
   - 반응형 디자인

### 1.9 웹 페이지 디자이너 관점

**핵심 원칙**:
- **시각적 일관성**: 브랜드 아이덴티티 유지
- **레이아웃 균형**: 공간 활용과 여백
- **타이포그래피**: 가독성과 계층 구조
- **반응형 디자인**: 다양한 화면 크기 지원

**구체적 요구사항**:
1. **레이아웃**
   - 그리드 시스템 활용
   - 일관된 간격 (4px/8px 기준)
   - 여백 활용으로 시각적 휴식

2. **타이포그래피**
   - 명확한 계층 구조 (H1-H6)
   - 적절한 줄 간격 (1.5-1.75)
   - 가독성 높은 폰트 (Inter, System UI)

3. **반응형**
   - 모바일: 단일 컬럼
   - 태블릿: 2컬럼
   - 데스크톱: 3-4컬럼

---

## 2. Phoenix vs Frontend 역할 분담

### 2.1 Phoenix에서 처리할 시각화 (외부 도구 활용)

#### ✅ UMAP 2D/3D 임베딩 맵
- **이유**: Phoenix의 핵심 기능, 고성능 렌더링
- **활용**: 질문/답변/컨텍스트 임베딩 공간 시각화
- **연동**: `tracker_metadata["phoenix"]["experiment"]["url"]` 링크 제공

#### ✅ HDBSCAN 클러스터링
- **이유**: Phoenix의 자동 클러스터링 알고리즘
- **활용**: 유사 쿼리 그룹핑, 이상치 감지
- **연동**: Phoenix Embeddings 탭에서 확인

#### ✅ Drift 시계열
- **이유**: Primary vs Reference 임베딩 거리 추적
- **활용**: 시간에 따른 품질 변화 모니터링
- **연동**: Phoenix Query Distance 탭

#### ✅ 포인트 클라우드 컬러링
- **이유**: 메트릭 점수/태그 기반 동적 색상 지정
- **활용**: 문제 영역 시각적 식별
- **연동**: Phoenix Embeddings 탭

#### ✅ 검색 품질 메트릭 자동 계산
- **이유**: Phoenix의 네이티브 기능
- **활용**: Precision@K, Recall@K, NDCG, MRR
- **연동**: Phoenix Retrieval Quality Dashboard

#### ✅ 트레이스 뷰
- **이유**: OpenTelemetry 기반 트레이스 시각화
- **활용**: 전체 파이프라인 실행 흐름 추적
- **연동**: Phoenix Traces 탭

### 2.2 Frontend에서 구현할 시각화 (EvalVault 특화)

#### 🔨 단계별 임베딩 비교 (Query vs Retrieved vs Answer)
- **이유**: Phoenix는 단일 임베딩 공간만 표시, 단계별 비교 불가
- **목적**: 검색 품질을 기하학적으로 확인
- **구현**:
  - Query 중심으로 Retrieved Docs 거리 시각화
  - Answer와 Context 유사도 시각화
  - 거리/유사도를 색상/크기로 인코딩

#### 🔨 단계별 메트릭 트렌드 (시간에 따른 변화)
- **이유**: Phoenix는 실시간 모니터링 중심, Run 간 비교 부족
- **목적**: 평가 실행 간 성능 변화 추적
- **구현**:
  - Line Chart: 시간에 따른 메트릭 변화
  - 비교: Base vs Target Run
  - 필터: 특정 메트릭/단계 선택

#### 🔨 클러스터별 메트릭 집계 및 비교
- **이유**: Phoenix는 클러스터 시각화만 제공, 메트릭 집계 없음
- **목적**: 클러스터별 성능 패턴 식별
- **구현**:
  - 클러스터별 평균 메트릭 계산
  - Bar Chart: 클러스터별 메트릭 비교
  - 저성과 클러스터 자동 감지

#### 🔨 Stage-level 메트릭 시각화 (Waterfall Chart)
- **이유**: Phoenix는 트레이스만 제공, Stage 메트릭 집계 없음
- **목적**: 단계별 성능 병목 식별
- **구현**:
  - Waterfall Chart: Retrieval → Rerank → Generation
  - 각 단계의 latency, precision, recall 표시
  - 병목 지점 강조

#### 🔨 EvalVault 특화 인사이트 (Domain Memory 연동)
- **이유**: EvalVault만의 기능, Phoenix와 무관
- **목적**: Domain Memory 기반 개선 가이드 제공
- **구현**:
  - 클러스터 → Domain Memory Facts 매핑
  - 개선 가이드 카드
  - 관련 Facts/Behaviors 표시

#### 🔨 Run 간 비교 시각화
- **이유**: Phoenix는 Experiment 비교만 제공, Run 단위 비교 부족
- **목적**: 평가 실행 간 회귀/개선 확인
- **구현**:
  - Delta Chart: 메트릭 변화량
  - Diff View: 답변 차이 하이라이트
  - 필터: Regressed Cases Only

#### 🔨 메트릭 상관관계 분석
- **이유**: Phoenix는 개별 메트릭만 표시, 상관관계 분석 없음
- **목적**: 메트릭 간 관계 파악
- **구현**:
  - Scatter Plot: 두 메트릭 간 관계
  - 상관계수 표시
  - 이상치 감지

---

## 3. 종합 구현 계획

### 3.0 Phase 0: 데이터/계측 기반 구축 (1~2주)

**목표**: Web UI에서도 Stage 데이터를 안정적으로 확보하고, 이후 시각화의 기반을 만든다.

**구현**:
- **StageEvent 저장 경로 확장**: Web UI 평가 요청에 `stage_store` 옵션(또는 설정 플래그) 추가
- **API 조회 확장**:
  - `GET /runs/{id}?include=stage_summary,stage_metrics` (권장)
  - 또는 `/runs/{id}/stage-events`, `/runs/{id}/stage-metrics` 별도 엔드포인트
- **StageMetric 재계산 경로**: 이벤트만 있을 때 `StageMetricService`로 재계산하는 옵션 제공
- **Phoenix Trace 연결**: `trace_id`/`span_id`를 StageEvent에 유지하여 Trace ↔ Stage 연결 가능하게 유지

**전문가 관점 적용**:
- **정보공학**: 데이터 모델의 일관성 확보
- **컴퓨터 공학**: 최소 데이터 요청으로 집계 응답 제공 (summary 먼저)

### 3.1 Phase 1: 기반 구축 (2주)

#### 1.1 Phoenix 연동 강화
**목표**: Phoenix 링크를 적절한 시점에 표시

**구현**:
- **기존 Phoenix CTA 정리/확장**
  - `RunDetails`/`EvaluationStudio`/`AnalysisLab`에서 Phoenix 링크 노출 위치를 통일
  - 조건: `tracker_metadata.phoenix.*.url` 존재 시만 활성화
  - 상태: Phoenix 비활성 시 안내 텍스트 + 설정 이동 링크 제공
- **Contextual Deep Link**
  - Embeddings/Traces/Experiment 탭으로 직접 이동하는 링크 템플릿 적용

**전문가 관점 적용**:
- **UI/UX**: 명확한 CTA 버튼, 적절한 위치
- **인지심리**: Phoenix 링크를 "다음 단계"로 제시
- **정보공학**: `tracker_metadata` 구조 표준화

#### 1.2 Stage-level 메트릭 API 확장
**목표**: Frontend에서 Stage 메트릭 조회 가능

**구현**:
- Phase 0에서 확장한 API를 실제 UI에서 소비
- **StageEvent 타입 정합성**
  - 현재 기본 Stage 타입: `system_prompt`, `input`, `retrieval`, `output`
  - `rerank`/`generation`은 추후 계측 확장 시 추가

**전문가 관점 적용**:
- **정보공학**: 일관된 API 응답 구조
- **컴퓨터 공학**: 효율적인 쿼리 (인덱스 활용)

### 3.2 Phase 2: 핵심 시각화 구현 (4주)

#### 2.1 Stage-level Waterfall Chart
**목표**: 단계별 성능 병목 시각화

**구현**:
- 컴포넌트: `StageWaterfallChart.tsx`
- 라이브러리: **Recharts 우선**, 필요 시 D3 보완
- 데이터: StageEvent의 `duration_ms` 집계 (Stage 타입 기반)
- 시각화:
  - X축: Test Case ID
  - Y축: 누적 시간 (ms)
  - 색상: 단계별 구분 (Input: Gray, Retrieval: Blue, Output: Green)
  - 호버: 단계별 상세 정보 (latency, precision, recall)

**전문가 관점 적용**:
- **인지심리**: 누적 시간으로 전체 흐름 파악
- **시각 정보**: 색상으로 단계 구분
- **뇌과학**: 대비를 통한 병목 지점 강조
- **색채**: 단계별 의미 있는 색상 (Blue=검색, Yellow=재정렬, Green=생성)

#### 2.2 단계별 임베딩 비교 (Query vs Retrieved vs Answer)
**목표**: 검색 품질을 기하학적으로 확인

**구현**:
- 컴포넌트: `EmbeddingComparison.tsx`
- 라이브러리: 2D는 Recharts/Canvas 기반, 3D는 **옵션(지연 로딩)**으로 Plotly
- 데이터:
  - Query Embedding (중심점)
  - Retrieved Documents Embeddings (주변점)
  - Answer Embedding (결과점)
- 시각화:
  - 2D/3D 스캐터 플롯
  - Query 중심으로 거리 표시
  - 색상: Retrieved Docs는 관련성 점수, Answer는 Faithfulness 점수
  - 크기: 메트릭 점수에 비례
- 인터랙션:
  - 호버: 문서 내용/점수 표시
  - 클릭: 상세 정보 모달
  - 필터: 특정 Test Case 선택

**전문가 관점 적용**:
- **인지심리**: 공간적 관계로 품질 직관적 이해
- **시각 정보**: 거리 = 관련성, 색상 = 품질
- **교육공학**: 기하학적 관계로 추상적 개념 시각화
- **컴퓨터 공학**: Plotly.js의 WebGL 렌더링으로 성능 최적화
  - **전제 조건**: 임베딩 벡터를 저장/조회할 데이터 파이프라인 필요 (Phase 0~1에서 준비)

#### 2.3 클러스터별 메트릭 집계
**목표**: 클러스터별 성능 패턴 식별

**구현**:
- 컴포넌트: `ClusterMetrics.tsx`
- 데이터 소스:
  - Phoenix export-embeddings 결과 (CSV/Parquet) 우선
  - Phoenix API 접근이 불가하면 **CSV 업로드**로 대체
- 시각화:
  - Bar Chart: 클러스터별 평균 메트릭
  - 색상: 평균 점수에 따라 그라데이션
  - 필터: 특정 메트릭 선택
- 인터랙션:
  - 클릭: 해당 클러스터의 Test Cases 목록
  - 호버: 클러스터 정보 (크기, 대표 질문)

**전문가 관점 적용**:
- **인지심리**: 그룹별 비교로 패턴 인식 촉진
- **정보공학**: 클러스터 → 메트릭 집계 파이프라인
- **교육공학**: 클러스터별 특징으로 학습 효과

### 3.3 Phase 3: 고급 시각화 (3주)

#### 3.1 메트릭 트렌드 (시간에 따른 변화)
**목표**: 평가 실행 간 성능 변화 추적

**구현**:
- 컴포넌트: `MetricTrendChart.tsx`
- 데이터: 여러 Run의 메트릭 점수
- 시각화:
  - Line Chart: 시간에 따른 메트릭 변화
  - 다중 라인: 여러 메트릭 동시 표시
  - 기준선: Threshold 표시
  - 영역: 개선/악화 구간 강조
- 인터랙션:
  - 필터: 특정 메트릭/단계 선택
  - 비교: Base vs Target Run
  - 줌: 특정 기간 확대

**전문가 관점 적용**:
- **인지심리**: 시간 축으로 변화 패턴 인식
- **뇌과학**: 선 그래프로 추세 인식 촉진
- **정보공학**: 시계열 데이터 구조화

#### 3.2 메트릭 상관관계 분석
**목표**: 메트릭 간 관계 파악

**구현**:
- 컴포넌트: `MetricCorrelation.tsx`
- 데이터: 모든 Test Case의 메트릭 점수
- 시각화:
  - Scatter Plot: 두 메트릭 간 관계
  - 색상: 클러스터 ID 또는 성공/실패
  - 추세선: 상관관계 표시
  - 상관계수: 숫자로 표시
- 인터랙션:
  - 선택: X/Y축 메트릭 선택
  - 호버: Test Case 정보
  - 필터: 특정 클러스터/단계

**전문가 관점 적용**:
- **시각 정보**: 산점도로 관계 직관적 이해
- **정보공학**: 상관계수 계산 알고리즘
- **교육공학**: 상관관계로 인과관계 학습

### 3.4 Phase 4: 통합 및 최적화 (2주)

#### 4.1 Phoenix 링크 통합
**목표**: Frontend에서 Phoenix로 자연스러운 전환

**구현**:
- 모든 시각화에 "View in Phoenix" 링크 추가
- 컨텍스트에 맞는 Phoenix 탭으로 이동
  - 임베딩 관련: Embeddings 탭
  - 트레이스 관련: Traces 탭
  - 메트릭 관련: Metrics 탭
- Phoenix에서 돌아올 때 상태 유지

**전문가 관점 적용**:
- **UI/UX**: 자연스러운 워크플로우
- **인지심리**: 컨텍스트 전환 최소화

#### 4.2 성능 최적화
**목표**: 대용량 데이터셋 처리

**구현**:
- 가상 스크롤: 대량 Test Case 목록
- 지연 로딩: 차트 데이터
- Web Workers: 복잡한 계산
- 캐싱: API 응답 캐시

**전문가 관점 적용**:
- **컴퓨터 공학**: 성능 최적화 기법
- **UI/UX**: 로딩 상태 표시

#### 4.3 접근성 개선
**목표**: WCAG 2.1 AA 준수

**구현**:
- ARIA 속성 추가
- 키보드 네비게이션
- 스크린 리더 지원
- 색상 대비 개선

**전문가 관점 적용**:
- **색채**: 색상 대비 기준 준수
- **UI/UX**: 접근성 가이드라인 준수

---

## 4. 기술 스택 및 라이브러리

### 4.1 차트 라이브러리
- **Recharts**: 기본 차트 (Line, Bar, Area)
  - 이유: React 네이티브, 가볍고 빠름
  - 용도: 트렌드, 집계 차트
- **Plotly.js (옵션)**: 고급 3D 시각화
  - 이유: 3D 스캐터 플롯, WebGL 렌더링
  - 용도: 임베딩 비교 (필요 시 지연 로딩)
- **D3.js (보완)**: 커스텀 시각화
  - 이유: Recharts로 구현이 어려운 경우에만 제한적으로 사용

### 4.2 상태 관리
- **현재 기본**: `services/api.ts` + 로컬 상태 (현행 유지)
- **React Query/Zustand (옵션)**:
  - 데이터 규모 증가 시 도입 검토
  - 도입 시 마이그레이션 범위/리스크를 명시

### 4.3 스타일링
- **Tailwind CSS**: 유틸리티 CSS
  - 이유: 일관된 디자인 시스템
- **Lucide React**: 아이콘
  - 이유: 일관된 아이콘 스타일

---

## 5. 디자인 시스템

### 5.1 색상 팔레트
- **기본 원칙**: Tailwind 토큰 + CSS 변수(`--primary`, `--muted`, `--destructive`) 우선 사용
- **Stage 컬러 매핑**:
  - Input: `--muted-foreground`
  - Retrieval: `--primary`
  - Output: `--success` (없을 경우 `--primary` 계열로 치환)
  - Phoenix CTA: Orange 계열 유지

### 5.2 타이포그래피
- **제목**: Space Grotesk (현재 `font-display`)
- **본문**: IBM Plex Sans KR (현재 기본 본문)
- **코드/수치**: JetBrains Mono

### 5.3 간격
- **기본 단위**: 4px
- **간격**: 8px, 16px, 24px, 32px, 48px

---

## 6. 성공 지표

### 6.1 사용성 지표
- **작업 완료 시간**: 평가 결과 분석 시간 단축
- **오류율**: 잘못된 해석/액션 감소
- **사용자 만족도**: 설문 조사

### 6.2 기술 지표
- **렌더링 성능**: 초기 로딩 < 2초
- **인터랙션 응답**: < 100ms
- **접근성 점수**: Lighthouse 90+ 점

---

## 7. 다음 단계

1. **Phase 0 시작**: Stage 데이터/API 기반 구축
2. **Phase 1 시작**: Phoenix 링크/요약 UI 정리
3. **Phase 2 시작**: 핵심 시각화 구현
4. **사용자 테스트**: 각 Phase 완료 후 피드백 수집

---

**참고 문서**:
- [Phoenix Embeddings Analysis](https://github.com/Arize-ai/phoenix/blob/arize-phoenix-v12.27.0/docs/phoenix/cookbook/retrieval-and-inferences/embeddings-analysis.mdx)
- [WCAG 2.1 Guidelines](https://www.w3.org/WAI/WCAG21/quickref/)
- [Information Visualization Design](https://www.interaction-design.org/literature/topics/information-visualization)
