Nuke 클라우드 렌더팜: 2026년 대규모 컴프 렌더링

클라우드 렌더팜에서 Nuke 컴프 렌더링하기

컴포지팅은 시각 효과 작업의 마지막 단계입니다. 시퀀스가 Nuke에 도달할 때쯤이면 3D 렌더링은 완료되고, 플레이트는 그레이딩된 상태이며, 아티스트는 머지·키·딥 홀드아웃·렌즈 작업·그레인 등으로 최종 이미지를 조립하고 있습니다. 문제는 이 '최종 이미지'를 출력하는 것이 결코 가볍지 않다는 점입니다. 멀티채널 EXR 입력과 GPU 활용 노드가 포함된 200프레임 4K 시퀀스는 단일 워크스테이션을 몇 시간 동안 점유할 수 있으며, 그동안 아티스트는 다른 작업을 할 수 없습니다. 이런 작업을 처리하기 위해 클라우드 렌더팜이 존재합니다.

저희 Super Renders Farm은 렌더 플릿 전체에서 NukeX를 운영하고 있으며, 수년간 Nuke 컴프가 렌더팜에서 깔끔하게 렌더링되는지 아니면 시퀀스 중간에 멈추는지를 결정짓는 몇 가지 반복적인 패턴을 관찰해 왔습니다. 문제는 거의 컴포지팅 연산에서 발생하지 않습니다. 누락된 기즈모, 일치하지 않는 OCIO 설정, Linux 워커에서는 아무 의미가 없는 절대 Windows 경로, 또는 어떤 Nuke 에디션이 원격에서 렌더링할 수 있는지에 대한 오해가 원인입니다. 이 가이드는 Nuke 컴프 렌더링이 렌더팜 전체에 분산되는 방식, 제출 전 이해해야 할 에디션 및 라이센스 환경, GPU 가속이 실제로 도움이 되는 경우(그리고 그렇지 않은 경우), 아무것도 누락되지 않도록 컴프를 패키징하는 방법을 안내합니다. 동일한 운영 방식은 더 광범위한 VFX 및 제품 시각화 워크플로우에도 적용되지만, Nuke에는 고유한 주의사항이 있으며 이 부분에 집중하겠습니다.

Nuke 컴프가 타일이 아닌 프레임 단위로 병렬 처리되는 이유

Nuke가 렌더팜 전체에 분산되는 방식을 이해하려면 3D 렌더러와 비교하는 것이 도움이 됩니다. V-Ray나 Arnold 같은 패스 트레이서는 단일 프레임을 버킷이나 타일로 분할하여 각 영역을 다른 스레드에, 또는 분산 렌더링의 경우 다른 머신에 할당할 수 있습니다. 좌측 상단 코너의 픽셀은 우측 하단 코너의 픽셀에 의존하지 않으므로 프레임을 공간적으로 분할할 수 있습니다.

2D 컴프는 다르게 작동합니다. N번 프레임의 픽셀 값은 오직 해당 프레임의 입력이 노드 트리를 통과한 결과에만 의존합니다. 각 프레임은 완전히 독립적이므로, Nuke 컴프는 프레임 단위로 완전히 병렬 처리됩니다. 즉, 프레임 1을 한 머신에서, 프레임 200을 다른 머신에서 동시에 렌더링할 수 있으며 상호 간의 조율이 필요하지 않습니다. Nuke는 하나의 프레임을 개별 머신으로 분산되는 공간 타일로 분할하지 않습니다 — Write 노드는 단일 프로세스에서 완전한 프레임을 렌더링합니다. 하나의 머신 내에서 Nuke는 CPU 스레드 전체에서 병렬 처리하고 스캔라인/리전 엔진을 사용하지만, 머신 간 분산 단위는 프레임입니다.

이 단일 사실이 Nuke 렌더팜 렌더링의 모든 것을 결정합니다. 렌더 매니저는 이미지를 세분화하지 않고 프레임 범위를 세분화합니다. 1,000프레임 시퀀스는 더 작은 프레임 범위 '청크' 세트가 되고, 각 청크는 워커에 할당되며, 모든 워커는 자신의 슬라이스에 대해 독자적인 헤드리스 Nuke 렌더를 실행합니다. 아래 다이어그램이 이 구조를 보여줍니다.

프레임이 독립적이기 때문에 처리량은 작업에 투입할 수 있는 워커 수에 거의 선형적으로 비례하여 증가합니다 — 이것이 클라우드에서 긴 컴프 시퀀스를 렌더링하는 것이 의미 있는 이유입니다.

헤드리스 렌더: 워커에서 Nuke가 실행되는 방식

렌더팜에는 GUI가 없습니다. 각 워커는 Nuke를 터미널(배치) 모드로 실행하여 지정된 프레임 범위에 대한 모든 활성 Write 노드를 렌더링한 후 종료합니다. 기본 명령어는 다음과 같습니다.

nuke -x -F 1-50 comp.nk

-x는 Nuke를 실행 모드로 전환합니다. -F는 프레임 범위를 설정하며, 단일 프레임(-F 7), 포함 범위(-F 1-50), 스텝 범위(-F 1-100x2는 매 두 번째 프레임을 렌더링)를 허용합니다. 비연속 범위에 대해 여러 -F 인수를 하나의 명령어에 전달할 수 있습니다. 단일 컴프에서 프로덕션 시퀀스로 넘어갈 때 몇 가지 추가 플래그가 중요합니다.

플래그	기능	렌더팜에서 중요한 이유
-x	모든 활성 Write 노드 실행(렌더)	표준 배치 렌더 스위치
-F a-bxc	선택적 스텝이 포함된 프레임 범위	렌더 매니저가 청크별로 이 값을 채워 넣음
-X node	지정된 Write 노드만 렌더링	컴프에 여러 Write가 있을 때 하나의 출력만 렌더링
--sro	Write 노드 렌더 순서 준수	다운스트림 Read가 이전 Write 출력에 의존할 때 필요
--cont	프레임 오류 후 계속 진행	손상된 프레임 하나로 전체 청크가 중단되지 않음
-m N	렌더 스레드 수 설정	워커별 동시성을 머신 코어에 맞게 조정

이 방식으로 시작된 렌더는 기본적으로 인터랙티브 시트 대신 렌더 라이센스를 요청합니다 — 다음 섹션에서 자세히 설명합니다. Nuke는 또한 렌더 매니저가 태스크 성공, 실패 또는 재시도 여부를 표시하는 데 사용하는 유용한 종료 코드를 반환합니다. 0은 성공, 1은 렌더 오류, 100은 라이센스 실패를 의미합니다. 관리형 렌더팜에서는 이 명령어를 직접 입력하는 경우가 거의 없으며, 제출 도구가 자동으로 생성합니다. 하지만 내부 동작을 이해하면 렌더 로그에서 보이는 대부분의 동작을 파악할 수 있습니다.

렌더팜 렌더링과 혼동되지 않도록 한 가지 더 언급할 배포 메커니즘이 있습니다. 바로 Nuke의 내부 Frame Server입니다. Frame Server는 여러 백그라운드 렌더 프로세스를 실행하여 단일 렌더를 가속화합니다 — 바쁜 워크스테이션이나 소규모 헬퍼 머신 그룹에 유용합니다. 이는 전체 시퀀스를 하룻밤이 아닌 긴 주말 동안 처리해야 할 때 필요한 렌더팜 규모의 프레임 범위 분산과는 다른 도구입니다.

렌더팜 렌더링을 위한 Nuke 에디션 및 라이센스

이 부분에서 가장 많은 사람이 어려움을 겪습니다. "Nuke"는 단일 제품이 아니라 제품 군이며, 에디션마다 렌더팜에서 동작이 다르기 때문입니다.

에디션	설명	렌더팜에서 렌더링 가능 여부
Nuke (Commercial)	기본 노드 기반 컴포지터	가능 — 렌더 라이센스 필요
NukeX	Nuke에 고급 노드 추가 (CameraTracker, 디노이즈, 디블러, 렌즈 왜곡, PointCloudGenerator, ParticleSystem)	가능 — 렌더 라이센스 필요
Nuke Studio	NukeX 툴셋에 편집/컨폼 타임라인 추가	가능 — 렌더 라이센스 필요
Nuke Indie	저가형 단일 아티스트 에디션	불가 — 외부 및 클라우드 렌더팜 미지원
Nuke Assist	페인트, 로토, 트래킹용 제한된 노드 서브셋	불가 — 인터랙티브 보조 시트이며 렌더 라이센스가 아님

이 표는 모든 렌더팜의 요구사항에 대한 Nuke 제품 군 전반을 설명한 것으로, 저희 플릿에만 해당되는 것이 아닙니다. 저희 렌더팜에서 렌더 측 애플리케이션은 이 가이드에서 설명하는 바와 같이 NukeX입니다. 표에서 두 가지 사항을 주목할 필요가 있습니다.

첫째, Nuke Indie는 렌더팜에서 전혀 렌더링할 수 없습니다. Foundry의 Indie 에디션은 수익 한도 이하의 1인 아티스트를 위해 설계되었으며, 그 약관은 외부 타사 렌더팜, 클라우드 렌더링 서비스, 원격 Frame Server 렌더링을 명시적으로 제외합니다. Indie는 또한 상용 파서가 읽을 수 없는 자체 암호화된 스크립트 형식으로 저장합니다. Indie를 사용하고 있는데 렌더팜 제출이 작동하지 않는 이유가 궁금하다면, 설정 문제가 아니라 라이센스 경계의 문제입니다. 렌더팜 렌더링에는 Commercial, NukeX, 또는 Nuke Studio 에디션이 필요합니다.

둘째, 렌더팜에서는 인터랙티브 시트가 아닌 렌더 라이센스로 렌더링합니다. 렌더 라이센스는 오직 렌더링만을 위한 헤드리스 GUI 없는 Nuke입니다 — 터미널 렌더를 실행하면 Nuke는 기본적으로 이를 요청합니다. 렌더 라이센스는 아티스트가 사용하는 인터랙티브 시트와 독립적이므로, 스튜디오는 50개의 완전한 인터랙티브 Nuke 시트를 구매하지 않고도 50대의 머신에서 컴프를 렌더링할 수 있습니다. 혼합 파이프라인에 유용한 세부사항: 렌더 라이센스는 NukeX 에디션 이하에서 생성된 모든 노드를 렌더링할 수 있으므로, NukeX가 탑재된 렌더 노드는 기본 Nuke에서 아티스트가 구성한 스크립트도 문제없이 렌더링합니다. NukeX는 Nuke의 상위 집합입니다 — 표준 노드를 읽는 능력을 제거하지 않고 노드를 추가합니다. 유일한 실제 제약은 반대 방향입니다. 기본 Nuke는 NukeX 전용 노드를 처리할 수 없습니다.

라이센스 모델의 경우, Foundry는 2023년 초에 Nuke 제품 군을 로그인 기반 라이센싱이 적용된 연간 구독으로 전환했으며, 온라인 또는 오프라인으로 실행할 수 있습니다. 영구 라이센스와 렌탈 옵션도 존재합니다. 세부사항은 스튜디오마다 다르며, 이것이 다음 섹션의 요점입니다.

저희 렌더팜에서의 라이센스 운영 방식

Super Renders Farm은 Foundry 파트너가 아니며, 그렇게 주장하지도 않습니다 — 저희의 검증된 벤더 파트너십은 컴포지팅 소프트웨어 벤더가 아닌 렌더 엔진 제조사와 맺고 있습니다. 저희 렌더팜이 운영하는 것은 렌더 전용 활용 모델로, 파트너십이 없는 다른 플릿 애플리케이션에도 동일하게 적용하는 방식입니다.

실제로 이는 워커별로 렌더 라이센스 시트를 직접 프로비저닝하거나 관리할 필요가 없다는 것을 의미합니다. 워커 플릿은 지원되는 빌드에 버전이 고정된 NukeX를 실행하며, 컴포지터는 헤드리스 모드로 스크립트를 렌더링합니다. SuperRenders는 풀 매니지드 렌더팜이므로, 머신에 원격 데스크톱으로 접속하거나 Nuke를 직접 설치하거나 라이센스 서버를 수동으로 구성할 필요가 없습니다 — 작업이 도착할 때 렌더 측 환경이 이미 준비되어 있습니다. 이것이 관리형 렌더팜과 IaaS 방식의 운영상 차이입니다. IaaS 방식에서는 모든 인스턴스에서 Nuke와 라이센스를 직접 설정해야 합니다.

비용 측면에서 컴프 렌더링은 나머지 CPU 작업과 동일하게 청구됩니다 — 사용한 컴퓨팅 기준 GHz-시간당 과금이며, 최소 머신 임대 기간이 없고 렌더 크레딧은 만료되지 않습니다. 신규 계정은 $25 크레딧으로 시작하며, 이는 짧은 테스트 시퀀스를 처음부터 끝까지 렌더링하고 전체 작업을 제출하기 전에 렌더팜에서 컴프가 워크스테이션과 동일하게 동작하는지 확인하기에 충분합니다. 현재 요금과 비용 계산기는 가격 페이지에서 확인할 수 있습니다.

실제 프레임 범위 분산

렌더팜이 프레임 범위를 청크로 나눈다는 것을 아는 것과, 그로부터 깔끔하고 예측 가능한 렌더를 얻는 것은 다른 문제입니다. 저희 지원 측에서 반복적으로 등장하는 몇 가지 관행이 있습니다.

청크 크기는 트레이드오프입니다. 작은 청크(프레임 수 개)는 더 많은 머신에 작업을 분산하고 실패한 태스크로부터 더 빠르게 복구하지만, Nuke의 시작 비용 — 스크립트 로드, 라이센스 체크아웃, 플러그인 초기화 — 을 더 자주 지불해야 합니다. 큰 청크는 시작 비용을 분산시키지만 하나의 느린 머신이 시퀀스의 마지막을 붙잡을 때 지연이 발생합니다. 대부분의 컴프에서는 각 워커가 몇 분 동안 바쁘게 유지되는 적당한 청크 크기가 합리적인 기본값입니다. 매우 무거운 프레임당 컴프(딥, 4K 이상, 많은 GPU 노드)는 더 작은 청크로 기울어집니다.

Write 노드 의존성에 주의하십시오. 스크립트에 이전 Write가 생성한 파일에 의존하는 다운스트림 Read가 있다면 — 예를 들어 디스크에 베이크된 프리컴프 — 해당 Write는 순서대로 실행되어야 합니다. 이것이 --sro의 용도입니다. 이 플래그 없이는 워커가 입력이 존재하기 전에 의존적인 Write를 시도할 수 있으며, 머신 타이밍에 따라 달라지기 때문에 무작위처럼 보이는 간헐적인 프레임 누락 오류가 발생합니다.

가끔 발생하는 불량 프레임을 계획하십시오. 읽을 수 없는 단일 입력이나 일시적인 스토리지 문제가 전체 청크를 중단시켜서는 안 됩니다. --cont를 사용하면 실패한 프레임 이후에도 렌더가 계속되므로, 모든 것을 다시 렌더링하는 대신 나중에 누락된 부분만 다시 큐에 넣을 수 있습니다. 이를 렌더 매니저의 자동 태스크 재시도와 함께 사용하면 장시간 시퀀스도 수동 개입 없이 진행됩니다.

이를 올바르게 처리했을 때의 이점은 명확합니다. 아티스트의 머신을 하루 종일 점유할 시퀀스가, 가장 느린 단일 청크가 렌더링되는 시간 안에 완료됩니다. 다른 모든 청크가 동시에 렌더링되기 때문입니다.

렌더팜에서 Nuke의 GPU 대 CPU 비교

GPU 우선 3D 렌더링을 경험한 사람들이 놀라는 부분이 있습니다. Nuke는 근본적으로 CPU 애플리케이션입니다. 대부분의 컴포지팅 연산 — 머지, 색보정, 트랜스폼, 키, 대부분의 필터 — 은 CPU에서 실행됩니다. Nuke의 GPU 가속은 특정 노드 서브셋에서 선택적으로 활성화되며, "사용 가능한 경우 GPU 사용" 컨트롤을 통해 노출됩니다. 이 컨트롤이 없는 노드는 CPU 전용입니다.

워크로드	실행 위치	예시
일반 컴포지팅	CPU	Merge, Grade, ColorCorrect, Transform, Keyer, 대부분의 필터
GPU 가속 노드	GPU (선택적, CPU 폴백 포함)	Kronos 및 MotionBlur 리타임, Denoise, VectorGenerator, Convolve, ZDefocus
BlinkScript / 머신 러닝	GPU	BlinkScript 커널, CopyCat 트레이닝 (NVIDIA GPU 필요)

하드웨어 관점에서, 그레이드·머지·트랜스폼 위주의 컴프는 GPU에서 거의 이점을 얻지 못하며, CPU 코어와 메모리를 필요로 합니다. 무거운 Kronos 리타임, 큰 ZDefocus, Denoise, 또는 커스텀 BlinkScript 작업에 기대는 컴프는 GPU에서 상당히 빨라질 수 있습니다. 대부분의 프로덕션 컴프는 그 중간 어딘가에 있으므로, 저희는 CPU 용량을 기본으로 하고 GPU는 실제로 사용하는 노드의 가속기로 취급합니다.

저희 플릿도 이를 반영합니다. 컴포지팅 작업의 대부분은 듀얼 Intel Xeon E5-2699 V4 프로세서와 96~256GB RAM이 탑재된 CPU 머신에서 실행됩니다 — 총 20,000개 이상의 CPU 코어 — 그리고 사람들이 과소평가하는 것은 바로 이 메모리 여유분입니다. 딥 컴포지팅과 고해상도 멀티채널 EXR 플레이트는 메모리를 많이 사용합니다. 4K에서 단일 딥 프레임은 픽셀당 많은 샘플을 보유할 수 있으며, 프레임 중간에 RAM이 부족해지는 것은 원시 CPU 속도보다 훨씬 흔한 렌더팜 렌더링 실패 원인입니다. GPU 노드로 실제 이득을 보는 컴프를 위해, 저희는 각 32GB VRAM의 NVIDIA RTX 5090 카드로 구성된 전용 GPU 클라우드 렌더팜도 운영합니다. 더 무거운 워크로드에서 해당 GPU 티어의 성능을 확인하려면 RTX 5090 클라우드 렌더링 벤치마크를 참고하십시오. 단, Nuke에 대한 솔직한 조언은 컴프에 맞게 적절히 조정하라는 것입니다. 머지 위주의 스크립트가 전혀 활용하지 않을 GPU 시간 비용을 지불하지 마십시오.

파일 및 에셋 처리: 실제로 문제가 발생하는 부분

Nuke 렌더가 렌더팜에서 실패한다면, 문제는 컴포지팅이 아니라 의존성 문제일 가능성이 압도적으로 높습니다. 컴프 스크립트는 대부분 참조들의 집합입니다 — 영상, 기즈모, 색상 설정에 대한 참조 — 그리고 이 참조들 하나하나가 아티스트의 머신이 아닌 워커에서도 동일하게 해석되어야 합니다.

의존성	실패 모드	확인 사항
영상 / Read 노드	프레임 누락, "파일을 찾을 수 없음"	네트워크에서 접근 가능하고 OS 독립적인 경로 — 아티스트 PC에만 존재하는 로컬 Z:\ 드라이브 문자 사용 금지
기즈모 / OFX 플러그인	스크립트 로드 불가, 알 수 없는 노드	모든 렌더 노드에 설치하거나, 제출 전 스크립트에 그룹/베이크 처리
OCIO 색상 설정	잘못된 색상, 불일치한 그레이드	아티스트가 사용한 것과 동일한 설정이 렌더팜에 배포되고 선택됨
폰트	Text 노드에서 대체되거나 잘못된 글리프	사용된 폰트가 렌더 노드에 존재함
LUT / .cube 파일	색상 변환 실패	컴프가 참조하는 독립 LUT 파일이 함께 전송됨
Nuke 버전	노드 비호환성	렌더 빌드가 아티스트가 사용한 빌드와 일치하거나 최신 버전

이 중 몇 가지는 더 자세히 살펴볼 필요가 있습니다. 경로는 전형적인 문제입니다. Windows에서 Z:\project\plates\를 참조하는 아티스트는 Linux 워커에서 아무 의미가 없는 스크립트를 생성합니다. 일관된 네트워크 접근 가능한 프로젝트 경로, 또는 렌더팜으로 전송될 때 경로를 재작성하는 렌더 매니저가 이를 해결합니다. 기즈모와 커스텀 OFX는 렌더 노드에 존재해야 합니다. 제출 전 가장 안전한 습관은 커스텀 기즈모를 그룹으로 변환하여 스크립트에 베이크 처리하고 외부 의존성이 없도록 하는 것입니다.

OCIO 설정 드리프트는 가장 미묘한 문제이며, 렌더가 성공하지만 색상이 잘못되는 결과를 낳기 때문에 주목할 가치가 있습니다. Nuke의 색상 관리는 OpenColorIO 설정에 의해 구동됩니다. 렌더팜이 아티스트가 사용한 것과 다른 설정을 참조한다면 — 다른 파일 경로, 배포되지 않은 커스텀 설정, 또는 다른 위치를 가리키는 환경 변수 — 색상 변환이 달라지고 렌더팜 렌더 결과가 아티스트가 승인한 뷰어와 일치하지 않습니다. 해결책은 규율입니다. 프로젝트를 특정 배포된 설정에 고정하고 렌더 환경이 정확히 그 설정을 사용하는지 확인하십시오. 관리형 렌더팜은 Nuke의 표준 번들 OCIO 설정을 기본적으로 유지하지만, 스튜디오의 커스텀 OCIO 설정은 여전히 작업과 함께 전송되어야 합니다.

출력 측면에서 Nuke 컴프는 일반적으로 멀티채널 EXR을 읽고 씁니다. 단일 OpenEXR 파일은 많은 채널을 담을 수 있습니다 — 뷰티 패스에 디퓨즈, 스페큘러, 라이팅 AOV, Z-깊이 패스, 크립토매트 매트 — 모두 하나의 Read 노드를 통해 읽고 Shuffle 노드로 패스별 컴프 작업을 위해 분리됩니다. 딥 컴포지팅을 위해 Nuke는 DeepRead와 DeepWrite를 통해 딥 EXR을 읽고 씁니다. 이는 픽셀당 여러 깊이 샘플을 저장하여 3D를 다시 렌더링하지 않고 홀드아웃 및 엣지 문제를 해결합니다. 대부분의 데이터는 HDR 선형 플레이트의 표준인 16비트 반정밀도 부동소수점으로 저장되며, 전체 정밀도가 필요한 월드 좌표나 모션 벡터 같은 데이터 패스에는 32비트 단정밀도 부동소수점이 예약됩니다. 이 중 특이한 것은 없지만, 각 채널은 이동해야 할 더 많은 데이터이고 보유해야 할 더 많은 메모리입니다. 이는 컴프 렌더링에서 코어 수만큼이나 RAM과 스토리지 처리량이 중요한 이유로 직접 이어집니다.

Nuke 컴프 제출 전 체크리스트

어떤 렌더팜에 컴프를 전송하기 전에 — 저희 팜이든 사내 큐든 — 다음 항목들을 빠르게 점검하면 실패 렌더의 대부분을 방지할 수 있습니다.

• 경로: 모든 Read 및 Write 노드가 네트워크 접근 가능하고 OS 독립적인 경로를 사용하며, 로컬 드라이브 문자를 사용하지 않습니다.
• 기즈모: 커스텀 기즈모는 그룹으로 변환(베이크)되거나 렌더 노드에 설치된 것이 확인됩니다.
• 색상: OCIO 설정이 렌더팜이 참조할 설정과 동일합니다. 커스텀 설정은 작업과 함께 전송됩니다.
• 폰트와 LUT: Text 노드에서 사용된 모든 폰트와 참조된 모든 .cube/LUT 파일이 존재합니다.
• 버전: 렌더 빌드가 컴프가 생성된 빌드와 일치합니다.
• 에디션: 스크립트가 Commercial Nuke, NukeX, 또는 Nuke Studio에서 생성되었으며, 렌더팜 렌더링이 불가한 Indie가 아닙니다.
• 렌더 순서: 다운스트림 Read가 이전 Write에 의존하는 경우 --sro로 렌더링합니다.
• 소규모 테스트: 전체 범위를 제출하기 전에 먼저 몇 프레임을 렌더링하고 아티스트의 로컬 출력과 비교합니다.

마지막 항목은 저렴한 보험입니다. 5프레임 테스트 렌더는 몇 분의 비용으로 경로, 색상 또는 버전 불일치를 잡아냅니다 — 야간 작업 800프레임 진행 후에 발견하는 것보다 훨씬 낫습니다.

더 넓은 파이프라인에서 Nuke 렌더링의 위치

최종 프레임 EXR 출력은 Nuke 컴프의 가장 일반적인 종점이지만, 유일한 것은 아닙니다. 샷이 플랫 렌더 시퀀스가 아니라 실시간 엔진으로 향한다면 — 버추얼 프로덕션 또는 인엔진 리뷰 — 통합 관련 질문이 달라지며, 저희는 이 경로를 Nuke to Unreal Engine 파이프라인 가이드에서 별도로 다룹니다. 명확히 구분하십시오. 이 글은 렌더팜에서 대규모로 컴프 프레임을 렌더링하는 것에 관한 것이고, Unreal 경로는 Nuke 작업을 실시간 컨텍스트로 이동하는 것에 관한 것입니다. 분산 렌더링이 일반적으로 어떻게 작동하는지 파악 중이라면, 렌더팜이란 무엇인가 가이드가 좋은 출발점입니다.

여기서 설명된 메커니즘에 대한 권위 있는 참조로, Foundry의 커맨드라인 운영 및 렌더팜 공식 문서와 Nuke 제품 군 라이센스 FAQ, 그리고 OpenEXR 및 OpenColorIO 프로젝트 사이트가 컴프가 의존하는 파일 및 색상 표준을 문서화하고 있습니다.

FAQ

Q: Nuke Indie 라이센스로 클라우드 렌더팜에서 Nuke를 렌더링할 수 있습니까? A: 아닙니다. Foundry의 Nuke Indie 에디션은 외부 타사 렌더팜, 클라우드 렌더링 서비스, 원격 Frame Server 렌더링을 명시적으로 지원하지 않으며, 상용 파서가 읽을 수 없는 암호화된 스크립트 형식으로 저장합니다. 렌더팜 렌더링에는 Commercial Nuke, NukeX, 또는 Nuke Studio 에디션이 필요합니다.

Q: 클라우드 렌더팜을 사용하려면 별도의 Nuke 렌더 라이센스가 필요합니까? A: 렌더팜에서 렌더는 인터랙티브 시트 대신 렌더 라이센스를 사용하여 헤드리스로 실행됩니다 — 스튜디오가 각 머신에 대해 완전한 인터랙티브 시트를 구매하지 않고도 많은 머신에서 렌더링할 수 있는 이유입니다. 저희 렌더팜에서는 직접 이를 프로비저닝할 필요가 없습니다. 워커 플릿은 렌더 전용 활용 모델하에서 NukeX를 실행하므로, 렌더 측 라이센스는 렌더팜 측에서 처리됩니다.

Q: Nuke 렌더링은 GPU와 CPU 중 어느 것이 더 빠릅니까? A: 대부분의 컴프에서는 CPU입니다. Nuke는 근본적으로 CPU 애플리케이션이며, Kronos, Denoise, ZDefocus, Convolve, BlinkScript, CopyCat 같은 머신 러닝 도구 등 특정 노드 서브셋만 GPU 가속을 지원합니다. 머지, 그레이드, 트랜스폼 위주의 컴프는 CPU 코어와 RAM을 필요로 하고, 이런 무거운 노드에 기대는 컴프는 GPU에서 이점을 얻습니다.

Q: 렌더팜은 Nuke 컴프를 어떻게 여러 머신에 분산합니까? A: 이미지 영역이 아닌 프레임 범위 단위로 분산합니다. 컴프의 각 프레임은 독립적이므로, 렌더 매니저는 전체 프레임 범위를 청크로 나누고 각 청크를 워커에 할당하며, 워커는 자신의 슬라이스를 헤드리스로 렌더링합니다. 처리량은 작업에 투입된 워커 수에 거의 선형적으로 비례합니다.

Q: 렌더팜에서 Nuke 컴프가 잘못된 색상으로 렌더링되는 이유는 무엇입니까? A: 가장 흔한 원인은 OCIO 설정 드리프트입니다 — 렌더팜이 다른 파일 경로, 환경 변수, 또는 렌더 노드에 배포되지 않은 커스텀 설정을 통해 아티스트가 사용한 것과 다른 OpenColorIO 설정을 참조했기 때문입니다. 프로젝트를 특정 설정에 고정하고 렌더 환경이 정확히 그 설정을 사용하는지 확인하십시오.

Q: Nuke 스크립트를 원격으로 렌더링하려면 어떤 파일을 함께 전송해야 합니까? A: 스크립트와 그것이 참조하는 모든 것입니다. 영상 및 이미지 시퀀스, 커스텀 기즈모 또는 OFX 플러그인(또는 그룹으로 베이크), OCIO 색상 설정, Text 노드에서 사용된 폰트, 독립 LUT 파일. 렌더 빌드도 컴프가 생성된 버전과 일치해야 합니다.

Q: NukeX는 표준 Nuke 컴프를 렌더링합니까? A: 그렇습니다. NukeX는 기본 Nuke의 상위 집합입니다 — 표준 노드를 읽는 능력을 제거하지 않고 노드를 추가하므로, NukeX 렌더 노드는 기본 Nuke에서 구성된 스크립트도 문제없이 렌더링합니다. 렌더 라이센스는 NukeX 에디션 이하에서 생성된 모든 노드를 렌더링할 수 있습니다. 유일한 제약은 반대 방향입니다. 기본 Nuke는 NukeX 전용 노드를 처리할 수 없습니다.

Q: Super Renders Farm에서 Nuke 컴프 렌더링 비용은 얼마입니까? A: 컴프 렌더링은 사용한 CPU 컴퓨팅 기준 GHz-시간당 과금이며, 최소 머신 임대 기간이 없고 렌더 크레딧은 만료되지 않습니다. 신규 계정은 $25 크레딧을 받으며, 이는 짧은 테스트 시퀀스를 처음부터 끝까지 처리하기에 충분합니다. 현재 요금과 비용 계산기는 가격 페이지에서 확인하십시오.