어둠의 던전을 밝혀라

이전 프로젝트에서는 Flutter 앱 개발, 스토어 출시, 광고를 통한 사용자 유입을 경험했습니다. 특히 "스냅슬라이드 퍼즐 게임"을 통해 광고 집행으로 다운로드를 만들 수 있다는 점을 확인했지만, 다운로드 수가 곧 지속 사용자를 의미하지는 않는다는 한계도 함께 확인했습니다.

그래서 이번 프로젝트에서는 단순히 앱을 출시하는 것보다, 사용자가 반복해서 플레이할 수 있는 게임 구조를 만드는 데 초점을 맞췄습니다. 처음에는 Text RPG를 구상했지만, 로그인과 데이터 관리 기반을 구현하는 과정에서 개발 범위가 예상보다 커졌습니다. 이후 더 빠르게 구현하면서도 반복 플레이 구조를 만들 수 있는 아이디어를 검토했고, 규칙이 직관적인 지뢰찾기 기반 RPG 퍼즐 게임으로 방향을 조정했습니다.

이 프로젝트를 선택한 이유는 다음과 같습니다.

참고한 게임은 Daniel Benmergui의 Dragonsweeper였습니다. Dragonsweeper는 관찰이 필요한 지뢰찾기 게임으로 소개되어 있으며, Minesweeper와 Roguelike 태그를 가진 HTML5 퍼즐 게임입니다 [Daniel Benmergui - Dragonsweeper, itch.io]. 이 프로젝트에서는 해당 게임의 아이디어를 그대로 복제하기보다, 지뢰찾기 규칙을 RPG 전투와 캐릭터 성장 구조에 연결하는 방향으로 확장했습니다.

개발 목표 설정

"어둠의 던전을 밝혀라"의 개발 목표는 Flutter로 지뢰찾기 기반 RPG 퍼즐 게임을 개발해 Android와 iOS에 출시하고, 로그인·데이터 저장·광고·인앱 결제까지 포함한 모바일 게임 구조를 구현하는 것이었습니다.

이번 프로젝트에서는 단순한 게임 로직 구현을 넘어, 사용자 식별과 진행 데이터 관리까지 함께 다뤄야 했습니다. 캐릭터 성장, 보유 재화, 스테이지 진행 상태, 광고 보상, 인앱 결제 상품이 서로 연결되기 때문에, 사용자의 플레이 기록과 결제 보상이 안정적으로 관리되는 구조가 필요했습니다.

특히 인앱 결제를 통한 수익화 구조를 실험하려면 데이터 무결성이 중요했습니다. 구매한 재화가 정확히 지급되고, 사용자별 진행 상태와 보유 재화가 일관되게 유지되어야 했기 때문입니다. 그래서 계정 기반의 사용자 식별 기능을 함께 구현하기로 했습니다.

로그인 기능은 Supabase Auth의 Social Login (OAuth) 기능을 활용해 Google 로그인과 Apple 로그인을 제공하고, 계정 없이 바로 시작할 수 있는 사용자를 위해 Anonymous Sign-Ins 방식도 제공하고자 했습니다.

이번 프로젝트의 개발 목표에는 완전히 통제된 Cursor 바이브코딩 실험도 포함되어 있었습니다. 전체 프로젝트 구조, 코드 배치, 기능 단위 설계는 직접 정하고, AI 도구는 정해진 구조 안에서 코드를 작성하는 코더 역할로 제한했습니다. 기능을 요청할 때도 어느 코드 파일에 어떤 기능과 어떤 내용을 구현해야 하는지 구체적으로 지시했고, 결과가 만족스럽지 않은 작은 부분은 직접 수정하는 방식으로 진행했습니다.

시스템 아키텍처

"어둠의 던전을 밝혀라"는 지뢰찾기 규칙을 기반으로 던전 타일을 열고, 주변 정보를 확인하며, 열쇠를 찾은 뒤 게이트를 통해 다음 스테이지로 이동하는 모바일 게임 앱으로 구성했습니다. 사용자가 타일을 선택하면 앱은 현재 던전 상태를 확인하고, 주변 몬스터 수와 주변 오브젝트 힌트를 바탕으로 다음 행동을 판단할 수 있도록 정보를 보여줍니다.

게임 진행은 던전 보드 상태를 중심으로 이어집니다. 타일에는 몬스터, 보물상자, 열쇠, 게이트, 빈칸 중 하나의 정보가 들어 있고, 사용자가 타일을 열 때마다 숫자 표시, 힌트 표시, 전투, 보상 획득, 열쇠 획득, 게이트 이동 흐름으로 분기되도록 구성했습니다.

핵심 구현 흐름

로그인과 사용자 데이터 관리

이 프로젝트에서는 사용자별 진행 상태를 저장하기 위해 로그인과 데이터 관리 기능을 함께 구현했습니다. 사용자가 누구인지 구분되어야 스테이지 진행, 보유 재화, 캐릭터 성장 정보를 안정적으로 관리할 수 있었기 때문입니다.

Supabase Auth를 활용해 게스트 로그인과 소셜 로그인 기반을 구성했고, 로그인한 사용자를 기준으로 게임 진행 데이터를 관리하는 구조를 만들었습니다 [Supabase - Auth]. 이 과정에서 단순한 로컬 게임보다 사용자 식별과 데이터 저장 설계가 중요하다는 점을 확인했습니다.

지뢰찾기 기반 던전 규칙 구현

"어둠의 던전을 밝혀라"는 지뢰찾기처럼 숨겨진 타일을 열고, 주변 정보를 바탕으로 다음 행동을 판단하는 구조로 설계했습니다. 사용자가 타일을 선택하면 해당 타일이 빈칸, 몬스터, 보물상자, 열쇠, 게이트 중 무엇인지에 따라 다른 흐름으로 분기되도록 구현했습니다.

빈칸을 열었을 때는 주변 9방향에 있는 몬스터 수를 숫자로 표시했습니다. 여기에 추가로 주변에 보물상자, 열쇠, 게이트가 있는지 알려주는 오브젝트 힌트를 넣어, 단순히 몬스터를 피하는 것이 아니라 보상과 진행 목표를 함께 추론할 수 있도록 만들었습니다.

스테이지의 목표는 모든 타일을 여는 것이 아니라, 던전 안에서 열쇠를 찾고 게이트를 통해 다음 스테이지로 이동하는 것이었습니다. 이를 통해 지뢰찾기의 추론 규칙을 던전 탐색과 스테이지 진행 구조로 확장했습니다.

스탯 기반 전투 로직 구현

몬스터 타일은 단순히 피해야 하는 장애물이 아니라, 전투를 통해 경험치와 재화를 얻을 수 있는 위험 요소로 설계했습니다. 캐릭터와 몬스터에는 공격력, 방어력, 스피드, HP를 두었고, 몬스터 타일을 열면 이 스탯을 기준으로 전투 결과가 계산되도록 구현했습니다.

전투는 캐릭터와 몬스터가 서로 공격하는 방식으로 진행했습니다. 기본적으로 공격력과 방어력을 기준으로 데미지를 계산하되, 스피드 차이에 따라 공격력·방어력 보정, 회피, 크리티컬이 발생할 수 있도록 했습니다. 이를 통해 같은 몬스터를 만나더라도 캐릭터 상태에 따라 전투 결과가 달라지도록 만들었습니다.

전투에서 승리하면 경험치와 재화를 얻고, 캐릭터 HP가 0이 되면 플레이가 종료됩니다. 다만 한 번은 크리스탈 또는 보상형 광고를 통해 부활할 수 있도록 하여, 전투 결과가 성장과 재화 사용 흐름으로 이어지게 했습니다.

캐릭터 성장과 반복 플레이 구조 구현

지속 플레이를 만들기 위해 전투 보상이 캐릭터 성장으로 이어지도록 구성했습니다. 사용자는 전투를 통해 경험치와 재화를 얻고, 이를 바탕으로 캐릭터를 성장시키거나 새로운 캐릭터를 구매할 수 있습니다.

캐릭터 성장은 단순히 레벨을 올리는 기능이 아니라, 더 높은 스테이지에 도전할 이유를 만드는 구조였습니다. 전투에서 얻은 보상은 캐릭터 능력치 강화와 연결했고, 골드와 크리스탈은 캐릭터 구매와 일부 성장 요소에 사용할 수 있도록 했습니다.

이 구조를 통해 사용자가 던전을 반복해서 플레이하고, 보상을 모으고, 캐릭터를 강화한 뒤 다시 더 높은 스테이지에 도전하는 흐름을 만들고자 했습니다.

상점과 인앱 결제 흐름 구현

상점은 크리스탈, 하트, 부활, 캐릭터 성장 요소가 연결되는 구조로 구현했습니다. 사용자는 실제 결제를 통해 크리스탈 같은 디지털 상품을 구매할 수 있고, 구매한 크리스탈은 게임 내 재화로 지급되도록 구성했습니다.

크리스탈은 하트 충전, 하트 충전 시간 감소, 부활, 캐릭터 구매와 성장 요소에 사용할 수 있도록 했습니다. 또한 캐릭터 HP가 0이 되었을 때 크리스탈을 사용하면 완전 HP로 부활하고, 보상형 광고를 보면 절반 HP로 부활하는 방식으로 결제 재화와 광고 보상을 함께 연결했습니다.

이 과정에서 Google Play Billing과 Apple In-App Purchase를 모두 적용했습니다. 단순히 상품을 등록하는 것에서 끝나는 것이 아니라, 결제 완료 여부를 확인하고 구매한 디지털 상품을 사용자 데이터에 반영하는 흐름까지 구현했습니다.

광고와 인앱 결제 적용

무료 게임으로 출시하면서 보상형 광고와 인앱 결제를 함께 적용했습니다. 사용자는 광고를 시청하고 보상을 받을 수 있으며, 크리스탈 같은 게임 내 재화를 인앱 결제로 구매할 수 있도록 구성했습니다.

Android에서는 Google Play Billing을, iOS에서는 Apple In-App Purchase를 기준으로 결제 구조를 적용했습니다 [Android Developers - Google Play Billing Library integration] [Apple Developer - In-App Purchase types]. 크리스탈처럼 사용하면 사라지고 다시 구매할 수 있는 상품은 소모성 상품 구조에 맞춰 설계했습니다.

바이브코딩 방식

이 프로젝트에서는 Cursor를 활용한 바이브코딩을 이전보다 더 통제된 방식으로 적용하고자 했습니다. 전체 프로젝트 구조와 코드 배치, 기능 단위의 설계 방향은 직접 정하고, AI는 정해진 범위 안에서 코드를 작성하는 역할로 제한했습니다.

작업을 요청할 때도 단순히 기능 구현을 맡기기보다, 수정할 파일과 연결해야 할 코드, 만족해야 할 동작을 구체적으로 지정했습니다. 작은 수정이나 결과가 만족스럽지 않은 부분은 직접 고치며, AI가 프로젝트 전체 구조를 흔들지 않도록 관리했습니다.

이 방식은 코드 구조를 파악하고 유지보수하는 데는 이전보다 유리했습니다. 하지만 작업을 잘게 나누고 결과를 계속 검토해야 했기 때문에, 개발 속도는 기대만큼 빨라지지 않았습니다. 특히 로그인처럼 처음 시도하는 기능은 직접 구조를 충분히 잡아주기 어려웠고, 결국 전체 흐름을 다시 파악한 뒤 대규모로 수정해야 했습니다.

또한 프로젝트 규모가 커질수록 코드 파일 수와 기능 간 연결이 늘어나면서, 같은 수준의 요청을 하더라도 AI가 지시한 요구사항을 한 번에 구현하지 못하는 경우가 다시 많아졌습니다. 결과적으로 통제된 바이브코딩은 코드 품질과 유지보수성 측면에서는 개선 효과가 있었지만, 복잡한 기능 구현과 개발 속도 측면에서는 여전히 한계가 있었습니다.

앱 출시 심사 이슈 대응

Google Play Store 출시는 예상보다 늦어졌습니다. Google Play는 새 개인 개발자 계정에 대해 프로덕션 출시 전 비공개 테스트를 요구하며, 최소 12명의 테스터가 14일 이상 연속으로 참여해야 프로덕션 신청이 가능하다고 안내합니다 [Google Play Console Help - App testing requirements for new personal developer accounts]. 이 요건 때문에 Google Play 출시가 지연되었고, Apple App Store에 먼저 앱을 출시하게 되었습니다.

문제는 이후 Google Play 프로덕션 심사에서 발생했습니다. Google Play의 명의도용 정책은 다른 앱이나 개발자와의 관계를 오해하게 만드는 앱 이름, 아이콘, 설명, 앱 내부 요소를 허용하지 않는다고 설명합니다 [Google Play Console Help - Impersonation]. 또한 지식재산권 정책은 저작권·상표권 등 타인의 권리를 침해하는 앱을 허용하지 않으며, 경우에 따라 권리 증빙을 요구할 수 있다고 안내합니다 [Google Play Console Help - Intellectual Property].

이 프로젝트에서는 다른 사람의 앱 이름, 이미지, 리소스, 설명을 사용하지 않았습니다. 다만 Google Play 심사 시점에는 내가 먼저 출시한 App Store 버전이 이미 공개되어 있었고, 검색했을 때 유사하게 보일 수 있는 대상도 그 App Store 버전뿐이었습니다. 그래서 선출시된 동일 앱이 Google Play 심사 과정에서 별도 앱 또는 타인의 앱처럼 오인되었을 가능성이 있다고 판단했습니다.

처음에는 App Store와 Google Play의 앱 이름, 저작권 표기, 개발자 정보, 이메일을 맞추고 App Store Connect 관리 화면, 접속 동영상, 사업자등록 증명, 신분 증명 자료를 제출했습니다. 하지만 이것만으로는 해결되지 않았습니다. 결국 App Store에 먼저 출시된 앱도 내가 만든 동일 앱이며, Google Play 출시 역시 같은 권리자가 진행한다는 별도 권리 증빙 문서를 작성해 제출했고, 그제서야 Google Play 재제출을 진행할 수 있었습니다.

스토어 출시