<pname>AI 도구로 3D 메시 · 모션캡쳐 파이프라인 설계 (아티스트 없는 팀의 리소스 병목 해결기)</pname>
<tag>회고,개발</tag>
"리소스를 어떻게 만들까"가 아니라, "리소스 제작을 어떻게 단계로 나눠 병목을 풀까"
TL;DR
- 졸업 작품(언리얼 엔진)을 프로그래머 3명으로 진행했다. 타 게임 IP 사용 허락을 받아 개발했지만, 아티스트가 없어 필요한 추가 리소스는 직접 제작해야 했다.
- 게임에 쓸 일부 3D 메시와 전용 모션이 필요했고, 이걸 팀이 감당 가능한 방식으로 확보하는 것이 과제였다.
- 문제를 5단계로 분할하고, 각 단계에 맞는 AI 도구를 선정해 이어 붙이는 파이프라인을 설계했다.
- 각 단계에서 원하는 퀄리티가 안 나오면 앞 단계로 돌아가 보완하는 반복 루프로 품질을 맞췄다.
- 결과적으로 아이디어에서 3D 메시 + 모션캡쳐까지, 팀 내부에서 리소스 병목을 자체 해결했다.
구현 배경
졸업 작품은 프로그래머 3명으로 구성된 팀 프로젝트였다. 타 게임의 IP 사용 허락을 받아 개발되었지만, 팀에 아티스트가 없었다. 즉, 게임에 필요한 추가 리소스(3D 메시, 전용 모션 등)를 우리가 직접 만들어야 하는 상황이었다.
여기서 진짜 문제는 "3D를 못 만든다"가 아니라 "리소스 제작이 개발 전체의 병목이 된다" 는 점이었다. 프로그래머 셋이 각자 개발을 하면서, 손으로 모델링하고 애니메이션을 찍기에는 시간도 역량도 부족했다.
그래서 접근을 바꿨다. "어떻게 잘 만들까"가 아니라 "제작 과정을 어떻게 단계로 쪼개서, 각 단계를 감당 가능한 도구로 처리할까" 로 문제를 재정의했다.
파이프라인 설계
리소스 하나를 만드는 과정을, 입력과 출력이 명확한 5개의 독립 단계로 나눴다. 각 단계는 앞 단계의 결과물을 받아 다음 단계가 쓸 형태로 변환하는 역할을 한다. 이렇게 나누면 문제가 생겼을 때 어느 단계가 원인인지 특정하고 그 단계만 다시 돌릴 수 있다.
1단계 — 콘셉트: 캐릭터 이미지 레퍼런스 확보
Mixboard로 캐릭터 이미지 레퍼런스를 다양하게 생성한 뒤, 내부 회의를 통해 방향에 맞는 이미지를 채택했다. 여러 후보를 빠르게 펼쳐 놓고 팀이 함께 고르는 단계다.
2단계 — 정제: T-포즈 · 단색 배경으로 정리
채택한 레퍼런스를 NovelAI로 단색 배경의 T-포즈 이미지로 정제했다. 이건 다음 단계(3D 변환)가 잘 먹히도록 입력 규격을 맞추는 과정이다. 배경이 깔끔하고 자세가 표준(T-포즈)일수록 뒤 단계의 3D 변환 품질이 안정적으로 나온다.
3단계 — 3D 변환: 이미지 → 메시
정제된 이미지를 RodinAI로 T-포즈 3D 메시로 변환했다. 2단계에서 입력을 표준화해 둔 덕분에, 이 단계의 결과가 안정적으로 나올 확률이 높아진다.
4단계 — 모션 캡쳐: 연기 → 애니메이션
필요한 애니메이션을 휴대폰 카메라로 직접 연기해 녹화하고, 이를 DeepmotionAI로 모션 캡쳐하여 언리얼 기본 마네킹 스켈레톤으로 내보냈다. 여기서 핵심 판단은 출력 대상을 언리얼 기본 마네킹 스켈레톤으로 통일한 것이다. 공통 스켈레톤을 기준으로 삼아야 다음 단계의 리타게팅이 깔끔하게 성립한다.
5단계 — 통합: 리타게팅
4단계에서 만든 애니메이션을, 3단계에서 만든 3D 메시에 리타게팅했다. 표준 스켈레톤을 매개로, "따로 만든 메시"와 "따로 캡쳐한 모션"을 하나로 합치는 마무리 단계다.
반복 개선 루프
각 단계를 진행하며 원하는 퀄리티의 결과물이 나오지 않으면 앞 단계로 돌아가 보완하는 과정을 반복했다. 예를 들어 3단계 메시 품질이 아쉬우면 2단계의 정제 이미지를, 그것도 한계가 있으면 1단계의 레퍼런스 채택까지 거슬러 올라갔다.
이게 단계를 나눈 진짜 이유다. 파이프라인을 독립적인 단계로 설계했기 때문에, 전체를 처음부터 다시 만들지 않고 문제가 된 지점만 고쳐서 다시 흘려보낼 수 있었다. 소프트웨어에서 모듈을 나누는 이유와 정확히 같은 발상이다.
트레이드오프: 왜 이 방식이었나
- 희생한 것: 완전한 수작업 대비 각 단계 결과물에 대한 세밀한 제어권은 떨어진다. 도구의 출력 특성에 맞춰 입력을 조정하는 품이 든다.
- 얻은 것: 아티스트 없이도 아이디어에서 인게임 리소스까지 도달할 수 있었고, 프로그래머들이 개발을 병행하면서도 리소스 병목에 발목 잡히지 않았다.
프로덕션 규모의 상용 프로젝트였다면 당연히 전문 아티스트와 정식 DCC 파이프라인이 정답이다. 하지만 아티스트가 없고 시간이 제한된 졸업 작품이라는 맥락에서는, "완성도 최상"보다 "병목을 뚫고 게임을 굴러가게 만드는 것"이 우선이었다. 그 목표에 맞춰 내린 선택이었다.
결과
- 아이디어 → 캐릭터 콘셉트 → 3D 메시 → 모션캡쳐 → 리타게팅까지, 리소스 제작 전 과정을 팀 내부에서 완결했다.
- 아티스트가 없다는 제약을, 파이프라인 설계로 극복해 프로젝트의 리소스 병목을 자체 해결했다.
회고 / 배운 점
- 문제 해결의 핵심은 도구가 아니라 "단계를 어떻게 나누고, 단계 사이의 인터페이스(입력·출력 규격)를 어떻게 맞출까" 였다. 2단계의 T-포즈 정제, 4단계의 공통 스켈레톤 통일이 그 인터페이스 설계였다.
- 독립적인 단계 + 되돌아가는 루프 구조 덕분에, 실패를 국소화하고 반복 비용을 낮출 수 있었다. 이건 코드 아키텍처의 모듈화와 같은 사고방식이었다.
- 프로그래머의 역량이 반드시 코드 안에만 있는 건 아니라는 것도 배웠다. 문제를 분해하고 도구를 조합해 없던 워크플로우를 만들어내는 것 역시 엔지니어링이었다.
이 글은 각 단계의 산출물(레퍼런스 → 정제 이미지 → 3D 메시 → 최종 인게임 장면)을 한 줄로 나열한 이미지가 있으면, 파이프라인이 한눈에 전달되어 특히 효과적이다.
<pagelist>