# 제품 목표 및 운영 관점 리뷰

## 기준 질문

이 저장소가 현재 상태에서 정말로 "시나리오 PDF를 받아 안정적으로 웹북용 이미지 산출물을 만든다"는 제품 목표를 달성할 수 있는가?

답은 다음과 같다.

- **가능은 하다.**
- 하지만 **안정적으로 반복 가능하냐**는 질문에는 아직 보수적으로 답해야 한다.

## 1. 목표에 이미 도달한 부분

### 1.1 핵심 사용자 흐름은 실제로 존재한다

- `README.md:1-6`은 시나리오 분석 → 웹북 제작 시스템을 설명한다.
- `backend/app/api/v1/episodes.py`는 업로드/조회/진행률 경로를 제공한다.
- `backend/app/api/v1/steps.py`와 `backend/app/api/v1/images.py`는 분석/이미지/스냅샷/편집 API를 제공한다.
- `frontend/src/pages/EpisodeDetail.tsx`와 `frontend/src/components/episode/EpisodeStills.tsx`는 실제 검토/편집 화면을 제공한다.

의미:

- 이 프로젝트는 아이디어 단계가 아니라, 이미 end-to-end 제품 골격을 가진다.

### 1.2 HiTL 방향의 기반도 있다

- still 선택/해제
- variation 생성/선택
- prompt 수정
- snapshot 저장/복원 API
- world guide, world rules, progress panel

즉 "AI가 만들고 사람이 고친다"는 방향은 코드에 이미 반영돼 있다.

## 2. 목표 달성을 막는 현재 병목

### 2.1 결과를 만들 수 있어도, 품질 상태를 신뢰하기 어렵다

실측:

- backend pytest: `637 passed, 56 failed, 2 errors, 1 skipped`
- frontend lint: `77 errors, 3 warnings`
- frontend test/spec: 없음

영향:

- 결과는 생성돼도, 작은 리팩토링이나 운영 환경 차이로 회귀할 가능성을 시스템이 충분히 막아주지 못한다.

### 2.2 사용자에게 보이는 계약이 완전히 하나가 아니다

- `EpisodeDetail`은 `/steps/run-all`을 사용
- `Episodes`는 `/analyze`를 사용

영향:

- 같은 "분석 시작" 행동이 화면마다 다른 백엔드 계약을 타면, 사용자 지원과 운영 진단이 어려워진다.

### 2.3 provenance와 reviewability가 아직 제품 중심 UX가 아니다

`docs/product-roadmap-discussion.md`가 정확히 지적하듯, 현업 사용자는 "왜 이렇게 나왔는지", "어디를 어떻게 고치면 되는지"를 알고 싶어 한다.

현재 상태:

- 관련 데이터는 일부 존재
- 하지만 설명 흐름과 편집 흐름은 아직 개발자 친화적이다

영향:

- 결과가 맞더라도 신뢰 확보 비용이 높다.

### 2.4 다중 에피소드/장기 운영 모델이 약하다

제품 논의 자료는 cross-episode canon, timeline, review workflow, approval 흐름을 미래 과제로 두고 있다.

현재 기준 문제:

- 에피소드 단위는 강하지만, 작품 전체 연속성 관리는 아직 제품 계약으로 고정되지 않았다.
- 이 프로젝트가 파일럿을 넘어 실무 도구가 되려면 반드시 넘어야 할 단계다.

## 3. 운영 관점 리스크

### 3.1 startup과 환경 초기화가 분리돼 있지 않다

- `backend/app/main.py:38-45`는 import-time `init_db()`와 startup bootstrap을 동시에 가진다.

영향:

- 테스트와 운영 모두에서 예상치 못한 초기화 부수효과가 발생하기 쉽다.

### 3.2 projection 실패가 사용자에게 충분히 보이지 않는다

- checkpoint는 성공했지만 DB projection이 stale할 수 있는 구조가 남아 있다.

영향:

- 사용자는 "AI가 틀렸는지", "UI가 stale한지"를 구분하기 어렵다.

### 3.3 복구 경로는 API 수준에는 있지만 UX 수준에는 약하다

- snapshot API는 존재한다.
- 그러나 실제 제품 플로우에서 복구/비교/되돌리기 UX는 충분히 드러나지 않는다.

## 4. 제품 관점에서 가장 먼저 필요한 것

### 4.1 안정성

현재는 기능 추가보다 다음이 먼저다.

- 계약 정합
- 테스트 lane 분리
- startup/test 경계 정리
- projection failure 가시화

### 4.2 설명 가능성

현업 사용자는 "좋은 결과"만이 아니라 "왜 그런 결과가 나왔는지"를 원한다.

필요 요소:

- provenance 노출
- 샷 선택 근거
- outlook / prompt 변화 이력

### 4.3 수정 가능성

현재도 수정 기능은 있지만, 감독/작가 관점에서는 아직 작업 개념보다 데이터 개념에 가깝다.

다음 단계는 이쪽이다.

- 이미지 위 지시
- 자연어 수정 요청
- 일괄 수정과 개별 수정의 분리
- review/approval 흐름

## 5. 결론

이 프로젝트는 "핵심 기능이 없는 상태"가 아니다.

오히려 반대다.

- 분석 파이프라인도 있다.
- 이미지 생성도 있다.
- 사람 개입 지점도 있다.

하지만 지금 필요한 것은 새 기능의 양적 확대보다, 이미 있는 흐름을 **반복 가능하고 신뢰 가능한 제품 흐름으로 굳히는 것**이다.