에셋 파이프라인

에셋 파이프라인은 게임에 쓸 그림과 소리의 원본 파일을 게임이 바로 읽는 파일로 바꿔 게임 안까지 실어 나릅니다. 만들 때 쓰는 원본은 고치기 편한 형식이라 게임이 그대로 읽기에는 크고 느립니다. 웹 개발에서도 브라우저에 보낼 파일을 묶어 내보내는 단계를 같은 이름으로 부릅니다. 이 항목은 게임 쪽 뜻을 다룹니다.

쉽고 빠른 이해

에셋 파이프라인은 게임에 쓸 그림·모델·소리 파일을 게임용 파일로 바꿔 주는 자동 처리 과정입니다. 아티스트가 벽돌 그림을 저장하면 몇 단계를 거쳐 그래픽 카드가 바로 읽는 압축 그림이 게임 파일 속에 들어갑니다.

원본 파일은 다시 고치기 쉽도록 레이어까지 담고 있어 큽니다. 게임이 켤 때마다 이것을 직접 바꾸면 로딩이 길어집니다. 기기마다 읽는 파일 형식도 달라서 손으로 바꾸면 실수가 쌓입니다.

어떻게 도나:

아티스트가 원본을 팀 저장소에 올립니다
도구가 원본을 검사하고 기기마다 맞는 형식으로 바꿉니다
바꾼 파일을 큰 묶음 파일로 싸서 게임에 넣습니다

대가는 시간입니다. 바꾸는 일이 오래 걸려서 바뀐 것만 다시 바꾸는 장치를 따로 만들어야 합니다.

에셋이 몇 개 안 되는 작은 게임이나 시제품에서는 이 과정을 거의 두지 않기도 합니다. 장치를 만드는 수고가 조금 긴 로딩보다 더 크게 들기 때문입니다.

상세

이 절은 아티스트가 그린 벽돌 그림 한 장을 놓고 갑니다. 먼저 원본 파일과 게임 파일이 왜 다른지 봅니다. 그다음 그림이 게임 안에 들어가기까지 거치는 단계를 차례로 따라갑니다.

백엔드 개발자에게 가장 가까운 것은 빌드입니다. 빌드는 사람이 읽는 소스 코드를 컴퓨터가 돌리는 실행 파일로 바꿉니다. 에셋 파이프라인은 사람이 고치는 원본 데이터를 게임이 읽는 데이터로 바꿉니다. 바꾸는 대상이 코드가 아니라 데이터라는 점만 다릅니다.

에셋

에셋은 게임에 들어가는 파일 가운데 코드가 아닌 것을 모두 이르는 말입니다. 게임을 내려받을 때 받는 용량의 대부분이 코드가 아니라 에셋입니다. 그래서 에셋을 어떻게 다루느냐가 게임 크기와 로딩 시간을 크게 가릅니다.

에셋은 종류가 여럿입니다. 흔한 것을 표로 모으면 이렇습니다.

종류	담는 것
텍스처	물체 겉면에 입히는 그림
3D 모델	캐릭터나 건물 같은 물체의 입체 모양
애니메이션	캐릭터가 움직이는 동작
사운드	효과음과 배경 음악
레벨	게임 속 지형과 물건 배치

이 편에서는 주로 텍스처를 예로 듭니다. 다른 종류도 같은 길을 지납니다.

원본 파일과 게임 파일이 다른 까닭

아티스트는 에셋을 포토샵 같은 그림 편집 프로그램이나 블렌더·마야 같은 3D 제작 프로그램으로 만듭니다. 이런 프로그램을 업계에서는 DCC 도구(Digital Content Creation, 디지털 콘텐츠 제작 도구)라고 부릅니다. DCC 도구가 저장하는 원본은 나중에 다시 고치기 쉽게 만들어져 있습니다.

벽돌 그림의 원본에는 레이어가 여러 장 겹쳐 있습니다. 벽돌 무늬 한 장, 이끼 한 장, 그림자 한 장을 따로 둡니다. 그래야 이끼만 지우거나 그림자만 옅게 고칠 수 있습니다. 대신 파일이 큽니다. 화면에 보일 그림을 얻으려면 레이어를 합치는 계산도 거쳐야 합니다.

게임은 반대를 원합니다. 게임은 실행 중에 그림을 고치지 않으므로 레이어가 필요 없습니다. 필요한 것은 작은 크기와, GPU(Graphics Processing Unit, 그래픽 처리 장치)가 손대지 않고 바로 읽는 형식입니다. 그래야 메모리를 덜 쓰고 빨리 불러옵니다.

그래서 둘 사이에 바꾸는 단계가 들어섭니다. 이 바꾸기를 게임을 켤 때마다 하면 로딩이 길어집니다. 게임을 만들 때 미리 한 번 해 두는 까닭입니다. 에셋 파이프라인이 이 미리 해 두는 일을 맡습니다.

에셋이 몇 개 안 되는 작은 게임이나 시제품에서는 이 단계를 거의 두지 않기도 합니다. 원본에 가까운 그림을 넣고 게임이 켤 때 바꿉니다. 미리 바꿔 두는 장치를 만드는 수고가 조금 긴 로딩보다 더 크게 들기 때문입니다. 에셋이 늘고 내는 기기가 늘수록 파이프라인을 따로 두는 쪽으로 옮겨 갑니다.

원본에서 게임까지 거치는 단계

벽돌 그림 한 장이 지나는 길을 그리면 이렇습니다. 단계 이름은 엔진과 회사마다 조금씩 다릅니다. 순서는 대체로 같습니다.

flowchart TD
    A["DCC 도구에서 원본 저장"] --> B["저장소에 올리기"]
    B --> C["가져오기"]
    C --> D["검사"]
    D -->|규칙을 어기면| A
    D --> E["변환"]
    E --> F["묶기"]
    F --> G["게임이 불러오기"]

저장소에 올리기에서는 원본을 팀 모두가 받아 쓰게 합니다. 코드처럼 버전 관리 시스템에 올립니다. 다만 원본 그림과 모델은 크기가 큰 이진 파일이라 코드와 다르게 다룹니다. Git 에서는 Git LFS(Large File Storage, 대용량 파일 저장소) 같은 확장으로 큰 파일을 저장소 밖에 따로 맡깁니다.

가져오기(임포트)에서는 원본을 엔진이 다루는 중간 형식으로 옮깁니다. 원본 파일은 DCC 도구마다 형식이 다릅니다. 엔진은 이것을 읽어 자기만의 공통 형식으로 맞춰 둡니다.

벽돌 그림이라면 가져오기를 거쳐 레이어가 합쳐진 한 장짜리 그림이 됩니다. 이렇게 형식을 하나로 맞춰 두면 뒤 단계는 원본이 어느 도구에서 왔는지 몰라도 됩니다.

검사에서는 규칙을 어긴 에셋을 걸러 냅니다. 그림 가로세로가 정한 크기를 넘지 않는지, 모델을 이루는 삼각형 수가 한도 안인지, 파일 이름이 팀 규칙을 따르는지를 봅니다. 걸린 에셋은 만든 사람에게 되돌아갑니다. 문제를 게임을 다 묶은 뒤가 아니라 올린 직후에 알게 됩니다.

변환에서는 중간 형식을 기기별 게임 파일로 바꿉니다. 그림이라면 텍스처 압축을 거칩니다. 텍스처 압축은 그림을 GPU 가 압축을 풀지 않고 바로 읽을 수 있는 형식으로 줄이는 일입니다. 압축된 채로 올리므로 GPU 메모리를 덜 씁니다.

3D 모델이라면 메시를 바꿉니다. 메시는 모델의 입체 모양을 꼭짓점과 삼각형으로 나타낸 데이터입니다. 변환은 이것을 GPU 메모리에 바로 올릴 수 있는 배열로 바꿉니다.

언리얼 엔진처럼 이 변환 단계를 쿠킹이라고 부르는 엔진도 있습니다. 우리말로는 에셋을 변환하는 일을 흔히 「굽는다」고 말합니다.

묶기(패키징)에서는 수많은 작은 파일을 큰 파일 몇 개로 합칩니다. 작은 파일을 하나씩 열면 파일을 찾고 여는 비용이 쌓입니다. 바꾼 에셋은 큰 아카이브 파일 하나에 이어 붙이고 앞머리에 목차를 둡니다. 게임은 목차를 보고 원하는 에셋이 몇 번째 바이트에서 시작하는지 찾아 읽습니다.

불러오기에서는 게임이 게임 파일을 메모리로 읽어 들입니다. 이미 바로 읽히는 형식이므로 게임은 거의 손대지 않고 메모리와 GPU 에 올립니다. 앞 단계들이 한 일이 이 끝에서 짧은 로딩 시간으로 드러납니다. 게임이 도는 동안 에셋을 찾아 올리고 내리는 일은 에셋 매니저가 맡습니다.

원본 한 벌에서 나오는 기기별 결과

같은 게임을 데스크톱 컴퓨터와 휴대폰과 게임 콘솔에 내면 변환 결과가 기기마다 따로 생깁니다. 기기마다 GPU 가 읽을 수 있는 압축 형식이 다르기 때문입니다. 메모리 크기도 달라서 휴대폰용 그림은 더 작게 줄이기도 합니다.

원본은 한 벌만 둡니다. 기기별 결과는 파이프라인이 원본에서 다시 만들어 냅니다. 아티스트는 원본만 고치면 됩니다. 기기별 파일을 손으로 맞출 일이 없습니다. 같은 소스 코드로 리눅스용과 윈도우용 실행 파일을 따로 빌드하는 것과 닮았습니다.

바뀐 에셋만 다시 굽기

변환은 오래 걸립니다. 텍스처 압축 하나만 해도 계산이 무겁습니다. 에셋이 많은 게임에서 매번 전부를 처음부터 바꾸면 한 번 돌리는 데 아주 오래 걸립니다.

그래서 파이프라인은 지난 결과를 기억해 두고 다시 씁니다. 원본 파일 내용과 변환 설정을 넣어 해시 값을 만듭니다. 결과물에는 이 값을 꼬리표로 붙입니다. 다음에 같은 해시가 나오면 바뀐 것이 없다는 뜻입니다. 변환을 건너뛰고 지난 결과를 꺼냅니다. 코드 빌드의 빌드 캐시와 같은 생각입니다.

해시에 넣을 입력을 빠뜨리면 탈이 납니다. 변환 설정만 바꾼 경우가 그렇습니다. 설정이 해시에 안 들어가 있으면 파이프라인은 바뀐 것이 없다고 봅니다. 그러고는 지난번의 낡은 결과를 그대로 내줍니다.

이를 막으려면 결과를 바꿀 수 있는 것을 모두 입력에 넣습니다. 원본 파일과 변환 설정에 더해 변환 도구의 버전도 넣습니다.

파이프라인을 꾸리는 사람

에셋 파이프라인은 엔진이 기본으로 주는 부분과 팀이 덧붙이는 부분으로 이뤄집니다. 가져오기와 변환의 뼈대는 대개 유니티나 언리얼 엔진 같은 게임 엔진이 줍니다. 팀은 그 위에 자기 게임에 맞는 검사 규칙과 변환 설정을 얹습니다.

이 일을 흔히 테크니컬 아티스트가 맡습니다. 그림도 알고 도구도 만드는 사람입니다. 아티스트가 원본을 고친 뒤 게임에서 보기까지 걸리는 시간을 줄이는 것이 이들의 큰 몫입니다. 그 시간이 짧을수록 아티스트가 더 자주 고쳐 볼 수 있습니다.

웹 개발의 에셋 파이프라인

웹 개발에서도 같은 이름을 씁니다. Rails 같은 웹 프레임워크는 CSS(Cascading Style Sheets, 웹 페이지의 생김새를 정하는 언어)와 자바스크립트 파일을 브라우저에 보내기 좋게 바꾸는 단계를 에셋 파이프라인이라고 부릅니다. 여러 파일을 하나로 묶고 공백과 주석을 걷어 크기를 줄입니다. 파일 이름에는 내용으로 만든 해시를 붙입니다.

이름에 해시를 붙이는 까닭은 브라우저 캐시입니다. 내용이 바뀌면 이름도 바뀌므로 브라우저는 새 파일을 새로 받습니다. 안 바뀐 파일은 저장해 둔 것을 오래 씁니다. 요즘은 이 일을 번들러가 맡는 경우가 많습니다.

두 뜻의 뼈대는 같습니다. 사람이 고치기 쉬운 원본을, 실행하는 쪽이 바로 읽는 형식으로 미리 바꿔 둡니다. 받는 쪽만 다릅니다. 웹에서는 브라우저가 받고 게임에서는 게임 엔진과 GPU 가 받습니다.

에셋 파이프라인

상세

에셋

원본 파일과 게임 파일이 다른 까닭

원본에서 게임까지 거치는 단계

원본 한 벌에서 나오는 기기별 결과

바뀐 에셋만 다시 굽기

파이프라인을 꾸리는 사람

웹 개발의 에셋 파이프라인

관련 항목

에셋 파이프라인이 실어 나르는 에셋 종류

에셋 파이프라인이 거치는 처리 단계

에셋 파이프라인이 다시 굽지 않으려고 쓰는 장치

에셋 파이프라인이 거쳐 가는 도구

에셋 파이프라인과 뼈대가 같은 코드 빌드

에셋 파이프라인이라는 이름을 함께 쓰는 웹 도구

에셋 파이프라인이 속하는 상위 분류

에셋 파이프라인과 이름이 비슷한 다른 파이프라인