← 블로그 목록

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

함께 읽으면 좋은 글

게임 개발프로토타입스타크래프트
거친 초기 스타크래프트 화면이 보여 주는 건 완성도가 아니라 검증 순서다

유명 게임의 초기 화면이 투박해 보이는 이유는 실패의 증거가 아니라 질문의 흔적이다. 라미 이스마일이 구분한 프로토타입과 버티컬 슬라이스 개념과 와이어트의 워크래프트 회고를 빌려, 프로토타입은 완성도를 증명하는 단계가 아니라 무엇이 재미인지 먼저 검증하는 단계임을 정리한다. 초반 핵심은 빨리 멋져 보이는 일이 아니라 빨리 틀려 보는 일이다.

게임 개발그래픽스컬링
컬링은 안 보이는 것을 덜 그려서 3D 장면을 버티게 만드는 기본 최적화다

3D 장면이 무거울 때는 폴리곤 수를 줄이는 것 못지않게 보이지 않는 것을 일찍 걸러내는 일이 중요하다. 백페이스, 프러스텀, 오클루전 컬링은 비슷해 보여도 해결하는 문제가 서로 다르고 비용 구조도 다르다. 안 보이는 이유가 방향 때문인지, 시야 밖이기 때문인지, 가려졌기 때문인지 구분해서 적용해야 한다는 점을 OpenGL과 Unity 문서를 함께 정리한다.

게임 개발프로그래밍리스프
고차 함수와 데이터 분리는 게임 로직의 변경 비용을 낮춘다

고차 함수와 데이터·로직 분리는 프로그램을 똑똑하게 만드는 마법이 아니라, 반복되는 패턴을 함수로 묶고 자주 바뀌는 설정을 코드 밖으로 빼서 변경 비용을 낮추는 추상화에 가깝다. SICP와 Unity ScriptableObject 사례를 함께 보면서, 게임처럼 규칙과 예외가 계속 늘어나는 환경에서 무엇을 코드로 두고 무엇을 데이터로 뺄지 가르는 기준을 정리한다.