server

온라인 게임과 네트워크 구성

언리얼배우기 프로젝트 2025. 3. 12. 20:09

1. 온라인 게임의 종류

온라인 게임은 여러 사람이 인터넷으로 연결되어 같은 게임 콘텐츠(예: 게임 맵, 캐릭터, 스토리 등)를 함께 즐기는 게임을 말한다.
 
이런 게임은 장르(액션, RPG, 전략 등)와 상관없이, 어떻게 플레이어들이 서로 연결되고 진행되는지에 따라 크게 두 가지로 나눌 수 있는데, 바로 실시간(Sync) 방식과 비동기(Async) 방식이다.
 

 1.1 실시간 방식(Sync)

실시간 방식은 두 가지 환경에서 주로 진행된다.
 
    1. 온라인 서버(클라우드)
      • 설명: 인터넷에 있는 큰 서버(컴퓨터)에 접속해서 전 세계 플레이어와 함께 게임을 즐기는 방식이다.
      • 설명 예시: 전 세계 친구들과 줌(Zoom) 화상 회의로 축구 경기 중계를 같이 보는 것과 비슷하다. 서버가 중간에서 모든 플레이어를 연결해준다.
      • 예시: 월드 오브 워크래프트(MMO) 같은 대규모 게임. 수많은 플레이어가 한 서버에서 동시에 접속해서 같이 몬스터를 잡는 것.
    2. LAN 파티
      • 설명: 같은 네트워크(예: 같은 집, 같은 건물)에 있는 컴퓨터끼리 연결해서 소규모로 게임을 즐기는 방식이다.
      • 설명 예시: 친구들끼리 한 방에 모여서 닌텐도 스위치로 마리오 카트 하는 것과 비슷하다. 인터넷 없이도 같은 네트워크로 연결해서 게임 가능.
      • 예시: 옛날 스타크래프트 LAN 파티처럼 친구들이 각자 컴퓨터 가져와서 같은 네트워크로 연결하고 대결했다고 한다.
  • 특징 요약: 실시간 방식은 바로바로 반응하는 게 중요해서 빠른 네트워크가 필요하다. 그래서 네트워크 상태가 안 좋으면 "렉(지연)"이 걸릴 수 있.

1.2 비동기(Async) 방식

  • 특징: 플레이어들이 동시에 접속하지 않아도 게임을 진행할 수 있다. 각 플레이어의 진행이 독립적이라, 내가 플레이할 때 다른 플레이어가 없어도 상관없다.
    • 설명 예시: 친구와 편지를 주고받으며 체스를 두는 것과 비슷한 느낌이다. 내가 기물을 옮기고 편지를 보내면, 친구가 나중에 보고 답장을 보내는 식으로, 서로 동시에 체스를 둘 필요는 없는 느낌이다.
    • 예시: 크래시 오브 클랜 같은 게임. 내가 상대 마을을 공격할 때 상대 플레이어가 접속해 있지 않아도 공격 결과를 서버가 저장해서 나중에 보여줍니다.
  • 장점:
    • 네트워크가 불안정해도 괜찮다. 내가 플레이하는 동안 상대가 없어도 게임이 진행되기 때문이다.
    • 모바일 게임에서 자주 사용된다. 예를 들면, 데이터가 끊겨도 게임이 멈추지 않을 때 처럼.
  • 예시:
    1. 턴제 게임: 하스스톤 같은 카드 게임. 내가 카드를 내면 상대가 나중에 보고 반응한다.
    2. 서버 검증 기반 게임: 클래시 오브 클랜. 내가 공격한 결과만 서버에 저장하고, 상대는 나중에 결과를 확인.
  • 특징 요약: 비동기 방식은 시간 차가 있어도 게임이 진행되니까 느리거나 네트워크가 불안정해도 문제가 없다. 대신 실시간으로 반응하는 재미는 덜할 수 있다.

2. CAP 이론과 게임 동기화

2.1 CAP 이론이란?

CAP 이론에 따르면 분산 시스템은 일관성(Consistency), 가용성(Availability), 분할 용인(Partition Tolerance) 중 최대 두 가지만 완벽히 만족할 수 있다. 게임 동기화에서는 네트워크 분할(Partition)이 발생할 수 있는 환경을 기본 전제로 하므로, 실질적으로 일관성(C)과 가용성(A) 중 하나를 선택하거나 균형을 맞추는 문제가된다.
 

그렇기 때문에 CAP 이론은 분산 시스템에서 세 가지 조건을 모두 만족할 수 없다고 주장하는 이론이다.

 

  1. 일관성(Consistency): 모든 시스템이 동일한 상태를 유지.
  2. 가용성(Availability): 언제든 시스템에 접근 가능.
  3. 분할 용인(Partition Tolerance): 시스템을 분할해 병렬 처리 가능.

게임에서는 이 세 요소 중 무엇을 우선하느냐에 따라 동기화 방식이 달라진다.

2.2 옛날 동기화 방식 (CP 설계)

  • 방법: 일관성을 우선(C), 가용성 포기(A).
  • 과정:
    1. 클라이언트가 서버에 접속.
    2. 서버가 모든 클라이언트의 상태를 초기화 후 게임 시작.
    3. 클라이언트에서 이벤트(이동, 공격 등) 발생.
    4. 서버가 이벤트 수집 후 일정 주기(Round/Tick)로 브로드캐스팅.
    5. 클라이언트가 상태 업데이트.
  • 특징: 반응 속도가 느려도 괜찮은 게임(예: 턴제 게임)에 적합.
  • 예시: 스타크래프트.

이 방식이 "옛날 방식"으로 불리는 이유는 현대 게임 환경에서는 빠른 반응성(가용성)이 점점 더 중요해졌기 때문이다. 초기 게임들은 플레이어 수가 적거나 턴제 게임처럼 실시간성이 덜 중요한 경우가 많았지만, MMO, FPS 같은 대규모 실시간 게임이 등장하면서 CP 설계의 한계가 나타나게 됐다.

  • 가용성 부족: 입력과 반영 사이의 지연은 현대 플레이어의 기대(빠른 피드백)에 부합하지 않음.
  • 기술 발전: 네트워크 속도와 클라이언트 성능이 향상되며 더 유연한 설계(AP 설계)가 가능해짐.

2.2.1 실시간 게임의 진화(AP 설계)와 옛날 동기화 방식(CP 설계)의 대비

반면, AP 설계(Availability + Partition Tolerance)는 가용성을 우선하고 일관성을 나중에 보정하는 방식으로, 현대 게임에서 주로 사용된다.

 

2.3 현재 실시간 게임의 진화 (AP 설계)

  • 방법: 가용성을 우선(A), 일관성 보정(C).
  • 과정:
    1. 기본 정보(위치, 회전 등)는 짧은 주기로 브로드캐스팅.
    2. 실시간 이벤트는 별도 채널로 다중 브로드캐스팅.
  • 특징: 빠른 반응성이 중요한 MMO, FPS, 스포츠 게임에 적합.
  • 예시: 포트나이트.

3. 동기화 보정 기법

3.1 동기화 보정 기법이란?

온라인 게임에서 동기화란 여러 플레이어가 참여하는 게임의 상태(캐릭터 위치, 이벤트 등)를 모든 클라이언트와 서버 간에 일치시키는 것을 말한다. 하지만 네트워크 지연(Latency), 패킷 손실, 지터(Jitter) 같은 현실적인 제약 때문에 완벽한 동기화는 어려운데, 동기화 보정 기법은 이런 제약을 극복하거나 사용자에게 덜 불편하게 느껴지도록 문제를 "보정"하는 방법을 뜻한다.

 

이 기법들은 CAP 이론의 선택(일관성 vs 가용성)에 따라 다르게 적용되며, 크게 세 가지로 나눠볼 수 있다.

  1. 가용성 보정: 일관성을 우선하는 CP 설계에서 가용성 저하를 보완.
  2. 일관성 보정: 가용성을 우선하는 AP 설계에서 일관성 문제를 보완.
  3. 클라이언트 보간: 네트워크 불안정성을 보완해 부드러운 경험 제공.

3.2 가용성 보정 (CP 설계)

  • 의미: CP 설계는 일관성을 우선하므로, 모든 클라이언트가 서버의 브로드캐스팅을 기다려야 해서 반응 속도(가용성)가 느려진다. 이를 "보정"하기 위해 클라이언트 측에서 즉각적인 피드백을 제공하는 방식이다.
  • 예시: 스타크래프트.
  • 동작:
    1. 플레이어가 마우스를 클릭(예: 유닛 이동 명령).
    2. 서버 응답을 기다리지 않고 즉시 사운드나 이펙트로 피드백 제공 → 가용성 저하를 위장.
    3. 서버가 이벤트를 수집해 브로드캐스팅 후 클라이언트 상태 업데이트.
  • 문제: 입력과 실제 반영 사이의 시간 차(Gap).
  • 보정 방법: 대기 시간을 플레이어가 느끼지 못하게 사운드/이펙트로 "가용성" 부족을 커버.
  • 왜 보정인가?: 가용성이 약한 CP 설계의 단점을 완화해 사용자 경험을 개선.

3.3 일관성 보정 (AP 설계)

  • 의미: AP 설계는 가용성을 우선하므로, 클라이언트가 먼저 상태를 업데이트(예측)하지만 서버와의 불일치가 생길 수 있다. 이를 나중에 서버 값으로 "보정"하는 방식이다.
  • 예시: 포트나이트.
  • 동작:
    1. 클라이언트가 즉시 상태 업데이트(예: 캐릭터 이동 예측).
    2. 서버 값과 비교 후, 불일치 시 서버 값으로 조정(롤백).
  • 문제: 낮은 Latency나 네트워크 문제로 일관성이 깨짐(예: 뒤늦게 사망, 위치 튐).
  • 보정 방법: 클라이언트 예측으로 가용성을 확보한 뒤, 서버로 일관성을 맞춤.
  • 왜 보정인가?: 일관성을 희생한 AP 설계에서 발생하는 불일치를 최소화.

3.4 클라이언트 보간 (Interpolation)

  • 의미: 네트워크의 불안정성(패킷 지연, 손실 등)으로 데이터가 불규칙하게 도착할 때, 클라이언트가 이를 "보간"하여 부드럽게 표현하는 기법이다. 엄밀히 말하면 CP/AP 설계와 직접 연관되지 않고, 동기화 전반의 품질을 높이는 보조 기술이다.
  • 목적: 끊김 없는 플레이 경험 제공.
  • 과정:
    1. 서버가 일정 간격(예: 50ms)으로 데이터(위치 등) 전송.
    2. 클라이언트가 데이터를 버퍼링해 지터 보정.
    3. 보간 계산으로 중간값 생성(예: 위치 부드럽게 이동).
    4. 매 프레임(60FPS)마다 렌더링.
  • 예시: Unreal 엔진에서 자동 지원.
  • 왜 보정인가?: 네트워크 불안정으로 인한 동기화 끊김을 보완해 자연스러운 움직임 구현.

4. 비동기(Async) 게임

  • 특징: 세션 유지 어려운 환경(모바일 등)에서 사용.
  • 방법:
    • TCP 프로토콜로 보장된 데이터 전송.
    • 이벤트만 서버로 전송 후 검증 및 DB 저장.
  • 예시: 래시 오브 클랜.
  • 장점: 다른 플레이어 접속 여부와 무관, 확장성 뛰어남.

5. 채팅 서버 vs 온라인 게임 서버

5.1 유사점

  • 사용자 입력 브로드캐스팅.
  • 세션 관리 및 채널별 상태 유지.
  • 로비 기능(채널 선택, 커스터마이징 등).

5.2 차이점

  • 그래픽 표현: 게임은 그래픽으로 상태/결과 표시, 채팅은 텍스트 중심.
  • 데이터량: 채팅은 적은 데이터, 재접속 시 전체 정보 전송 가능.
  • Latency: 게임은 낮은 지연 시간 고려, 채팅은 덜 민감.

6. 네트워크 구성의 진화

온라인 게임 회사가 처음엔 작은 서버 하나로 시작해서, 점점 더 많은 플레이어를 감당하기 위해 서버를 쪼개고 기능을 나누며 커져가는 과정은 아래와 같다.

6.1 초기: 단일 서버

  • 구성: 서버 1대에 DB 포함.
  • 설명 예시: 작은 식당에서 요리사 한 명이 요리도 하고, 주문도 받고, 설거지도 하는 상황으로 모든 일을 한 사람이 다 한다.
  • 문제점: 병목(Bottleneck) 현상. 병목현상으로 인해 예를들면 손님이 10명만 와도 주문이 밀리고 요리가 늦진다. 한 사람이 다 하니까 바빠서 감당이 안 되는 것과 같다.
  • 문제 상황: 플레이어가 많아지면 서버가 느려지고 게임이 멈춤.

6.2 분리 시작

  • DB 분리: 병목(Bottleneck) 현상 완화.
  • 설명 예시: 식당에서 요리사는 요리만 하고, 주문은 따로 받는 사람을 둬서 일이 빨라졌다.
  • 로그인 서버 분리: 세션 인증 후 게임 서버 접속.
  • 설명 예시: 식당 입구에 안내원이 생겨서 손님을 확인하고 자리에 앉게 해요. 요리사가 손님 확인까지 안 해도 됨.
  • 예: 로그인 서버가 플레이어 인증(아이디/비번 체크)을 하고, 인증된 플레이어만 게임 서버로 보냄.

6.3 세분화

  • 채팅 서버 분리: 채팅 트래픽 증가 대응.
    • 설명 예시: 식당에서 손님들이 서로 떠드는 소리가 커져서, 대화 공간을 따로 만듦.
    • 예: 게임 내 채팅이 많아지자, 채팅만 처리하는 서버를 따로 둬서 게임 서버 부담 줄임.
  • 패치 서버 분리: 빈번한 업데이트 처리.
    • 설명 예시: 식당 메뉴판을 자주 바꿔야 해서, 메뉴판 관리인을 따로 둠.
    • 예: 게임 업데이트(패치)를 배포하는 서버를 따로 만들어 게임 서버가 멈추지 않게 함.
  • 게임 서버 확장: 월드/샤드 단위로 분할.
    • 설명 예시: 식당이 커져서 지점을 여러 개 만듦(예: 서울점, 부산점).
    • 예: 게임 서버를 지역별(북미, 아시아)이나 월드 단위로 나눠서 플레이어가 몰려도 괜찮게 함.

6.4 보안 및 안정성

  • 방화벽 추가: 해킹 방어.
    • 설명 예시: 식당에 경비원을 세워서 이상한 손님이 못 들어오게 막음.
    • 예: 해커가 서버를 공격하지 못하게 방화벽(보안 장치)을 설치.
  • DB 클러스터: 분산 DB(NoSQL, Replication) 도입.
    • 설명 예시: 주문 기록을 한 곳에만 두지 않고, 여러 곳에 나눠서 저장. 한 곳이 고장 나도 괜찮음.
    • 예: 데이터 저장소를 여러 대로 나눠서(DB 클러스터) 부하를 줄이고 안정성 높임.
  • 캐시 서버: DB 부하 감소(Redis, Memcached).
    • 설명 예시: 자주 주문하는 메뉴(예: 김치찌개)를 미리 만들어 놓고 바로 줌.
    • 예: 자주 쓰는 데이터를 캐시 서버에 저장해 DB에서 매번 찾지 않게 함.

6.5 통신 최적화

  • Message Queue: 서버 간 통신 안정화(RabbitMQ).
    • 설명 예시: 요리사와 서빙 직원 사이에 주문 전달 메모판을 둬서 바빠도 소통이 끊기지 않음.
    • 예: 서버들이 서로 메시지를 주고받을 때, 중간에 Message Queue를 둬서 통신이 안정적이고 순서대로 처리됨.
  • 부가 기능: 매치메이킹, 결제 서버 등 추가.
    • 설명 예시: 식당에 예약 시스템이나 결제 카운터를 따로 만듦.
    • 예: 게임에서 상대 찾기(매치메이킹)나 결제를 별도 서버로 처리.

 

네트워크 구성의 진화를 비유로 정리

  • 처음: 작은 식당 1개 → 손님 많아지면 감당 못 함.
  • 중간: 요리, 주문, 채팅 공간 나눔 → 더 효율적.
  • 나중: 지점 늘리고, 경비원 두고, 주문 기록 여러 곳에 저장 → 크고 안전한 체인점.
  • 왜 이렇게 변했나?: 플레이어가 많아지고 게임이 복잡해지니까, 서버 하나로는 못 버텨서 일을 나눈 것이다.
  • 무엇을 나눴나?: 게임 진행, 로그인, 채팅, 데이터 저장 등 각 역할을 따로 맡기게 됐다.
  • 결과: 게임이 느려지거나 멈추지 않고, 해킹도 막고, 더 많은 플레이어를 받을 수 있게 되었다.

정리한 중요한내용 3가지

  1. 플레이어 세션 동기화 기법
    • CP 설계: 게임 상태를 똑같이 유지(일관성)하지만 반응이 느림. 예: 스타크래프트.
    • AP 설계: 빠른 반응(가용성) 우선, 나중에 상태 맞춤. 예: 포트나이트.
    • 보간: 네트워크 끊김이 덜 보이게 부드럽게 움직임 보정.
      → 게임이 원활하게 느껴지도록 동기화하는 방법!
  2. 네트워크 시스템 구성
    • 처음엔 서버 1개로 다 했지만, 플레이어 많아지자 로그인, 게임, 채팅, 데이터 저장 등을 따로 서버로 나눔.
    • 점점 커져서 지역별 서버(예: 아시아 서버)로 확장하고, 보안(방화벽)과 속도(캐시)도 추가!
      → 서버를 잘 나누고 관리해서 게임이 안 멈추게 함.
  3. 네트워크 기본 용어(CAP)
    • Consistency(일관성): 모든 플레이어가 같은 게임 상태를 봄.
    • Availability(가용성): 게임이 언제나 빠르게 반응함.
    • Partition Tolerance(분할 용인): 네트워크 끊겨도 게임이 계속됨.
      → 게임이 잘 작동하려면 일관성, 가용성, 분할 용인 중 어떤걸 중요하게 할지 선택해야한다.

'server' 카테고리의 다른 글

네트워크  (0) 2025.03.12

'server'의 다른글

  • 현재글온라인 게임과 네트워크 구성

관련글

티스토리툴바