게임 서버

게임 로직이 아니라 커뮤니티 기능으로 고르세요

게임 서버는 아주 다른 두 가지 일을 합니다. 하나는 게임 자체 — 말을 옮기고, 명중을 판정하고, 세계를 일관되게 유지하는 것. 다른 하나는 게임을 둘러싼 모든 것이며, 이 두 번째 일이 초보자가 예상하는 것보다 훨씬 큽니다. 그리고 플레이어가 내일 다시 돌아올지를 결정하는 것도 이쪽입니다.

프레임 속도를 비교하기 전에, 아래 중 몇 개를 직접 만들고 보안을 챙기고 운영까지 해야 하는지 세어 보세요.

• 계정과 로그인 — 기기·이메일·Apple·Google·Steam, 그리고 그 모두를 한 플레이어로 묶어 기기가 바뀌어도 진도가 이어지게 하는 것.
• 채팅과 게시판 — 1:1·그룹·방 채팅, 재접속해도 남아 있는 대화 이력, 그리고 신고와 차단.
• 길드와 친구 — 가입 신청, 역할과 권한, 구성원 목록, 접속 상태(지금 누가 온라인인가).
• 리더보드와 토너먼트 — 일간·주간 초기화, 동점 처리 규칙, 그리고 부정 사용자를 상위권에서 걸러내는 것.
• 푸시 알림과 결제 — 에너지가 찼다고 알려주는 것, 그리고 무언가를 주기 전에 영수증이 진짜인지 검증하는 것.

Docker — 서버는 결국 이렇게 돕니다

어떤 서버를 고르든 결국 어딘가에서 돌아야 하고, 오늘날 그 어딘가는 거의 항상 컨테이너입니다. Docker 는 서버와 그것이 돌아가는 데 필요한 모든 것 — 런타임, 라이브러리, 설정 — 을 한 덩어리로 묶습니다. 그 결과로 나온 이미지 하나가 내 노트북에서든 다른 나라에 빌린 컴퓨터에서든 똑같이 동작합니다.

게임 서버에서는 이것이 다른 소프트웨어보다 더 중요합니다. 게임 백엔드는 결코 프로그램 하나가 아니기 때문입니다. 서버에 데이터베이스가 붙고 보통 캐시까지 붙으며, 이것들이 서로를 찾아 올바른 순서로 떠야 합니다. Docker 는 그 일을 설치 안내문 한 페이지에서 파일 하나와 명령 하나로 바꿉니다 — Nakama 도 SpacetimeDB 도 빠른 시작을 컨테이너로 안내하는 이유가 이것입니다.

알아야 할 네 단어

Compose — 전체 스택을 파일 하나로

게임 백엔드는 함께 떠야 하는 여러 컨테이너입니다. Docker Compose 는 그 전부 — 서버·데이터베이스·캐시 — 를 볼륨·네트워크·기동 순서와 함께 YAML 파일 하나에 적습니다. 그러면 docker compose up 한 줄로 스택 전체가 살아나고, 실제 서버에 복사하는 것도 같은 파일입니다.

오늘 밤 당장 Nakama 를 시험해 볼 수 있는 이유가 이것입니다. 공식 빠른 시작이 서비스 두 개짜리 compose 파일이고, 명령 하나면 데이터베이스가 붙은 게임 백엔드가 내 컴퓨터에서 돕니다. 시스템에 설치되는 것도 없고, 나중에 지울 것도 없습니다.

초보자가 걸려 넘어지는 세 가지

• 볼륨을 지우면 데이터베이스가 사라집니다. 볼륨까지 정리하는 옵션이 붙은 명령은 컨테이너와 함께 플레이어 데이터도 기꺼이 지웁니다. 정리 명령을 돌리기 전에 그것이 어떤 볼륨을 건드리는지 정확히 아세요 — 그리고 알기 전에 먼저 백업하세요.
• 호스트 포트 하나에 프로세스 하나입니다. 이미 무언가가 그 포트를 쥐고 있으면 두 번째 컨테이너는 그냥 기동에 실패합니다. 사이트를 여럿 돌리는 컴퓨터에서 흔한 원인이며, 해법은 포트를 열지 말고 앞단의 리버스 프록시 하나가 도메인으로 갈라 보내게 하는 것입니다.
• 안 뜨면 로그를 읽으세요. 컨테이너 실패의 대부분은 자기 로그에 이유를 적어 둡니다. 그리고 초보자 대부분은 보는 대신 짐작합니다. 로그 읽기를 마지막이 아니라 첫 번째로 하세요.

SpacetimeDB

SpacetimeDB 는 근본적으로 다른 길을 택합니다 — 데이터베이스가 곧 서버입니다. 데이터베이스와 대화하는 게임 서버를 따로 짜는 것이 아니라, 데이터베이스 안에서 도는 함수(리듀서)를 작성하고, 클라이언트는 엔드포인트를 호출하는 대신 쿼리를 구독합니다. 따로 배포할 서버 프로세스가 없고, 두 시스템 사이의 동기화 코드도 없습니다. 시스템이 하나뿐이기 때문입니다.

그래서 지속되는 세계를 만들 때 진짜로 우아하고, 구조가 단순해서 한 사람이 전체를 머리에 담을 수 있습니다. 대가는 아직 젊고 생태계가 작다는 것, 그리고 사고방식의 전환이 실제로 품이 든다는 것입니다 — 단순하지만, 이미 알고 있는 그것이 아닙니다.

Nakama 란 무엇인가

Nakama 는 Heroic Labs 가 만든 오픈소스 게임 백엔드 서버입니다. Go 로 작성되었고, 단일 바이너리 하나와 PostgreSQL 호환 데이터베이스로 배포됩니다. 네트워크 코드 라이브러리도 아니고 호스팅 플랫폼도 아닙니다 — 그 둘 사이의 계층입니다. 플레이어가 누구이고, 무엇을 가지고 있으며, 누구와 함께 놀고 있는지를 아는 쪽입니다.

설치하면 곧바로 다음을 제공합니다.

• 신원과 인증 — 기기 ID·이메일·Apple·Google·Facebook·Steam·커스텀. 하나의 계정에 여러 인증 수단을 연결해 플랫폼을 넘나듭니다.
• 스토리지 엔진 — 버전이 붙는 JSON 문서, 객체마다의 소유권과 접근 규칙. 플레이어 저장 데이터가 여기 들어갑니다.
• 소셜 — 친구, 그룹과 길드, 접속 상태, 그리고 채팅(1:1·그룹·방)과 대화 이력.
• 경쟁 — 초기화 주기를 설정할 수 있는 리더보드와 토너먼트, 그리고 속성으로 조건을 거는 매치메이커.
• 경제 — 원자적 원장 거래를 지원하는 지갑, 그리고 Apple·Google·Steam 인앱 결제 영수증 검증.
• 실시간 — WebSocket 과 rUDP 소켓, 그리고 서버 쪽 틱 루프를 직접 작성하는 권위 있는 매치 런타임.
• 런타임 모듈 — Go·Lua·TypeScript 로 서버를 확장합니다. 자신만의 RPC 를 등록하고, 내장 동작의 앞뒤에 후크를 겁니다.

실제로 좋은 점

잘 못하는 것

결정하기 전에 알아 둘 것들입니다. 감춰진 비밀이 아니라, 위에서 본 설계 선택의 결과입니다.

대안들

Nakama 와 똑같이 좋은 하나짜리 답은 없습니다. 무엇을 최적화하려는가에 따라 갈립니다. 내 어려운 문제가 무엇인지 먼저 정하고 고르세요.

결이 가장 가까운 것 — 오픈소스, 자체 호스팅 가능

관리형·상업용

• PlayFab — Microsoft 의 제품이며 이 분야에서 기능 폭이 가장 넓습니다 — LiveOps·A/B 테스트·세그먼트·분석·경제. 매치메이킹과 전용 서버를 모두 갖췄지만 Azure 에서만 돕니다. 사용량 기반 과금이고, 데이터는 내 것이 아닙니다.
• AccelByte — 엔터프라이즈급이며, 전용 서버 오케스트레이션을 직접 운영하는 유일한 경쟁자입니다. 투자를 받은 스튜디오를 겨냥한 가격입니다.
• Pragma — 라이브 서비스 게임을 위한 「백엔드 게임 엔진」을 표방합니다. 깊은 커스터마이즈, 파티와 매치메이킹, 서버 할당, 인벤토리, 성장, 배틀패스와 상점. 상업 진영에서 Nakama 와 철학이 가장 비슷한 쪽입니다.
• Photon (Fusion / Quantum) — 백엔드가 아니라 네트워킹이 먼저입니다. Quantum 의 결정론적 롤백은 경쟁 액션 게임에서 견줄 것이 없지만, 서비스가 딸린 네트워크 코드 제품이지 그 반대가 아닙니다.
• LootLocker · brainCloud · Beamable — 관리형이고 시작이 빠르며 얇습니다. LootLocker 는 매치메이킹도 서버도 없고, Beamable 은 릴레이만 하고 실시간은 외부로 넘깁니다. 게임이 백엔드를 거의 필요로 하지 않을 때 좋습니다.

어떻게 고를 것인가

• 어려운 것은 실시간 동기화이고 메타 계층은 단순하다 → Colyseus
• 지속되는 공유 세계이고, 구조를 새로 생각할 각오가 있다 → SpacetimeDB
• 신원·소셜·경제·리더보드가 필요하고 자체 호스팅을 원한다 → Nakama
• 매치마다 전용 서버 무리가 필요하다 → Agones + Open Match, 또는 Edgegap — 그 옆에 메타 백엔드를 따로 둔다
• LiveOps 도구를 만들기보다 사서 쓰고 싶다 → PlayFab 또는 Pragma
• 이미 자체 실시간 서버가 있다 → 메타 서비스만 Nakama 로 쓰는 것도 흔하고 합리적인 방식이다

자체 호스팅을 선호하고 특정 업체에 묶이는 것을 싫어한다면, 정직한 후보는 Nakama · Colyseus · 메타 계층 직접 만들기 셋입니다. Nakama 를 택하는 거래는 이렇습니다 — 크고 고집 있는 Go 바이너리 하나를 받아들이는 대신, 친구·채팅·지갑·리더보드를 만드는 여섯 달을 건너뜁니다. 물어야 할 질문은 이것입니다: 내 게임의 메타 계층이 Nakama 의 전제와 충분히 닮아서, 그것과 싸우지 않고 확장하게 될 것인가.