에픽 온라인 서비스와 Hathora를 활용한 Loftia MMO 아키텍처 구축

게임의 귀여운 그래픽만 보고 속단하기엔 이릅니다. 이 스튜디오는 데뷔작임에도 불구하고 로프티아의 멀티플레이어 기능에 대해 처음부터 매우 야심 찬 비전을 갖고 있었습니다. 그 목표에는 매끄러운 온라인 코옵 플레이와 솔로 플레이, 플레이어들이 집을 합칠 수 있는 역동적인 세션, 수백 명의 플레이어가 함께 공유하는 대규모 소셜 허브 등이 포함됩니다.
 
최근에 클라우드 게임즈(Qloud Games)의 공동 설립자 겸 CTO인 에릭 말론(Eric Mallon)을 만나 게임 아키텍처를 구축하는 과정에서 직면했던 중요한 선택과 도전 과제에 관한 이야기를 들어보았습니다. 이번 글을 통해 클라우드 게임즈가 에픽 온라인 서비스(EOS)와 Hathora를 활용하여 어떻게 소규모 팀으로 원대한 비전을 실현할 수 있었는지 확인해 보세요.

에릭은 말합니다. "우리 팀의 엔지니어링 실력 및 자체 백엔드 시스템 구축 능력에 대해서는 항상 자신이 있었습니다. 하지만, 소규모 팀이었기 때문에 크로스 플랫폼 플레이어 인증이나 확장 가능한 서버 호스팅처럼 시간이 많이 소요되는 작업은 기존 툴을 활용하고 싶다는 것을 알고 있었죠."

에릭은 크로스 플랫폼 플레이어 인증은 개발자가 구현하는 데 시간이 많이 드는 기능임을 알고 있었고, 에픽 온라인 서비스는 쉽게 시작할 수 있는 잘 다듬어진 무료 솔루션을 제공했습니다. 시간이 지남에 따라 클라우드는 세션 관리 및 음성 채팅과 같은 에픽 온라인 서비스의 모듈형 기능을 점점 더 많이 활용하고 있습니다.

서버 호스팅의 경우, 에릭과 그의 팀은 이러한 시스템을 구축하고 유지하는 데 얼마나 많은 작업이 필요한지 잘 알고 있었습니다. 실시간으로 서버를 유지하고 모니터링하는 전담팀이 필요한 경우가 많은데, 클라우드 게임즈에는 로프티아 개발에서 그렇게 할 여력이 없었습니다.

"Hathora는 정말 빠르게 설정할 수 있고 게임용으로 특화되어 있었습니다. 집중해야 할 다른 일이 많았던 만큼 EC2 인스턴스를 직접 관리할 필요가 없다는 점이 정말 좋았습니다."라고 에릭은 말합니다.

로프티아의 백엔드 아키텍처는 크게 두 가지 핵심 그룹으로 구성되어 있습니다.

1. 데이터 및 원격 측정 파이프라인: 지속성, 분석, 장기적인 플레이어 상태를 처리합니다. 이를 위해 Qloud는 Sentry, AWS Firehose, DynamoDB와 같은 툴을 사용합니다.
2. 실시간 게임플레이 인프라: 플레이어가 실시간으로 상호작용하는 세션의 실행을 담당합니다.

로프티아가 특히 흥미로운 점은 클라우드 게임즈가 매치메이킹을 처리하는 방식 때문입니다. 전통적인 경쟁형 매치가 아니라, 플레이어가 적절한 세션으로 원활하게 이동하여 친구와 바로 플레이를 시작하도록 되어 있습니다. 이 접근 방식은 세련되면서도 놀라울 정도로 간단합니다.

플레이어 연결 흐름은 속도와 안정성을 중심으로 설계되었습니다.

1. 플레이어가 월드 참가를 요청합니다.
2. 게임에서 에픽 온라인 서비스를 사용하여 기존 세션을 검색합니다.

• 일치하는 세션이 발견되면 게임에서 언리얼 온라인 비컨(Online Beacons)을 통해 자리를 예약합니다.

3. 일치하는 세션이 없으면 Hathora를 통해 새 서버가 생성됩니다.

• 온라인 상태가 되면 해당 서버가 에픽 온라인 서비스에 등록되어 다른 플레이어가 연결할 수 있게 됩니다. 통합 팁: 에픽 온라인 서비스 세션은 Hathora의 룸(Rooms)과 잘 매핑됩니다.

큰 틀에서 보면 이 흐름은 단순해 보이지만, 모든 MMO가 그렇듯 특별한 상황에서 문제가 나타납니다. 클라우드에서 겪었던 몇 가지 흥미로운 도전 과제를 자세히 살펴보겠습니다.
 

도전 과제 #1: 새로운 서버 레이스 현상

초기에 로프티아 팀은 까다로운 문제에 직면했습니다. 매칭되는 세션이 없을 때 서버를 과도하게 프로비저닝하지 않는 방법이 필요했습니다.

팀의 목표는 기술 효율성과 월드의 생동감을 유지하기 위해 플레이어를 가능한 한 적은 수의 소셜 허브 세션으로 통합하는 것이었습니다. 같은 원칙이 플레이어 하우스에도 적용되었습니다.

해결책은 무엇이었을까요? Hathora에서 새 인스턴스가 생성되는 동안 서버 요청을 대기열에 대기시키는 AWS 람다(AWS Lambda) 버퍼를 사용하는 것이었습니다. 이 버퍼를 통해 여러 개의 참가 요청이 동시에 발생할 때 서버가 중복 실행되는 것을 방지할 수 있습니다.

실제 테스트결과, 로프티아의 첫 번째 비공개 알파 테스트 당시, 이 버퍼 로직이 없어서 불필요한 서버가 한꺼번에 대량으로 생성되는 문제가 발생했습니다. 이는 알파 테스트가 중요한 이유를 다시 한번 일깨워주는 사례입니다.
 

도전 과제 #2: 서버 슬롯 예약

또 하나의 미묘하지만 중요한 세부 문제는 참가 프로세스 중에 빈 슬롯을 예약하는 것입니다. 빈 슬롯이 5개밖에 없는 서버에 5명의 플레이어가 참가하려고 하면 5명의 요청이 모두 겹쳐서 일부 플레이어가 거절될 위험이 있습니다.

로프티아는 언리얼 온라인 비컨을 사용하여 이용 가능 여부를 조회할 뿐만 아니라 연결을 시도하기 전에 세션의 자리를 예약함으로써 이 문제를 피해 갔습니다. 이는 사소한 세부사항이지만 순간순간의 플레이 경험을 크게 향상시켜 주는 요소입니다.

로프티아처럼 아늑하고 소셜 중심적인 게임에서는 잠깐의 불편함으로도 이러한 분위기를 깨트릴 수 있으며, 이러한 작은 구현상의 디테일을 해결하는 것이 플레이어 경험에 큰 영향을 줄 수 있습니다.