
게임 프로그래머는 기획서의 규칙을 실제로 돌아가는 코드로 바꾸는 사람입니다. 수업은 C 언어와 C++로 변수, 함수, 포인터, 객체지향 같은 기본기를 단단히 …
모바일 기기가 안고 있는 네 가지 제약
- 성능 편차: 최신 고성능 기기부터 몇 년 된 보급형 기기까지 함께 써야 함
- 발열: 계산량이 많으면 기기가 뜨거워지고 스스로 성능을 낮춤
- 배터리: 화면을 많이 그리고 계산을 많이 할수록 배터리가 빨리 닳음
- 메모리와 용량: 사용할 수 있는 메모리가 적고 설치 용량에도 민감함
특히 발열은 PC 게임에서는 잘 겪지 않는 문제입니다. 휴대폰은 뜨거워지면 스스로 처리 속도를 낮추기 때문에, 처음에는 부드럽던 게임이 몇 분 뒤부터 끊기기 시작합니다. 개발용 고성능 기기에서는 이 문제가 잘 드러나지 않아, 출시 후에야 알게 되는 경우도 있습니다.
메모리가 부족하면 운영체제가 게임을 강제로 종료하기도 합니다. 플레이어 입장에서는 게임이 갑자기 꺼진 것으로 보이기 때문에, 원인을 알기 어려운 나쁜 경험이 됩니다.
최적화가 이용자와 매출에 닿는 이유
모바일 게임은 설치하고 몇 분 안에 계속할지 말지를 결정하는 이용자가 많습니다. 첫 실행에서 로딩이 길거나 화면이 끊기면, 게임의 재미를 보여 주기도 전에 이용자를 잃습니다. 보급형 기기에서도 무리 없이 돌아가야 더 많은 사람에게 게임을 보여 줄 수 있습니다.
설치 용량도 비슷합니다. 내려받아야 할 용량이 크면 설치 자체를 망설이는 사람이 생깁니다. 그래서 많은 모바일 게임이 처음에는 꼭 필요한 리소스만 받고, 나머지는 플레이하면서 추가로 받는 구조를 씁니다. 이런 구조를 설계하는 것도 프로그래머의 일입니다.
리뷰도 영향을 받습니다. 끊김과 발열, 강제 종료에 대한 불만은 스토어 리뷰에 그대로 남고, 새로 설치하려는 사람의 판단에도 영향을 줍니다. 최적화는 눈에 띄지 않지만 게임의 평판을 지키는 일입니다.
프로그래머가 주로 손대는 최적화 영역
첫째는 화면 그리기 비용입니다. 화면에 그리는 물체가 많거나, 투명한 이미지가 여러 겹 겹치면 그래픽 처리 부담이 커집니다. 같은 재질의 물체를 묶어서 그리고, 보이지 않는 물체는 그리지 않고, 멀리 있는 물체는 단순한 모델로 바꾸는 방법을 씁니다. 이 작업은 아티스트와 함께 기준을 정하는 경우가 많습니다.
둘째는 코드 실행 비용입니다. 매 프레임 불필요한 계산을 반복하거나, 객체를 계속 새로 만들고 버리면 끊김이 생깁니다. C#을 쓰는 유니티에서는 버려진 메모리를 정리하는 가비지 컬렉션이 순간적인 끊김을 만들 수 있어서, 총알이나 이펙트처럼 자주 생기는 객체는 미리 만들어 두고 재사용하는 오브젝트 풀링을 많이 씁니다.
셋째는 메모리와 로딩입니다. 텍스처 크기와 압축 방식을 기기에 맞게 정하고, 지금 필요 없는 리소스는 메모리에서 내리고, 다음 장면의 리소스는 미리 조금씩 불러오는 식으로 관리합니다. 로딩 화면이 길어지는 원인이 리소스 크기인지 초기화 코드인지 나눠서 보는 것도 중요합니다.
측정하지 않은 최적화는 추측일 뿐입니다
최적화에서 가장 흔한 실수는 느릴 것 같은 부분을 감으로 고치는 것입니다. 실제로 느린 곳은 전혀 다른 곳인 경우가 많습니다. 그래서 엔진이 제공하는 프로파일러(어떤 작업에 시간이 얼마나 쓰이는지 측정하는 도구)로 먼저 원인을 찾고, 고친 뒤 다시 측정해 효과를 확인하는 순서가 기본입니다.
측정은 개발용 PC가 아니라 실제 기기에서 해야 정확합니다. 가능하다면 성능이 낮은 기기 하나를 기준 기기로 정해 두고, 그 기기에서 목표 프레임을 유지하는지 확인하는 습관을 들이세요. 몇 분 이상 계속 플레이하며 발열 이후의 성능도 함께 보는 것이 좋습니다.
목표도 미리 정해 두어야 합니다. 몇 프레임을 유지할지, 메모리는 어느 선 아래로 쓸지, 로딩은 얼마나 걸려도 되는지 기준이 있어야 최적화가 끝났는지 판단할 수 있습니다. 기준 없이 시작하면 끝없이 고치거나, 반대로 중요한 문제를 놓친 채 멈추게 됩니다. 실무에서는 이 기준을 기획, 아트와 함께 정하는 경우가 많습니다.
포트폴리오에서 최적화 경험을 보여 주는 법
- 모바일 기기에 빌드한 게임을 준비하고 사용한 테스트 기기를 적기
- 프로파일러로 찾은 문제 지점을 화면 캡처와 함께 기록하기
- 어떤 방법으로 고쳤는지, 전후 프레임이나 메모리가 어떻게 달라졌는지 정리하기
- 오브젝트 풀링, 리소스 관리처럼 적용한 기법을 코드와 함께 보여 주기
전후 비교가 있는 최적화 기록은 신입 포트폴리오에서 눈에 띄는 자료입니다. 큰 개선이 아니어도 괜찮습니다. 문제를 측정하고, 원인을 찾고, 고친 뒤 확인하는 과정을 한 번이라도 제대로 보여 주면 실무 감각이 있다는 인상을 줍니다. 면접에서도 최적화 질문이 나왔을 때 이 경험을 그대로 이야기할 수 있습니다.
처음부터 가볍게 만드는 습관이 가장 좋은 최적화입니다
최적화를 출시 직전에 몰아서 하면 고칠 곳이 너무 많아집니다. 처음부터 매 프레임 실행되는 코드에 무거운 작업을 넣지 않고, 리소스 크기 기준을 정해 두고, 주기적으로 실제 기기에서 확인하는 습관이 결국 가장 효과적인 최적화입니다. 이런 습관은 모바일뿐 아니라 어떤 플랫폼에서도 통합니다.
모바일 게임 프로젝트를 만들어 보고 싶은데 최적화까지 어떻게 다뤄야 할지 막막하다면, SBS아카데미게임학원 유니티 과정 상담에서 모바일 빌드와 성능 점검을 포함한 프로젝트 방향을 함께 정리해 보세요.
자주 묻는 질문
신입에게도 최적화 경험을 기대하나요?
깊은 경험까지 기대하지는 않지만, 기본 개념과 측정 도구를 써 본 경험이 있으면 좋은 평가를 받습니다. 특히 모바일 게임 회사에서는 자주 묻는 주제입니다.
테스트할 기기가 하나뿐이면 어떻게 하나요?
가진 기기에서 꾸준히 측정하는 것만으로도 의미가 있습니다. 가능하다면 성능이 낮은 기기에서도 한 번쯤 확인해 보는 것이 좋습니다.
언리얼로 만든 모바일 게임도 최적화 방법이 같나요?
원리는 같지만 도구와 설정은 엔진마다 다릅니다. 사용하는 엔진의 공식 문서에서 모바일 관련 항목을 함께 확인하세요.
가까운 캠퍼스에서 게임프로그래밍 알아보기
사는 곳과 가까운 캠퍼스를 고르면 수업 내용, 오시는 길, 상담 신청을 한 번에 볼 수 있습니다.