Runway Enhance Frame Rate, Dev API에 출시: 24~120fps, NTSC 포함

Runway는 2026년 9월 17일 자사 개발자 API에 새로운 프레임 보간 모델을 공개했는데, 실제로 중요한 디테일은 최상위 레인지가 아니라 소수점 단위의 프레임 레이트다. Runway Enhance Frame Rate는 이미 보유한 영상을 24, 25, 30, 48, 50, 60 또는 120 fps 목표로 리타이밍하며, 방송과 영화가 실제로 전달하는 세 가지 레이트인 23.98, 29.97, 59.94도 지원한다. Runway 자체 개발자 체인지로그에는 이 모델이 enhance_frame_rate로 문서화되어 있고, 회사가 이미 크리에이티브 업스케일러에 사용하는 동일한 POST /v1/video_upscale 엔드포인트를 통해 호출되며, 작업당 입력 300초로 제한되고 2초당 1크레딧으로 청구된다.

그 청구 항목이 두 번째 놀라움입니다. 프레임 보간은 보통 출력 기준으로 가격이 책정됩니다 — 같은 엔드포인트에서 Runway 자체의 Magnific Video Upscaler는 720p/1K에서 출력 프레임당 0.7 크레딧을 청구합니다 — 즉 24 fps에서 120 fps로의 변환은 24에서 25로의 변환에 드는 비용의 다섯 배가 듭니다. enhance_frame_rate는 입력 초당 요금이 청구됩니다. 5배 프레임 증식과 1.05배 증식의 비용은 정확히 같습니다. 여러분의 작업이 하나의 영상을 여러 프레임 레이트로 납품하는 것이라면, 가격표의 그 한 줄은 일반적인 계산법을 뒤집어 놓습니다.

타이밍도 의미심장하다. Runway의 독립형 Frame Interpolation 도구는 회사의 공식 지원 중단 도구 목록에 있으며, Animate Keyframes 앱이 그 대체 도구로 명시되어 있다. Enhance Frame Rate는 그 웹 도구의 부활이 아니다. 그것은 API 모델로 다시 구축된 프레임 보간으로, 타임라인을 클릭해 넘겨보는 사람이 아니라 파이프라인을 겨냥한다.

Enhance Frame Rate가 실제로 하는 일

이것은 리타이밍 모델이지 생성형 모델이 아닙니다. 프롬프트도, 이미지도, 참조 클립도 없습니다. 이미 존재하는 영상, 즉 카메라로 찍은 영상, 편집본, 다른 Runway 모델의 결과물 등 무엇이든 건네면, 목표 프레임 레이트에 도달하는 데 필요한 중간 프레임을 합성합니다. Runway가 자사 X 계정에 올린 발표도 같은 취지로 설명합니다: “어떤 푸티지든 필요한 사양으로 변환합니다.”

구조적으로 보면 video upscale 엔드포인트에서 실행되는 비동기 작업입니다. 비디오 URI를 POST하고 model: "enhance_frame_rate"를 설정하면 작업 ID를 돌려받은 뒤 결과를 폴링합니다. Runway의 업스케일러와 엔드포인트를 공유하므로, 이미 /v1/video_upscale과 통신하는 파이프라인이라면 새 통합이 아니라 매개변수 변경만 필요합니다.

Runway의 변경 로그에는 다음이 현재 공급업체가 밝힌 사양으로 나열되어 있습니다. 이 중 어느 것도 독립적으로 검증되지 않았습니다 — 이 모델에 대한 제3자 벤치마크가 없으며, 작성 시점 기준으로 이 모델은 공개된 지 하루밖에 되지 않았습니다.

• 대상 레이트 — 24, 25, 30, 48, 50, 60 및 120fps, 그리고 23.98, 29.97 및 59.94fps(API에서는 23_98, 29_97 및 59_94로 표기)

• 입력 제한 — 작업당 300초

• 가격 — 입력 2초당 1크레딧; Runway API 크레딧은 개당 $0.01

• 액세스 — Runway Dev에서 model: "enhance_frame_rate"로 POST /v1/video_upscale

• Runway의 선행 기술 — frame_interpolation_v1 작업 유형은 2024-11-06 API 버전에 존재했으며, 독립형 웹 Frame Interpolation 도구는 지원 중단되었습니다.

• 독립적 평가 — 발표된 사례 없음

프레임 레이트 계층, 그리고 23.98이 진짜 핵심인 이유

모든 소비자용 보간 도구는 정수 배율을 제공합니다. 여기서 흥미로운 열은 분수 배율 열입니다. 왜냐하면 전달 사양이 실제로 명시하는 것이 바로 분수 배율이기 때문입니다:

• 23.98(23.976) — NTSC 필름 레이트. 거의 모든 시네마 및 스트리밍 마스터에 해당하며, DVD와 Blu-ray가 기준으로 제작된 레이트이기도 합니다.

• 24 — 실제 필름 속도이며, 여전히 DCP와 많은 영화제 납품물에 사용됩니다.

• 25 — PAL 및 EBU 지역: 영국, 유럽 대부분, 오스트레일리아, 아시아와 아프리카의 상당 지역.

• 29.97 — NTSC 방송, 30의 소수점 버전.

• 30 — 화면 캡처, 웹 및 게임 영상에 대한 정수 레이트.

• 48 — 고프레임레이트 시네마(호빗 영화가 촬영되고 상영된 프레임 레이트).

• 50 — PAL 고프레임률, 정확히 2× 25.

• 59.94 — NTSC 고프레임 레이트, 미국과 일본에서의 60 Hz 방송 송출 레이트.

• 60 — 정수 60Hz, 부드러운 웹 재생을 위한 일반적인 목표입니다.

• 120 — 슬로모션 및 고주사율 제공.

24와 23.976 사이의 차이는 사소해 보이지만 사소하지 않다. 1시간 러닝타임 동안 둘은 약 3.6초씩 벌어진다. 24.000 마스터를 23.98 납품 체인에 넣으면 방송 QC에서 실패할 오디오 싱크 드리프트와 케이던스 오류가 발생한다. 그래서 포스트하우스들은 역사적으로 레이트를 리샘플링하기 위해 별도의 컨폼 단계를 운영했거나, 해당 작업을 거부했다. 프랙셔널 레이트를 직접 출력하는 도구는 그 체인에서 한 단계를 없애준다. 이는 "120 fps"보다 훨씬 좁고 훨씬 더 지루한 주장이며, 방송사에 납품하는 사람이라면 신경 써야 할 이유다.

48과 120 목표치는 실제로는 의심해야 할 대상이다. 24fps 소재를 120fps까지 보간한다는 것은 실제 프레임 하나마다 네 개의 프레임을 만들어내는 것을 뜻하며, 빠른 움직임, 가림, 심한 모션 블러가 있는 경우 모든 종류의 보간기는 고스팅과 워핑을 만들어낸다. Runway는 아티팩트 분석도, 다른 어떤 보간기와의 비교도, 샷별 품질 지침도 공개하지 않는다 — 그러므로 정직한 입장은 스펙이 120을 지원한다는 것이고, 당신의 푸티지에서 120이 어떤 모습인지는 검증되지 않았다는 것이다.

비용은 얼마인가, 하나하나 따져보면

계산이 유난히 깔끔한 것은 단위가 입력 초이기 때문이다. 2초당 1크레딧이고, Runway 개발자 API에서는 크레딧당 $0.01이다(선불, 1,000크레딧에 최소 $10):

• 10초 클립, 어떤 목표 속도에서든 — 5크레딧, 약 $0.05

• 30초 클립 — 크레딧 15개, 약 $0.15

• 60초 클립 — 30 크레딧, 약 $0.30

• 5분 클립, 최대 300초 — 150크레딧, 약 $1.50

• 90초 클립, 24 → 25 fps — 45 크레딧, 약 $0.45

• 동일한 90초 클립, 24 → 120 fps — 45 크레딧, 약 $0.45

마지막 두 줄이 전체 가격 논거입니다. 출력 프레임당 모델에서는 두 번째 작업의 프레임 수가 5배가 되므로 청구 금액도 대략 5배가 됩니다. 여기서는 무료입니다.

같은 엔드포인트에 있는 인접 서비스와의 비교는 이 점을 구체적으로 보여줍니다. Magnific Video Upscaler는 출력 프레임당 과금합니다 — 720p/1K에서 0.7크레딧, 2K에서 0.9크레딧, 4K에서 1.2크레딧이며, 생성당 최소 1크레딧이 적용됩니다. 10초, 30fps 클립은 출력 프레임 300개이므로 720p/1K 요금은 210크레딧, 약 $2.10이 됩니다. 동일한 클립을 enhance_frame_rate로 처리하면 5크레딧, 약 $0.05입니다. 더 큰 이미지가 아니라 더 높은 프레임 레이트를 원한다면, 업스케일러를 선택하는 비용은 약 40배 더 듭니다. 또한 업스케일러의 선택적 fps 향상을 활성화하면 출력 프레임 수가 바뀌어 해당 청구 금액이 더 올라간다는 점에 유의하세요 — Runway의 가격 문서에서 이를 명시적으로 밝히고 있습니다.

한 가지 비용 관련 주의사항을 짚어둘 필요가 있습니다. 여기서 기준이 되는 것은 이 글이 아니라 Runway의 개발자 가격 페이지이며, 크레딧 가격은 2026년 8월부터 맞춤형 가격 책정을 위해 검토 중인 것으로 보고되었습니다. 대규모 배치를 예산에 반영하기 전에 포털을 확인하세요.

300초 제한, 그리고 이를 우회하는 방법

모든 작업은 입력이 300초로 제한됩니다. 이는 쇼트 하나에는 넉넉하고 릴 하나에는 짧은 시간이라, 그보다 긴 것은 분할해야 합니다 — 그리고 어떻게 분할하느냐가 제한 시간 자체보다 더 중요합니다.

고정된 시간 간격이 아니라 장면 경계에서 컷하세요. 인터폴레이터는 인접 프레임 사이의 모션을 추론합니다. 하드 컷에서는 샷 A의 마지막 프레임과 샷 B의 첫 프레임 사이에 모션 관계가 전혀 없으며, 컷을 감지하지 못하는 모델은 그 사이에 모프를 아무렇지 않게 만들어냅니다. Runway의 체인지로그에는 이 모델에 대한 자동 장면 감지가 문서화되어 있지 않으므로, 없다고 가정하는 것이 안전합니다. 컷 지점에서 청크를 나누고, 각 청크를 보간한 뒤, 새 레이트로 타임라인에서 다시 조립하세요.

그 조언은 Runway에만 국한된 것이 아니다 — 그것은 모든 곳에서 AI 리타이밍에 관한 표준적인 주의사항이다. 23.976 → 25 및 29.97 → 23.976 같은 변환을 위한 TensorRT 최적화 보간 파이프라인을 설명한 2025년 SMPTE 논문도 같은 점을 지적한다: 프레임 변환된 콘텐츠는 장면 컷에서 프레임 브레이크가 필요하고, 이후 QC가 필요하다. 그렇지 않으면 모델이 접합부를 넘어 환각을 일으킨다. 첫 번째 패스에서는 어려운 전환 주변에 수동 프레임 교체가 필요할 것으로 예상하라.

대안 대비 어디에 위치하는가

프레임 보간은 꽤 오래전부터 거의 해결된 문제였는데, 둘 다 이 방식과는 다른 두 가지 형태로 존재해 왔습니다.

• 데스크톱 제품군 — Topaz Video AI의 Apollo와 Chronos 모델은 품질 중심 리타이밍의 기준점이다. 영구 라이선스, 직접 보유한 GPU, 초당 요금 청구 없음, 그리고 자신이 무엇을 보고 있는지 아는 사람에게 보답하는 튜닝 과정.

• 오픈소스 인터폴레이터 — RIFE 및 유사 모델, 자체 호스팅 방식으로, 하드웨어만 갖추면 한계 비용이 사실상 무료이며, 포스트 프로덕션 업체들이 직접 구축한 대부분의 맞춤형 파이프라인의 기반이 된다.

• Runway Enhance Frame Rate — 로컬 컴퓨팅 불필요, API 호출 방식, 입력 초당 과금, 그리고 그동안 다른 두 기능에서는 사용자가 직접 수작업으로 맞춰야 했던 소수점 NTSC 프레임 레이트.

이 트레이드오프는 분명하다. 이미 보유한 워크스테이션에서 한 번만 처리할 샷이라면, 로컬 보간기가 더 저렴하고 Runway가 노출하지 않는 조절 옵션을 제공한다. 자동화 파이프라인 안으로 들어오는 푸티지, 또는 동일한 클립을 한 지역에서는 23.98로, 다른 지역에서는 25로 출력해야 하는 납품 결과물 매트릭스의 경우, 소수 레이트를 직접 반환하는 API는 컨폼 단계를 하나 없애주며, 입력 초당 가격이므로 다중 레이트 출력에 추가 비용이 들지 않는다.

그것을 둘러싼 라우팅 계층

리타이밍은 가까운 어딘가에 언어 모델 단계가 있는 파이프라인의 한 단계입니다. 샷 리스트와 컨폼 노트, 새로운 프레임 레이트에 맞춰 다시 타이밍을 조정해야 하는 자막 및 캡션 패스, 지역별 전달 메타데이터, QC 로그 — 이는 텍스트 작업이며, 비디오 파이프라인에서 아무도 예산을 배정하지 않는 부분입니다.

그 계층이 실행되는 방식은 OrcaRouter 카탈로그에 있는 200개 모델 전반에서 사용하는 하나의 키이며, 제공업체 정가가 0% 마크업으로 그대로 전달되고 제공업체 간 자동 장애 조치가 이루어지므로, 더 새롭거나 더 저렴한 모델을 실제 트래픽에서 시험해 보면서도 프로덕션 경로를 그 모델에 걸지 않아도 됩니다. 범위를 정확히 하자면: Runway Enhance Frame Rate는 Runway 자체 엔드포인트에서 호출되는 Runway Dev API 모델이며, OrcaRouter는 이를 제공하지 않습니다. 우리가 다루는 것은 그 주변의 모든 것입니다.

아직 알려지지 않은 것

품질에 관해서는 거의 다루지 않았습니다. 이 모델은 이 글을 쓰는 시점을 기준으로 대략 하루 된 모델이며, 위에서 설명한 그 동작에 관한 모든 내용은 Runway 자체 변경 로그와 발표에서 나온 것입니다. 특히 검증되지 않은 사항은 다음과 같습니다:

• 빠른 움직임, 가림, 모션 블러 및 저비트레이트 소스에서의 아티팩트 양상 — 아무도 공개한 테스트가 없음

• 장면 컷을 자동으로 감지하는지, 아니면 컷을 넘어 블렌딩하는지

• 프레임 레이트가 변경될 때 오디오가 그대로 전달되는지, 리샘플링되는지, 아니면 버려지는지

• 품질 면에서 RIFE, Apollo 또는 Chronos와 어떻게 비교되는지 — 직접 비교한 자료는 없음

• 목표 속도가 높아져도 입력 초당 가격이 유지되는지, 아니면 나중에 등급이 다시 조정되는지

120 fps와 48 fps 목표치는 자신의 영상을 직접 그것들로 돌려보기 전까지는 주장일 뿐이라고 여기고, 처음 보내는 클립에서 컷 처리 상태를 확인하세요.

누가 지금 움직여야 하나요?

방송 또는 다지역 사양으로 납품하면서 현재 컨폼 단계에 비용을 지불하고 있다면, API 호출 하나를 더 감당할 수 있는 자동화 파이프라인을 푸티지가 이미 통과하고 있다면, 또는 고속 촬영을 한 적 없는 카메라에서 슬로 모션을 원하지만 GPU를 돌리기는 싫다면, 지금 행동하세요.

단일 작업에서 5분 넘게 필요하고 컷 지점에서 분할할 수 없다면, 해상도도 함께 높여야 한다면 — 그건 프레임당 가격이 책정된 업스케일러입니다 — 또는 이미 데스크톱 인터폴레이터를 보유하고 있고 이번이 일회성 촬영이라면, 기다리세요. 그리고 편의성보다 품질이 결정적 요인이라면 기다리세요: Runway 밖에서는 아무도 수치를 공개하지 않았고, 첫 독립 비교가 기다릴 가치가 있는 것입니다.

주목할 패턴은 Runway가 이 엔드포인트를 모델별로 계속 확장하는지 여부다. 이미 크리에이티브 업스케일러를 갖추고 있고 이제는 리타이머도 있는데, 둘 다 POST /v1/video_upscale에 있으며 가격은 전혀 다른 단위로 책정된다. 전달 파이프라인을 구축하는 사람이라면, 출력 프레임이 아니라 입력 초라는 단위가 설계 기준으로 삼을 만한 부분이다.