# 20260328 Research — Kling Repackaging / Reverse-Engineering Analysis

## 질문
Kling 원 API를 fal.ai 같은 중간 사업자들이 리패키징해서 판매하는지, 그리고 그 문서/SDK/예제를 통해 Kling API 문서를 역구성할 수 있는지 평가한다.

## 결론
- **전제는 대체로 맞다.** Kling capability를 중간 사업자가 래핑해서 판매하는 사례가 실제로 존재한다.
- 다만 **원본 Kling API와 1:1 동일하다고 가정하면 위험하다.**
- 그러나 **capability map, 요청 흐름, 비동기 작업 구조, callback 패턴, 파라미터 범주를 역추론하는 데는 매우 유용하다.**

## 확인된 사례

### 1. Freepik API
문서:
- `https://docs.freepik.com/api-reference/video/kling-v3-omni/generate-std`

확인된 내용:
- Kling 3 Omni Standard를 직접 상품화해서 제공
- Text-to-video, Image-to-video, Multi-shot, Element control 설명 포함
- `video-to-video generation using a reference video`는 별도 endpoint로 분리한다고 명시
- OpenAPI 형식 문서 제공
- callback용 `webhook_url` 필드 존재
- 비동기 task 생성/조회 패턴 존재

의미:
- Kling capability가 외부 서비스에서 실제로 재패키징되어 판매되고 있음
- 특히 `reference video`가 별도 endpoint라는 설명은, 공식 Kling 문서에서 확인한 `videoExtension`, `multiImageToVideo` 분리 구조와 맞물려 해석 가능

### 2. GitHub `mcp-kling`
문서:
- `https://github.com/199-mcp/mcp-kling/blob/main/kling-api-docs.md`

확인된 내용:
- Video Generation 섹션에 다음 capability map 존재
  - Text to Video
  - Image to Video
  - Multi-Image to Video
  - Video Extension
  - Lip-Sync
  - Video Effects
- Callback Protocol, Account Information Inquiry 섹션 포함
- 요청/응답 예제 및 필드 설명 포함

의미:
- 이 문서는 공식 Kling 문서 구조와 매우 높은 수준으로 대응한다
- 특히 `Multi-Image to Video`, `Video Extension`, `Callback Protocol`, `Account Information Inquiry`는 우리가 공식 bundle에서 확인한 path 구조와 일치한다
- 따라서 이 자료는 원본 Kling API 구조를 역추론하는 데 매우 강한 단서다

## 냉정한 평가

### 맞는 점
1. **중간 사업자 문서는 매우 유용하다**
   - capability map 확보
   - async task 흐름 이해
   - callback/webhook 구조 이해
   - endpoint 분리 방식 이해

2. **공식 문서 bundle에서 발견한 구조와 외부 문서 구조가 일치한다**
   - `OmniVideo`
   - `multiImageToVideo`
   - `videoExtension`
   - `callbackProtocol`
   - `rateLimits`

3. **역구성 전략으로 가치가 높다**
   - 공식 본문을 못 뚫는 상황에서 현실적인 우회다

### 조심할 점
1. **파라미터 이름은 다를 수 있다**
   - 공급자마다 wrapper field명을 바꿀 수 있음
   - 기본값/옵션 단순화가 있을 수 있음

2. **일부 capability만 노출할 수 있다**
   - 공급자마다 기능 범위가 다를 수 있음

3. **원문 문장/정확한 요청 형식이라고 단정하면 안 된다**
   - 문서 재구성 시 반드시 `확인됨 / 추정 / wrapper 기준`을 구분해야 한다

## 최종 판단
- 이 전략은 **타당하고, 지금 상황에서는 매우 현실적**이다.
- 특히 `mcp-kling` 문서는 capability map이 공식 bundle 구조와 높은 정합성을 보여서 가치가 크다.
- 따라서 다음 API 문서 생성 단계에서는:
  1. 공식 Kling 구조(bundle/path)
  2. 리패키징 서비스 문서(Freepik 등)
  3. wrapper/open-source 문서(mcp-kling)
를 교차검증해서 **실용적인 Kling API 문서 초안**을 만드는 전략이 적절하다.