1편에서 아이디어를 고르고, 2편에서 조작과 판정 규칙을 정했다. 이제 그걸 어떤 도구로 만들었는지 정리한다. 이 글은 "사용한 기능" 편이다.

왜 Compose로 시작했나

Android에서 먼저 만들기로 했다. 화면 대부분이 직접 그리는 게임 화면이라 선언형 UI가 잘 맞았다. Flutter 버전은 Android를 끝낸 뒤에 생각하기로 했다. [보강: Flutter가 아니라 Compose를 먼저 고른 이유]

쓴 라이브러리

app/build.gradle.kts의 의존성을 역할별로 묶으면 이렇다.

// UI
implementation(platform(libs.compose.bom))
implementation(libs.compose.material3)
implementation(libs.compose.material3.windowsize)   // 태블릿·가로 화면 대응
implementation(libs.androidx.navigation.compose)

// 구조
implementation(libs.hilt.android)                    // 의존성 주입
ksp(libs.hilt.compiler)
implementation(libs.androidx.hilt.navigation.compose)

// 데이터
implementation(libs.moshi)                           // JSON
ksp(libs.moshi.kotlin.codegen)
implementation(platform(libs.firebase.bom))
implementation(libs.firebase.auth)
implementation(libs.firebase.firestore)

// 수익·분석
implementation(libs.play.services.ads)               // AdMob

폴더는 기능별로 나눴다

feature/play        게임 화면과 ViewModel
game/logic          자르기·판정 같은 순수 규칙
data/repository     저장·불러오기
core/ads            광고 관리
core/feedback       진동·효과음 같은 피드백
core/analytics      분석 이벤트

핵심은 game/logic이다. 자르기와 판정 규칙을 화면과 분리해 두니 규칙을 바꿔도 화면 코드를 거의 건드리지 않았다. 2편에서 판정 방식을 갈아엎을 수 있었던 것도 이 덕분이다.

Hilt + Repository를 쓴 이유

[보강: 작은 게임인데 Hilt와 Repository까지 쓴 이유를 본인 말로]

정리

• 화면(Compose) / 규칙(game/logic) / 저장(repository) / 부가 기능(ads, feedback, analytics)을 폴더로 나눴다.
• 규칙을 화면에서 분리하면 판정 방식을 바꿔도 수정 범위가 작다.
• 태블릿 대응용으로 material3-window-size-class를 넣어 두었다.

다음 글에서는 AI와 이 코드를 실제로 어떤 순서로 만들었는지, 만들다 겪은 버그와 함께 쓴다.