6/24/2026 개발일지

    안녕하십니까 쳇바퀴 스튜디오입니다. 2026년 6월 24일 개발일지를 작성하겠습니다. 우선 체험판 출시는 상점 페이지 검토를 거쳐 빌드 파일 검증 단계에 들어갔습니다. 곧 출시되어 여러분께 선보일 수 있습니다. 체험판 이외로는 현재 네트워크 작업들을 하고 있습니다. 아래에서 자세한 내용을 보여드리겠습니다.

   우선 Firebase라는 구글의 Backend-as-a-Service(BaaS)플랫폼에 가입하여, 백엔드 서비스를 비교적 쉽게 구현할 수 있도록 했습니다. 한 번의 도전이 끝나고 점수가 산정될 때마다 Firestore서버에 점수를 전송하여, 랭킹의 점수가 등록되도록 구현했습니다. 

 

   사실상 이번 개발일지는 시각적으로 보여드릴 사항들이 많이 없습니다. 왜냐하면 백엔드 작업과 처음 써 보는 Firebase를 프로젝트에 적용하는 시행착오가 많았기 때문입니다. Firebase로 선택한 이유를 말씀드리겠습니다. Firebase는 다른 프로젝트들은 사용자 수에 따라서 비용이 부과되는데 반해, Firebase는 서버에 쓰기, 읽기 명령 횟수에 따라서 비용이 부과됩니다. 제 게임은 한 유저가 MMORPG처럼 서버와 수천수만번의 읽기쓰기 행동을 하지 않기 때문에 명령 횟수에 따라서 비용을 내어야 더 경제적이라고 판단했기 때문입니다. 다음으로 기술적으로 Firebase를 효율적으로 쓰기 위해 했던 노력들을 설명드리겠습니다.

    제 게임의 주된 목적은 주간으로 리더보드가 갱신되는 것입니다. 원초에는 하나의 Collection이 유일한 리더보드이며, 매 주 어떠한 시각마다 해당 콜렉션의 모든 데이터를 삭제하는 걸 생각했습니다. 왜냐하면 Firebase와 네트워크에 대한 지식이 전무했기 때문입니다. 하지만 이는 쉽게 Collection을 변경하는 것으로 구현될 수 있었습니다. 위 사진과 같이 2026년 26번째 주의 리더보드동안의 문서들을 저장하고, 27번째 주가 된다면 2026년 27번째 주의 Collection을 생성해서 그 안에 점수 기록을 전송하면 된다는 것을 깨달았습니다.

    게임이 오프라인 상황에서도 문제없이 실행되고, 오프라인에서 이뤄낸 결과물들이 추후에 온라인일 때 서버에 정상적으로 전송되는 것을 원했습니다. 따라서 로그인 작업과 점수를 전송할 때 여러가지 처리를 했습니다. [하지만 지금부터 기술되는 부분은 완벽한 테스트가 된 상태에서 기록되는 부분이 아닙니다. 추후 문제가 생겨 현재 기록과 달라지는 경우에는 아래 부분에 대한 검열이 필요합니다.] 대부분의 상황에서 FirebseFirestoreSettings의 PersistenceEnabled를 키는 것으로 오프라인 상황에서의 문제는 해결되었습니다. 왜냐하면 이 설정이 오프라인일 때의 AddAsync 명령어를 통해 서버에 쓰기 작업을 하는 것을 Queue에 저장하여 온라인이 되었을 때 알아서 쓰기 작업을 해주도록 지원해주는 설정이었기 때문입니다. 하지만 이 상태로는 다음과 같은 2가지 문제가 있었습니다. 

1.  오프라인 상태에서 시작해도, 온라인으로 변경할 수 있는 시점에서 프로그램이 자체적으로 서버와 연결하려는 노력을 하지 않는 문제
2.  서버에 회원가입이 되어있지 않은 상태로(Credential이 확보되지 않은 상태) AddAsync명령자체를 호출할 수 없기 때문입니다. 왜냐하면 서버에 전송하기 위해 로그인 정보가 필요한데, 회원가입조차 하지 못한 상태에선 유효안 로그인 정보를 얻을 수 없기 때문입니다. 이외로도 Firestore내부적으로도 유효하지 않은 회원 정보로 오프라인 상황을 대처할 수 없습니다.

    위 두 상황을 해결하기 위해서 다음과 같은 노력을 했습니다.

1.  내부적으로 서버에 접속하려고 할 때마다 로그인을 다시 시도합니다. 결과적으로 오프라인 상태에서 시도해도, 서버에 접속하려는 타이밍에 온라인이 된다면 리더보드에 정상적으로 점수가 기록됩니다.
2.  게임 내에서 점수들을 기록하여, 추후에 로그인에 성공하게 된다면 이 기록들을 전송하도록 했습니다. 이를 구현하기 위해서 게임이 시작부터 천년동안 오프라인 상태로 계속 플레이할 시, 점수 데이터가 끊임없이 게임에 쌓이게 되는 문제가 생겼지만, 쌓이는 점수 데이터들이 거대하지도 않고 이러한 경우는 희귀하다고 생각했기 때문에 PlayerRefs를 사용한 내부기록으로 달성할 수 있었습니다.

 

 

   이 뿐만 아니라 자체적으로 FireBase의 읽기 쓰기 토큰을 아껴쓰기위해 매 번 FireBase에 접속하는 것을 막고 내부적인 개인기록들을 저장하고 이들을 수정하다가 꼭 필요한 타이밍에 서버에 쓰기명령을 하는 방식을 채택했습니다. 한 플레이어가 그 주에 리더보드에 상위 6개의 개인기록을 기록할 수 있습니다만 이를 위해 매 번 FireBase의 개인기록 최대 6가지를 읽어야하는 상황을 모면할 수 있었습니다. 결과적으로 매 번 (최악의 상황일 때) 6읽기, 2쓰기(기존 기록 삭제, 신기록 갱신)에서 맨 처음 6읽기와 매 번 2쓰기로 개선할 수 있었습니다. 물론 내부적인 개인기록과 서버에 존재하는 기록 사이에 불일치가 생길 수도 있지만, 이를 방지하기 위한 노력들이 프로그램 내부에 존재합니다. 그럼에도 문제가 생긴다면, 추후 개선토록 하겠습니다.

 

    마지막으로 보안에 대해 노력한 점들을 말씀드리겠습니다. 치트를 사용한 유저가 999999점을 상단에 줄세우는 것을 방지하기 위해 다음과 같은 노력들을 했습니다. XOR obfuscation기법을 채택한 데이터 변수를 사용하여 점수가 쉽게 조작되지 않기 위해 노력했습니다. 또한, 서버에 전송되기 직전에 내부적으로 점수를 검산하여 이 정보가 조작된지 아닌지를 판단하는 노력을 했습니다. 그럼에도 불구하고 정보점수가 조작될 수 있고, 이를 방지하기 위한 노력은 검산단계를 서버에서 진행하는 것이라고 생각합니다만, 이는 추가적인 비용이 발생하기 때문에 진행하지 않았습니다. 추후에 문제가 생긴다면, 보안에 대한 추가적인 노력을 해보겠습니다.

 

 

 

    이번주에는 보여드릴 새로운 이미지도 없고, 기술적인 말들이 너무 많았습니다. 죄송합니다. 다음 개발일지에는 프로토타입 버전의 리더보드를 보여드릴 수 있도록 노력하겠습니다. 항상 쳇바퀴 스튜디오에 대한 많은 관심 감사합니다. 언제든지 디스코드에 참여하여 의견 공유해주시면 감사드리겠습니다.