모범답안 — 게임서버 기본 구조: 클라-서버, 룸/세션, 게이트웨이

난이도: 하

핵심 답변

클라-서버 vs P2P: 클라-서버는 모든 클라이언트가 중앙 서버에 연결되고, 서버가 게임 상태의 "진실(authority)"을 가진다. P2P는 클라이언트끼리 직접 통신한다. 온라인 게임은 보통 권위 서버 방식을 쓰는데, (1) 치팅 방지(클라이언트는 신뢰 불가), (2) 일관된 상태 관리, (3) NAT/방화벽 문제 회피, (4) 영속 데이터(계정/아이템) 관리가 필요하기 때문이다.
세션(session): 한 플레이어의 "접속 단위" 상태. TCP 연결(소켓), 인증된 계정 정보, 현재 상태를 묶어 서버가 메모리에 들고 있는 객체. 보통 로그인 시 생성되고 접속 종료 시 파기된다.
룸(room): 함께 게임을 하는 플레이어들의 묶음(매치/방). 매칭이 성사되면 생성되고, 게임이 끝나면 해체된다. 세션보다 수명이 짧다.
게이트웨이(gateway): 클라이언트의 외부 진입점. 인증, 연결 관리, 패킷 라우팅, 부하 분산을 담당하고 내부 로직 서버를 외부에 직접 노출하지 않는다.

깊이 있는 설명 (왜, 트레이드오프)

왜 권위 서버인가. P2P는 서버 비용이 거의 없고 지연이 낮을 수 있지만, "누구의 상태가 맞는지"를 정할 주체가 없다. 한 클라이언트가 "내 HP는 9999"라고 우기면 막을 방법이 없다(메모리 조작/패킷 위변조). 권위 서버는 클라이언트 입력을 **명령(intent)**으로만 받고 결과는 서버가 계산·판정하므로, 클라이언트 데이터를 전혀 신뢰하지 않아도 된다. 대신 서버 비용·서버 한 홉 추가로 인한 지연·서버 장애 시 전원 영향이라는 비용을 진다.

세션과 연결(connection)은 다르다. 연결은 TCP 소켓 같은 물리적 통로이고, 세션은 그 위에 얹힌 논리적 사용자 상태다. 모바일 게임처럼 네트워크가 불안정하면 소켓은 끊겼다 붙어도 세션은 짧게 유지하다가(재연결 토큰으로 복구) 타임아웃되면 정리하는 식으로 분리 설계한다. 이렇게 해야 "잠깐 끊겼다고 게임에서 즉시 튕기는" 문제를 피한다.

책임 분리의 트레이드오프. 인증·매칭·게임 로직을 한 프로세스에 넣으면(모놀리식) 개발/배포가 단순하고 내부 통신 비용이 없다. 분리하면 각 부분을 독립적으로 확장(scale-out)하고 배포할 수 있으며 장애 격리가 된다. 하지만 프로세스 간 통신·상태 공유·운영 복잡도가 늘어난다. 초기에는 합쳐 시작하고 트래픽이 커지면 게이트웨이/매칭/게임 서버를 분리하는 것이 현실적이다.

응용/실무 연결 (게임서버에서)

시나리오의 권장 흐름 예시:

클라이언트 → 게이트웨이/로그인 서버: 계정 인증. 성공 시 세션 토큰 발급, 세션 객체 생성.
클라이언트 → 매칭 서버: "매칭 요청". 매칭 서버가 대기열에서 4명을 묶어 룸 배정.
매칭 서버 → 게임(룸) 서버: 빈 룸 인스턴스 생성 또는 여유 있는 게임 서버에 룸 할당. 게임 서버 접속 정보(주소/룸ID/입장 토큰)를 클라이언트들에게 통보.
클라이언트 → 게임 서버: 입장 토큰으로 룸에 입장, 대전 진행.
게임 종료 → 룸 해체, 결과를 결과/DB 서버에 기록, 클라이언트는 로비로 복귀.

세션은 이 전 과정에서 토큰으로 식별되어 유지되고(게이트웨이 또는 별도 세션 스토어가 보관), 룸은 3~5단계에서만 존재한다. 게임 서버 하나가 여러 룸을 동시에 호스팅하므로 "룸 = 가벼운 논리 객체, 게임 서버 = 그것을 돌리는 프로세스"로 구분하면 좋다.

흔한 오답·함정

"세션 = TCP 연결"이라고 단정: 연결과 세션은 분리해야 재연결/이동 처리가 가능하다.
"P2P가 무조건 나쁘다": 격투/소규모 대전 등 지연이 극도로 중요한 일부 장르는 P2P + 결정론적 락스텝(deterministic lockstep)을 쓰기도 한다. 다만 치팅·동기화 한계가 명확하다.
게이트웨이를 단순 프록시로만 이해: 게이트웨이는 인증·세션 라우팅·연결 수 흡수(수만 연결)·내부망 보호 같은 핵심 역할을 한다.
모든 것을 처음부터 마이크로서비스로 쪼갬: 초기 과설계는 운영 부담만 키운다.

꼬리질문 대비