WAN I2V를 붙였는데 결과가 계속 5초로만 나오면, 모델 한계라기보다 워크플로우 입력값이 기본값으로 떨어진 경우가 많다. 핵심은 길이를 직접 제어하는 입력(num_frames, fps 등)이 실제 요청 JSON에 들어갔는지 먼저 확인하는 것이다.

flowchart LR
A[증상: 결과가 항상 5초] --> B[입력 점검: 요청 JSON 확인]
B --> C{길이 제어 필드 존재?}
C -- 아니오 --> D[기본값 실행\n(체감상 5초 고정)]
C -- 예 --> E[fps/frames 계산 검증]
E --> F[재실행 후 길이 확인]

🧠 칠판 치트시트

  • 5초 고정의 1순위 원인은 모델보다 입력 누락이다.
  • n8n에서는 “JSON 본문이 문자열로 나간” 경우도 반드시 확인한다.
  • seconds = num_frames / fps로 먼저 목표 길이를 역산한다.

왜 5초로 보이기 쉬운가

wavespeedai/wan-2.1-i2v-480p 모델 설명에는 5초 480p 생성 문구가 보인다. 이 문구는 성능 설명(예시) 성격이 강하고, 실제 생성 길이는 호출 시 입력 파라미터/워크플로우 설정 영향을 받는다.
공식 모델 페이지와 API 문서를 함께 보면, 호출 요청의 input 필드가 결과를 좌우한다.

10분 점검 순서 (실무형)

1) 먼저 “실제 전송 JSON”을 본다

n8n HTTP Request 노드에서 Body를 어떻게 보냈는지 로그/실행데이터로 확인한다.
UI에서 넣은 값과 실제 전송값이 다른 경우가 자주 생긴다.

참고: n8n HTTP Request 노드 문서
https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/

2) 길이 제어 필드를 명시한다

길이를 고정값에 맡기지 말고, 최소한 num_frames, fps를 함께 넣어 목표 길이를 계산한다.

  • 예: 8초 목표, 16fps → num_frames=128
  • 예: 10초 목표, 24fps → num_frames=240

3) n8n 본문 타입을 다시 확인한다

JSON 본문이 문자열로 직렬화되면 API가 파라미터를 다르게 해석하거나 거절할 수 있다.
n8n 이슈에서도 유사 문제가 보고됐다.

4) 래퍼 입력 스키마를 점검한다 (message_text만 받는지)

현업에서 자주 놓치는 부분은 “모델”이 아니라 “중간 래퍼”다.
워크플로우가 message_text만 받는 구조라면, fps/num_frames를 UI에 적어도 실제 요청 body에는 반영되지 않을 수 있다.

  • 점검 순서: 래퍼 입력 스키마 확인 → 길이 필드 허용 여부 확인 → 허용 안 되면 스키마 확장 후 재실행
  • 판단 기준: 실행 로그에 fps, num_frames가 실제 body에 보이면 길이 제어가 정상 경로에 올라탄 상태

증상별로 바로 잡는 3가지 처방

현장에서 제일 자주 나오는 실패 패턴은 아래 3가지다.

  1. 항상 5초 근처로만 출력된다
  • 원인 후보: fps/num_frames 누락
  • 바로 조치: 목표 길이부터 역산해 입력 고정 (seconds = frames / fps)
  1. 같은 워크플로우인데 실행마다 길이가 흔들린다
  • 원인 후보: Expression 값 타입 불안정(문자열/숫자 혼재)
  • 바로 조치: n8n에서 숫자형으로 강제하고 실행데이터에서 실제 body 확인
  1. 길이 필드를 넣었는데도 무시된다
  • 원인 후보: JSON 본문이 문자열로 직렬화되어 API 해석 실패
  • 바로 조치: HTTP Request 노드의 JSON 전송 옵션 재확인 후 재실행

바로 붙여서 쓰는 요청 예시

아래처럼 input 내부에 길이 관련 필드를 명시해 시작하면, “5초 체감 고정” 재현률이 크게 줄어든다.

{
  "version": "MODEL_VERSION_ID",
  "input": {
    "image": "https://.../input.png",
    "prompt": "cinematic motion, natural light",
    "fps": 16,
    "num_frames": 128
  }
}

미니 사례 2개

사례 A — 실패 → 성공

  • 실패: message_text만 전달(길이 파라미터 없음) → 결과가 계속 5초 근처
  • 성공: fps+num_frames 명시 → 목표 길이(8초)로 안정화

사례 B — 실패 → 성공

  • 실패: n8n Expression 사용 중 body가 문자열로 전달 → 파라미터 무시/오류
  • 성공: JSON 본문 전송 방식 수정 + 실행데이터 검증 → 정상 길이 출력

운영 체크리스트

  1. 모델 플레이그라운드/API 예시에서 입력 필드 이름 최신 여부 확인
  2. n8n 실행데이터에서 실제 전송 body 확인
  3. num_frames / fps 계산값과 결과 길이 비교
  4. 2회 이상 같은 길이로 고정되면 노드 직렬화(본문 타입)부터 재점검

다음 읽기

AI 도구를 활용해 초안을 작성했고, 공식 문서 링크를 기준으로 실무 점검 순서를 재구성했습니다.