← 블로그 목록

MMORPG 서버에서 ‘방’보다 중요한 것은 누구에게 무엇을 보여 줄지 정하는 일이다

MMORPG 서버 설계의 진짜 문제는 ‘방을 몇 개로 나눌까’가 아니라 ‘각 플레이어에게 지금 무엇이 relevant한가’를 어떻게 싸게 계산하느냐다. 거리 기반 필터링과 공간 분할 같은 interest management가 그래서 중요하다. 좋은 서버는 많이 보내는 구조가 아니라 ‘어떻게 덜 보내도 충분하게 만들까’를 푸는 구조에 가깝다는 점을 정리한다.

MMORPG 서버에서 ‘방’보다 중요한 것은 누구에게 무엇을 보여 줄지 정하는 일이다

MMORPG 서버에서 ‘방’보다 중요한 것은 누구에게 무엇을 보여 줄지 정하는 일이다

멀티플레이 게임을 처음 만들 때 가장 쉬운 방법은 단순하다. 모든 플레이어에게 모든 상태를 보내는 것이다. 소규모 테스트에서는 이 방식이 실제로 잘 돌아가기도 한다. 하지만 플레이어 수와 오브젝트 수가 늘어나면 곧 한계가 드러난다.

대규모 온라인 게임에서 중요한 질문은 방을 몇 개로 나눌 것인가보다 각 플레이어에게 지금 무엇이 relevant한가를 어떻게 계산할 것인가에 더 가깝다. 서버 구조의 핵심은 결국 관심 범위, 즉 interest management 문제다.


모든 상태를 모두에게 보내는 방식은 금방 무너진다

Mirror 공식 문서의 Interest Management는 멀티플레이 게임에서 가장 처음 떠오르는 접근이 전체 월드 상태를 모든 플레이어에게 브로드캐스트하는 것이라고 설명한다. 그리고 월드 오브 워크래프트 같은 규모를 생각하면 이런 방식은 말이 되지 않는다고 지적한다.

이 설명은 MMORPG에 그대로 들어맞는다.

즉 서버는 단순히 상태를 복제하는 기계가 아니라, 지금 누구에게 무엇이 보여야 하는지 판단하는 필터가 되어야 한다.


“방”은 쉬운 출발점이지만 충분한 해법은 아니다

방 개념은 여전히 유용하다. 던전, 매치, 채널처럼 플레이어 집합이 명확히 분리되는 경우에는 지금도 잘 맞는다. Mirror가 MatchScene 기반 격리를 별도로 두는 이유도 여기에 있다.

하지만 MMORPG 월드는 방처럼 또렷하게 끊기지 않는 경우가 많다.

그래서 서버는 방 단위 분리 위에 한 단계 더 올라가, 누가 누구의 관찰자(observer)인가를 계속 계산해야 한다.


실무에서는 거리 기반과 공간 분할이 많이 쓰인다

Mirror의 Distance Interest Management는 가장 단순한 방법을 보여 준다. 각 연결과 각 엔티티의 거리를 계산해 범위 안에 있는 것만 전송하는 방식이다. 다만 이 방법은 엔티티와 연결 수가 많아질수록 비용이 커진다.

그래서 대규모 상황에서는 Spatial Hashing처럼 공간을 그리드로 나눠 주변 셀만 보내는 방식이 더 잘 쓰인다. Mirror 문서도 예전 거리 계산보다 이 방식이 훨씬 빠르게 확장된다고 설명한다.

이런 구조의 장점은 분명하다.

즉 MMORPG 서버에서 중요한 것은 이라는 단어보다 관심 범위를 얼마나 싸게 계산하느냐에 있다.


채팅과 상태 동기화를 같은 방식으로 다루면 비효율적이다

글로벌 채팅이나 길드 채팅은 텍스트 몇 줄만 전달하면 된다. 반면 위치, 애니메이션, 발사체, 몬스터 AI 같은 월드 상태는 훨씬 빈번하고 비용이 크다.

그래서 서버 설계에서는 보통 이 둘을 같은 계층으로 다루지 않는다.

Gaffer on Games의 What Every Programmer Needs To Know About Game Networking도 게임 네트워크에서 무엇을 동기화하고 무엇을 생략할지 결정하는 일이 성능과 체감 품질 모두에 중요하다고 설명한다.


핵심 정리

MMORPG 서버에서 핵심은 방을 몇 개로 나누는 기술보다, 각 플레이어에게 지금 무엇이 중요하고 무엇이 불필요한지를 계산하는 기술이다. 대규모 온라인 게임일수록 서버는 전체 월드를 모두 뿌리는 대신, 거리와 공간 분할, 팀, 씬 같은 기준으로 관심 범위를 좁혀야 한다.

결국 좋은 서버 구조는 “어떻게 많이 보낼까”가 아니라 “어떻게 덜 보내도 충분하게 만들까”를 푸는 구조에 더 가깝다. MMORPG의 네트워크 최적화는 전송 기술보다 relevance 판단 문제라고 보는 편이 정확하다.

참고 자료

← 목록으로
Related

함께 읽으면 좋은 글

게임 개발소프트웨어 디자인아키텍처
데이터 주도 설계의 핵심은 데이터를 많이 두는 것이 아니라 경계를 잘 나누는 것이다

데이터 주도 설계는 모든 값을 JSON이나 테이블로 빼는 일이 아니다. 저장 형식과 도메인 모델 사이에 변환 계층을 두고, 자주 바뀌는 값과 시스템 개념을 구분하며, 데이터 변경이 핵심 로직까지 무차별적으로 퍼지지 않게 경계를 설계하는 일에 가깝다. 결국 중요한 것은 데이터의 양이 아니라 경계의 질이다.

소프트웨어 공학시스템 설계프로젝트 관리
대규모 소프트웨어 개발은 코드 양보다 조정 비용과 구조 설계가 더 어렵다

큰 시스템이 어려운 이유는 코드 양 그 자체보다 모듈 사이의 관계 수와 사람 사이의 조정 비용, 그리고 보이지 않는 복잡성에 있다. 프레드 브룩스의 통찰처럼 인원을 더 넣는다고 일정이 줄지 않고, 문서와 경계가 없으면 시스템은 금세 개인 의존형이 된다. 대규모 개발의 진짜 실력이 기능 구현보다 운영 현실을 견디는 구조를 만드는 데서 드러난다는 점을 정리한다.

게임 개발MMO커뮤니티 관리
온라인 게임과 커뮤니티는 자유와 통제 중 하나를 고르지 않고 둘의 설계를 같이 한다

온라인 게임과 커뮤니티가 자유와 통제 중 하나만 강조하면 양쪽 다 잃기 쉽다. 오스트롬의 공유지 논의와 Minecraft·Reddit·WoW 커뮤니티 연구가 보여 주듯, 지속 가능한 공간은 자율을 없애서 유지되지 않고 명시적 규칙과 신고·검토 도구, 단계적 제재를 함께 설계할 때 유지된다. 자유가 오래 버티게 만드는 제도화된 자율의 원리를 정리한다.