[기고칼럼] 자체 서버실부터 GBaaS까지, 게임서버 구축방법의 변천사

칼럼 | 김규만 기자 | 댓글: 13개 |



[▲ 문대경 아이펀팩토리 대표]
인벤에서는 게임업계 1.5세대 인물로 안정적인 게임서버엔진인 아이펀 엔진을 개발한 아이펀팩토리의 문대경 대표님을 모시고 서버 관련 컬럼을 기고 받고 있습니다.

문대경 대표는 서울대 컴퓨터 공학과를 졸업하고 미국 UC Berkeley 에서 컴퓨터 공학 박사 학위를 수여하였고, 1999년 넥슨 입사 후 2005년까지 넥슨에서 출시되는 다수의 게임 개발 프로젝트에서 서버 프로그램을 책임졌습니다.

아이펀팩토리가 개발한 '아이펀 엔진'은 네트워크 처리, DB처리, 분산 처리 등 게임 서버 구현에 필요한 필수 기능을 제공하여 효율적인 게임 개발이 가능하게 하는 게임 서버엔진입니다.

그 여덟번째 시간으로, 자체 서버실부터 각종 클라우드 컴퓨팅을 이용한 서버 구축까지, 게임 서버를 구축하는 방법의 변천사를 살펴보겠습니다.


* 본 내용은 본지의 편집방향과 일치하지 않을 수도 있습니다.

우리는 어디서나 컴퓨팅 자원을 쉽게 접할 수 있는 환경에서 살고 있다. 연산능력에 비해 PC 가격은 지극히 낮아졌고, PC를 직접 구하지 않더라도 클라우드라는 이름으로 가상 서버를 손쉽게 얻어 누구나 서버를 돌릴 수 있는 시대가 되었기 때문이다. 하지만 이런 일은 불과 20년 전만 해도 상상도 할 수 없는 일들이었다. 세월이 지나고 기술이 발전하고 내 머리카락이 빠져 프로스카를 쪼개먹는 일이 필요해지는 동안 게임 서버를 구축하는 방식 역시 많이 변화해왔다.

이번 회에서는 게임 서버를 구축하는 방식들이 어떻게 변화되어 왔는지 살펴보도록 하겠다.



■ 자체 서버실의 시대

우리나라에 초고속 인터넷이 대중화되기 시작한것은 대략 1999년정도이다. 지금은 상상도 할 수 없지만 그 전까지는 인터넷 연결 없이 PC를 사용하는 것이 당연하게 여겨졌다. 물론 "접속"같은 영화에서 보듯 하이텔이나 데이콤, 나우누리같은 PC 통신은 존재했고, 그들 서비스가 전화 PPP라는 방식을 통해서 인터넷 연결을 제공하긴 했지만 속도는 너무 느렸고, 전화비도 많이 나와서 마음대로 쓸 수 있는 것이 아니었다.

그래서 개인용 컴퓨터에서 하는 대부분의 작업은 창세기전 같은 패키지 게임을 설치해서 플레이하거나, 문서작업을 하거나, 아니면 CD-ROM이나 ZIP Drive같은 보조 저장장치로 복사해 온 동영상을 보는 것이 전부였다. 1998년도에 서울대학교 공과대학 전산실에 1배속, 그나마도 걸핏하면 뻑나는 CD Writer가 있는 정도였으니 정보의 이동이라는 것이 얼마나 제약이 컸을지 상상이 갈 것이다.

인터넷이 이런 상황이니 서버를 운영하는 주체도 별로 없었다. 서버는 대학이나 대규모 기업에서 활용하는 것으로 생각했다. 그 때문에 서버를 누군가가 대신 운영해준다는 것 역시 상상하기 어려웠다. 그래서 초창기 게임 서비스는 해당 개발사의 건물 어딘가에 서버실을 만들어 거기에 서버를 쌓아두고 이루어졌다.

내가 재직했던 넥슨 역시 선정릉역 인근 건물에 단지 서버 몇 대를 가지고 바람의나라 서비스를 시작했다. 그 서버는 지금 기준으로는 어이없을지 모르지만, 당시 PC 기준으로는 최첨단인 Pentium II 350Mhz CPU 두 개 꽂고 256MB RAM을 사용한 조립 기계였다. 세월이 지남에 따라 Pentium II가 Pentium III가 되고, 메모리는 512MB까지 쓸 수 있었지만 어쨌거나 기계를 직접 마련해서 회사 건물에 쌓아두는 건 마찬가지였다. 당시에도 엔씨소프트처럼 직접 조립을 하지 않고 인텔 서버를 공급하는 업체에서 사다가 쓰는 회사도 있었고, 인텔 서버가 아니라 SPARC이나 IBM AIX를 쓰는 경우도 있었지만, 어쨌거나 서버는 회사 서버실에 있는 것이 보통이었다.




▲ 그림1: 인텔 Pentium III CPU를 두 개 꽂은 서버. 지금의 CPU와는 달리 팬 일체형에 슬롯 형태로 꽂는 타입이다. 이런 서버들을 서버실 한켠에 쌓아두고 서비스를 했었다. [출처: tyan.com]

이렇게 서버를 직접 두고 서비스한다고 할 때 사용자가 늘어남에 따라 어떤 것이 큰 병목이 되기 시작했을까? 바로 네트워크였다. 예나 지금이나 서버측에서는 네트워크가 큰 병목이 되는데, 일반 인터넷망으로 서비스를 하는 것은 불가능하다. 그래서 전용선을 서버실까지 끌어와야 했는데 이것이 돈도 많이 들고 단순히 돈을 지불한다고 한도 끝도 없이 공급해주는 것도 아니었다. 당시에 넥슨에서 이걸 담당하신 분이 과거 넥슨 공동 대표와 네오플 대표를 하셨고 현재 한국인터넷디지털엔터테인먼트 협회장을 맡고 계신 강신철 회장님인데, 그때 회선 따오려고 통신사 분들과 술을 엄청나게 많이 드시고 그랬다. 나의 저질체력이라면 절대 못할 일이었다.

그리고 서버를 서버실에 두던 시절에는 서버 개발자와 서버 관리자의 경계가 거의 없었다. 서버 프로그램 하는 사람이 자기가 올릴 서버를 관리하는 것은 당연한 것이었고 그 서버 위에 프로그램을 돌리는 거였다. 그래서 서버프로그래머는 단지 프로그램만 짜는게 아니라 OS 의 이것저것도 잘 알고 있어야 했다. 서버에 문제가 생기면? 원격 접속이니 뭐니 필요 없이 서버 프로그래머가 서버실에 가서 고치면 됐다.

그러나 서비스가 커짐에 따라 이렇게 서버실을 직접 운영하는 방식은 당연하게도 많은 문제가 발생하기 시작했다.



■ 서버를 IDC에 맡기는 시대. 그리고 서버 관리자라는 역할 분화

정부의 지원 속에 우리나라에는 초고속 인터넷이 폭발적으로 보급됐다. 덕분에 2000년대 초반에는 수많은 인터넷 서비스들이 태어났고 지금 우리가 알고 있는 대형 IT 회사들이 급성장을 이룰 수 있던 기회의 시기였다. 게임 산업 역시 마찬가지였는데, 이렇게 장사가 잘 됐단 이야기는 서버를 엄청나게 증설할 필요가 있어졌다는 뜻이 된다. 그리고 자체 서버실은 이런 속도를 따라갈 수 없었다.

서버 대수가 많아짐에 따라 생각해야 되는 것들이 무엇이 있을까? 많은 문제들이 있겠지만 몇 가지만 언급해 보겠다.

1) 공간: 당연하지만 서버를 수백 대 넣으려면 엄청나게 큰 공간이 필요하다.

2) 전력: 건물로 끌어올 수 있는 전기 용량이 가장 빨리 병목이 되었다. 이를 무시하고 계속 기계를 집어 넣었다가는 어느 순간 정전이 돼서 전체 서버가 다 내려가게 된다. 나 역시 이런 경우를 수도 없이 경험했다. 그리고 전기 용량을 초과하지 않더라도 정전에 대한 대비가 없는 일반 건물이라는 점을 감안하면 안정적인 전력 공급이 용이하지는 않다. 몇백 대의 서버 모두를 커버할 수 있는 무정전 장치 (UPS) 를 구축하는 것은 비용상 감당하기 어려울 정도로 큰 지출이었다.

3) 네트워크 회선: 앞서 네트워크 회선을 따오는 것이 쉬운 작업이 아니라고 했었다. 더 많은 유저 때문에 더 많은 서버를 붙이게 되면 더 큰 회선이 필요해진다. 그런데 이건 원한다고 바로바로 되는 일이 아니었다. 게임 서비스를 오픈한 뒤에 회선이 부족해서 유저가 튕기거나 새로 오픈한 게임이 너무 잘 돼서 다른 게임에 영향을 주는 경우가 비일비재했다. 이 때문에 프로그래머는 클라이언트-서버 패킷 다이어트도 시도했고, P2P 방식도 시도하기 시작했다.

4) 온도: 계산 능력의 극대화와 공간 활용 때문에 서버 한대에는 여러 개의 CPU 가 장착된다. 그리고 CPU = 열이다. 이는 게임 열심히 하는 우리 유저분들께서 누구보다 잘 알 것이다. 그런 서버가 몇백 대 있다면 어떻게 될까? 서버실 온도를 낮게 유지하기 위해서 처음에는 작은 에어컨 하나로 충분했지만 나중에는 대규모 냉방시설이 필요해진다.

5) 서버 관리 문제: 사람들은 서버가 죽는 것이 예외 상황이라고 생각할지 모르지만, 서버 대수가 늘어남에 따라 죽는 서버가 나오는 것은 일상적인 상황이라고 봐야 된다. 서버가 하루 동안 죽을 확률이 1% 라고 할 때, 서버가 100대라면 하루에 한 대는 평균적으로 죽는다는 뜻이 된다. 그리고 500 대라면 하루에 다섯 대는 죽는다. 기존에 작은 규모의 서버실을 운영했을 때에는 서버 프로그래머가 그냥 적당히 서버 운영도 같이 할 수 있었지만, 이제 서버를 추가하기 위한 작업, 중간에 서버가 죽는 경우의 대응을 생각해보면 전문적인 시스템 관리자가 절실해질 수밖에 없다. 바야흐로 시스템 엔지니어라는 직업의 등장이다.

6) 건물주: 사실 이게 제일 큰 문제 중에 하나인데, 건물주들은 서버가 많은 것을 싫어한다. 건물주가 되어보지 않아서 모든 건물주가 싫어하는지는 모르겠지만, 확실히 많은 건물주들이 싫어한다는 것은 사실이다. 일단 앞서 언급한 전기 용량 증설 공사를 하는 것이 골치 아플뿐더러 화재 위험도 높아지고, 서버가 많아지면 하중 문제가 발생한다.. “도박묵시록 카이지”라는 만화에서 물통을 잔뜩 쌓아놔서 건물을 약간 기울게 하는 것을 기억하는 사람이 있는가? (저작권 때문에 인용할 수가 없다ㅠ) 비슷한 일이 실제로 발생한다. 넥슨 역시 건물 2층에 있던 서버실을 건물이 기운다는 건물주의 항의로 나중에 지하실로 옮겼었다.

어쨌거나 자체적으로 서버실을 운영하는 것은 게임 서비스가 잘 됨에 따라 이처럼 많은 난관에 부딪히게 되었다. 그리고 가려운 곳이 생기면 그걸 긁어주는 사람들이 생기는 법... 바로 IDC 업체들이 두각을 나타내기 시작했다.

IDC 는 앞서 언급한 충분한 전기 용량, 네트워크 회선, 대형 냉방 장치를 갖추고 높은 하중을 견딜 수 있는 대형 건물에 건설되었다. 그리고 서버가 죽는 것을 대신 모니터링해주는 서비스까지 제공해주기 시작했다. 그 때문에 가격은 좀 비싸지만 결과적으로 거의 모든 서비스가 IDC 로 이주하게 되었다. 

IDC 시대를 맞이하여 이제 서버 프로그래머는 더 이상 서버 관리자가 아니게 되었다. 작은 회사에서는 둘을 겸임하는 경우도 많았지만, 많은 회사들에서 별도의 전문적인 서버 관리자들을 두기 시작했다. 그리고 그런 서버 관리자들은 초기에는 하드웨어적인 관리만 했으나 점차 서버에 필요한 프로그램들도 설치하고 관리하기 시작했다.

이제 새로운 서버 환경이 필요하면 서버 관리자에게 요청하고, 서버 프로그래머는 원격으로 서버에 접속해서 게임 서버만 띄우면 되는 방식으로 분업화됐다.



■ IaaS 클라우드 시대

IDC에 서버를 두고 직접 서버실을 운영하는 데 겪는 많은 문제를 해결했지만, 여전히 해결되지 않는 문제들이 존재했다. 바로 서버를 증설하는 데 너무 시간이 오래 걸리고, 일단 서버를 사서 넣으면 나중에 그게 필요 없어져도 계속 들고 있어야 한다는 문제가 생기는 것이다. 설령 조립 서버라고 하더라도 오토바이 퀵이 도착하는 동안의 시간은 소요되고, 그걸 들고 IDC까지 가는 시간이 허비된다. 그리고 거기 OS와 필요한 프로그램을 설치하는 데도 많은 시간이 들었다. 하물며 조립을 해도 이 정도이니 서버를 발주해서 받는 것은 어떻겠는가... 몇 주 단위로 시간이 소요된다.

그런데 이런 문제는 우리나라 게임업계만 겪는 것이 아니라 전 세계 IT회사들이 모두 겪는 문제였다. 그 때문에 클라우드라는 개념이 각광받게 되었다.

먼저, 클라우드라는 것을 간단히 설명하면, "어딘가에 있는 자원을 원할 때 필요한 만큼 쓰고 그 만큼만 돈을 내는 방식"이다.

컴퓨터 네트워크에서는 "대충 이 안에 이런 식으로 네트워크가 연결되어있을 것이다"라는 생략의 의미로 구름 형태를 사용했다. 그 관례로 여기서도 "어딘가에 자원이 있다","내 안에 자원있다"라는 의미로 구름을 쓰기 시작했고, 그래서 '클라우드'라는 이름이 된 것이다.

그리고 쓴 만큼 낸다는 점에서 전기나 수도와 유사한 과금 방식이고 그 때문에 이를 “공과금” 의 영어 단어인 “유틸리티(utility)” 라는 단어를 써서 “유틸리티 컴퓨팅” 이라고도 한다. 즉 전기 콘센트에 플러그를 꽂거나 수도꼭지를 틀어서 쓰는 것처럼 어떤 컴퓨팅 자원을 필요할 때 바로 쓰고 쓴만큼 내는 개념이다. 

여기서 “자원” 이라는 모호한 표현을 썼는데, 이 자원이 뭘 말하느냐에 따라 클라우드 종류가 달라진다. “가상 서버”를 의미한다면 “가상 서버를 필요한 만큼 쓰고 돈을 낸다” 라는 개념이 된다. 이건 인프라를 제공하는 것이되기 때문에 Infrastructure-as-a-Service 라고 한다. “Infra” 는 접두사이지 영어 단어가 아니다. 그러니 “infra” 라고 말하면 콩글리쉬가 된다. “Infrastructure” 가 맞는 표현이다. 그리고 “as-a-Service” 는 “쓴 만큼 돈 내는 방식으로 제공한다” 라는 의미로 생각하면 된다.



▲ 그림2: 클라우드 컴퓨팅은 "자원이 어딘가에 있다"는 의미로 뭉게구름으로 표현하고, 필요할 때 그 뭉게구름에 플러그를 꽂아 쓰는 것처럼 "필요할 때 쓰고, 쓴 만큼 돈을 낸다"라는 개념으로 등장했다. 여기서 자원은 가상 서버와 같은 인프라가 될 수도 있고, 전체 시스템을 구현하기 위한 일부 기능일 수도 있고, 아니면 하나의 완전한 프로그램일 수도 있다. [출처: Wikipedia.org]


이렇게 인프라를 제공하는 것의 선두 업체는 미국 아마존이었다. 아마존을 많은 사람들이 쇼핑몰로 알고 있지만, 아마존은 세계 최대, 그리고 최고의 클라우드 컴퓨팅 회사이다. 그런데 아마존이 가상 서버를 공급하는 이런 IaaS 클라우드를 시작한 것이 블랙프라이데이를 대비해서 서버를 왕창 준비했는데 그 서버들이 평소에 노는 것이 아까워서 서버를 어떻게 임대라도 줘서 활용할 수 없을까를 고민하다가 시작했다는 말도 있고, 그건 유언비어고 원래부터 이 사업을 하려고 했다는 말도 있다. 내가 미국 있을 때 아마존 엔지니어가 발표하는 발표를 몇 번 들을 수 있었는데, 각각 다른 말들을 들었기 때문에 어떤 것이 맞는지는 모르겠다. (혹시 어떤 게 맞는 말인지 아시는 분은 개인적으로 연락이라도.. 쿨럭..)




▲ 그림3: 아마존은 세계 최대/최고의 클라우드 컴퓨팅 회사이다. MS, IBM, 구글 등을 모두 합친 것 보다도 아마존이 압도적으로 높은 시장 점유율을 갖고 있다.


어쨌거나 이런 클라우드 방식으로 서버를 쓸 수 있게 되면서 서버를 준비하는 데 걸리는 시간을 단축하고, 서버가 필요 없어지면 바로 뺄 수 있다는 엄청난 메리트를 가지게 되었다. 더구나 해외로 게임 서비스를 론칭하는 경우에 물리적인 IDC를 구할 필요 없이 자리에 앉아서 해당 지역의 클라우드에 서비스를 준비할 수 있게 된 것도 큰 메리트다.

그런데 주의할 것은 클라우드가 필요할 때만 쓸 수 있고, 쓴 만큼 돈을 낸다는 것이 IDC보다 반드시 싸다는 말은 아니라는 것이다. 잠깐 몇 번 타는 거라면 택시가 돈이 덜 들지만, 매일 장거리로 차를 써야 된다면 자차가 더 저렴할 수 있는 것처럼 클라우드 역시 클라우드의 메리트인 짧은 기간 유연한 운용이라는 측면에서는 가격 경쟁력이 높지만, 계속해서 돌려야 되는 서비스라면 직접 서버를 운영하는 것이 더 쌀 수도 있다. 그 때문에 드롭박스처럼 처음에는 클라우드에서 서비스를 시작했다가 나중에 서비스가 커지면 IDC로 옮기는 경우도 많다. 이는 많은 사람들이 서비스를 시작할 때 놓치는 부분이다. 물론 직접 서버를 운영하면서 고려해야 되는 하드웨어 관리 등의 문제는 있지만 말이다.

IaaS 클라우드 방식이 큰 그림에서 일대 변화를 의미했고, 특히 IDC 시절의 시스템 관리자들에게 이것이 엄청난 변화인 것은 분명하지만, 게임 서버 프로그래머 입장에서는 IaaS 클라우드나 IDC나 큰 차이는 없었다. 어차피 서버를 준비해달라고 하고 그걸 원격에서 접속해서 게임 서버 프로그램을 돌리는 것은 마찬가지였기 때문이다.

그리고 게임 서버는 OS에 프로그램만 몇 개 설치한다고 해결되는 것이 아니다. 그 위에 여러 가지 것들을 더 구현해야 되는 것들이 있게 되는데 이는 IaaS가 해결해주지 못하는 것이었다. 그 때문에 가상 서버만 던져주는 IaaS가 아닌 좀 더 높은 수준의 서비스를 제공하는 PaaS라는 형태의 클라우드가 관심을 받기 시작했다.



■ PaaS 클라우드 시대, 게임 서버 기능의 외주화

앞에서 IaaS 클라우드를 설명할 때 “어딘가에 있는 자원을 쓰고 싶을 때 쓰고 그만큼 돈을 낸다고 했다” 그리고 “자원” 이 가상 서버를 의미할 때 그것이 IaaS 클라우드라고 했다. 예를 들어 가상 서버를 받아와서 그걸 DB 기계로 꾸미는 경우 이는 IaaS 다.

그런데 DB 만 하더라도 서비스가 커짐에 따라 확장을 해야 되고, DB 가 죽는 경우를 대비하기 위해서 복제판을 만들어야 되는 등 단순히 “DB” 가 있다고 해결되지 않는 문제들이 존재한다. 그리고 DB 를 가지고 그 위에 이런 문제를 해결한 무언가를 구현하는 것은 굉장히 난이도가 높은 작업이라서 모든 사람이 이를 할 수도 없다.

이 때문에 단순히 DB 를 설치하기 위한 가상 서버를 주는 것 이상으로, “서비스 규모에 상관없이 마치 한 대의 DB 서버인 양 쓸 수 있는, 그러면서도 DB 에 저장된 것들은 알아서 어딘가에 안전하게 복제되는... “ 같은 좀 더 수준 높은 서비스들이 필요해졌다.

이런 서비스들은 전체 게임 서비스를 구현하기 위한 중요 컴포넌트이면서 기존의 물리적인 인프라 이상의 레벨이다. 이런 것들을 Platform 이라고 부른다. 우리가 알고 있는 플랫폼과는 약간 의미가 다른데, Platform 이라는 것의 의미가 뭔가를 할 수 있게 판을 깔아준 단상 같은 것이라고 생각하면 좀 도움이 될 것이다. 그런 의미에서 카카오톡은 유저 베이스를 활용해서 뭔가를 할 수 있게 판을 깔아준 것이고, 클라우드에서 플랫폼은 어떤 시스템을 손쉽게 구현할 수 있게 판을 깔아준 것.. 처럼 말이다. 

어쨌거나 이처럼 Infrastructure 가 아니라 Platform 을 필요할 때마다 쓸 수 있다는 의미에서 Platform-as-a-Service, PaaS라는 것이 사용되기 시작했다.

가상 서버에 자신이 직접 설치하는 것이 아니라 아마존에서 제공하는 DB 종류, 그리고 구글에서 제공하는 Google App Engine 이라는 제품이 PaaS 에 해당한다.




▲ 그림5. PaaS의 대표적인 예로 프로그래머들에게 많은 사랑을 받은 구글 앱 엔진과 헤로쿠

게임 서버 프로그래머 입장에서 IaaS 가 IDC 사용하는 것과 크게 다른 점이 없었지만, PaaS 를 활용하는 것은 크게 달랐다. 기존에 서버를 가지고 직접 작업 해야 했던 것들을 안 해도 되고, 그리고 자신이 만드는 것보다 훨씬 안정적으로 사용할 수 있었기 때문이다. 앞에서 예를 든 DB 의 경우도 그렇지만, 게임 서비스를 할 때 서버 패치를 하기 위해서 서버 프로그램을 수백 대의 서버에 복제를 했어야 됐는데 이런 기능도 구글 앱 엔진 같은 PaaS 가 제공하는 기능이다. 유사하게 새로 서버가 필요해질 때 알아서 기계를 추가하고 서버 프로그램을 설치해서 서비스를 자동으로 키워주는 것도 (autoscaling 이라고 한다) PaaS 가 제공하는 편리한 기능 중 하나다.

이처럼 OS 위에 직접 프로그램을 올리는 방식이 아니라, OS 보다 한 단계 높은 레벨의 플랫폼에 필요한 프로그램과 기능 호출만 하면 알아서 서버를 만들 수 있다는 측면에서 PaaS 는 획기적이었다. IaaS 가 시스템 관리자에게 큰 변화였다면, PaaS 는 서버 프로그래머에게도 큰 변화였던 것이다.



■ GBaaS. 정형화된 게임 시스템을 사다 쓰는 시대

앞에서 “X-as-a-Service” 라는 것은 X 라는 자원이 필요할 때 전기 콘센트 꽂아 쓰듯 바로 가져다 쓰고 쓴 만큼 돈을 내는 것이라고 말을 했다. 그래서 이 개념이 점차 확장되기 시작했다. 고객 관리 프로그램처럼 하나의 완전한 프로그램을 원할 때 쓰고 쓴 만큼 돈을 내는 것을 SaaS 라는 이름으로 부르고 (사실 나는 기존의 인터넷 서비스들이 결국 우기면 다 SaaS 가 되는 게 아닐까 의심하고 있다.)  그리고 IaaS, PaaS, SaaS 는 그림2에서 보이듯 다루는 자원의 레벨이 높아지는 것을 의미한다.

그런데 모바일 게임 쪽에서는 “서버 구현” 이라는 것을 자원으로 하는 클라우드 서비스들이 나타나기 시작했다. 이 서비스가 전체 게임 서비스 구현에 있어서 일부가 되는지 (PaaS), 아니면 그 자체가 완전한 게임 서비스가 되는지 (SaaS) 모호한 면이 있는데, 어쨌거나 게임 서비스에서 뒷 단 (Game Backend)을 구현해 준다는 의미로 “Game Backend-as-a-Service”, 줄여서 GBaaS 라는 신조어로 부르는 서비스가 나온 것이다.

이 서비스들은 비동기 모바일 게임들이 필요한 기능들이 제한적이라는 점에 착안해서 나온 것이다. 비동기 모바일 게임의 경우 인증 처리나, 결제 영수증 처리, 그리고 인벤토리 관리, 랭킹 관리 등의 공통된 기능이 쓰이기 때문에 이들을 묶어서 이 기능이 필요할 때 외부에서 호출해서 쓰고 호출한 횟수 등에 따라 비용을 지불하는 방식이다.

이는 PaaS 에서부터 이어진 “OS 에 직접 뭔가를 돌리는 게 아니라 필요한 걸 호출해서 가져다 쓴다” 라는 개념의 연장선상이었다. 그 때문에 게임 서버 프로그래머가 하는 일은 직접 대부분의 기능을 프로그래밍하는 것이 아니라 GBaaS 의 기능을 호출해서 로직을 만드는 일이 되었다.

국내에서 서비스되다 없어진 BaaS.io 나 해외의 GameSparks 혹은 Photon Realtime 등이 이런 GBaaS 에 해당한다. 




▲ 그림4. GBaaS 의 한 예인 GameSparks. GBaaS 는 게임 서버에서 사용하는 기능을 하나의 자원처럼 클라우드로 제공하는 방식으로 동작을 한다.

GBaaS 는 정형화된 기능을 손쉽게 가져다 쓸 수 있다는 장점이 있으나, 게임의 콘텐츠가 복잡해짐에 따라 결국 기능을 커스터마이징 가능한 지가 관건이 되기 시작했고, 기능 호출을 위해서 GBaaS 클라우드와 통신을 해야 된다는 것이 문제가 되기 시작했다. 특히 이는 실시간 게임을 구현하는데 있어서 큰 장애가 됐는데, 실시간 플레이를 하는 사용자의 모든 트래픽이 GBaaS 클라우드에 갔다 와야 되는 상황이 발생하기 때문이다.



■ 다시 직접 OS에 프로그램을 설치하는 시대로, 그리고 트레이드오프

앞서 IaaS 까지는 직접 OS 가 주어지고 거기에 프로그램을 올리는 방식이라고 설명을 했었다. 그러던 것이 PaaS 와 GBaaS 로 오면서 OS 에 직접 도는 프로그램이 아닌 외부 기능을 호출하는 방식으로 변화하기 시작했다.

이런 방식은 분명 작업량을 줄여주지만, 반대로 모든 게임이 정형화되어버리는 문제가 있었다. 그 때문에 게임이 복잡해짐에 따라 직접 커스터마이징이 필요한 경우가 많아지기 시작했다. 그 때문에 요즘 게임들은 다시금 직접 OS 위에 프로그램을 얹는 방식으로 회귀하고 있다.

그런데 이는 어떤 기술이 더 우위에 있다는 것을 의미하지는 않는다. 우리가 기성복을 사게 되면 만들어진 것 중에 마음에 드는 것을 골라 입어야 되고, 자신만의 옷을 만들고 싶으면 월계수 양복점 같은 데서 직접 맞춤옷을 해 입을 수 밖에 없는 것처럼, 기술 역시 모든 조건을 만족하는 “은 탄환” 같은 기술은 존재하지 않는다. 그중에서 자신에게 가장 적합한 것을 고를 수밖에 없는 것이다.

댓글

새로고침
새로고침

기사 목록

1 2 3 4 5