Company
교육 철학

프로젝트 개요

게임 업계에서 흔히 듣는 말이 있습니다. “유니티만 알아서는 현업에서 오래 버티기 어렵다.”
그 이유는 단순합니다.
대규모 회사의 게임 개발은 수십, 수백 명이 동시에 협업하고, 한 번 출시한 게임은 5년, 10년 이상 서비스를 이어갑니다. 이 과정에서 단순한 유니티 기본 코드만으로는 규모를 감당할 수가 없습니다. 그래서 대형 게임사들은 반드시 자체 프레임워크를 만들어 기본 API 위에 래핑을 씌웁니다.
이 프레임워크는 단순히 멋있어 보이기 위해 존재하는 게 아닙니다.
첫째, 팀 단위 협업을 위해서입니다. 프로그래머가 많아질수록 각자 다른 스타일로 코드를 짜면 충돌이 잦아지고 유지보수가 불가능해집니다. 이벤트 시스템, 태스크 풀, 데이터 프로바이더 같은 공통 구조를 두어야 코드의 일관성이 유지됩니다.
둘째, 장기 운영과 확장성 때문입니다. MMORPG처럼 라이브 서비스가 길게 이어지는 게임은 몇 년 뒤에도 새로운 기능이 붙고, 버그 수정이 반복됩니다. 초기에는 간단한 코드로도 동작하지만, 시간이 지날수록 관리가 지옥이 되죠. 프레임워크 구조를 도입하면 이런 복잡성을 통제할 수 있습니다.
셋째, 재사용성입니다. 다운로드 매니저, 리소스 로더, 데이터 관리, UI 업데이트 같은 기능은 모든 게임에서 필요합니다. 한 번 잘 만들어둔 프레임워크는 차기작에서도 그대로 가져다 쓸 수 있고, 개발 속도와 안정성이 동시에 확보됩니다.
반대로 학원이나 인강에서 가르치는 내용은 왜 이렇게 단순할까요? 그건 입문자를 고려하기 때문입니다. 객체지향, 디자인 패턴, 비동기 처리, 이벤트 기반 시스템까지 한 번에 알려주면 대부분 포기해버립니다. 그래서 교육 과정에서는 “버튼 하나 눌러 캐릭터 점프” 같은 단순 예제를 보여주며 성취감을 주는 방식으로 진행되는 겁니다. 결과는 금방 나오지만, 그 구조로는 현업에서 살아남을 수 없습니다.
결국 경쟁력의 차이는 여기서 갈립니다. 교육 과정에서 배운 것은 어디까지나 출발점일 뿐이고, 현업에서는 그 위에 프레임워크적 사고를 얼마나 빠르게 습득하고 체득하느냐가 진짜 실력을 가르는 기준이 됩니다.
대규모 게임사가 기본 유니티 코드를 그대로 쓰지 않고 프레임워크를 래핑하는 이유는 명확합니다. 협업, 장기 유지보수, 재사용성. 이 세 가지가 없으면 대형 프로젝트는 유지될 수 없기 때문입니다.

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

현업에서 쓰이는 프레임워크는 수많은 모듈과 기능이 얽혀 있고, 그 양이 방대합니다. 이벤트, 데이터 관리, 다운로드, UI, 리소스 로딩, 메모리 풀, 태스크 시스템 등등… 이 모든 걸 처음부터 끝까지 한 번에 파악하려고 하면 머릿속에 체계가 잡히기 전에 공부의 늪에 빠지게 됩니다. 포트폴리오 완성이 우선입니다.
프레임워크는 “전체를 외워서 쓰는 것”이 아니라, “필요할 때 해당 기능 부분만 찾아보고 이해하면서 확장해나가는 것”이 정석입니다. 예를 들어 리소스를 불러와야 한다면 Data Provider 부분만, 다국어를 적용해야 한다면 Localization 모듈만 집중해서 보면 됩니다. 이렇게 실제 구현 과정에서 맞닥뜨린 문제를 계기로 부분적으로 이해하고, 점차 연결해서 큰 그림을 완성해야 합니다.
왜 이렇게 해야 할까요?
1.
양이 너무 많다
대규모 프레임워크는 사실상 “작은 엔진”과 비슷할 정도로 방대한 코드량을 가집니다. 전체를 한 번에 읽어내려가면 지쳐버리고, 결국 이해도 안 된 채 포기하게 됩니다.
2.
맥락이 필요하다
기능이 실제로 필요하지 않은 상황에서 문서와 코드를 읽으면, 단순히 “이런 게 있구나” 정도로만 스쳐 지나가고 기억에도 남지 않습니다. 반대로, “지금 UI에 다국어를 붙여야 하는데?”라는 필요성이 생긴 순간에 해당 모듈을 보면 훨씬 빠르게 이해됩니다.
3.
현업 방식과도 같다
실제 회사에서도 프레임워크를 입사 첫날부터 완전히 이해하는 건 불가능합니다. 선배 개발자들도 필요할 때 필요한 부분만 파고들며 점차 익숙해집니다. 중요한 건 전체 구조를 억지로 외우는 게 아니라, “어디에 무엇이 있는지, 필요한 순간에 어떻게 접근할지” 감을 잡는 것입니다.
유니티와 언리얼의 프레임워크 비교
Unity
Unity는 엔진 자체가 “가볍고 범용적인 엔진”으로 설계되어 있어서, 기본 제공 시스템(컴포넌트, 씬, 프리팹 등)은 단순합니다.
대신 프로젝트가 커질수록 프레임워크를 따로 설계해서 래핑해야 안정적인 유지보수가 가능해집니다.
Unreal Engine
언리얼은 애초에 대규모 게임 제작을 염두에 두고 만들어진 엔진입니다.
그래서 코어 레벨에서 이미 프레임워크적 아키텍처가 탑재되어 있습니다.
GameMode, GameInstance, Actor, Component 같은 체계적 클래스 계층
UObject, Garbage Collector, Reflection 시스템
유니티와 언리얼은 단순히 엔진이 다를 뿐만 아니라, 개발자가 성장하는 방식도 완전히 다릅니다.
유니티는 기본 엔진이 심플하기 때문에 큰 프로젝트를 만들려면 반드시 프레임워크를 직접 구현하고 래핑해야 합니다. 데이터 로딩, 이벤트 큐, 다운로드 매니저, 상태 머신 같은 시스템들을 하나하나 직접 설계하면서, 개발자는 자연스럽게 구조를 짜는 힘을 키워갑니다.
반대로 언리얼은 이미 방대한 프레임워크를 내장하고 있습니다. GameMode, GameInstance, Actor, Component, Subsystem 같은 구조부터 시작해, 온라인 멀티플레이를 위한 리플리케이션, 대규모 전투를 위한 GAS, 리소스 최적화를 위한 Async Loading까지 다 갖춰져 있죠. 그래서 언리얼에서는 뭔가를 새로 만드는 것보다, 이미 있는 시스템을 해체하고 이해하며 자기 것으로 만드는 과정이 곧 경쟁력의 핵심이 됩니다.
즉, 유니티는 없는 것을 직접 만들며 성장하는 엔진이라면, 언리얼은 이미 있는 거대한 구조를 뜯어보고 소화하며 성장하는 엔진입니다.
유니티에서 경쟁력은 “프레임워크를 직접 설계할 수 있는 능력”이고, 언리얼에서 경쟁력은 “방대한 엔진 프레임워크를 깊게 이해하고 상황에 맞게 확장할 수 있는 능력”인 셈이죠.
결국 두 엔진 모두 개발자에게 요구하는 건 같습니다.
단순히 예제나 튜토리얼 수준에서 멈추는 게 아니라, 엔진의 깊은 구조를 얼마나 자기 것으로 만들 수 있느냐가 현업에서의 진짜 경쟁력입니다.
왜 학원이나 인강에서는 이런 프레임워크 중심의 개발 방식을 잘 가르치지 않을까요? 그 이유는 현실적인 제약에서 비롯됩니다.
첫 번째로, 러닝커브의 문제입니다. 프레임워크 구조에는 객체지향, 디자인 패턴, 비동기 처리, 이벤트 기반 설계 등 고급 개념이 얽혀 있습니다. 프로그래밍을 막 시작한 입문자에게 이런 구조를 곧바로 설명하면 대부분 이해하지 못하고 좌절해버립니다. 그래서 교육 과정에서는 “버튼을 누르면 캐릭터가 점프한다”, “리소스를 불러와서 화면에 띄운다”와 같이 눈에 보이는 단순하고 직관적인 예제를 통해 성취감을 주는 데 집중합니다.
두 번째로, 교육 목표의 차이가 있습니다. 학원이나 인강은 학생들에게 재미와 동기를 부여해야 하기 때문에, 바로 결과가 보이는 실습에 초점을 맞춥니다. 반면, 기업용 프레임워크는 즉각적인 성과보다는 장기적인 유지보수와 확장성을 고려한 구조에 방점을 둡니다. 즉, 목표가 다르기 때문에 교육 방향도 다르게 흘러갈 수밖에 없습니다.
세 번째는 취업과 프로젝트의 차이입니다. 학원과 인강의 주요 목적은 학생들이 포트폴리오를 만들어 취업에 성공하도록 돕는 것입니다. 따라서 “게임 한 편을 끝까지 완성해보는 경험”을 주는 게 핵심이지, 내부 구조의 확장성이나 재사용성을 깊게 다루기는 어렵습니다. 6개월 정도의 짧은 교육 과정으로는 담아낼 수 없는 영역이기 때문입니다.
마지막으로, 강사의 수준과 환경 차이도 있습니다. 실제로 수십만 라인에 달하는 대규모 프레임워크를 직접 설계하고 운영해본 경험을 가진 강사는 드뭅니다. 그래서 많은 교육 현장에서는 작은 예제와 기초 개념 위주의 수업을 진행하게 되고, 현업에서 쓰이는 복잡한 프레임워크 구조까지 전달하기에는 현실적인 한계가 있습니다.
그렇다면 이런 프로젝트 포트폴리오가 취업 준비생에게 얼마나 경쟁력이 있을까요?
결론부터 말하자면, 학원이나 인강에서 만든 포트폴리오는 어디까지나 입문용일 뿐입니다. 기본적인 툴 사용법과 단순한 게임 완성 경험을 보여줄 수는 있지만, 그것만으로는 현업에서 바로 필요한 역량을 증명하기는 어렵습니다.
실제 경쟁력은 그 이후에 달려 있습니다. 즉, 단순한 예제 수준을 넘어, 현업에서 사용되는 프레임워크와 패턴을 얼마나 빨리 이해하고 흡수할 수 있느냐가 핵심입니다. 기업은 신입에게도 곧바로 실무에 투입될 수 있는 ‘적응력’을 기대하기 때문입니다.
비유하자면, 학원 교육은 자전거에 보조바퀴를 달고 가르치는 단계에 가깝습니다. 안정적으로 기본기를 익히고 넘어지지 않게 해주는 거죠. 하지만 현업은 자동차를 정비하고 직접 운전해야 하는 단계입니다. 규모도 크고, 유지보수도 길고, 팀 협업도 복잡합니다. 이 간극을 얼마나 빠르게 메우느냐가 결국 취업 경쟁력으로 이어집니다.
결국 정리하자면, 대규모 게임 회사는 프레임워크 기반 설계 없이는 프로젝트를 유지할 수 없습니다. 수많은 인원이 협업하고 장기간 서비스를 이어가려면, 코드의 일관성과 재사용성이 반드시 필요하기 때문입니다.
반면, 학원이나 인강에서는 입문자를 배려해 단순한 구조로 가르칠 수밖에 없습니다. 복잡한 패턴과 아키텍처를 그대로 들이밀면 초반에 학습 난이도가 너무 높아 학습자가 금세 포기하기 때문이죠. 그래서 교육 과정에서는 눈에 보이는 결과물을 빠르게 만들며 성취감을 주는 방식이 주를 이룹니다.
그렇다면 진짜 경쟁력은 어디에서 나오느냐? 바로 이런 기초 위에 현업 수준의 프레임워크 설계 능력을 얼마나 빠르게 쌓아 올리느냐에 달려 있습니다. 즉, 단순히 “작동하는 게임”을 만드는 것에서 멈추지 않고, 실제 회사에서 쓰이는 구조와 방식을 이해하고 자기 프로젝트에 녹여낼 수 있어야 진정한 실무 경쟁력이 생기는 것입니다.