💭회고

오늘은 게임 시스템에서 플레이어 세션 동기화 원리, 네트워크 시스템의 구성 및 진화 과정, 그리고 네트워크 기본 용어에 대해 학습했다. 온라인 게임 네트워크는 단순해 보이지만, 실제로는 매우 복잡한 구성과 다양한 동기화 기법을 사용한다. 게임 개발에서는 실시간 동기화와 비동기 방식, 그리고 클라이언트 예측 및 보간 기법 등을 통해 원활한 게임 플레이를 구현한다.

🗺️마인드맵

📒학습 내용

1. 온라인 게임 네트워크의 기초 개념

1.1 온라인 게임의 종류

온라인 게임은 여러 사용자가 하나의 콘텐츠를 공유하는 게임이다. 게임은 아래 두 가지 방식으로 구분된다.

  • 동기(Sync) 방식 🔄
    • 실시간으로 게임 상태를 모든 플레이어에게 동기화한다.
    • FPS나 액션 게임에서 주로 사용하며, 모든 플레이어의 행동이 즉시 반영된다.
  • 비동기(Async) 방식 ⏱️
    • 실시간 동기화 없이 이벤트 기반으로 게임 상태를 처리한다.
    • 모바일 게임(예: 크래시 오브 클랜)에서 주로 사용하며, 네트워크 연결 불안정 시에도 안정적으로 운영된다.

실무 팁: 게임의 장르와 타겟 플랫폼에 따라 적합한 네트워크 방식을 선택한다. 모바일 게임은 불안정한 네트워크 상황에 대비해 비동기 방식을, 경쟁 액션 게임은 실시간 반응을 위해 동기 방식을 사용한다.

1.2 CAP 이론 : 온라인 게임 설계의 기본 원칙

CAP 이론은 분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 용인(Partition Tolerance) 세 가지 특성을 동시에 만족시킬 수 없다고 설명한다.

  • 일관성(Consistency, 같은 상태 유지)
    모든 클라이언트가 동일한 게임 상태를 유지한다.
  • 가용성(Availability, 언제든 접근 가능)
    플레이어의 입력에 빠르게 반응하여, 게임의 연속성을 유지한다.
  • 분할 용인(Partition Tolerance, 시스템 분할 처리)
    서버를 여러 개로 분산하여 많은 플레이어를 수용하고 장애 발생 시 대응한다.

CAP 이론에 따르면 세 가지 중 최대 두 가지만 동시에 만족할 수 있다. 게임 개발자는 네트워크의 기본 전제인 분할 용인성을 고려한 후, 일관성 또는 가용성 중에서 선택한다.

설계 방식  설명 게임 예시
CP 설계 일관성과 분할 용인을 우선하여 안정적인 게임 상태를 유지한다. 스타크래프트, 하스스톤 등
AP 설계 가용성과 분할 용인을 우선하여 빠른 입력 반응을 구현한다. 포트나이트 등 FPS, 액션 게임들

실무 팁: 게임 특성에 따라 CP 설계와 AP 설계를 적절히 선택해야 한다. 예를 들어, 전략 게임은 CP 설계를, FPS 게임은 AP 설계를 사용한다.

2. 게임에서의 동기화 방법

온라인 게임의 동기화 방법은 플레이어의 입력과 서버의 데이터 처리 방식에 따라 다양하게 구분된다.

2.1 CP 설계: 일관성 우선 게임

CP(Consistency + Partition Tolerance) 설계는 일관성을 우선시한다. 대표 게임으로 스타크래프트, 하스스톤, 체스 등이 있다.

CP 설계 동작 방식:

  1. 플레이어가 입력(예: 마린 이동)을 한다.
  2. 클라이언트는 즉시 피드백(사운드, 이펙트)을 주고, 서버에 이벤트를 전송한다.
  3. 서버는 일정 시간(예: 0.333초~X초) 동안 이벤트를 모아 모든 클라이언트에 브로드캐스팅한다.
  4. 각 클라이언트는 서버 데이터를 받아 게임 상태를 업데이트한다.

실무 팁: CP 설계에서는 입력과 실제 게임 반응 사이의 지연을 최소화하기 위해 시각적/청각적 피드백을 강화한다.

2.2 AP 설계: 가용성 우선 게임

AP(Availability + Partition Tolerance) 설계는 가용성을 우선시한다. FPS나 액션 게임에서 주로 사용하며, 플레이어 입력에 즉시 반응하는 특징이 있다.

 

AP 설계 동작 방식:

  1. 플레이어가 입력을 한다.
  2. 클라이언트는 클라이언트 예측을 통해 화면을 즉시 업데이트한다. (미리 계산하여 예측하는 기법)
  3. 동시에 서버에 이벤트를 전송한다.
  4. 서버는 이벤트를 처리 후 결과를 모든 클라이언트에 전송한다.
  5. 각 클라이언트는 서버 데이터와 예측값을 비교, 차이가 있을 경우 서버 보정을 한다.

실무 팁: 클라이언트 예측 알고리즘의 정확성이 게임 경험에 큰 영향을 미치므로, 언리얼 엔진의 기본 예측 시스템을 게임 특성에 맞게 세밀하게 조정한다. 예측이 정확할수록 서버 보정 시 발생하는 "튕김" 현상이 줄어든다.

2.3 클라이언트 보간(Interpolation) 기법

네트워크는 우리가 생각하는 것보다 훨씬 불안정하다. 1/20초마다 서버에서 데이터를 보내도, 클라이언트에서 정확히 1/20초 간격으로 받지 못한다. 이를 네트워크 지터(Network Jitter, 패킷 도착 시간의 변동)라고 한다.네트워크 지터(데이터 전송 간격의 불규칙성) 문제를 해결하기 위해 클라이언트는 보간 기법을 사용한다.

 

보간 기법 동작 방식:

  1. 서버는 일정 간격(예: 50ms)마다 캐릭터의 위치 데이터를 전송한다.
  2. 클라이언트는 데이터를 바로 적용하지 않고, 약간의 지연(예: 100ms)을 두고 버퍼에 저장한다.
  3. 두 위치 값 사이를 시간 비율에 따라 계산(보간)한다.
  4. 매 프레임마다 계산된 중간 위치를 표시하여 부드러운 움직임을 구현한다.

실무 팁: 보간 버퍼의 크기는 게임 장르에 따라 조정해야 한다. FPS 게임은 작은 버퍼를, 시각적 부드러움이 중요한 게임은 큰 버퍼를 사용한다. (대부분의 액션 게임에서 100-150ms 정도의 보간 버퍼가 적절하다고 한다.)

2.4 비동기(Async) 방식

모바일 게임 등 네트워크 연결이 불안정한 환경에서는 비동기 방식을 사용한다.

비동기 방식 동작 방식:

  1. TCP 프로토콜(데이터 전송 안정성을 보장하는 통신 규약)을 사용한다.
  2. 사용자의 이벤트만 서버로 전송하고, 서버는 이벤트를 검증 후 데이터베이스에 저장한다.
  3. 다른 플레이어의 접속 여부와 무관하게 게임을 진행한다.

💡비동기 방식은 서버 부하를 줄이는 데 유리하나, 실시간 상호작용이 중요한 게임에는 적합하지 않으므로 게임 특성에 맞게 선택한다.

3. 채팅 서버와 온라인 게임 서버 비교

채팅 서버와 온라인 게임 서버는 기본 원리에서 유사한 점이 많다. 과거 1978년 MUD에서 시작된 기술은 오늘날의 게임 서버에도 그대로 적용된다.

3.1 유사점

  • 사용자 입력을 전체 사용자에게 브로드캐스팅한다.
  • 사용자의 세션(접속 상태)을 관리한다.
  • 채널(서버) 별로 서로 다른 상태 정보를 가진다.
  • 로비 시스템(채널 선택, 아바타 커스터마이징, 친구 목록 등)을 제공한다.

3.2 차이점

  • 그래픽 표현: 게임은 채팅보다 복잡한 그래픽 표현을 필요로 한다.
  • 승패 판정: 게임은 승패와 성공/실패가 명확하지만, 채팅은 그러하지 않다.
  • 데이터 처리: 채팅은 데이터 양이 적어 재접속 시 모든 정보를 다시 받을 수 있으나, 게임은 그렇지 않다.
  • 지연 시간 고려: 게임 서버는 낮은 지연 시간(Latency)을 고려해야 한다.

💡간단한 온라인 게임 프로토타입을 제작할 때, 채팅 시스템을 먼저 구현하고 그래픽 레이어를 추가하는 방식으로 개발을 진행하면 효율적이다.

4. 온라인 게임 서버 구성의 진화 과정

게임 서비스가 성장함에 따라 서버 구성은 단일 서버에서 고도화된 분산 시스템으로 진화한다.

4.1 초기 구성 – 단일 서버

소규모 게임은 하나의 서버에서 모든 기능(게임 로직, 데이터베이스 등)을 처리한다.
하지만 사용자 수 증가 시 병목 현상이 발생한다.

4.2 기본 분리 – DB 서버와 게임 서버

가장 먼저 데이터베이스(DB) 서버를 분리하여 게임 서버의 부하를 줄인다.

4.3 기능별 분리 – 로그인, 채팅, 패치 서버

사용자 수가 증가하면 각 기능별로 서버를 분리한다.

  • 로그인 서버: 사용자 인증과 세션 관리를 담당한다.
  • 채팅 서버: 플레이어 간 메시지 교환을 처리한다.
  • 패치 서버: 게임 업데이트 파일 배포(CDN)를 담당한다.

4.4 확장 단계 – 월드 샤딩, 로드 밸런싱, 보안 강화

서비스 성장에 따라 서버 증설이 필요해진다.

  • 게임 서버 샤딩(Sharding): 월드나 리전별로 서버를 분할한다.
  • 로드 밸런서(Load Balancer): 트래픽을 여러 서버에 분산하여 장애 발생 시 대응한다.
  • 방화벽: 해킹 시도를 차단한다.

4.5 고도화 단계 – DB 클러스터링, 캐시 서버, 메시지 큐

대규모 서비스에서는 DB 하나로는 감당할 수 없으므로 고급 기술을 적용한다.

 

분산DB 동기화를 위해 잦은 사용을 대신해 줄 수 있는 솔루션 : 메모리 캐쉬 서버(Redis, Memcached)
채팅 서버와 게임 서버 등 서버 간의 통신이 소실되는 경우가 생기는데, 한쪽 서버가 과부하가 걸려서 못 받는 경우 또는 사용자에게 전체 메시지를 보내야 하는 경우 등을 위해 Message Queue (RabbitMQ)를 적용

  • DB 클러스터링: NoSQL이나 Active-Active Replication을 통해 데이터베이스를 분산한다.
  • 캐시 서버(Redis, Memcached): 자주 사용하는 데이터를 메모리에 저장하여 DB 부하를 줄인다.
  • 메시지 큐(RabbitMQ): 서버 간 안정적인 통신을 보장한다.

🟣오늘의 옵시디언 현황

'Dev. > 게임 네트워크' 카테고리의 다른 글

[TIL_250311_1] 네트워크 개념 이해 2  (0) 2025.03.11
[TIL_250310] 네트워크 개념 이해  (0) 2025.03.10

티스토리툴바