모바일 게임 쪽 이야기는 가끔 콘솔이나 PC 개발자에게는 덜 화려하게 들립니다. 그런데 Unity가 2026년 6월 5일 공개한 Building Westeros for mobile in Game of Thrones: Dragonfire를 읽어보면, 오히려 지금 게임 개발 현장에서 가장 현실적인 문제들이 그대로 드러납니다. 좋은 비주얼을 넣는 일보다 먼저, 플레이어가 기다리지 않게 만들고 메모리 때문에 죽지 않게 만들고 패치가 과하게 무거워지지 않게 관리하는 일이 얼마나 중요한지 다시 보여주는 사례였습니다.
특히 이 글은 단순한 홍보성 성공담이라기보다, 로딩 병목과 번들 구조, 메모리 사용, 비동기 로드, 패치 파이프라인을 어떻게 다뤘는지 꽤 솔직하게 풀어냈다는 점에서 실무 참고 가치가 높습니다.
무엇이 공개됐나
이번 글에서 Unity는 Warner Bros. Games Boston 팀이 Game of Thrones: Dragonfire를 모바일에서 운영하기 위해 어떤 최적화 방식을 썼는지 구체적으로 소개했습니다. 공개일은 2026년 6월 5일이고, 형식은 Unity 엔진 기술 홍보보다는 실제 개발팀 인터뷰에 가깝습니다.
핵심 포인트는 명확합니다. 첫째, 로딩 각 단계를 커스텀 프로파일링 이벤트로 쪼개고 CSV, Chrome Trace Events, OpenTelemetry traces로 병목을 시각화했습니다. 둘째, Unity Profiler CPU 모듈과 Profile Analyzer, Rendering 모듈, RenderDoc, Memory Profiler를 조합해 로딩과 런타임 문제를 따로 파고들었습니다. 셋째, 2000×4000 규모 맵 데이터를 한 번에 들고 있지 않고 플레이어 주변만 로드하는 방식으로 메모리와 로딩 시간을 줄였습니다.
이건 그냥 “Unity 툴이 좋다”는 이야기가 아닙니다. 실제 서비스 게임에서 어떤 순서로 병목을 잡아야 하는지, 그리고 어느 정도까지 툴 체인을 체계적으로 써야 하는지 보여주는 운영형 사례라고 보는 게 더 정확합니다.
왜 게임 개발팀 전체에 의미가 큰가
이 사례가 중요한 이유는 모바일 프로젝트만의 이야기가 아니기 때문입니다. PC나 콘솔 프로젝트도 결국은 같은 문제를 겪습니다. 처음 플레이 진입 속도, 복귀 유저의 상태 복원, 스트리밍 가능한 데이터와 선탑재 데이터의 경계, 메모리 스파이크, 그리고 패치 크기 증가는 플랫폼만 바뀔 뿐 늘 반복되는 문제입니다.
Unity 글에서 특히 눈에 들어온 부분은 “플레이어가 지금 당장 필요한 것만 먼저 로드한다”는 원칙입니다. 이건 엔진 불문 실무 원칙에 가깝습니다. 에셋을 많이 만든다고 좋은 경험이 생기는 게 아니라, 적절한 타이밍에 필요한 것만 보여줘야 경험이 부드러워집니다. 개발자 입장에서는 로딩 시간을 줄이는 문제고, 플레이어 입장에서는 첫 인상이 좋아지는 문제입니다.
또 하나는 팀 간 언어가 맞아야 한다는 점입니다. 프로그래머만 프로파일러를 보고 끝나는 일이 아니라, 어떤 바이옴 에셋이 공유 번들로 빠져야 하는지, 어떤 머티리얼이나 텍스처가 중복 로드되는지, 어떤 VFX가 초반 진입 구간에서 꼭 필요한지까지 아트와 테크 아트, 클라이언트 개발이 같이 정리해야 합니다.
테크 아트와 VFX 관점에서 특히 눈여겨볼 부분
이 글은 렌더링 기법 발표는 아니지만, 테크 아트 관점에서는 꽤 직접적입니다. Memory Profiler로 예상 밖의 에셋 로드 시점을 잡고, 하나의 텍스처 때문에 큰 번들이 통째로 메모리에 올라오는 상황을 추적했다는 대목은 머티리얼과 VFX 에셋 관리에도 그대로 연결됩니다.
Niagara 같은 시스템을 다루는 Unreal 쪽이든, Unity 파티클/셰이더 그래프를 다루는 팀이든 문제 구조는 비슷합니다. 효과 하나를 위해 너무 많은 텍스처 의존성이 끌려오면 그건 보기 좋은 연출 이전에 로딩 비용 문제로 바뀝니다. 결국 멋진 연출은 프레임과 메모리, 번들 구조 안에서 살아남아야 실제 제품이 됩니다.
개인적으로는 “아트 품질을 지키는 최적화”라는 표현보다 “제품을 살아 있게 만드는 구조 정리”에 더 가깝게 느껴졌습니다. 플레이어가 초반 로딩에서 이탈하면, 그 뒤의 셰이더 품질이나 연출 완성도는 보여줄 기회조차 없기 때문입니다.
실무에 바로 가져갈 만한 체크포인트
이 사례에서 바로 가져갈 만한 건 거창한 기술보다 운영 습관입니다. 로딩 과정을 단계별 이벤트로 쪼개 기록하고, 병렬 구간을 시각화하고, 큰 맵이나 큰 번들을 한 번에 먹지 않게 구조를 바꾸는 접근은 규모가 작은 팀에도 적용할 수 있습니다.
특히 다음 네 가지는 바로 체크해볼 만합니다. 첫째, 첫 실행 경험에서 반드시 필요한 데이터와 나중에 받아도 되는 데이터를 분리했는지. 둘째, 에셋 번들이 사용 맥락 기준으로 묶여 있는지. 셋째, 공유 텍스처나 공용 메시에 의해 불필요한 중복 로드가 발생하는지. 넷째, 빌드 파이프라인에서 번들 크기 급증을 자동으로 경고하는 장치가 있는지입니다.
Unity 글에서는 번들 크기가 갑자기 5MB 이상 커져 스토어 제출 제한에 부딪힌 사례도 언급됐습니다. 이건 학생 포트폴리오나 인디 팀에게도 좋은 교육 포인트입니다. 최적화는 출시 직전에만 하는 일이 아니라, 제작 구조를 설계할 때부터 시작해야 나중에 덜 아픕니다.
이 사례에서 챙길 것
이 사례가 보여주는 건 신기능이 아니라, 잘 만든 게임을 실제 서비스에서 버티게 하는 최적화 감각입니다. 모바일 팀뿐 아니라 게임 클라이언트 개발자, 테크 아티스트, 디자이너, VFX 아티스트 모두에게 “보이는 퀄리티” 못지않게 “들어가는 구조”가 중요하다는 점을 다시 상기시켜 줍니다.
화려한 신기능 소식보다 이런 운영 사례가 더 오래 남을 때가 많습니다. 특히 포트폴리오를 준비하거나 팀 파이프라인을 정리하는 입장이라면, 이번 Unity 글은 한 번 읽고 끝낼 자료가 아니라 체크리스트로 바꿔둘 만한 내용입니다.
참고 출처
- Unity Blog,
Building Westeros for mobile in Game of Thrones: Dragonfire, 2026-06-05: https://unity.com/blog/building-westeros-for-mobile-in-game-of-thrones-dragonfire