우당탕탕 개발일지

[방치RPG 서버 제작기] 3. 방치 RPG 유저 데이터 관리 (이론) 본문

Server/방치RPG 서버

[방치RPG 서버 제작기] 3. 방치 RPG 유저 데이터 관리 (이론)

devchop 2025. 4. 21. 18:18

유저 데이터 관리 구조 정리

이 게시글은 Unity와 Spring Boot 기반의 모바일 게임에서 게스트 로그인부터 유저 데이터 저장 및 검증까지 설계하는 방법을 다룬다.

처음에는 간단한 로그인 시스템이었지만, 점차 확장되어 방치형 RPG 게임에서의 골드 획득, 저장 동기화, 리셋 처리까지 포함한 구조로 발전했다.


🔑 State Sync + Plausibility Check(현실성 검증) 

방치RPG 에서는 유저의 모든 액션을 통신하기 부담스럽다. 끊임없이 재화가 자동으로 수급되는 문제가 있다. 방치형 RPG 시스템에 맞게끔 유저데이터를 관리하기 위해서, State Sync + Plausibility Check 기법을 사용하려 한다. 

1. State 중심 설계

  • 클라이언트가 현재 상태를 서버에 보내고,
  • 서버는 그 상태가 가능한지 검증한 후 저장함.

상태를 보내는 것이지, 클라이언트가 행동(Action)을 주장하는 게 아님!

2. Plausibility Check (현실성 검증)

  • 서버는 "그 변화가 가능한가?"만 판단
  • 예: 4시간 방치 보상 2만 골드? → DPS 기준으로 1.2만만 가능하다면 거절 or 조정

3. 신뢰 구간 처리

  • 정상 범위 → 저장
  • 애매한 범위 → 일부 지급 + 로그 저장
  • 비정상 → 거절 + 동기화 요구

✅ 서버 API 설계 정리

1. 유저 데이터 불러오기 (로그인 시)

  • 클라이언트 진입 시 전체 상태 로드
  • 재화, 인벤토리, 퀘스트, 미션 등 포함

2. 유저 데이터 백업 (state sync)

  • 클라이언트에서는 변경된 데이터만 발송. 
  • 해당 변화가 유효한지 검증
  • 클라이언트의 값과 다른 내용만 추려서 반환

요청 예시:

{
  "currentTime": "2025-04-21T13:00:00",
  "totalGold": 24500,
  "dps": 160,
  "lastBackupTime": "2025-04-21T08:00:00"
}

응답 예시:

{
  "result": "ok",
  "updatedFields": {
    "gold": 24500,
    "freeGachaTicket": 2
  }
}

또는 서버가 상태가 꼬였다고 판단한 경우:

{
  "result": "resync_required",
  "fullUserState": {
    "gold": 24500,
    "freeGachaTicket": 3,
    "inventory": [...]
  }
}

 


🕘 오전 9시 초기화 처리 방식

서버 측 처리:

  • lastResetDate 필드로 리셋 여부 판단
  • 요청마다 LocalDate.now().atTime(9, 0) 기준으로 비교
  • 조건 만족 시 재화 초기화 & lastResetDate 갱신

클라이언트 측 처리:

  • 클라이언트는 UI에서 시간 카운트다운만 보여줌
  • 9시 지났다고 판단되면 state-sync 요청 전송 → 서버가 판단 후 리셋 여부 포함 응답
{
  "dailyResetOccurred": true,
  "freeGachaTicket": 3
}

🎯 중요 액션 전 전체 상태 백업 구조

예: 뽑기, 강화, 인앱 결제 등

  1. 클라이언트가 먼저 state-sync 요청
  2. 서버가 최신 상태로 백업하고 검증
  3. 이후 클라이언트가 뽑기 등 액션 요청
  4. 서버는 백업 상태 기준으로 유효성 판단 후 처리

✅ 안정성 보장, 해킹 방지, 상태 꼬임 예방


❓ 의심스러운 요청이 들어왔을 때?

상황 처리 방식

살짝 과한 골드 요청 일부만 지급 + 로그 남김
매우 과한 수익 주장 거절 + resync_required 응답
클라 상태 꼬임 전체 상태 재요청 요구

🧩 전체 구조 요약

항목 설명

클라는 전체 상태를 서버에 보냄 전체 상태 = 골드, 장비, 티켓 등
서버는 이전 백업 상태와 비교 수익량 계산, 시간 경과 등 기반 검증
이상 없음 → 저장 + 수정된 데이터만 응답 성능 최적화
문제 있음 → 부분 지급 or 전체 재동기화 요구 신뢰성 보장
중요한 액션 전엔 반드시 state-sync 뽑기, 강화, 결제 등 전제조건

이런 설계를 통해 서버 비용, 보안, 데이터 무결성을 모두 잡을 수 있고, 특히 방치형/모바일 RPG에서 운영 안정성과 유저 신뢰도를 동시에 확보할 수 있다. 이 구조를 바탕으로 다음엔 실제로 유저 데이터를 관리하는 API를 만들어보자.