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

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

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

가운데 서버 탑이 말 세 개가 놓인 게임판 하나를 들고 있고, 둘레의 휴대폰·노트북·태블릿·게임기가 서버로 수를 보내고 같은 게임판을 돌려받습니다. — 온라인 게임에서는 모든 플레이어가 서버로 수를 보내고, 서버가 하나뿐인 진짜 게임 상태를 지켜 모두에게 돌려보냅니다. 공정한 심판과 같습니다.

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

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

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

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

게임 서버에서는 이것이 더 중요합니다. 게임 는 하나가 아니기 때문입니다. 서버에 가 붙고, 보통 까지 붙습니다. 이것들이 서로를 찾아 올바른 순서로 켜져야 합니다. Docker 를 쓰면 한 페이지짜리 설치 안내가 파일 하나와 명령 하나로 줄어듭니다. 뒤 탭에서 다룰 게임 백엔드 서버 도 공식 빠른 시작을 로 안내합니다.

알아야 할 네 단어

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

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

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

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

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

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

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

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

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

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

SONUB 은 Compose 파일 하나에 적힌 여러 컨테이너로 돕니다 — 과 뒤에서 일하는 일꾼(큐·), PostgreSQL, , 실시간을 맡는 , 백업. 그 앞의 공용 리버스 프록시가 연결을 받아 풀고 안으로 넘깁니다. 변경을 배포하는 일은 를 올리고 서비스를 다시 하는 것입니다. 게임 서버를 위해 Docker 를 배우면, 앞으로 만들 다른 것을 배포하는 법도 함께 배운 셈입니다.

SpacetimeDB

는 보통의 게임 서버와 다른 길을 갑니다. 가 곧 서버입니다. 데이터베이스와 대화하는 게임 서버를 따로 짜지 않고, · 같은 언어로 쓴 을 올리면 그 안의 함수()가 데이터베이스 안에서 돌며 을 바꿉니다. 는 리듀서를 불러 상태를 바꾸고, 필요한 테이블을 해 바뀐 줄을 바로 받습니다. 시스템이 하나뿐이라, 따로 할 서버 프로세스도 두 시스템을 맞추는 도 없습니다.

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

Nakama 란 무엇인가

는 Heroic Labs 가 만든 게임 서버입니다. 로 작성되었고, 단일 하나와 호환 로 됩니다. 도 아니고 도 아닙니다 — 그 둘 사이의 계층입니다. 플레이어가 누구이고, 무엇을 가지고 있으며, 누구와 함께 놀고 있는지를 아는 쪽입니다.

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

신원과 — 기기 ·이메일·Apple·Google·Facebook··커스텀. 하나의 계정에 여러 인증 수단을 연결해 플랫폼을 넘나듭니다.
— 이 붙는 문서, 마다의 소유권과 접근 규칙. 플레이어 저장 가 여기 들어갑니다.
소셜 — 친구, 그룹과 , , 그리고 채팅(1:1·그룹·방)과 대화 이력.
경쟁 — 초기화 주기를 설정할 수 있는 와 토너먼트, 그리고 속성으로 조건을 거는 .
경제 — 를 지원하는 지갑, 그리고 Apple·Google·Steam .
실시간 — 과 , 그리고 을 맡는 매치 — 서버 쪽 를 직접 작성합니다.
런타임 — Go·· 로 서버를 확장합니다. 자신만의 를 등록하고, 내장 동작의 앞뒤에 를 겁니다.

SONUB 은 Nakama 를 쓰지 않습니다

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

실제로 좋은 점

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

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

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

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

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

잘 못하는 것

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

전용 서버를 오케스트레이션하지 않는다 Nakama 는 서버가 판정을 맡는 매치를 직접 돌리지만, 매치마다 띄우는 전용 게임 서버를 여러 대 켜고 끄며 관리하는 일()은 이나 GameLift 같은 파트너에게 넘깁니다. 매치마다 화면 없이 도는() · 를 띄워야 한다면 그것은 따로 풀어야 할 문제입니다.

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

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

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

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

대안들

와 똑같이 좋은 하나짜리 답은 없습니다. 무엇을 최적화하려는가에 따라 갈립니다. 내 어려운 문제가 무엇인지 먼저 정하고 고르세요. 아래 ''은 게임 판 밖의 기능(계정·친구·채팅·저장·), ''는 출시 뒤 이벤트·상점·업데이트를 운영하는 일입니다.

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

	언어	강점	Nakama 대비 약점
	/	동급 최고의 자동 상태 , 내장 , ···· .	실시간 방만 다룹니다 — 신원·저장·소셜·경제·리더보드가 없습니다. 메타 계층은 직접 만들어야 합니다.
	/	근본적으로 다른 모델 — 가 곧 서버입니다. 는 를 하고, 대신 를 씁니다. 지속되는 세계를 만들 때 진짜로 우아합니다.	아직 젊고 가 작으며, 사고방식의 전환에 실제로 품이 듭니다.
Rivet	Rust 코어, JS/TS 스크립팅	이고 가능. 게임 서버·매치메이킹·에 스크립팅까지 — Nakama 를 통째로 대체하는 데 가장 가깝습니다.	커뮤니티가 작고, 회사가 범용 쪽으로 방향을 틀어 게임 집중도가 옅어졌습니다.
+		Google 이 뒷받침하며, 무리를 하는 업계 표준입니다.	다른 문제를 풉니다 — 메타 계층이 아예 없습니다. Nakama 를 대체하는 것이 아니라 함께 씁니다.

관리형·상업용

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

시장에 대한 한 가지

이 분야는 다른 분야보다 빠르게 통합됩니다 — 이 영역의 호스팅 서비스들이 큰 예고 없이 문을 닫거나 사업에서 빠져나간 사례가 있습니다. 몇 년을 굴려야 하는 라이브 서비스를 계획한다면, 자체 호스팅 가능한 쪽을 택할 이유가 됩니다.

어떻게 고를 것인가

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

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