Python으로 render farm 업로드 자동화: paramiko와 rsync 가이드

클라우드 렌더링에서 가장 느린 구간은 렌더링 자체가 아닌 경우가 많습니다. 멀티카메라 VFX 샷이나 400 GB Houdini 캐시를 매일 밤 render farm에 전송해야 하는 스튜디오에게 병목은 바로 파일 이동입니다. 프로젝트를 안정적으로 업로드하고, 아침에 직원들이 출근하기 전에 완성된 프레임을 내려받는 것이 핵심입니다. 자정에 진행률 표시줄을 바라보며 수동으로 처리하는 방식은 확장성이 없습니다. 스크립트로 자동화하면 됩니다.

이 가이드는 Python으로 파일 전송 레이어를 자동화하는 방법을 다룹니다. 저희는 풀 매니지드 render farm인 Super Renders Farm을 운영하며, "풀 매니지드"는 자동화 측면에서 정확한 의미를 갖습니다. 즉, 머신에 원격으로 접속하거나, 소프트웨어를 설치하거나, 라이센스를 관리할 필요가 없습니다. 따라서 파이프라인에서 직접 스크립트로 제어하는 부분은 파일이 오가는 구간입니다. 전송 인터페이스는 SFTP를 통해 실질적으로 스크립트화할 수 있으며, Python은 이를 위한 1순위 방법입니다. 저희 전송 문서에서는 Python의 paramiko 라이브러리를 지원 클라이언트로 직접 명시하고 있으며, SSH를 통한 rsync와 표준 sftp 명령줄도 지원합니다.

현재 Python에서 자동화할 수 없는 부분도 명확하게 설명하겠습니다. 존재하지 않는 기능에 기반한 파이프라인은 첫 번째 무인 실행에서 실패하기 때문입니다. 헤드리스(headless)와 무인(unattended)의 개념적 차이, 명령줄 렌더링을 위한 씬 준비 방법 등 더 넓은 맥락이 필요하다면 별도의 컴패니언 가이드를 참고하십시오. 이 가이드는 코드 수준에 집중합니다. paramiko, rsync, SSH 키, 재시도, 그리고 스튜디오 자동화에 바로 적용할 수 있는 야간 동기화 패턴입니다.

현재 Python으로 자동화할 수 있는 것

코드를 작성하기 전에 경계를 먼저 파악하는 것이 좋습니다. 풀 매니지드 render farm에서 파이프라인의 일부는 완전히 스크립트화할 수 있고, 일부는 의도적으로 GUI 방식으로 운영되며, 그 사이에 있는 부분도 있습니다. 각각의 차이를 명확히 파악해야 자동화가 조용히 실패하는 상황을 막을 수 있습니다.

• 프로젝트 업로드 — 완전히 스크립트화 가능. paramiko, rsync, 또는 스크립트화된 sftp 명령어는 모두 저희 SFTP 서버에서 작동합니다. 이하 내용의 핵심입니다.
• 완성된 프레임 다운로드 — 완전히 스크립트화 가능. 출력은 동일한 도구로 가져올 수 있는 작업별 디렉터리에 저장됩니다.
• 작업 완료 감지 — 부분적. 폴링할 수 있는 공개 상태 API가 없습니다. 가능한 방법은 SFTP 출력 디렉터리를 폴링하여 프레임이 나타나고 안정화되는 것을 감시하는 것입니다. 이는 공식 신호가 아닌 휴리스틱이며, 아래에서 그렇게 처리합니다.
• 렌더 작업 제출 — 현재 GUI 방식. 제출은 웹 양식, SuperRenders Client App, 또는 DCC별 제출 플러그인을 통해 처리됩니다. 작업 제출, 상태 폴링, 출력 검색을 위한 공개 REST API는 로드맵에 있지만, 현재는 직접 연동 가능한 공개 API 엔드포인트가 없습니다. 제출 API가 파이프라인의 구체적인 병목이라면 지원팀에 문의하여 사용 사례를 공유해 주십시오. 로드맵은 실제 파이프라인 요구사항을 바탕으로 만들어집니다.
• 계정, 크레딧, 청구 관리 — GUI. 파일 전송 자동화 범위 밖입니다.

따라서 자동화할 수 있는 영역은 전송입니다. 프로젝트를 업로드하고, 렌더 결과물을 다운로드하며, 그 사이의 간극은 출력 디렉터리를 감시하는 방식으로 처리합니다. 제출 단계는 의도적인 인계 지점으로 남아 있으며, 최종 파이프라인에서 명확히 표시합니다. 풀 매니지드 렌더링의 개념적 맵에 대해서는 풀 매니지드 render farm이란 무엇인가 가이드를 참고하십시오. 신규 계정은 시작 가이드에서 시작할 수 있습니다.

사전 준비: SFTP 접근, SSH 키, Python 환경

첫 번째 스크립트 업로드 전에 세 가지를 준비해야 합니다.

SFTP 접근, 계정별 활성화. SFTP는 요청 시 계정별로 활성화됩니다. 로그인 후 계정 설정에서 "SFTP access"를 찾아 자격 증명을 생성하십시오. 보이지 않는다면 지원팀에 활성화를 요청하십시오. 자격 증명에는 서버 호스트명(지역 및 스토리지 할당에 따라 달라지므로 설정값으로 읽어야 하며, 절대 하드코딩하지 마십시오), 계정에 연결된 사용자명, 비밀번호 또는 SSH 키, 표준 SFTP 포트 22가 포함됩니다. 중요한 경로는 두 가지입니다. /uploads/<your-project-folder>/는 쓰기 영역이고, /output/<job-id>/는 완성된 렌더 결과물이 나타나는 경로입니다.

비밀번호 대신 SSH 키 사용. 자동화된 작업에는 SSH 키 인증이 적합합니다. 스크립트에서 비밀 정보를 분리하고, 대화형 프롬프트 없이 무인 실행을 지원합니다. 현대적인 키 쌍을 생성하고 공개 키를 계정에 등록하십시오.

ssh-keygen -t ed25519 -C "pipeline@yourstudio.example"
# ~/.ssh/id_ed25519.pub 내용을
# superrendersfarm.com -> Settings -> SFTP -> SSH Keys 에 추가하십시오

계정 보안 관련 참고: 현재 계정에서 이중 인증은 지원되지 않습니다. SFTP에서 가장 강력한 보안 강화 방법은 키 파일에 패스프레이즈를 설정하고 SSH 에이전트가 세션 중 잠금 해제된 키를 보유하게 하는 것입니다. 키와 패스프레이즈를 함께 사용하면 2단계 인증과 유사한 역할을 합니다.

paramiko를 포함한 Python 환경. 아래 내용은 모두 표준 순수 Python SSH/SFTP 구현인 paramiko를 사용하며, 대용량 증분 전송에는 rsync를 호출합니다.

python3 -m venv .venv && source .venv/bin/activate
pip install paramiko

무인 업로드에서 살아남는 프로젝트 패키징

대부분의 렌더 작업 실패는 엔진 버그가 아니라 패키징 문제입니다. 아티스트의 워크스테이션에서 렌더링되는 씬이 새 워커에서는 실패하는 이유는 텍스처 경로가 로컬 전용 드라이브를 가리키거나, 참조된 하위 씬이 번들에 포함되지 않았기 때문입니다. 자동화는 이 문제를 증폭시킵니다. 잘못된 패키지를 무인 업로드하면 무인 실패로 이어집니다. 두 가지 규칙이 패키지를 올바르게 유지합니다.

첫째, 상대 경로를 사용하여 프로젝트를 자체 완결적으로 만드십시오. DCC의 수집 및 패키지 명령(Archive, Collect Files, Save Project with Assets)을 실행하여 모든 텍스처, 프록시, 캐시가 프로젝트 루트를 기준으로 상대 경로로 해석되게 하십시오. 둘째, 압축 전에 아카이브 형식에 주의하십시오. 저희는 tar, tar.gz, 7z를 지원하지만 .zip은 지원하지 않습니다. .tar.gz로 재패킹하거나, 아카이브를 건너뛰고 rsync로 폴더 트리를 전송하십시오. 지속적인 프로젝트에는 후자가 보통 더 나은 선택입니다. 실용적인 상한선으로, 단일 업로드는 ~300 GB 미만으로 유지하십시오. 그 이상이면 일회성 전송보다 재개 기능을 갖춘 rsync를 사용하십시오.

paramiko로 프로젝트 업로드하기

첫 번째 빌딩 블록은 재귀 업로더입니다. 키로 연결하고, 로컬 프로젝트 트리를 순회하며, /uploads/ 아래에 디렉터리 구조를 재생성하고, 각 파일을 전송합니다. RejectPolicy로 호스트 키를 고정하고 연결 세부 정보는 환경 변수에서 읽어 스크립트에 민감한 정보가 남지 않게 합니다.

import os
import paramiko

def connect():
    host = os.environ["SRF_SFTP_HOST"]
    user = os.environ["SRF_SFTP_USER"]
    key_path = os.environ["SRF_SFTP_KEY"]      # 개인 키 경로

    client = paramiko.SSHClient()
    client.load_system_host_keys()             # ~/.ssh/known_hosts만 신뢰
    client.set_missing_host_key_policy(paramiko.RejectPolicy())
    client.connect(hostname=host, port=22, username=user, key_filename=key_path)
    return client, client.open_sftp()

def _ensure_remote_dir(sftp, remote_dir):
    # SFTP를 통한 mkdir -p: 경로를 한 세그먼트씩 생성
    path = ""
    for segment in remote_dir.strip("/").split("/"):
        path += "/" + segment
        try:
            sftp.stat(path)
        except IOError:
            sftp.mkdir(path)

def upload_dir(sftp, local_dir, remote_dir):
    for root, _dirs, files in os.walk(local_dir):
        rel = os.path.relpath(root, local_dir)
        remote_root = remote_dir if rel == "." else f"{remote_dir}/{rel.replace(os.sep, '/')}"
        _ensure_remote_dir(sftp, remote_root)
        for name in files:
            local_path = os.path.join(root, name)
            remote_path = f"{remote_root}/{name}"
            sftp.put(local_path, remote_path)
            print(f"uploaded {remote_path}")

하나의 프로젝트를 업로드하는 방법:

client, sftp = connect()
try:
    upload_dir(sftp, "/local/projects/archviz-tower", "/uploads/archviz-tower-2026-06")
finally:
    sftp.close()
    client.close()

소규모 및 중간 규모 프로젝트에는 이 정도로 충분합니다. sftp.put은 전송된 바이트 수와 전체 용량을 받는 callback= 인수도 지원하므로, 이를 진행률 미터 또는 파일별 로그 라인에 연결할 수 있습니다. 그러나 스튜디오 작업의 특성상 대용량 반복 전송에는 rsync가 더 적합한 도구입니다.

SSH를 통한 rsync로 증분 동기화

렌더 프로젝트는 한 번만 업로드하는 경우가 드뭅니다. 셰이더를 조정하고, 시뮬레이션을 재캐시하고, 조명을 수정하고 다시 업로드합니다. 매번 전체 폴더를 전송하면 수 시간이 낭비됩니다. rsync는 변경된 부분만 전송합니다. 매일 밤 업로드하는 스튜디오에게 이것은 전송 레이어에서 가장 큰 시간 절약 요소입니다. 전체 프로젝트가 아닌 변경분(delta)만 전송하기 때문입니다.

표준 호출 방식:

rsync -avz --partial --progress \
  /local/projects/archviz-tower/ \
  "$SRF_SFTP_USER@$SRF_SFTP_HOST:/uploads/archviz-tower-2026-06/"

-a는 구조와 타임스탬프를 보존하고, -z는 전송 중 압축을 적용하며, --partial은 부분 전송된 파일을 유지하여 연결이 끊겨도 처음부터 다시 시작하지 않고 재개하며, --progress는 파일별 진행 상황을 보고합니다. 변경 후 동일한 명령을 다시 실행하면 수정된 파일만 전송됩니다. 자동화가 목표이므로 Python으로 감싸서 나머지 스크립트와 함께 관리하고 종료 코드에 반응할 수 있게 합니다.

import subprocess

def rsync_up(local_dir, remote_subdir):
    host = os.environ["SRF_SFTP_HOST"]
    user = os.environ["SRF_SFTP_USER"]
    dest = f"{user}@{host}:/uploads/{remote_subdir}/"
    cmd = ["rsync", "-avz", "--partial", "--progress",
           f"{local_dir.rstrip('/')}/", dest]
    subprocess.run(cmd, check=True)   # 실패 시 CalledProcessError 발생

무인으로 실행하려면 일정을 예약하십시오. 작업 디렉터리를 매일 밤 오전 1시에 render farm에 미러링하는 스튜디오에는 cron 라인 하나로 충분합니다.

0 1 * * *  cd /studio/pipeline && /usr/bin/python3 nightly_sync.py >> sync.log 2>&1

SSH를 통한 rsync가 프롬프트 없이 인증하려면 -e "ssh -i ~/.ssh/id_ed25519"로 키를 지정하거나, SSH 에이전트가 세션 중 잠금 해제된 키를 보유하게 하십시오.

완성된 프레임 자동 다운로드

작업이 완료되면 출력 프레임이 SFTP 서버의 /output/<job-id>/에 기록됩니다. 다운로드 측은 업로드 측의 미러입니다. paramiko의 재귀 get 또는 rsync 풀을 사용합니다. paramiko 버전은 원격 디렉터리를 순회하고 로컬에 재생성합니다.

import stat

def download_dir(sftp, remote_dir, local_dir):
    os.makedirs(local_dir, exist_ok=True)
    for entry in sftp.listdir_attr(remote_dir):
        remote_path = f"{remote_dir}/{entry.filename}"
        local_path = os.path.join(local_dir, entry.filename)
        if stat.S_ISDIR(entry.st_mode):
            download_dir(sftp, remote_path, local_path)
        else:
            sftp.get(remote_path, local_path)
            print(f"downloaded {local_path}")

대용량 출력 세트의 경우, rsync 풀이 다시 더 효율적이고 재개 가능한 선택입니다.

rsync -avz --progress \
  "$SRF_SFTP_USER@$SRF_SFTP_HOST:/output/<job-id>/" \
  /local/downloads/<job-id>/

무인 파이프라인에서 중요한 운영 세부사항이 있습니다. 렌더 출력은 작업 완료 후 45일 동안 보관되다가 자동으로 삭제됩니다. SFTP는 이 기간을 연장하지 않습니다. 안전한 패턴은 출력이 나타나는 즉시 로컬 아카이브로 미러링하는 야간 동기화입니다. 보관 기간이 프레임 손실의 원인이 되지 않게 하는 것입니다.

상태 API 없이 작업 완료 감지하기

이 부분이 솔직한 경계가 구체적인 엔지니어링 선택으로 이어지는 지점입니다. "작업 12345가 완료되었는가?"를 묻는 공개 엔드포인트가 없지만, 출력 디렉터리 자체는 SFTP를 통해 관찰할 수 있습니다. 실용적인 패턴은 /output/<job-id>/를 폴링하고, 파일 수를 세어 예상 프레임 수에 도달했고 연속적인 확인 사이에 안정적으로 유지되는지 기다리는 것입니다(다운로드를 시작하기 전에 쓰기가 완료되었는지 확인합니다).

import time

def wait_for_output(sftp, output_dir, expected_frames, poll=120, stable_checks=2):
    last_count, stable = -1, 0
    while True:
        try:
            files = sftp.listdir(output_dir)
        except IOError:
            files = []                      # 폴더 미생성 = 아직 시작 안 됨
        count = len(files)
        if count >= expected_frames and count == last_count:
            stable += 1
            if stable >= stable_checks:
                return files                # 수량 충족 + 안정 = 완료로 간주
        else:
            stable = 0
        last_count = count
        time.sleep(poll)

이 방식이 무엇인지 명확히 인지하십시오. 프레임은 증분적으로 나타나므로, 존재 자체만으로는 완료를 의미하지 않습니다. 예상 수에 도달했는지 확인하고 폴링 사이에 안정적으로 유지되는지 검증하는 것이 자동화에서 충분히 신뢰할 수 있게 만듭니다. 이것은 공식 계약이 아닌 디렉터리 휴리스틱입니다. 공개 API가 출시되면 이 함수 전체가 상태 API 호출로 대체됩니다. 그때까지 출력 디렉터리를 감시하는 것이 현재 존재하는 기능에만 의존하는 근거 있는 방법입니다.

통합: 무인 전송 파이프라인

이 구성 요소들이 하나의 야간 스크립트로 합쳐집니다. 형태는 다음과 같습니다. 프로젝트를 동기화하여 업로드하고, 제출을 인계하며, 출력이 나타나고 안정될 때까지 기다렸다가 내려받고, 검증한 후 아카이브합니다. 제출 단계는 의도적인 GUI 인계 지점입니다. 풀 매니지드 render farm에서는 웹 양식, Client App, 또는 DCC 제출 플러그인을 통해 제출합니다. 제출이 이미 스크립트로 제어하는 도구 안에 있을 때, DCC별 플러그인은 호스트 애플리케이션의 자체 스크립팅 환경(MAXScript, DCC 내부 Python)에서 구동할 수 있습니다. 저희는 API가 존재하는 척하는 함수로 이 단계를 감싸는 대신, 솔직하게 표시합니다.

def nightly_pipeline(project_dir, remote_subdir, job_id, expected_frames):
    client, sftp = connect()
    try:
        # with_retries()(다음 섹션에서 정의)는 네트워크 호출을 감쌉니다
        with_retries(lambda: rsync_up(project_dir, remote_subdir))    # 1. 변경분 업로드
        # 2. 제출: GUI / Client App / DCC 플러그인 — 공개 API 없음 (현재)
        files = wait_for_output(                                       # 3. 출력 디렉터리 감시
            sftp, f"/output/{job_id}", expected_frames)
        with_retries(lambda:                                           # 4. 완성된 프레임 다운로드
            download_dir(sftp, f"/output/{job_id}", f"/local/downloads/{job_id}"))
        print(f"job {job_id}: {len(files)} frames retrieved")
    finally:
        sftp.close()
        client.close()

1, 3, 4단계는 완전히 자동화됩니다. 2단계는 인계 지점입니다. 공개 제출 API가 출시되면 2단계와 3단계는 API 호출로 대체되고 디렉터리 폴링은 불필요해집니다. 아키텍처는 변하지 않습니다. 제출 및 상태 레그만 GUI와 휴리스틱에서 엔드포인트로 이동합니다.

오류 처리, 재시도, 재개 가능한 전송

무인이라는 말은 전송이 문제가 생겼을 때 아무도 보고 있지 않다는 뜻입니다. 따라서 스크립트가 스스로 복구해야 합니다. 세 가지 습관으로 대부분의 실패를 처리할 수 있습니다.

백오프를 적용한 일시적 오류 재시도. 긴 전송 중 네트워크 블립과 짧은 연결 끊김은 정상입니다. 단일 연결 끊김으로 실행이 중단되지 않도록 취약한 호출을 감싸십시오(nightly_pipeline에서 위에 그렇게 처리합니다). 모든 예외를 잡는 대신, 특정 일시적 오류를 잡으십시오. paramiko의 SSHException, 소켓용 OSError 계열, 실패한 rsync에 대한 CalledProcessError입니다.

def with_retries(fn, attempts=3, backoff=5):
    transient = (paramiko.SSHException, OSError, subprocess.CalledProcessError)
    for i in range(1, attempts + 1):
        try:
            return fn()
        except transient:                  # SSH / 네트워크 / rsync 오류 재시도
            if i == attempts:
                raise
            time.sleep(backoff * i)        # 백오프: 5초, 10초, 15초

재개 가능성 활용. rsync --partial은 이미 중단된 파일을 재개하고, rsync를 다시 실행하는 것은 멱등적입니다. 누락된 것만 전송하므로 재시도 동기화는 재시작이 아닌 저렴한 작업입니다. paramiko 전송의 경우, 재시도와 재순회를 통해 동일한 효과를 얻습니다. 이미 존재하는 파일은 거의 즉시 전송됩니다.

호스트 키 및 연결 오류를 명시적으로 처리. "host key verification failed" 오류는 ~/.ssh/known_hosts에 캐시된 키가 서버 키와 더 이상 일치하지 않음을 의미합니다. 드문 호스트 키 교체 후 주로 발생합니다. 오류에서 지명된 오래된 라인을 제거하고 다시 연결하여 새 키를 수락하십시오. 연결 거부 또는 타임아웃은 보통 스튜디오 방화벽이 아웃바운드 TCP 22를 차단함을 의미합니다. 허용하거나 대안에 대해 지원팀에 문의하십시오. 처리량이 링크 속도보다 훨씬 낮다면 SFTP의 패킷별 오버헤드가 장거리 링크에서 원인입니다. 병렬 세그먼트를 사용하는 lftp나 여러 동시 SFTP 세션으로 대부분의 격차를 회복할 수 있습니다.

요약: 무엇을, 어떻게 자동화할까

전송 레이어는 코드로 소유하는 풀 매니지드 render farm 파이프라인의 영역이며, Python이 이를 완전히 처리합니다.

작업	Python에서 자동화 가능?	도구	참고
프로젝트 업로드	예	paramiko 또는 rsync	대용량/반복에는 rsync; 재개에는 --partial
증분 재업로드	예	SSH를 통한 rsync	변경된 파일만 전송
완성된 프레임 다운로드	예	paramiko get / rsync 풀	야간 미러링 — 45일 보관
완료 감지	부분적	/output/<job-id>/ 폴링	수량 + 안정성 휴리스틱, 상태 API 없음
렌더 작업 제출	아니요 (현재)	Web / Client App / DCC 플러그인	공개 API 로드맵에 있음
인증	예	SSH 키 (ed25519)	키 + 패스프레이즈; 하드코딩된 비밀 없음

업로드를 자동화하고, 다운로드를 자동화하며, 중간은 출력 디렉터리를 감시하여 처리하고, 제출 인계 지점을 명확히 유지하십시오. 이렇게 하면 연결 지점에 솔직하면서도 신뢰할 수 있는 야간 파이프라인이 완성됩니다. 전송 신뢰성이 가장 중요한 대용량 시뮬레이션 중심 프로젝트의 경우(수 테라바이트 Houdini 캐시 등), 동일한 패턴이 Super Renders Farm에서 직접 적용됩니다. 해당 워크로드에 대해서는 Houdini cloud render farm 페이지를 참고하십시오.

FAQ

Q: render farm에 업로드할 때 어떤 Python 라이브러리를 사용해야 합니까? A: paramiko가 표준 선택이며, 저희 SFTP 문서에서 지원 클라이언트로 직접 명시합니다. 순수 Python으로 구현되어 SFTP를 깔끔하게 처리하며 업로드 및 다운로드 로직에 잘 작동합니다. 매우 크거나 자주 반복되는 전송에는 Python에서 subprocess를 통해 SSH 기반 rsync를 호출하십시오. 변경된 파일만 전송하고 중단된 전송을 재개하며, paramiko는 기본적으로 이를 지원하지 않습니다.

Q: Python 파이프라인에서 렌더 작업을 제출할 공개 API가 있습니까? A: 아직 없습니다. 제출, 상태 폴링, 출력 검색을 위한 공개 REST API는 로드맵에 있지만, 현재는 공개 엔드포인트가 없습니다. 현재 프로그래밍 방식의 제출 경로는 SuperRenders Client App과 DCC별 제출 플러그인이며, 후자는 MAXScript나 DCC 내부 Python과 같은 호스트 애플리케이션의 스크립팅 환경과 연동됩니다. 파이프라인이 특히 공개 제출 API에서 막혀 있다면 지원팀에 문의하여 사용 사례를 공유해 주십시오. 로드맵은 실제 파이프라인 요구사항을 바탕으로 만들어집니다.

Q: 상태 API가 없을 때 렌더 작업이 완료되었는지 어떻게 감지합니까? A: 작업의 SFTP 출력 디렉터리 /output/<job-id>/를 폴링하고 프레임 수를 감시하십시오. 프레임이 쓰이는 중에 다운로드를 시작하지 않으려면, 수량이 예상 합계에 도달하고 연속적인 확인에서 안정적으로 유지될 때만 완료로 처리하십시오. 공식 상태 신호가 아닌 디렉터리 휴리스틱이지만, 현재 존재하는 기능에만 의존합니다.

Q: 자동화된 전송에 SSH 키와 비밀번호 중 무엇을 사용해야 합니까? A: SSH 키를 사용하십시오. 스크립트에 비밀번호를 하드코딩하는 것은 보안 위험이며, 키 인증은 대화형 프롬프트 없이 무인으로 실행됩니다. ed25519 키를 생성하고 공개 키를 Settings → SFTP → SSH Keys에 등록한 다음 SSH 에이전트가 보유한 패스프레이즈로 개인 키를 보호하십시오. 현재 계정에서 이중 인증이 지원되지 않으므로, 키와 패스프레이즈가 SFTP 접근에 대한 가장 강력한 실용적 보안 강화 방법입니다.

Q: 스크립트에서 .zip 아카이브를 업로드할 수 있습니까? A: 아니요. .zip 아카이브는 지원되지 않습니다. .tar.gz(또는 .tar / .7z)로 재패킹하거나, 아카이브를 건너뛰고 rsync로 폴더 트리를 직접 전송하십시오. 업로드 사이에 변경되는 프로젝트에는 후자가 보통 더 나은 선택입니다. 단일 업로드는 약 300 GB 미만으로 유지하고, 그 이상에는 rsync --partial을 사용하여 연결이 끊겨도 재시작하지 않고 재개할 수 있게 하십시오.

Q: 이 방식으로 얼마나 큰 프로젝트를 전송할 수 있습니까? A: SFTP를 통해 수 테라바이트 전송을 지원합니다. 실질적인 한계는 render farm이 아닌 자신의 업로드 대역폭입니다. 100 Mbps에서 1 TB 업로드는 약 하루가 걸리므로 링크를 기준으로 계획하십시오. 대용량 또는 장거리 연결에서 최대 처리량을 얻으려면 병렬 세그먼트를 사용하는 lftp나 여러 동시 SFTP 세션을 사용하십시오. 단일 SFTP 스트림은 패킷별 오버헤드로 제한됩니다.

Q: 렌더링된 프레임을 다운로드할 수 있는 기간은 얼마입니까? A: 출력은 작업 완료 후 45일 동안 보관되다가 자동으로 삭제되며, SFTP는 이 기간을 연장하지 않습니다. 무인 파이프라인에서는 출력이 나타나는 즉시 로컬 아카이브로 미러링하십시오. /output/<job-id>/의 야간 rsync 풀이 보관 기간이 프레임 손실의 원인이 되지 않게 합니다.

Q: 헤드리스 및 무인 워크플로우 가이드와 어떻게 다릅니까? A: 그 가이드는 개념적 맵입니다. 헤드리스 렌더링의 의미, 명령줄 렌더링을 위한 씬 준비 방법, 무인 루프가 풀 매니지드 render farm에서 어떻게 맞물리는지를 다룹니다. 이 가이드는 전송 레이어에 집중하는 코드 수준 컴패니언입니다. 프로젝트를 업로드하고 프레임을 다운로드하기 위해 실제로 작성하는 paramiko와 rsync 코드입니다. 형태를 파악하려면 워크플로우 가이드를, 구현에 활용하려면 이 가이드를 참고하십시오.