PC 게임을 모바일로 옮긴다는 말은 얼핏 단순해 보입니다. 해상도를 낮추고, 버튼을 크게 만들고, 성능 옵션을 조금 줄이면 될 것 같기도 합니다. 그런데 실제 제작에서는 그렇게 깔끔하게 끝나지 않습니다. PC에서 괜찮던 UI가 손가락 입력에서는 답답할 수 있고, 데스크톱에서는 별문제 없던 텍스처와 아틀라스가 모바일 다운로드 크기와 메모리 압박으로 돌아올 수 있습니다. 화면이 작아졌다고 작업도 작아지는 것이 아니라, 오히려 제작 판단은 더 촘촘해집니다.
Unity가 2026년 7월 2일 공개한 Adapting Causa: Into the Dusk for mobile with Unity 6.3는 이런 지점을 짧지만 꽤 실무적으로 보여주는 사례입니다. Niebla Games는 PC로 먼저 출시된 전략 카드 게임 Causa: Into the Dusk를 Google Play Pass로 가져가기 위해 Unity 2019 프로젝트를 Unity 6.3으로 올리고, Built-in Render Pipeline에서 Universal Render Pipeline, 즉 URP로 전환하고, Device Simulator로 다양한 모바일 화면을 확인하고, Unity Profiler와 Sprite Atlas System, Atlas Analyzer로 병목과 빌드 크기를 정리했다고 설명했습니다.
이 글은 Unity 사례를 그대로 요약하는 뉴스가 아니라, PC 기반 게임을 모바일로 옮길 때 팀이 어떤 순서로 판단해야 하는지 보는 제작 사례 분석입니다. Unity 사용자뿐 아니라 Unreal, Godot, 자체 엔진을 쓰는 팀도 비슷한 질문을 만납니다. 어느 시점에 엔진 버전을 올릴 것인가. 렌더 파이프라인을 바꿀 가치가 있는가. UI는 단순히 작아진 화면에 맞추는 문제인가, 아니면 플레이 감각을 다시 설계하는 문제인가. 빌드 크기와 성능을 줄이면서도 게임의 분위기와 정보 전달을 어떻게 지킬 것인가.
이번 사례가 흥미로운 이유는 거대한 오픈월드나 최신 AAA 그래픽이 아니라, 카드 게임이라는 비교적 정적인 장르에서도 모바일 이식이 만만하지 않다는 점입니다. UI-heavy 게임이라면 오히려 더 섬세합니다. 카드를 읽고, 선택하고, 덱과 상태를 비교하고, 턴 흐름을 따라가야 하는 게임에서 UI는 장식이 아니라 플레이 그 자체입니다. 그래서 모바일 이식은 기술 이전이 아니라, 플레이어가 게임을 어떻게 들고, 보고, 이해하고, 오래 머무는지를 다시 확인하는 작업입니다.
1. 이식의 출발점은 플랫폼이 아니라 플레이 루프입니다
Niebla Games가 Unity 인터뷰에서 먼저 언급한 것은 단순한 포팅 욕심이 아니었습니다. Causa: Into the Dusk에는 강한 싱글 플레이어 draft campaign mode가 있었고, 이 모드의 engagement와 retention이 좋았기 때문에 Google Play Pass 같은 subscription model에 어울린다고 판단했다는 흐름이 나옵니다. 기술 이전보다 먼저 콘텐츠와 서비스 모델의 적합성을 본 것입니다.
이 순서가 중요합니다. 모바일 이식은 “우리 게임을 다른 플랫폼에도 내보자”로 시작하면 금방 흔들립니다. 모바일 플레이어가 언제 이 게임을 켜는지, 한 세션이 얼마나 길어야 하는지, 화면 안에 어떤 정보가 반드시 보여야 하는지, 과금 또는 구독 모델과 게임 구조가 맞는지 먼저 봐야 합니다. PC에서 전략 카드 게임을 즐기는 플레이어는 긴 시간 앉아서 덱과 텍스트를 비교할 수 있지만, 모바일에서는 같은 장면도 훨씬 더 빠른 판단과 명확한 터치 흐름을 요구합니다.
그래서 이 사례를 제작 관점에서 보면 첫 질문은 “Unity 6.3으로 올렸나”가 아닙니다. “왜 이 게임이 모바일 구독 환경에서 다시 읽힐 수 있다고 봤나”입니다. 팀이 이 질문을 먼저 잡으면 기술 선택이 더 선명해집니다. UI를 단순 축소할지, 모바일-first experience처럼 다시 다듬을지, 성능 목표를 어느 기기군까지 잡을지, 다운로드 크기를 얼마나 민감하게 볼지 결정할 수 있습니다.
인디 팀이나 작은 스튜디오라면 이 판단이 더 중요합니다. 플랫폼 확장은 수익 기회이지만, 동시에 유지보수 표면을 늘립니다. PC 버전 하나를 고치는 것과 PC, Android, 여러 화면비, 여러 성능 등급을 함께 관리하는 것은 전혀 다릅니다. 이식이 성공하려면 새 플랫폼이 단순한 추가 매장이 아니라, 게임의 핵심 루프와 어울리는 새로운 소비 방식인지 확인해야 합니다.
디자이너에게도 같은 질문이 돌아옵니다. Causa 같은 전략 카드 게임은 화면에 많은 정보를 놓는 장르입니다. 카드 텍스트, 비용, 상태, 턴 진행, 선택 가능한 액션, 상대의 의도, 캠페인 진행이 모두 UI에 묶입니다. PC에서는 커서 hover, 넓은 화면, 키보드 단축키, 긴 읽기 시간이 도움이 됩니다. 모바일에서는 손가락이 화면을 가리고, 짧은 세션에서 빠르게 정보를 읽어야 하며, 버튼 하나의 위치가 실수와 피로를 만듭니다. 그러니 모바일 이식은 입력 장치 변경이 아니라 정보 구조 변경입니다.
이 관점은 Unreal이나 Godot 프로젝트에도 그대로 적용됩니다. 엔진은 다르더라도 PC UI를 모바일에 맞출 때 가장 먼저 봐야 하는 것은 해상도 대응이 아니라 플레이 루프입니다. 플레이어가 어떤 결정을 가장 자주 하는지, 그 결정에 필요한 정보가 어디에 있어야 하는지, 손가락 입력이 어떤 정보를 가리는지, 세션 길이가 어떻게 바뀌는지 봐야 합니다. 기술 작업은 그 다음입니다.
이 단계에서 팀이 해볼 만한 간단한 작업은 핵심 5분 플레이를 다시 쓰는 것입니다. PC 버전에서 플레이어가 처음 5분 동안 무엇을 읽고, 무엇을 누르고, 어디서 망설이고, 어떤 보상을 기대하는지 적습니다. 그 다음 같은 5분을 모바일 플레이어 기준으로 다시 씁니다. 첫 카드 선택까지 몇 번 탭하는지, 카드 설명을 읽는 동안 화면의 다른 정보가 사라지는지, 전투 결과를 확인한 뒤 다음 선택으로 가는 손의 이동이 자연스러운지 봅니다. 이 문서가 있으면 이후 엔진 업그레이드, URP 전환, UI 재배치, 성능 예산 결정이 모두 같은 목적을 바라보게 됩니다.
작은 팀일수록 이 문서가 더 필요합니다. 구성원이 적으면 디자이너, UI 아티스트, 프로그래머, QA 역할이 한 사람에게 겹치기 쉽습니다. 그러면 “모바일에서 편하게 만들자” 같은 추상적인 말만 남고, 실제 구현에서는 각자 다른 기준으로 판단하게 됩니다. 누군가는 텍스트 가독성을 우선하고, 누군가는 카드 일러스트 크기를 우선하고, 누군가는 프레임을 우선합니다. 모두 맞는 말이지만 우선순위가 없으면 빌드가 흔들립니다. 모바일 이식 초반에는 무엇을 지킬 것인지, 무엇은 줄여도 되는지, 무엇은 새 플랫폼에 맞춰 다시 설계할 것인지 합의해야 합니다.
2. Unity 2019에서 Unity 6.3으로 올린 결정은 도구 접근권을 사는 선택입니다
Unity 인터뷰에서 Niebla Games는 모바일 대응을 생각하며 첫 번째 기술 과제로 Unity 2019에서 Unity 6.3으로의 migration을 언급했습니다. 오래된 프로젝트를 최신 LTS 계열로 올리는 일은 보통 달갑지 않습니다. API 변화, 패키지 호환성, 플러그인 문제, 에셋 import 차이, 렌더링 결과 변화, 빌드 설정 변경이 따라옵니다. 기존 PC 버전이 안정적으로 돌아가고 있었다면 팀 내부에서는 “굳이 지금 올려야 하나”라는 말이 나올 수 있습니다.
그럼에도 이 결정이 의미 있는 이유는 모바일 이식에서 최신 도구의 접근권이 중요하기 때문입니다. Unity 6.3 문서와 공식 소개 흐름을 보면, Unity 6.3은 여러 엔진 개선과 패키지 업데이트를 포함하고, Sprite Atlas Analyzer 같은 2D 제작/분석 도구가 강조됩니다. Unity 블로그의 Causa 사례도 최신 Profiler, Device Simulator, Sprite Atlas System, Atlas Analyzer를 모바일 최적화에 활용했다고 설명합니다. 즉 엔진 업그레이드는 단순 버전 숫자 변경이 아니라, 모바일 이식에 필요한 관찰 도구와 정리 도구를 얻는 과정이 됩니다.
하지만 여기에도 리스크가 있습니다. 프로젝트 업그레이드는 성능을 자동으로 좋게 만들지 않습니다. 오히려 기존 화면이 달라지고, 오래된 셰이더나 플러그인이 깨지고, 모바일 빌드에서 새로운 문제가 생길 수 있습니다. 그래서 이 단계는 “최신이라서 좋다”가 아니라 “이번 이식에 필요한 도구가 최신 버전에 있고, 그 도구가 업그레이드 비용을 이긴다”는 판단이어야 합니다.
실무에서는 업그레이드 계획을 몇 개의 체크포인트로 쪼개는 편이 안전합니다. 먼저 원본 PC 프로젝트의 기준 빌드를 고정합니다. 그 다음 엔진 버전만 올린 빌드를 만들고, 플레이 루프와 주요 장면이 유지되는지 확인합니다. 그 뒤 렌더 파이프라인 전환, 모바일 UI 조정, 아틀라스 정리, 프로파일링을 순서대로 붙입니다. 모든 것을 한 번에 바꾸면 문제가 생겼을 때 원인을 알기 어렵습니다.
팀 단위로 보면 이 결정은 개발자만의 일이 아닙니다. 아티스트는 렌더링 톤과 UI 결과가 달라지는지 봐야 하고, 디자이너는 입력과 세션 흐름이 유지되는지 봐야 하며, QA는 기존 PC 버전과 모바일 전환 빌드의 차이를 정리해야 합니다. 업그레이드가 끝났다는 기준도 “빌드가 성공했다”가 아니라 “게임의 핵심 루프가 새 버전에서 재현되고, 새 도구를 쓸 수 있는 상태가 됐다”여야 합니다.
포트폴리오 관점에서도 이 지점은 좋은 소재입니다. 많은 사람들이 새 기능 데모는 보여주지만, 오래된 프로젝트를 최신 버전으로 안전하게 옮기는 과정은 잘 기록하지 않습니다. 실제 스튜디오에서는 이 능력이 매우 중요합니다. 어떤 플러그인이 문제였고, 어떤 렌더 결과가 바뀌었고, 어떤 테스트 장면으로 회귀를 잡았는지 기록하면 단순한 “Unity 사용 가능”보다 훨씬 실무적인 포트폴리오가 됩니다.
업그레이드 기록에는 성공한 일만 쓰지 않는 편이 좋습니다. 어떤 패키지를 올렸더니 특정 UI 애니메이션이 달라졌는지, 어떤 셰이더가 URP 변환 후 색이 바뀌었는지, 어떤 에셋 import 설정이 다시 저장되었는지 같은 작은 문제들이 나중에는 큰 힌트가 됩니다. 특히 모바일 이식에서는 “왜 이 설정을 이렇게 바꿨는가”가 중요합니다. 프로젝트를 이어받은 사람이 이 기록을 보면 성능을 위해 의도적으로 낮춘 설정인지, 임시로 우회한 설정인지, 단순 실수인지 구분할 수 있습니다.
또 하나 중요한 것은 업그레이드와 기능 추가를 분리하는 태도입니다. 새 Unity 버전으로 올리는 김에 UI를 다시 만들고, 렌더 파이프라인도 바꾸고, 아틀라스도 정리하고, 모바일 입력까지 동시에 붙이면 진행 속도는 빨라 보일 수 있습니다. 하지만 회귀가 생겼을 때 원인 추적이 매우 어려워집니다. 좋은 포팅 일정은 보기보다 지루합니다. 엔진 업그레이드 빌드, 렌더 전환 빌드, UI 대응 빌드, 성능 정리 빌드가 따로 있어야 합니다. 지루한 단계 구분이 나중의 디버깅 시간을 줄입니다.
3. Built-in에서 URP로 가는 결정은 프레임뿐 아니라 제작 규칙을 바꾸는 일입니다
Causa 팀은 Built-in Render Pipeline에서 URP로 전환한 이유로 더 높은 frame rate와 더 consistent frame rate를 언급했습니다. UI-heavy 카드 게임에서 이 결정은 꽤 흥미롭습니다. 보통 URP 전환은 3D 그래픽 품질, 조명, 모바일 렌더링 최적화와 함께 이야기되지만, 카드 게임에서도 안정적인 프레임은 중요합니다. 카드 이동, 선택 피드백, 전환 애니메이션, 입력 반응이 흔들리면 플레이어는 게임이 둔하다고 느낍니다.
렌더 파이프라인 전환은 단순한 성능 옵션 변경이 아닙니다. 머티리얼, 셰이더, 조명, 후처리, UI 렌더링, 카메라 stack, quality setting, 플랫폼별 그래픽 설정이 모두 영향을 받을 수 있습니다. 특히 오래된 Unity 2019 프로젝트라면 Built-in 기준으로 만들어진 셰이더와 머티리얼, UI 효과, 2D/3D 혼합 방식이 있을 수 있습니다. URP로 옮기면 성능의 가능성은 열리지만, 팀은 새 제작 규칙을 받아들여야 합니다.
여기서 중요한 것은 목표를 숫자로만 잡지 않는 것입니다. “60fps”라는 목표는 필요하지만, 카드 게임에서는 프레임의 일관성도 플레이 감각에 큰 영향을 줍니다. 카드가 손가락을 따라 움직일 때 미세한 끊김이 생기면 플레이어는 조작이 불안하다고 느낍니다. 메뉴 전환과 카드 확대가 부드럽지 않으면 콘텐츠가 가벼워 보여도 완성도가 낮게 느껴질 수 있습니다. 모바일에서 프레임은 액션 게임만의 문제가 아닙니다.
VFX와 technical art 관점에서는 UI 효과의 비용을 다시 봐야 합니다. 반투명 레이어, 블러, 글로우, 카드 그림자, particle overlay, animated background, screen-space effect는 카드 게임 분위기를 살리는 데 좋지만, 모바일에서는 overdraw와 fill-rate 문제가 될 수 있습니다. URP 전환은 이런 효과를 더 체계적으로 정리할 기회가 됩니다. 어떤 효과를 유지하고, 어떤 효과를 낮은 품질 옵션으로 분리하고, 어떤 효과를 아틀라스나 애니메이션으로 대체할지 판단해야 합니다.
이 과정에서 아티스트와 개발자가 같은 언어를 써야 합니다. “이 효과가 예쁘다”와 “이 효과가 비싸다” 사이에서 싸우는 것이 아니라, 플레이어가 실제로 체감하는 가치와 비용을 함께 봐야 합니다. 핵심 카드 선택 피드백이라면 비용을 남길 가치가 있습니다. 배경에서 거의 눈에 띄지 않는 장식 효과라면 줄일 수 있습니다. 렌더 파이프라인 전환의 목표는 화면을 무조건 단순하게 만드는 것이 아니라, 중요한 표현에 예산을 다시 배치하는 것입니다.
이때 team-level decision으로 정리하면 좋은 항목이 있습니다. 첫째, 프레임 목표를 평균이 아니라 하한 기준으로 잡습니다. 평균 60fps보다 중요한 것은 입력 직후와 카드 전환, 보상 연출, 화면 전환에서 갑자기 튀는 hitch를 줄이는 일입니다. 둘째, 품질 단계를 실제 플레이 맥락으로 나눕니다. 전투 중 정보 전달에 영향을 주는 효과는 낮은 옵션에서도 남기고, 배경의 장식 효과는 기기 등급에 따라 줄입니다. 셋째, URP 전환 후 색감과 가독성 QA를 따로 잡습니다. 파이프라인이 바뀌면 조명과 후처리만이 아니라 카드 일러스트, 아이콘 대비, 텍스트 가장자리까지 달라질 수 있습니다.
렌더 파이프라인을 바꾼 뒤에는 “예전과 똑같이 보이는가”만 확인하면 부족합니다. 모바일에서는 더 작은 화면과 더 다양한 밝기 환경에서 보입니다. PC에서는 멋있던 어두운 배경이 모바일 야외 환경에서는 읽기 어려울 수 있고, 미세한 glow가 작은 화면에서는 텍스트 주변을 흐리게 만들 수 있습니다. 그래서 비교 기준은 원본 재현과 모바일 가독성 두 가지여야 합니다. 원본 감성을 지키되, 모바일 플레이어가 실제로 정보를 더 빨리 읽을 수 있어야 합니다.
4. Device Simulator는 화면비 테스트 도구가 아니라 손의 피로를 미리 보는 도구입니다
Unity 공식 Device Simulator 문서는 이 기능이 모바일 디바이스에서 애플리케이션이 어떻게 보이고 동작하는지 시뮬레이션하는 Editor 기능이라고 설명합니다. Causa 팀도 다양한 device range에 맞춰 UI를 조정하기 위해 Device Simulator를 사용했다고 말했습니다. 여기서 많은 팀이 Device Simulator를 단순 화면비 확인 도구로만 씁니다. 물론 그것도 중요합니다. 하지만 모바일 UI에서 더 중요한 것은 손의 위치와 반복 조작의 피로입니다.
PC UI를 모바일로 옮길 때 흔한 실수는 모든 정보를 그대로 살리려는 것입니다. 카드 게임은 정보가 많기 때문에 더 위험합니다. 텍스트를 작게 만들면 한 화면에 많이 들어가지만, 읽기 피로가 커집니다. 버튼을 작게 만들면 카드 영역을 살릴 수 있지만, 오입력이 늘어납니다. 정보를 접으면 화면은 깔끔해지지만, 플레이어가 매 턴 더 많이 탭해야 합니다. 모바일 UI는 공간 절약이 아니라 행동 비용 설계입니다.
Device Simulator의 가치는 빠른 반복에 있습니다. 실제 기기 테스트를 대체하지는 못하지만, 매번 빌드하지 않고도 safe area, aspect ratio, orientation, 대략적인 화면 구성을 빠르게 볼 수 있습니다. 팀은 여기서 몇 가지 질문을 반복해야 합니다. 핵심 버튼이 엄지손가락이 닿기 좋은 곳에 있는가. 카드 확대와 닫기 동작이 자연스러운가. 튜토리얼 문장이 화면을 덮지 않는가. 전투나 턴 진행 정보가 손가락에 가리지 않는가. 긴 카드 텍스트를 읽을 때 다른 중요 정보가 사라지지 않는가.
디자이너는 이 단계에서 플레이어의 행동 루프를 다시 그려야 합니다. 카드 선택, 정보 확인, 확정, 취소, 덱 확인, 보상 선택, 캠페인 이동 같은 반복 행동이 모바일에서 몇 번의 탭으로 끝나는지 봐야 합니다. 개발자는 입력 처리와 UI scaling, safe area, orientation 대응을 챙겨야 합니다. 아티스트는 카드 이미지와 아이콘이 작은 화면에서도 의도를 유지하는지 확인해야 합니다. VFX 아티스트는 터치 피드백과 선택 이펙트가 정보를 가리지 않는지 봐야 합니다.
실제 기기 테스트는 그 다음입니다. Simulator에서 좋아 보인 UI도 저가형 기기의 밝기, 색감, 터치 지연, 손 크기, 발열, 네트워크 상황에서는 다르게 느껴질 수 있습니다. 그래서 Simulator는 결론을 내리는 도구가 아니라, 실제 기기 테스트에 들어가기 전 문제를 줄이는 도구로 보는 편이 맞습니다. 빠르게 넓은 화면비를 훑고, 위험한 레이아웃을 걸러내고, 실제 기기에서는 더 깊은 플레이 감각을 확인하는 순서가 좋습니다.
모바일 UI QA는 스크린샷 비교만으로 끝나면 안 됩니다. 손가락이 버튼을 누르는 동안 어떤 정보가 가려지는지, 한 손 플레이와 두 손 플레이가 모두 가능한지, 긴 문장을 읽을 때 다음 행동이 어디에 있는지, 실수로 취소를 눌렀을 때 복구가 쉬운지 직접 봐야 합니다. 카드 게임에서는 특히 선택 후보와 확정 버튼의 거리가 중요합니다. 너무 가까우면 실수가 늘고, 너무 멀면 매 턴 손이 많이 움직입니다. 이 작은 피로가 긴 캠페인에서는 retention에 영향을 줄 수 있습니다.
디자인 문서에는 읽기, 선택, 확정, 취소, 비교, 보상 확인 같은 동사를 기준으로 UI를 정리하는 것이 좋습니다. 화면 요소 이름만 나열하면 실제 플레이 행동이 보이지 않습니다. 동사 기준으로 보면 어떤 행동이 반복되고, 어떤 행동이 피곤하고, 어떤 행동에 시각 피드백이 부족한지 빨리 드러납니다. Causa처럼 전략 카드와 캠페인 흐름이 결합된 게임에서는 이 동사 목록이 모바일 UX의 뼈대가 됩니다.
5. Profiler와 Atlas Analyzer는 감으로 줄이던 최적화를 증거 중심으로 바꿉니다
Causa 팀은 모바일 이식에서 가장 어려웠던 부분으로 optimization을 언급했고, Unity 6.3의 최신 Profiler로 bottleneck과 improvement area를 찾았다고 했습니다. Unity Profiler 문서는 애플리케이션의 성능 정보를 확인하고, 의도한 release platform에서 어떻게 동작하는지 보기 위해 네트워크상의 기기나 연결된 기기에 붙일 수 있다고 설명합니다. 이 지점은 모바일 이식에서 매우 중요합니다. Editor에서 빠른 것과 실제 모바일 기기에서 빠른 것은 다릅니다.
게임 팀이 모바일 최적화를 할 때 흔히 빠지는 함정은 먼저 줄이고 보는 것입니다. 텍스처 해상도를 낮추고, 애니메이션을 줄이고, 효과를 끄고, 폰트를 압축하고, 배경을 단순화합니다. 그러면 빌드는 가벼워질 수 있지만, 정작 플레이어가 좋아하던 감각을 잃을 수도 있습니다. Profiler는 이 과정을 조금 더 침착하게 만듭니다. CPU가 문제인지, GPU가 문제인지, UI rebuild가 문제인지, asset loading이 문제인지, GC allocation이 문제인지, 렌더링 overdraw가 문제인지 먼저 확인할 수 있습니다.
Sprite Atlas와 Atlas Analyzer도 같은 흐름입니다. Unity의 Sprite Atlas 문서는 여러 텍스처를 하나의 atlas texture로 묶어 draw call을 줄일 수 있다고 설명합니다. 2D Tooling의 Sprite Atlas Analyzer 문서는 프로젝트의 sprite atlas 정보를 분석해 성능 문제 가능성을 찾는 도구로 설명됩니다. Causa 팀도 예전에는 Sprite Atlas를 수동으로 만들었지만, Unity Sprite Atlas System과 Atlas Analyzer를 사용해 asset을 더 효율적으로 정리하고 build size를 줄이는 데 도움을 받았다고 했습니다.
모바일에서 빌드 크기는 단순한 저장 공간 문제가 아닙니다. 다운로드 진입 장벽이고, 첫 실행 기대감이고, 업데이트 이탈률입니다. 특히 구독 서비스나 Play Pass 같은 환경에서는 플레이어가 여러 게임을 가볍게 시도할 수 있습니다. 이때 다운로드가 무겁고 첫 실행이 느리면 좋은 게임도 시작 전에 손해를 봅니다. 텍스처와 아틀라스 정리는 시각 품질을 포기하는 일이 아니라, 플레이어가 게임에 들어오기 전의 마찰을 줄이는 일입니다.
아트팀 입장에서는 Atlas Analyzer가 작업 방식을 바꿀 수 있습니다. 예전에는 “이 스프라이트는 어디에 들어갔는지”, “중복 텍스처가 있는지”, “아틀라스 공간이 얼마나 낭비되는지”를 감으로 보거나 수작업으로 확인했다면, 이제는 보고서와 지표로 이야기를 시작할 수 있습니다. 이렇게 되면 아티스트가 방어적으로 느끼지 않아도 됩니다. “퀄리티를 낮추자”가 아니라 “낭비되는 공간을 찾아서 같은 퀄리티를 더 가볍게 싣자”에 가까워지기 때문입니다.
개발자에게도 이 흐름은 중요합니다. Sprite Atlas를 정리하면 draw call이나 batching에 영향을 줄 수 있지만, asset bundle, addressable 흐름, memory residency, loading timing과도 엮일 수 있습니다. 잘못 묶으면 필요 없는 텍스처까지 같이 올라올 수 있고, 너무 잘게 나누면 관리 비용이 늘어납니다. 그래서 Analyzer는 답을 대신 내려주는 도구가 아니라, 팀이 아틀라스 전략을 논의할 때 보는 근거가 됩니다.
실무에서는 아틀라스 정리를 세 갈래로 나눠 보는 편이 좋습니다. 첫째는 자주 함께 쓰이는 UI와 카드 요소입니다. 같은 화면에서 반복적으로 등장한다면 한 묶음으로 관리할 가치가 있습니다. 둘째는 캠페인, 상점, 튜토리얼처럼 특정 구간에서만 쓰이는 요소입니다. 이런 리소스는 항상 메모리에 남길 필요가 없을 수 있습니다. 셋째는 이벤트성 또는 낮은 빈도의 장식 이미지입니다. 이 요소들은 다운로드 크기와 업데이트 크기 측면에서 따로 관리하는 편이 나을 때가 있습니다.
아티스트가 이 기준을 알고 있으면 작업 방식도 달라집니다. 무조건 큰 이미지를 작게 압축하라는 이야기가 아니라, 어떤 리소스가 플레이 루프의 중심이고 어떤 리소스가 구간성 리소스인지 구분하게 됩니다. UI 아이콘 하나를 바꾸는 일도 빌드 크기와 메모리, 업데이트 패치 크기에 연결될 수 있습니다. 모바일에서는 이런 작은 선택이 누적됩니다. 그래서 Atlas Analyzer 같은 도구는 최적화 담당자만 쓰는 창이 아니라, 아트 리드와 UI 디자이너가 같이 볼 수 있는 대화 자료가 되어야 합니다.
Profiler도 마찬가지입니다. CPU Usage, rendering, memory, UI rebuild, asset loading 같은 항목을 개발자만 보고 끝내면 팀 전체의 행동이 바뀌지 않습니다. 예를 들어 UI rebuild가 큰 문제라면 디자이너는 애니메이션과 레이아웃 변경 방식을 다시 봐야 하고, 아티스트는 동적 요소와 정적 요소를 분리해야 하며, 개발자는 canvas 구조나 batching을 조정해야 합니다. 숫자는 책임을 몰아가기 위한 자료가 아니라, 여러 파트가 같은 문제를 같은 이름으로 부르게 만드는 자료입니다.
6. 모바일 포팅에서 VFX와 시각 피드백은 줄이는 대상이 아니라 우선순위를 다시 매기는 대상입니다
카드 게임이라고 해서 VFX가 중요하지 않은 것은 아닙니다. 오히려 카드 선택, 공격, 방어, 보상, 상태 이상, 턴 전환, 캠페인 진행 같은 순간은 작은 시각 피드백이 플레이 감각을 만듭니다. 모바일에서는 화면이 작고 손가락이 정보를 가리기 때문에, 피드백이 더 선명해야 할 때도 있습니다. 문제는 그 피드백을 PC와 같은 방식으로 유지할 수 없다는 점입니다.
모바일 포팅에서 VFX 예산을 정할 때는 화려함보다 정보 우선순위를 봐야 합니다. 플레이어가 반드시 알아야 하는 피드백은 남겨야 합니다. 내가 선택한 카드, 사용할 수 있는 대상, 피해가 들어간 순간, 턴이 넘어간 순간, 보상이 확정된 순간 같은 신호입니다. 반대로 배경 분위기나 장식성 particle은 기기 성능에 따라 낮출 수 있습니다. 중요한 것은 모든 효과를 같은 칼로 자르지 않는 것입니다.
URP 전환과 Profiler, 아틀라스 정리가 함께 들어가면 이 작업을 더 잘할 수 있습니다. 예를 들어 카드 선택 피드백은 비용이 작더라도 선명하게 남기고, 배경 애니메이션은 해상도나 update rate를 낮추고, 큰 반투명 레이어는 줄이고, 반복되는 UI spark나 glow는 atlas 기반 애니메이션으로 바꿀 수 있습니다. Shader Graph나 VFX Graph를 쓰는 프로젝트라면 모바일용 variant를 따로 관리하는 것도 방법입니다. 핵심은 “모바일에서는 다 줄인다”가 아니라 “모바일에서는 무엇을 더 분명히 보여줘야 하는가”입니다.
디자이너와 아티스트가 함께 봐야 할 부분은 피드백의 타이밍입니다. PC에서는 마우스 hover가 많은 정보를 해결해줍니다. 모바일에서는 hover가 없습니다. 그래서 탭 전 preview, 길게 누르기, 카드 확대, 선택 후보 강조, 취소 제스처 같은 대체 흐름이 필요합니다. 여기에 들어가는 이펙트는 단순 장식이 아니라 입력 언어입니다. 이 언어가 약하면 플레이어는 실수했다고 느끼고, 너무 과하면 화면이 피곤해집니다.
Unreal이나 Godot 프로젝트도 같은 교훈을 얻을 수 있습니다. 엔진이 다르더라도 모바일 이식의 핵심은 시각 효과를 없애는 것이 아니라 피드백 계층을 재설계하는 것입니다. 어떤 신호는 UI로 보내고, 어떤 신호는 world effect로 남기고, 어떤 신호는 사운드와 햅틱으로 보완할지 정해야 합니다. 기술 최적화는 이 판단을 돕는 수단입니다.
여기서 플레이어 경험을 기준으로 효과를 세 등급으로 나눠볼 수 있습니다. 첫 번째는 반드시 남겨야 하는 정보 효과입니다. 선택 가능, 피해 발생, 보상 획득, 턴 전환, 실패 경고처럼 게임 규칙을 이해하게 만드는 효과입니다. 두 번째는 분위기를 강화하지만 없어도 규칙 이해에는 문제가 없는 표현 효과입니다. 배경 입자, 장식 glow, 카드 테두리의 세밀한 animation 같은 것입니다. 세 번째는 특정 고사양 기기에서만 남겨도 되는 프리미엄 효과입니다. 이 분류가 있으면 최적화 회의가 훨씬 덜 감정적으로 흘러갑니다.
모바일 VFX에서 또 하나 조심할 것은 작은 화면의 대비입니다. PC에서는 부드럽고 고급스러운 효과가 모바일에서는 흐릿한 얼룩처럼 보일 수 있습니다. 특히 반투명과 블러, bloom이 텍스트 주변에 붙으면 가독성이 나빠집니다. 반대로 너무 강한 효과는 카드 정보와 충돌합니다. 그래서 모바일 피드백은 짧고 선명하며, 정보와 겹치지 않아야 합니다. 이 원칙은 장르가 카드 게임이든, 퍼즐이든, RPG든 크게 다르지 않습니다.
7. 작은 팀이 이 사례에서 바로 가져갈 수 있는 제작 순서
이 사례를 실제 프로젝트에 적용하려면 순서를 정하는 것이 좋습니다. 첫 번째는 목적 확인입니다. 새 플랫폼에서 어떤 플레이 루프를 기대하는지, 구독 모델이나 모바일 마켓에서 어떤 세션 길이를 목표로 하는지, 기존 PC 콘텐츠 중 무엇이 모바일에서도 강점인지 정리합니다. 이 단계가 없으면 기술 작업이 방향을 잃습니다.
두 번째는 기준 빌드 고정입니다. 기존 PC 버전의 화면, 성능, 메모리, 빌드 크기, 핵심 UX를 기록합니다. 단순 스크린샷보다 짧은 플레이 영상과 프로파일 캡처가 좋습니다. 이 기준이 있어야 모바일 전환 후 무엇이 좋아졌고 무엇이 깨졌는지 비교할 수 있습니다.
세 번째는 엔진과 렌더 파이프라인의 실험 브랜치입니다. Unity라면 Unity 6.3 같은 목표 버전으로 올리고, URP 전환을 별도 단계로 나눕니다. Unreal이라면 엔진 버전과 모바일 renderer, scalability, input mode를 분리해 봅니다. Godot라면 렌더링 backend와 export preset, UI scaling을 별도 체크합니다. 중요한 것은 한 번에 모든 것을 바꾸지 않는 것입니다.
네 번째는 UI 행동 루프 테스트입니다. 화면비 대응, safe area, 터치 크기, 정보 계층, 카드 확대, 취소 동작, 긴 텍스트 읽기, 반복 탭 피로를 확인합니다. 이 단계에서는 Device Simulator 같은 빠른 도구로 넓게 보고, 실제 기기에서 깊게 보는 방식이 좋습니다.
다섯 번째는 성능과 빌드 크기 정리입니다. Profiler로 실제 기기 병목을 보고, Sprite Atlas와 Atlas Analyzer 같은 도구로 텍스처와 2D 에셋 낭비를 찾습니다. 여기서 아트 품질을 먼저 희생하지 말고, 낭비와 중복을 먼저 제거합니다. 그런 다음 남는 비용을 어떤 시각 피드백에 쓸지 결정합니다.
여섯 번째는 플랫폼별 QA입니다. 저가형 기기, 긴 세션, 재실행, 다운로드 후 첫 실행, 네트워크 불안정, 가로/세로 전환, 알림 후 복귀, 발열 상태, 배터리 절약 모드 같은 조건을 봐야 합니다. 모바일 이식은 첫 빌드가 켜지는 순간 끝나는 것이 아니라, 여러 일상적 방해 속에서도 게임이 이해 가능하게 남는지 보는 과정입니다.
마지막은 기록입니다. 어떤 문제 때문에 URP로 바꿨는지, 어떤 UI가 모바일에서 실패했는지, 어떤 아틀라스 정리가 build size에 영향을 줬는지 남겨야 합니다. 이 기록은 다음 플랫폼 대응의 자산이 됩니다. 포트폴리오나 블로그 콘텐츠로도 좋습니다. “PC 게임을 모바일로 냈습니다”보다 “PC UI를 모바일-first flow로 바꾸며 어떤 기준으로 성능과 정보 구조를 조정했습니다”가 훨씬 강합니다.
이 순서를 실제 일정으로 바꾸면 더 명확합니다. 첫 주에는 기준 빌드와 핵심 5분 플레이 문서를 만들고, 둘째 주에는 엔진 업그레이드와 렌더 파이프라인 전환을 분리해 검증합니다. 셋째 주에는 Device Simulator와 실제 기기로 UI 행동 루프를 반복 확인합니다. 넷째 주에는 Profiler와 Atlas Analyzer로 성능과 빌드 크기를 정리합니다. 마지막에는 QA 결과와 남은 리스크를 정리해 출시 여부를 판단합니다. 프로젝트마다 기간은 다르겠지만, 단계의 순서는 꽤 보편적으로 쓸 수 있습니다.
그리고 이 모든 과정에서 “모바일 버전은 PC 버전의 하위 버전”이라는 생각을 버리는 편이 좋습니다. 모바일 버전은 제약이 많지만, 다른 장점도 있습니다. 더 짧은 세션, 더 쉬운 접근, 구독 서비스에서의 발견 가능성, 터치 기반의 직접성, 휴대성은 PC 버전과 다른 강점입니다. 포팅의 목적은 PC에서 하던 일을 억지로 작은 화면에 밀어 넣는 것이 아니라, 같은 게임의 장점을 다른 플레이 맥락에서 다시 살아나게 하는 것입니다.
PC 카드 게임을 모바일로 옮길 때: Unity Causa 사례로 보는 UI, 성능, 빌드 크기 작업 메모
Unity의 Causa 모바일 이식 사례는 짧은 공식 인터뷰지만, 제작자 입장에서는 꽤 많은 질문을 남깁니다. PC 게임을 모바일로 옮긴다는 것은 화면 크기만 줄이는 일이 아닙니다. 플레이 루프, 입력 방식, 렌더 파이프라인, UI 정보 구조, 성능 관찰, 빌드 크기, 시각 피드백 우선순위를 다시 정하는 일입니다.
이 사례에서 가장 마음에 드는 부분은 기술 선택이 목적과 연결되어 있다는 점입니다. Google Play Pass에 맞는 싱글 플레이 캠페인 가능성을 보고, Unity 2019에서 Unity 6.3으로 올리고, Built-in에서 URP로 전환하고, Device Simulator와 Profiler, Sprite Atlas Analyzer로 모바일 대응을 정리했습니다. 완전히 새로운 게임을 만든 것은 아니지만, 기존 게임을 새로운 플레이 환경에 맞게 다시 읽은 것입니다.
게임 개발자와 디자이너, 아티스트, 테크니컬 아티스트에게 이 흐름은 좋은 참고가 됩니다. 포팅은 단순 호환 작업이 아니라 제작 의사결정입니다. 모바일에서 무엇을 더 선명하게 보여줄지, 무엇을 가볍게 만들지, 무엇을 지켜야 플레이어가 같은 게임으로 느낄지 정해야 합니다.
VFX Diary 관점에서도 이 주제는 계속 볼 만합니다. 모바일 최적화는 이펙트를 줄이는 이야기가 아니라, 플레이어가 작은 화면에서 어떤 신호를 받아야 하는지 다시 설계하는 이야기입니다. 좋은 포팅은 그래픽을 낮추는 작업이 아니라, 중요한 경험을 더 많은 기기에서 안정적으로 전달하는 작업입니다.
참고 출처
- Unity Blog, 2026-07-02,
Adapting Causa: Into the Dusk for mobile with Unity 6.3: https://unity.com/blog/adapting-causa-into-the-dusk-for-mobile - Unity Manual,
New in Unity 6.3: https://docs.unity3d.com/6000.4/Documentation/Manual/WhatsNewUnity63.html - Unity Manual,
Device Simulator introduction: https://docs.unity3d.com/6000.2/Documentation/Manual/device-simulator-introduction.html - Unity Manual,
Unity Profiler: https://docs.unity3d.com/6000.5/Documentation/Manual/Profiler.html - Unity Manual,
Sprite Atlas Analyzer: https://docs.unity3d.com/Packages/com.unity.2d.tooling%403.0/manual/index.html - Unity Manual,
Sprite atlases: https://docs.unity3d.com/6000.4/Documentation/Manual/sprite/atlas/atlas-introduction.html