서버와 함께 도는 모바일 앱에서 점검을 예고하고, 점검 중에는 접속을 막고, 끝나면 옛 버전 사용자를 새 버전으로 업데이트하게 하는 흐름을 서버 쪽 기준으로 설계하는 방법입니다.
개인 게임 앱에 서버 규칙이 바뀌는 업데이트를 내보내려니, 그동안은 점검 공지도 업데이트 안내도 없었다는 걸 알았습니다. 서버만 바꾸면 옛 앱과 규칙이 어긋나고 앱만 먼저 나가도 마찬가지라, 점검 시간을 잡고 그 안에서 둘을 맞추는 장치부터 만들었습니다.
- 점검 상태와 빌드 기준은 서버가 들고 있고, 앱은 요청마다 자기 빌드 번호를 보낸다
- 점검 중에는 게임 요청을 503, 최소 빌드보다 낮은 앱의 진행 요청은 426 으로 막는다
- 이 장치가 없는 옛 앱도 기존 응답 형식 안에서 안내를 받게 따로 챙긴다
1. 왜 필요한가: 앱과 서버 규칙이 섞이면 진행이 되돌아간다
이 앱은 부정 방지를 위해 서버가 진행을 다시 계산합니다. 앱이 10초마다 진행을 보내면 서버가 같은 규칙으로 다시 계산해 보고, 결과가 다르면 앱의 진행을 서버 쪽 값으로 되돌립니다.
그래서 앱과 서버의 규칙 버전이 다르면 정상적으로 한 플레이도 서버 계산과 어긋나 되돌아갈 수 있습니다. 실제로 시험 서버만 새 규칙으로 올리고 폰에는 옛 규칙 앱이 깔린 채로 하루를 보냈더니, 그사이 산 영구 강화가 서버 기록에는 한 번도 남지 않은 일이 있었습니다. 기록이 부족해 원인을 하나로 확정하진 못했지만, 규칙 차이로 계산이 어긋나 되돌아갔을 가능성이 가장 컸습니다.
시험 서버라 고쳐 줄 수 있었지만, 운영에서 같은 일이 생기면 이용자의 진행이 사라지는 사고가 됩니다. 결국 규칙이 바뀌는 업데이트는 서버와 앱이 같은 순간에 바뀌어야 하고, 그 순간을 만드는 게 점검입니다.
2. 점검의 세 단계: 예고, 점검 중, 끝
점검은 시작과 끝 시각을 가진 한 줄짜리 기록으로 서버 DB 에 두었습니다. 서버가 두 대라 상태는 DB 가 정본이고, 서버마다 몇 초씩만 기억해 두고 다시 읽습니다.
- 예고: 예약하는 순간부터 앱 화면 위에 "10/20 03:00~04:00 점검 예정" 같은 띠가 뜨고, 하루 한 번 안내 창과 시작 10분 전 창을 띄운다
- 점검 중: 게임 요청은 503 Service Unavailable 과 함께 점검 정보를 돌려준다. 앱은 시작 5초 전에 진행을 멈추고 마지막으로 저장한 뒤 전체 화면 안내로 바꾸고, 15초마다 다시 확인한다
- 끝: 앱은 서버 상태부터 다시 받고 이어서 시작한다. 점검 동안 비운 시간은 방치 보상으로 채워 준다
점검 중에도 막으면 안 되는 길은 열어 두었는데, 운영자 화면과 헬스 체크, 앱이 점검 상태를 묻는 주소가 그렇습니다. 점검 상태를 묻는 주소까지 막으면 앱이 점검이 끝났는지 알 방법이 없어집니다.
3. 최소 빌드와 권장 빌드
업데이트 안내는 빌드 번호 두 개로 나눴습니다. 앱은 요청마다 빌드 번호와 OS 를 머리글로 보내고, 서버는 OS 별로 정해 둔 최소, 권장 빌드와 비교합니다.
- 최소 빌드보다 낮으면: 진행이 바뀌는 요청(저장, 뽑기, 우편 받기 등)을 426 Upgrade Required 로 막고, 앱은 닫을 수 없는 "새 버전이 나왔어요" 창과 스토어로 가는 단추를 띄운다
- 권장 빌드보다만 낮으면: 막지 않고 닫을 수 있는 안내를 하루 한 번만 띄운다
최소 빌드를 올리는 시점은 새 버전이 스토어에 실제로 보인 뒤여야 합니다. 스토어에 아직 없는데 최소 빌드부터 올리면, 이용자는 업데이트할 수도 없이 막히게 됩니다.
결제는 따로 생각했는데, 최소 빌드보다 낮은 앱이라도 이미 돈을 낸 결제의 지급은 막지 않았습니다. 점검 직전에 결제했다가 지급 전에 막히면 앱이 거래를 끝내지 않고 남겨 두었다가 다음에 들어올 때 다시 보내게 했습니다.
4. 이 장치가 없는 옛 앱은 어떻게 안내하나
이미 깔려 있는 옛 앱은 점검 창도 업데이트 창도 없고 빌드 번호도 보내지 않습니다. 그래서 서버는 빌드 머리글이 없으면 옛 앱으로 보고, 옛 앱이 원래 알아듣는 응답 안에 안내를 실어 보냅니다.
이 앱은 원래 서버 상태를 받으면 그대로 따르고 우편이 오면 "편지가 왔어요" 창을 띄우니, 점검 중이나 업데이트가 필요할 때는 저장하지 않은 서버 상태에 안내 글을 우편처럼 붙여 돌려줍니다. 옛 앱에는 스토어로 가는 단추가 없어 글로만 안내하는 한계가 있으니, 처음 앱을 낼 때부터 빌드 번호를 보내고 서버 응답으로 막을 수 있는 구조를 넣어 두는 게 좋습니다.
5. 정리
서버와 함께 도는 앱이라면 점검 상태와 최소, 권장 빌드를 서버가 들고, 앱은 요청마다 빌드 번호를 보내게 해 두면 점검과 강제 업데이트를 한곳에서 다룰 수 있습니다. 특히 서버가 진행을 다시 계산하는 앱은 규칙이 다른 앱과 서버가 섞이는 순간 진행이 되돌아갈 수 있으니, 점검 안에서 서버와 앱을 함께 바꾸고 최소 빌드는 스토어에 새 버전이 보인 뒤에 올리는 순서를 지키는 게 중요했습니다.
스토어에서 새 버전이 공개되는 시점을 맞추는 방법은 플레이 콘솔 관리형 게시로 심사 통과와 공개 시점 떼어 놓기에 따로 적어 두었습니다.
여기까지 모바일 앱 점검 공지와 강제 업데이트 설계에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!
