VFX 컴포지팅 클라우드 렌더링: Comp vs 3D 차이

소개

대부분의 클라우드 렌더링 콘텐츠는 하나의 워크로드만 다룹니다. 노이즈가 사라지고 프레임이 완성될 때까지 버킷 단위로 패스 트레이서를 거치는 3D 씬입니다. 이러한 설명은 Redshift나 V-Ray 작업에는 정확하지만, Compositing(컴포지팅) 렌더에는 거의 쓸모가 없습니다. Compositing은 빛의 경로를 샘플링하지 않습니다. 이미 존재하는 푸티지와 패스를 대상으로 노드 그래프를 평가하는 작업이며, 소요 시간과 비용을 결정하는 요인은 거의 GPU 샘플 수가 아닙니다.

이 차이는 겉보기보다 훨씬 중요합니다. 일반적인 "클라우드 렌더링" 조언에서는 두 워크로드가 계속 하나로 묶여 다뤄지기 때문입니다. Nuke 스크립트나 After Effects 프로젝트를 처음으로 render farm에 올리는 compositor는 3D 렌더와 동일한 GPU 중심 동작을 기대하다가, 시뮬레이션도 ray tracing도 없는 comp가 왜 여전히 느린지, 또는 선택한 GPU 티어와 무관하게 왜 빠른지 혼란을 겪게 됩니다. 이 가이드는 바로 그 격차를 다룹니다. comp 렌더가 farm에서 실제로 어떤 일을 하는지, 3D 렌더와 메커니즘적으로 어떻게 다른지, 그리고 밤새 워크스테이션을 돌리는 대신 compositing 작업을 클라우드로 옮기는 것이 언제 가치가 있는지에 대한 내용입니다.

저희는 Super Renders Farm에서 이 파이프라인의 양쪽 모두를 매일 다루고 있습니다. 뷰티 패스와 AOV를 생성하는 3D 렌더부터 이를 최종 샷으로 조합하는 compositing 렌더까지입니다. 두 워크로드는 하드웨어를 공유하지만 렌더 동작 측면에서는 공통점이 거의 없으며, 이 차이를 이해하는 것이 comp 렌더 작업을 미스터리가 아니라 예측 가능한 것으로 만드는 핵심입니다.

3D 렌더 패스가 다중 레이어 EXR 파일로 합쳐진 뒤 compositing 소프트웨어를 거쳐 최종 그레이딩으로 이어지는 다중 패스 EXR compositing 흐름을 보여주는 파이프라인 다이어그램

Compositing은 3D 렌더링과 다른 렌더 워크로드입니다

V-Ray, Redshift, Arnold와 같은 3D 렌더러는 광선 전달(light transport)을 수행합니다. 광선을 추적하고, 머티리얼을 샘플링하며, 이미지가 수렴할 때까지 시간에 걸쳐 노이즈를 줄여 나갑니다. 이 작업은 픽셀당 실질적으로 연산량이 매우 많으며, 이 때문에 3D 렌더링은 엔진에 따라 CPU 중심이거나 GPU 중심이 되고, GPU 가속이 3D 렌더 시간에 큰 영향을 미치는 이유이기도 합니다.

Compositing 렌더는 이런 작업을 전혀 하지 않습니다. Nuke, After Effects, Fusion 등의 툴은 노드 그래프를 평가합니다. 이미지를 읽고, 색 보정을 적용하고, 두 레이어를 병합하고, 트랜스폼을 적용하고, 결과를 씁니다. 샘플링도 수렴도 없습니다. 각 연산은 결정적(deterministic)이며 대부분 선형대수 방식으로 픽셀 데이터를 처리하는 패스이며, 이러한 연산의 대다수(머지, 그레이딩, 키어, 트랜스폼, 대부분의 필터)는 GPU가 아니라 CPU에서 실행됩니다. 일부 특정 노드 유형(고사양 리타임, 일부 디노이즈 연산, 특정 머신러닝 툴)은 GPU로 가속되지만, 이는 일반적인 comp에서 예외이지 규칙이 아닙니다.

comp 렌더에 걸리는 시간을 실제로 결정하는 것은 연산 문제보다는 데이터 이동 문제에 더 가깝습니다:

읽기 처리량. comp 스크립트는 프레임마다 푸티지와 렌더 패스, 종종 여러 개의 다중 레이어 EXR 시퀀스를 한 번에 읽습니다.
CPU 스레딩. Compositing 연산은 한 프레임 내에서 CPU 코어에 걸쳐 병렬화되며, 렌더 매니저는 프레임 범위를 여러 워커에 나누어 프레임 단위로 병렬화합니다.
메모리. 여러 개의 풀 해상도, 다중 채널 프레임(뷰티 패스, 여러 AOV, Cryptomatte(크립토매트) 매트, 경우에 따라 딥 패스까지)을 한 번에 메모리에 올려 두는 것은 겉보기보다 훨씬 많은 메모리를 요구하며, 프레임 도중 RAM이 부족해지는 것은 순수 CPU 속도보다 comp 렌더 실패의 더 흔한 원인입니다.
쓰기 처리량. 최종 합성된 프레임 또는 중간 precomp는 다시 기록되어야 하며, VFX 파이프라인 결과물의 경우 이 출력은 보통 단일 비디오 파일이 아니라 또 다른 EXR 시퀀스입니다.

이는 compositing 소프트웨어를 비판하려는 것이 아닙니다. 이는 처음부터 이미지 데이터를 생성하기보다 기존 이미지 데이터를 이동하고 조합하는 데 초점을 맞춘 완전히 다른 유형의 워크로드이며, comp 작업을 3D 렌더처럼 취급해 GPU 용량은 과도하게 배정하면서 RAM과 스토리지 처리량은 아끼는 render farm은 오히려 이 작업을 가장 잘 처리해야 할 바로 그 머신에서 성능이 떨어지게 됩니다.

Comp 렌더가 실제로 읽고 쓰는 것

compositing 작업의 입력과 출력 형태는 3D 렌더링과의 차이가 가장 구체적으로 드러나는 지점입니다.

다중 레이어, 다중 패스 EXR 입력. comp는 보통 프레임마다 이미 여러 채널을 담고 있는 하나 이상의 OpenEXR 파일을 엽니다. 뷰티 렌더, 별도의 디퓨즈·스펙큘러 패스, 라이팅 AOV, Z-뎁스 패스, 모션 벡터, 그리고 오브젝트·머티리얼·에셋 ID 분리를 위한 cryptomatte 매트까지, 이 모든 것이 하나의 Read 노드로 읽어들이는 단일 파일 안에 들어 있으며 Shuffle 노드로 패스별로 분리됩니다. 이 파일을 읽는 것은 작은 파일 하나에 접근하는 것이 아니라, 주어진 comp가 그중 일부 채널만 사용하더라도 프레임이 가진 모든 채널을 끌어오는 작업입니다. 이 때문에 대부분의 EXR 데이터를 읽는 것이 아니라 쓰는 3D 렌더와 달리, comp가 많은 farm 노드에서는 스토리지 읽기 대역폭이 실질적인 병목이 됩니다.

출력이 아니라 입력으로서의 Cryptomatte. Cryptomatte 데이터(compositor가 재렌더링 없이 사후에 개별 오브젝트, 머티리얼, 에셋 인스턴스를 분리할 수 있게 해주는 절차적으로 생성된 ID 매트)는 3D 렌더에서 기록되고 comp에서 사용됩니다. 즉, compositing farm 작업은 상위 3D 렌더가 생성한 cryptomatte 채널을 그대로 물려받으며, cryptomatte 분리 기능에 크게 의존하는 comp는 그렇지 않은 comp보다 프레임당 더 많은 채널을 읽습니다. 저희의 EXR-IO와 cryptomatte 가이드에서는 이 데이터가 어떻게 구성되어 있고 어떻게 효율적으로 다루는지 다루고 있으며, cryptomatte 비중이 큰 comp를 farm으로 보내기 전에 읽어볼 가치가 있습니다.

적은 수의 고비트심도 출력. 3D 렌더가 프레임마다 여러 패스를 쓰는 경우가 많은 것과 달리, comp 렌더는 보통 이러한 패스들을 하나 또는 소수의 최종 합성 출력으로 축소합니다. 이후 VFX 파이프라인으로 넘어가는 HDR 리니어 결과물은 보통 16비트 half-float EXR로, 완전한 정밀도가 필요한 데이터 패스는 간혹 32비트로 씁니다. 쓰기 작업은 읽기보다 채널 수는 적지만 여전히 풀 해상도 프레임이며, 딥 컴포지팅(deep compositing) 작업(3D 씬을 재렌더링하지 않고 홀드아웃을 해결하기 위해 픽셀당 여러 깊이 샘플을 유지하는 작업)의 경우 읽기와 쓰기 모두 상당히 무거워집니다.

비디오 인코딩은 렌더 자체가 아니라 별도의 단계입니다. 최종 결과물이 이미지 시퀀스가 아니라 H.264나 HEVC인 경우, 이 인코딩은 일반적으로 프레임별 comp 렌더의 일부가 아니라 그 이후에 이루어지는 별도의 패스로 처리됩니다. 비디오 코덱은 독립적인 이미지 시퀀스처럼 여러 워커에 깔끔하게 나눌 수 없기 때문입니다. 저희의 H.264 대 H.265 인코딩 가이드에서 이 마지막 단계의 트레이드오프를 더 자세히 다룹니다.

6개의 렌더 패스(뷰티, 디퓨즈, 스펙큘러, cryptomatte, 뎁스, 앰비언트 오클루전)가 하나의 다중 레이어 EXR 파일로 수렴하는 다이어그램

Comp 렌더가 클라우드 Farm에 분산되는 방식

compositing 작업의 분산 모델은 3D 렌더러보다는 Nuke의 방식에 더 가까우며, 그 이유를 정확히 짚어볼 가치가 있습니다.

3D 렌더러는 하나의 프레임을 공간적으로 분할할 수 있습니다. 한 영역의 픽셀이 다른 영역의 픽셀에 실제로 의존하지 않기 때문에 버킷이나 타일 단위로 서로 다른 스레드나 머신에 나눠줄 수 있습니다. 반면 comp는 일반적으로 그런 방식으로 분할할 수 없습니다. 프레임 N에서 한 픽셀의 값은 해당 프레임의 입력이 전체 노드 트리를 통과한 결과에 좌우되기 때문에, 대부분의 compositing 작업은 이미지 영역이 아니라 프레임 단위로 매우 쉽게 병렬화할 수 있습니다. 렌더 매니저는 comp 프레임을 세분화하지 않고 프레임 범위를 세분화하여, 각 워커가 자신이 맡은 구간에 대해 compositing 애플리케이션을 헤드리스(GUI 없이)로 실행하도록 청크 단위로 나누어 줍니다.

이는 저희의 Nuke 클라우드 렌더 farm 가이드에서 Nuke에 특화해 정확한 커맨드라인 플래그와 라이선스 메커니즘까지 자세히 다루는 모델입니다. After Effects는 대부분의 프로덕션 comp(타이틀 시퀀스, 모션 그래픽, archviz 리빌)에서 비슷하게 동작하지만, 한 가지 짚고 넘어갈 유의점이 있습니다. 프레임 간 시간적 상태에 의존하는 AE 컴포지션(크로스 프레임 샘플링을 사용하는 모션 블러, 누적되는 파티클 시뮬레이션, 일부 트래킹 연산)은 깔끔하게 프레임 병렬화되지 않으며, 이를 단순하게 워커 간에 분할하면 청크 경계에서 눈에 띄는 이음매(seam)가 생길 수 있습니다. 저희의 After Effects 클라우드 렌더링 설정 가이드에서는 어떤 AE 워크플로가 깔끔하게 병렬화되고 어떤 워크플로가 단일 워커 패스를 필요로 하는지 다룹니다.

farm에서 comp 렌더 작업의 실제 형태는 다음과 같습니다. 스크립트나 프로젝트와 그것이 참조하는 모든 요소가 자체 완결형 번들로 업로드되고, 렌더 매니저가 전체 프레임 범위를 청크로 나누며, 각 워커는 자신이 맡은 청크를 가져와 아티스트의 머신에 있던 것과 동일한 푸티지 경로·컬러 설정·폰트·플러그인 의존성을 해석한 뒤 헤드리스로 렌더링합니다. 완료된 프레임은 각 청크가 끝날 때마다 공유 또는 클라우드 스토리지에 저장되므로, 긴 시퀀스라도 마지막 워커가 끝나기 훨씬 전부터 사용 가능한 결과물을 받아볼 수 있습니다.

클라우드 Compositing에서 흔히 발생하는 문제

farm에서 실패하거나 잘못된 결과가 나오는 comp 렌더의 압도적 다수는 compositing 연산 자체의 문제가 아닙니다. 로컬 워크스테이션이 조용히 가려주던 의존성과 환경 문제인 경우가 대부분입니다.

문제	원인	해결 방법
색상이 틀어짐, 렌더는 "성공"하지만 결과가 이상함	아티스트가 로컬에서 사용한 것과 다른 OCIO/컬러 설정이 farm에서 적용됨	프로젝트를 배포된 하나의 컬러 설정에 고정하고, 렌더 환경이 기본값이 아닌 정확히 그 설정을 사용하는지 확인
푸티지 누락 또는 플레이스홀더 블록	원격 워커에서는 아무 의미가 없는 절대 로컬 경로(Windows 드라이브 문자, 매핑된 네트워크 드라이브)	제출 전에 참조된 모든 미디어를 자체 완결형·네트워크 접근 가능한 번들로 수집
프레임 도중 메모리 부족 실패	여러 개의 풀 해상도 다중 채널 EXR 패스와 cryptomatte 매트가 동시에 메모리에 상주	CPU 코어 수뿐 아니라 RAM 여유를 고려해 comp 렌더 노드를 프로비저닝; 순수 연산 능력보다 더 흔한 실패 원인
청크 경계에서 눈에 띄는 이음매	시간 의존적 연산(모션 블러, 파티클 시뮬레이션, 일부 트래킹)이 프레임 독립적인 것처럼 워커 간에 분할됨	시간 의존적 comp를 식별해 프레임 범위 분산 대신 단일 워커 렌더링으로 라우팅
플러그인, 기즈모, 폰트 누락	로컬에는 설치되어 있지만 렌더 워커에는 없는 커스텀 기즈모, 서드파티 플러그인, 폰트	가능한 경우 커스텀 노드/기즈모를 스크립트에 베이크; 제출 전 farm과 플러그인·폰트 매트릭스 확인
GPU 티어 노드에서 예상보다 느림	comp가 GPU 가속 노드 서브셋이 아닌 CPU 연산인 머지, 그레이딩, 트랜스폼 위주로 구성됨	작업을 CPU 용량에 맞게 조정; GPU 노드는 실제로 GPU 가속 리타임, 디노이즈, ML 노드에 의존하는 comp에 예약

이는 특정 애플리케이션에만 국한된 문제가 아닙니다. compositing 스크립트가 원래 작성된 머신을 벗어날 때 흔히 깨지는 일반적인 패턴이며, "전체 시퀀스를 커밋하기 전에 소규모로 테스트하기"(먼저 몇 개의 프레임만 렌더링해 로컬 결과와 비교)가 어떤 farm에서 어떤 comp 렌더를 하든 저비용으로 해볼 가치가 있는 안전장치인 이유입니다.

클라우드 렌더링이 Compositing 파이프라인에 실제로 도움이 되는 경우

모든 comp에 farm이 필요한 것은 아닙니다. 로컬에서 몇 분 만에 렌더링되는 짧은 시퀀스는 클라우드로 옮기는 업로드·대기열 오버헤드에서 얻는 이점이 거의 없습니다. 클라우드 compositing이 제 값을 하는 특정 상황들이 있습니다:

마감이 임박한 급증 작업. 며칠이 아니라 몇 시간 내에 필요한 결과물로, 프레임 수와 복잡도가 마감 기한보다 더 오래 워크스테이션을 붙잡아 둘 상황입니다. 1,000프레임 시퀀스를 수십 개의 워커에 분산하면 밤새 걸리던 렌더가 1~2시간 만에 돌아올 수 있습니다. 처리량이 사용 가능한 워커 수에 거의 선형적으로 비례해 늘어나기 때문입니다.

그렇지 않으면 아티스트를 막아버릴 야간 배치 작업. 마감이 급박하지 않더라도, 아티스트의 머신을 몇 시간씩 붙잡아 두는 comp는 그 시간 동안 아티스트가 반복 작업, 리뷰, 다음 샷 작업을 할 수 없게 만듭니다. 이를 farm으로 보내면 로컬 렌더가 끝나기를 기다리지 않고 워크스테이션을 즉시 사용할 수 있습니다.

프레임당 데이터가 많은 대규모 시퀀스. 딥 컴포지팅, 4K 이상의 다중 채널 EXR, cryptomatte 비중이 큰 comp는 프레임당 렌더 시간이 가장 많이 누적되는 워크로드이며, 채널 수가 적은 가벼운 comp보다 다수의 CPU 중심 워커에 분산했을 때 얻는 이득이 훨씬 큽니다.

이미 farm을 사용 중인 3D와 comp 혼합 파이프라인. 한 샷의 3D 렌더가 이미 클라우드 farm에서 실행되고 있다면, compositing 단계도 같은 인프라에 두는 것이 두 단계 사이에 로컬 머신을 오가는 왕복을 없애고, 패스(뷰티, AOV, cryptomatte)를 comp가 읽을 위치 가까이에 유지해 줍니다.

클라우드 compositing이 가장 효과가 적은 경우는, 마감 압박 없이 소수의 짧고 단순한 comp이며 로컬 렌더 시간이 자체 완결형 프로젝트 번들을 준비하고 업로드하는 시간보다 이미 훨씬 짧은 경우입니다. 업로드와 의존성 점검 오버헤드는 실재하며, 소규모 작업에서는 절약되는 시간보다 더 클 수 있습니다.

비용: Comp 렌더 작업의 실제 비용

일반적인 comp에서 대다수의 노드는 CPU 및 메모리 중심 워크로드이기 때문에, 보통 비용을 좌우하는 것은 CPU 요금이며, GPU 요금은 실제로 GPU 가속을 사용하는 특정 노드(고사양 리타임, 일부 디노이즈, 머신러닝 툴)에만 적용됩니다.

저희 farm에서 CPU 연산은 GHz-시간 단위로 과금되며 기본 요금은 $0.004/GHz-시간입니다(대기열 우선순위에 따라 우선순위 티어는 $0.004~$0.016/GHz-시간). GPU 연산은 OctaneBench-시간(OBh) 단위로 과금되며 기본 요금은 $0.003/OBh이고, RTX 5090(32 GB VRAM) 카드는 완전 가동 시 카드당 시간당 약 $5.2입니다. Render Credit은 만료되지 않고 머신 대여 최소 사용량도 없으므로, comp 작업은 예약된 시간 블록이 아니라 실제로 소비한 연산량에 대해서만 과금됩니다.

이를 구체적인 예시로 설명하면(실제 프레임당 렌더 시간은 해상도, 채널 수, 노드 복잡도에 따라 크게 달라지므로 벤치마크 수치가 아니라 예시 계산입니다), 수십 개의 워커에 걸쳐 밤새 처리되는 수천 프레임 규모의 4K 시퀀스에서 나올 법한 정도인 총 5,000 GHz-시간의 CPU 연산을 소비하는 compositing 배치는 우선순위 티어 배수를 적용하기 전 기본 요금 기준으로 약 $20의 연산 비용이 듭니다. 같은 작업의 일부가 GPU 가속 노드에 의존한다면, 그 부분은 GHz-시간 요금이 아니라 OBh 요금으로 별도 과금됩니다. 정확한 수치는 작업마다 달라지더라도 예산을 세울 때 중요한 원리는 단순합니다. 비용은 실제 경과 시간이 아니라 소비된 총 연산량을 기준으로 하므로, 더 빨리 끝내려고 더 많은 워커에 작업을 분산한다고 해서 그 자체로 비용이 달라지지는 않습니다.

Comp 렌더링과 3D 렌더링 비교

구분	3D 렌더링	Compositing 렌더링
핵심 연산	광선 전달: 샘플링, ray tracing, 노이즈 수렴	노드 그래프 평가: 읽기, 결합, 변환, 쓰기
주요 병목	GPU 또는 CPU 연산(엔진에 따라 다름)	CPU 스레딩, 메모리 용량, 스토리지 I/O
병렬화 단위	흔히 공간(타일/버킷) + 프레임	거의 항상 프레임 단위, 이미지 영역 단위가 아님
GPU 관련성	GPU 엔진(Redshift, Octane)에서는 렌더의 핵심	특정 노드 서브셋에만 선택적으로 적용; 대부분의 연산은 CPU 전용
일반적인 입력	씬 지오메트리, 머티리얼, 텍스처	다중 레이어, 다중 패스 EXR 시퀀스(뷰티, AOV, cryptomatte)
일반적인 출력	뷰티 패스와 AOV, 프레임당 여러 파일인 경우가 많음	소수의 합성된 출력, 보통 최종 EXR 시퀀스 하나
실패 패턴	수렴/노이즈, 복잡한 씬에서의 메모리, 라이선스 경합	경로/에셋 의존성, 컬러 설정 drift, 다중 채널 읽기 시 메모리 부족

더 넓은 클라우드 렌더링 파이프라인에서 Compositing의 위치

Compositing은 보통 3D 렌더로 시작되는 체인의 마지막 단계이며, 두 단계를 하드웨어와 병목에 대해 동일한 가정으로 다루는 것이 클라우드 compositing을 처음 접하는 팀의 지원 티켓에서 가장 흔히 보이는 실수입니다. 파이프라인이 전적으로 3D 쪽이고 아직 더 넓은 서비스 모델을 정리하지 못했다면, 저희의 클라우드 render farm이란 무엇인가 가이드와 VFX 및 제품 시각화 클라우드 렌더링 가이드에서 관련 내용을 다룹니다. compositing 단계에 특화된 내용은 Nuke 클라우드 렌더링 가이드와 After Effects 클라우드 렌더링 설정 가이드에서 이 글이 의도적으로 일반적으로 남겨둔 애플리케이션별 메커니즘(라이선스, 제출 플래그, 플러그인 매트릭스)을 다룹니다. After Effects 쪽에서는 저희의 After Effects 클라우드 render farm 페이지에서 지원되는 워크플로와 가격을 직접 확인할 수 있습니다.

대부분의 VFX compositing 파이프라인의 기반이 되는 파일 포맷에 대한 표준 참고 자료로는, OpenEXR 프로젝트가 대부분의 comp 렌더가 읽고 쓰는 다중 채널·다중 파트 포맷을 문서화하고 있으며, Cryptomatte 명세가 ID 매트 데이터가 해당 파일에 어떻게 인코딩되는지 문서화하고 있습니다.

FAQ

Q: 클라우드 farm에서 compositing 렌더링은 3D 렌더링과 같은 것인가요? A: 아닙니다. 3D 렌더는 광선 전달을 수행하며, 이미지가 수렴할 때까지 광선을 샘플링하고 추적합니다. 이 작업은 픽셀당 실질적으로 연산량이 매우 많습니다. compositing 렌더는 이미 존재하는 이미지 데이터(푸티지, 렌더 패스)를 대상으로 노드 그래프를 평가하며, 샘플링보다는 CPU 스레딩, 메모리 용량, 스토리지 I/O가 지배적입니다. 두 워크로드는 farm 하드웨어를 공유하지만 병목과 실패 양상은 서로 다릅니다.

Q: Compositing은 왜 3D 렌더링보다 I/O에 더 종속적인가요? A: comp는 보통 프레임마다 하나 이상의 다중 레이어·다중 패스 EXR 파일을 읽으며, 파일이 담고 있는 모든 채널(뷰티, AOV, cryptomatte 매트, 뎁스)을 끌어오고, 노드 그래프를 평가하는 동안 이런 풀 해상도 프레임 여러 개를 동시에 메모리에 유지합니다. 이 읽기량과 합성된 프레임을 다시 쓰는 작업이 합쳐져, 일반적인 comp에서 대다수의 노드에는 순수 연산 속도보다 스토리지 처리량과 RAM 용량이 comp 렌더 시간에 더 큰 영향을 미칩니다.

Q: Compositing render farm에 GPU 노드가 필요한가요? A: 대부분의 comp에서는 필요하지 않습니다. compositing 연산의 대다수(머지, 그레이딩, 키어, 트랜스폼, 대부분의 필터)는 CPU에서 실행됩니다. 더 적은 특정 노드 유형(고사양 리타임, 일부 디노이즈 연산, 머신러닝 툴)만 GPU로 가속되며, 이런 노드에 크게 의존하는 comp는 GPU 용량의 혜택을 받습니다. 머지와 그레이딩 위주의 일반적인 comp라면 GPU 티어보다 CPU 코어와 RAM이 더 중요합니다.

Q: Cryptomatte란 무엇이며 클라우드 compositing에서 왜 중요한가요? A: Cryptomatte는 3D 렌더에서 기록되는 절차적으로 생성된 ID 매트 데이터로, compositor가 3D 씬을 재렌더링하지 않고도 사후에 개별 오브젝트, 머티리얼, 에셋 인스턴스를 분리할 수 있게 해줍니다. 클라우드 compositing 작업에서 cryptomatte 데이터는 comp 렌더가 생성하는 것이 아니라 comp가 읽어들이는 입력이며, cryptomatte 비중이 큰 comp는 프레임당 더 많은 채널을 읽어 렌더 노드의 I/O와 메모리 부하를 높입니다.

Q: Nuke와 After Effects comp를 같은 클라우드 farm에서 렌더링할 수 있나요? A: 네, 두 애플리케이션을 모두 지원하는 farm이라면 가능합니다. 다만 분산 모델은 약간 다릅니다. Nuke comp는 설계상 거의 항상 프레임 병렬적입니다(각 프레임이 완전히 독립적입니다). After Effects comp는 대부분의 프로덕션 상황에서 프레임 병렬적이지만, 특정 모션 블러나 파티클 시뮬레이션 설정처럼 프레임 간 시간적 상태에 의존하는 컴포지션은 이음매를 피하기 위해 프레임 범위 분산 대신 단일 워커 렌더링이 필요합니다. 저희의 Nuke와 After Effects 가이드에서 애플리케이션별 메커니즘을 다룹니다.

Q: compositing 작업을 로컬 대신 클라우드 farm으로 보내는 것이 언제 합리적인가요? A: 클라우드 compositing은 마감이 임박한 급증 작업, 그렇지 않으면 아티스트의 워크스테이션을 붙잡아 둘 야간 배치 작업, 그리고 규모가 크거나 프레임당 데이터가 많은 시퀀스(딥 컴포지팅, 4K 이상의 다중 채널 EXR, cryptomatte 비중이 큰 comp)에서 가장 효과적입니다. 마감 압박이 없는 소수의 짧고 단순한 comp이며 로컬 렌더 시간이 업로드용 자체 완결형 프로젝트 번들을 준비하는 시간보다 이미 짧은 경우에는 효과가 가장 적습니다.

Q: 클라우드 farm에서 compositing 렌더링은 어떻게 과금되나요? A: 저희 farm에서는 대부분의 compositing 작업 비용을 좌우하는 CPU 연산이 GHz-시간 단위로 과금되며 기본 요금은 $0.004/GHz-시간이고, 우선순위 티어는 최대 $0.016/GHz-시간까지 올라갑니다. GPU 가속 노드는 OctaneBench-시간 단위로 별도 과금되며 기본 요금은 $0.003/OBh입니다. 비용은 실제 경과 시간이 아니라 소비된 총 연산량을 기준으로 하므로, 더 빨리 끝내려고 더 많은 워커에 작업을 분산한다고 해서 그 자체로 총비용이 달라지지는 않습니다.

Q: Compositing render farm은 보통 어떤 파일 포맷을 다루나요? A: 다중 레이어·다중 파트 OpenEXR이 VFX 파이프라인 입출력의 표준이며, 뷰티 패스, AOV, cryptomatte 매트, 뎁스 데이터를 16비트 half-float(완전한 정밀도가 필요한 데이터 패스는 32비트)로 담습니다. 최종 결과물이 이미지 시퀀스가 아니라 비디오 파일(H.264, HEVC, ProRes)인 경우, 이 인코딩은 보통 프레임별 comp 렌더 이후 별도의 패스로 실행됩니다. 비디오 코덱은 일반적으로 독립적인 이미지 시퀀스처럼 워커 간에 분할할 수 없기 때문입니다. 저희의 H.264 대 H.265 가이드에서 이 마지막 인코딩 단계를 다룹니다.