게임그래픽 작업은 결국 엔진 안에서 완성됩니다. 툴에서 아무리 멋지게 보여도 엔진에 올리면 색이 달라지거나 그림자가 어색해지는 일이 흔합니다. 수업에서는 완성…
문제 하나: 예쁜데 무거운 화면
TA가 가장 자주 마주하는 문제는 성능입니다. 아티스트는 더 많은 디테일과 효과를 넣고 싶어 하고, 게임은 정해진 기기에서 일정한 프레임을 유지해야 합니다. 특히 모바일 게임처럼 다양한 성능의 기기를 지원해야 하는 경우, 고사양 기기에서는 괜찮던 장면이 저사양 기기에서는 끊기는 일이 흔합니다.
이때 TA는 무엇이 무거운지부터 찾습니다. 엔진의 프로파일링 도구로 화면을 그리는 데 시간이 어디서 많이 드는지 확인하고, 원인이 폴리곤 수인지, 텍스처 용량인지, 겹쳐 그려지는 반투명 효과인지, 그림자 계산인지를 가립니다. 원인을 찾으면 거리에 따라 단순한 모델로 바꾸는 LOD, 텍스처 압축과 묶음 처리, 효과의 개수 조정처럼 화면 품질을 최대한 지키면서 부담을 줄이는 방법을 제안합니다.
문제 둘: 원하는 표현이 기본 기능으로 안 될 때
아트 디렉터가 물에 젖은 듯한 바닥, 캐릭터가 다가가면 흔들리는 풀, 만화처럼 테두리 선이 들어간 캐릭터를 원한다고 해 봅시다. 엔진의 기본 머티리얼만으로는 이런 표현을 만들기 어려운 경우가 많습니다. TA는 셰이더를 작성하거나 노드 기반 머티리얼을 짜서 이런 표현을 구현합니다.
셰이더는 화면의 각 점이 어떤 색으로 보일지를 계산하는 작은 프로그램입니다. 빛을 어떻게 받는지, 표면이 얼마나 반짝이는지, 시간이 지나면서 어떻게 움직이는지를 정합니다. TA는 원하는 표현을 만드는 동시에 그 셰이더가 너무 무겁지 않은지도 확인해야 하므로, 앞의 성능 문제와 늘 함께 고민하게 됩니다. 아티스트가 숫자 몇 개만 바꿔 색과 강도를 조절할 수 있게 만들어 주는 것도 중요한 부분입니다.
문제 셋: 아트가 엔진에 들어가는 길이 막힐 때
아트 작업은 3D 툴에서 만들어져 게임 엔진으로 옮겨집니다. 이 과정을 파이프라인이라고 부릅니다. 파이프라인이 정리되지 않으면 아티스트마다 파일 이름, 크기 단위, 뼈대 구조, 텍스처 형식을 제각각으로 만들게 되고, 엔진에 넣을 때마다 오류가 나거나 손으로 고쳐야 하는 일이 생깁니다.
- 모델의 크기 단위와 기준점이 엔진과 맞지 않아 크기가 이상하게 들어감
- 파일 이름 규칙이 달라 엔진에서 에셋을 찾기 어려움
- 캐릭터 뼈대 구조가 달라 같은 애니메이션을 함께 쓸 수 없음
- 텍스처 형식과 해상도가 제각각이라 용량이 불필요하게 커짐
TA는 이런 규칙을 정해 문서로 만들고, 규칙을 지켰는지 자동으로 검사하는 장치를 만들기도 합니다. 새 아티스트가 합류했을 때 이 문서만 읽고도 같은 방식으로 작업할 수 있도록 예시 파일을 함께 두는 경우도 많습니다. 처음에는 귀찮아 보이지만, 파이프라인이 정리되면 수십 명의 아티스트가 같은 방식으로 일하게 되어 전체 작업 속도가 크게 올라갑니다.
문제 넷: 반복 작업에 시간이 새어 나갈 때
아티스트가 하루에 같은 작업을 수십 번 반복하고 있다면 TA가 나설 차례입니다. 수백 개 에셋의 이름을 한꺼번에 바꾸거나, 여러 모델에 같은 설정을 적용하거나, 내보내기 과정을 버튼 하나로 줄이는 툴을 만드는 일입니다. 이런 툴은 3D 툴이나 엔진에서 쓰는 스크립트 언어로 만드는 경우가 많습니다.
툴을 만들 때 중요한 것은 쓰는 사람의 입장입니다. 기능이 강력해도 사용법이 복잡하면 아티스트가 쓰지 않습니다. 그래서 TA는 실제로 그 작업을 하는 아티스트 옆에서 어떤 순서로 일하는지 지켜보고, 가장 불편한 지점을 먼저 해결합니다. 작은 툴 하나가 팀 전체의 야근을 줄이는 경우도 있어, TA의 성과가 가장 눈에 잘 보이는 영역이기도 합니다.
문제를 풀기 위해 TA가 갖추는 역량
| 역량 | 쓰이는 장면 |
|---|---|
| 아트 이해 | 아티스트가 원하는 표현과 우선순위를 알아들음 |
| 엔진·렌더링 지식 | 화면이 그려지는 원리를 알고 병목을 찾음 |
| 셰이더·머티리얼 | 기본 기능 밖의 표현을 구현함 |
| 스크립트 | 반복 작업을 자동화하는 툴을 만듦 |
| 소통과 문서화 | 규칙과 해결 방법을 팀에 전달함 |
모든 역량을 처음부터 다 갖춘 TA는 드뭅니다. 3D 아티스트나 이펙트 아티스트로 시작해 기술 쪽으로 넓혀 가는 사람도 있고, 프로그래머로 시작해 아트 쪽 이해를 넓혀 가는 사람도 있습니다. 어느 쪽에서 출발하든 '이 문제를 어떻게 풀었는가'를 보여 주는 자료가 포트폴리오의 핵심이 됩니다. 소통 능력을 가볍게 보면 안 됩니다. TA가 아무리 좋은 해결책을 찾아도 아티스트가 이해하지 못하면 현장에서 쓰이지 않습니다. 최적화 때문에 디테일을 줄여야 할 때, 왜 줄여야 하는지와 어떤 대안이 있는지를 아트 팀이 납득할 수 있게 설명하는 것도 TA의 일입니다. 반대로 프로그래머에게는 아트 팀의 요구를 기술 용어로 정리해 전달해야 합니다.
포트폴리오에서 문제 해결을 보여 주는 법
TA 포트폴리오는 결과 화면만으로는 부족합니다. 어떤 문제가 있었고, 어떻게 원인을 찾았고, 무엇을 바꿨으며, 결과가 어떻게 달라졌는지를 함께 보여 줘야 합니다. 예를 들어 같은 장면의 최적화 전후 화면과 프로파일링 결과를 나란히 놓고, 품질을 얼마나 지키면서 부담을 줄였는지 설명하는 식입니다. 직접 만든 셰이더라면 노드 구조와 조절 가능한 값을, 툴이라면 사용 전후의 작업 시간 차이를 보여 주세요. 아트와 기술 중 어느 쪽에서 출발하는 것이 내게 유리한지 판단이 서지 않는다면, SBS아카데미게임학원 게임그래픽 과정 상담에서 지금까지 만든 3D 작업물을 기준으로 출발점을 정리할 수 있습니다.
자주 묻는 질문
TA가 되려면 프로그래밍을 얼마나 해야 하나요?
툴 제작과 셰이더 작업을 위해 스크립트와 기본적인 프로그래밍 개념은 필요합니다. 다만 게임 시스템 전체를 개발하는 프로그래머 수준까지 요구하는 경우는 많지 않습니다.
TA는 신입으로도 채용하나요?
경력직 채용이 많은 편이지만 신입이나 주니어 TA를 뽑는 회사도 있습니다. 문제 해결 과정을 보여 주는 포트폴리오가 있으면 신입도 경쟁력을 가질 수 있습니다.
가까운 캠퍼스에서 게임그래픽 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.