AI 영상 생성은 얼마나 걸리나요? Sume Job, 실행, 한도

Sume에서 영상 생성 Job 하나는 모델과 파라미터에 따라 보통 30초에서 몇 분이 걸리고, 롱폼 호스트 영상을 만드는 Format 실행은 보통 15~30분이면 끝납니다. 영상은 이만큼 오래 걸리기 때문에 Sume는 이를 비동기로 실행합니다. 제출한 뒤 ID를 보관하고, 폴링하거나 웹훅을 받는 방식입니다.

이 수치는 Sume 문서에 나온 값으로, 주로 영상 생성 (영문), Format API (영문), 실행과 결과 (영문) 페이지를 2026-09-26에 확인했습니다. Sume는 Job별 예상 완료 시간(ETA)을 공개하지 않으며, 이 글도 따로 벤치마크를 더하지 않습니다.

영상 작업은 종류별로 얼마나 걸리나요?

문서에 나온 것은 약속이 아니라 일반적인 범위입니다. 또 이 시간은 영상의 길이가 아니라 영상을 만드는 데 걸리는 시간입니다. 아바타 스크립트와 다중 장면 계획은 추정 영상 길이가 4~60초 안에 들어야 하며, 모델별 클립 길이는 모델별 AI 영상 길이 한도에 정리되어 있습니다.

영상 Job이 더 오래 걸리는 이유는 무엇인가요?

문서는 다음 요인을 꼽습니다.

• 모델과 그 설정입니다. 해상도가 높을수록 생성 시간이 길어지고 비용도 늘어납니다.
• 서버 부하입니다. pending 상태에 머무는 /v1/videos Job은 모델, 해상도, 서버 부하에 따라 몇 분이 걸릴 수 있습니다. 문서는 일정한 간격으로 계속 폴링하라고 권합니다.
• 워크스페이스 큐입니다. queued는 정상적인 접수 상태이고 동시성 한도는 워커가 Job을 processing으로 옮길 때 적용되므로, Job이 먼저 슬롯을 기다릴 수 있습니다.
• mode는 요인이 아닙니다. 결과를 어떤 방식으로 전달받든 Job의 비용이나 실행에 걸리는 시간은 바뀌지 않습니다.

Format 실행에서는 시간이 어디에 쓰이나요?

Format 실행의 events_url인 GET /v1/format-runs/{run_id}/events는 phase 타임라인을 반환합니다. 각 항목에는 at 타임스탬프, phase, status(pending, running, done, warning, error, skipped 중 하나)가 있고, 단계가 스스로 시간을 측정했다면 duration_ms도 있습니다. 단계는 세 가지입니다.

• preparing: 에이전트가 실행을 넘겨받기 전까지의 모든 과정입니다.
• running: 에이전트가 레시피대로 작업하는 단계로, 문서는 시간이 쓰이는 곳이 바로 여기라고 설명합니다.
• finalizing: 정리(teardown)와 출력물 수집 단계입니다.

{
  "data": [
    { "at": "2026-08-23T23:23:41.000Z", "phase": "preparing", "status": "done", "duration_ms": 1840 },
    { "at": "2026-08-23T23:31:12.000Z", "phase": "running", "status": "running", "duration_ms": null },
    { "at": "2026-08-23T23:40:57.000Z", "phase": "finalizing", "status": "done", "duration_ms": 620 }
  ]
}

느린 실행과 멈춘 실행은 어떻게 구분하나요?

타임라인의 마지막 항목을 읽으세요. 단계와 상태가 같은 연속 항목은 하나로 합쳐지고 그 항목의 at이 계속 갱신되므로, 마지막 항목의 at이 곧 실행의 진행 시계입니다. 이 값이 몇 분 동안 움직이지 않으면, 문서는 그 실행이 느린 것이 아니라 멈춘 것이며 아래 한도에서 종료 처리된다고 설명합니다. UI 쪽은 진행 상황 표시하기에서 다룹니다.

queued에서 멈춘 실행에는 따로 신호가 있습니다. 아무것도 실행을 가져가지 않은 채 일반적인 픽업 시간을 넘기면 queue.state가 runtime_unavailable로 바뀝니다. 이 상태가 몇 분 넘게 이어지면 request_id를 담아 지원 티켓을 보낼 만합니다.

시간 한도는 어떻게 되나요?

문서에 공개된 한도는 다음과 같습니다.

• Format 실행 상한입니다. 영수증의 expires_at을 넘겨서도 계속되는 실행은 failed로 강제 종료됩니다. 이 마감 시각은 created_at으로부터 최대 90분 뒤이며, 전체 규칙은 Format 실행 수명주기에 있습니다.
• 한도에 걸린 미완료 작업입니다. 생성 Job이 아직 끝나지 않은 채 시간 한도에 도달한 실행은 incomplete_assembly로 실패하며, details.pending_jobs[]가 그 Job들을 알려 줍니다. previous_run_id로 실행을 이어 가세요. 완료된 클립은 스레드에 있고 다시 생성되지 않습니다.
• 30초 대기입니다. sync나 subscribe 제출의 wait_timeout_seconds는 0–30으로 클램프됩니다. 이 값은 Job이 아니라 HTTP 요청을 제한하며, 대기 시간이 다 지나도 Job ID는 그대로 돌아옵니다.
• Job 타임아웃입니다. 실패한 Job의 오류 카테고리는 generation_timeout이나 worker_timeout일 수 있으며, 문서는 두 경우 모두 상태를 폴링하거나 나중에 재시도하라고 안내합니다.

클라이언트는 얼마나 기다린 뒤 포기해야 하나요?

마감 시간은 위 범위에 맞춰 정하세요.

• Job: 문서는 영상에 대해 클라이언트 쪽 마감 시간 20분이 적당하다고 보며, @sume-com/sdk의 waitForJob도 기본값이 20분입니다. 영상 생성 문서는 약 30초마다 폴링하라고 제안합니다.
• Format 실행: subscribeFormatRun의 기본값은 20분, waitForRun은 10분입니다. 롱폼 호스트 영상은 두 기본값보다 오래 걸릴 수 있으므로, 쿡북은 롱폼 영상에서 타임아웃을 늘리고(예시는 45분) expires_at을 정직한 상한으로 삼습니다.
• 클라이언트 타임아웃은 아무것도 취소하지 않습니다. Job이나 실행은 계속 돌아가고 계속 과금되므로, ID를 보관했다가 나중에 다시 읽으세요.