비디오 렌더링 서비스란? 클라우드 비디오 렌더링 작동 방식

소개

"비디오 렌더링 서비스"라는 용어는 다소 느슨하게 사용됩니다. 때로는 3D 애니메이션을 완성된 MP4로 변환하는 렌더팜을 의미하고, 때로는 이미 가지고 있는 비디오 파일을 재인코딩하기만 하는 클라우드 트랜스코딩 도구를 의미하며, 때로는 범용 렌더팜에 가까운 것을 가리키는 마케팅 용어로 쓰이기도 합니다. 이러한 혼란은 이해할 만합니다. 실제 비디오 렌더 작업은 서로 매우 다른 두 가지 작업, 즉 3D 씬이나 comp에서 프레임을 렌더링하는 것과 그 프레임을 재생 가능한 비디오 파일로 인코딩하는 것이 함께 결합되어 있기 때문입니다.

이 가이드는 비디오 렌더링 서비스가 프로젝트 업로드부터 분산 프레임 렌더링, 최종 H.264/H.265 인코딩과 다운로드에 이르기까지 처음부터 끝까지 어떤 일을 하는지, 그리고 실제 컴퓨팅 비용이 어디서 발생하는지 자세히 다룹니다. 표준 GHz-시간당 요금을 사용한 실제 비용 계산 예시를 살펴본 다음, 자체 머신에서 로컬로 렌더링하는 것과 비교해 서비스를 사용하는 것이 언제 합리적인지 다룹니다. 여기서는 렌더팜과 렌더 서비스 용어 문제(이는 별도의, 더 정의 중심적인 주제입니다. 이 문제 때문에 이 글을 찾아오셨다면 저희의 렌더 서비스와 렌더팜 비교 글을 참고하세요)나 일반적인 온라인 렌더링 서비스 비즈니스 모델(온라인 렌더링 서비스 작동 방식에서 다룹니다)은 다루지 않습니다. 이 글은 구체적으로 비디오 파이프라인, 즉 "제출" 버튼을 누른 뒤부터 완성된 비디오 파일을 받기까지 무슨 일이 일어나는지에 관한 내용입니다.

비디오 렌더링 파이프라인: 씬 업로드, 프레임 시퀀스 렌더링, 프레임 QC, H.264/H.265 인코딩, 전달

"비디오 렌더링"이 실제로 의미하는 것

파이프라인을 분석하기 전에, 실제로 무엇이 만들어지는지 정확히 짚고 넘어가는 것이 도움이 됩니다. 3D나 모션 디자인 맥락에서 "비디오 렌더링"은 거의 항상 다음 두 가지 결과물 유형 중 하나를 의미합니다.

• 3D 씬(3ds Max, Maya, Cinema 4D, Blender, Houdini)이나 모션 그래픽 컴프(After Effects)에서 렌더링된 애니메이션 또는 이미지 시퀀스: 워크스루, 제품 영상, 타이틀 시퀀스, VFX 샷 등이 여기에 해당합니다.
• 하나의 비디오 파일로 합쳐져야 하는 프레임 시퀀스: 브라우저, 편집 툴, 또는 클라이언트 재생 기기가 실제로 재생할 수 있는 코덱(H.264, H.265/HEVC)을 담은 컨테이너 포맷(MP4, MOV)입니다.

이 글에서 다루는 의미의 비디오 렌더링 서비스는 이 두 가지를 모두 처리합니다. 여러 머신으로 이루어진 클러스터에서 씬이나 comp의 프레임을 렌더링한 다음, 그 프레임을 최종 납품용 비디오 포맷으로 인코딩합니다. 이는 순수한 트랜스코딩 서비스와는 다릅니다. 트랜스코딩 서비스는 두 번째 절반만 처리합니다(이미 비디오 파일을 가지고 있고 단지 다른 코덱이나 비트레이트로 재인코딩하고 싶은 경우입니다). 코덱 관련 내용은 저희의 H.264/H.265 비디오 인코딩 가이드에서 별도로 다룹니다.

클라우드 비디오 렌더링 작동 방식: 파이프라인

이 메커니즘은 네 단계로 나뉘며, 실제 엔지니어링이 일어나는 곳은 가운데 두 단계입니다.

1. 프로젝트 업로드. 씬 파일(또는 After Effects 프로젝트)과 그것이 참조하는 모든 에셋(asset), 즉 텍스처, HDRI, 지오메트리 캐시, 폰트, 플러그인 종속 요소, 푸티지 플레이트를 함께 업로드합니다. 대부분의 렌더 실패는 이 단계에서 비롯됩니다. 누락된 텍스처, 로컬 드라이브에서만 해석되는 상대 경로, 렌더팜에 설치되어 있지 않은 폰트 등이 원인입니다. 풀 매니지드 렌더팜에서는 제출 클라이언트나 플러그인이 참조된 에셋을 스캔하여 해석되지 않은 항목을 작업이 전송되기 전에 표시해 줍니다. 이는 어차피 도중에 실패했을 작업에 컴퓨팅 시간을 소모하기 전에 상당수의 오류를 미리 잡아냅니다.

2. 분산 프레임 렌더링. 클라우드 렌더링을 애초에 사용할 가치가 있게 만드는 단계입니다. 비디오의 프레임 시퀀스는 본질적으로 병렬적입니다. 프레임 400은 (아래에서 다루는 몇 가지 예외를 제외하면) 프레임 399가 먼저 끝나는 것에 의존하지 않습니다. 그래서 렌더 매니저는 전체 프레임 범위를 사용 가능한 워커 노드 수만큼 나누어 각 노드에 청크 단위로 분배합니다. 1,200프레임 시퀀스를 30개의 워커에 분산하면 각 노드는 약 40프레임씩 렌더링하며, 전체 시퀀스는 워커 한 대가 1,200프레임을 모두 렌더링하는 시간이 아니라 40프레임 분량을 렌더링하는 시간에 가깝게 완료됩니다. 이것이 바로 밤새 걸리던 로컬 렌더링을 한두 시간 만에 끝낼 수 있게 만드는 핵심 메커니즘입니다.

3. 인코딩. 전체 파이프라인이 동일한 방식으로 병렬화된다고 가정하는 사람들이 놀라는 지점입니다. 비디오 코덱은 일반적으로 프레임 렌더링처럼 워커 간에 나뉘지 않습니다. H.264와 H.265는 시간적 압축을 사용합니다. 이후 프레임이 이전 프레임을 참조하기 때문입니다(P-프레임과 B-프레임은 모든 프레임을 독립적으로 저장하는 대신 인접 프레임에서 예측합니다). 즉 인코더는 깨끗하고 아티팩트 없는 결과물을 만들기 위해 일반적으로 전체 프레임 시퀀스를 순서대로 필요로 합니다. 인코딩을 여러 워커로 나누어 조각을 다시 이어 붙이면 청크 경계에서 눈에 보이는 이음매가 생길 위험이 있습니다. 실무에서 흔한 패턴이자 저희가 자체 렌더팜에서 비디오 작업에 사용하는 방식은, 전체 워커 풀에 걸쳐 프레임 시퀀스를 렌더링한 뒤(프레임 병렬이라 빠릅니다), 인코딩은 하나의 워커에서든 다운로드 후 로컬에서든 단일 패스로 실행하는 것입니다. 인코딩은 일반적으로 프레임을 렌더링하는 것보다 훨씬 빠르기 때문에, 이 단일 패스 단계가 병렬 렌더링으로 얻은 시간 절감을 없애지는 않습니다. 다만 워커를 추가해도 작업의 "인코딩" 항목은 "렌더" 항목처럼 축소되지는 않는다는 의미입니다.

4. 다운로드. 완료된 결과물, 즉 최종 인코딩된 비디오이거나 이후 컴포지팅이나 컬러 그레이딩 단계에 필요한 원본 프레임 시퀀스는 파일 크기와 워크플로에 따라 웹 다운로드, SFTP, 또는 자동 다운로드 클라이언트를 통해 반환됩니다.

프레임 렌더링과 인코딩이 규모에서 다르게 작동하는 이유

위의 2단계와 3단계 사이의 차이는 자세히 살펴볼 가치가 있습니다. "비디오 렌더링 서비스"가 렌더링 절반이 그렇다는 이유만으로 전체 파이프라인에 걸쳐 선형적으로 확장된다고 가정할 때 가장 흔하게 발생하는 오해의 원인이기 때문입니다.

프레임 렌더링 작업에 워커 노드를 추가하면 나눠줄 독립적인 프레임이 소진되는 지점까지는 실제 소요 시간이 거의 비례해서 줄어듭니다(200프레임 작업을 300개의 워커에 분산하면 100개는 유휴 상태가 됩니다). 반면 인코딩 작업에 워커를 추가해도 거의 효과가 없습니다. 보통 인코딩 작업은 여러 개가 아니라 하나뿐이기 때문입니다. 이 때문에 서류상으로는 "GPU 중심"이나 "CPU 중심"으로 보이는 제출 작업도, 프레임 수가 시퀀스 재생 시간에 비해 적거나 납품물 목록에 각각 별도의 단일 패스를 실행해야 하는 여러 개의 인코딩 대상(4K 마스터, 압축된 웹용 컷, 세로형 소셜 크롭 등)이 포함되어 있으면 여전히 단일 워커 인코딩 단계에서 병목이 발생할 수 있습니다.

렌더링 쪽에도 예외는 있습니다. 프레임 경계를 넘나들며 샘플링하는 모션 블러, 프레임마다 상태가 누적되는 파티클 시뮬레이션, 유체나 천 시뮬레이션 캐시처럼 시간적 종속성을 가진 이펙트는 순수하게 프레임 독립적인 렌더링만큼 깔끔하게 병렬화되지 않습니다. 프레임 500을 렌더링하는 워커가 프레임 499에서 계산된 시뮬레이션 상태를 필요로 할 수 있기 때문입니다. 렌더팜은 이를 처리하기 위해 먼저 시뮬레이션·캐싱 패스를 실행하고(흔히 단일 스레드나 소수의 워커에서 실행됩니다), 캐시가 생성된 뒤에는 순수 렌더링 패스를 전체 풀에 분산합니다. 프로젝트가 특히 After Effects를 사용한다면, 저희의 After Effects 클라우드 렌더링 설정 가이드에서 정확한 aerender 커맨드 구조를 포함해 이 2단계 패턴(전체 플릿에서의 이미지 시퀀스 렌더링 후 단일 워커에서의 Adobe Media Encoder 패스)을 더 자세히 다룹니다. Cinema 4D, After Effects, 그리고 타이틀 시퀀스와 커머셜 영상에 흔히 쓰이는 플러그인 스택을 포함한 더 넓은 범위의 모션 디자인 파이프라인에 대해서는 저희의 모션 디자인 렌더팜 가이드에서 워크플로별 고려사항을 다룹니다.

비용은 얼마나 듭니까? 실제 계산 예시

렌더 서비스 요금은 보통 영상당 정액제가 아니라 컴퓨팅 시간 단위로 책정됩니다. 10초짜리 타이틀 카드와 60초짜리 VFX 중심 광고 영상은 해상도와 프레임 수가 같더라도 소비하는 컴퓨팅 양이 크게 다르기 때문입니다. 저희 렌더팜에서는 CPU 렌더링에 GHz-시간당 $0.004, GPU 렌더링에 OctaneBench-시간(OBh)당 $0.003의 요금이 부과되며, RTX 5090(32GB VRAM) 기준으로는 이 기본 요금에서 카드 시간당 약 $5.2가 소요됩니다. 렌더 엔진 라이선스(V-Ray, Corona, Arnold, Redshift, Octane)는 별도 청구 없이 이 요금에 포함되어 있으며, Cycles는 무료 오픈소스입니다.

숫자를 좀 더 구체적으로 체감할 수 있도록 예시를 하나 들어보겠습니다. 1920×1080 해상도, 24fps로 제작되는 30초짜리 제품 시각화 영상을 가정하면, 이는 720프레임에 해당합니다.

CPU 경로(V-Ray 또는 Corona, 표준 우선순위): 예시로, 저희 CPU 노드(듀얼 Intel Xeon E5-2699 V4, 44코어, 기본 클럭 2.2GHz, 노드당 합산 클럭 속도 약 96.8GHz 상당) 한 대에서 프레임당 평균 6분의 렌더 시간이 걸린다고 가정해 보겠습니다.

• 프레임당 컴퓨팅: (6분 ÷ 60) × 96.8GHz = 9.68 GHz-시간
• 프레임당 비용: 9.68 × $0.004 = $0.0387
• 720프레임 총합: 720 × $0.0387 ≈ $27.90

GPU 경로(Redshift 또는 Octane, RTX 5090): 예시로, GPU 카드 한 장에서 프레임당 평균 2분의 렌더 시간이 걸린다고 가정해 보겠습니다.

• 프레임당 컴퓨팅: 2분 ÷ 60 = 0.033 카드-시간
• 프레임당 비용: 0.033 × $5.2 ≈ $0.173
• 720프레임 총합: 720 × $0.173 ≈ $124.80

이 비교에서 주목할 점은 두 가지입니다. 첫째, 이 특정 예시에서는 GPU 항목이 더 높게 나왔는데, 이는 GPU 렌더링이 자동으로 더 저렴한 선택지라는 반사적인 가정과는 다릅니다. 실제로는 해당 씬이 CPU 대비 GPU에서 얼마나 빠르게(또는 그렇지 않게) 렌더링되는지, 그리고 사용하는 렌더 엔진의 GPU 경로가 씬의 특정 기능 세트(무거운 디스플레이스먼트, 특정 셰이더 그래프, VRAM 초과 씬 등)를 얼마나 잘 처리하는지에 크게 좌우됩니다. 이런 요소들은 GPU 속도 우위를 완전히 상쇄할 수 있습니다. 둘째, 워커 노드를 더 많이 또는 더 적게 사용해 작업을 분산해도 총액은 변하지 않습니다. 병렬 처리는 실제 소요 시간을 바꿀 뿐, 소비되는 총 컴퓨팅량을 바꾸지는 않습니다. 실제로 사용한 GHz-시간이나 카드-시간에 대해 비용을 지불하는 것이지, 실제 소요 시간에 대해 지불하는 것이 아니기 때문입니다. 720프레임을 30개 노드에 분산하면 노드 한 대로 처리할 때보다 약 30배 빠르게 끝나지만, 청구 금액은 어느 쪽이든 동일합니다.

인코딩 비용은 일반적으로 렌더링 총액에 약간 더해지는 정도입니다. 720프레임 시퀀스를 H.264로 인코딩하는 작업은 동일한 프레임을 3D 씬에서 렌더링하는 것보다 훨씬 빠르게 끝납니다. 프레임당 연산량이 훨씬 가볍기 때문입니다. 최적화할 가치가 있는 항목은 렌더 항목이며, 납품물 목록이 서로 다른 해상도나 코덱으로 여러 번의 개별 인코딩 패스를 요구하지 않는 한 대부분의 작업에서 인코딩 단계는 총액에서 거의 오차 범위 수준입니다.

이 수치는 계산 방식을 보여주기 위한 예시일 뿐, 특정 프로젝트에 대한 견적이 아닙니다. 실제 프레임 시간은 씬 복잡도, 해상도, 샘플링 설정, 적용된 이펙트에 따라 크게 달라집니다. archviz와 애니메이션 씬 유형별 프레임당 시간 범위를 더 폭넓게 정리한 표는 저희 프레임당 비용 가이드를 참고하세요. 저희 비용 계산기는 프로젝트별 견적을 제공하며, 전체 작업 전에 소규모 테스트 프레임을 제출해 보는 것이 자신의 씬에 대한 실제 수치를 검증하는 가장 확실한 방법입니다.

비디오 렌더링 서비스가 적합한 경우 vs. 로컬 렌더링이 적합한 경우

로컬 렌더링이 적합한 경우: 작업이 짧아 로컬 렌더 시간이 일정에 부담을 주지 않고, 워크스테이션이 해당 씬을 처리할 만큼 충분한 VRAM이나 CPU 여유가 있으며, 최종 품질의 처리량보다 빠른 로컬 피드백 루프가 더 중요한 룩데브(look-dev) 반복 작업을 하고 있는 경우입니다. 로컬 렌더링은 대용량 에셋 라이브러리의 업로드 시간도 피할 수 있는데, 이는 느린 인터넷 환경에서 특히 중요할 수 있습니다.

비디오 렌더링 서비스가 적합한 경우: 프레임 수나 프레임당 복잡도로 인해 로컬 렌더 시간이 일정을 잠식하는 경우(밤새 돌린 로컬 렌더링이 다음 날 정오에야 끝나는 것은 가상의 상황이 아니라 실제 프로덕션 리스크입니다), 추가 머신을 구매하지 않고도 로컬 하드웨어보다 더 많은 렌더 용량이 필요한 경우, 또는 최종 품질 결과물을 렌더링하는 동안 워크스테이션을 다음 프로젝트의 룩데브 작업을 위해 비워두고 싶은 경우입니다. 마감이 4K 마스터, 압축된 웹용 컷, 세로형 소셜 크롭처럼 여러 납품물을 동시에 요구할 때도 중요합니다. 각각이 별도의 렌더 플러스 인코딩 패스이며, 단일 로컬 머신에서는 이 부담이 빠르게 누적됩니다.

이 두 가지는 하나의 프로젝트 안에서 서로 배타적이지 않습니다. 흔한 패턴은 룩데브와 반복 작업은 로컬에서 진행하고, 씬이 확정되면 최종 품질 렌더링 한 번을 렌더팜으로 보내는 것입니다. 크리에이티브 단계에서는 빠른 로컬 피드백을, 납품 단계에서는 분산 처리량을 얻는 방식입니다.

클라우드 비디오 렌더링에서 흔히 발생하는 문제

누락되거나 해석되지 않은 에셋. 비디오 렌더 작업이 실패하거나 부분적으로 실패하는 가장 흔한 원인입니다. 절대 경로로 참조된 텍스처, 워커 플릿에 설치되지 않은 폰트, 렌더팜이 라이선스를 보유하지 않은 플러그인 종속 이펙트 등이 여기에 해당합니다. 제출 전 에셋 스캔을 실행하면 컴퓨팅 시간을 소모하기 전에 대부분의 문제를 잡아낼 수 있습니다.

순서에 맞지 않게 렌더링된 시뮬레이션 종속 프레임. 씬에 (디스크에 미리 캐시되지 않고) 렌더링 과정에 그대로 포함된 유체, 천, 파티클 시뮬레이션이 있는 경우, 시뮬레이션 캐시를 먼저 생성하지 않고 프레임을 워커에 분산하면 프레임마다 결과가 일관되지 않을 수 있습니다. 각 워커가 자신이 맡은 구간을 독립적으로 계산하기 때문입니다. 해결책은 시뮬레이션을 먼저 캐싱한 다음, 순수 시각적 렌더링 패스만 분산하는 것입니다.

청크 경계에서 발생하는 인코딩 아티팩트. 일부 파이프라인은 시간을 절약하기 위해 인코딩 작업을 워커 간에 분할하기도 하는데, 이 경우 구간이 이어지는 지점에서 눈에 띄는 이음매나 밝기·색상 변화가 나타날 수 있습니다. 이것이 인코딩 단계를 프레임 렌더링과 같은 방식으로 분산하지 않고 보통 단일 패스로 실행하는 이유입니다.

납품 시 프레임 레이트 또는 컬러 스페이스 불일치. 잘못된 프레임 레이트로 설정된 렌더링이나, 프레임이 렌더링된 컬러 스페이스와 맞지 않는 인코딩은 기술적으로는 완성되었지만 클라이언트가 기대한 것과 맞지 않는 비디오를 만들어냅니다. 제출 전 프레임 레이트, 해상도, 컬러 스페이스(그리고 납품물이 방송 안전 기준을 충족해야 하는지 여부)를 확인하면 재렌더링을 피할 수 있습니다.

요약 체크리스트

FAQ

Q: 비디오 렌더링 서비스란 무엇인가요? A: 비디오 렌더링 서비스는 자신의 워크스테이션이 아니라 원격 하드웨어에서 3D 씬이나 모션 그래픽 프로젝트로부터 비디오 결과물을 렌더링해 주는 서비스로, 프레임 단위 렌더링과 최종 결과물을 재생 가능한 비디오 파일(보통 H.264 또는 H.265)로 인코딩하는 것을 모두 처리합니다. 이미 가지고 있는 비디오 파일을 재인코딩하기만 하는 순수 트랜스코딩 서비스와는 다르며, 트랜스코딩 서비스는 씬에서 프레임을 렌더링하지 않습니다.

Q: 분산 비디오 렌더링은 실제로 어떻게 작동하나요? A: 비디오 렌더링에서는 대부분의 프레임이 서로 독립적으로 렌더링되기 때문에, 렌더 매니저가 전체 프레임 수를 사용 가능한 워커 노드에 분할합니다. 각 워커는 배정된 프레임 범위를 병렬로 렌더링하므로, 한 대의 머신에서는 몇 시간이 걸릴 시퀀스도 여러 대에 걸쳐 훨씬 빠르게 완료됩니다. 완성된 프레임을 하나의 비디오 파일로 만드는 인코딩 단계는 일반적으로 같은 방식으로 분산되지 않고 이후에 단일 패스로 실행됩니다. 비디오 코덱이 워커 간에 깔끔하게 나눌 수 없는 시간적 압축을 사용하기 때문입니다.

Q: 워커를 추가해도 왜 인코딩은 렌더링과 같은 방식으로 빨라지지 않나요? A: 보통 인코딩 작업은 프레임마다 하나가 아니라 납품물마다 하나이기 때문입니다. 프레임 렌더링은 각 프레임을 (대부분) 독립적으로 계산할 수 있어 병렬화됩니다. 프레임 시퀀스를 H.264나 H.265로 인코딩하는 작업은 일반적으로 압축된 결과물에서 이후 프레임이 이전 프레임으로부터 예측되기 때문에 전체 시퀀스가 순서대로 준비되어 있어야 합니다. 인코딩을 워커 간에 분할하면 조각을 다시 이어 붙이는 지점에서 눈에 띄는 이음매가 생길 위험이 있어, 대부분의 렌더팜은 대신 단일 패스로 실행합니다.

Q: 클라우드 비디오 렌더링 비용은 얼마나 되나요? A: 비용은 영상당 정액 요금이 아니라 소비된 총 컴퓨팅(CPU는 GHz-시간, GPU는 OctaneBench-시간)에 따라 결정됩니다. 저희 렌더팜에서는 CPU 렌더링에 GHz-시간당 $0.004, GPU 렌더링에 OBh당 $0.003이 부과되며(이 요금 기준 RTX 5090은 카드 시간당 약 $5.2입니다), 렌더 엔진 라이선스가 포함되어 있습니다. 30초, 720프레임짜리 영상은 씬 복잡도, 엔진, 그리고 해당 씬이 CPU와 GPU 중 어느 쪽에서 더 빠르게 렌더링되는지에 따라 약 $25에서 $100 이상까지 다양할 수 있으며, 모든 프로젝트에 적용되는 단일한 숫자는 없습니다. 특정 작업의 비용을 추산하는 가장 확실한 방법은 테스트 프레임 렌더링입니다.

Q: 더 많은 머신에서 렌더링하면 총 비용이 달라지나요? A: 아닙니다. 작업을 더 많은 워커 노드에 분산해도 바뀌는 것은 소요 시간이지 소비되는 총 컴퓨팅량이 아닙니다. 몇 개의 노드가 병렬로 처리했는지와 관계없이, 프레임을 렌더링하는 데 실제로 사용된 GHz-시간이나 카드-시간에 대해 요금이 청구됩니다. 100프레임을 1개 대신 10개의 노드에서 처리하면 약 10배 빠르게 끝나지만, 총 컴퓨팅 비용은 동일합니다.

Q: 비디오를 로컬에서 렌더링해야 하나요, 아니면 클라우드 비디오 렌더링 서비스를 사용해야 하나요? A: 프레임 수, 마감 압박, 하드웨어에 따라 다릅니다. 일정에 부담을 주지 않는 짧은 렌더링이나, 처리량보다 빠른 로컬 피드백이 중요한 활발한 룩데브 반복 작업이라면 대체로 로컬에서 처리해도 괜찮습니다. 긴 시퀀스, 촉박한 마감, 또는 4K 마스터에 여러 개의 압축 컷이 더해진 것처럼 동시에 여러 납품물이 필요한 경우에는 로컬 렌더링이 워크스테이션을 전체 시간 동안 묶어두기 때문에 클라우드 서비스의 분산 처리 능력이 비용만큼의 가치를 발휘합니다.

Q: 클라우드 비디오 렌더링은 일반적으로 어떤 비디오 포맷과 코덱을 지원하나요? A: 대부분의 비디오 렌더링 서비스는 표준 납품 코덱으로 H.264와 H.265/HEVC를 지원하며, 완성된 비디오 파일이 아니라 후속 컴포지팅이나 컬러 그레이딩 단계로 넘겨야 하는 파이프라인을 위해 무손실 중간 포맷(EXR, PNG, DPX 이미지 시퀀스)도 함께 지원합니다. 코덱 라이선스와 인코더 지원 여부(특히 ProRes)는 제공업체와 플랫폼(Windows 워커 대 macOS 워커)에 따라 다르므로, 특정 코덱이 필요한 납품물이라면 직접 확인하는 것이 좋습니다. 저희 비디오 인코딩 가이드에서 납품용 H.264, H.265, AV1의 실질적인 차이를 다룹니다.

Q: 비디오 렌더링 서비스는 유체나 파티클 같은 시뮬레이션도 처리할 수 있나요? A: 네, 가능합니다. 다만 순수하게 프레임 독립적인 렌더링과는 워크플로가 다릅니다. 시간적 종속성을 가진 시뮬레이션(각 프레임이 이전 프레임의 상태에 의존하는 경우)은 일반적으로 먼저 디스크에 캐시됩니다. 흔히 소수의 워커, 때로는 단 하나의 워커에서만 처리됩니다. 그런 다음 그 캐시를 읽어 들이는 시각적 렌더링 패스는 시뮬레이션이 없는 씬과 마찬가지로 전체 워커 풀에 분산됩니다. 미리 생성된 캐시 없이 시뮬레이션 자체를 독립된 워커 간에 분산하려고 하면 프레임 간 결과가 일관되지 않을 수 있습니다.