기본적으로 가볍습니다: 작은 스튜디오가 게임을 빠르게 유지하는 방법

2026년 6월 29일

터치에서 실행까지의 모든 밀리초는 당신을 반대하는 조용한 베팅입니다. 모바일에서는 이 베팅이 누적됩니다 — 느린 시작, 버벅이는 첫 프레임, 게임 제목 화면을 보기도 전에 누군가의 데이터 사용량을 조용히 소모하는 다운로드. 대부분의 플레이어는 기다리지 않습니다. 로딩 바가 반쯤 채워지기도 전에 탭을 닫고 다른 것을 엽니다.

우리는 Pong Studio에서 이 문제를 항상 고려합니다. 이는 첫 번째 커밋부터 최종 릴리스 빌드에 이르기까지 결정을 형성합니다.

“가볍고 빠르고 재미있음”은 우연히 결정한 슬로건이 아닙니다. 우리가 선택한 제약 조건입니다. 의도적으로 선택된 제약 조건은 작업을 더 좋게 만듭니다.

왜 모바일은 다른 게임인가

데스크탑 플레이어는 느린 시작을 용서합니다. 그들은 이미 자리 잡고 있고, 전원을 연결하고 있으며, 다른 탭에 주의를 분산시킵니다. 모바일 플레이어는 한 가지 일과 다른 일 사이에 있습니다. 버스에 타고 있거나 줄을 서서 있고, 업무 사이의 30초를 채우고 있습니다. 인내심의 한계는 좁고, 경쟁은 기기의 다른 모든 것이 됩니다.

또한 하드웨어의 현실도 있습니다. 기술 언론에서 리뷰하는 플래그십 스마트폰은 대부분의 플레이어가 사용하는 스마트폰이 아닙니다. 출시 당시 중간 수준이었지만, 지금은 물려받은 두세 년 전의 폰이 실제 타겟입니다. 우리가 소유한 최고의 하드웨어만 테스트한다면, 실제로 플레이하는 사람에 대해 스스로를 속이는 것입니다.

성능을 넘어선 것은 존중입니다. 배터리는 제한되어 있고, 데이터 요금제도 제한되어 있고, 주의도 제한되어 있습니다. 이러한 한계를 존중하는 게임은 플레이어가 단 한 번도 버튼을 누르지 않았음에도 불구하고 호의를 얻습니다.

오직 가치를 증명한 것만 출시하라

우리가 수행하는 가장 효과적인 최적화는 단 한 줄의 코드도 작성하기 전에 이루어집니다. 즉, 무엇을 만들지 않을지를 결정하는 것입니다.

모든 기능, 모든 자산, 모든 의존성에는 비용이 따릅니다 — 다운로드 크기, 파싱 시간, 런타임 메모리, 유지보수 부담. 매번 같은 질문을 던집니다. 이것이 제 몫을 합니까? 게임을 분명히 더 재미있게 만듭니까, 아니면 우리가 할 수 있기 때문에 추가하는 것입니까? 다른 곳에서 본 것입니까? “진짜 게임” 같아야 한다고 느껴서입니까?

많은 것들이 최종적으로 포함되지 않습니다. 이는 실패가 아닙니다. 이는 자기 통제의 결과입니다.

생략한 기능은 성능 버그를 일으키지 않습니다.

이러한 사고방식은 우리의 웹 도구에도 적용됩니다. Toolio는 우리가 “유용한 도구는 실제로 무엇을 필요로 할까?”라는 질문을 계속 던지며, 그 질문에 답하지 못하는 모든 것을 지속적으로 버렸기 때문에 존재합니다.

추가하기 전에 측정하라, 이후가 아니라

지금 어떤 것을 추가하고 나중에 비용을 걱정하는 것이 유혹적일 수 있습니다. 우리는 이 순서를 뒤집는 방법을 배웠습니다. 라이브러리를 가져오거나 새로운 시스템을 추가하기 전에 먼저 비용을 이해하려고 합니다 — 파일 크기뿐만 아니라 CPU, GPU, 그리고 런타임 시 플레이어의 주의를 요구하는 부분도 포함하여.

어떤 것이 느리다고 느껴질 때, 우리는 추측하기 전에 프로파일링을 합니다. 직감이 병목 현상이 어디에 있는지 올바르게 파악하는 경우보다는 틀리는 경우가 더 많습니다. 실제 원인은 보통 예상치 못한 곳에 있습니다. 먼저 측정하는 것은 우리가 원래 느리지 않았던 것을 다듬는 대신 진짜 문제를 해결할 수 있게 해줍니다.

기다릴 수 있는 것은 지연 로딩하라

플레이어가 탭하는 순간에 모든 것이 준비되어야 할 필요는 없습니다. 타이틀 화면은 최종 보스 음악이 로딩되어 있을 필요가 없습니다. 튜토리얼은 마지막 레벨의 자산이 필요하지 않습니다.

로딩을 플레이어가 즉시 필요로 하는 것과 나중에 필요로 하는 것으로 나누어, 가능한 한 모든 것을 미룹니다. 게임과의 첫 접촉은 빠르게 이루어져야 합니다. 나머지는 플레이어가 이미 몰입하고 기분 좋은 상태일 때 배경에서 조용히 로딩됩니다.

성능은 정리 작업이 아니라 기능입니다

위험한 것은 성능을 마지막에 최적화할 것처럼 생각하는 것입니다. 그 시점에는 아키텍처가 이미 결정되고, 자산의 크기도 결정되어 있고, 의존성도 고정되어 있습니다. 기존 요소를 제거하는 것은 처음부터 추가하지 않는 것보다 더 어렵습니다.

우리는 처음부터 성능을 디자인 제약으로 다룹니다. 재미, 명확성, 학습 곡선과 마찬가지로요. 이는 작업을 더 어렵게 만드는 것이 아니라, “이것이 우리를 가볍게 유지하는가?”라는 구체적인 질문에 구체적인 답변을 주기 때문에 결정을 더 쉽게 만듭니다.

작은 스튜디오는 엔지니어링 인력을 충분히 갖추지 못해 블로트를 스마트한 런타임 기술로 덮어 버릴 수 없습니다. 우리는 가볍게 유지해야 하기 때문에 그렇게 합니다. 그리고 “해야 한다”는 의무감이 더 나은 게임을 만든다는 것을 알게 되었습니다.

다음 게임이 플레이 가능해지는 순간을 알고 싶으세요? 출시 소식 받기 →