V-Ray 6 클라우드 렌더팜: 2026 실무 가이드

소개

V-Ray는 20년 이상 프로덕션 렌더링의 표준으로 자리잡아 왔으며, V-Ray 6는 현재도 많은 스튜디오가 일상적으로 사용하는 버전입니다. 새로운 메이저 버전이 출시되더라도 파이프라인 검증에는 시간이 걸리고, 다음 주에 납품해야 하는 4K 건축 시각화 작업은 버전 마이그레이션을 기다릴 여유가 없습니다. 그렇기 때문에 V-Ray 7이 출시된 지금도 V-Ray 6 클라우드 렌더팜에 도달하는 씬의 상당수는 버전 6로 빌드, 라이팅, 최종 승인된 것들이며, 단일 워크스테이션에서와 동일하게 수천 개의 코어에서 렌더링되어야 합니다.

바로 이 부분에서 대부분의 문제가 발생합니다. 빌드된 머신에서 완벽하게 렌더링되는 V-Ray 6 씬이라도, 프레임이 프로젝트 폴더를 한 번도 본 적 없는 워커 노드에 분산되는 순간 플리커가 발생하거나, 에셋이 누락되거나, 잘못된 엔진으로 조용히 폴백될 수 있습니다. Super Renders Farm에서는 수년간 어떤 단계가 이 전환을 통과하고 어떤 단계가 실패하는지 직접 관찰해 왔습니다. 이 가이드는 실제로 렌더 버튼을 누르는 사람들을 위해 V-Ray 6에서 무엇이 바뀌었는지, 지원하는 호스트 앱에서 이 버전이 어떻게 동작하는지, V-Ray GPU가 V-Ray CPU를 앞서는 경우(그리고 그렇지 않은 경우), 그리고 분산 렌더링 시 깔끔한 프레임이 돌아오도록 씬을 패키징하는 방법을 안내합니다. 별도의 렌더 라이선스를 구매했거나 큐를 관리하기 위해 머신에 원격 접속해야 한다는 전제는 전혀 없습니다.

실제 렌더링하는 사람들을 위해 V-Ray 6가 바꾼 것들

V-Ray 6에 관한 논의의 상당 부분은 모델링 및 룩 개발 편의성에 집중됩니다. 렌더팜에서 중요한 것은 더 좁은 범위입니다. 어떤 기능이 렌더 노드의 작업량, 전송해야 할 파일 크기, 또는 설치되어야 할 플러그인을 변경하는지입니다. V-Ray 6 릴리스에서 렌더팜과 직접 관련된 몇 가지 기능이 있습니다.

Enmesh는 소스 메시를 파일에 베이크하지 않고 렌더 타임에 서피스 전체에 타일링합니다. 체인메일, 천공 파사드, 직조 패브릭, 격자 구조물 등을 생각해 보십시오. 렌더링하는 동안 저장된 파일이 아닌 노드에서 지오메트리를 생성하기 때문에, 각 워커에 전달되는 .vrscene은 작게 유지되고 무거운 지오메트리는 렌더 메모리에만 존재합니다. 이는 렌더팜에서 실질적인 이점입니다. 네트워크 전송량이 줄어들고, RAM이 저장 파일이 아닌 렌더에 따라 확장됩니다.

Chaos Scatter는 V-Ray 자체에 네이티브 스캐터링을 도입했습니다. 식생, 암석, 지표 커버 등을 렌더 타임에 절차적으로 해석합니다. 렌더팜 측의 이점은 의존성 감소입니다. Chaos Scatter로 스캐터링된 씬은 모든 노드에 서드파티 스캐터 플러그인이 라이선스 설치될 필요가 없으므로, 프레임이 워커에 도달했을 때 누락될 수 있는 항목이 하나 줄어듭니다.

V-Ray Decals는 UV나 토폴로지를 건드리지 않고 서피스에 머티리얼을 투영합니다. 레이블, 스티커, 표면 마모, 간판 등이 이에 해당합니다. V-Ray의 자체 파이프라인 내에서 완전히 해석되므로 노드에 필요한 것은 데칼의 텍스처 맵에 대한 접근뿐입니다.

절차적 스카이 및 볼류메트릭 클라우드를 사용하면 고정 HDRI가 아닌 파라미터로 하늘을 만들고, 씬에서 실제 볼륨으로 동작하는 구름을 생성할 수 있습니다. 프레임당 렌더링은 무거워지지만 완전히 프레임 병렬로 처리됩니다. 각 노드는 이웃 노드에 의존하지 않고 자체 프레임을 계산하므로 깔끔하게 분산됩니다. 주의할 점은 V-Ray GPU 메모리입니다. 조밀한 볼류메트릭 스카이는 VRAM을 많이 사용하며, 복잡한 스카이는 CPU에서 더 안전한 경우가 많습니다.

V-Ray Frame Buffer 또한 렌더팜 파이프라인에서 계속 그 가치를 발휘합니다. Light Mix 기능을 사용하면 렌더 엘리먼트가 저장된 후에 개별 라이트 또는 라이트 그룹을 분리하고 재조정할 수 있습니다. 다시 렌더링 없이 바로 컴포지팅에서 가능합니다. 시퀀스가 완료된 다음 날 디렉터가 "키 라이트를 따뜻하게 하고 필 라이트를 낮춰달라"고 요청할 때, 해당 조정은 큐로 돌아가지 않고 컴포지팅에서 처리됩니다. 이것이 파이프라인에서 가장 비용이 적게 드는 변경입니다. 그리고 Chaos Cosmos, 내장 에셋 라이브러리는 뷰포트에서 편리하지만 저희가 가장 많이 보는 렌더팜 실패의 단일 원인이기도 합니다. 자세한 내용은 워크플로우 섹션에서 다루겠습니다.

저희 렌더팜에서 지원하는 DCC별 V-Ray 6

V-Ray 6는 별도의 호스트 애플리케이션에 대한 별도의 통합으로 제공됩니다. 렌더팜 관점에서 중요한 사실은 모두 동일한 디스패치 포맷으로 수렴된다는 것입니다. V-Ray Standalone으로 렌더링되는 .vrscene 파일입니다. 모델링하는 호스트는 워크플로우에 영향을 미치지만, 내보낸 씬을 단순히 실행하는 노드에는 거의 영향을 주지 않습니다.

저희 렌더팜에서 V-Ray를 통해 실행하는 호스트 애플리케이션은 3ds Max, Maya, Cinema 4D, Houdini입니다. V-Ray를 사용하는 3ds Max는 건축 시각화의 핵심 도구이며 가장 일반적인 경로입니다. 인테리어, 익스테리어, 제품 시각화 등이 이에 해당합니다. V-Ray를 사용하는 Maya는 VFX 및 애니메이션 파이프라인에서 동일한 역할을 수행합니다. V-Ray를 사용하는 Cinema 4D는 모션 및 디자인 스튜디오에 서비스를 제공합니다. V-Ray for Houdini를 사용하는 Houdini는 VEX 및 노드 기반 지오메트리가 내보낼 때 내보낸 씬으로 해석되는 절차적으로 빌드된 씬을 완성합니다. 애플리케이션별 세부 정보는 3ds Max, Maya, Cinema 4D, Houdini 전용 페이지와 V-Ray 클라우드 렌더팜 페이지에서 확인하실 수 있습니다.

두 가지 솔직한 한계를 명확히 짚고 넘어가겠습니다. SketchUp에는 자체 V-Ray 통합이 있지만, SketchUp은 저희 렌더팜에서 실행하는 호스트 애플리케이션이 아닙니다. SketchUp 사용자에게는 여전히 명확한 경로가 있습니다. V-Ray for SketchUp은 .vrscene을 직접 내보낼 수 있으며, 이 파일은 3ds Max에서 내보낸 것과 동일하게 V-Ray Standalone에서 렌더링됩니다. 대안으로는 모델을 3ds Max로 가져와 머티리얼을 재연결한 후 내보내는 방법이 있는데, 작업이 더 많지만 정리에 전체 3ds Max 툴셋을 활용할 수 있습니다. 어느 쪽이든 렌더링은 SketchUp 내부가 아닌 지원되는 호스트의 내보내기를 통해 이루어집니다.

또 다른 한계는 Blender입니다. 저희 렌더팜에서 Blender 씬은 V-Ray가 아닌 Blender의 네이티브 프로덕션 렌더러인 Cycles로 렌더링됩니다. 따라서 파이프라인이 V-Ray라면 위의 네 가지 호스트를 사용하고, Blender라면 Cycles를 사용하며 이는 다른 워크플로우입니다.

렌더팜에서 V-Ray GPU vs V-Ray CPU: 실제 결정 기준

V-Ray 6는 머티리얼과 라이팅을 공유하지만 확장 시 매우 다르게 동작하는 두 가지 렌더링 엔진을 제공합니다. 잘못된 엔진을 선택하는 것은 렌더팜에서 가장 비용이 많이 드는 실수 중 하나인데, 대개 프레임이 돌아오기 전까지는 알 수가 없습니다.

먼저 평범한 사실부터 시작하겠습니다. 대부분의 V-Ray 작업은 여전히 CPU 작업입니다. 저희가 처리하는 작업 중 약 70%가 CPU 렌더링입니다. V-Ray (CPU), Corona, Arnold CPU 등이며, 그 대부분은 건축 시각화입니다. V-Ray CPU는 물리 코어에 거의 선형으로 확장되기 때문에 고코어 서버에 매우 적합합니다. 저희 CPU 플릿은 96~256GB RAM을 갖춘 인텔 듀얼 Xeon E5-2699 V4 머신으로 구성되어 있으며, 총 20,000개 이상의 CPU 코어를 보유하고 있습니다. 워크스테이션에서 몇 시간이 걸리는 4K 인테리어 작업도 이 풀 전체에 프레임 단위로 분산됩니다. CPU 렌더링은 VRAM이 아닌 시스템 RAM을 사용하므로, 전체 세트에 4K 및 8K PBR 머티리얼이 가득한 텍스처 집약적인 인테리어도 GPU처럼 메모리 한계에 부딪히지 않습니다. 대규모 최종 품질 건축 시각화에는 CPU가 일반적으로 안전한 기본값입니다.

V-Ray GPU는 나머지 30%를 담당하며, 씬이 맞을 때 실제로 더 빠릅니다. RTX 클래스 NVIDIA GPU의 하드웨어 레이 트레이싱 코어를 사용하는 RTX 모드와 광범위하게 호환되는 CUDA 모드의 두 가지 모드로 실행됩니다. 저희 GPU 머신은 VRAM 32GB의 RTX 5090 카드를 탑재하고 있으며, VRAM 수치가 전부입니다. VRAM은 GPU 렌더링의 주요 제약 조건입니다. 씬의 지오메트리와 텍스처가 맞으면 V-Ray GPU는 반복 작업과 적당한 복잡도의 인테리어에 탁월합니다. 24GB(일반적인 고성능 워크스테이션 카드)에서 32GB로의 도약은 씬 전체가 메모리에 들어갈 수 있는지, 아니면 out-of-core로 데이터를 페이징해야 하는지의 차이이며, 이는 성능에 영향을 미칩니다. 24GB 카드에서 페이징이 발생했던 씬이라면 단순히 여유 공간이 생기는 것만으로도 속도 향상의 상당 부분을 차지할 수 있습니다. 저희는 이를 RTX 5090 하드웨어에서 V-Ray GPU 속도 테스트 및 RTX 5090 렌더링 성능 글에서 벤치마킹했습니다. GPU 클라우드 렌더팜 페이지에서는 해당 노드 구성 방법을 다룹니다.

핵심 결정 기준을 정리하면 다음과 같습니다.

V-Ray GPU 선택 시…	V-Ray CPU 선택 시…
씬 지오메트리 + 텍스처가 VRAM에 맞는 경우(또는 거의 맞는 경우)	씬이 out-of-core에서도 VRAM을 초과하는 경우(대규모 도시 세트, 100GB 이상의 텍스처)
빠른 반복 작업 및 빠른 테스트 프레임이 필요한 경우	최종 납품을 위한 가장 성숙한 기능 세트가 필요한 경우
적당한 복잡도의 인테리어/제품 시각화	GPU 패리티에서 아직 누락된 기능을 사용하는 렌더
GPU 노드에서 렌더링하는 경우	주로 CPU 풀에서 예측 가능한 동작을 원하는 경우

V-Ray 6는 동일 노드의 CPU 코어와 GPU가 하나의 렌더에 기여하는 하이브리드 모드도 지원합니다. GPU 씬이 메모리 예산의 한계에 있을 때 유용합니다. 피해야 할 것은 "GPU가 항상 더 빠르다"는 가정입니다. 크고 텍스처가 많은 건축 시각화 씬의 경우, V-Ray CPU가 메모리 한계와 싸우지 않기 때문에 전체적으로 더 빠른 경우가 많습니다. 소문이 아닌 씬에 맞는 엔진을 선택하십시오.

렌더팜에서 V-Ray 6 씬을 깔끔하게 렌더링하기

이 부분이 프레임을 사용 가능한 상태로 돌려받을 수 있는지를 결정합니다. 메커니즘 자체는 복잡하지 않지만, 일부는 조용히 실패하는데 이것이 가장 나쁜 방식의 실패입니다.

디스패치 경로. 렌더팜에서 V-Ray를 렌더링하는 표준 방법은 씬을 .vrscene으로 내보내고 V-Ray Standalone이 각 노드에서 렌더링하게 하는 것입니다. 중요한 결과는 라이선스입니다. V-Ray Standalone을 실행하는 워커는 렌더링을 위해 3ds Max, Maya, Cinema 4D 라이선스가 필요하지 않고 V-Ray만 필요합니다. 저희 렌더팜에서 렌더 라이선스는 렌더링 비용에 포함되어 있습니다. 별도의 라이선스를 가져올 필요도, 아무것도 설치할 필요도 없습니다. 이것이 "풀 매니지드"의 실질적인 의미입니다. 원격 데스크톱 없이, 라이선스 서버 관리 없이, 여러분 측에서 노드별 소프트웨어 설정 없이. 이것이 인프라 임대 모델과의 명확한 차이점이기도 합니다. 인프라 임대 모델에서는 머신을 임대하고 자체 라이선스를 제공해야 합니다.

프레임 분산, Distributed Rendering이 아님. 이 두 가지는 항상 혼동됩니다. 렌더팜은 여러 노드에 전체 프레임을 분산합니다. 노드 A는 프레임 1을 렌더링하고, 노드 B는 프레임 2를 렌더링하는 방식입니다. V-Ray의 Distributed Rendering (DR)은 다른 개념입니다. 여러 머신이 실시간으로 네트워크를 통해 버킷을 분할하여 단일 프레임 하나에 협력하는 방식입니다. DR은 하나의 거대한 히어로 프레임을 위한 스튜디오 도구입니다. 네트워크 레이턴시가 추가되고, 모든 곳에서 동일한 V-Ray 버전이 필요하며, 대규모에서는 효율성이 떨어집니다. 사실상 모든 애니메이션 및 이미지 시퀀스에는 프레임 분산이 올바른 방식이며, 렌더팜이 기본적으로 수행하는 방식입니다.

플리커 없는 GI. 애니메이션의 경우 이것이 핵심 선택입니다. Brute Force GI에 프레임당 Light Cache를 사용하면 모든 프레임에 대해 독립적으로 라이팅을 계산합니다. 프레임당 속도는 느리지만 플리커가 없고 프레임 간 의존성도 없으므로, 어떤 노드든 어떤 순서로든 프레임을 렌더링할 수 있습니다. 이것이 분산 애니메이션에 권장하는 플리커 안전 기본값입니다. Irradiance Map 방식은 GI 솔루션을 미리 계산하고 재사용하기 때문에 프레임당 속도는 빠르지만, 정적 라이트와 오브젝트가 있는 카메라 플라이스루 애니메이션에만 작동하며 모든 노드가 공유 경로에서 동일한 미리 계산된 맵을 읽어야 합니다. 전형적인 실패 패턴은 맵이 C:\Users\artist\scene.vrmap 같은 로컬 경로에 저장되어 있고, 노드가 이를 찾지 못해 모든 프레임이 조용히 GI를 다시 계산하는 것입니다. 바로 피하려 했던 플리커가 발생합니다. Irradiance Map을 사용한다면 한 번 베이크하고, 파일을 작업과 함께 전송하고, 경로를 수정하십시오. 확실하지 않다면 Brute Force를 사용하십시오.

디노이징. V-Ray 6는 V-Ray Denoiser (CPU), NVIDIA AI Denoiser (노드에 NVIDIA GPU 필요), Intel Open Image Denoise (CPU, 어디서나 실행)를 제공합니다. 세 가지 모두 프레임 간 상태 없이 프레임당 작동하므로 완전 병렬 렌더링에 안전합니다. 저희의 표준 권고 사항은 디노이즈된 출력과 함께 원본의 디노이즈되지 않은 뷰티 패스를 항상 저장하는 것입니다. 디노이저가 디테일을 뭉개면 시퀀스를 다시 렌더링하지 않고 포스트에서 다시 디노이즈할 수 있습니다.

Chaos Cosmos 에셋 — 조용한 실패의 원인. 이것이 신규 사용자들이 겪는 가장 흔한 V-Ray 6 렌더팜 실패이며, 조용히 실패합니다. Cosmos 에셋은 로컬 Cosmos 캐시에 다운로드됩니다. .vrscene을 내보내면 해당 에셋이 로컬 경로로 참조됩니다. 노드에는 여러분의 Cosmos 캐시가 없으므로 파일이 없는 경로를 가리키는 씬을 받게 됩니다. 결과는 누락된 식생, 회색 소품, 또는 빈 하늘이며 하드 에러도 없습니다. 해결책은 제출 전에 에셋을 수집하는 것입니다. V-Ray의 에셋 수집/"프로젝트 패킹" 도구를 사용하여 모든 Cosmos 및 텍스처 파일을 씬 옆의 한 폴더에 모으고 모든 경로를 상대 경로로 수정하십시오. 이렇게 하면 작업이 자급자족하게 됩니다. 건너뛰면 다시 렌더링해야 합니다. 일반 텍스처에도 동일한 원칙이 적용됩니다. 절대 로컬 경로로 참조된 모든 것은 누락될 에셋입니다.

업로드. 프로젝트를 .tar.gz 또는 .7z로 패킹하십시오. .zip 아카이브는 업로드를 지원하지 않으므로 압축 프로젝트를 전송하기 전에 재패킹하십시오. 매우 큰 씬의 경우 브라우저 업로드보다 SFTP 또는 데스크톱 클라이언트가 더 안정적입니다. 렌더 출력은 45일간 보관되므로 완료된 프레임을 신속히 다운로드하거나 클라이언트가 자동으로 다운로드하게 하십시오.

제출 전 사전 점검 체크리스트

대부분의 실패한 렌더팜 렌더링은 4~5가지 반복 가능한 원인으로 귀결됩니다. 2,000프레임 시퀀스를 시작하기 전에 단일 테스트 프레임을 렌더팜에 통과시키는 데 몇 분이 걸리며 거의 모든 문제를 잡을 수 있습니다. 다음은 저희가 제공하는 간단한 체크리스트입니다.

점검 항목	렌더팜에서 중요한 이유	빠른 해결 방법
에셋 수집 및 경로 수정 완료	절대 로컬 경로(텍스처, Cosmos) = 노드에서 누락된 에셋	프로젝트 패킹 / 에셋 수집하여 상대 경로로 변환
GI 방법 의도적 선택	움직이는 씬의 Irradiance Map = 플리커	기본적으로 애니메이션에는 Brute Force + Light Cache
엔진이 씬에 맞음	VRAM을 초과하는 GPU 씬은 멈춤; CPU 씬을 GPU에서 실행하면 낭비	먼저 프레임 버퍼에서 VRAM 수요 확인
원본 + 디노이즈 패스 모두 저장	잘못된 디노이즈는 다시 렌더링이 필요	뷰티와 디노이즈된 엘리먼트 모두 출력
렌더팜에서 테스트 프레임 한 장 렌더링	로컬 성공 ≠ 렌더팜 성공	프레임 1 제출 후 확인, 그 후 전체 범위 제출
프로젝트를 .tar.gz / .7z로 패킹	.zip은 지원되지 않음	업로드 전 재패킹

비용은 엔진 전반에 걸쳐 동일한 단위 로직을 따르므로 예산 산정이 간단합니다. CPU 렌더링은 GHz-시간당 $0.004, GPU 렌더링은 OctaneBench-시간당 $0.003으로 청구되며, 모든 렌더 엔진 라이선스가 해당 요금에 포함되어 있습니다. 신규 계정은 위와 같은 단일 프레임 테스트를 진행하기 위한 $25의 무료 렌더 크레딧으로 시작하며, 크레딧은 만료되지 않습니다. 자세한 내역은 가격 페이지에서 확인하실 수 있으며, 엔진이 아닌 제공업체를 비교하고 있다면 V-Ray용 렌더팜 비교에서 확인해야 할 사항을 정리해 두었습니다.

FAQ

Q: V-Ray 7로 업그레이드하지 않고도 클라우드 렌더팜에서 V-Ray 6를 렌더링할 수 있습니까? A: 가능합니다. V-Ray 6 씬은 내보낸 .vrscene을 통해 V-Ray Standalone에서 렌더링되며, 먼저 최신 메이저 버전으로 마이그레이션할 필요가 없습니다. 많은 프로덕션 파이프라인이 의도적으로 V-Ray 6에 머물고 있으며, 렌더팜은 씬이 빌드되고 승인된 버전으로 렌더링합니다.

Q: 클라우드 렌더링을 위해 자체 V-Ray 라이선스를 구매해야 합니까? A: 아닙니다. 저희 렌더팜에서 V-Ray 렌더 라이선스는 단위당 렌더 요금에 포함되어 있으므로, 렌더링을 위해 별도의 라이선스를 가져오거나 비용을 지불할 필요가 없습니다. 이것이 풀 매니지드 렌더팜과 인프라 임대 모델의 차이입니다. 인프라 임대 모델에서는 머신을 임대하고 자체 소프트웨어 라이선스를 제공해야 합니다.

Q: 렌더팜에서 V-Ray GPU와 V-Ray CPU 중 무엇을 사용해야 합니까? A: 씬의 지오메트리와 텍스처가 VRAM에 맞고 인테리어나 반복 작업에서 속도가 필요하다면 V-Ray GPU를 사용하십시오. 씬이 크고 텍스처가 많거나 최종 납품을 위한 가장 성숙한 기능 세트가 필요하다면 V-Ray CPU를 사용하십시오. CPU는 VRAM이 아닌 시스템 RAM을 사용하므로 GPU를 더 느린 out-of-core 페이징으로 몰아넣을 수 있는 대형 건축 시각화 씬을 처리할 수 있습니다.

Q: 여러 노드에서 렌더링되는 V-Ray 6 애니메이션의 GI 플리커를 방지하려면 어떻게 해야 합니까? A: 기본값으로 프레임당 Light Cache와 함께 Brute Force GI를 사용하십시오. 각 프레임에 대해 독립적으로 라이팅을 계산하므로 분산 노드 간에 불일치가 발생하지 않습니다. Irradiance Map 방식은 정적 라이트와 오브젝트가 있는 카메라 전용 플라이스루에만 사용하고, 미리 계산된 맵이 모든 노드가 읽을 수 있는 공유 경로에 있는지 확인하십시오.

Q: 렌더팜에서 프레임이 돌아왔을 때 Chaos Cosmos 에셋이 없는 이유는 무엇입니까? A: Cosmos 에셋은 자체 캐시에만 존재하는 로컬 경로로 참조되므로, 렌더 노드가 찾지 못해 오브젝트가 회색, 누락 또는 빈 상태로 렌더링됩니다. 하드 에러도 발생하지 않습니다. 제출하기 전에 모든 에셋을 자급자족 프로젝트 폴더에 수집하고 경로를 수정하십시오. V-Ray의 에셋 수집 도구가 이를 처리합니다.

Q: 렌더팜에서 V-Ray for SketchUp 씬을 렌더링할 수 있습니까? A: 내보내기를 통해 가능합니다. SketchUp은 저희가 실행하는 호스트 애플리케이션이 아니지만, V-Ray for SketchUp은 V-Ray Standalone에서 직접 렌더링되는 .vrscene을 내보낼 수 있습니다. 또는 모델을 3ds Max로 가져와서 내보낼 수도 있습니다. 렌더링은 SketchUp 내부가 아닌 지원되는 호스트에서 내보낸 씬을 통해 이루어집니다.

Q: 렌더팜과 V-Ray Distributed Rendering의 차이점은 무엇입니까? A: 렌더팜은 많은 머신에 전체 프레임을 분산합니다. 이것이 애니메이션 및 이미지 시퀀스에 효율적인 방식입니다. V-Ray Distributed Rendering (DR)은 대신 여러 머신에 실시간으로 단일 프레임의 버킷을 분할합니다. 매우 큰 히어로 프레임 하나에는 유용하지만, 대규모에서는 느리고 불안정하며 렌더팜에서 시퀀스를 렌더링하는 방식이 아닙니다.