게임 결과를 저장해야 할 때 서버 구조를 함께 봅니다
이 페이지는 웹게임 제작의 보조 기준입니다. 교육용 게임, 소형 웹게임, 프로토타입에서 점수·수료·랭킹·로그를 저장해야 할 때 서버와 DB 구조를 함께 설계합니다. 저장할 데이터가 없으면 게임은 정적 파일만으로도 끝날 수 있습니다.
서버가 붙는 기준
게임을 끝낸 사용자에게 결과만 보여주고 닫는다면 서버가 없어도 됩니다. 하지만 점수, 수료 여부, 랭킹, 시도 횟수, 외부 시스템 전송처럼 나중에 다시 확인해야 할 정보가 있으면 서버와 DB가 필요합니다. 이때부터는 게임 화면 개발과 별도로 저장 구조, 권한, 보관 기간을 정합니다.
게임 서버에서 다룰 수 있는 데이터
- 사용자 ID
- 점수
- 플레이 시간
- 시도 횟수
- 완료 여부
- 랭킹
- 수료 상태
- 미션 진행률
- 다운로드 이력
- API 호출 로그
개발 가능한 백엔드 기능
- 점수 저장 API와 랭킹 조회 API
- 미션 완료, 수료 상태, 보상 지급 이력 저장
- 새로고침·중복 제출 방지와 idempotency 처리
- 비정상 점수 필터링과 서버 기준 검증
- 플레이 로그 저장과 운영 통계 집계
- 관리자 로그인, 권한, CSV 다운로드 연결
- LMS, SSO, CRM, 사내 시스템 API 연동
부정 제출 방지 설계
| 위험 | 대응 | 주의 |
|---|---|---|
| 동일 결과 반복 제출 | 토큰, 세션, 중복 키, 완료 상태 저장 | 사용자 식별 방식 필요 |
| 비정상 점수 조작 | 허용 범위 필터링, 서버 기준 검증 | 룰 검증 범위가 넓으면 비용 증가 |
| 새로고침 재전송 | idempotency 키, 제출 완료 상태 | 프론트만으로는 한계 있음 |
| 개인정보 노출 | 최소 수집, 권한, 보관 기간 설정 | 캠페인형이면 별도 운영 기준 필요 |
배포 방식
- 고객사 서버에 API/관리자 설치
- PHYSIA 호스팅에서 게임과 관리자 운영
- 정적 게임 + 별도 API 서버 구성
- 클라우드 서버와 DB 조합
- LMS/사내망/API 테스트 환경 분리
FAQ
점수만 저장해도 서버가 필요한가요?
사용자별 결과를 나중에 조회하거나 다운로드해야 한다면 서버와 DB가 필요합니다. 단순 결과 화면만 보여주는 정적 게임은 서버 없이 끝낼 수 있습니다. 저장이 필요한지 애매하면 “운영자가 나중에 무엇을 확인해야 하는가”부터 정합니다.
부정 점수 제출을 막을 수 있나요?
중복 제출 제한, 토큰/세션 검증, 허용 범위 필터링, 서버 기준 검증을 적용할 수 있습니다. 게임 룰을 서버에서 얼마나 검증할지에 따라 비용이 달라집니다. 경품이나 보상이 있으면 부정 제출 방지 기준도 더 높게 봐야 합니다.
고객사 서버에 설치할 수 있나요?
설치할 수 있습니다. 서버 OS, PHP/Node 등 런타임, DB, SSL, 방화벽, 배포 권한을 확인한 뒤 고객사 서버 또는 PHYSIA 호스팅 중 선택합니다. 내부망 배포라면 테스트 계정과 접근 방법도 함께 필요합니다.
관련 기준
