게임 서버 · Nakama · SpacetimeDB 와 대안들

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

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

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

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

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

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

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

알아야 할 네 단어

이미지 프로그램과 그 환경을 얼려 둔 읽기 전용 스냅샷입니다. 남이 만든 것을 받거나(nakama·postgres) Dockerfile 로 직접 만듭니다. 이미지는 태그로 버전이 붙습니다 — latest 대신 실제 버전을 못 박으세요. 그러지 않으면 어느 날 아침 서버가 발밑에서 바뀝니다.

컨테이너 이미지를 실제로 띄운 것입니다. 컨테이너는 일부러 일회용으로 설계됐습니다 — 하나를 멈추고 같은 이미지로 새로 띄워도 잃을 것이 없습니다. 요령은 그것뿐입니다: 버리는 것이 안전하면 도 안전합니다.

볼륨 컨테이너보다 오래 사는 저장 공간입니다. 컨테이너 안에 쓴 것은 교체되는 순간 사라집니다 — 그래서 데이터베이스 파일은 컨테이너가 아니라 에 있어야 합니다. 초보자가 플레이어 데이터를 잃는 가장 흔한 경로가 바로 이것입니다.

네트워크와 포트 같은 Docker 네트워크에 있는 컨테이너는 서로를 이름으로 찾습니다 — 게임 서버는 가 아니라 postgres 로 접속합니다. 는 플레이어가 직접 접속하는 것만 바깥으로 열면 되고, 호스트 포트 하나는 정확히 한 프로세스의 것입니다.

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

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

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

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

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

이 사이트도 같은 방식으로 돕니다

SONUB 은 Compose 파일 하나에 적힌 컨테이너 넷입니다 — 웹앱, PostgreSQL, 실시간을 맡는 Centrifugo, 그리고 Redis. 그 앞에 를 종단하는 공용 가 있습니다. 변경을 배포하는 일은 를 올리고 서비스 하나를 다시 하는 것입니다. 게임 서버를 위해 Docker 를 배우면, 앞으로 만들 다른 모든 것을 배포하는 법도 함께 배운 셈입니다.

SpacetimeDB

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

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

Nakama 란 무엇인가

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

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

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

SONUB 은 Nakama 를 쓰지 않습니다

이 페이지는 Nakama 를 여러 선택지 가운데 하나로 가르칩니다. 이 사이트 자체는 Laravel · PostgreSQL · Centrifugo · Redis 로 돌아가며 Nakama 를 쓰지 않습니다. 우리가 쓰는 기술이 아니라 하나의 도구를 설명하는 것입니다.

실제로 좋은 점

확장 모델이야말로 진짜 기능 대부분의 관리형 백엔드는 고정된 를 주고, 벗어날 구멍으로 서버리스 함수를 하나 줍니다. Nakama 는 모든 내장 호출의 앞뒤에 후크를 걸고 원하는 RPC 를 프로세스 안에서 등록하게 해 줍니다. 내가 짠 로직이 같은 바이너리 안에서 데이터베이스에 직접 접근하며 돕니다 — 콜드 스타트도 없고, 람다로 넘어가는 네트워크 왕복도 없습니다. Go 라면 타입이 붙은 인터페이스를 네이티브 속도로 다루게 됩니다.

단일 바이너리 운영 Nakama 하나에 데이터베이스 하나. 쿠버네티스도, 서비스 메시도, 메시지 브로커도 필요 없습니다. 작은 인스턴스 한 대에서 전부 돌릴 수 있고, 신경 쓸 필요가 생기기 전까지 수만 명의 동시 접속을 무난히 감당합니다. 이 분야에서는 드문 일입니다 — 경쟁 제품 대부분은 완전 관리형이거나 클러스터 운영을 전제합니다.

진짜 오픈소스이고, 데이터는 내 것 Apache 2.0 라이선스입니다. 데이터베이스는 내 것이고, 스키마는 문서화되어 있고, 서버는 내 하드웨어에서 돕니다. Heroic Labs 가 내일 사라져도 게임은 계속 돌아갑니다. 빠져나가는 길이 고객 지원 티켓이 아니라 데이터베이스 덤프입니다.

소셜 계층이 성숙하다 이력이 남는 채팅, 역할과 가입 신청이 있는 그룹, 친구 관계, 접속 상태 — 만들기는 지루하고 미묘하게 틀리기는 쉬운 것들입니다. Nakama 의 구현은 10년 가까이 실제 서비스에서 돌아왔습니다.

다시 짜지 않고 관리형으로 Heroic Cloud 는 자체 호스팅과 같은 서버를 돌립니다. 관리형으로 옮기는 것이 이식이 아니라 설정 변경입니다. 어느 방향으로도 길이 막히지 않습니다.

잘 못하는 것

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

전용 서버를 오케스트레이션하지 않는다 Nakama 에는 권위 있는 매치 런타임이 있지만, 전용 서버 오케스트레이션은 직접 하지 않고 Edgegap 이나 GameLift 같은 파트너로 넘깁니다. 매치마다 헤드리스 Unreal·Unity 빌드를 띄워야 한다면 그것은 따로 풀어야 할 문제입니다.

매치 루프는 공유 프로세스 안의 고정 틱 턴제·카드·보드·캐주얼 실시간·가벼운 액션에는 충분합니다. 128인 슈터에 쓸 물건은 아닙니다.

런타임은 샌드박스가 아니다 「클라우드 코드」라는 말이 주는 인상과 달리, 잘못된 Go 모듈 하나가 서버 전체를 내립니다. 프로세스 안에서 네이티브 속도로 도는 것의 뒷면입니다.

클러스터링은 Enterprise 전용 오픈소스 빌드는 단일 노드입니다. 비용을 치르기로 결정하기 전까지는 더 큰 기계로 수직 확장합니다. 작은 게임 대부분에게 그 천장은 멀리 있지만, 분명히 존재하는 천장입니다.

스토리지 쿼리에 제약이 있다 키-값에 약간의 JSON 인덱싱이 붙는 정도이지, 플레이어 데이터에 임의의 을 던질 수는 없습니다. Go 모듈에서 데이터베이스를 직접 조회하는 것이 흔한 우회법입니다.

대안들

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

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

	언어	강점	Nakama 대비 약점
Colyseus	TypeScript / Node	동급 최고의 자동 상태 동기화, 내장 매치메이킹, Unity·Defold·Construct·Haxe·JS .	실시간 방만 다룹니다 — 신원·저장·소셜·경제·리더보드가 없습니다. 메타 계층은 직접 만들어야 합니다.
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 의 전제와 충분히 닮아서, 그것과 싸우지 않고 확장하게 될 것인가.