블랜더 3D 모델링 랜더링 시간 대폭 줄이는 방법 | 샘플, 텍스처 정리부터 RTX 50 업그레이드와 Vast, RunPod 임대까지

렌더링은 무엇이고 왜 이렇게 오래 걸리나

블렌더 화면(뷰포트)에서 보이는 장면은 작업하기 편하게 대충 그린 미리보기에 가까워요. 렌더링은 이 장면을 정해진 해상도와 품질로 다시 꼼꼼하게 계산해서 PNG 같은 이미지 파일로 저장하는 과정이에요. 애니메이션이면 이 작업을 프레임마다 처음부터 다시 해요. 앞 프레임의 결과를 이어 쓰지 않기 때문에, 프레임 수가 곧 렌더 횟수예요.

프레임 한 장이 만들어지는 과정은 두 단계로 나뉘어요. 먼저 CPU가 장면을 준비해요. 이 프레임에서 자동차가 어디까지 움직였는지, 캐릭터 뼈대(리그)가 어떤 자세인지 애니메이션을 계산하고, 바뀐 형태와 위치 데이터를 그래픽카드로 보내요. 블렌더 내부에서는 이 계산 묶음을 디펜던시 그래프(depsgraph) 평가라고 불러요. 그다음 GPU가 실제로 그림을 그려요. 빛, 그림자, 반사를 계산해 픽셀 색을 정하고, 정해진 횟수만큼 반복해 깨끗하게 다듬어요.

앞의 사례에서 렌더 로그를 단계별로 나눠 보면, 조금 가벼웠던 이전 버전 장면 기준으로 CPU 준비 단계가 프레임마다 약 1.5초, GPU가 16번 그리는 단계가 평균 약 6.4초, 합성과 PNG 저장이 0.1초 정도였어요. 오브젝트와 텍스처가 늘어난 최종 버전은 평균 10.8초가 됐어요. 렌더 중 작업 관리자 수치로도 그리는 단계에서는 내장 GPU 사용률이 93~96%까지 올라가고, 준비 단계에서는 46~57%로 내려가요. 내장 그래픽이 대부분의 시간을 붙잡고 있고, 그 사이사이에 CPU만 일하는 1~2초가 끼어 있는 구조예요.

프레임당 1초를 줄이면 3,287프레임 기준 약 55분, 3초를 줄이면 약 2시간 45분이 줄어요. 줄일 곳은 두 군데예요. GPU가 그리는 시간은 그래픽카드 성능과 샘플 수가 정하고, CPU가 준비하는 시간은 장면에 들어 있는 오브젝트와 애니메이션의 양, 그리고 CPU 성능이 정해요.

EEVEE와 Cycles, 그리고 샘플이 뜻하는 것

블렌더에는 렌더 엔진이 두 가지 있어요. EEVEE는 게임 엔진처럼 화면을 빠르게 그리는 방식(래스터라이즈)이고, Cycles는 빛이 튀는 경로를 하나하나 추적하는 방식(패스 트레이싱)이에요. 같은 장면이면 Cycles가 훨씬 사실적이지만 프레임당 몇 분씩 걸리기도 하고, EEVEE는 몇 초 안에 끝나는 대신 그림자와 반사를 근사로 처리해요. 쇼츠나 모션그래픽처럼 프레임 수가 많은 작업은 EEVEE를 많이 써요.

샘플(Samples)은 한 프레임을 몇 번 반복해서 그린 뒤 평균을 낼지 정하는 숫자예요. EEVEE는 같은 프레임을 조금씩 어긋나게 여러 번 그려 계단 현상과 그림자 얼룩을 줄이는데, 블렌더 공식 문서는 이 방식을 TAA(Temporal Anti-Aliasing)라고 부르고 "샘플이 많을수록 계단 현상이 줄지만 성능을 대가로 치른다"고 설명해요. 렌더 설정의 Sampling 패널에서 Render 값을 16으로 두면 한 프레임을 16번 그리는 거예요.

그래픽카드를 고를 때 흔히 보는 블렌더 벤치마크 점수(Blender Open Data)는 Cycles로 측정한 값이라 RT 코어 성능이 크게 반영돼요. 예를 들어 RTX 5080의 Open Data 점수는 약 9,100점인데, 이 점수 차이가 EEVEE 렌더 시간 차이로 그대로 이어지지는 않아요. EEVEE 속도는 래스터 성능과 메모리 대역폭 쪽에 더 가까워요.

RTX 5090으로 바꿔도 1시간이 넘는 이유

블렌더 공식 매뉴얼은 EEVEE의 한계 항목에서 "EEVEE는 GPU만 써서 렌더하지만, 장면이 복잡하면 프레임마다 CPU가 지오메트리를 준비해야 하므로 CPU 성능도 필요하다"고 적어 두었어요. 앞에서 본 CPU 준비 단계가 바로 이 부분이에요. 그래픽카드를 바꾸면 GPU가 그리는 6.4초는 크게 줄지만, CPU가 준비하는 1~2초는 그대로 남아요.

계산식으로 쓰면 프레임당 시간은 "CPU 고정 시간 + GPU 시간 ÷ 그래픽카드 배율"이에요. 내장 그래픽보다 10배 빠른 카드를 꽂으면 GPU 시간은 10분의 1이 되지만, CPU 고정 시간 1~2초는 나눠지지 않아요. 그래서 비싼 카드일수록 CPU 시간이 전체에서 차지하는 비율이 커지고, 5070과 5090의 차이가 생각보다 작아져요. 3,287프레임에 프레임당 CPU 시간 1초만 남아도 약 55분, 2초면 약 1시간 50분이에요.

테크게이지(Techgage)도 블렌더 3.3 EEVEE 테스트에서 비슷한 현상을 보고했어요. 렌더 사이마다 CPU를 많이 쓰는 데모 프로젝트에서는 RTX 3090에서 4090으로 바꿨을 때 향상 폭이 "훨씬 작았다"고 해요. 클라우드에서도 같은 일이 보였어요. 같은 장면을 vCPU 2개짜리 구글 코랩 T4에서 돌렸더니 GPU는 거의 놀고 CPU만 바쁘게 일하면서 프레임당 12.5~16.8초가 걸려, 오히려 집의 내장 그래픽보다 느렸어요.

핵심 포인트: EEVEE 렌더 시간은 "GPU가 그리는 시간"과 "CPU가 준비하는 시간"의 합이에요. 그래픽카드는 앞쪽만 줄여 주고, 뒤쪽은 장면 정리와 CPU, 그리고 여러 대로 나누기로 줄여야 해요.

RTX 5050~5090 사양과 가격, 예상 렌더 시간

아래 표는 NVIDIA 공식 사양과 2026년 10월 국내 최저가(다나와, 쿠팡 등), 그리고 앞의 3,287프레임 장면을 16샘플로 렌더할 때의 예상 시간이에요. 예상 시간은 낙관치와 보수치 두 값으로 나눴어요.

예상 시간은 이렇게 계산했어요. 프레임당 시간을 CPU 고정 시간(낙관 1초, 보수 2초)과 나머지 GPU 시간으로 나눈 뒤, GPU 시간을 카드별 배율로 나눴어요. 낙관 배율은 3DMark Time Spy 그래픽 점수를 내장 그래픽 점수(737)로 나눈 값이고, 보수 배율은 메모리 대역폭을 함께 반영해 5050을 약 7.6배로 잡은 뒤 Tom's Hardware의 1440p 게임 프레임 비율로 다른 카드에 넓혔어요. 블렌더 Open Data 점수는 RT 코어를 쓰는 Cycles 기준이라 EEVEE 계산에는 쓰지 않았어요. RTX 50 시리즈 전체를 블렌더 5.x EEVEE로 렌더한 공개 벤치마크는 아직 없어서, 실제 값은 이 범위를 벗어날 수 있어요.

표가 말해 주는 결론은 세 가지예요. 첫째, 어떤 RTX 50 카드든 약 10시간이 1~3시간대로 줄어요. 둘째, 5060급 위로는 편당 10~30분 정도만 더 빨라져요. 5090은 5080보다 약 4배 비싸지만 줄어드는 시간은 5분 남짓으로 추정돼요. 셋째, 그래픽카드를 바꾼 뒤에는 샘플을 16에서 8로 내려도 10~25분 정도만 줄어요. 샘플 절감은 내장 그래픽처럼 GPU가 느릴 때 효과가 커요.

VRAM은 이 장면 기준 약 3.5~4.5GB가 필요할 것으로 추정돼요. 8GB 카드에도 들어가지만, 더 무거운 장면이나 렌더 중에 블렌더 화면을 열어 두는 경우를 생각하면 12~16GB가 여유 있어요. Tom's Hardware는 5060 Ti 8GB와 16GB가 대부분의 작업에서 1~5% 차이였다고 보고했어요. 16GB는 장면이 8GB를 넘을 때 의미가 생겨요. 사기 전에는 파워 용량과 케이스 길이를 먼저 봐야 해요. 5070 Ti는 750W, 5080은 850W, 5090은 1000W 파워가 권장돼요.

돈 안 들이고 렌더 시간을 줄이는 방법

그래픽카드를 사기 전에 장면과 설정에서 줄일 수 있는 시간이 꽤 있어요. 효과가 큰 순서보다는 품질 위험이 낮은 순서로 놓았어요. 어떤 방법이든 몇 장면을 먼저 렌더해서 이전 결과와 나란히 비교한 뒤 전체 렌더에 적용하는 편이 안전해요.

샷마다 화면에 안 나오는 오브젝트 끄기

블렌더는 렌더에 포함된 오브젝트라면 카메라에 안 보여도 프레임마다 애니메이션과 형태를 계산하고 GPU로 보내요. 긴 영상을 한 파일에서 여러 샷으로 나눠 찍는다면, 3번 샷에만 나오는 건물과 차들이 1번 샷을 렌더할 때도 계속 계산되는 셈이에요. 오브젝트 속성의 Visibility 패널에 있는 Renders 체크(아웃라이너의 카메라 아이콘)를 끄면 그 오브젝트는 렌더 대상에서 빠지고, 이 체크는 키프레임을 넣을 수 있어서 샷 경계에서 켜고 끌 수 있어요. 컬렉션 단위로 끄면 한 번에 정리하기 쉬워요.

다만 화면 밖에 있어도 그림자나 반사로 화면에 영향을 주는 물체는 남겨야 해요. 화면 밖 건물이 도로에 드리우는 그림자, 차 유리에 비치는 주변 풍경이 대표적이에요. EEVEE에는 오브젝트별 Ray Visibility에 Camera와 Shadow 체크가 따로 있어서, 카메라에는 안 보이게 하면서 그림자는 계속 드리우게 할 수 있어요. 공식 매뉴얼은 이 옵션이 같은 효과를 셰이더 노드로 만드는 것보다 성능상 효율적이라고 설명해요. 이 방법으로 실제 몇 초가 줄어드는지는 장면 구성에 따라 크게 달라서, 무거운 샷 하나로 전후 시간을 재 보는 것이 가장 정확해요.

렌더 샘플 16에서 8로 내리기

샘플은 렌더 설정의 Sampling 패널 Render 값이에요. 앞 사례의 내장 그래픽에서는 GPU 그리기 시간이 대부분이라 16에서 8로 내리면 전체가 약 9.9시간에서 5.9~6.3시간으로 줄어들 것으로 추정돼요. 반대로 RTX 50 카드를 쓴다면 GPU 몫이 작아서 10~25분 정도만 줄어요. 샘플을 내리면 움직이는 물체 가장자리의 계단 현상과 부드러운 그림자의 얼룩이 늘 수 있으니, 그림자와 디테일이 많은 정지 컷 두세 장을 8과 16으로 뽑아 휴대폰 화면 크기에서 비교해 보고 정하면 돼요. 세로형 쇼츠는 휴대폰에서 보기 때문에 모니터에서 보이는 차이가 실제로는 잘 안 보이는 경우가 많아요.

먼 차 텍스처 줄이기와 배경 차 저폴리

4K(4096×4096) 텍스처 한 장은 압축하지 않은 RGBA 8비트 기준으로 약 64MB, 1K(1024×1024)는 약 4MB예요. 16분의 1이에요. 화면 구석을 지나가는 차가 4K 텍스처를 여러 장 쓰고 있다면 1K로 바꿔도 화면에서는 차이가 거의 안 나고 GPU 메모리와 전송량은 크게 줄어요. 블렌더 Simplify 패널의 텍스처 크기 제한은 매뉴얼상 Cycles 설정이라, EEVEE에서는 이미지 파일을 1K 버전으로 바꿔 끼우는 방법이 확실해요. 배경에 늘어선 차들은 면 수가 적은 저폴리 버전(LOD)으로 바꾸면 프레임마다 준비할 지오메트리가 줄어요. 에셋 사이트에서 같은 모델의 LOD 버전을 함께 주는 경우가 많아요.

반복 샷 재사용과 바뀐 샷만 다시 렌더

카메라와 물체가 전혀 움직이지 않는 정지 샷은 프레임 한 장만 렌더해서 영상 편집에서 길이만큼 늘이면 돼요. 인트로나 아웃트로처럼 매 편 똑같은 샷은 한 번 렌더한 파일을 계속 쓰면 되고요. 수정 사항이 생겼을 때도 전체를 다시 렌더하지 말고 바뀐 샷의 프레임 구간만 다시 뽑아 PNG 순번을 덮어쓰면 돼요. 프레임 단위 PNG로 출력하면 이렇게 부분 재렌더가 쉬워요. 영상 파일 하나로 바로 뽑으면 중간에 멈췄을 때 처음부터 다시 해야 해요.

무거운 효과는 필요한 샷에만

EEVEE의 레이트레이싱, 볼류메트릭, 모션 블러는 켜기만 하면 장면 전체에 비용이 붙어요. 공식 매뉴얼에 따르면 레이트레이싱을 끄면 미리 계산된 라이트 프로브를 쓰는 더 빠른 방식으로 바뀌고, 볼류메트릭 그림자는 "매우 계산 비용이 큰 옵션"이에요. 모션 블러는 Steps 값만큼 장면을 나눠 렌더하는데, 매뉴얼은 "각 스텝이 장면 전체를 다시 평가하는 것과 같아서 렌더 시간이 크게 늘 수 있다"고 적어 두었어요. CPU 준비 단계가 무거운 장면이라면 모션 블러 4스텝은 준비 단계도 네 번 반복된다는 뜻이에요. 반사가 중요한 클로즈업 샷에만 레이트레이싱을 켜고, 안개가 필요한 장면만 볼류메트릭을 쓰는 식으로 샷별로 나누면 나머지 구간이 빨라져요.

한 번에 전체 구간 렌더하기

Cycles에는 렌더 데이터를 메모리에 남겨 다음 프레임을 빨리 시작하는 Persistent Data 옵션이 있지만, 블렌더 5.2 매뉴얼 기준으로 이 옵션은 Cycles의 Performance 패널에만 있고 EEVEE 패널에는 없어요. EEVEE에서 쓸 수 있는 방법은 블렌더를 한 번 띄워 전체 프레임 구간을 이어서 렌더하는 거예요. 프레임마다 블렌더를 새로 실행하는 스크립트를 쓰면 파일 열기와 셰이더 컴파일이 매번 반복되는데, 앞의 장면은 첫 프레임 셰이더 컴파일에만 클라우드에서 130초가 걸렸어요.

메모리 EXPO(XMP) 켜기

내장 그래픽은 별도 그래픽 메모리 없이 시스템 메모리를 같이 써요. 그래서 메모리 속도가 곧 그래픽 성능이에요. DDR5-5600 메모리를 꽂아도 메인보드 BIOS에서 EXPO(인텔은 XMP)를 켜지 않으면 기본값인 4800으로 돌아가는 경우가 흔해요. 앞 사례의 PC도 5600 메모리가 4800으로 돌고 있었어요. EXPO를 켜면 이론 대역폭이 76.8GB/s에서 89.6GB/s로 약 17% 늘어나요. 렌더가 실제로 몇 퍼센트 빨라지는지는 공개된 측정이 없고, 그래픽카드를 따로 꽂으면 효과는 거의 사라져요. BIOS 설정이라 부팅이 안 되면 CMOS 초기화로 되돌릴 수 있다는 점도 알고 시작하는 편이 좋아요.

여러 대로 나눠 렌더하기

블렌더 매뉴얼은 EEVEE가 "여러 GPU 시스템을 지원하지 않는다"고 적고 있어요. 한 컴퓨터에 그래픽카드를 두 장 꽂아도 EEVEE 렌더 하나가 빨라지지는 않는다는 뜻이에요. 대신 프레임 구간을 나눠 여러 컴퓨터나 여러 임대 GPU에서 동시에 돌리면, 앞에서 말한 CPU 준비 시간까지 같이 나눠져요. 1번 기계는 1~1,100프레임, 2번은 1,101~2,200프레임, 3번은 나머지를 맡는 식이에요.

임대 GPU는 쓴 시간만큼 돈을 내기 때문에, 1대로 2시간 돌리나 2대로 1시간씩 돌리나 GPU 시간 합계는 같아요. 대당 붙는 준비 시간(부팅, 블렌더 다운로드, 파일 업로드, 첫 프레임 셰이더 컴파일)만 조금씩 늘어요. 아래는 vCPU 16개짜리 RTX 5090을 Vast.ai에서 빌린다고 가정한 예상치예요.

이 계산은 클라우드의 CPU 준비 시간을 코랩 실측(vCPU 2개에서 프레임당 약 12.5초)에서 vCPU 수에 반비례하게 늘려 잡고, 5090급 GPU 몫을 0.2~0.6초, 대당 준비 시간을 0.15~0.3시간으로 둔 추정이에요. 처음 한 번은 환경을 맞추느라 1~2시간 정도 인스턴스 비용이 더 들 수 있어요.

GPU 임대(Vast.ai, RunPod)와 렌더팜 비교

GPU 임대는 원격 리눅스 컴퓨터를 시간 단위로 빌려서 블렌더를 직접 설치하고 명령어로 렌더하는 방식이에요. 렌더팜은 .blend 파일을 올리면 업체가 자기 서버 여러 대에 나눠 렌더해 주는 서비스예요. 임대가 훨씬 싸지만 손이 많이 가고, 렌더팜은 비싼 대신 플러그인으로 업로드만 하면 돼요. 아래 비용은 앞의 3,287프레임 장면 한 편 기준 추정치예요.

이 장면에서 가장 중요한 숫자는 GPU 등급보다 vCPU 수예요. CPU 준비 시간이 크기 때문에, RunPod의 vCPU 6개짜리 4090이 vCPU 16개짜리 3090보다 느리고 비싸게 나와요. Vast.ai에서 매물을 고를 때도 vCPU 16개 이상, 호스트 신뢰도 0.98 이상인 것을 골라야 계산대로 나와요. 10월 20일 오전 Vast.ai 실시간 매물에서 이 조건을 만족하는 5090은 28개였고 최저 시간당 0.414달러, 중간값 0.76달러였어요. 한국에 있는 5090 호스트도 0.497달러(vCPU 16개)에 있었어요.

과금 방식의 차이도 알아 둘 만해요. Vast.ai와 RunPod은 초 단위로 과금하고, RunPod은 다운로드 트래픽이 무료예요. Vast.ai는 인스턴스를 멈춰도 디스크 요금이 계속 나가서 끝나면 삭제해야 하고, 다운로드 트래픽 요금은 호스트마다 달라요(2.8GB 결과물 기준 약 0.01~0.15달러). 최소 충전은 Vast.ai 5달러, RunPod 10달러예요. GarageFarm은 씬 로딩과 저장 시간까지 초 단위로 과금하고 대기열에 있는 시간은 받지 않아요. 가입하면 25달러 체험 크레딧을 주는데, 체험 중에는 노드 10대와 작업 30개로 제한돼요. Low 등급은 이메일 지원만 되고 24시간 지원은 Medium부터예요.

RebusFarm, Ranch, Fox처럼 OctaneBench 시간(OB시간)으로 받는 팜은 노드의 점수가 공개되지 않아 미리 계산할 수 없어요. 대부분 몇 프레임을 시험 렌더해 견적을 내 주니 그 숫자를 보고 정하면 돼요. RenderDay는 무료 시험 렌더 뒤 고정 견적을 주는 방식인데, 자사 사례로 1080p 64샘플 EEVEE 300~350프레임에 2.13~2.38유로를 공개했어요.

무료 렌더팜 SheepIt은 쓸 만한가

SheepIt은 2007년부터 운영된 블렌더 전용 무료 분산 렌더팜이에요. 회사가 서버를 두고 렌더하는 게 아니라, 전 세계 사용자가 자기 PC를 빌려주고 그 대가로 받은 포인트로 자기 프로젝트를 렌더해요. 공식 홈페이지는 Cycles, EEVEE, Workbench를 모두 지원하고 새 블렌더 버전을 며칠 안에 추가한다고 밝히고 있고, 블렌더 5.2는 2026년 7월 15일에 추가됐어요.

잭슨 정(Jackson Zheng)의 아래 영상은 SheepIt 가입부터 프로젝트 업로드, 결과 다운로드까지 보여 줘요. 영상 속 규칙 몇 가지는 공식 FAQ에 없는 내용이에요.

돌아가는 방식

영상은 구조를 양치기와 양으로 설명해요. 셰퍼드(shepherd)라고 부르는 서버가 작업을 나눠 주고, 시프(sheep)라고 부르는 사용자 PC가 실제 렌더를 해요. 공식 FAQ에 따르면 프로젝트를 올리면 애니메이션을 프레임 단위로 쪼개고, 각 PC의 메모리와 CPU, GPU 성능을 보고 프레임을 배분해요. 2023년부터는 프로젝트를 GPU나 CPU 중 한쪽에서만 렌더하도록 바뀌었어요. 2026년 8월 10일에는 2023년에 끊었던 AMD GPU 지원을 애플 GPU와 함께 되살렸는데, 운영진은 이를 대규모 시험이라고 부르며 제조사 간 결과 차이가 크면 연말에 다시 끌 수 있다고 밝혔어요.

포인트 계산은 공식 FAQ에 공식이 나와 있어요. 렌더 시간은 내 PC의 실제 시간이 아니라 기준 기계(CPU는 인텔 i5-9600, GPU는 RTX 3060)로 환산한 시간이에요. GPU 프로젝트는 기준 시간 1분당 180포인트를 쓰고, 남의 프레임을 렌더하면 1분당 684포인트를 벌어요. CPU는 각각 10포인트와 38포인트예요. 같은 시간 일하면 쓰는 것보다 약 3.8배를 버는 구조라, 남의 작업을 하루 정도 렌더해 두면 꽤 큰 프로젝트를 올릴 수 있어요. 계산 예시로, 기준 GPU에서 프레임당 6초(0.1분) 걸리는 장면이라면 3,287프레임에 약 5만 9,000포인트가 들어요. 실제 기준 시간은 장면마다 달라서 시험 렌더 전에는 알 수 없어요.

클라이언트 설정과 업로드 순서

렌더를 돕는 클라이언트는 윈도우용 실행 파일 하나로 끝나고, 리눅스와 맥은 자바만 있으면 돼요. 블렌더는 클라이언트가 알아서 받아요. 최소 사양은 RAM 8GB(여유 2GB), CPU 2코어, 디스크 여유 40GB이고, 2026년 8월부터는 블렌더 5.1을 돌릴 수 있는 기기여야 새 클라이언트를 쓸 수 있어요. 설정 화면에서는 GPU와 CPU 선택, 쓸 메모리 양, 프레임당 최대 시간, 큰 프로젝트 다운로드 차단 같은 항목을 고를 수 있어요.

설정 중에 "Block Eevee projects"라는 항목이 있어요. 영상은 EEVEE가 일부 기기를 불안정하게 만들 수 있어서 있는 옵션이라고 설명하는데, 클라이언트 안에서 이 옵션은 헤드리스(headless) 설정으로 불려요. EEVEE와 그리스 펜슬은 OpenGL 화면 컨텍스트가 있어야 렌더되는데, 모니터 없이 도는 서버형 PC는 이를 만들 수 없어서 EEVEE 프로젝트를 받지 않도록 하는 장치예요. 앞에서 본 임대 GPU의 EGL 문제와 같은 이유예요. 그래서 EEVEE 프로젝트는 이 옵션을 켜지 않은, 화면이 있는 PC로만 돌아가요.

업로드 전 준비는 이래요. 외부 텍스처를 파일 안에 묶거나(Pack Resources) 상대 경로로 바꾼 폴더를 zip으로 묶어 올려요. 블렌더 버전은 자동으로 인식되지만 바꿀 수 있고, 정식 버전만 지원해요. 영상은 GPU 대기열을 권하는데, GPU 1분이 CPU 18분 몫으로 계산될 만큼 빠르기 때문이에요. 올린 뒤에는 프로젝트 페이지의 격자에서 프레임별 진행 상황을 보고, 끝나면 결과를 내려받아요. 공식 FAQ에 따르면 포인트가 너무 많이 마이너스로 내려가면 프로젝트가 일시 정지되고, 다시 남의 프레임을 렌더하면 재개돼요.

내 파일이 남의 PC로 간다는 점

내 .blend 파일은 묶어 넣은 텍스처와 모델까지 통째로, 내가 모르는 사람들의 PC에 내려가서 렌더돼요. 클라이언트는 내려받은 프로젝트 압축을 그 PC에서 풀어 렌더하고, 작업 화면에는 마지막으로 렌더한 프레임의 미리보기가 떠요. 레딧 r/sheepit에서는 "임시 폴더에 내려온 파일은 모두 노출됐다고 가정하라, 크라우드 렌더를 쓰면서 비공개를 보장받을 수는 없다"는 답이 달렸어요(레딧).

에셋 라이선스와 부딪히는 것도 이 지점이에요. SheepIt 약관은 렌더 결과물의 권리를 주장하지 않는다고 하면서, 그 조건으로 "사용한 모든 에셋의 진짜 권리자이고 권리자의 허락을 지킬 것"을 붙여요. 파일 속 에셋을 남의 PC로 보내도 되는지는 올리는 사람이 책임져야 해요.

SheepIt은 직접 만들었거나 CC0인 에셋만 쓴, 공개해도 괜찮은 작업에 맞아요. Fab, BlenderKit 로열티 프리, Mixamo, 유료 스토어 에셋이 들어간 파일이나 공개 전 작업은 RunPod 시큐어 클라우드처럼 내가 빌린 서버에서 렌더하는 편이 안전해요. 한 사용자는 내가 관리하는 PC에서만 렌더되는 비공개 프로젝트 설정이 있다고 적었지만(GameDev.tv), 그렇게 하면 다른 사람의 PC를 빌리는 장점이 사라져요.

써 본 사람들의 반응

레딧 r/blender의 한 사용자는 GTX 1650으로 약 4시간 걸릴 애니메이션을 SheepIt에서 45분 만에 받았다고 했어요. 다만 렌더하던 사람이 PC를 끄면 계속 렌더 중으로 표시되는 프레임이 생겨서, 그런 프레임은 프로젝트를 멈추고 직접 렌더했다고 해요(레딧). 1,800프레임 Cycles 애니메이션을 두 번 올린 사용자는 15샘플 버전에 25,585포인트를 써서 47분(로컬 3090 예상 약 3.5시간), 512샘플 버전에 146,785포인트를 써서 6시간(로컬 예상 약 11시간)이 걸렸다고 했고, 로컬에서 22초인 프레임이 팜에서는 약 30초 걸리는 부가 시간이 있다고 했어요(GameDev.tv).

r/blenderhelp에서는 "로컬에서 3~4시간 안에 끝나는 작업은 올리지 않는다, SheepIt은 속도가 아니라 양을 위한 것"이라는 경험칙과 함께, NDA가 걸린 작업이나 저해상도 미리보기라도 남이 보면 안 되는 작업에는 쓰지 말라는 의견이 나왔어요(레딧). X에서도 "가벼운 작업에는 무료 SheepIt, 무거운 작업은 유료 팜"이라는 답이 있었어요(X). 이 글의 3,287프레임 EEVEE 쇼츠처럼 프레임당 렌더는 짧고 장면 준비가 긴 작업은 프레임을 한 장씩 나눠 여러 PC에 보내는 SheepIt 방식에서는 PC마다 장면을 새로 열어야 해서 부가 시간 비중이 커질 수 있어서, 처음에는 짧은 구간을 올려 실제 소요 시간과 포인트를 보는 편이 좋아요.

임대 GPU에서 EEVEE를 돌리는 순서

임대 GPU는 리눅스 컨테이너라서 EEVEE를 돌리려면 그래픽 기능(EGL)을 따로 열어 줘야 해요. 기본 설정은 계산용 CUDA만 들어오기 때문에 Cycles는 바로 되지만, EEVEE는 GPU를 못 찾고 CPU 소프트웨어 렌더(llvmpipe)로 조용히 떨어지거나 오류를 내요. 블렌더 아티스츠 포럼에서 도커 안 EEVEE가 안 되던 사례도 "graphics 기능을 켜야 한다, 기본으로는 CUDA만 켜져 있어서 Cycles만 된다"는 답으로 해결됐어요. 공식 템플릿 중 Vast.ai의 Blender 템플릿은 블렌더 3.6.2라 5.x 파일에는 맞지 않아요.

준비 순서는 이래요. 인스턴스를 만들 때 환경변수 NVIDIA_DRIVER_CAPABILITIES=all을 넣고, /usr/share/glvnd/egl_vendor.d/10_nvidia.json 파일이 libEGL_nvidia.so.0을 가리키는지 봐요. 블렌더는 서버에서 blender.org의 리눅스 버전을 직접 받는 편이 빠르고, 내 PC에서는 리소스를 모두 묶은(Pack Resources) .blend 하나만 scp나 rsync로 올리면 돼요. 서버 터미널에서 아래처럼 한 프레임을 먼저 렌더해 GPU를 제대로 잡는지 봐요.

blender -b scene.blend --debug-gpu -f 1

로그에 나오는 GL 렌더러 이름이 NVIDIA 카드면 정상이고, llvmpipe면 CPU로 떨어진 거라 바로 멈춰야 해요. 정상이면 출력 경로와 프레임 구간을 지정해 전체를 렌더해요. 아래 명령은 1~1,100프레임을 PNG로 뽑는 예시이고, 여러 대로 나눌 때는 -s와 -e 값만 바꾸면 돼요.

blender -b scene.blend -o /work/out/f_#### -F PNG -s 1 -e 1100 -a

-o 출력 경로를 꼭 지정해야 해요. 윈도우에서 저장한 파일은 출력 경로가 C:\ 같은 윈도우 경로로 들어 있어서 리눅스에서는 엉뚱한 곳에 저장될 수 있어요. 렌더가 끝나면 PNG 폴더를 압축해 내려받고 장수를 세어 본 뒤, 인스턴스를 정지가 아니라 삭제해야 요금이 멈춰요. 충전은 소액만 하고 자동 충전은 꺼 두면, 실수로 켜 둬도 잔액 이상은 나가지 않아요. 이 과정은 Vast.ai CLI와 RunPod API로 스크립트로 묶을 수 있어서, 한 번 맞춰 두면 다음 편부터는 매물 검색, 생성, 업로드, 렌더, 다운로드, 삭제를 자동으로 돌릴 수 있어요.

RunPod에서 EEVEE용 GPU 고르는 법

RunPod의 GPU 배포 화면에는 서른 종류가 넘는 GPU가 올라와 있어서, 처음 보면 무엇을 골라야 할지 막막해요. EEVEE 렌더만 놓고 보면 기준은 세 가지예요. 화면을 그리는 그래픽 기능(OpenGL, 서버에서는 EGL이라는 방식으로 씀)이 있는 카드인지, 함께 빌려주는 CPU 코어 수(vCPU)가 몇 개인지, 그리고 시간당 가격이에요. 앞에서 본 것처럼 이 장면은 프레임마다 CPU 준비 시간이 커서, 같은 값이면 GPU 등급보다 vCPU 수가 편당 비용을 더 많이 좌우해요.

아래 가격은 2026년 10월 20일 12시 21분(한국 시간) RunPod 배포 화면의 온디맨드 가격이에요. 앞의 비교표에 쓴 10월 8일 요금표와 다르고, 예를 들어 RTX 4090은 시간당 0.89달러에 vCPU 8개, RTX 3090은 0.50달러에 vCPU 6개로 나와 있었어요. 같은 GPU라도 붙어 나오는 vCPU와 RAM은 시점과 재고에 따라 바뀌니, 배포 직전에 화면에서 다시 보는 편이 안전해요.

데이터센터 연산 카드와 MIG 조각은 빼요

목록 위쪽의 A100, H100, H200, B200, B300, MI300X, MI350X는 AI 학습과 과학 계산용 카드예요. NVIDIA는 A100 백서에서 이 카드에 디스플레이 출력, RT 코어, NVENC 인코더가 없다고 밝혔고, 가상화 기술 문서에서는 H100, A100, A30이 그래픽 작업을 지원하지 않는다고 적었어요. H100 아키텍처 문서도 H100이 그래픽 처리용이 아니며, 화면을 그리는 셰이더를 돌릴 수 있는 블록이 칩 전체에서 두 개뿐이라고 설명해요. EEVEE는 바로 이 래스터 그래픽 파이프라인으로 그리기 때문에, 시간당 수 달러를 내고도 제대로 돌지 않거나 아주 느릴 가능성이 커요. B200과 B300도 NVIDIA가 AI용으로 내놓은 데이터센터 카드라 EEVEE 렌더에 맞는 선택이 아니고, 가격도 시간당 7.99~8.99달러예요.

AMD의 MI300X와 MI350X는 계산 전용 설계(CDNA)를 쓰는데, AMD 백서는 이 설계에서 화면을 그리는 데 쓰는 그래픽 전용 하드웨어와 디스플레이 엔진을 모두 덜어 냈다고 설명해요. EEVEE가 쓰는 OpenGL 그래픽 경로가 없는 셈이라 후보에서 빠져요.

B300 MIG 34GB, PRO 6000 MIG 24GB처럼 이름에 MIG가 붙은 항목은 GPU 한 장을 여러 조각으로 나눈 상품이에요. NVIDIA MIG 문서는 MIG 모드에서 OpenGL, Vulkan 같은 그래픽 API를 지원하지 않는다고 적고 있어요. RTX PRO 6000 블랙웰만 그래픽을 켠 일부 MIG 프로필(+gfx)을 예외로 두지만, RunPod 목록의 PRO 6000 MIG가 어떤 프로필인지는 배포 화면에 나오지 않아요. 게다가 24GB 조각은 vCPU가 4개라 CPU 준비 시간이 길어지고, vCPU 16개인 48GB 조각은 시간당 1.29달러로 더 싼 일반 카드보다 비싸요.

편당 예상 비용으로 줄 세우면

아래 표의 편당 비용은 같은 3,287프레임 장면 기준 추정치예요. 프레임당 CPU 시간은 vCPU 2개에서 약 12.5초였던 실측을 vCPU 수에 반비례하게 줄이고(16개를 넘으면 더 줄지 않는다고 봄), 카드 등급에 따라 GPU 시간 0.2~1.4초와 포드 준비 시간 0.15~0.3시간을 더한 값이에요. RTX PRO 4000, PRO 4500, RTX 2000 Ada, A4500은 공개된 EEVEE 측정이 없어서 같은 세대 카드와 비슷하다고 보고 넣은 값이라 오차가 더 클 수 있어요.

표를 보면 vCPU가 적은 카드가 얼마나 손해인지 바로 보여요. RTX 4090은 GPU만 보면 위쪽 카드지만 vCPU가 8개라 시간당 0.25달러짜리 A4500보다 느리고 서너 배 비싸게 나와요. RTX 3090도 vCPU 6개 때문에 예전 요금표에서 보던 가성비가 사라졌어요. 반대로 L40은 vCPU 32개에 RAM 250GB가 붙어 나와서, 16개를 넘는 vCPU가 조금이라도 도움이 된다면 표보다 더 빠를 수 있어요. VRAM은 이 장면 기준 4GB 안팎으로 추정되니 목록의 어떤 카드도 모자라지 않아요.

가장 싼 선택, 균형 잡힌 선택, 가장 빠른 선택

비용만 보면 RTX A4500 한 대가 가장 싸요. 편당 약 630~1,040원, 시간은 1.9~3.1시간으로 추정돼요. 자기 전에 걸어 두고 아침에 받는 용도라면 이걸로 충분해요. 배포 화면에 최대 대수가 표시되지 않았으니, 재고가 있으면 네 대로 나눠 35~60분에 약 780~1,340원으로 끝낼 수도 있어요.

시간과 비용의 균형은 RTX PRO 4000 네 대(화면상 최대 4대)가 좋아요. 네 대로 나누면 35~60분, 편당 약 1,770~3,040원으로 추정돼요. 한 대만 쓰고 싶다면 vCPU 32개짜리 L40 한 대가 1.4~2.3시간, 약 1,480~2,480원이에요.

가장 빨리 받아야 할 때는 RTX 6000 Ada 일곱 대가 계산상 가장 효율적이에요. 21~37분에 편당 약 3,170~5,630원으로, 같은 일곱 대 기준 L40S(19~35분, 약 3,280~5,910원)나 RTX 5090(20~36분, 약 3,690~6,600원)과 속도는 비슷하면서 조금 싸요. A40 열 대도 22~39분, 약 2,900~5,060원으로 나오지만 대수가 많을수록 업로드와 셰이더 컴파일 같은 대당 준비 시간이 늘어서, 일곱 대를 넘기면 시간은 거의 줄지 않고 비용만 늘어요. 대수가 늘면 대당 준비 시간이 전체 시간의 절반 가까이를 차지하기 때문이에요.

RunPod 세팅 순서

템플릿은 기본값인 PyTorch 이미지(Ubuntu 24.04, CUDA 12.8)를 그대로 써도 돼요. 블렌더는 따로 받아서 실행하니 이미지 안의 PyTorch는 쓰지 않아요. 중요한 건 그래픽 드라이버 기능이에요. 컨테이너에는 기본으로 계산용 CUDA만 들어와서, 배포할 때 환경변수에 NVIDIA_DRIVER_CAPABILITIES를 all(최소한 graphics 포함)로 넣어야 EEVEE가 GPU를 잡아요. 코랩에서 같은 장면을 돌렸을 때는 EGL 벤더 폴더에 Mesa용 파일(50_mesa.json)만 있어서 EGL_BAD_MATCH 오류와 함께 GPU 메모리를 전혀 쓰지 않는 소프트웨어 렌더로 떨어졌고, NVIDIA용 벤더 파일을 만들어 __EGL_VENDOR_LIBRARY_FILENAMES 환경변수로 지정한 뒤에야 GPU를 잡아 VRAM을 약 3GB 썼어요. 포드 터미널에서 아래처럼 벤더 파일을 확인하고, 없으면 만들어요.

ls /usr/share/glvnd/egl_vendor.d/
cat > /usr/share/glvnd/egl_vendor.d/10_nvidia.json <<'J'
{"file_format_version":"1.0.0","ICD":{"library_path":"libEGL_nvidia.so.0"}}
J
export __EGL_VENDOR_LIBRARY_FILENAMES=/usr/share/glvnd/egl_vendor.d/10_nvidia.json

저장 공간은 두 종류를 구분해야 해요. RunPod 문서에 따르면 컨테이너 디스크(이번 화면 기준 50GB)는 포드를 멈추면 지워지고, /workspace에 붙는 볼륨 디스크는 포드를 삭제할 때까지 남아요. 네트워크 볼륨은 포드와 따로 존재해서 여러 포드에 붙일 수 있어요. 블렌더와 .blend 파일, 렌더 결과는 /workspace에 두는 편이 안전하고, 여러 대로 나눌 때 같은 파일을 반복해서 올리기 싫다면 네트워크 볼륨에 한 번 올려 두고 각 포드에 붙이면 돼요. 네트워크 볼륨은 포드를 만들 때 붙여야 하고 나중에 뗄 수 없어요.

파일 전송은 RunPod 포드에 미리 설치된 runpodctl이 가장 간단해요. 내 PC에서 runpodctl send scene.blend를 실행하면 일회용 코드가 나오고, 포드에서 runpodctl receive 코드로 받으면 돼요. 문서는 큰 파일에는 SSH를 설정한 뒤 scp나 rsync를 권해요. 블렌더는 포드에서 공식 리눅스 버전을 바로 받아 풀면 돼요. 코랩에서는 블렌더 실행에 필요한 X11, GL 라이브러리가 빠져 있어서 libxi6, libxkbcommon0, libxkbcommon-x11-0, libsm6, libxrender1, libxxf86vm1, libxfixes3, libgl1, libegl1을 apt로 설치해야 했어요. 포드 이미지에도 빠져 있으면 같은 패키지를 설치하면 돼요.

cd /workspace
wget https://download.blender.org/release/Blender5.2/blender-5.2.2-linux-x64.tar.xz
tar -xf blender-5.2.2-linux-x64.tar.xz
./blender-5.2.2-linux-x64/blender -b scene.blend --debug-gpu -f 1

로그의 GL 렌더러 이름이 NVIDIA 카드인지 본 다음, 전체를 걸기 전에 50~100프레임만 먼저 렌더해서 프레임당 시간을 재요. 이 숫자에 전체 프레임 수를 곱하면 표의 추정치가 맞는지, 어떤 카드가 실제로 가장 싼지 바로 알 수 있어요. 아래 첫 줄이 시험 렌더이고, 둘째 줄부터는 네 대로 나눌 때 각 포드에서 돌릴 구간 예시예요.

time ./blender-5.2.2-linux-x64/blender -b scene.blend -o /workspace/out/f_#### -F PNG -s 1 -e 80 -a
# 포드 1: -s 1 -e 822 / 포드 2: -s 823 -e 1644 / 포드 3: -s 1645 -e 2466 / 포드 4: -s 2467 -e 3287
./blender-5.2.2-linux-x64/blender -b scene.blend -o /workspace/out/f_#### -F PNG -s 1 -e 822 -a

렌더가 끝나면 결과 폴더를 tar로 묶어 runpodctl이나 scp로 내려받고, 장수가 맞는지 센 다음 포드를 삭제(terminate)해요. RunPod 요금 문서 기준으로 멈춘(stop) 포드는 GPU 요금은 나가지 않지만 볼륨 디스크가 GB당 월 0.20달러로 계속 청구되고, 컨테이너 디스크만 과금되지 않아요. 네트워크 볼륨은 포드를 지워도 남아서 GB당 월 0.07달러가 계속 나가니, 다음 편에도 쓸 게 아니라면 함께 지워요. 잔액이 0이 되면 네트워크 볼륨이 없는 포드는 데이터째 삭제된다는 점도 알아 둘 만해요.

요금제도 고를 수 있어요. 시큐어 클라우드는 T3/T4 데이터센터에서 돌고, 커뮤니티 클라우드는 심사를 거친 개인 호스트 서버라 더 싸지만 안정성이 들쭉날쭉할 수 있어요. RunPod은 커뮤니티 클라우드에 새 호스트를 더 받지 않는다고 밝혔고, 기존 자원은 계속 쓸 수 있어요. 스팟(인터럽터블) 포드는 더 싸지만 언제든 중단될 수 있어요. PNG를 프레임마다 /workspace에 저장하고 있다면 중단돼도 마지막으로 저장된 다음 프레임부터 -s 값을 바꿔 이어서 렌더하면 되니, 급하지 않은 렌더에는 쓸 만해요. 온디맨드 포드를 띄우려면 선택한 구성의 1시간치 이상 잔액이 있어야 해요.

영상으로 보는 RunPod 블렌더 렌더 전략

라울 아히레(Rahul Ahire)가 올린 아래 영상은 RunPod에서 RTX 4090을 빌려 블렌더를 렌더하는 과정을 처음부터 끝까지 보여 줘요. RunPod의 후원을 받은 영상이라 장점 위주로 흘러가지만, 요금제 선택과 파일 저장, 다운로드에서 실수하기 쉬운 지점을 실제 화면으로 짚어 줘요.

영상 속 가격은 촬영 당시 기준이라 지금과 달라요. 현재 요금은 이 절 앞의 10월 20일 12시 21분 화면 표를 보면 돼요.

작업은 주피터(Jupyter) 템플릿으로 포드를 띄우고 모든 파일을 /workspace에 둔 다음, 자신이 만든 설치 스크립트를 wget으로 받아 실행해요. 이 스크립트는 고른 버전의 블렌더와 필요한 라이브러리를 설치하고, GPU가 있으면 GPU로, 없으면 CPU로 렌더하도록 잡아 줘요. 블렌더 버전은 .blend를 저장한 버전에 맞추라고 강조해요. 새 버전은 대개 옛 파일을 열지만, 옛 버전은 새 지오메트리 노드를 읽지 못하기 때문이에요.

렌더 설정은 명령어보다 파일 안에서 끝내라는 쪽이에요. 프레임 구간과 출력 형식을 .blend 안에서 지정하고 제대로 저장해야 하는데, 저장이 덜 된 파일은 "missing DNA block" 오류로 열리지 않았다고 해요. 그다음 -f 1로 한 프레임을 시험하고 -a로 전체를 걸어요. 영상 제작자는 프레임 구간을 정하는 명령행 옵션이 잘 먹지 않았다고 말하는데, 원인은 영상에 나오지 않아요. 블렌더 매뉴얼은 명령행 인자를 적힌 순서대로 처리한다고 설명하니, 구간을 나눌 때는 앞의 예시처럼 -s와 -e를 -a보다 앞에 두는 게 중요해요. 렌더는 노트북 셀이 아니라 터미널 탭에서 돌려야 로그를 읽기 편하다는 팁도 있어요.

이 영상을 EEVEE 쇼츠에 옮길 때

영상의 시험 렌더는 Cycles였어요. 디노이즈 커널을 준비하는 과정이 로그에 나오는 것도 그래서예요. Cycles는 CUDA만 있으면 GPU를 잡기 때문에, 영상 속 순서만 따라 하면 EEVEE에서는 GPU를 못 잡고 CPU 소프트웨어 렌더로 떨어질 수 있어요. EEVEE를 쓴다면 앞의 세팅 순서에 있는 NVIDIA_DRIVER_CAPABILITIES 환경변수와 EGL 벤더 파일 설정을 그대로 해야 하고, --debug-gpu로 한 프레임을 돌려 GL 렌더러가 NVIDIA 카드인지 먼저 봐야 해요.

시큐어와 커뮤니티의 속도 차이도 그대로 옮겨 오기는 어려워요. 영상의 19초와 41초는 Cycles 렌더에서 나온 숫자이고, 앞의 표에서 본 EEVEE 장면은 프레임마다 CPU 준비 시간이 커서 vCPU 수가 결과를 더 크게 좌우해요. 시큐어를 고르라는 권고와 결과를 묶어서 받으라는 팁, 쓰고 나면 삭제하라는 습관은 EEVEE에도 그대로 통해요.

RunPod으로 블렌더를 렌더한 사람들의 반응

X에서는 RunPod 5090 여섯 대로 블렌더 렌더를 나눠 돌린 라일리 브라운의 글 이후 반응이 많았어요. 한 사용자는 "블렌더 장면을 렌더하려고 H100을 사는 건 휴대폰 충전하려고 발전소를 사는 셈이고, 5090 여섯 대를 한 번에 3달러로 빌리는 게 핵심"이라고 답했어요(X). 다른 사용자는 "RunPod에서 헤드리스 블렌더로 프레임 구간을 여러 포드에 나눈 뒤 합치라"고 조언했고(X), 이후 3,487프레임을 RunPod에서 20분 안에 1달러 미만으로 렌더했다는 보고를 소개한 글은 그 숫자가 렌더 비용만이고 전체 작업 비용은 아니며, 글쓴이도 같은 결과를 내 본 것은 아니라고 단서를 달았어요(X). 프레임 수는 앞 사례와 비슷하지만 렌더 엔진과 장면이 달라서 그대로 비교할 수는 없어요.

레딧 r/blender에서는 "RunPod이 보장형 RTX 4090을 시간당 약 0.34~0.39달러, 초 단위 과금에 다운로드 요금 없이 제공한다"는 댓글이 있었는데(레딧), 10월 20일 화면의 온디맨드 4090은 0.89달러라 시점과 요금 종류에 따라 차이가 커요. 반대로 "RunPod을 써 봤는데 렌더보다 세팅에 시간을 더 썼다"는 댓글도 있었어요. 다른 서비스를 홍보하는 글에 달린 말이라 걸러 들을 필요는 있지만, 처음 한 번은 EGL과 저장 공간 설정에 시간이 든다는 점은 앞의 순서와 맞아요(레딧).

보안과 에셋 라이선스

BlenderKit이나 Fab에서 받은 에셋이 들어간 파일을 남의 서버에 올려도 되는지는 약관 문구를 보면 방향이 보여요. BlenderKit의 로열티 프리(RF) 라이선스는 렌더 이미지와 애니메이션 판매를 허용하고, 금지하는 것은 에셋 자체를 다른 마켓에 파는 것이에요. BlenderKit 매뉴얼에는 렌더팜이나 다른 작업용 컴퓨터로 옮기기 위해 에셋 폴더를 묶는 기능도 안내돼 있어요. Fab 표준 라이선스는 "프로젝트를 함께 작업하는 협업자와 비공개 저장소나 프로젝트 안에서 공유할 수 있다"고 하고, 에셋을 단독으로 재배포하는 것을 금지해요. 내 작업을 렌더하려고 계약한 렌더팜이나 내가 빌린 GPU에 비공개로 올리는 것은 이 범위 안으로 읽혀요. 법률 자문이 필요한 상업 프로젝트라면 에셋 판매처에 직접 문의하는 편이 확실해요.

SheepIt은 사정이 달라요. 내 .blend 파일이 불특정 다수의 기부자 PC로 내려가서 렌더되기 때문에, 유료 에셋이 들어간 파일을 올리면 에셋 재배포에 가까워져요. 에셋별로 어디까지 괜찮은지는 앞의 SheepIt 절에 표로 묶어 두었어요. 내 PC의 EEVEE에서는 멀쩡하던 연기 표현이 SheepIt 결과물에서는 뿌옇게 나왔다는 후기도 있어요.

Vast.ai의 일반 매물은 개인이 내놓은 PC라 파일이 남의 디스크에 잠시 머물러요. 라이선스 위반이라기보다 보안의 문제예요. 미공개 작업이라면 데이터센터 표시가 있는 매물이나 RunPod 시큐어 클라우드를 고르고, 렌더가 끝나면 인스턴스를 삭제하는 편이 안전해요. GarageFarm은 자매사가 ISO 27001 인증을 받았고 NDA를 맺을 수 있으며, 파일은 마지막 작업 28일 뒤 삭제한다고 안내해요.

사용자 후기와 반응

GPU 임대를 써 본 사람들은 싸다는 점과 손이 많이 간다는 점을 함께 말해요. 레딧 r/blender의 한 사용자는 Vast.ai에서 RTX 5090을 시간당 0.36달러에 빌릴 수 있다면서도 "블렌더와 렌더 환경을 직접 설정해야 하고, 랜덤 판매자의 GPU라 데이터가 완전히 비공개는 아니다"라고 적었어요(레딧). 다른 사용자도 "Vast.ai를 추천하지만 블렌더에서 돌아가게 만드는 데 꽤 품이 든다"고 했어요(레딧). 2026년 2월에는 EEVEE와 그리스 펜슬 때문에 Vast에서 직접 렌더하는 것을 포기했다는 글도 올라왔는데(레딧), 앞에서 본 EGL 설정이 바로 이 문제를 푸는 부분이에요.

렌더팜 쪽에서는 숨은 비용 이야기가 많아요. RenderStreet에서 EEVEE를 돌린 사용자는 "로컬 GTX 1080에서 4초인 프레임이 서버에서는 4분 세팅에 20초씩 걸렸고, 작업을 서버 10대로 나누면서 4분 세팅이 40분으로 청구됐다"고 했어요(레딧). RebusFarm을 처음 써 본 사용자는 240프레임 견적이 100~120유로였고, 로컬 M3 Max에서 1분 5초인 프레임이 팜에서 1분 40초~3분 걸렸으며 체험판 결과물에 워터마크가 찍혔다고 했어요. 같은 글에는 "클라우드에 직접 세팅할 줄 알면 240프레임에 2~3달러면 된다, 아니면 관리형 서비스 값을 내는 것"이라는 답글이 달렸어요(레딧).

반면 렌더팜의 편의성을 높이 사는 후기도 있어요. GarageFarm을 10년 썼다는 사용자는 "씬 업로드 플러그인이 94% 정도는 잘 되고, 빨리 알리면 실패한 렌더를 일부 환불해 준다"고 했고(레딧), RebusFarm을 10년 쓰다 GarageFarm으로 옮겼다는 3ds Max 사용자는 "UI와 사용성이 훨씬 낫다"고 평했어요(레딧). 기계를 통째로 빌리는 방식에 대해서는 "켜져 있는 동안 계속 요금이 나가고, 사람들이 여기서 돈을 날린다, 나도 그랬다"는 경고가 있어요(레딧). 레딧의 렌더팜 추천 댓글 중에는 업체 직원이나 홍보 계정이 쓴 글이 꽤 많아서, 구체적인 숫자와 경험이 있는 글 위주로 보는 편이 좋아요.

X에서는 RunPod으로 블렌더 렌더를 나눠 돌린 사례가 화제가 됐어요. 라일리 브라운은 지하철에서 블렌더 장면을 편집하면서 렌더는 RunPod의 RTX 5090 6대로 넘겼다고 올렸고(X), 답글에서는 약 20분에 3달러 정도였다는 계산이 나왔어요(X). 다른 사용자는 "RunPod에 10달러를 충전하고 API 키를 만드는 게 전부였고, 해 보니 됐다"고 적었어요(X).

전문 스튜디오는 렌더 시간을 어떻게 다루나

렌더를 기다리는 건 혼자 작업하는 사람만의 문제가 아니에요. 영화 스튜디오도 기다리고, 오히려 더 오래 기다려요. 다른 점은 기다리는 시간을 미리 계산해서 일정에 넣고, 기계를 많이 쓰고, 같은 렌더를 두 번 하지 않도록 작업 방식을 짜 둔다는 거예요. 규모는 비교가 안 되지만, 그 방식 대부분은 집 PC 한 대로도 그대로 따라 할 수 있어요.

영화 한 프레임에 몇 시간씩 걸려요

1995년 토이 스토리는 듀얼 프로세서 87대와 쿼드 프로세서 30대, 모두 117대의 SPARCstation 20으로 렌더했어요. 당시 SunWorld 기사에 따르면 11만 프레임을 렌더하는 데 연속 처리 기준 46일이 걸렸고, 프레임 하나에 프로세서 시간으로 1~3시간이 들었어요. 픽사 창업자이자 최고기술책임자였던 에드 캣멀은 "1,000배 더 많은 성능이 있어도 어디에 쓸지 정확히 안다"고 말했는데, 실제로 기계는 계속 늘었어요. 2013년 몬스터 대학교 때 픽사의 렌더팜은 컴퓨터 2,000대, 코어 24,000개 이상으로 커졌지만, 감독 기술 책임자 산제이 박시는 최종 품질 프레임 하나에 약 29시간이 걸렸다고 했어요. 영화 전체에는 1억 CPU시간 이상이 들었어요.

장면이 복잡해지는 속도가 컴퓨터가 빨라지는 속도를 따라잡기 때문에 이런 일이 생겨요. 디즈니 애니메이션은 빅 히어로 6를 위해 네 지역에 나눠 둔 컴퓨터 4,600대, 코어 55,000개를 하나의 시스템처럼 묶었고, 기네스 세계기록은 이를 영화 제작에 쓰인 가장 큰 연산 규모로 올렸어요. 이 클러스터는 하루 40만 개의 렌더 작업을 처리할 수 있었다고 해요. 웨타 디지털은 아바타를 시작할 무렵 약 4,400코어였던 렌더 장비를 제작 막바지에 약 35,000코어까지 늘렸고, 제작 중에는 매일 처리할 수 있는 양보다 더 많은 작업이 대기열에 쌓여 있었다고 회고했어요.

사내 렌더팜에 나눠 돌리고, 바쁠 때는 클라우드를 빌려요

스튜디오의 아티스트는 자기 작업용 컴퓨터로 최종 렌더를 하지 않아요. 렌더 작업을 Deadline이나 Tractor 같은 렌더 관리 프로그램에 넣으면, 프로그램이 대기열을 관리하면서 프레임을 렌더 전용 컴퓨터(노드) 수십~수천 대에 나눠 줘요. 웨타 디지털은 아바타 제작이 정점일 때 픽사의 대기열 프로그램 Alfred로 1만 개가 넘는 작업과 하루 130만~140만 개의 세부 작업을 돌렸다고 알려졌어요.

사내 장비가 모자랄 때는 클라우드를 잠깐 빌려 써요. AWS의 렌더 관리 서비스 Deadline Cloud 문서는 사내 렌더팜에 클라우드 작업 컴퓨터를 같은 농장으로 붙여서, 수요가 몰릴 때 넘치는 작업을 클라우드로 보내는 방식을 "클라우드 버스팅(cloud bursting)"이라고 설명해요. 실제로 스카이댄스 애니메이션은 큰 사내 렌더팜을 갖고 있었지만 영화 럭(Luck)의 최대 수요를 감당하기에는 부족해서, AWS의 저렴한 스팟 인스턴스로 렌더를 늘리는 체계를 만들었어요.

낮에는 작업하고, 렌더는 밤에 돌려요

렌더 장비는 사람이 퇴근한 시간에 가장 바쁘게 일해요. 레딧 r/vfx의 한 사용자는 스튜디오 렌더 방식을 설명하면서 "큰 렌더도 다른 기계에서 돌기 때문에 누구의 컴퓨터도 묶어 두지 않고, 보통 밤사이나 다른 사람 작업 사이의 빈틈에 돈다"고 적었어요(레딧). 같은 댓글은 필요한 시간을 "프레임 수 곱하기 프레임당 시간 나누기 기계 수"로 계산하고, 마감보다 길면 기계를 더 구한다고 덧붙였어요.

미리보기로 확인하고 최종 렌더는 한 번만 해요

픽사 애니메이터는 최종 렌더 대신 자체 프로그램 프레스토에서 동작을 초당 약 8프레임으로 재생해 보며 장면이 맞는지 확인해요. 몬스터 대학교에 참여한 픽사 애니메이터 클라크(Clark)는 VentureBeat 인터뷰에서 배우는 20번 다시 찍을 수 있지만 애니메이션은 최종 렌더 비용 때문에 "20가지 버전을 만들 수 없다"고 말했어요. 그래서 동작, 카메라, 타이밍은 가벼운 미리보기로 모두 확정하고, 최종 품질 렌더는 확정된 장면에만 걸어요.

블렌더에도 같은 도구가 있어요. 5.2 매뉴얼 기준으로 3D 뷰포트의 View 메뉴에 있는 Render Playblast는 뷰포트 화면 그대로 애니메이션을 빠르게 뽑아 주고, Workbench와 EEVEE에서 쓸 수 있어요. Render Playblast on Keyframes를 쓰면 키프레임이 있는 프레임만 그리고 나머지는 앞 프레임을 반복해서 더 빨라요. X의 3D 아티스트 @WittyDZN도 F1 영상의 비 효과를 플레이블라스트 미리보기로 먼저 공개하고 "최종 렌더 준비가 끝났다"고 올렸어요(X).

샷과 레이어로 쪼개고, 바뀐 것만 다시 렌더해요

스튜디오는 영상을 샷 단위로 나누고, 한 샷 안에서도 캐릭터, 배경, 이펙트를 따로 렌더한 뒤 합성(컴포지팅)에서 합쳐요. 수정 요청이 오면 바뀐 부분만 다시 렌더하면 되니까요. 블렌더 매뉴얼은 뷰 레이어(View Layers)를 "렌더를 여러 레이어로 나눠 나중에 합성할 수 있게 해 주는 기능"이라고 설명하고, 바뀐 레이어만 다시 렌더할 수 있어서 수정 작업 때 성능과 유연성이 좋아진다고 적어 두었어요. 색, 빛, 깊이, 노멀 같은 정보를 따로 뽑는 패스(Passes)는 EEVEE에서도 쓸 수 있고, 컴포지터의 Render Layers 노드에서 다시 조합해요. 토이 스토리 때 픽사 운영 담당자가 "대체할 수 없는 데이터만 백업하고, 나머지는 언제든 다시 렌더할 수 있다"고 말한 것도 같은 맥락이에요.

장면을 가볍게 만드는 건 스튜디오도 마찬가지예요

픽사 렌더맨의 모델링 가이드는 무거운 폴리곤 모델이 "화면에서 아무리 작게 보여도 메모리를 많이 쓴다"고 경고하고, 변위가 없는 무거운 메시는 화면을 가득 채우든 2픽셀 높이든 같은 메모리를 쓴다고 설명해요. 그래서 세밀한 모델은 가벼운 모델과 변위 맵으로 바꾸고, 렌더러가 화면 크기에 따라 디테일을 자동으로 줄이게 해요. 디즈니는 자사 렌더러 하이페리온을 소개하면서 "멀리 있는 풍경을 그림으로 흉내 내는 트릭 없이" 샌프란소쿄 전체를 렌더할 수 있게 됐다고 강조했는데, 거꾸로 말하면 그전까지는 먼 배경을 그림이나 가벼운 대체물로 처리하는 게 흔한 방법이었다는 뜻이에요. 앞에서 다룬 먼 차 텍스처 줄이기, 배경 차 저폴리, 안 보이는 오브젝트 끄기가 바로 이 방법의 개인 버전이에요.

광고, 방송, 유튜브는 실시간 엔진으로 넘어가는 중이에요

언리얼 엔진 같은 게임 엔진은 프레임을 실시간으로 그리기 때문에 렌더 대기 자체가 거의 없어요. ILM과 에픽게임즈에 따르면 드라마 만달로리안 시즌 1은 절반 이상을 LED 벽으로 둘러싼 스테이지에서 찍었고, 벽에 나오는 배경은 동기화된 PC 네 대에서 언리얼 엔진으로 실시간 렌더했어요. 영국 제작사 Quite Brilliant는 TV 광고에 같은 방식을 쓰려고 시험 영상을 찍은 뒤 "후반 작업 대부분이 사전 제작으로 옮겨 온다"고 했어요. 에픽게임즈는 방송과 라이브 이벤트용으로 실시간 합성과 가상 스튜디오 기능을 내세우고 있고, WWE 행사에서 결과물 400개를 2주 만에 렌더한 사례를 소개해요. 유튜브에서는 코리 윌리엄스가 어린이 채널의 크로커다일 캐릭터 영상을 혼자 언리얼 엔진으로 만들며 한 편을 며칠 만에 완성한다고 알려졌어요. 블렌더의 EEVEE도 같은 래스터 방식이라, 품질 요구가 맞는다면 프레임당 몇 초 안에 끝나는 쪽을 고르는 것 자체가 업계의 흐름과 맞아요.

혼자 작업하는 크리에이터는 이렇게 해요

개인 크리에이터에게 수천 대짜리 렌더팜은 없지만, 방식은 비슷하게 가져갈 수 있어요. 레딧 r/blender에서 친구의 뮤직비디오를 만든 사용자는 장면을 나눠 RTX 2080 한 대로 몇 주 동안 밤마다 렌더했다고 하면서, 결과를 미리 보고 싶을 때는 샘플을 크게 낮춰서 보라고 조언했어요(레딧). r/vfx의 다른 사용자는 클라우드 렌더 견적을 낼 때 가장 가벼운 프레임, 가장 무거운 프레임, 보통 프레임 3~5장을 실제 장비에서 렌더해 보고, "첫 최종본이 마지막인 경우는 드무니" 전체 재렌더 한 번 분량을 예산에 넣으라고 했어요(레딧). 결국 좋은 GPU 한 대로 밤에 렌더하는 것을 기본으로 두고, 마감이 급하거나 수정이 몰릴 때만 임대 GPU나 렌더팜을 붙이는 구조예요.

예산과 상황별 추천

결론은 상황마다 달라요. 렌더가 일주일에 한두 편이고 밤새 돌려도 괜찮다면 돈을 쓸 이유가 크지 않고, 매일 올려야 하거나 블렌더 화면 자체가 버벅인다면 그래픽카드가 답이에요.

그래픽카드는 렌더 시간만 사는 게 아니라 블렌더 작업 화면의 속도도 같이 사는 거예요. 면이 400만 개 넘는 장면을 내장 그래픽으로 편집하면 화면이 끊기는데, 임대 GPU는 렌더만 대신해 줄 뿐 작업 화면은 빨라지지 않아요. 반대로 비용만 보면 임대가 압도적이에요. 편당 1천~3천 원대인 임대 비용으로 5060 Ti 16GB 값을 채우려면 약 300~1,400편이 필요해요(추정). 5070 Ti, 5080, 5090은 이 장면 기준으로 5070보다 편당 5~20분 정도만 빨라서, 렌더만 보면 35만~640만 원을 더 낼 이유가 약해요.

렌더 시간 줄이기 체크리스트

렌더를 걸기 전에 아래 항목을 차례로 보면 대부분의 낭비를 줄일 수 있어요.

• 무거운 샷 하나를 골라 프레임당 시간을 먼저 재고, 전체 프레임 수를 곱해 예상 시간을 계산한다
• 샷마다 화면에 안 나오는 오브젝트와 컬렉션의 Renders를 끄되, 그림자와 반사를 만드는 물체는 남긴다
• 정지 컷 두세 장을 샘플 8과 16으로 뽑아 휴대폰 크기에서 비교한 뒤 샘플을 정한다
• 멀리 지나가는 차와 소품은 1K 텍스처와 저폴리 버전으로 바꾼다
• 레이트레이싱, 볼류메트릭, 모션 블러는 필요한 샷에만 켜 둔다
• 출력은 프레임별 PNG로 하고, 수정이 생기면 바뀐 구간만 다시 렌더한다
• 내장 그래픽을 쓴다면 BIOS에서 메모리 EXPO나 XMP가 켜져 있는지 본다
• GPU를 빌릴 때는 vCPU 16개 이상을 고르고, 첫 프레임 로그에서 NVIDIA GPU를 잡았는지 확인한 뒤 전체를 건다
• 임대 렌더가 끝나면 결과물 장수를 센 다음 인스턴스를 정지가 아니라 삭제한다
• 유료 에셋이 들어간 파일은 SheepIt 같은 공용 팜에 올리지 않는다

마무리

앞에서 다룬 블렌더 EEVEE 렌더 시간 줄이기에서 기억해 둘 것만 추리면 이래요.

• 프레임 한 장은 CPU 준비와 GPU 그리기의 합이고, 그래픽카드는 GPU 몫만 줄여 줘요
• 내장 그래픽으로 약 10시간 걸리던 3,300프레임 장면은 어떤 RTX 50 카드로든 1~3시간대로 줄어들 것으로 추정돼요
• 5060급 위로는 편당 10~30분 차이라, 렌더만 보면 5060 Ti 16GB나 5070이 가격 대비 균형이 좋아요
• 샘플 16에서 8은 내장 그래픽에서 약 4시간을 줄이지만 RTX 50에서는 10~25분 수준이에요
• GPU 임대는 편당 수백~수천 원으로 가장 싸고, vCPU 수가 GPU 등급보다 중요해요
• 렌더팜은 편당 수천~수만 원이지만 업로드만 하면 되고, 유료 에셋 파일은 비공개 서버나 계약된 팜에만 올려요

「렌더 시간은 장수 곱하기 프레임당 시간이다」 무거운 샷 하나의 프레임당 시간을 먼저 재고, 장면 정리로 줄일 수 있는 만큼 줄인 다음에 카드 구입이나 임대를 정하면 돈과 시간을 같이 아낄 수 있어요.

출처와 링크

• Blender 5.2 LTS 매뉴얼: EEVEE Limitations (CPU 준비, 다중 GPU, 헤드리스)
• Blender 5.2 LTS 매뉴얼: EEVEE Sampling
• Blender 5.2 LTS 매뉴얼: EEVEE Motion Blur
• Blender 5.2 LTS 매뉴얼: EEVEE Raytracing
• Blender 5.2 LTS 매뉴얼: EEVEE Object Properties (Ray Visibility)
• Blender 5.2 LTS 매뉴얼: Cycles Performance (Persistent Data)
• Blender 5.2 LTS 매뉴얼: Simplify
• NVIDIA GeForce 그래픽카드 사양 비교
• ComputerBase 3DMark Time Spy 그래픽 점수
• LessWork Lab GPU 순위 (Tom's Hardware 1440p 측정)
• Tom's Hardware RTX 5060 Ti 8GB와 16GB 비교
• Techgage Blender 3.3 성능 분석 (EEVEE)
• 다나와 RTX 5060 Ti 16GB 가격
• RunPod GPU 요금
• Vast.ai 콘솔 (실시간 매물)
• GarageFarm 요금과 FAQ
• RenderStreet Blender EEVEE
• RenderDay 요금 사례
• SheepIt FAQ
• Blender Artists: 도커 안에서 EEVEE가 안 될 때
• BlenderKit 라이선스 FAQ
• Fab 표준 라이선스
• SunWorld (1995): 117대의 SPARCstation으로 렌더한 토이 스토리
• GamesBeat: 픽사 몬스터 대학교 렌더팜과 프레임당 29시간
• VentureBeat: 픽사 애니메이터 인터뷰 (프레스토 미리보기)
• 기네스 세계기록: 빅 히어로 6, 영화 제작에 쓰인 최대 연산 규모
• Engadget: 디즈니 빅 히어로 6와 55,000코어 렌더팜
• 디즈니 애니메이션: 하이페리온 렌더러
• Computerworld: 아바타 렌더월의 HP 서버 4,352대
• NetApp: 웨타 디지털 아바타 렌더월 확장기
• VizWorld: 아바타 렌더 대기열과 프레임 렌더 시간
• AWS Deadline Cloud: 사내 렌더팜을 클라우드로 확장하기
• P1 Technologies: 스카이댄스 애니메이션 AWS 버스트 렌더 사례 (PDF)
• Blender 5.2 LTS 매뉴얼: View Layers 소개
• Blender 5.2 LTS 매뉴얼: Passes
• Blender 5.2 LTS 매뉴얼: Viewport Render (Render Playblast)
• RenderMan 26: Modeling Guidelines
• ILM: 만달로리안 LED 스테이지 제작 기술
• Unreal Engine: 만달로리안 제작기
• Unreal Engine: TV 광고와 버추얼 프로덕션 (Quite Brilliant)
• Unreal Engine: 방송과 라이브 이벤트
• Unreal Engine: 코리 윌리엄스의 어린이 유튜브 채널
• RunPod 문서: Pod 요금과 저장 공간 과금
• RunPod 문서: 저장 공간 종류
• RunPod 문서: 파일 전송 (runpodctl, scp, rsync)
• RunPod 문서: Pod 고르기 (시큐어 클라우드와 커뮤니티 클라우드)
• RunPod API 문서: 인터럽터블(스팟) 포드
• NVIDIA A100 아키텍처 백서
• NVIDIA 기술 문서: 가상화 연산과 그래픽 워크로드용 GPU
• NVIDIA Hopper 아키텍처 해설 (H100 그래픽 TPC)
• NVIDIA MIG 사용자 가이드: 배포 시 고려 사항
• AMD CDNA 아키텍처 백서
• Blender 5.2.2 리눅스 다운로드

조사 기준: 2026년 10월 20일 (한국 시간). 그래픽카드 가격과 임대 요금은 매일 바뀌고, 렌더 시간과 편당 비용은 장면에 따라 크게 달라지는 추정치예요. 환율은 1달러 1,330원으로 계산했어요.

• YouTube: Rahul Ahire, Make Your Blender Render 10x Faster With Runpod (RunPod 후원)
• Blender 5.2 LTS 매뉴얼: 명령행 인자 (적힌 순서대로 처리)
• YouTube: Jackson Zheng, Render Blender Projects 10x Faster With This (SheepIt)
• SheepIt 홈 (지원 엔진과 운영 현황)
• SheepIt 이용 약관 (저작권과 금지 콘텐츠)
• SheepIt 공지: 프로젝트 크기 2GB로 상향 (2024)
• SheepIt 공지: 프레임당 허용 렌더 시간과 기준 기계 (2021)
• SheepIt 공지: CPU와 GPU 성능 점수 분리 (2023)
• SheepIt 공지: AMD와 애플 GPU 지원 재개, 블렌더 5.1 요구 (2026)
• SheepIt 공지: 블렌더 5.2 추가 (2026)
• SheepIt 공지: 광고 중단 (2026)
• SheepIt 클라이언트 소스 코드 (Block Eevee projects, 헤드리스 모드)
• Adobe 커뮤니티: Mixamo 라이선스 FAQ (원본 파일 배포 금지)
• 레딧 r/sheepit: 프로젝트 유출과 개인정보 질문
• 레딧 r/blender: SheepIt은 쓸 만한가 (GTX 1650 사례)
• 레딧 r/blenderhelp: SheepIt 사용 의견
• GameDev.tv 커뮤니티: SheepIt 하루 사용기 (1,800프레임 두 번)
• X: 가벼운 작업에는 SheepIt이라는 답글