장장 35년을 이어온 거대 로봇물 꿈의 제전 ‘슈퍼로봇대전’. 다만 지난해 이맘때쯤 ‘슈퍼로봇대전 Y’가 발매되기까지 수년간 신작 소식이 끊겨 뭇 팬의 애간장을 태운 바 있다. 오랜 사령탑인 테라다P가 떠나며 새로운 개발 체제로의 이행과 더불어, 개발 엔진을 유니티로 교체하는 대작업을 거쳤으니 늦은 것도 이해 못 할 바는 아니다.

그렇다면 ‘슈퍼로봇대전’은 어째서, 그리고 어떻게 유니티 엔진 기반의 게임으로 거듭났는가. 이에 반다이남코 포지 디지털 소속 리드 아티스트 타나카 노부유키와 리드 소프트웨어 엔지니어 푸충 양이 7월 21일(화) 코엑스서 열린 ‘유나이트 서울 2026’서 ‘슈퍼로봇대전 Y 개발기: 레거시 시리즈의 유니티 마이그레이션 여정’이란 주제로 발표했다.

※ PPT 촬영 금지였던 관계로, 이해를 돕고자 임의의 스크린샷을 넣었습니다.

반다이남코 포지 디지털 타나카 노부유키 리드 아티스트(좌), 푸충 양 리드 소프트웨어 엔지니어(우)

35년간 1,900만 장, 그러나 쌓여버린 과제

“어린 시절부터 ‘슈퍼로봇대전’을 좋아해 자주 즐겼지만, 당시에는 설마 내가 직접 만드는 쪽이 되리라고 상상도 못했다"라고 밝힌 푸충 양 리드는 대만 출신으로 ‘슈퍼로봇대전 Y’ 시스템 개발 및 그래픽스, 퍼포먼스 최적화를 책임졌다. 타나카 노부유키 리드는 α(알파) 시절부터 배틀 애니메이션 제작에 참여한 베테랑이자 ‘슈퍼로봇대전 Y’ 그래픽 전반의 제작 관리 담당이었다.

‘슈퍼로봇대전’은 여러 기체와 파일럿을 강화하고 다음 미션을 선택하는 전략 파트, 작품 간 크로스오버가 전개되는 어드벤처 파트, 유닛을 조작해 전투를 진행하는 전투 맵, 그리고 시리즈의 대표적 매력으로 꼽히는 배틀 애니메이션까지 크게 네 파트로 구성된다. 타나카 리드는 “각 파트는 요구되는 역할과 표현이 서로 다르다”며 “번 재구축에서도 파트마다 서로 다른 기술적 과제에 대응해야 했다”고 설명했다.

시리즈가 안고 있던 문제는 세 갈래로 정리됐다. 첫 번째는 기술적 과제다. 개발 환경이 초기 PS 시절부터 발전을 이어 온 결과 자체 툴과 구조가 켜켜이 쌓였다. 두 번째는 개발 체제의 과제로, 오랜 개발 과정에서 지식과 노하우가 베테랑 개인에 쏠려 신규 인원이 합류할 때 드는 교육 비용과 적응 부담이 커졌다. 세 번째는 플랫폼 대응이다. 시장의 기기가 늘수록 멀티 플랫폼 대응 난도가 덩달아 올라갔고, 특히 스위치의 메모리 제약이 큰 과제였다.

타나카 리드는 작년 8월 최신작 ‘슈퍼로봇대전 Y’ 발매 시점에 시리즈 누계 출하량이 1,900만 장을 돌파했음을 밝혔다. 그는 “오랜 기간 시리즈를 지탱해 온 성과”라 자평하면서도 “동시에 이 상태로는 미래 지향적인 신작 개발은 어렵다고 느꼈다"고 덧붙였다. 요컨대 ‘슈퍼로봇대전’ 개발 체제는 단순한 개선이 아니라 변혁이 필요했다.

세 가지 선택지, 고심 끝에 내린 답은 ‘유니티’

개발팀은 엔진 교체가 정말 필요한지부터 다시 검토해 세 가지 선택지를 도출했다. 첫 번째는 기존 엔진을 계속 쓰는 방안이다. 당연히 비용이 가장 낮고 현재 개발 환경도 유지되지만, 지식의 쏠림과 멀티 플랫폼 대응 부담은 그대로 남을 따름이다. 푸충 양 리드는 “우리가 해결하려 했던 문제에 대한 답이 되지는 못한다”며 첫 번째 선택지를 지웠다.

두 번째는 새로운 자체 엔진을 개발하는 방안이다. ‘슈퍼로봇대전’에 맞춰 필요한 기능을 자유롭게 설계할 수 있다는 점은 이상적이었으나, 이제와 개발 엔진을 처음부터 만든다는 게 여간 수고스러운 일이 아니었다. 엔지니어들이 느낄 부담과 더불어 비용 역시 지나치게 커진다. 푸충 양 리드는 재차 “현실적인 선택지가 아니었다”며 선택지를 지웠다.

세 번째가 바로 ‘유니티’였다. 멀티 플랫폼 대응과 풍부한 인재, 충실한 에코 시스템이 개발팀이 지향하던 방향과 가장 부합했다. 푸충 양 리드는 “우리가 진짜 원했던 바는 눈앞의 문제를 해결하는 것만이 아니었다”며 “10년, 아니 20년 후에도 ‘슈퍼로봇대전’을 계속 만들 수 있는 개발 환경이 필요했다”고 말했다. 즉 단기 비용 대신 지속 가능성을 택한 셈.

‘유니티’로의 전환을 결정한 뒤 세운 재구축 방침은 “전부 다시 만들지는 않겠다”라고. 코어 시스템은 쇄신하되 기존 애셋은 최대한 살리고, 제작 팀에 미치는 영향을 억제하면서 기능 단위로 단계적으로 옮긴다는 것이다. 이날 세션에서는 그 가운데 변경 폭이 가장 컸던 애셋 관리와 렌더링, 퍼포먼스 최적화 세 영역을 소개했다.

애셋 관리, 참조를 지우고 일관된 규칙을 세우다

가장 크게 바뀐 영역은 애셋 관리다. ‘슈퍼로봇대전'은 캐릭터마다 여러 표정 차분을 갖고 있고, 작품에 따라 의상 배리에이션도 존재한다. 여기에 대화 장면용과 전투 애니메이션·UI용 페이스처럼 용도가 다른 일러스트까지 다 갖춰야 해 취급하는 애셋 수가 많은 편. 때문에 구 시스템은 에셋 변환에 전용 툴이 필요했고, 캐릭터 하나를 구현하는 데도 여러 담당자가 작업을 거쳤다. 에셋 수가 늘면서 어쩔 수 없는 실수와 관리 복잡화가 불거졌다.

‘유니티’ 전환과 함께 도입한 해결책은, 참조를 관리하는 대신 규칙을 관리하기로 한 것이다. 파일명을 키로 활용하고 어드레서블(Addressables)로 런타임에 로드하는 구조를 구축했으며, 수작업 참조 설정은 폐지하고 명명 규칙 중심 운용으로 바꿨다. 이제 시나리오 스크립트에 캐릭터 ID와 표정 번호가 기술되면, 게임 측이 둘을 조합해 키를 생성한다. 표정 번호 0번은 통상 표정을 뜻하며, 번호만 4번으로 바꾸면 생성되는 키가 달라지고 시스템이 새 키에 대응하는 에셋을 자동으로 가져와 표정이 바뀐 상태로 표시한다. 별도의 참조 설정 없이 스크립트와 명명 규칙만으로 필요한 에셋을 취득하는 구조다.

명명 규칙에는 대화 장면용인 스탠딩과 전투 애니메이션·UI용인 페이스를 구분하는 타입, 전투복·사복·적 버전 등을 지정하는 배리에이션, 그리고 표정 번호가 조합된다. 0번은 통상 표정, 3번은 미소 같은 식이다. 모든 애셋이 똑같은 규칙으로 관리되니 규칙에 맞춰 키를 만들기만 하면 끝. 덕분에 작업 공정이 축소되고 실수가 눈에 띄게 줄었다. 푸충 양 리드는 ”단순한 명명 규칙에 그치지 않고 워크플로를 지탱하는 시스템 설계의 일부가 됐다"고 설명했다.

옛 하드웨어에 의존하던 연출을 URP서 되살리다

다음으로 렌더링 재구축의 목표는 ‘슈퍼로봇대전’다운 외형과 분위기를 유지하는 것으로 설정됐다. 이에 따라 과거 작품의 연출을 재현할 것, 전투 애니메이션 품질을 유지할 것, 앞으로의 작품에서 새로운 연출을 추가할 수 있을 것이 주된 요건으로 잡혔다. 재현 대상이란 스토리 진행 중 화면 전체를 물결치듯 일그러뜨리는 연출, 로봇이나 캐릭터가 다른 공간에서 등장하거나 시공의 일그러짐을 표현할 때 쓰이는 시리즈 특유의 이펙트 등이다.

여기서 가장 까다로운 문제는 옛 하드웨어에 의존하던 특수 블렌딩 처리였다. 네거티브 블렌드 모드처럼 당시 하드웨어가 직접 지원하던 기능을 활용한 표현이 과거 시리즈에서 다수 쓰였지만, 현행 렌더링 파이프라인에서는 그대로 이용할 수 없다. 푸충 양 리드는 “과거 작품의 연출을 재현하려면 별도의 방법을 고안해야 했다”고 술회하며, 소스와 타깃의 차이의 절댓값을 구하는 앱솔루트 디퍼런스 방식을 하나의 예로 들었다.

바로 이 시점에 URP이 구원투수로 떠올랐다. 주목할 점은 세 가지다. 첫째는 이행 전략으로, 당시 빌트인 렌더 파이프라인의 장래성이 불안했고 ‘유니티’ 개발 방침도 URP 중심으로 옮겨 가고 있었다. 둘째는 접근 방식의 제약으로, 레거시 블렌드 모드 같은 표현과 시리즈 고유 연출에 대응하기에는 기존 구조는 유연성이 충분치 않았다. 셋째는 확장성. 스크립터블 렌더 파이프라인으로 필요한 렌더링 기능을 자유롭게 넣고, 커스텀 렌더 패스로 시리즈 고유 연출에 유연히 대응 가능하다고 봤다.

실제 구현은 각 표현마다 전용 렌더 패스를 만들면 된다. 렌더링 파이프라인 중간에 자체 커스텀 렌더 패스를 추가해 필요한 묘사 처리를 넣는다. 렌더 패스가 실행할 이펙트를 선택하고 머티리얼, 파라미터를 설정한 뒤 묘사 처리를 실행하면 실제 묘사는 셰이더가 책임진다. 소용돌이 이펙트와 라디얼 블러를 조합해 화면에 일그러짐 처리를 적용한 뒤 블러를 걸고 합성하는 식. 나중에 또 포스트 이펙트가 필요해지면 동일 구조로 구현할 수 있다고.

병목은 GPU가 아닌 CPU였다, 판단은 꼭 실기로

최적화 파트에서는 내부적인 진단이 틀렸던 실제 사례를 들었다. ‘슈퍼로봇대전 Y’ 최적화는 닌텐도 스위치를 기준으로 최적화에 힘썼다. 그 과정서 내심 GPU가 주된 병목이라고 판단했지만 실제로는 CPU 처리와 메모리가 관건이었다. 문제를 어렵게 만든 요인은 이 현상이 유니티 에디터에 거의 잡히지 않았다는 점이다. 에디터로는 별 문제가 보이지 않았지만 닌텐도 스위치 실기에서 확인하자 큰 폭의 퍼포먼스 저하와 메모리 크래시가 발생했다.

푸충 양 리드는 이 경험에서 얻은 교훈으로 “가설만으로 판단해서는 안 된다”며 최적화는 반드시 실기에서 계측하고 그 결과에 근거해 개선하라고 강조했다. 참고로 CPU 병목의 원인은 전투 맵 그리드였다. ‘슈퍼로봇대전’은 맵을 그리드 표시로 전환할 수 있고 이동 및 공격 범위 표시까지 병행되기에 대량의 그리드 오브젝트를 그려야 한다. 당초 이를 개별 오브젝트로 묘사하면서 드로 콜이 늘고 CPU 부하가 높아졌다.

해법은 생성 시점에 한 번만 메시를 결합하는 방식이었다. 사전에 메시를 준비해 두는 방법도 있었지만, 맵 사이즈나 그리드 수가 자주 바뀌는 시리즈 특성상 기획자와 디자이너의 워크플로에 제약을 주고 싶지 않아 런타임 메시 생성을 택했다. GPU 인스턴싱도 검토했으나 그리드가 생성 후 거의 변화하지 않는다는 점과 CPU 오버헤드를 함께 고려해 런타임 메시 결합 방식을 선택했다. 그 결과 드로 콜을 큰 폭으로 줄이고 CPU 부하를 개선했다.

거기다 GPU 문제가 없었던 것도 아니다. 특정 스테이지서 퍼포먼스가 떨어지는 현상을 조사한 결과 지나치게 고해상도 텍스처와 라이트맵이 쓰이고 있었다. 이에 고해상도 텍스처가 메모리 대역폭에 부하를 주면서 GPU 병목이 발생한다는 가설을 세우고 또 검증해냈다. 다만 일부 텍스처가 스테이지 전체에 공유되고 작은 오브젝트까지 포함하고 있어 해상도를 쉬이 낮출 수 없었다. 대신 라이트맵과 노멀맵 등을 재검토하고 플랫폼별 에셋을 나눴으며, 특히 닌텐도 스위치에서는 ASTC 포맷을 활용해 메모리 대역폭 부하를 억제했다.

배틀 애니메이션, 스프라이트 스튜디오의 효용

‘슈퍼로봇대전’의 백미라 해도 좋을 배틀 애니메이션 파트는 타나카 리드가 설명했다. 사실 이 작업은 오랫동안 자체 툴은 쓰며 기능 추가를 거듭한 끝에 너무 복잡해진 상태였다. 여기서 ‘유니티’ 스프라이트 스튜디오를 활용해 유지보수가 쉬운 제작 구조를 구축했다. 타나카 리드는 " 단순한 툴 변경이 아니라 제작 효율과 품질의 향상이 목적"이었다고 덧붙였다.

새로운 워크플로에서는 작업 공정을 분할해 여러 스태프가 나눠 맡을 수 있도록 했다. 시리즈의 오랜 매력인 박력 있는 전투 연출을 유지하면서 효율적인 제작 환경을 구현했다는 설명이다. 이날 현장에서는 ‘슈퍼로봇대전’ 배틀 애니메이션 제작 지시서도 일부분 공개됐는데, 흔히 떠올리는 콘티만큼 상세히 만들지는 않고 컷 분할 이미지에 가까운 형태다.

엔진 전환은 설계 사상과 개발 체제의 재검토

이날 세션은 푸충 양, 타나카 리드가 ‘유니티’ 전환 과정서 얻은 네 가지 배움으로 마무리됐다. 첫 번째는 기술 자체보다 워크플로 설계가 중요하다는 점이다. 푸충 양 리드는 “아무리 뛰어난 기술을 투입하더라도 팀 전체가 효율적으로 활용할 수 없다면 의미가 없다”고 못박았다. 두 번째는 앞서 봤듯 명명 규칙처럼 단순한 요소도 시스템 설계의 일부가 될 수 있다는 것. 세 번째는 최적화를 설계 단계에서 고려해야 한다는 점으로 드로 콜, 메모리, 로딩 타임까지 처음부터 함께 살펴야 함을 피력했다.

네 번째는 GC(Garbage Collector)에 지나치게 의존하지 말라는 것이다. 유니티는 GC에 맡기는 데 그치지 않고 메모리 관리 자체를 설계하는 것이 중요하다며, 이것이 프로젝트 종반에 특히 강하게 실감한 배움이었다고 밝혔다. 끝으로 푸충 양 리드는 “마이그레이션은 단순히 엔진이나 코드를 바꿔 놓는 것이 아니라 워크플로와 설계 사상, 그리고 개발 체제 그 자체를 재검토하는 것”이라며 "금번 재구축을 통해 우리는 단순히 엔진을 변경한 것이 아니라 ‘슈퍼로봇대전’의 미래로 이어질 개발 기반을 다질 수 있었다”며 발표를 끝맺었다.