본문 바로가기
Unity/Records

1인 개발 가디언 슬래시 출시 후기

by Dev_카페인 2025. 1. 1.
반응형

1인 개발 가디언 슬래시 출시 후기

 

게임 이름 : 가디언 슬래시

플랫폼 : 구글 플레이 스토어 (안드로이드)

출시 날짜 : 2024년 12월 19일

 

 

2024년 12월 19일 구글 플레이 스토어에 첫 게임을 출시하였습니다.

처음 게임을 기획할 때에는 어렸을 때 즐겨 했던 건물 부수기를 모티브로 잡고 모바일 환경에 맞춰 여러가지 기능을 추가하면서 시작했습니다. 건물 부수기 게임은 하늘에서 떨어지는 건물을 스틱맨이 검을 휘둘러 부수는 것과 건물을 막아 떨어지는 속도를 늦출 수 있는 것이 이 게임의 재미라고 판단하였고, 재미 요소와 더불어 여러가지 성장 요소(스테이지, 아이템)를 추가하면서 게임의 틀을 잡아나갔습니다.

 

가디언 슬래시 프로젝트를 진행하면서 가장 욕심냈던 부분은 게임 개발 프로세스의 이해와 응용이었습니다. 특히 모바일 환경에 맞춘 인터페이스와 사용자의 데이터 저장, 그리고 수익화에 관련된 광고와 인앱결제까지 구현하고 출시하는 것이 목표였습니다.

 

막막했던 부분

처음에 가장 막막했던 부분은 데이터의 저장이었습니다. 물론 기기에 저장하는 쉬운 방법이 있었지만 내 자신의 성장과 더불어 경험을 쌓기 위해 다른 방안을 찾아봤습니다. 구글 플레이 게임즈에서 지원하는 데이터 저장 방식, 파이어 베이스나 뒤끝 처럼 게임 데이터 서버를 지원해주는 플랫폼, 유명한 아마존과 포톤 서버, 직접 서버를 구현해 사용자 데이터를 저장하는 방식 등 여러가지 방법을 두고 몇날며칠을 고민했습니다.

 

데이터 저장에 관한 사항들을 결정하기에 앞서 프로젝트에서 사용되는 기능 또는 데이터들가 무엇이 필요한지 정리가 필요했습니다. 어떤 데이터가 필요한지 생각해보니 기본적으로 사용자를 구분할 수 있는 ID와 스테이지 정보, 아이템 정보 등이 필요했고 그 외 기능(길드, 이벤트, 우편, 채팅)은 사용할 일이 없었습니다. 그리고 서버와의 통신에 대해서 깊게 이해할 필요가 있다고 판단하여 직접 서버와 데이터베이스를 구현하기로 결정했습니다.

서버 선택

서버를 직접 구현한다고 마음은 먹었지만 처음부터 뜻대로 되는 것은 없었습니다. 경험도 없고 이론적인 지식만 있는 상태에서 직접 서버를 구현한다는 것은 맨땅에 헤딩하는 것과 같은 느낌을 받았습니다. 시작하기 전에 가장 두려웠던 것은 아무래도 서버의 비용, 즉 금액적인 부분이 뇌리에 계속 맴돌수밖에 없었습니다. 아마존과 같은 대형 서비스를 사용하다가 몇 백만원이 넘는 비용이 부과되었다는 이야기도 있고 트래픽이나 사용량이 예상한 것 보다 높게 나와서 얻은 것 없이 돈만 나갔다는 이야기를 들었기 때문에 안정적인 수익이 없는 상태에서 조심스러울 수 밖에 없었습니다. 이런 저런 정보를 찾아보다가 가상 호스팅 서버를 지원하는 카페 24를 발견했고 생각보다 저렴한 가격과 국내 지원 정책 때문에 선택을 안할 수 없었습니다. 다만 가장 문제였던 것은 익숙하지 않은 리눅스 기반 서버를 사용해야한다는 것이었습니다. 윈도우 서버의 경우 

월 2만5천원 가량이 부가되고 리눅스 서버는 월 5천원 정도의 가격으로 사용할 수 있었습니다. 서버 공부 또는 실패 경험을 구매한다는 생각으로 월 5천원을 투자하기로 결심했습니다. 1년 치를 결제하고 보니 12개월 비용과 설치비용 그리고 부가세? 등 9만원 정도 결제한 것 같습니다.

 

서버 설정

처음 서버를 설정하면서 가장 우려되었던 것은 해커들의 공격이었습니다. 사용자의 개인정보를 저장하고 있지는 않지만, 데이터를 저장하는 입장에서 내 데이터를 누군가가 몰래 가져간다는 것은 일어나서도 안되고 이후에도 항상 조심해야하는 것이기 때문에 주의깊게 살펴봤습니다. 서버가 설치되고 하루도 지나지 않아 로그에는 열려있는 포트 HTTP, SSH 등에 접근 시도가 여러차례 있었고 무차별적인 대입 공격이 위협적으로 다가왔습니다. 이러한 이유 때문에 다음과 같은 조치를 취했습니다.

1. 사용하지 않는 포트 닫기.

2. 특정 IP의 접근 제한

3. 비밀번호를 n번 틀렸을 경우의 차단

4. SSH 키 생성

5. 루트 직접 로그인 제한

지금은 SSH 접속은 현재 사용중인 컴퓨터에 저장되어있는 SSH 키를 이용한 로그인 밖에 되지 않도록 설정되어 있습니다.

 

처음 서버 연결로 실시간 통신이 필요없을 뿐더러 속도가 크게 중요하지 않기 때문에 HTTP를 이용한 통신을 고려했지만 항상 오픈되어있기 때문에 C# 닷넷 서버로 결정했습니다. 대규모 사용자에 대한 처리능력과 실시간 통신에 필요한 멀티 스레드와 트랜잭션 처리를 체득하고 싶었기 때문에 지금 생각하면 가장 잘 선택한 일이라 생각됩니다. 

 

서버 구현

처음 서버의 구현은 TCP/UDP를 이용해서 성공적으로 통신을 구현한 것 같았습니다. 하지만 1대 1환경에서만 동작할 뿐 동시에 처리되지 못하는 문제가 있었습니다. 멀티스레드에 대한 이론을 알고있다고 해도 단순히 데이터를 보내고 받는 것과 안전성과 최적화를 고려하는 것은 전혀다른 문제라는 것을 직감했습니다. 부족한 부분을 채우기위해 인프런에서 마침 할인하던 서버 구현 파트를 구매, 수강하면서 프로그래밍적 충격을 많이 받았습니다. 지금까지 해왔던 재사용에 대한 개념이 너무 큰 데이터의 재사용일 뿐 최적화에 크게 도움이 되지 않았었다는 충격에 휩쌓였습니다. 강의 안에서는 바이트 단위로 재사용성을 높였고 패킷에 대한 지식 틀을 잡을 수 있었습니다. 강의 내용을 응용하여 서버를 구현했고 직접 클라이언트와 통신해보며 안정화 시킬 수 있었습니다.

 

데이터 베이스 구현

데이터 베이스를 구현할 때에는 테이블을 어떻게 나누는 것이 가장 효율적인지에 대해 고민을 많이 했고 정규화에 대한 고민도 많이 했습니다.

기본적으로 프로젝트에 필요한 정보는 사용자 정보, 스테이지, 재화, 상품, 아이템이 있었습니다.

구글 스토어에서는 로그인 없이 콘텐츠를 살펴볼 수 있도록 만들어야 스토어에 출시가 가능했습니다. 그래서 처음 고려되었던 것은 게스트 로그인에 대한 지원이었습니다. 추 후 구글 로그인을 지원하거나 IOS 앱 스토어도 지원해야하기 때문에 확장성을 고려한 선택이 중요했고 무분별한 접근을 막기위한 대처도 필요했습니다. 이러한 고려사항을 모두 적용하니 3개의 테이블( 공급자, 사용자, 접근 )로 좁힐 수 있었습니다.

 

로그인 정보

공급자는 단순히 게스트, 구글 등으로 나뉘었습니다. 처음에는 카카오 로그인을 시도하려 했지만 이용 약관에 게임과 관련되어 사용은 불가하다는 것을 보고 시간을 많이 날렸습니다. 사용자는 공급자와 관련된 ID를 저장했습니다. 게스트로그인의 경우 최대한 중복이 없도록 UUID 버전 4를 사용하였고 기본키로 사용하기에는 데이터 크기가 크기 때문에 AI(자동 증가)를 기본키로 사용하였습니다. 또한 무분별한 접근을 막기위해 액세스 토큰을 생성하여 접근을 제한했습니다. 처음에는 JWT라는 토큰 방식을 사용하려 했으나 서버의 사양이 매우 낮기 때문에 직접 토큰을 생성하여 발급했습니다. 토큰은 사용자의 키를 기반으로 토큰과 인증 시간, 만료 시간으로 나누었습니다. 인가되지 않은 사용자는 UUID를 알고 있어도 정상적인 로그인 방식으로 로그인하지 않는 이상 토큰을 발급받을 수 없기 때문에 데이터의 접근을 성공적으로 막을 수 있습니다. 

로그인 방법에 대한 내용을 도식화한다면 다음과 같은 프로세스가 완성됩니다.

클라이언트에서는 회원가입을 요청하고 서버에서는 요청에 대한 처리를 합니다. 초기 로그인의 경우 UUID를 생성하는 과정이 있으며, UUID를 사용자가 가지고 있는 경우 AccessToken만 생성 발생합니다. 위 도식화한 그림에서 초기 유저 데이터 생성 위치가 잘못 표기되긴 했지만 보는데 불편함은 없으니 넘어가겠습니다. :) 위 이미지와 같은 흐름으로 인가된 사용자에게만 데이터를 제공하므로 보안을 고려한 설계가 완성됩니다.

 

 

재화 정보

게임내 재화는 두가지를 사용합니다. 게임 내 골드와 유료재화인 다이아를 사용하고 있고 이 또한 최소 2개의 테이블로 구성할 수 있었습니다. 재화의 정보 (재화의 타입, 재화의 이름)와 사용자가 가지고있는 재화 (유저 키, 재화 타입, 수량)로 나뉘었고 비정상 적인 접근을 확인하기 위해 재화가 변경될 때 마다 Log가 생성되도록 만들었습니다. 데이터 베이스에서는 트리거라는 아주 좋은 기능을 지원하기 때문에 매번 쿼리를 작성하지 않아도 된다는 이점이 있습니다.

아이템 정보

아이템은 무기, 목걸이, 반지 3가지를 만들었습니다. 무기는 단순히 공격력만을 가지고 있지만 강화할 수 있도록 수량과, 강화 레벨을 가지고 있습니다. 또한 목걸이와 반지에는 게임 내에서 적용 가능한 능력을 추가했습니다. 점프력, 추가 공격력, 추가 재화, 블록 감속, 기사회생, 막기 파워 등을 추가하여 재미 요소와 성장 요소를 더했습니다. 아이템에 대한 정보는 중복되지 않도록 Code로 분류하였고 기본적인 정보는 아이템 코드를 참고하여 접근 가능하도록 구현했습니다.

위에서 설명한 테이블 외에도 상품에 대한 정보, 구매내역에 대한 정보, 스테이지 정보 등 다양한 테이블을 구성하여 프로젝트에 사용되고 있습니다.

 

 

서버의 구성과 데이터베이스에 대한 내용을 마칩니다.

반응형