재사용 가능한 게임 프레임워크 구축: 우리가 게임을 50% 더 빠르게 출시하는 방법

발행: (2026년 2월 24일 오후 09:05 GMT+9)
12 분 소요
원문: Dev.to

Source: Dev.to

Ocean View Games

모든 새로운 게임 프로젝트는 동일한 보일러플레이트로 시작합니다: 오디오 매니저, 씬 전환, 저장 시스템, 햅틱‑피드백 래퍼, 분석 훅, UI 스캐폴딩. 이들 중 어느 것도 게임에 고유한 것이 아니지만, 각 팀은 이를 처음부터 다시 구축합니다.

Ocean View Games에서는 그 비용을 더 이상 지불하지 않기로 했습니다. What’s That(모바일 퀴즈 게임)를 개발할 때 이를 재사용 가능한 프레임워크를 위한 실시간 테스트베드로 활용했습니다. 게임은 성공적으로 출시되었지만, 실제 전달물은 우리가 추출한 모듈식 컴포넌트 라이브러리였습니다.

그 라이브러리를 사용하면 빈 Unity 프로젝트에서 시작하는 것보다 클라이언트 프로젝트를 30‑50 % 빠르게 시작할 수 있습니다 (Rapid Prototyping Hyper‑Casual Framework).

The Problem: Rewriting the Same Code, Every Project

우리의 첫 해 클라이언트 작업에서 패턴을 발견했습니다. 모든 모바일 게임은 다음이 필요합니다:

  • Audio manager – 음악, SFX 및 볼륨 설정을 관리합니다.
  • Scene manager – 전환, 로딩 화면 및 딥 링크를 관리합니다.
  • Save system – 플레이어 상태를 로컬 스토리지에 직렬화합니다.
  • Haptic‑feedback wrapper – iOS Taptic Engine과 Android 진동을 통합합니다.
  • UI system – 공통 패턴(모달, 토스트, 로딩 스피너)을 제공합니다.
  • Analytics hook – 특정 제공업체에 종속되지 않고 이벤트를 발생시킵니다.

각 항목을 제대로 구축하는 데 2–5 일이 소요됩니다. 6–8주 프로젝트에서는 2–3 주가 실제 게임플레이 코드를 작성하기 전 인프라에 사용됩니다.

하이퍼캐주얼 시장은 이를 더욱 부각시켰습니다. 클라이언트는 4–6 주 안에 MVP를 빠르게 필요로 합니다. 그 절반을 보일러플레이트에 소비하는 것은 경쟁력이 없습니다.

Key Takeaway: 모든 프로젝트에서 동일한 시스템을 구축하고 있다면, 중복 작업에 대해 클라이언트에게 비용을 청구하거나 스스로 비용을 흡수하고 있는 것입니다. 어느 쪽도 지속 가능하지 않습니다.

우리의 접근 방식: 추출, 표준화, 테스트

우리는 상향식으로 프레임워크를 설계했습니다. 배송된 게임에서 검증된 코드를 추출하면서 하향식이 아닌 하향식으로 구축했습니다.

Step 1 – 실제 제품에 적용

What’s That는 다양한 일반 시스템(오디오, UI, 영속성, 햅틱, 씬 관리)을 활용하도록 의도적으로 범위를 잡았습니다. 게임에 필요한 것보다 약간 더 추상화된 형태로 각 시스템을 구축했으며, 나중에 이를 추출할 수 있다는 점을 염두에 두었습니다.

Step 2 – 디커플링 및 패키징

게임이 출시된 후 각 시스템을 검토하면서 다음 질문을 던졌습니다: “이 시스템이 What’s That에만 특화된 무언가에 의존하고 있나요?”

  • → 결합을 제거하도록 리팩터링.
  • 아니오 → 그대로 프레임워크에 추가.

그 결과, 각각이 다음을 갖춘 독립적인 모듈 집합이 만들어졌습니다:

  • 명확한 공개 API
  • 다른 프레임워크 모듈에 대한 의존성 없음(명시적으로 선언된 경우 제외)
  • 설정을 위한 프리팹 또는 ScriptableObject
  • 기본 단위 테스트

Step 3 – 클라이언트 프로젝트에서 검증

프레임워크의 가치는 다른 게임에서도 살아남을 때 입증됩니다. 우리는 이를 세 개의 후속 클라이언트 프로젝트에 배포하고 필요한 조정을 추적했습니다:

  1. 오디오 매니저 – Android에서 백그라운드/포그라운드 전환을 올바르게 처리하지 못함.
  2. 저장 시스템 – 암호화 지원이 필요함.

각 수정 사항은 프레임워크에 다시 반영되었습니다.

Source:

프레임워크에 포함된 내용

Audio Manager

음악, SFX, 환경음의 세 가지 오디오 레이어를 독립적인 볼륨 제어와 함께 관리하는 싱글톤.

  • 음악 트랙 간 크로스‑페이드 전환
  • 자동 덕킹 (SFX 재생 시 음악 볼륨이 순간적으로 낮아짐)
  • 앱 최소화 처리 – 앱이 포커스를 잃으면 음악이 일시 정지하고 다시 포커스를 얻으면 정상적으로 재개
  • 볼륨 설정이 저장 시스템을 통해 지속됨

Haptic Feedback Wrapper

iOS와 Android는 햅틱을 전혀 다르게 처리합니다. 우리 래퍼는 통합 API를 제공합니다:

HapticFeedback.Light();   // iOS selection feedback, Android 10 ms vibration
HapticFeedback.Medium();  // iOS impact feedback, Android 25 ms vibration
HapticFeedback.Heavy();   // iOS notification feedback, Android 50 ms vibration

플레이 테스트를 통해 각 단계가 플랫폼 간에 인지적으로 동등하게 느껴지도록 튜닝되었습니다.

Scene Manager

구성 가능한 로딩 화면을 사용한 씬 전환을 담당합니다.

  • 사용자 정의 커브가 가능한 페이드‑투‑블랙 전환
  • 진행 상황 콜백을 지원하는 비동기 씬 로딩
  • 매끄러운 전환을 위한 씬 사전 로딩
  • 딥‑링크 처리 (앱을 특정 씬으로 직접 열기)

Save System

Unity의 PlayerPrefs 위에 구축된 가벼운 직렬화 레이어에 구조를 추가했습니다.

  • 타입‑안전 접근자 (코드베이스 전체에 흩어져 있는 원시 문자열 키 제거)
  • 민감한 데이터에 대한 선택적 AES 암호화
  • 마이그레이션을 지원하는 버전 관리 저장 포맷
  • 쓰기 전 자동 백업

UI Component Library

일관된 인터랙션 패턴을 따르는 사전 구축된 테마 가능한 컴포넌트.

  • 배경 탭으로 닫을 수 있는 모달 다이얼로그
  • 자동 해제 타이머가 있는 토스트 알림
  • 진행 표시기가 포함된 로딩 오버레이
  • 눌림 시 스쿼시‑앤‑스트레치 애니메이션과 사운드가 적용된 버튼 컴포넌트

클라이언트 프로젝트에 대한 영향

The framework does not eliminate custom work. Every game still needs unique gameplay code, art integration, and design iteration. What it eliminates is the first two weeks of setup.

On a recent project for Mojo Games (Pocket Factory) the framework saved an estimated 10 days of development time. Audio, haptics, and scene management were configured in hours rather than days, and that time went directly into gameplay.

Ready to accelerate your next Unity project?
Explore the full framework and case studies on our website: https://oceanviewgames.co.uk

Source:

라잎 폴리시; 실제로 제품을 차별화하는 개발 부분

핵심 요약: 프레임워크의 가치는 단순히 속도에 있는 것이 아니라 일관성에도 있습니다. 오디오, 저장, UI가 검증된 패턴을 따를 때, 이미 해결된 문제에 대해 새로운 코드를 디버깅하지 않으므로 결함률이 낮아집니다.

자체 프레임워크를 구축해야 할 때

모든 스튜디오가 프레임워크를 만들 필요는 없습니다. 다음과 같은 경우에 의미가 있습니다:

  • 연간 여러 프로젝트를 출시할 때 – 투자 비용이 여러 릴리스에 걸쳐 상쇄됩니다.
  • 프로젝트들이 같은 플랫폼을 공유할 때 – 모바일 Unity 프레임워크는 데스크톱 Unreal 프로젝트에 도움이 되지 않습니다.
  • 전투 검증된 코드를 추출할 수 있을 때 – 프레임워크를 추상적으로 설계하지 말고, 실제 출시된 제품에서 추출하세요.
  • 팀이 업데이트에 대해 엄격히 관리할 때 – 유지 관리되지 않는 프레임워크는 오히려 부채가 됩니다.

2년마다 게임 하나만 출시한다면, 프레임워크 유지에 드는 비용이 절감 효과보다 클 가능성이 높습니다. 대신 깔끔하고 문서화된 코드를 중점적으로 관리하세요.

관련 읽을거리

0 조회
Back to Blog

관련 글

더 보기 »

SDF 폰트 가이드 작성하기

2024년에 나는 서명 거리 필드(SDF) 렌더링을 이용해 폰트의 외곽선과 그림자를 한 번에 구현하려는 실험을 시작했다. 나는 프로토…

GitHub README에 Credly 인증서 전시하기

개요: Credly에 인증서가 있고 이를 GitHub 프로필에 표시하고 싶다면, 오픈‑source 도구가 이를 매우 간단하게 만들어 줍니다. 이 도구는 무료 API를 제공합니다.