게임 업계에서 흔히 듣는 말이 있습니다. “유니티만 알아서는 현업에서 오래 버티기 어렵다.”

그 이유는 단순합니다.

대규모 회사의 게임 개발은 수십, 수백 명이 동시에 협업하고, 한 번 출시한 게임은 5년, 10년 이상 서비스를 이어갑니다. 이 과정에서 단순한 유니티 기본 코드만으로는 규모를 감당할 수가 없습니다. 그래서 대형 게임사들은 반드시 자체 프레임워크를 만들어 기본 API 위에 래핑을 씌웁니다.

이 프레임워크는 단순히 멋있어 보이기 위해 존재하는 게 아닙니다.

첫째, 팀 단위 협업을 위해서입니다. 프로그래머가 많아질수록 각자 다른 스타일로 코드를 짜면 충돌이 잦아지고 유지보수가 불가능해집니다. 이벤트 시스템, 태스크 풀, 데이터 프로바이더 같은 공통 구조를 두어야 코드의 일관성이 유지됩니다.

둘째, 장기 운영과 확장성 때문입니다. MMORPG처럼 라이브 서비스가 길게 이어지는 게임은 몇 년 뒤에도 새로운 기능이 붙고, 버그 수정이 반복됩니다. 초기에는 간단한 코드로도 동작하지만, 시간이 지날수록 관리가 지옥이 되죠. 프레임워크 구조를 도입하면 이런 복잡성을 통제할 수 있습니다.

셋째, 재사용성입니다. 다운로드 매니저, 리소스 로더, 데이터 관리, UI 업데이트 같은 기능은 모든 게임에서 필요합니다. 한 번 잘 만들어둔 프레임워크는 차기작에서도 그대로 가져다 쓸 수 있고, 개발 속도와 안정성이 동시에 확보됩니다.

반대로 학원이나 인강에서 가르치는 내용은 왜 이렇게 단순할까요? 그건 입문자를 고려하기 때문입니다. 객체지향, 디자인 패턴, 비동기 처리, 이벤트 기반 시스템까지 한 번에 알려주면 대부분 포기해버립니다. 그래서 교육 과정에서는 “버튼 하나 눌러 캐릭터 점프” 같은 단순 예제를 보여주며 성취감을 주는 방식으로 진행되는 겁니다. 결과는 금방 나오지만, 그 구조로는 현업에서 살아남을 수 없습니다.

결국 경쟁력의 차이는 여기서 갈립니다. 교육 과정에서 배운 것은 어디까지나 출발점일 뿐이고, 현업에서는 그 위에 프레임워크적 사고를 얼마나 빠르게 습득하고 체득하느냐가 진짜 실력을 가르는 기준이 됩니다.

대규모 게임사가 기본 유니티 코드를 그대로 쓰지 않고 프레임워크를 래핑하는 이유는 명확합니다. 협업, 장기 유지보수, 재사용성. 이 세 가지가 없으면 대형 프로젝트는 유지될 수 없기 때문입니다.

해당 프레임워크를 절대 한 번에 전부 이해하려 하지 마세요.

현업에서 쓰이는 프레임워크는 수많은 모듈과 기능이 얽혀 있고, 그 양이 방대합니다. 이벤트, 데이터 관리, 다운로드, UI, 리소스 로딩, 메모리 풀, 태스크 시스템 등등… 이 모든 걸 처음부터 끝까지 한 번에 파악하려고 하면 머릿속에 체계가 잡히기 전에 공부의 늪에 빠지게 됩니다. 포트폴리오 완성이 우선입니다.

프레임워크는 “전체를 외워서 쓰는 것”이 아니라, “필요할 때 해당 기능 부분만 찾아보고 이해하면서 확장해나가는 것”이 정석입니다. 예를 들어 리소스를 불러와야 한다면 Data Provider 부분만, 다국어를 적용해야 한다면 Localization 모듈만 집중해서 보면 됩니다. 이렇게 실제 구현 과정에서 맞닥뜨린 문제를 계기로 부분적으로 이해하고, 점차 연결해서 큰 그림을 완성해야 합니다.

왜 이렇게 해야 할까요?

  1. 양이 너무 많다

    대규모 프레임워크는 사실상 “작은 엔진”과 비슷할 정도로 방대한 코드량을 가집니다. 전체를 한 번에 읽어내려가면 지쳐버리고, 결국 이해도 안 된 채 포기하게 됩니다.

  2. 맥락이 필요하다

    기능이 실제로 필요하지 않은 상황에서 문서와 코드를 읽으면, 단순히 “이런 게 있구나” 정도로만 스쳐 지나가고 기억에도 남지 않습니다. 반대로, “지금 UI에 다국어를 붙여야 하는데?”라는 필요성이 생긴 순간에 해당 모듈을 보면 훨씬 빠르게 이해됩니다.

  3. 현업 방식과도 같다

    실제 회사에서도 프레임워크를 입사 첫날부터 완전히 이해하는 건 불가능합니다. 선배 개발자들도 필요할 때 필요한 부분만 파고들며 점차 익숙해집니다. 중요한 건 전체 구조를 억지로 외우는 게 아니라, “어디에 무엇이 있는지, 필요한 순간에 어떻게 접근할지” 감을 잡는 것입니다.

<aside> 📝

유니티와 언리얼의 프레임워크 비교

유니티와 언리얼은 단순히 엔진이 다를 뿐만 아니라, 개발자가 성장하는 방식도 완전히 다릅니다.

유니티는 기본 엔진이 심플하기 때문에 큰 프로젝트를 만들려면 반드시 프레임워크를 직접 구현하고 래핑해야 합니다. 데이터 로딩, 이벤트 큐, 다운로드 매니저, 상태 머신 같은 시스템들을 하나하나 직접 설계하면서, 개발자는 자연스럽게 구조를 짜는 힘을 키워갑니다.

반대로 언리얼은 이미 방대한 프레임워크를 내장하고 있습니다. GameMode, GameInstance, Actor, Component, Subsystem 같은 구조부터 시작해, 온라인 멀티플레이를 위한 리플리케이션, 대규모 전투를 위한 GAS, 리소스 최적화를 위한 Async Loading까지 다 갖춰져 있죠. 그래서 언리얼에서는 뭔가를 새로 만드는 것보다, 이미 있는 시스템을 해체하고 이해하며 자기 것으로 만드는 과정이 곧 경쟁력의 핵심이 됩니다.

즉, 유니티는 없는 것을 직접 만들며 성장하는 엔진이라면, 언리얼은 이미 있는 거대한 구조를 뜯어보고 소화하며 성장하는 엔진입니다.

유니티에서 경쟁력은 “프레임워크를 직접 설계할 수 있는 능력”이고, 언리얼에서 경쟁력은 “방대한 엔진 프레임워크를 깊게 이해하고 상황에 맞게 확장할 수 있는 능력”인 셈이죠.

결국 두 엔진 모두 개발자에게 요구하는 건 같습니다.

단순히 예제나 튜토리얼 수준에서 멈추는 게 아니라, 엔진의 깊은 구조를 얼마나 자기 것으로 만들 수 있느냐가 현업에서의 진짜 경쟁력입니다.

</aside>