헤드리스 렌더링·무인 렌더팜 워크플로 (2026)

Q: 헤드리스 렌더링이란 무엇인가요?

헤드리스 렌더링은 그래픽 인터페이스를 열지 않고 명령줄에서 렌더를 실행하는 것을 뜻하며, 예를 들어 blender -b scene.blend -a나 nuke -x script.nk가 있습니다. 모든 렌더팜 노드가 이 방식으로 동작하고, 아티스트도 업로드 전에 씬을 테스트하려고 로컬에서 같은 진입점을 사용합니다.

Q: 업로드 전에 씬을 테스트하려면 Blender를 명령줄에서 어떻게 렌더링하나요?

백그라운드 모드를 사용합니다. 예를 들어 테스트 프레임 하나는 blender -b scene.blend -E CYCLES -f 1로 렌더링합니다. -b 플래그는 GUI 없이 실행하고 -E는 엔진을 선택하며, 저희 렌더팜은 Cycles와 EEVEE를 모두 렌더링합니다. --python-exit-code와 함께 실행하는 작은 bpy 스크립트로 같은 패스에서 절대 경로나 누락된 경로를 보고할 수도 있습니다.

Q: 무인 밤샘 렌더를 예약할 수 있나요?

여러분 쪽 작업은 예약할 수 있습니다. cron이나 작업 스케줄러(Task Scheduler)로 실행하는 사전 점검, 통과한 각 프로젝트를 SRF Space에 올리는 AWS CLI 업로드, Client App이 내려받는 프레임을 처리하는 감시 스크립트가 그것입니다. 제출은 웹 대시보드, Client App 또는 DCC 플러그인에서 이루어지므로, 사람이 짧은 핸드오프를 한 번 수행합니다.

소개

자동화된 렌더 파이프라인의 목표는 아무도 하고 싶어 하지 않는 일을 통해 설명하는 것이 가장 쉽습니다. 새벽 2시에 워크스테이션 앞에 앉아 프레임 큐를 지켜보는 일입니다. 테크니컬 디렉터는 500프레임짜리 시퀀스를 큐에 넣고 퇴근하며, 다음 날 아침 완성된 프레임이 로컬 스토리지에 있기를 바랍니다. 이 바람에는 쉽게 혼동되는 두 부분이 있습니다. 바로 헤드리스(headless) 렌더링과 무인(unattended) 워크플로입니다.

헤드리스 렌더링은 그래픽 인터페이스를 열지 않고 명령줄에서 렌더를 구동하는 것을 뜻합니다. 무인이란 루프(씬을 렌더팜으로 보내고, 렌더링하고, 결과물을 되가져오는 과정) 전체가 사람이 지켜보지 않아도 돌아가는 것을 뜻합니다. 둘 중 하나만 갖출 수도 있습니다. 이 가이드는 두 개념을 구분한 다음, 풀 매니지드 클라우드 렌더팜을 중심으로 오늘날 무인 루프를 어디까지 구축할 수 있는지 차근차근 살펴봅니다.

저희는 2010년부터 분산 렌더링을 운영해 왔으며, 저희가 받는 파이프라인 관련 문의 중 상당수는 공개 제출 API가 있다고 가정합니다. 저희 렌더팜에는 공개 제출 API가 없으며, 이 점을 정확히 밝혀 둡니다. 존재하지 않는 기능 위에 만든 워크플로는 첫 밤샘 실행에서 무너지기 때문입니다. 실제로 있는 기능은 사람들이 예상하는 것보다 많습니다. 준비 작업은 여러분 쪽 연결 구간에 있고, 업로드는 SRF Space에 대한 S3 access를 통해 AWS CLI로 스크립트화할 수 있습니다.

헤드리스 렌더링이란 정확히 무엇인가

헤드리스 렌더링은 단일 렌더 호출의 속성입니다. 렌더러가 애플리케이션의 사용자 인터페이스를 열지 않고 실행됩니다. 주요 3D 및 컴포지팅 애플리케이션은 모두 이를 위한 명령줄 진입점을 제공하며, 랙에 들어 있는 머신에는 모니터가 연결되어 있지 않으므로 모든 렌더팜 노드가 이를 사용합니다.

아래는 저희가 지원하는 애플리케이션별 대표 호출 형식입니다. 이 명령은 로컬 준비와 검증을 위해 여러분의 머신에서 실행하며, 매니지드 렌더팜에서는 렌더팜이 자체 노드에서 동등한 명령을 대신 호출합니다.

애플리케이션	명령줄 도구	대표 호출	참고
Blender	`blender -b`	`blender -b scene.blend -E CYCLES -o //out/fr_ -s 1 -e 250 -a`	`-b` = 백그라운드, GUI 없음. `-a`는 범위를 렌더링하고 `-f N`은 단일 프레임을 렌더링합니다. `-E`는 엔진을 선택하며, 저희 렌더팜은 Cycles와 EEVEE를 모두 렌더링합니다.
Maya	`Render`	`Render -r arnold -s 1 -e 100 -rd /out/ -of exr scene.ma`	`-r`은 렌더러를 선택합니다(`arnold`, `vray` 등). 의도한 카메라가 렌더링되도록 `-cam`을 지정합니다.
3ds Max	`3dsmaxcmd.exe`	`3dsmaxcmd.exe -frames:1-100 -outputName:"D:\out\fr_.exr" scene.max`	콜론 `key:value` 문법을 사용하며, 조용한 실행을 위해 `-showRFW:0`을 추가합니다.
Cinema 4D	`Commandline.exe`	`Commandline.exe -render scene.c4d -frame 1 100 -oimage D:\out\fr_`	`-frame`은 공백으로 구분된 시작 프레임과 끝 프레임을 받으며, 프레임 번호는 `-oimage` 이름 뒤에 붙습니다.
Houdini	`hbatch` / `husk`	`husk --engine cpu --frame 1 --frame-count 100 -o '/out/fr_$F4.exr' scene.usd`	`hbatch`는 HIP 파일의 ROP를 구동하고, `husk`는 Karma로 USD 스테이지를 렌더링합니다(`--engine`으로 CPU 또는 XPU 선택). `$F4`는 프레임 번호에 0을 채워 자릿수를 맞춥니다.
After Effects	`aerender`	`aerender -project x.aep -comp "Main" -s 1 -e 100 -OMtemplate "EXR Sequence" -output /out/fr_[####].exr`	`-comp`는 컴포지션 이름과 정확히 일치해야 하며, `-OMtemplate`은 저장된 출력 모듈 템플릿 이름을 지정합니다(여기에 쓴 이름은 예시). `[####]`는 시퀀스에 번호를 붙입니다.
NukeX	`nuke -x`	`nuke -x -F 1-100 script.nk`	`-x`는 스크립트를 헤드리스로 실행한다는 뜻입니다(NukeX를 의미하지 않음). `-F`는 `1-100` 또는 간격을 둔 `1-100x2`를 받습니다. 사용 중인 라이센스 에디션이 명령줄 렌더링을 허용하는지 확인하세요.

벤더 문서에는 버전별 정확한 플래그가 정리되어 있으므로 북마크해 둘 만합니다. 저희가 가장 자주 안내하는 두 곳은 Blender 명령줄 렌더링 매뉴얼과 SideFX husk 레퍼런스입니다.

헤드리스와 무인은 서로 다른 문제입니다

이 구분은 분명히 해 두는 편이 좋습니다. 헤드리스는 렌더가 어떻게 실행되는가, 즉 GUI 없이 실행된다는 뜻입니다. 무인은 워크플로 전체에서 사람이 자리에 있어야 하는가를 뜻합니다. 둘은 겹치지만 같은 축이 아닙니다.

인터페이스 유형과 사람의 개입 정도를 기준으로 헤드리스 렌더링과 무인 렌더링을 비교한 사분면 도표 헤드리스(렌더가 어떻게 실행되는가)와 무인(사람이 자리에 있는가)은 서로 독립된 축입니다. 자동화가 겨냥하는 곳은 오른쪽 위 구석이며, 이 가이드의 나머지 부분에서는 매니지드 렌더팜 워크플로가 오늘날 그곳에 얼마나 가까이 갈 수 있는지를 다룹니다.

렌더가 헤드리스이면서 유인일 수도 있습니다. 터미널에서 nuke -x를 실행하고 프레임이 하나씩 쌓이는 것을 지켜보다가, 12번 프레임에서 오류가 나면 바로 중단하는 경우가 그렇습니다. 반대로 GUI 도구를 쓰면서도 느린 부분을 백그라운드에서 돌려 대체로 무인으로 운영하는 워크플로도 가능합니다. 파이프라인 자동화의 목표는 무인 쪽입니다.

렌더팜에서는 상황이 달라집니다. 헤드리스 렌더링이 원래 해결하려고 만들어진 문제, 즉 화면이 없는 머신에서 렌더를 실행하는 일을 렌더팜이 이미 맡고 있기 때문입니다.

매니지드 렌더팜이 헤드리스 문제를 바꾸는 이유

클라우드 렌더링에는 크게 두 가지 형태가 있습니다. 인프라 대여 모델에서는 머신을 빌리고 여러분이 렌더 관리자(render wrangler) 역할을 합니다. 풀 매니지드 모델에서는 렌더팜이 머신을 운영하고 여러분은 씬을 넘깁니다. "헤드리스"라는 말은 두 모델에서 의미가 다릅니다.

책임	인프라 대여(직접 관리)	풀 매니지드 렌더팜
머신 프로비저닝	여러분이 노드별로 수행	렌더팜
노드별 DCC 및 플러그인 설치	여러분이 모든 노드에서 수행	렌더팜
렌더 엔진 라이센스 관리	여러분: 라이센스 서버, 체크아웃	렌더팜(요금에 포함)
노드별 헤드리스 렌더 실행	여러분: 노드 전반에 걸쳐 `Render`, `blender -b` 등을 스크립트화	렌더팜
프레임 분배 및 실패 재시도	여러분: 오케스트레이션은 여러분의 코드	렌더팜
준비, 업로드, 제출, 결과물 수집	여러분	여러분: 파일은 웹, Client App 또는 S3 access로, 작업은 웹 대시보드, Client App 또는 DCC 플러그인으로

매니지드 클라우드 렌더팜에 연결된 스튜디오 워크스테이션. 렌더 노드는 렌더팜 쪽에서 운영됨 매니지드 렌더팜에서 노드는 렌더팜의 몫이며, 스튜디오 쪽은 깨끗한 프로젝트를 올리고 프레임을 받아 오는 일을 맡습니다.

자체 관리 모델에서 "헤드리스"는 노드 오케스트레이션을 뜻하며, 여러분이 작성하는 자동화가 곧 렌더 관리 계층 전체입니다. 풀 매니지드 렌더팜에서는 그 계층을 맡을 필요가 없습니다. 저희 CPU 쪽은 20,000개 이상의 CPU 코어에서 V-Ray, Corona, Arnold 같은 엔진을 실행하고, GPU 쪽은 Redshift, Octane, V-Ray GPU를 위해 NVIDIA RTX 5090 카드(VRAM 32 GB)를 운영하며, 이 모든 것이 내부에서 오케스트레이션됩니다. 따라서 노드를 직접 구동할 일이 전혀 없습니다. 남는 것은 렌더팜 주변의 루프이고, 그 대부분은 여러분 자신의 머신에서 실행됩니다.

엔드 투 엔드 스크립트 제출이 오늘 당장 필수 요건이라면, 머신 대여와 자체 자동화 운영이 솔직한 선택지입니다. 저희의 전용 렌더 서버를 포함해 대여 머신에는 DCC 스택이 설치되어 있으며, 그 위에서 여러분의 자동화와 전송 도구를 직접 실행합니다.

매니지드 렌더팜의 루프, 단계별로

전체 루프를 각 단계에 대한 솔직한 표시와 함께 정리하면 다음과 같습니다.

준비, 패키징, 업로드는 스크립트화 가능, 제출은 수동, 렌더링은 렌더팜에서, 결과물 수집은 스크립트화 가능한 6단계 렌더 루프 매니지드 렌더팜의 루프: 준비, 패키징, 업로드(S3 access 이용)는 스크립트화할 수 있고, 제출은 수동으로 남으며, 렌더팜이 렌더링하고, 결과물 수집은 다시 스크립트화할 수 있습니다.

1. 헤드리스 준비 및 사전 점검(여러분 쪽, 완전히 스크립트화 가능). 테스트 프레임 하나를 로컬에서 헤드리스 모드로 렌더링합니다(blender -b scene.blend -f 1, nuke -x -F 1 script.nk). 로컬에서 1번 프레임이 실패하면 렌더팜 작업의 모든 프레임에서도 실패합니다. 그다음 모든 외부 참조를 점검합니다. Blender의 Report Missing Files, 3ds Max의 Asset Tracking, Maya의 File Path Editor, Houdini의 hou.fileReferences()가 그 도구입니다. 씬 파일에 대한 상대 경로(Blender의 //, Houdini의 $HIP/, Maya 프로젝트의 sourceimages/)는 어떤 노드로 옮겨져도 유지됩니다. 프로젝트가 절대 경로에 의존한다면(일부 스캐터, 크라우드, 캐시 플러그인은 내부에 절대 경로를 저장합니다), Client App의 Auto keep local path 옵션이 클라우드 스토리지에 로컬 폴더 구조를 그대로 재현해 이 경로가 계속 유효하도록 합니다.

2. 프로젝트 패키징(여러분 쪽, 완전히 스크립트화 가능). 씬과 종속 파일을 하나의 프로젝트 폴더로 모으고 압축하지 않은 상태로 유지합니다. 렌더팜은 아카이브(.zip, .rar, .7z, .tar, .tar.gz)를 풀지 않으므로, 아카이브 안에 든 것은 렌더링되지 않습니다. 3ds Max 사용자는 렌더팜용 3ds Max 파일 패키징 안내를 따라 하면 됩니다.

3. 업로드(S3 access로 스크립트화 가능). 경로는 세 가지입니다. 웹 업로드에는 명확한 크기 상한이 없지만, 일반 가정용 회선에서는 브라우저 업로드 한 건이 약 2 GB를 넘으면 느려지고 약 5 GB를 넘으면 불안정해지며, 탭을 닫으면 중단됩니다. SuperRenders Client App은 청크를 병렬로 업로드하고, 연결이 끊기면 마지막으로 완료된 청크부터 이어서 올리며, Windows에서는 메인 창을 닫아도 백그라운드 서비스가 전송을 계속합니다. S3 access(계정의 Cloud Direct Connect)는 스크립트로 다룰 수 있는 경로입니다. 그곳에서 액세스 키를 생성하면 AWS CLI 또는 Cyberduck(프로토콜: Amazon S3)으로 SRF Space와 파일을 주고받을 수 있으므로, 아무도 자리에 없어도 예약된 작업에서 업로드를 실행할 수 있습니다.

4. Scene Analysis 및 제출(수동). 파일 업로드가 끝나면 Scene Analysis가 크레딧이 청구되기 전에 프로젝트가 렌더링될 수 있는지 점검합니다. 이후 웹 대시보드, Client App(Start Render Job: 프레임 범위, 출력 형식, Normal 또는 Express 우선순위), 또는 3ds Max, Maya, Cinema 4D 안의 제출 플러그인에서 작업을 시작합니다. 플러그인은 제출 전 에셋 점검을 실행하고 열려 있는 씬을 패키징합니다. S3 access는 파일만 옮깁니다. 빌드 스크립트에서 호출할 수 있는 공개 API, SDK, 명령줄 제출 도구는 없습니다. 파이프라인이 그런 도구를 전제로 설계되어 있다면, 바로 이 지점을 우회해서 설계해야 합니다.

5. 렌더링 및 모니터링(렌더팜의 몫, 여러분은 지켜보기). Client App의 Render Jobs 패널이나 웹 대시보드에서 진행 상황을 확인합니다. Client App은 제출, 완료, 주요 진행 시점, 오류가 발생할 때 알림을 보낼 수 있습니다. 사람이 보는 화면이며, 스크립트가 폴링할 수 있는 상태 피드는 아닙니다.

6. 결과물 수집(Client App으로 무인 처리). 기본적으로 Client App은 각 프레임의 렌더링이 끝나는 즉시 기본 폴더 또는 제출 시 지정한 작업별 폴더로 내려받으므로, 작업이 완료될 때 프레임은 이미 디스크에 있습니다. 작업 도중 다운로드 경로가 사라지면(외장 드라이브를 뽑은 경우가 흔한 원인입니다) 쓰기 가능한 폴더로 경로를 다시 지정하고 Sync output을 사용하세요. 웹 다운로드도 가능합니다. 파일은 고정된 자동 삭제 기간 없이 계속 다운로드할 수 있고 요청 시 삭제되지만, 렌더팜은 아카이브가 아니라 렌더 서비스로 취급하시기 바랍니다.

스크립트를 넣을 곳은 1단계에서 3단계까지, 그리고 6단계 이후의 모든 작업입니다.

스튜디오 쪽 자동화: 사전 점검, 패키징, 업로드

밤샘 실행 실패의 대부분은 입력에서 비롯되므로, 가장 가치 있는 자동화는 업로드가 시작되기 전에 실행되는 게이트입니다. 씬 파일이 있는지 확인하고, 아카이브와 불필요한 파일에 표시를 하고, 체크섬 매니페스트를 작성합니다. 저희의 동반 가이드인 렌더팜 업로드의 스튜디오 쪽 자동화에서는 바로 이 작업을 하는 의존성 없는 Python 스크립트를 단계별로 설명합니다.

여기에 DCC 쪽에서 헤드리스로 실행되는 점검을 함께 두세요. Blender의 경우 bpy 몇 줄이면 절대 경로이거나 누락된 외부 경로를 모두 보고하며, --python-exit-code는 실패를 래퍼 스크립트가 처리할 수 있는 0이 아닌 종료 코드로 바꿔 줍니다.

# check_paths.py
# run: blender -b scene.blend --python-exit-code 2 --python check_paths.py
import os
import bpy

absolute = [p for p in bpy.utils.blend_paths(absolute=False) if not p.startswith("//")]
missing = [p for p in bpy.utils.blend_paths(absolute=True) if not os.path.exists(p)]
for p in absolute:
    print("ABSOLUTE:", p)
for p in missing:
    print("MISSING:", p)
if absolute or missing:
    raise RuntimeError(f"{len(absolute)} absolute, {len(missing)} missing paths")

다른 도구에서도 같은 패턴이 통합니다. hython에서 hou.fileReferences(), mayapy에서 filePathEditor 쿼리, 3ds Max에서 에셋 트래킹을 훑는 MAXScript가 그 예입니다. DCC 점검과 폴더 점검을 하나의 셸 스크립트로 묶으면, 프로젝트가 준비되었다고 통과시키거나 준비되지 않은 이유를 정확히 알려 주는 게이트가 완성됩니다.

게이트를 통과하면 같은 스크립트가 업로드까지 시작할 수 있습니다. Cloud Direct Connect에서 받은 Access Key ID와 Secret Access Key, 리전 ap-southeast-1로 aws configure를 한 번 실행한 다음, 스크립트가 aws s3 cp에 --recursive를 붙여 압축하지 않은 프로젝트 폴더를 Remote Directory로 복사하게 합니다. 게이트가 정상 종료할 때만 업로드하면 깨진 프로젝트가 네트워크 밖으로 나가지 않습니다. 스크립팅 세부 사항은 같은 동반 가이드에서 다룹니다.

반환 경로 자동화: 다운로드 폴더 감시

Client App의 자동 다운로드가 전송을 맡으면, 프레임은 제출 시 지정한 로컬 폴더에 도착합니다. 그 이후는 일반적인 로컬 자동화입니다. 예상한 프레임 범위가 모두 모이고 각 파일의 크기가 더 이상 변하지 않을 때까지 폴더를 감시한 다음, 인코딩, 리뷰용 업로드, 아카이브 복사를 실행합니다. 동반 가이드에는 바로 이 단계를 위한 감시 스크립트가 들어 있습니다.

작업이 프레임당 여러 패스를 기록한다면 패스 이름 하나만 골라 세어서 각 프레임이 한 번씩만 집계되게 하세요. "크기가 안정되었는지" 확인하는 것도 중요합니다. 아직 기록 중인 프레임은 이름은 맞아도 바이트는 아직 맞지 않기 때문입니다.

예약할 수 있는 것을 예약하기

매니지드 렌더팜의 밤샘 실행은 스케줄러로 감싼 로컬 작업과 스크립트 업로드로 이루어지며, 중간에 수동 단계가 하나 있습니다.

핸드오프 이전: 타이머로 cron(macOS, Linux) 또는 작업 스케줄러(Task Scheduler, Windows)를 사용해 "제출 준비 완료" 폴더에 대해 사전 점검 게이트를 실행하고, 통과한 각 프로젝트를 AWS CLI로 SRF Space에 업로드합니다.
핸드오프: 사람이 업로드된 프로젝트를 제출합니다. 1분이면 끝나지만, 오늘 기준으로 스크립트화할 수 없는 유일한 단계입니다.
핸드오프 이후: Client App을 계속 실행해 두고(Windows에서는 Run on Windows startup을 켜 두면 재부팅 후에도 백그라운드 서비스가 유지됩니다), 해당 작업의 다운로드 폴더에 감시 스크립트를 시작합니다.

# minute hour day month weekday  command
0 1 * * 1-5 /studio/bin/preflight-and-upload.sh >> "$HOME/render-preflight.log" 2>&1

여기서 preflight-and-upload.sh는 여러분이 직접 작성하는 래퍼입니다. 게이트를 실행하고, 통과한 프로젝트에 대해서만 aws s3 cp를 호출합니다. 무인 작업에서 2>&1 리디렉션은 선택이 아닙니다. 오류를 로그에 남겨 주며, 이것이 없으면 아무도 지켜보지 않는 사이 점검이나 업로드가 실패해도 조용히 지나갑니다.

오늘 자동화할 수 있는 것과 없는 것

기준으로 삼을 수 있도록 분명히 말씀드립니다. Super Renders Farm은 현재 공개 REST API, SDK, 명령줄 작업 제출 도구를 제공하지 않습니다. 폴링할 상태 엔드포인트도, 렌더 완료 시 호출되는 웹훅도 없습니다. 저희는 매니지드 렌더팜에서도, 대여 머신에서도 SFTP나 FTP를 제공하지 않습니다. 이 글의 이전 버전에는 실제로는 존재하지 않는 스크립트 가능한 SFTP 경로가 소개되어 있었습니다.

스크립트로 다룰 수 있는 전송 경로는 S3 access입니다. Cloud Direct Connect에서 발급한 액세스 키를 AWS CLI 또는 Cyberduck과 함께 사용해 SRF Space와 파일을 주고받습니다.

단계	오늘 자동화할 수 있나요?	방법
로컬 테스트 렌더 및 경로 점검	예	여러분의 머신에서 실행하는 헤드리스 DCC(`blender -b`, `hython`, `mayapy`, `nuke -x`)
패키징 및 체크섬 매니페스트	예	로컬 스크립트, 프로젝트 폴더는 압축하지 않은 상태로 유지
업로드	예, S3 access 사용 시	스크립트나 예약 작업에서 AWS CLI 사용. 수동 시작에는 Client App(이어 올리기, 백그라운드 서비스)과 웹 업로드
Scene Analysis 및 제출	아니요, 수동	웹 대시보드, Client App, 또는 3ds Max, Maya, Cinema 4D용 플러그인
진행 상황	지켜보기만 가능, 폴링 불가	Client App Render Jobs 패널, 웹 대시보드, Client App 알림
다운로드	예, 무인 처리	작업별 폴더로의 Client App 자동 다운로드
렌더 후 작업	예	다운로드 폴더에 대한 로컬 감시 스크립트, 이후 인코딩, 리뷰, 아카이브 스크립트

프로그래밍 방식 제출은 저희 로드맵에 있으며 현재는 제공되지 않습니다. 파이프라인에 필수 요건이라면 어떤 호출을 어느 시점에 사용하고 싶은지 저희 지원팀에 알려 주세요. 그 의견이 로드맵을 만드는 데 반영됩니다.

자체 노드를 운영하는 방식과 비교해 보고 계신다면, 풀 매니지드 모델과 매니지드 방식과 직접 구축 방식의 장단점을 다룬 글을 참고하세요. 시작 가이드에서는 업로드, 제출, 다운로드를 스크린샷으로 안내하고, 애플리케이션별 안내는 Blender 및 Houdini 클라우드 렌더팜 페이지에 있으며, 요금 페이지에서는 크레딧 모델을 설명합니다.

무인 렌더 워크플로의 흔한 함정

아래는 저희 지원팀이 가장 자주 접하는 원인입니다.

증상	원인	해결 방법
로컬에서는 괜찮은데 렌더팜에서는 텍스처가 분홍색 또는 검은색으로 렌더링됨	노드에 존재하지 않는 절대 에셋 경로(`D:\...`)	씬 기준 상대 경로(`//`, `$HIP/`, 프로젝트 `sourceimages/`)를 사용하거나 Client App의 Auto keep local path로 업로드
작업이 씬을 찾지 못하거나 아무것도 렌더링되지 않음	프로젝트를 아카이브로 업로드했거나 하위 폴더만 업로드함	참조하는 모든 에셋이 제자리에 있는 전체 프로젝트 폴더를 압축하지 않은 상태로 업로드
아침에 확인하니 업로드가 60%에서 멈춰 있음	웹 업로드 중 브라우저 탭이 닫혔거나 머신이 절전 모드로 들어감	마지막 청크부터 이어 올리는 Client App, 또는 S3 access를 통해 로그를 남기는 AWS CLI 업로드 사용
출력물의 카메라가 다름	다중 카메라 씬에서 카메라를 지정하지 않음	제출 전에 씬에서 렌더 카메라를 설정(로컬 테스트에는 Maya `-cam`)
작업이 끝났는데 로컬에 프레임이 없음	자동 다운로드 경로가 분리되었거나 옮겨진 드라이브였음	다운로드 폴더를 쓰기 가능한 경로로 지정한 뒤 Sync output 사용
밤샘 스크립트가 "아무것도 하지 않았고" 오류도 없음	`2>&1` 로그 없음, 조용한 실패	stdout과 stderr를 로그로 리디렉션하고, 먼저 로컬 테스트 프레임을 렌더링

공통점은 결정성(determinism)입니다. 무인 워크플로는 실행이 시작되기 전에 모든 입력이 고정되어 있을 때만 동작합니다. 여러분의 워크스테이션에만 있는 무언가에 의존하는 렌더는 눈앞에서 지켜볼 때는 한 번 성공하지만, 새벽 2시에는 다시는 성공하지 못합니다.

FAQ

Q: 헤드리스 렌더링이란 무엇인가요? A: 헤드리스 렌더링은 그래픽 인터페이스를 열지 않고 명령줄에서 렌더를 실행하는 것을 뜻하며, 예를 들어 blender -b scene.blend -a나 nuke -x script.nk가 있습니다. 모든 렌더팜 노드가 이 방식으로 동작하고, 아티스트도 업로드 전에 씬을 테스트하려고 로컬에서 같은 진입점을 사용합니다.

Q: 헤드리스 렌더링과 무인 렌더링은 어떻게 다른가요? A: 헤드리스는 단일 렌더가 어떻게 실행되는가, 즉 GUI 없이 실행된다는 뜻입니다. 무인은 워크플로 전체에서 사람이 자리에 있어야 하는가에 관한 것입니다. 매니지드 렌더팜에서는 헤드리스 부분을 렌더팜이 처리하므로, 자동화는 그 주변의 루프에 들어갑니다.

Q: 스크립트나 API로 Super Renders Farm에 작업을 제출할 수 있나요? A: 현재는 불가능합니다. 저희 렌더팜은 공개 REST API, SDK, 명령줄 제출 도구를 제공하지 않으며, 프로그래밍 방식 제출은 로드맵에 있습니다. 작업은 웹 대시보드, Client App, 또는 3ds Max, Maya, Cinema 4D의 플러그인에서 제출합니다. 스크립트로 처리할 수 있는 것은 그 이전의 준비 작업, S3 access를 통한 업로드, 그리고 그 이후의 후처리입니다.

Q: 렌더팜으로의 파일 전송을 스크립트로 처리할 수 있나요? A: 네, S3 access로 가능하며 SFTP와 FTP는 제공하지 않습니다. 계정의 Cloud Direct Connect에서 액세스 키를 생성한 다음, AWS CLI(리전 ap-southeast-1) 또는 Amazon S3 프로토콜을 사용하는 Cyberduck으로 SRF Space와 파일을 주고받으면 됩니다. 수동 전송에는 웹 업로드와 SuperRenders Client App을 쓸 수 있으며, 완성된 프레임은 Client App 자동 다운로드나 웹 다운로드로 받습니다.

Q: 컴퓨터 앞에 앉아 있지 않고 완성된 렌더를 받으려면 어떻게 하나요? A: Client App의 자동 다운로드를 사용하세요. 기본으로 켜져 있으며, 각 프레임이 완료되는 즉시 기본 폴더 또는 작업별 폴더로 내려받습니다. Windows에서는 메인 창을 닫아도 백그라운드 서비스가 전송을 계속하고, 해당 폴더에 로컬 감시 스크립트를 두면 인코딩이나 리뷰 단계를 시작할 수 있습니다.

Q: 업로드 전에 씬을 테스트하려면 Blender를 명령줄에서 어떻게 렌더링하나요? A: 백그라운드 모드를 사용합니다. 예를 들어 테스트 프레임 하나는 blender -b scene.blend -E CYCLES -f 1로 렌더링합니다. -b 플래그는 GUI 없이 실행하고 -E는 엔진을 선택하며, 저희 렌더팜은 Cycles와 EEVEE를 모두 렌더링합니다. --python-exit-code와 함께 실행하는 작은 bpy 스크립트로 같은 패스에서 절대 경로나 누락된 경로를 보고할 수도 있습니다.

Q: 무인 밤샘 렌더를 예약할 수 있나요? A: 여러분 쪽 작업은 예약할 수 있습니다. cron이나 작업 스케줄러(Task Scheduler)로 실행하는 사전 점검, 통과한 각 프로젝트를 SRF Space에 올리는 AWS CLI 업로드, Client App이 내려받는 프레임을 처리하는 감시 스크립트가 그것입니다. 제출은 웹 대시보드, Client App 또는 DCC 플러그인에서 이루어지므로, 사람이 짧은 핸드오프를 한 번 수행합니다.

Q: 렌더팜에서 헤드리스 렌더링을 하려면 렌더 엔진 라이센스를 직접 관리해야 하나요? A: 아니요. 풀 매니지드 렌더팜에서는 렌더 엔진 라이센스를 서비스의 일부로 렌더팜 쪽에서 처리합니다. 자체 관리 환경에서는 직접 라이센스 서버를 운영하고 각 노드에서 헤드리스 렌더를 직접 실행해야 합니다.