Corona Renderer 렌더팜 완벽 설정 가이드

소개

Corona Renderer는 주요 렌더러 중에서 독특해요. CPU 기반 레이 트레이싱만 사용하거든요 — GPU 렌더링 경로가 없어요. 이 아키텍처는 렌더팜 배포에 깊은 영향을 미쳐요. V-Ray GPU용으로 지어진 전통적인 렌더팜에서 Corona는 다른 하드웨어 프로비저닝, 라이선싱 모델, 최적화 접근법이 필요해요.

우리는 공식 Chaos (카오스) 렌더 파트너로, 우리 렌더팜에서 Corona Renderer 외에도 V-Ray와 Redshift를 지원해요. Corona의 CPU 중심 설계는 GPU 렌더팜 대역폭이 제한되어 있거나 클라이언트가 CPU 안정성을 선호하는 시나리오에서 탁월해요. 지난 3년 동안 우리는 수천 개의 Corona 작업을 처리했고 렌더팜 효율을 최대화하면서 일반적인 배포 문제를 최소화하는 워크플로우를 정제했어요.

이 가이드는 Corona 아키텍처, 분산 렌더링 설정, 노드 라이선싱, 씬 준비, 일반적인 오류와 해결책, 렌더팜에서 Corona 대 V-Ray, Corona 렌더 시간을 경쟁력 있게 유지하는 최적화 기법을 다루고 있어요.

Corona의 CPU 기반 렌더링 아키텍처 이해하기

Corona Renderer는 단방향 경로 추적을 통해 포토리얼리스틱 출력물을 생성해요 — 단일 광선이 카메라에서 씬을 통해 튀면서 광원이나 바운스 한계에 도달할 때까지 광 샘플을 수집해요. 이는 양방향 경로 추적(V-Ray 접근법) 또는 분광 렌더링(Arnold)과 달라요. Corona의 단방향 설계는 속도와 일관성을 우선시해요. 기술 문서는 Corona Renderer 매뉴얼을 참고해요.

왜 CPU만 사용해요? CPU 레이 트레이싱은 GPU 메모리 제약을 피하고 대규모 씬 파일을 가능하게 해요. 5억 폴리곤 또는 10GB 텍스처가 있는 씬이 128GB RAM이 있는 CPU 머신에 편안하게 맞아요. GPU 렌더링은 어려움을 겪을 거예요. CPU는 또한 우수한 수치 정밀도(64비트 부동소수점)를 제공하는데, 이는 작은 표면 오정렬이 중요한 건축 시각화에 중요해요.

렌더팜 영향: Corona 렌더는 CPU 집약적이지만 메모리에 관대해요. 단일 4소켓 Xeon 서버는 쿼드 GPU 머신보다 복잡한 씬을 4~8배 빠르게 렌더링하지만 동일한 전력을 소비해요. 우리 렌더팜은 Corona용으로 듀얼 소켓 Xeon E5-2699 v4 머신을 할당해요 — 머신당 44코어, 렌더링 중 100% 사용률로 실행돼요.

라이선싱 현실: Corona는 노드 잠금 라이선스를 사용하는데, 한 라이선스가 하나의 CPU 코어를 활성화해요. 44코어 머신은 44개의 Corona 라이선스가 필요해요. 규모가 커지면 비싸지만 정확한 용량 청구를 제공하고 부동 라이선스 오버헤드를 피해요. 렌더러 간 상세 라이선싱 모델은 우리 노드 라이선스 가이드를 보세요.

Corona에서 분산 렌더링 설정

Corona의 분산 렌더링은 프레임을 여러 머신에 분할해요. 각 머신은 타일을 렌더링하고 결과를 컴포지팅용 제출 머신으로 반환해요. 설정에는 다음이 필요해요:

1. 제출 머신(주요): Corona를 실행하고 작업을 제출하고 타일 결과를 받아요.

2. 렌더팜 워커(보조): Corona를 헤드리스 모드에서 실행하고 타일 할당을 받고 렌더링된 타일을 반환해요.

3. 네트워킹: 빠른 LAN이 필요해요(최소 기가비트, 10기가비트 권장). Corona는 네트워크를 통해 타일을 전송하므로 지연시간과 대역폭이 중요해요.

4. 공유 스토리지: 텍스처, 캐시 파일, 프로젝트 자산은 모든 워커에서 접근 가능해야 해요. 우리는 10Gb NAS를 NFS를 통해 모든 렌더팜 노드에 마운트해요.

구성 단계:

Corona 시작 → 렌더 → 분산 렌더링 설정 → 분산 모드 활성화 → 워커 머신 구성(IP 주소 또는 호스트명). Corona는 자동으로 주요 머신에서 타일 분할과 결과 컴포지션을 처리해요.

3ds Max 또는 Cinema 4D와 함께 Corona를 사용하면, 프로세스는 유사하지만 Corona의 독립형 UI가 아닌 렌더 설정 대화상자에 있어요.

워커 노드 요구사항: 각 워커는 주요 머신과 정확히 같은 Corona 버전이 필요해요. 버전 불일치는 무음 타일 오류를 야기해요. 우리는 자동화된 프로비저닝으로 버전 일관성을 유지해요 — 새 워커 노드는 초기화 중 중앙 저장소에서 Corona를 끌어와요.

렌더팜용 Corona 라이선싱

Corona 노드 라이선스는 영구적이고 코어별 구독이에요. 한 라이선스는 렌더링용 CPU 코어 하나를 활성화해요. V-Ray의 노드 라이선스 모델과 달라요(코어 수와 관계없이 머신당 한 라이선스), Corona는 세분화되어 있어요.

비용 영향: 64코어 머신은 64개 Corona 라이선스가 필요해요 — 비싸지만 투명해요. 당신이 사용하는 것에만 비용을 지불해요. 우리는 우리 렌더팜의 Corona 라이선싱을 약 ₩0.03~₩0.05/렌더 코어/월로 계산했어요(우리 Chaos 렌더 파트너 계약 기반), 대량 생산에 1,000코어 렌더팜을 경제적으로 실현 가능하게 만들어요.

라이선스 활성화: Corona 라이선스는 시스템 MAC 주소를 통해 노드 잠금돼요. 우리 렌더팜에서 우리는 MAC 주소를 라이선스 키에 매핑하는 라이선스 데이터베이스를 유지해요. 워커가 부팅할 때, 초기화 중 라이선스가 자동으로 활성화돼요 — 탄력적인 클라우드 배포에 중요해요.

부동 대 노드 잠금: Corona는 부동 라이선스(V-Ray와 달라)를 지원하지 않아요. 각 코어는 자신의 라이선스를 받아요. 이는 부기를 단순화하지만 신중한 인벤토리 관리가 필요해요. 렌더러 라이선싱 모델 비교는 우리 Corona 라이선싱 비교를 보세요.

업그레이드 경로: Corona는 주요 버전 간 역호환성을 유지해요(예를 들어, 11 렌더러는 Corona 10 씬과 작동 가능해요). 그러나 라이선스 키는 버전별 잠금돼요. Corona 10에서 Corona 11로 업그레이드하려면 모든 코어에 대한 새 라이선스 키가 필요해요.

우리 렌더팜에서: 우리는 라이선스 배치 두 개를 유지해요 — 프로덕션 렌더링용 주요 세트와 개발 및 테스트용 보조 세트. 이는 프로덕션을 실험과 격리시켜요.

씬 준비 및 일반적인 렌더팜 제출 오류

Corona 씬은 예측 가능한 이유로 렌더팜에서 실패해요. 우리의 사전 제출 체크리스트는 모두를 다루고 있어요:

1. 텍스처 경로: 모든 텍스처가 절대 UNC 경로를 사용하도록 해요(예: \\\\farm-nas\\\\project\\\\textures\\\\wood.exr) 또는 프로젝트 구조 내 상대 경로. Corona는 일부 렌더러처럼 텍스처를 씬 파일에 굽지 않으므로, 경로 누락 = 렌더링 시간에 텍스처 누락이에요.

우리는 제출 전에 non-UNC 텍스처 경로를 보고하는 MaxScript의 자동화된 "경로 확인" 스크립트를 만들었어요. 이는 "누락된 텍스처" 렌더팜 오류의 약 95%를 없애줬어요.

2. 프록시 파일: Corona는 V-Ray 프록시(.vrmesh)를 아름답게 지원하지만, 프록시 경로는 절대 경로여야 해요. 우리는 상대 경로(예: .\\\\proxies\\\\building.vrmesh)를 제출 전에 전체 UNC 경로로 변환해요.

3. HDR 맵: 환경 맵(.hdr 파일)은 렌더팜 워커에서 접근 가능해야 해요. 텍스처와 같은 규칙 — 절대 UNC 경로.

4. 플러그인 및 확장: Corona의 플러그인 생태계는 작아요. 당신의 씬이 서드파티 재료를 사용하면(예: 3ds Max 내 Substance Designer), 그 플러그인이 렌더팜 워커에 존재해야 하지 않으면 재료는 무음으로 로드 실패하고 검은색으로 렌더링돼요.

5. 애니메이션 씬: Corona는 애니메이션과 모션 블러를 효율적으로 처리해요, 하지만 워커 노드의 프레임 캐싱을 확인해요. 일부 설정은 불필요하게 프레임을 캐시해서 NAS 사용량을 부풀려요.

6. 라이선싱 가용성: 당신의 Corona 라이선스 수가 당신이 요청하는 코어 수와 일치하는지 확인해요. 100코어로 제출된 씬이 50개 라이선스만 있으면 50% 용량으로 무음 렌더링돼요 — 에러 메시지가 없어요. 우리는 이를 방지하려고 우리 렌더팜 대시보드에 할당량 확인을 추가했어요.

일반적인 오류 해결하기

오류	원인	수정
렌더가 검은 픽셀 또는 완전 검은색 반환	누락된 플러그인 또는 재료	씬에서 재료 정의 확인; 렌더팜에서 플러그인 가용성 확인
타일이 제대로 컴포지트되지 않음	주요 워커 간 버전 불일치	모든 워커를 주요 머신과 일치하는 Corona 버전으로 업데이트
렌더가 극도로 느림(예상보다 약 100배)	분산 렌더링 대신 대화형 모드로 렌더링	분산 렌더링 설정 활성화 및 워커 등록 확인
일부 타일은 실패, 다른 타일은 성공	텍스처 검색 시 네트워크 타임아웃	텍스처를 NFS를 통해 접근 가능한 로컬 NAS 볼륨으로 이동; Corona 설정에서 네트워크 타임아웃 증가
워커 라이선스 활성화 실패	MAC 주소 불일치 또는 라이선스 키 만료	라이선스 데이터베이스에서 MAC 주소 확인; 만료하면 라이선스 갱신
노이즈/아티팩트가 일관되게 나타남	워커 캐시 손상	모든 워커에서 `C:\\\\ProgramData\\\\Corona\\\\Cache` 지우고; 재제출

렌더팜에서 Corona 대 V-Ray: 각각을 언제 사용할지

Corona 강점:

대규모 씬 지원(5억+ 폴리곤, 10GB+ 텍스처)
일관되고 깨끗한 출력물로 관리할 아티팩트가 적어요
뛰어난 건축 및 제품 시각화 품질
CPU만 사용하므로 예측 가능한 확장(더 많은 코어 = 더 빠름)

우리 렌더팜에서 Corona 설정에 대한 더 많은 세부 정보는 우리 Corona 렌더팜 랜딩 페이지를 보세요.

Corona 약점:

CPU만 사용(GPU 경로 없음), 그래서 코어당 V-Ray GPU보다 느려요
더 비싼 라이선싱(머신당 아님, 코어당)
V-Ray보다 작은 플러그인 생태계

V-Ray 강점:

GPU 렌더링(RTX 카드) — 복잡한 씬에 빨라요
분산, 네트워크 렌더링이 잘 정립돼 있어요
더 큰 생태계 및 서드파티 지원

V-Ray 약점:

GPU 메모리는 씬을 약 50~100GB 텍스처 예산으로 제한해요
GPU 리소스 경쟁 — 하나의 무거운 씬이 다른 것을 굶주려요

우리의 의사결정 프레임워크:

Corona용: Archviz(>200M 폴리곤), 제품 시각화, 대규모 자산 라이브러리를 가진 스튜디오 작업
V-Ray용: 짧은 처리량, GPU 가용, 애니메이션 렌더링(프레임 렌더팜)
둘 다: 대량 혼합 작업 — Corona 및 V-Ray 풀에 분산

분산 Corona 렌더링 최적화 기법

1. 타일 크기 조정: Corona는 프레임을 타일로 분할해요(기본값 32x32 픽셀). 작은 타일 = 세분화된 분배이지만 더 많은 네트워크 오버헤드. 큰 타일 = 더 적은 네트워크 왕복이지만 한 타일이 더 어려우면 불균형 부하. 우리는 일반적으로 4K 출력에 64x64, 8K에 128x128을 사용해요.

2. 다중 패스 렌더링: Corona는 프레임을 여러 패스로 분할하는 것을 지원해요(직접광, 간접광, AO 등), 각각을 독립적으로 렌더링해요. 이는 단일 패스 렌더링보다 빠르고 컴포지팅 유연성을 가능하게 해요. 우리 렌더팜은 기본적으로 모든 Corona 작업을 다중 패스로 렌더링해요.

3. 메모리 대역폭: Corona의 CPU 렌더링은 메모리 바운드지, CPU 바운드가 아니에요. 최대 RAM 주파수(3200MHz+)를 갖춘 듀얼 소켓 머신은 표준 RAM보다 약 20% 빠르게 렌더링해요. 우리는 Corona 전용 하드웨어에서 고주파 메모리를 지정해요.

4. 캐시 지역성: Corona는 CPU L3 캐시의 혜택을 받아요. 더 큰 캐시를 가진 머신(E5-2699 v4처럼 55MB L3)은 10~15% 더 빠르게 렌더링해요. Corona 용량을 프로비저닝할 때, 클록 속도보다 CPU 캐시를 우선시해요.

5. 네트워크 최적화: 10Gb LAN은 Corona 렌더팜에 투자할 가치가 있어요. 기가비트 LAN은 20개 이상의 동시 Corona 렌더링 위에서 병목이 돼요. 우리는 이를 문서화했어요; 10Gb 인프라를 가진 렌더팜은 25~30% 빠른 타일 전송을 보아요.

6. 씬 전처리: 렌더팜 제출 전에, Corona의 내장 "분산 렌더링용 전처리"를 사용해요. 이는 기하, 재료, 텍스처를 로컬로 캐시해요. 이는 실제 렌더링 중 네트워크 트래픽을 줄여요.

규모 배포: 우리 렌더팜 아키텍처

우리의 Corona 설정은 12개의 듀얼 소켓 Xeon 머신(528개 총 코어, 오버헤드 후 약 480개 사용 가능)에 걸쳐 있어요. 이 구성:

씬 복잡도에 따라 100~200개의 동시 Corona 작업 처리
일반적인 건축 시각화 4K + 무거운 GI 프레임 3~~5분을 20~~30분에 렌더링
월별 약 ₩6~8K 전력, 유지 보수, 라이선싱 비용
월별 약 ₩15~20K 수익 생성, 하드웨어 배포 후 18개월 내 2.5배 ROI 생성

온프레미스 Corona 렌더팜을 고려 중인 스튜디오의 경우, 이 규모는 손익분기점이에요. 300코어 아래, 클라우드 렌더링(AWS, Google Cloud)이 더 비용 효과적이에요. 500코어 위, 온프레미스가 더 잘 확장해요.

Super Renders Farm 은 클라우드 렌더팜이며 Chaos의 공식 렌더링 파트너에요.

FAQ

Corona를 같은 씬에서 V-Ray와 함께 사용할 수 있어요?

아니요. 한 씬은 한 엔진으로 렌더링돼요. 그러나 두 개의 패스를 렌더링할 수 있어요(하나 Corona, 하나 V-Ray) 그리고 후처리에서 합성해요. 복잡성 때문에 우리는 추천하지 않지만, 기술적으로 가능해요.

Corona는 중첩된 분산 렌더링(렌더팜 → 서브팜)을 지원해요?

아니요. Corona의 분산 모드는 주요 머신과 플랫 네트워크의 워커 머신을 기대해요. 중첩된 위임은 지원되지 않아요. 복잡한 씬은 렌더팜을 페더레이팅하지 않고 단일 렌더팜을 확대해서 처리돼요.

분산 렌더링의 전형적인 오버헤드는 얼마나 돼요?

네트워크 및 타일 합성 오버헤드는 5~~15%예요, 타일 크기 및 네트워크 지연시간에 따라. 1분 단일 머신 렌더링은 8개 머신에 분산되면 65~~75초가 걸릴 수 있어요(1분 ÷ 8 머신 = 7.5초, 5~15% 오버헤드 더함). 합성 오버헤드 때문에 약 50개 머신 이상에서 확장이 깨져요.

Corona를 인터넷을 통해 원격 렌더팜으로 렌더링할 수 있어요?

기술적으로 그렇지만 네트워크 지연시간이 비실용적으로 만들어요. 100ms 지연시간 → 타일 전송에서 눈에 띄는 지연. 우리는 로컬 기가비트 LAN을 권장해요. 원격 렌더링의 경우, 클라우드 서비스(Chaos Cloud, AWS, Google Cloud)를 최적화된 네트워킹으로 사용해요.

Corona의 라이선스는 인터넷 연결을 요구해요?

아니요. Corona 라이선스는 MAC 주소를 통해 노드 잠금돼요. 활성화되면, 오프라인으로 작동해요. 이는 인터넷 접근이 없는 보안 스튜디오에 이상적이에요. 라이선스 키는 영구적 — 구독 갱신이 없어요.

Corona가 워커 크래시 중간에 렌더링을 재개할 수 있어요?

아니요. 분산 렌더링은 워커가 실패하면 전체 작업을 재시작해요. 이는 강건한 하드웨어와 네트워크 모니터링이 중요한 이유예요. 크래시된 워커는 렌더링 중간에 계산 시간을 낭비해요. 우리는 능동적인 하드웨어 모니터링 및 열 관리를 통해 99.5% 워커 가용성을 유지해요.

렌더팜에서 Corona 씬 반복을 어떻게 처리해요?

버전 관리를 사용해요. 각 반복은 분리된 파일(scene_v01.max, scene_v02.max)이에요. 렌더팜 제출은 파일 버전에 연결되어, 추적 및 특정 반복의 재렌더링을 가능하게 해요. 우리는 작업 ID를 씬 버전에 매핑하는 파일 데이터베이스를 유지해요.

Corona의 출력 형식이 다운스트림 합성에 유연해요?

네. Corona는 임의 패스(직접, 간접, 반사, 확산, 그림자 등)를 가진 OpenEXR으로 렌더링할 수 있어요. 이는 완전한 합성 유연성을 가능하게 해요. 우리는 기본적으로 다중 패스 OpenEXR으로 렌더링해요. 후처리가 재렌더링 없이 조명, 재료, 효과를 조정할 수 있게 해요.

Corona가 처리할 수 있는 최대 씬 크기는 얼마나 돼요?

이론적으로 무제한이고, 사용 가능한 RAM으로만 제한돼요. 우리는 3GB 씬 파일(10억+ 폴리곤, 50GB 텍스처 라이브러리)을 256GB RAM 머신에서 문제 없이 렌더링했어요. 그 이상, 우리는 씬을 분할하고 후처리에서 합성할 거예요.

Corona가 렌더팜에서 모션 블러와 뎁스 오브 필드를 어떻게 처리해요?

둘 다 샘플링 중 계산돼요 — 별도 후처리 없어요. 모션 블러는 추가 레이 캐스팅 때문에 약간 느려요. 뎁스 오브 필드는 오버헤드가 최소예요. 둘 다 로컬 머신처럼 렌더팜에서 동일하게 작동해요.