게임 서버
서버는 게임 로직만이 아닙니다. 플레이어가 누구이고 누구와 함께 노는지가 전부 여기 있습니다.
많은 사람이 게임 서버를 고를 때 「내 게임 규칙을 충분히 빠르게 돌릴 수 있는가」부터 묻습니다. 그것은 첫 질문으로 틀렸습니다. 여섯 달 뒤 시간을 잡아먹는 것은 규칙이 아니라 계정·친구·길드·채팅·리더보드·푸시 알림·영수증입니다. 그것들을 이미 가진 서버를 고르거나, 직접 만들 각오를 하십시오.
게임 서버는 아주 다른 두 가지 일을 합니다. 하나는 게임 자체 — 말을 옮기고, 명중을 판정하고, 세계를 일관되게 유지하는 것. 다른 하나는 게임을 둘러싼 모든 것이며, 이 두 번째 일이 초보자가 예상하는 것보다 훨씬 큽니다. 그리고 플레이어가 내일 다시 돌아올지를 결정하는 것도 이쪽입니다.
프레임 속도를 비교하기 전에, 아래 중 몇 개를 직접 만들고 보안을 챙기고 운영까지 해야 하는지 세어 보세요.
<b>계정과 로그인</b> — 기기·이메일·Apple·Google·Steam, 그리고 그 모두를 한 플레이어로 묶어 기기가 바뀌어도 진도가 이어지게 하는 것. <b>채팅과 게시판</b> — 1:1·그룹·방 채팅, 재접속해도 남아 있는 대화 이력, 그리고 신고와 차단. <b>길드와 친구</b> — 가입 신청, 역할과 권한, 구성원 목록, 접속 상태(지금 누가 온라인인가). <b>리더보드와 토너먼트</b> — 일간·주간 초기화, 동점 처리 규칙, 그리고 부정 사용자를 상위권에서 걸러내는 것. <b>푸시 알림과 결제</b> — 에너지가 찼다고 알려주는 것, 그리고 무언가를 주기 전에 영수증이 진짜인지 검증하는 것.
어떤 서버를 고르든 결국 어딘가에서 돌아야 하고, 오늘날 그 어딘가는 거의 항상 컨테이너입니다. Docker 는 서버와 그것이 돌아가는 데 필요한 모든 것 — 런타임, 라이브러리, 설정 — 을 한 덩어리로 묶습니다. 그 결과로 나온 이미지 하나가 내 노트북에서든 다른 나라에 빌린 컴퓨터에서든 똑같이 동작합니다.
게임 서버에서는 이것이 다른 소프트웨어보다 더 중요합니다. 게임 백엔드는 결코 프로그램 하나가 아니기 때문입니다. 서버에 데이터베이스가 붙고 보통 캐시까지 붙으며, 이것들이 서로를 찾아 올바른 순서로 떠야 합니다. Docker 는 그 일을 설치 안내문 한 페이지에서 파일 하나와 명령 하나로 바꿉니다 — Nakama 도 SpacetimeDB 도 빠른 시작을 컨테이너로 안내하는 이유가 이것입니다.
알아야 할 네 단어
Compose — 전체 스택을 파일 하나로
게임 백엔드는 함께 떠야 하는 여러 컨테이너입니다. Docker Compose 는 그 전부 — 서버·데이터베이스·캐시 — 를 볼륨·네트워크·기동 순서와 함께 YAML 파일 하나에 적습니다. 그러면 docker compose up 한 줄로 스택 전체가 살아나고, 실제 서버에 복사하는 것도 같은 파일입니다.
오늘 밤 당장 Nakama 를 시험해 볼 수 있는 이유가 이것입니다. 공식 빠른 시작이 서비스 두 개짜리 compose 파일이고, 명령 하나면 데이터베이스가 붙은 게임 백엔드가 내 컴퓨터에서 돕니다. 시스템에 설치되는 것도 없고, 나중에 지울 것도 없습니다.
초보자가 걸려 넘어지는 세 가지
<b>볼륨을 지우면 데이터베이스가 사라집니다.</b> 볼륨까지 정리하는 옵션이 붙은 명령은 컨테이너와 함께 플레이어 데이터도 기꺼이 지웁니다. 정리 명령을 돌리기 전에 그것이 어떤 볼륨을 건드리는지 정확히 아세요 — 그리고 알기 전에 먼저 백업하세요. <b>호스트 포트 하나에 프로세스 하나입니다.</b> 이미 무언가가 그 포트를 쥐고 있으면 두 번째 컨테이너는 그냥 기동에 실패합니다. 사이트를 여럿 돌리는 컴퓨터에서 흔한 원인이며, 해법은 포트를 열지 말고 앞단의 리버스 프록시 하나가 도메인으로 갈라 보내게 하는 것입니다. <b>안 뜨면 로그를 읽으세요.</b> 컨테이너 실패의 대부분은 자기 로그에 이유를 적어 둡니다. 그리고 초보자 대부분은 보는 대신 짐작합니다. 로그 읽기를 마지막이 아니라 첫 번째로 하세요.
PES 는 Compose 파일 하나에 적힌 컨테이너 넷입니다 — 웹앱, PostgreSQL, 실시간을 맡는 Centrifugo, 그리고 Redis. 그 앞에 HTTPS 를 종단하는 공용 리버스 프록시가 있습니다. 변경을 배포하는 일은 코드를 올리고 서비스 하나를 다시 빌드하는 것입니다. 게임 서버를 위해 Docker 를 배우면, 앞으로 만들 다른 모든 것을 배포하는 법도 함께 배운 셈입니다.
SpacetimeDB 는 근본적으로 다른 길을 택합니다 — 데이터베이스가 곧 서버입니다. 데이터베이스와 대화하는 게임 서버를 따로 짜는 것이 아니라, 데이터베이스 안에서 도는 함수(리듀서)를 작성하고, 클라이언트는 엔드포인트를 호출하는 대신 쿼리를 구독합니다. 따로 배포할 서버 프로세스가 없고, 두 시스템 사이의 동기화 코드도 없습니다. 시스템이 하나뿐이기 때문입니다.
그래서 지속되는 세계를 만들 때 진짜로 우아하고, 구조가 단순해서 한 사람이 전체를 머리에 담을 수 있습니다. 대가는 아직 젊고 생태계가 작다는 것, 그리고 사고방식의 전환이 실제로 품이 든다는 것입니다 — 단순하지만, 이미 알고 있는 그것이 아닙니다.
Nakama 는 Heroic Labs 가 만든 오픈소스 게임 백엔드 서버입니다. Go 로 작성되었고, 단일 바이너리 하나와 PostgreSQL 호환 데이터베이스로 배포됩니다. 네트워크 코드 라이브러리도 아니고 호스팅 플랫폼도 아닙니다 — 그 둘 사이의 계층입니다. 플레이어가 누구이고, 무엇을 가지고 있으며, 누구와 함께 놀고 있는지를 아는 쪽입니다.
설치하면 곧바로 다음을 제공합니다.
신원과 인증 — 기기 ID·이메일·Apple·Google·Facebook·Steam·커스텀. 하나의 계정에 여러 인증 수단을 연결해 플랫폼을 넘나듭니다. 스토리지 엔진 — 버전이 붙는 JSON 문서, 객체마다의 소유권과 접근 규칙. 플레이어 저장 데이터가 여기 들어갑니다. 소셜 — 친구, 그룹과 길드, 접속 상태, 그리고 채팅(1:1·그룹·방)과 대화 이력. 경쟁 — 초기화 주기를 설정할 수 있는 리더보드와 토너먼트, 그리고 속성으로 조건을 거는 매치메이커. 경제 — 원자적 원장 거래를 지원하는 지갑, 그리고 Apple·Google·Steam 인앱 결제 영수증 검증. 실시간 — WebSocket 과 rUDP 소켓, 그리고 서버 쪽 틱 루프를 직접 작성하는 권위 있는 매치 런타임. 런타임 모듈 — Go·Lua·TypeScript 로 서버를 확장합니다. 자신만의 RPC 를 등록하고, 내장 동작의 앞뒤에 후크를 겁니다.
이 페이지는 Nakama 를 여러 선택지 가운데 하나로 가르칩니다. 이 사이트 자체는 SvelteKit · PostgreSQL · Centrifugo · Redis 로 돌아가며 Nakama 를 쓰지 않습니다. 우리가 쓰는 기술이 아니라 하나의 도구를 설명하는 것입니다.
결정하기 전에 알아 둘 것들입니다. 감춰진 비밀이 아니라, 위에서 본 설계 선택의 결과입니다.
Nakama 와 똑같이 좋은 하나짜리 답은 없습니다. 무엇을 최적화하려는가에 따라 갈립니다. 내 어려운 문제가 무엇인지 먼저 정하고 고르세요.
결이 가장 가까운 것 — 오픈소스, 자체 호스팅 가능
| 언어 | 강점 | Nakama 대비 약점 | |
|---|---|---|---|
| Colyseus | TypeScript / Node | 동급 최고의 자동 상태 동기화, 내장 매치메이킹, Unity·Defold·Construct·Haxe·JS SDK. | 실시간 방만 다룹니다 — 신원·저장·소셜·경제·리더보드가 없습니다. 메타 계층은 직접 만들어야 합니다. |
| SpacetimeDB | Rust / C# 모듈 | 근본적으로 다른 모델 — 데이터베이스가 곧 서버입니다. 클라이언트는 쿼리를 구독하고, 엔드포인트 대신 리듀서를 씁니다. 지속되는 세계를 만들 때 진짜로 우아합니다. | 아직 젊고 생태계가 작으며, 사고방식의 전환에 실제로 품이 듭니다. |
| Rivet | Rust 코어, JS/TS 스크립팅 | Apache 2.0 이고 자체 호스팅 가능. 게임 서버·매치메이킹·인증에 백엔드 스크립팅까지 — Nakama 를 통째로 대체하는 데 가장 가깝습니다. | 커뮤니티가 작고, 회사가 범용 상태 저장 서비스 쪽으로 방향을 틀어 게임 집중도가 옅어졌습니다. |
| Agones + Open Match | Kubernetes | Google 이 뒷받침하며, 전용 서버 무리를 오케스트레이션하는 업계 표준입니다. | 다른 문제를 풉니다 — 메타 계층이 아예 없습니다. 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 의 전제와 충분히 닮아서, 그것과 싸우지 않고 확장하게 될 것인가.