[취재] 최신 온라인 게임의 발전 : 엔씨소프트 & 인텔

최신 컴퓨터 그래픽스와 인터랙티브 기술을 소개하는 ‘시그래프 아시아 2010(SIGGRAPH ASIA 2010)’ 이 12월 15일부터 18일까지 4일동안 서울 삼성동 코엑스에서 진행된다. 시그래프 아시아 2010은 미국 컴퓨터 협회(ACM)의 주최로 1974년부터 시작된 미국 ‘시그래프’ 행사의 아시아권 행사로, 2008년 처음 시작해 올해 3회를 맞아 서울에서 개최된다.

이번 시그래프 아시아 2010의 트랙 프로그램에서는, 최근 온라인 게임들에 적용되기 시작하는 최신 기술들과 앞으로 해결해야 할 과제들에 대해 짚어 보는 프로그램이 진행되었다. ‘최신 온라인 게임의 발전’ 이라는 주제의 이 프로그램은 그래픽과 서버 기술, 게임 테스트와 멀티쓰레딩 이슈까지 크게 네 가지 주제를 다루었다. 이번 기사에서는 게임 테스트와 멀티쓰레딩 내용을 다뤘다.

■ 엔씨소프트 '서버 관리 힘들다. 그래서...!'

▲ 큰 인기를 끌었던 SNS게임 ‘We Rule’

엔씨소프트(NCsoft)의 김종원 기술이사가 차세대 MMORPG의 서비스 구조에 대해 발표를 진행했다. 그는 먼저 아이폰용 SNS 게임으로 큰 인기를 끌었던 ‘We Rule’을 소개하면서, 이 게임이 가진 ‘전 세계적인 단일 공간 서비스’ 와 각종 SNS 서비스들과의 연계, 그리고 기본적인 서비스의 안정성 등이 미래의 MMORPG가 갈 길이라고 언급했다. 그리고 ‘안정성’을 확보하지 못한 We rule 은 일종의 실패로 보고 있다는 견해를 밝혔다.

향후 MMORPG는 크게 두 가지로 나뉠 것으로 예상된다. 현재처럼 ‘메이저 급’ 게임은 5년 뒤 수백 GB의 용량과 FHD를 뛰어넘는 해상도의 지원, 강력한 게임엔진의 사용 등 많은 것이 요구되고 지원될 것으로 보인다. 반면 ‘경량화된’ MMORPG는 다운로드 없는 플레이와 모바일까지 포함하는 멀티플랫폼 엔진의 사용 등으로 발전할 것으로 기대된다.

그리고 전통적인 MMORPG를 서비스하는 입장에서, We Rule의 서비스 방법과 규모는 놀라운 수준이라고 소개했다. 이 회사의 서비스는 하루에도 7천만명 이상의 사용자가 다녀가고 이용할 정도로 대규모이며, 신규 서비스하는 게임 서비스였던 ‘피시빌’ 은 1주만에 600만 유저가 증가하기도 했다. 이를 효과적으로 감당하기 위한 서버 구성 방법이 궁금해질 만도 하다.

사실 이들 서비스의 서버 구조는 간단하다 php 기반의 웹서버는 캐시 서버를 거쳐 DB에 접속하고, 자바 기반의 MMO서버가 DB에 접속되는 형태다. DB는 MySQL이 이용되고 있다. 하지만 이 대규모의 사용자를 감당하기 위해 ‘스케일 업(Scale up)’과 ‘스케일 아웃(Scale out)’을 계획적으로 진행하고 있으며, 데이터베이스를 여러 개 두고 분산시켜 공유하는 등의 방법을 사용한다.

▲ 국내 게임업체들은 서버가 구역으로 분할되어 있다.

엔씨소프트를 포함한 국내 게임업체들의 접근방식은 이들과 약간 다르다. 국내에서의 분산 방법은 아예 ‘지역’ 구분의 성격이며, ‘채널’ 당 동시 접속자수를 제한해 같은 콘텐츠를 가진 복수의 채널을 운영하고 있다. 이는 서버 기술적인 문제 뿐 아니라 콘텐츠 소비의 밸런스를 위해 기획적인 부분에서부터 고려하는 점인데, 이런 게 없으면 한 지역에 지나치게 많은 사람이 몰려 있어서 나타나는 부작용을 피할 수 없기 때문이라고 한다.

하지만 이런 구조의 경우 다른 월드나 채널의 사용자와 커뮤니케이션이 쉽지 않으며, 데이터 교환도 힘들어진다. 덕분에 웹 서비스와의 연동도 힘들어지는데, 웹에서는 읽기만 하고 데이터 변경이 되지 않는, 데이터의 일방적인 흐름만 일어나게 된다. 엔씨소프트 뿐 아니라 다른 업체들도 비슷한 상황이며, 실제 전체 월드를 한 대의 서버가 담당하는 공통적인 구조를 가지고 있다. 물론 이는 효율 면에서 장점이 되는 경우도 있다.

앞으로 온라인 게임들에 요구되는 것은 ‘하나의 거대한 월드’, 그리고 스마트폰과 웹, SNS들과의 연동 등이 있다. 그리고 이를 위해서는 새로운 게임 디자인과 콘텐츠, 서비스 아키텍처가 필요하며, 게임과 웹, SNS들이 하나의 데이터를 공유하고, 여러 활동들을 기록해 하나로 묶어 사용할 수 있게 하는 것이 중요하다.

▲ NoSQL 솔루션 mongoDB

현재 사용하는 DB는 수십 개의 월드를 묶게 되면 사용자 규모를 감당하지 못해 서비스가 불가능해진다. 이는 DB의 확장 자체가 어렵기 때문이다. 또한 MMORPG는 DB의 쓰기 작업이 많으며, 하드 디스크의 병목 현상이 심하다. SSD를 사용해 서비스하는 경우 이 부분에서 개선이 크지만, 수명이나 리스크 부담 등이 있어 현재는 보조적인 수단으로 사용하고 있다고 소개되었다.

게임도 다시 설계할 필요가 있다. 동기화될 데이터와 그렇지 않은 데이터를 나눌 필요가 있고, 웹서비스나 모바일 서비스와의 연계 계획도 미리 할 필요가 있다. 이런 점은 나중에 추가하려 하면 대단히 문제가 복잡해진다. 또한 이런 활동들을 저장할 수 있는 통합 로그 시스템이 필요하다는 점이 지적되었다.

이런 DB의 규모 문제를 해결하고 성능을 높이기 위해 고려되는 대안 중 하나가 ‘NoSQL’의 접목이다. 이 솔루션은 DB의 스케일 업, 스케일 아웃 문제를 해결하고, 서버를 추가할수록 성능과 안정성을 함께 담보할 수 있다는 성격을 가지고 있다. 물론 기존 게임에 바로 적용하기는 힘든데, 사용 방법과 범위가 상당히 다르기 때문이다. 덕분에 주로 ‘병용’ 하는데 중요한 데이터는 RDBMS, 크게 중요치 않은 기록은 NoSQL을 이용하는 것이 효율적이다.

NoSQL은 전통적인 개념의 DBMS가 아니다. 가장 큰 차이점은 테이블 스키마의 존재가 없는 간단한 구조를 가지고 있다는 것이며, 성능 면에서도 더 뛰어난 면이 있다. 또한 일반적으로 이러한 솔루션들은 오픈 소스 기반의 프로젝트로 진행되고 있으며, 덕분에 이를 활용할 경우 솔루션의 비용까지도 절감할 수 있다는 부분이 있다.

이런 형태의 솔루션으로는 Digg 이 사용하고 있으며 아파치 프로젝트에 포함되어 있는 Cassandra, 오픈 소스 프로젝트로 진행되고 있고, Foursquare나 SourceForge 등이 사용하고 있는 mongoDB 가 있다. 특히 mongoDB는 오픈 소스 프로젝트임에도 지원을 담당하는 회사가 있고 자금 지원 등도 이루어지고 있어 지속적인 개발에 대한 신뢰감을 주고 있는 것이 특징이다.

▲ 분산된 서버에서는 통합된 통계를 내기도 힘들어진다.

사용자가 늘어나고 데이터베이스가 방대해지면서, 데이터베이스를 분산해야 하는 경우도 생긴다. 이 때 선택할 수 있는 방법은 크게 두 가지로 나뉘며, 서로 장단점이 있다. 먼저 DB를 테이블별로 나누어 각각 다른 시스템에 탑재하는 것을 선택할 수 있는데, 이 때는 한 테이블에 집중적인 요청이 이루어질 경우 전체 처리 성능에 병목 현상이 일어날 수 있으며, 개별 시스템의 성능에 제약을 받는다.

다른 방법으로는 사용자의 ID나 위치 등의 특정 데이터를 기준으로 해 전체 DB를 여러 개의 작은 DB의 모음으로 만드는 방법이 있다. 이 방법의 단점은 ‘번거로움’ 인데, 전체 DB를 검색해야 할 경우 분산된 DB에 모두 쿼리를 보내야 하기 때문이다. 이런 점을 줄이기 위해 자주 연결되는 데이터의 경우 어느 정도 중복성을 가지게 하는 식으로도 구성한다.

또한 사용자가 늘어나고 서비스를 위한 시스템을 확장하게 되는 경우 조심해야 할 점도 소개되었다. 온라인 게임을 서비스하는 데 있어서 게임 서비스보다 이를 보조하는 웹, 업데이트 서버가 더 많은 경우가 흔하며, 서버는 구매 비용보다는 이를 운영하는 데 드는 비용이 더 크다는 것이다. 또한 서비스를 설계하고 요구사항들을 반영하다 보면 서버가 늘어나고, 비용은 더 커지며, 시스템이 늘어나면 고장난 시스템이 나올 확률도 높아진다.

이런 상황을 대비하고 서비스의 안정성을 확보하기 위해서는 여러 가지 방법이 사용되고 있다. 먼저, 일부 시스템에 장애가 생기더라도 서비스가 진행될 수 있도록 시스템들을 이중화하는 것을 감안해볼 수 있다. 하지만 게임의 로직 서버 등은 이중화에 있어 부담이 크며, 완전한 이중화가 힘든 상황에서는 최소한 DB의 안정성을 담보할 수 있도록 캐시나 백업, 다중화 등을 고려해야 한다.

인프라를 이루는 개별 시스템의 경우, 일단 구입 가능한 선에서 최대한 고성능의 시스템을 사용하여 전체 시스템 수를 줄이고 퍼포먼스를 높이는 것을 추천했다. 이는 구입비보다 운영비가 더 큰 면이 반영된 것이다. 또한 현재까지 가상화나 클라우드를 고려하는 것보다는, 싱글 시스템에서 최대한의 성능을 내게 해, 전체 시스템 수를 줄이는 식으로 접근하고 있다고 덧붙였다.

■ 인텔 '패러렐 컴퓨팅이 앞으로의 대세'

▲ 요즘 프로세서들은 멀티 코어 디자인이 대세다.

마지막 순서로는 인텔의 최병원 박사가 ‘멀티 코어를 위한 온라인 게임의 최적화’ 에 대해 소개했다. 그는 먼저, 이제 싱글 코어에서 성능의 향상은 한계에 오고 있으며, 성능 향상을 위한 대안으로 제시된 멀티 코어, 멀티 쓰레드의 경우에는 소프트웨어의 병렬화가 되어 있지 않은 경우에 성능 향상을 볼 수 없다는 문제를 가지고 잇다고 소개했다.

게임 분야는 다른 부분에 비해 멀티쓰레딩 적용이 쉽지 않다. 게임 안에는 다양한 연산 요소들이 있지만, 가장 큰 문제는 ‘렌더링’ 때문이다. GPU의 경우에는 이미 병렬화 구조가 확립되어 있지만, GPU로 가기 전의 원시 데이터의 처리, GPU에서 나온 결과값의 처리는 병렬화가 어렵고 한계가 있기 때문이라는 것이다.

최근의 게임 엔진들은 듀얼 이상의 멀티 쓰레드 환경을 활용하기 위해 다양한 방법을 시도하고 있다. 렌더링 쓰레드와 업데이트 쓰레드를 병렬로 구동하고 버퍼를 사용해 최대한 대기 시간을 줄이는 줄이는 것이 대표적인 방법이다. 물론 이 경우 렌더링 쓰레드가 부하가 클 경우 한계가 분명하지만, 최근의 게임들이 물리 연산이나 AI가 복잡해지면서 업데이트 프로세스의 부하도 큰 만큼, 현재까지는 이런 구성도 비교적 괜찮은 효율을 보여 준다.

서버 부분에서는 비교적 멀티 쓰레드 환경에 대한 대비가 잘 되어 있는 편이다. 여러 유저에게서 오는 메시지를 각 접속별로 쓰레드를 생성해 처리하면 그것만으로도 멀티 쓰레딩 환경이 구현된다. 예전부터 게임에 사용되는 DB 등도 이런 다중 사용자 환경을 잘 지원해 왔고, 서버 쪽은 코어 수에 따라 성능이 비교적 잘 올라갔다.

▲ 프로그램 병렬화를 도와주는 ‘페러렐 스튜디오’

현재의 멀티코어 프로세서를 활용하는 데 있어 가장 핵심적인 요소는 ‘쓰레드’의 활용이다. 이를 어떤 식으로 나누느냐에 따라 쿼드 코어 이상으로 발전하고 있는 프로세서의 활용도와 성능에 차이가 나기 때문이다. 현재 많은 수의 게임들이 단순히 ‘듀얼 쓰레드’ 수준을 지원하는 이유는 게임에서의 쓰레딩 관리가 생각보다 힘들며, 너무 적은 쓰레드도 문제지만 너무 많은 쓰레드도 성능 저하의 원인이 되기 때문이다.

최근의 게임들이 많이 사용하는 멀티 코어 활용의 방법은 목적별로 코어를 할당하는 형태다. 한 코어가 렌더링을 담당하고 다른 코어들이 각각 사운드, AI 등을 처리하는 것이다. 이 경우 한쪽 쓰레드가 처리의 한계에 달하면 성능 향상의 한계가 오며, 향후 더 많은 코어를 탑재한 프로세서가 나와도 게임 성능의 한계는 개별 코어 성능의 벽을 극복할 수 없게 된다.

인텔이 제시하는, 가장 이상적인 병렬화 방법은 ‘태스크 기반 병렬화’다. 기존의 작업의 흐름을 유지하면서, 각각의 작업을 모두 작은 단위로 쪼갠 다음 모든 쓰레드에 분산 할당하는 형태로 병렬화하는 것이다. 이 때 쪼개진 작은 단위가 ‘태스크’ 이며, 이는 완전히 수행되어야 하고 중복 수행 등을 피할 필요가 있다.

또한 병렬화는 처리에 가장 오랜 시간이 필요한 ‘핫스팟’ 부터 진행하는 것이 추천된다. 비중이 크지 않은 부분에서 병렬화는 실질적인 프로그램의 성능 향상에 큰 도움이 되지 않기 때문이다. 이런 핫스팟은 각종 프로파일링 툴을 통한 분석 결과를 기반으로 비교적 쉽게 찾을 수 있다. 인텔의 경우 Vtune과 페러렐 스튜디오 솔루션에서 이런 기능들을 지원하고 있다고 덧붙였다.

일반적으로 싱글 쓰레드 프로그램들에서 가장 많은 실행 시간을 소비하는 작업은 ‘루프’ 다. 덕분에 보통 프로파일링 툴을 통해 병렬화하고자 하는 지점을 찾으면 루프 문이 나오게 된다. 하지만 이 경우 루프문에서 사용하는 변수가 이전 회차의 루프에서 나온 결과를 참고한다든지 하는 경우엔 병렬화가 어려워지게 되므로, 이런 종속성은 최대한 줄일 필요가 있다.

한편, 프로그램의 병렬화 이후 가장 까다로운 부분이 ‘디버깅’ 이다. 시스템의 상태에 따라 수행할 때마다 다른 결과가 나오고, 버그에 대한 재현도 쉽지 않기 때문이다. 인텔은 이런 디버깅의 어려움을 해결하기 위해 패러렐 스튜디오에 쓰레딩 에러의 가능성과, 디버깅 후 제대로 성능이 나오는지에 대한 확인이 가능한 툴을 제공하고 있다고 소개했다.