# 20260328 Research — Kling API Phase 1 Analysis

## 목적
Cloudflare Browser Rendering으로 확보한 Kling 문서 HTML의 내부 구조를 분석해, 실제 API 파라미터/문서 본문 접근 가능성을 판단한다.

## 분석 대상
- `samples/kling-api/overview.html`
- `samples/kling-api/omni_video.html`
- `samples/kling-api/omni_guide.html`

## 현재 결과

### 1. Browser Rendering 자체는 성공
- `content` endpoint로 3개 문서 HTML 확보 성공
- 따라서 Kling 문서 접근 경로는 확보됨

### 2. 하지만 본문 추출은 아직 실패에 가까움
분석 결과:
- `overview`와 `omni_video` HTML은 표면상 거의 동일한 셸(shell) 성격
- `video reference`, `next shot`, `previous shot`, `OpenAPI`, `rate limit` 같은 핵심 키워드가 본문에 직접 노출되지 않음
- `api_like_paths`도 추출되지 않음
- `__NEXT_DATA__` 같은 직관적인 hydration payload 흔적도 안 보임

### 3. 현재 판단
이 페이지들은 단순 SSR 본문 페이지가 아니라,
- 클라이언트 렌더링이 더 깊게 필요하거나
- 내부 API/XHR로 본문을 별도 로드하거나
- 브라우저 상호작용/추가 로딩 이후에만 본문이 보이는 구조일 가능성이 높음

## 확인된 사실
- `window.__CDN_DISPATCH__` 등 페이지 셸 스크립트는 보임
- 하지만 문서 실본문이나 파라미터 표는 현재 HTML에 직접 포함되지 않음
- 따라서 단순 `content` endpoint 1회 호출만으로는 Kling API spec 확보가 어려움

## 다음 단계 후보
1. Browser Rendering의 다른 사용 방식 검토
   - Playwright/Workers bindings
   - 페이지 로딩 후 DOM 상호작용/대기
2. HTML 안의 JS bundle / network 호출 단서 추적
3. 문서 링크 구조를 먼저 더 넓게 파악해, 실제 데이터 소스 URL 탐색
4. 필요 시 Cloudflare가 아닌 더 강한 브라우저 자동화(Apify 등) 검토

## 결론
Phase 1 정찰 결과, Browser Rendering `content`만으로는 Kling API 전체 내용을 바로 얻을 수 없다.
다만:
- 접근 경로는 확보되었고
- 문서가 셸/동적 로딩 구조라는 중요한 사실을 확인했으며
- 이후 수집 전략을 정교화할 근거는 확보했다.