- 들어가며
- 자산 파이프라인의 전체 흐름
- 실시간 파이프라인: 게임 엔진의 세계
- 오프라인 파이프라인: 영화의 렌더팜
- 실시간 vs 오프라인: 핵심 비교
- 최적화: 실시간을 떠받치는 기술
- 교환 포맷: glTF와 USD
- 협업: 파이프라인은 결국 사람의 흐름
- 리깅과 애니메이션: 자산에 생명을 불어넣다
- 한 자산의 여정: 검에서 게임 속 무기로
- 파이프라인의 흔한 함정
- 현대 파이프라인의 변화: 두 세계의 수렴
- 자산 관리: 버전과 캐시
- 마치며
- 참고 자료
들어가며
앞선 글에서 우리는 형태를 만들고(모델링), 표면에 재질을 입혔습니다(텍스처링·렌더링). 그러나 실제 작품 하나가 완성되기까지는 이보다 훨씬 긴 여정이 필요합니다. 모델은 UV를 펼치고, 텍스처를 입고, 뼈대를 갖추고, 움직임을 배우고, 마침내 빛 아래에서 한 장의 그림이나 한 편의 영상이 됩니다. 이 일련의 단계를 묶어 파이프라인(pipeline)이라 부릅니다.
흥미로운 점은, 같은 모델이라도 그것이 게임으로 가느냐 영화로 가느냐에 따라 파이프라인의 모양이 사뭇 달라진다는 것입니다. 게임은 1초에 수십 번씩 화면을 그려야 하므로 속도가 절대적입니다. 반면 영화는 한 프레임을 몇 시간에 걸쳐 계산해도 괜찮으므로 화질이 우선입니다. 이 근본적인 차이가 자산을 만드는 방식 전반에 영향을 미칩니다.
이 글에서는 3D 자산 파이프라인의 전체 흐름을 먼저 살펴본 뒤, 게임의 실시간(real-time) 환경과 영화의 오프라인(offline) 환경이 어떻게 갈라지는지, 그리고 그 사이에서 자산을 주고받는 포맷과 협업 방식까지 폭넓게 다루겠습니다.
자산 파이프라인의 전체 흐름
먼저 하나의 3D 자산이 거쳐 가는 표준적인 단계를 살펴보겠습니다. 게임이든 영화든 큰 줄기는 비슷합니다.
3D 자산 파이프라인의 표준 흐름
[모델링] 형태를 만든다
│
▼
[UV 언래핑] 표면을 2D로 펼친다
│
▼
[텍스처링] 재질과 색을 입힌다 (PBR 맵)
│
▼
[리깅] 움직일 수 있도록 뼈대(skeleton)를 심는다
│
▼
[애니메이션] 뼈대를 움직여 동작을 만든다
│
▼
[렌더] 빛을 비춰 최종 결과를 출력한다
각 단계를 간략히 짚어 보겠습니다.
- 모델링: 메시로 형태를 만듭니다.
- UV 언래핑: 텍스처를 입히기 위해 표면을 평면으로 펼칩니다.
- 텍스처링: 베이스컬러·러프니스·노멀 등 PBR 맵으로 재질을 정의합니다.
- 리깅(Rigging): 캐릭터나 움직이는 물체에 뼈대(스켈레톤)와 제어 장치를 심습니다. 마치 인형 안에 관절을 넣는 것과 같습니다.
- 스키닝(Skinning)/웨이트(Weight): 각 뼈가 메시의 어느 부분을 얼마나 움직일지 가중치를 정합니다.
- 애니메이션: 뼈대를 시간에 따라 움직여 동작을 만듭니다.
- 렌더: 카메라와 조명을 설정해 최종 이미지나 영상으로 출력합니다.
여기서 갈림길이 생깁니다. 마지막 두 단계, 특히 렌더가 실시간이냐 오프라인이냐에 따라 앞 단계의 작업 방식까지 거슬러 영향을 받습니다.
실시간 파이프라인: 게임 엔진의 세계
게임은 플레이어의 입력에 즉각 반응해 매 순간 새 화면을 그려야 합니다. 보통 초당 30회, 60회, 혹은 그 이상의 프레임을 끊김 없이 만들어 내야 하므로, 한 프레임을 그리는 데 허락된 시간은 수 밀리초에 불과합니다. 이 가혹한 제약이 실시간 파이프라인의 모든 결정을 지배합니다.
실시간 렌더 루프(단순화)
┌─────────────────────────────────────────┐
│ 매 프레임(예: 16.6ms 안에 완료) │
│ │
│ 입력 처리 ──▶ 게임 로직 ──▶ 컬링 │
│ │ │
│ ▼ │
│ GPU 드로콜 제출 ──▶ 셰이딩 │
│ │ │
│ ▼ │
│ 화면에 출력 │
└─────────────────────────────────────────┘
위 과정을 1초에 수십 번 반복
대표적인 게임 엔진으로 Unity와 Unreal Engine이 있습니다. 두 엔진은 실시간 렌더링, 물리, 사운드, 입력 처리 등을 통합 제공해, 자산을 받아 실제로 움직이는 인터랙티브 경험으로 만들어 줍니다.
실시간 환경에서 자산을 만들 때는 다음 개념이 핵심입니다.
폴리 예산(Poly Budget)
화면에 한 번에 그릴 수 있는 폴리곤 수에는 한계가 있습니다. 그래서 각 자산에 사용할 수 있는 폴리곤 수를 미리 정해 두는데, 이를 폴리 예산이라 합니다. 캐릭터, 소품, 배경마다 예산이 다르며, 이 안에서 최대한 보기 좋게 만드는 것이 실시간 아티스트의 핵심 역량입니다.
LOD(Level of Detail)
멀리 있는 물체는 자세히 그릴 필요가 없습니다. 그래서 같은 물체를 여러 단계의 정밀도로 준비해 두고, 카메라와의 거리에 따라 바꿔 끼웁니다. 이를 LOD라 합니다.
LOD 단계 전환
거리 사용 모델 폴리곤 수(예시)
──────── ──────────── ──────────────
가까움 LOD0(고밀도) 20,000
중간 LOD1 8,000
멀리 LOD2 2,000
아주 멀리 LOD3(저밀도) 500
* 멀어질수록 가벼운 모델로 교체해 성능 확보
드로콜(Draw Call)
CPU가 GPU에게 "이것을 그려라" 하고 지시하는 한 번의 명령이 드로콜입니다. 드로콜이 많아지면 CPU가 병목이 되어 성능이 떨어집니다. 그래서 여러 물체를 하나로 묶어(배칭) 드로콜 수를 줄이는 최적화가 중요합니다.
드로콜 최적화 개념
최적화 전 최적화 후(배칭)
물체A ──드로콜1──▶ 물체A ┐
물체B ──드로콜2──▶ GPU 물체B ├─드로콜1──▶ GPU
물체C ──드로콜3──▶ 물체C ┘
드로콜 3회 드로콜 1회 (CPU 부담 감소)
이 밖에도 텍스처를 하나로 합치는 아틀라스(atlas), 노멀맵으로 디테일을 대체하는 기법, 동일 재질로 묶기 등 다양한 최적화가 동원됩니다. 실시간 작업의 본질은 "제한된 자원으로 최대한 그럴듯하게"입니다.
오프라인 파이프라인: 영화의 렌더팜
영화나 고품질 영상의 한 프레임은 한 번 계산하면 끝입니다. 그 대신 화질에 타협이 없습니다. 한 프레임을 그리는 데 수십 분에서 수 시간이 걸려도 괜찮습니다. 90분짜리 애니메이션 영화라면 이런 프레임이 십수만 장 필요하므로, 한 대의 컴퓨터로는 감당할 수 없습니다. 그래서 등장하는 것이 렌더팜(render farm)입니다.
렌더팜의 작동 개념
[작업 제출]
샷/프레임을 작업 단위로 분할
│
▼
[스케줄러/큐] 작업을 여러 노드에 분배
│
┌────┼────┬────┐
▼ ▼ ▼ ▼
노드1 노드2 노드3 ... 노드N (수십~수천 대)
│ │ │ │
└────┴────┴────┘
│
▼
[결과 수합] 완성된 프레임을 모아 영상으로
렌더팜은 수많은 컴퓨터(노드)가 프레임을 나눠 동시에 계산하는 분산 시스템입니다. 영화 1편을 만들 때 한 컴퓨터로 1000일이 걸릴 작업도, 1000대로 나누면 하루에 끝낼 수 있습니다. 오프라인 렌더는 주로 레이트레이싱·패스트레이싱 계열을 사용해, 반사·굴절·간접광·서브서피스 스캐터링(피부 같은 반투명 표면) 등을 물리적으로 충실히 계산합니다.
오프라인 환경에서는 폴리곤 수나 텍스처 해상도에 대한 제약이 훨씬 느슨합니다. 디스플레이스먼트로 진짜 굴곡을 만들고, 수억 개의 폴리곤을 동원하며, 8K 텍스처를 여러 장 쌓아도 됩니다. 화질이 최우선이기 때문입니다.
실시간 vs 오프라인: 핵심 비교
두 파이프라인의 차이를 한눈에 정리하면 다음과 같습니다.
실시간 vs 오프라인 비교
항목 실시간(게임) 오프라인(영화)
───────────── ────────────────── ──────────────────
프레임 시간 수 밀리초 수 분~수 시간
렌더 방식 주로 래스터화 주로 레이/패스 트레이싱
폴리곤 제약 엄격(폴리 예산) 느슨
텍스처 해상도 제한적 매우 높음
최적화 비중 매우 큼(LOD/드로콜) 상대적으로 작음
상호작용 있음(플레이어 입력) 없음(정해진 카메라)
목표 부드러운 성능 최고의 화질
대표 도구 Unity, Unreal Cycles, Arnold 등
다만 이 경계도 점점 흐려지고 있습니다. 실시간 엔진의 화질이 빠르게 좋아지면서, 영화·드라마의 배경을 거대한 LED 화면에 실시간으로 띄우고 그 앞에서 촬영하는 가상 프로덕션(virtual production) 같은 기법이 늘고 있습니다. 또한 게임에서도 부분적인 레이트레이싱이 도입되어 두 세계가 서로 닮아 가고 있습니다. 이러한 기능의 지원 범위는 하드웨어와 엔진 버전에 따라 다를 수 있습니다.
최적화: 실시간을 떠받치는 기술
특히 실시간 파이프라인에서 최적화는 선택이 아니라 생존의 문제입니다. 앞서 본 LOD·드로콜 외에도 자주 쓰이는 기법을 정리하면 다음과 같습니다.
- 컬링(Culling): 화면 밖에 있거나 다른 물체에 가려 보이지 않는 것은 아예 그리지 않고 건너뜁니다. 보이지 않는 것을 그리는 낭비를 막습니다.
- 텍스처 아틀라스/압축: 여러 텍스처를 한 장으로 합치고, GPU 친화적인 형식으로 압축해 메모리와 대역폭을 아낍니다.
- 인스턴싱(Instancing): 같은 물체(나무, 풀, 군중)를 수천 개 그릴 때, 데이터를 한 번만 보내고 위치만 바꿔 반복합니다.
- 밉맵(Mipmap): 텍스처를 여러 크기로 미리 준비해, 멀리 있는 표면에는 작은 텍스처를 써서 깜빡임을 줄이고 성능을 높입니다.
- 베이크된 조명(Baked Lighting): 움직이지 않는 정적 환경의 그림자와 간접광을 미리 계산해 텍스처(라이트맵)에 구워 둡니다. 실시간에 매번 계산하지 않아 가볍습니다.
프레임 예산의 분배(개념)
한 프레임 16.6ms 안에서
████████ 렌더(셰이딩/조명)
████ 물리/충돌
███ 게임 로직/AI
██ 애니메이션
█ 그 외
* 어느 한쪽이 예산을 넘으면 프레임이 떨어진다(끊김)
오프라인에서도 최적화가 전혀 없는 것은 아닙니다. 렌더 시간을 줄이기 위해 샘플 수를 조절하고, 디노이저(denoiser)로 노이즈를 제거하며, 불필요한 광선 계산을 줄이는 등의 노력이 이루어집니다. 다만 그 절실함의 정도가 실시간과는 비교가 되지 않습니다.
교환 포맷: glTF와 USD
여러 도구와 사람이 자산을 주고받으려면 공통의 언어, 즉 표준 파일 포맷이 필요합니다. 오늘날 가장 주목받는 두 가지를 살펴보겠습니다.
주요 3D 교환 포맷의 성격
포맷 주된 용도 특징
────── ────────────────── ─────────────────────────
glTF 실시간·웹·게임 전송 가볍고 빠른 전송에 최적,
PBR 표준 내장
USD 대규모 영화 제작 협업 거대 씬의 레이어·조합에 강함
FBX 범용 자산 교환 오랜 산업 표준, 호환성 넓음
OBJ 단순 형태 교환 단순·고전적, 애니메이션 약함
- glTF(GL Transmission Format): Khronos 그룹이 만든 개방형 포맷입니다. "3D계의 JPEG"이라 불릴 만큼 가볍고 전송에 최적화되어 있으며, PBR 머티리얼을 표준으로 담습니다. 웹과 실시간 환경에서 널리 쓰입니다.
- USD(Universal Scene Description): 픽사가 개발해 공개한 포맷입니다. 거대한 영화 씬을 여러 사람이 레이어로 나눠 동시에 작업하고 조합하는 데 강력합니다. 대규모 제작 협업의 표준으로 자리 잡아 가고 있습니다.
- FBX: 오랫동안 자산 교환의 사실상 표준으로 쓰여 온 포맷으로, 호환성이 넓습니다.
포맷마다 강점이 다르므로, 어디로 자산을 보내느냐에 따라 적절한 것을 고릅니다. 웹 뷰어나 게임이라면 glTF, 영화 협업이라면 USD가 자연스러운 선택입니다.
협업: 파이프라인은 결국 사람의 흐름
큰 프로젝트에서 한 사람이 모든 단계를 다 하는 일은 드뭅니다. 모델러, 텍스처 아티스트, 리거, 애니메이터, 라이팅·렌더 담당이 각 단계를 맡아 자산을 이어받습니다. 그래서 파이프라인은 기술인 동시에 사람들 사이의 약속입니다.
협업 파이프라인의 흐름
모델러 ──▶ 텍스처 ──▶ 리거 ──▶ 애니메이터 ──▶ 라이팅/렌더
│ │ │ │ │
└─────────┴──────────┴─────────┴──────────────┘
버전 관리 · 자산 라이브러리 · 명명 규칙
* 한 단계의 결과가 다음 단계의 입력이 된다
* 일관된 규칙이 없으면 자산이 어긋나 작업이 막힌다
원활한 협업을 위해서는 몇 가지 약속이 필요합니다. 일관된 명명 규칙(파일과 오브젝트 이름을 통일), 버전 관리(누가 무엇을 언제 바꿨는지 추적), 공유 자산 라이브러리(반복 사용 자산을 한곳에서 관리), 그리고 단계 간 검수 절차입니다. 이런 약속이 없으면 아무리 솜씨 좋은 아티스트가 모여도 자산이 서로 어긋나며 작업이 멈춥니다.
기술적 파이프라인이 데이터의 흐름이라면, 협업 파이프라인은 사람과 책임의 흐름입니다. 좋은 스튜디오는 이 둘을 모두 잘 설계합니다.
리깅과 애니메이션: 자산에 생명을 불어넣다
파이프라인 중간에는 정적인 모델을 움직이게 만드는 단계가 있습니다. 바로 리깅과 애니메이션입니다. 이 단계가 어떻게 작동하는지 조금 더 들여다보겠습니다.
리깅의 기본 구조
[메시] ── 겉으로 보이는 형태
│
│ 안에 뼈대를 심는다
▼
[스켈레톤] ── 관절을 가진 뼈의 계층
│
│ 각 뼈가 메시의 어느 부분을 움직일지 정한다
▼
[스키닝/웨이트] ── 뼈와 메시의 연결 강도
│
▼
[컨트롤 리그] ── 애니메이터가 다루기 쉬운 조종 장치
리깅(rigging)은 모델 안에 디지털 뼈대(스켈레톤)를 심는 작업입니다. 사람이 골격을 가지고 움직이듯, 3D 캐릭터도 뼈를 따라 움직입니다. 그다음 스키닝(또는 웨이트 페인팅)으로 각 뼈가 표면의 어느 부분을 얼마나 끌고 갈지 정합니다. 팔꿈치를 굽혔을 때 피부가 자연스럽게 접히려면 이 가중치가 잘 잡혀 있어야 합니다.
마지막으로 컨트롤 리그를 만듭니다. 애니메이터가 뼈를 하나하나 직접 돌리는 것은 번거로우므로, 손이나 발 같은 직관적인 조종 장치를 만들어 둡니다. 잘 만든 리그는 인형극의 정교한 인형과 같아서, 애니메이터가 빠르고 자연스럽게 동작을 만들 수 있게 해 줍니다.
실시간과 오프라인은 여기서도 갈립니다. 게임의 캐릭터는 뼈 수와 영향 범위에 제약이 있어, 한 버텍스가 받는 뼈의 영향 수를 제한하는 경우가 많습니다. 반면 영화는 그런 제약이 느슨해 매우 정교한 얼굴 리그나 근육 시뮬레이션까지 동원할 수 있습니다.
한 자산의 여정: 검에서 게임 속 무기로
추상적인 단계만으로는 감이 오지 않으니, 가상의 자산 하나가 파이프라인을 통과하는 과정을 따라가 보겠습니다. 게임에 들어갈 검 한 자루를 예로 들겠습니다.
검 자산의 파이프라인 여정 (실시간)
1. 하이폴리 제작
스컬프팅으로 칼날의 흠집, 손잡이의 가죽 결까지 정교하게
2. 로우폴리 제작(리토폴로지)
게임용으로 폴리 예산에 맞춘 가벼운 메시
3. UV 언래핑
칼날·손잡이·날밑을 효율적으로 펼치기
4. 베이킹
하이폴리 디테일 → 로우폴리 노멀맵·AO로 굽기
5. 텍스처링
금속 칼날, 가죽 손잡이, 녹과 때를 PBR로
6. 익스포트
glTF/FBX로 내보내 게임 엔진에 임포트
7. 엔진 세팅
LOD 단계 생성, 충돌 메시 지정, 머티리얼 연결
이 여정에서 핵심은 하이폴리와 로우폴리의 분업입니다. 정교한 디테일은 하이폴리에서 만들되, 실제 게임에 들어가는 것은 가벼운 로우폴리입니다. 둘 사이를 잇는 다리가 바로 베이킹된 노멀맵입니다. 이 구조 덕분에 적은 폴리곤으로도 정교한 검이 화면에 나타날 수 있습니다.
같은 검이라도 영화로 간다면 여정이 달라집니다. 폴리 예산이 느슨하니 로우폴리 단계를 생략하고 하이폴리를 그대로 쓸 수도 있고, LOD나 충돌 메시 같은 실시간 전용 단계도 필요 없습니다. 대신 8K 텍스처와 디스플레이스먼트로 디테일을 끝까지 밀어붙입니다. 목적지가 작업의 모양을 결정한다는 것을 이 한 자루의 검이 잘 보여 줍니다.
파이프라인의 흔한 함정
파이프라인을 설계하고 운영할 때 자주 겪는 문제들이 있습니다. 미리 알아 두면 값비싼 재작업을 피할 수 있습니다.
- 스케일 불일치: 도구마다 기본 단위(센티미터·미터 등)가 달라, 자산을 옮길 때 크기가 100배 차이 나는 일이 흔합니다. 프로젝트 초기에 단위 기준을 정하세요.
- 뒤늦은 최적화: 화질만 좇다가 막판에 폴리 예산을 초과해 전면 재작업하는 경우입니다. 목표 예산을 처음부터 의식하며 만드세요.
- 명명 규칙 부재: 파일 이름이 제각각이면 자동화 도구가 자산을 찾지 못하고 협업이 꼬입니다. 규칙을 문서로 남기세요.
- 베이킹 오류 방치: 노멀맵 베이킹에서 생긴 흠(케이지 문제, 면 교차)을 무시하면 최종 화면에 이상한 그림자나 줄이 나타납니다. 베이킹 직후 검수하세요.
- 포맷 맹신: 한 포맷이 모든 정보를 완벽히 옮긴다고 가정하면 안 됩니다. 애니메이션·블렌드셰이프·머티리얼이 누락될 수 있으니, 옮긴 뒤 반드시 확인하세요.
- 버전 혼선: 누가 어떤 버전을 쓰는지 추적하지 않으면 옛 자산으로 작업하는 사고가 생깁니다. 버전 관리를 습관화하세요.
이 함정들의 공통점은 "초기의 약속 부재"입니다. 파이프라인은 시작할 때 정한 규칙이 끝까지 따라옵니다. 단위, 명명, 예산, 포맷에 대한 약속을 프로젝트 초반에 명확히 해 두면, 뒤에서 생기는 대부분의 문제를 예방할 수 있습니다.
현대 파이프라인의 변화: 두 세계의 수렴
앞서 실시간과 오프라인을 뚜렷이 구분했지만, 최근 몇 년 사이 그 경계는 빠르게 흐려지고 있습니다. 두 세계가 서로의 기술을 빌려 오면서 새로운 작업 방식이 생겨나고 있습니다.
실시간과 오프라인의 수렴
과거 현재
────────── ──────────
실시간 ───── 명확한 벽 ───── 오프라인
(속도) (화질)
▼ 경계가 흐려짐 ▼
실시간 ─── 가상 프로덕션 ─── 오프라인
게임용 RT 도입
엔진의 영화급 렌더
공통 포맷(USD)
대표적인 변화가 가상 프로덕션(virtual production)입니다. 거대한 LED 벽에 실시간 엔진으로 배경을 띄우고, 배우가 그 앞에서 연기하며 카메라로 촬영합니다. 카메라가 움직이면 LED 속 배경의 시점도 실시간으로 따라 바뀌어, 마치 실제 장소에 있는 듯한 화면을 즉석에서 얻습니다. 과거에는 영화의 영역이던 작업에 게임 엔진의 실시간 기술이 깊숙이 들어온 것입니다.
또 다른 흐름은 공통 포맷을 통한 협업입니다. 특히 USD는 영화·게임·시각화 등 서로 다른 분야가 같은 자산 기술 방식을 공유하도록 돕습니다. 한 자산을 여러 도구와 분야가 일관되게 주고받을 수 있게 되면서, 파이프라인 사이의 벽이 낮아지고 있습니다.
USD가 협업을 돕는 방식 (개념)
레이어 A (모델러) ┐
레이어 B (텍스처) ├── 합성(컴포지션) ──▶ 최종 씬
레이어 C (애니메) │ 각 레이어는 독립적으로
레이어 D (조명) ┘ 수정·교체 가능
다만 이러한 기능과 워크플로는 빠르게 발전하는 영역이라, 구체적인 지원 범위와 모범 사례는 도구·엔진의 버전에 따라 다를 수 있습니다. 큰 흐름은 분명합니다. 실시간과 오프라인은 각자의 강점을 유지하면서도, 자산을 공유하고 기술을 빌려 오며 서로 닮아 가고 있습니다. 따라서 오늘날의 3D 작업자는 어느 한쪽에만 갇히기보다, 양쪽의 사고방식을 모두 이해하는 편이 유리합니다.
자산 관리: 버전과 캐시
규모가 커질수록 자산을 "어떻게 저장하고 추적하느냐"가 작업 속도를 좌우합니다. 파이프라인 후반에서 흔히 다루는 두 개념을 살펴보겠습니다.
자산 버전 관리의 흐름
검_v001 ──▶ 검_v002 ──▶ 검_v003(현재)
(초안) (수정) (승인)
│
여기서 분기 가능
▼
검_v003_variant(변형)
* 옛 버전을 지우지 않고 보존해야 되돌릴 수 있다.
- 버전 관리: 자산의 변경 이력을 보존해, 문제가 생겼을 때 이전 상태로 되돌리거나 누가 무엇을 바꿨는지 추적합니다. 코드의 버전 관리와 같은 원리이지만, 용량이 큰 바이너리 파일을 다룬다는 특수성이 있습니다.
- 캐시(Cache): 시뮬레이션(천, 머리카락, 군중, 유체)처럼 계산이 무거운 결과를 미리 계산해 파일로 저장해 두는 것입니다. 매번 다시 계산하지 않고 저장된 캐시를 불러와 작업 속도를 높입니다. 알렘빅(Alembic) 같은 포맷이 이런 캐시 교환에 자주 쓰입니다.
시뮬레이션 캐시의 활용
무거운 시뮬레이션 계산 (1회)
│
▼
[캐시 파일로 저장] ── 결과를 동결
│
┌─────┴─────┐
▼ ▼
렌더 작업 다른 씬에 재사용
(빠르게) (다시 계산 불필요)
이처럼 큰 파이프라인은 단순히 자산을 만드는 데 그치지 않고, 그것을 체계적으로 저장·추적·재사용하는 시스템 위에서 돌아갑니다. 좋은 자산 관리는 눈에 잘 띄지 않지만, 프로젝트가 커질수록 그 가치가 분명해집니다.
마치며
3D 파이프라인은 모델링에서 시작해 렌더로 끝나는 긴 강줄기와 같습니다. 그 강은 목적지에 따라 두 갈래로 나뉩니다. 매 순간 새로 그려야 하는 게임의 실시간 세계는 속도를 위해 폴리 예산·LOD·드로콜 같은 제약과 최적화를 받아들입니다. 한 프레임에 시간을 들일 수 있는 영화의 오프라인 세계는 렌더팜을 동원해 화질을 끝까지 밀어붙입니다.
두 세계는 서로 다른 가치를 추구하지만, 출발점인 자산의 기본기는 같습니다. 깔끔한 토폴로지, 잘 펼친 UV, 충실한 PBR 텍스처는 어느 쪽으로 가든 좋은 결과의 토대가 됩니다. 그리고 glTF·USD 같은 포맷과 명확한 협업 약속이 그 자산을 사람과 도구 사이로 매끄럽게 흘려보냅니다.
어느 길을 택하든, 파이프라인 전체를 머릿속에 그릴 수 있는 사람은 자기 작업이 어디로 가는지 알고 만듭니다. 그 큰 그림이 결국 좋은 자산과 좋은 협업을 만드는 가장 든든한 밑바탕입니다.