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 필드가 결과를 좌우한다.
- 모델 페이지: https://replicate.com/wavespeedai/wan-2.1-i2v-480p
- API 레퍼런스: https://replicate.com/docs/reference/http
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가지다.
- 항상 5초 근처로만 출력된다
- 원인 후보:
fps/num_frames누락 - 바로 조치: 목표 길이부터 역산해 입력 고정 (
seconds = frames / fps)
- 같은 워크플로우인데 실행마다 길이가 흔들린다
- 원인 후보: Expression 값 타입 불안정(문자열/숫자 혼재)
- 바로 조치: n8n에서 숫자형으로 강제하고 실행데이터에서 실제 body 확인
- 길이 필드를 넣었는데도 무시된다
- 원인 후보: 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 본문 전송 방식 수정 + 실행데이터 검증 → 정상 길이 출력
운영 체크리스트
- 모델 플레이그라운드/API 예시에서 입력 필드 이름 최신 여부 확인
- n8n 실행데이터에서 실제 전송 body 확인
num_frames / fps계산값과 결과 길이 비교- 2회 이상 같은 길이로 고정되면 노드 직렬화(본문 타입)부터 재점검
다음 읽기
- 08. OpenClaw 스킬
- 11. skills 실전
- 17. 유튜브 에디터
- 19. OpenClaw 설치 오류 복구
- 29. 프롬프트 캐싱 안 먹을 때 해결
- 31. 바이브코딩 실전 워크플로우
- 37. 팀 바이브코딩 텔레그램 공동조작
- 39. MCP vs CLI 실전 판단 기준
- 40. OpenClaw 텔레그램 권한 변경 대응
- 41. 하니스 완전공개
- 49. Claude Code Best Practice 운영 가이드
- 51. 텔레그램 프라이버시 모드 복구
- 55. 50대 체력 회복 루틴 정리
- 54. Claude Code 스킬 크리에이터
AI 도구를 활용해 초안을 작성했고, 공식 문서 링크를 기준으로 실무 점검 순서를 재구성했습니다.