유니티 엔진 10년을 거슬러 올라간 인디 게임 업데이트 분투기

10년 된 유니티 프로젝트를 다시 연다는 것

혹시 몇 년 전에 만들었던 프로젝트를 다시 열어본 적 있으세요? 빌드가 안 되거나, 라이브러리 버전이 안 맞거나, 문서는 사라졌거나... 개발자라면 누구나 겪는 '시간 여행의 저주' 같은 상황이죠. 이번에 소개할 글은 바로 그 상황을 진짜로 겪은 개발자의 생생한 일지예요. Gun Rocket이라는 인디 게임을 10년 만에 업데이트하면서, 그동안 바뀐 유니티 엔진의 역사를 하나하나 뚫고 지나간 이야기입니다.

Gun Rocket은 2015년경 유니티 5 시절에 만들어진 게임이에요. 지금은 유니티 2023, 2024 버전이 나와 있는 시점이니, 엔진 메이저 버전만 따져도 수 세대가 차이 납니다. 단순히 '버전 올리기'가 아니라 사실상 고고학 발굴에 가까운 작업이었다고 해요.

10년 전 유니티와 지금의 유니티는 다른 물건이다

개발자가 가장 먼저 부딪힌 벽은 렌더링 파이프라인이었어요. 이게 뭐냐면, 게임 화면을 그리는 방식을 정하는 뼈대 같은 거예요. 예전에는 유니티에 딱 하나의 렌더 방식(지금은 Built-in Render Pipeline이라 부르는 것)만 있었는데, 지금은 URP(Universal Render Pipeline), HDRP(High Definition Render Pipeline) 등 여러 선택지가 있고 각각 셰이더 작성법도 다릅니다. 10년 전에 쓰던 커스텀 셰이더를 그대로 가져오면 핑크색으로 표시되거나(재질이 깨졌다는 신호예요) 아예 컴파일조차 안 됩니다.

그다음 문제는 에셋과 플러그인의 수명이었어요. 에셋 스토어에서 샀던 플러그인들은 이미 판매 중단된 게 수두룩하고, 메인테이너가 연락이 안 되는 경우도 많죠. 특히 UnityScript(유니티 자바스크립트) 로 작성된 코드가 있으면 상황이 더 복잡합니다. 유니티는 2017년부터 UnityScript 지원을 중단해서, 이제는 그 코드를 전부 C#으로 재작성해야 하거든요. 다행히 유니티가 제공했던 자동 변환 도구가 있긴 했지만 완벽하진 않고, 결국 수작업 리팩토링이 붙습니다.

입력 시스템도 큰 변화가 있었어요. 예전 Input.GetKey 같은 API 대신 지금은 New Input System 패키지가 권장됩니다. 게임패드, 터치, 키보드를 통합적으로 다루는 구조인데, 10년 전 코드를 그대로 두면 동작은 해도 신형 컨트롤러 지원이 안 되거나 입력 지연이 생길 수 있어요. 마찬가지로 Mono에서 IL2CPP로 넘어간 빌드 백엔드도 큰 허들입니다. IL2CPP는 C# 코드를 C++로 변환 후 네이티브로 컴파일하는 방식인데, 성능이 좋아진 대신 리플렉션이나 동적 코드 로딩이 빡빡해져서 기존 코드가 런타임에 펑펑 터지는 경우가 있어요.

이 글이 주는 진짜 교훈

단순히 '업데이트 힘들다'는 푸념이 아니에요. 이 글에서 제가 인상 깊었던 포인트는 '장기 보존 가능한 프로젝트 설계'에 대한 간접 메시지예요. 엔진이나 프레임워크에 너무 깊이 종속된 코드는 시간이 지나면 빚이 됩니다. 반대로 순수 C#으로 비즈니스 로직(게임 로직)을 분리해 둔 부분은 거의 수정 없이 돌아갔다고 해요. 이건 게임 개발뿐 아니라 웹, 앱 어디서나 통하는 원칙이죠. 핵심 로직은 프레임워크 의존성을 최소화해야 수명이 길어진다는 것.

경쟁 엔진 쪽과 비교해보면 더 재밌어요. 언리얼 엔진은 C++ 기반이고 엔진 소스가 공개돼 있어서 하위 호환 이슈가 다른 결로 나타납니다. 옛날 프로젝트의 API가 deprecated되긴 해도, 엔진 코드를 직접 뜯어고쳐서 맞출 수도 있죠. Godot은 자체 스크립트 언어(GDScript)가 있어서 언어 자체는 바뀌어도 구조는 단순합니다. 유니티는 유연함과 폭넓은 플러그인 생태계를 제공한 대신, 버전 간 이주 비용이 상당히 크다는 게 이번 사례로도 잘 드러나요.

한국 개발자에게 주는 시사점

국내에도 유니티로 만든 오래된 프로젝트를 다시 살려야 하는 경우가 꽤 있습니다. 모바일 게임 IP를 리마스터하거나, 교육용 시뮬레이션을 현세대 OS에 맞추거나, AR/VR 버전을 내놓을 때 특히 그래요. 이때 무작정 최신 LTS로 점프하지 말고, 중간 버전을 거쳐 단계적으로 업그레이드하는 전략을 권합니다. 예를 들어 2019 LTS → 2021 LTS → 2022 LTS 순으로 올리면 각 단계마다 어떤 API가 망가지는지 추적하기 쉬워요. 한 번에 뛰면 어디서 터졌는지 찾기가 거의 불가능합니다.

그리고 깃 리포지토리를 버전별로 브랜치로 보존해두는 것도 강력 추천이에요. 유니티 프로젝트는 바이너리 에셋이 많아서 롤백이 까다로운데, 각 엔진 버전으로 마이그레이션한 시점의 스냅샷을 남겨두면 문제 발생 시 원인 추적이 훨씬 쉬워집니다. Git LFS 설정도 잊지 마시고요.

마무리

결국 이 이야기는 '내가 쓰는 도구에 대한 기술 부채는 반드시 돌아온다' 는 교훈으로 읽힙니다. 엔진 선택은 단기 생산성뿐 아니라 10년 뒤 유지보수 비용까지 포함해서 봐야 하는 결정인 거죠.

여러분은 지금 만들고 있는 프로젝트를 10년 뒤에 다시 열었을 때 빌드할 수 있을 거라 자신하세요? 만약 자신이 없다면, 어느 부분을 지금부터 더 '순수하게' 분리해두면 좋을까요?