전세계의 쟁쟁한 게임사 개발자들의 축제 GDC에 넷텐션도 참가했습니다. 

본격적인 일정이 시작되는 GDC 3일차, 각 게임 업체들의 게임과 엔진 등 다양한 제품이 소개되는

엑스포(EXPO)행사에서 한국을 대표하는 서버 엔진 프라우드넷의 넷텐션 부스도 만날 수 있었습니다.

기사전문보기

넷텐션이 오는 7일부터 9일까지 사흘간 미국 샌프란시스코서 열리는 '2012 게임개발자컨퍼런스(GDC)'에 홍보부스를 마련하는 등 본격적인 해외시장 공략에 나선다.

넷텐션(대표 배현직)은 5일 이번 컨퍼런스에서 서울애니메이션센터의 한국공동관에 부스를 설치하고 해외 업체들과 협업을 위한 자리를 마련했다고 밝혔다.

지난 2009년 설립된 넷텐션은 현재 국내 서버엔진 업체의 독보적인 자리를 차지하고 있으며 그동안 해외 엔진 업체들이 국내에 진출하기만 했던 환경 속에서 국내 독자개발 엔진 업체가 해외 진출을 한다는 점에서 의미가 크다.

(기사 전문 보기)

현재 프라우드넷의 Adobe Flash(이하 플래시) 버전이 베타 릴리즈 중에 있습니다. 평가판 신청시 "베타 버전 신청"을 명기하시면 받아보실 수 있습니다.

쌩뚱맞게도 웬 플래시 버전? 이라고 생각하시는 분들이 있을 것입니다. 소셜 게임에서도 쓰라고? 라고 생각하실테죠.

맞습니다. 뭐 설치하려면 한참 걸리는 PC방, 뭐 설치하고 컴 재부팅했더니 홀라당 언인스톨 되어 버리는 PC방에서는 플래시 게임이 쉬운 선택이긴 합니다. 한국 PC방에서는 보기 힘들지만, 당장 동남아시아를 놀러가봐도 PC방에서 난닝구 한장 걸쳐 입고 열심히 소셜 게임에서 농사를 짓는 분들을 심심찮게 볼 수 있습니다.

왜 농사일까요? 농사 게임 자체가 재미있다는 이유도 있지만, 공학도 입장에서 볼때, 실시간 멀티플레이를 만들기 까다롭기 때문입니다. 서버에서 능동적으로 data push를 할 수 없는 웹 프로토콜은 실시간 멀티플레이를 넣고 싶어도 못 넣게 합니다. 

플래시를 지원하는 프라우드넷은 이러한 문제를 근본적으로 해결합니다. 플래시용 프라우드넷을 이용하면 리니지 1 정도 수준의 MMORPG는 플래시로도 만들 수 있습니다.

아직 공개되지는 않았지만 넷텐션 내부에서는 플래시용 프라우드넷을 이용해서 MMO 슈팅 게임도 개발해서 내부 테스트를 마친 상태입니다. 심지어 한쪽에서는 C++로 만든 클라이언트를 붙여서 "플래시 클라 대 C++ 클라" 대항전도 할 수 있게 만들었습니다. 서버 머신당 동접 10000 이상요? 당연히 되죠.

플래시용 프라우드넷을 도입하세요. 그리고 맨날 농사만 짓는 지긋지긋한 소셜 게임에 태풍을 일으켜보세요!

현재 프라우드넷의 Unity3D (이하 유니티) 버전이 베타 릴리즈 중에 있습니다. 평가판 신청시 "베타 버전 신청"을 명기하시면 받아보실 수 있습니다.

프라우드넷의 유니티 버전은 PC 뿐만 아니라 안드로이드폰, 아이폰에서도 정상 작동이 확인되었습니다. 유니티를 쓸 경우 모바일에서도 프라우드넷을 쓸 수 있음을 의미합니다.

프라우드넷의 서버는 C#이나 C++로 개발할 수 있습니다. 프라우드넷은 네트웍 송수신 루틴을 자동 생성하는 기능이 있는데, 당연히, C# 버전과 C++ 버전을 모두 생성해줍니다. 물론, 네트워크 프로토콜도 서로 호환됩니다. 예를 들어 C++로 만든 클라이언트와 유니티로 만든 클라이언트가 서로 다른 플랫폼에서 같은 보스몹을 사이에 두고 레이드를 할 수 있음도 의미합니다.

유니티용 프라우드넷을 도입하셔서, 모바일용 FPS나 MMORPG도 만들어보시길~! 

한편~! 프라우드넷의 iOS 및 안드로이드 네이티브 버전도 제공될 예정입니다. 유니티를 쓰지 않고 모바일 게임을 개발하시는 분들은 기다려 주세용~

프라우드넷을 사용하고 있는 분들은 이미 아시겠지만, 프라우드넷은 '비공개 기술문답 게시판'이 있습니다. (http://ndn.nettention.com)

비공개 기술문답 게시판은 mantis(www.mantis.org)와 비슷하게 생겼습니다. 비공개라고 불리는 이유는, 프라우드넷 사용자라 하더라도 서로 다른 프로젝트에서 일하시는 분들은 서로의 존재를 알 수 없게 하기 때문입니다.

그런데, mantis보다 더 강화된 기능을 내장하고 있습니다. 이러한 기능들 때문이죠.

• 코드 삽입이 가능합니다.
• 내부 직원 자동 알람 기능이 있습니다.
• 디자인이 더 예쁩니다.

게임 서버는 어디서 어떻게 작동하나

게임 서버와 게임 클라이언트는 그 목적과 역할이 정 반대이다.

게임 클라이언트는 화려한 그래픽과 무거운 용량을 자랑한다. 게임 클라이언트는 사용자에게 극대화된 수준의 그래픽 연출을 보여주기 위해 컴퓨터 하드웨어의 성능을 극한으로 남김 없이 사용해야 한다. 그렇기 때문에, 제아무리 좋은 컴퓨터를 사용해도 쿨링팬이 굉음을 내며 돌아갈 수밖에 없다.

게임 클라이언트는 최대한 화려한 것을 사용자에게 보여줘야 한다. 하지만 게임 서버는 아무리 보여줘 봤자 '랙' 아니면 '서버 다운'뿐이다. 즉 잘 만들어진 게임 서버일수록 그 존재를 드러내지 않아야 한다. 아마도 궁극적인 경지에 오른 게임 서버는 그 자체를 아무도 느끼지 못하는 수준이 아닐까?

앞 편에서 언급했듯이, 게임 서버는 화면에 보여주는 것 없이 뇌 역할을 한다. 그러다 보니 게임 서버의 실행 모습은 클라이언트와 달리 무척 밋밋하게 생겼다. 프리 서버를 써본 독자들은 알겠지만 (웬만하면 그 프리섭이라는 것은 즉시 갖다 버리길 권장한다. 매우 위험한 물건이다.) 프리서버는 화면에 보여주는 것이 무척 밋밋한 프로그램이다.

실제 게임 서버도 마찬가지다. 화면에 보여주는 것이 밋밋하거나 아예 없기도 한다.

안정화된 게임 서버는 'Daemon'이라고 불리는 상태로 작동한다. Daemon 상태로 작동하는 게임 서버는 심지어 컴퓨터를 로그온해 놓지 않은 상태에서조차 물밑에서 작동하고 있다. 얼핏 보면 게임 서버는 그냥 켜 놓은 '멍텅구리 컴퓨터'처럼 보일 뿐이다.

비록 게임 서버 자체는 아무것도 보여주지 않지만, 게임 개발사들은 게임 서버의 실행 상황을 관제하는 프로그램을 자체 개발해서 사용한다. 이를 게임 서버 관리 프로그램이라고 부른다. 게임 서버 관리 프로그램은 게임 서버 컴퓨터에 원격으로 접속해서 게임 서비스 상태를 보거나 제어할 수 있다. 게임 서버와 함께 게임 서버 관리 프로그램도 1급 보안으로 다뤄진다.

게임 서버가 구동되는 환경은 일반 컴퓨터와 완전히 다르다. 정온 정습을 유지하는 밀폐된 공간에, 특수 제작된 얇고 넓은 컴퓨터들이 층층이 쌓여 있고 그 뒤에는 복잡한 케이블 뭉치가 똬리를 틀고 있다. 그리고 랙을 최소하하기 위해 게임 서버는 최소한의 인터넷 백본망이라고 불리는 매우 비싼 네트워크 환경에 장착하기도 한다.

그러다보니 게임 서버를 유지하는 데 필요한 컴퓨터, 소프트웨어, 네트워크 임대, 공간 임대에 들어가는 비용이 막대할 수밖에 없다. 소문에 의하면 월드오브워크래프트는 서버 유지비로 하루에 1억 6천만 원이 들어간다고 한다.

게임 서버 하드웨어 또한 게임 회사에서는 1급 비밀로 다룬다. 예를 들어, 게임 서버를 다른 곳으로 이전할 때 서버 이전 계획을 극소수의 사람만 아는 상태로 조용히 수행한다. 미연의 사고를 방지하기 위해 무장 경비가 호송하는 경우도 있다고 한다.

게임 서버가 구동되는 운영체제는 우리가 일반적으로 쓰고 있는 윈도(Windows)가 아니다. 윈도 서버(Windows Server)나 리눅스(Linux)라고 불리는 특수 목적의 서버 운영체제에서 게임 서버를 실행하는 경우가 일반적이다.

리눅스는 완전히 공짜이다. 그래서 서버 유지비용이 윈도 서버보다 싸다. 게다가 소스 코드가 모두 공개되어 성능 극대화를 위한 여러 가지 기회가 있다. 운영체제의 기능 중 불필요한 것들을 쉽게 뜯어낼 수 있다는 것도 리눅스의 장점이다. 리눅스가 '고성능의 게임 서버를 만들 수 있는 궁극의 선택인 이유'가 여기에 있다.

그러나 리눅스는 일반 윈도보다 사용법도 복잡하고 재미없게 생겼다. 특히 윈도 환경에 익숙해져 버린 게임 개발자들에게 리눅스의 첫인상은 숨 막힐 수밖에 없다. 모든 작업을 그래픽 없이 텍스트만 나오는 곳에서 마우스도 없이, 키보드로만 해야 하기 때문이다.

필자가 게임 서버를 처음 개발하기 시작한 97년에 리눅스는 아직 유명하지 않았고, 대신 유사한 운영체제인 '솔라리스(Solaris)'가 게임 서버용 운영체제의 대세였다. 그 당시에는 게임 개발자들 사이에서도 윈도 서버가 게임 서버로서의 역할을 잘할지 알려지지 않은 상황이었다.

하지만 이미 윈도 프로그램 개발에 익숙해져 버린 필자는, '익숙하지도 않은데다 가격까지 비싼 운영체제와 개발툴'을 쓰는 것이 왠지 낭비로 보였다. 더구나, 장기적으로 게임 클라이언트와 게임 서버 간의 유기적인 작동을 위해서 양쪽 모두 같은 프로그램 개발툴을 사용하는 것이 더 좋다고 판단했다.

결정적으로, 리눅스나 솔라리스에서는 그토록 하고 싶던 스타크래프트가 작동을 못 했다! 당연히 필자뿐만 아니라 다른 회사의 게임 서버 개발자들은 필사적으로(!) 윈도 서버에서의 게임 서버 개발 방법을 연구하기 시작했다. 결국 윈도 서버에서도 얼마든지 고성능의 게임 서버를 개발할 방법을 개척해냈고, 지금에 이르렀다.

게임 서버가 하는 일은 '게임 로직 처리'라고 앞서 언급한 바 있다. 특히 게임 서버는 여러 플레이어간의 상호 작용을 중재하는 역할도 한다.

예를 들어 플레이어1과 플레이어2가 있고 두 플레이어가 대결(PVP)를 한다고 가정하자. 플레이어1이 플레이어2를 때렸을 때 이를 클라이언트에서 때렸다고 판정하지 않는다. 클라이언트는 서버에게 “때렸음을 요청함”만을 보낼 뿐이다.

서버는 “플레이어1이 플레이어2를 때렸음을 요청”받고 이것에 대한 처리 판정을 한다. 즉 플레이어1은 어그로를 먹거나 보라돌이가 되고 플레이어2는 HP가 깎는다. 이 일을 서버가 한다. 그리고 게임 서버는 플레이어1에게 “너 어그로 먹었다”라고, 그리고 플레이어 2에게는 “너 HP 깎였다”라고 알려준다.

패키지 게임과 달리 온라인 게임에서는 게임 로직 처리 말고도 하는 일이 더 있다. 가령 여러 사람의 전투 판정을 중재해주는 역할이나, 누가 게임을 하는지 식별하기 위해 인증(로그인) 처리 한다거나, 사용자가 먹은 아이템들을 저장하고 있다가 다음에 다시 접속할 때 그것을 다시 보여주거나, 랭킹을 보여주기 위해 사용자들의 정보를 정렬하는 역할 등을 해야 한다. 게다가 해킹 시도를 하는 불량 사용자를 찾아서 축출하는 일도 해야 한다. 운영자, 즉 GM을 불러 도움을 받기 위한 일도 하며, 뺏긴 아이템을 누가 가졌는지 추적하기 위한 기록 누적(로그라고 부른다) 역할도 한다.

과거에는 게임 서버 한 대가 이 모든 일을 했다. 하지만 이러한 방식은 다수의 동시접속자를 처리하기 때문에, 서버 랙 혹은 서버 다운이 쉽게 발생한다는 문제가 있다. 우리가 흔히 말하는 ‘서버 다운’ 혹은 ‘섭다’라고 부르는 것은 게임 서버가 오작동해서 정지해 버리는 현상을 말한다. ‘서버 랙’이라고 불리는 것은, 서버가 과부하 걸려서 작동이 심각하게 느려질 때 발생하기도 한다. 서버 다운이나 서버 랙이 생기는 원인 중 하나는 동시접속자가 많을 때이다.

이를 해결하기 위해서, 그리고 게임 서버가 처리할 수 있는 동시접속자를 늘리기 위해서 게임 서버를 여러 대의 머신으로 분산하기도 한다. 지금 온라인 게임 개발에서 게임 서버의 역할 분산은 거의 필수가 되었다.

게임 서버의 역할 분산 구성은 게임의 장르나 특성에 따라 다양하지만, 기본적으로 비슷한 패턴이 있다. MMORPG 게임 서버는 다음과 같이 분산하기도 한다.

게임 서버를 이렇게 역할 분산 구성하면 게임 서버 개발이 훨씬 복잡해지고 까다로워 진다. 그 대가로 많은 동시접속자를 원활하게 처리할 수 있다. 물론, 랙과 서버 다운도 그만큼 줄어들게 되고, 서버 유지비용도 절약된다. 고성능 컴퓨터를 적게 유지하는 것보다 중저성능 컴퓨터를 많이 유지하는 것이 더 저렴하기 때문이다.

게임 서버를 분산 구성할 때 얻는 또 다른 효과는 서버 다운으로 생기는 피해를 더 줄일 수 있다는 데 있다. 만약 게임 서버 한 대가 모든 것을 담당하면 아주 사소한 오류로 게임 서버가 죽으면 게임을 하던 사람들이 예외 없이 모두 게임에서 쫓겨나게 된다. 그렇지만 게임 서버가 여러 컴퓨터로 분산 구성되어 있으면, 서버의 일부 기능만이 작동을 멈춘다. 물론 게임 하는 것이 불편하겠지만 아주 쫓겨나는 것보다는 훨씬 낫다.

예를 들어 메신저 서버가 다운되더라도 메신저만 못 쓸 뿐 게임은 계속 돌아간다. NPC 서버가 죽으면 아무리 월드를 뛰어다녀도 몹 한 마리 없는 적막한 상태가 된다. (그래도 플레이어 대 플레이어 전투는 된다.) 로비 서버가 죽으면 필드에서 몹 사냥은 되지만 정작 인던에 들어가지는 못한다. 게임 서버의 역할 분산은 이렇게 피해 파장을 줄여주는 효과가 있다.

잘 죽지 않는 게임 서버의 핵심에는 이러한 분산 서버 개발의 노고가 담겨 있다.





게임 서버는 누가 만드나

앞서 소개했듯이, 게임 서버는 게임 플레이어의 정보, 보안, 관리 등을 담당한다. 그리고 동시접속자가 많을수록 신속하게 대량의 연산량을 감당해야 한다. 그러다 보니 게임 서버는 그에 특화된 기술을 가진 프로그래머가 개발하는 경우가 일반적이다.

게임 서버 개발자라고 해서 게임 프로그래밍 일반에 대해서 몰라도 되는 것은 아니다. 게임 서버 또한 엄연히 게임 로직 처리를 하기 때문에 게임 프로그래밍 일반에 대해서도 잘할 수 있어야 한다. 특히, 멀티플레이에 관련된 부분이나 보안이 민감한 부분에 대해서는 게임 서버 프로그래머가 주도적으로 개발 업무를 해야 한다. 즉, 게임 기획서에 대해서 깊은 이해를 하고 있어야 하는 것이다.

클라이언트 프로그래머는 게임 연출이나 그래픽 프로그래밍 관련해서 게임 기획에 집중하는 동안, 게임 서버 프로그래머는 게임 플레이 규칙, 커뮤니티, 밸런스 등에 대해서 기획자와 협업(사실상 싸움)을 한다.

클라이언트 프로그래머가 법사의 힐 스킬을 만들기 위해 그래픽 디자이너와 같이 버프 이펙트 연출 방법과 시전 절차 등을 같이 고민하면서 일 하는 동안, 서버 프로그래머는 법사의 힐 스킬이 다른 플레이어에게 영향을 주어 체력이 회복되는 과정에 대해 기획자와 고민하면서 일하게 된다. 즉, 눈에 보이는 부분은 클라이언트 프로그래머가 작업하고, 눈에 안 보이는 부분은 서버 프로그래머가 한다.

클라이언트와 서버를 항상 서로 다른 사람이 분담하는 것은 아니다. 어떤 게임 회사는 게임 서버와 클라이언트를 같은 사람이 담당하되, 업무량을 분산할 뿐이다. 예를 들어 힐 스킬을 만드는 사람은 힐 스킬과 관련된 서버와 클라이언트 작업을 모두 담당하고, 길드 시스템을 만드는 사람은 역시 그것과 관련된 서버와 클라이언트 작업을 모두 담당한다. 이렇게 분산하면 어떤 문제가 발생했을 때 그것이 서버에서 원인인 것인지 아니면 클라이언트인지 금방 파악할 수 있다는 장점이 있다. 물론, 업무 분담을 하더라도 서버의 핵심 기술을 담당하는 개발자가 따로 있다. 클라이언트 쪽에서도 마찬가지다.

게임 서버는 화면에 화려한 그래픽을 보여주는 일이 없다. 그렇지만 온라인 게임의 뇌에 해당하는 부분을 담당하기 때문에 눈에 보이지 않는 것을 한 치의 오차도 없이 작동하도록 세심하게 작업해야 한다. 그러다 보니 화려한 그래픽보다는 건조한 글자 뭉치들 사이에서 일한다. 게임 서버가 작동하는 동안 내부에서 발생하는 것들을 로그(게임 서버가 작동하면서 남기는 기록들. 한 시간에 수천 줄을 남긴다)들을 다루는 일이 많다.

게임 클라이언트는 화려한 그래픽 연출 기법과 처리 성능을 매우 중시한다. 복잡한 수학을 다루는 것은 예사이고, 전산학의 다양한 지식을 동원한다. 게임 프로그래머 자리에 '수학 정석' 책이 괜히 꽂혀있는 것이 아니다. 최신 컴퓨터 하드웨어의 성능을 총동원해서 사용하는 것도 GPU 프로그래밍 등 고도의 기술을 요구한다. 게다가 게임 클라이언트는 프로그램의 복잡도와 개발해야 하는 양 자체도 많다.

한편, 서버 쪽에서는 안정성을 더 중요하게 여긴다. 복잡한 수학 공식이나 알고리즘을 다루는 일은 적지만 분산 서버를 구성하다보면 프로그램이 자연스럽게 복잡해지게 된다. ‘동기화’라는 것을 자주 다루며, 동시에 여러 가지 작업이 서버들 사이에서 실행되게 하면서도 다루는 정보의 순서가 뒤틀리거나 망가지지 않게 하는 것이 그들의 몫이다. 이것을 조금이라도 잘못하게 되면 서버 불안정이나 랙으로 이어지게 되며, 심지어 이러한 결함들을 이용한 아이템 복제나 해킹 등이 일어날 수 있다. 서버 프로그래머가 만드는 게임 서버에 대해서 많은 검토를 반복하는 것도 이러한 문제를 막기 위해서다.

여러분들은 온라인 게임을 하다가 불편 사항이 있으면 운영자(GM)에게 쪽지나 게시판 글을 보낸다. 그러나, 게임 서버 개발자를 포함하여 게임 개발에 참여하는 어떠한 사람도 운영자가 아니다. 개발자와 운영자는 역할이 분명하게 나뉘어 있다. 운영자는 개발자와 게임 유저들 사이에서 창구 역할을 하는 사람들이다.

그들은 게임의 점검이나 패치, 업데이트에 관련해서 어떠한 작업도 주체적으로 할 수 없다. 한편, 개발자는 운영자의 일에 끼어들 수 없다. 가령, 리니지 서버 프로그래머한테 가서 3백만 아데나좀 채워달라는 요청 해봤자 절대 들어줄 수 없다.

20년 전, 용산 전자상가를 돌아다니며 원하던 패키지 게임을 사 들고 집으로 돌아올 때 느꼈던 설렘이 아직도 어렴풋이 기억난다. 아침 일찍 살짝 갑갑한 공기가 감돌던 오락실에 가서 게임 한판 하고 탑 스코어에 필자의 이니셜 세 글자를 찍고 흐뭇해하던 시절이 있었다.

그 당시 게임은 미국 아니면 일본에서 개발된 것이 전부였다. 당연히 국산 게임은 거의 없었다. 1990년이 지나서야 하나 둘 국산 게임이 등장했다. 필자가 게임 업계에 입문했던 1995년, 게임 회사의 환경은 매우 열악했다. 미국과 일본에서 등장하는 멋진 게임들은 그저 '동경의 대상'이었던 시절이다.

(기사 전문 보기 http://www.inven.co.kr/webzine/news/?news=42073 )