[▲ 문대경 아이펀팩토리 대표]
문대경 대표는 1999년 넥슨 입사 후 2005년까지 넥슨에서 출시되는 다수의 프로젝트 서버 프로그램을 책임졌으며, 현재 아이펀팩토리의 대표로 게임서버 엔진인 '아이펀엔진'을 개발하였습니다.
아이펀팩토리가 개발한 '아이펀 엔진'은 네트워크, DB처리, 분산 시스템 등 게임 서버 구현에 필요한 필수 기능을 손쉽게 구현해 개발 시간 단축을 돕는 모바일 게임 서버엔진입니다.
그 첫 번째 시간으로 게임 서비스 구성 방법 연대기에 대해 갤러그부터 H.I.T까지의 게임의 역사를 통해 소개합니다.
* 본 내용은 본지의 편집방향과 일치하지 않을 수도 있습니다.
필자는 대학 3학년 시절이던 1999년 5월, 넥슨에서 처음으로 회사생활을 시작했다. 독자들 입장에서는 실망스러울지 모르겠지만, 게임이 너무 좋아서 학교를 때려치우고 게임 회사에 투신했다거나 하는 감동 스토리는 아니고, 가난한 자취생이 먹고 살기 위해 방학기간 동안 웹개발 알바로 지원을 한 것이다.
면접을 마치고 무척 존경하던 95학번 선배가 게임 개발을 하고 있어서 인사나 하고 가려던 참에 넥슨 정상원 부사장을 우연히 만났다. 당시 그는 넥슨 게임 개발부서의 맏형 역할을 하던 게임업계의 뚝심이었다. 우연히 만났지만 필자가 학과 시스템 관리자 출신이라는 이유만으로 게임 서버 프로그래머로 채용이 됐다.
그 뒤 어쩌다보니 알바가 아니라 휴학을 하고 정직원이 되었고, 다시 어쩌다보니 대학원 유학을 떠나기 전까지 넥슨에서 만 6년이 넘는 시간을 보내며 황금 같던 20대 시간의 대부분을 검은색 터미널 위에 서버 코드를 들여다보며 보내게 되었다. (덕분에 넥슨 나갈 때까지 연애를 못해봤다. 주륵 ㅠㅠ)
필자가 처음 맡은 작업은 당시 동접이 몇 백명도 안되던 바람의 나라의 하급 몬스터의 AI 를 수정하는 일이었다. 지금 생각해보면 굉장히 단순한 작업이었지만, 온라인 게임이라는 것이 낯설던 시절이라 필자에게는 어떤 것이 클라이언트 작업인지, 어떤 것이 서버 작업인지조차 낯설기만 했다.
지금은 그로부터 꽤 많은 시간이 흘렀고, 산업 자체가 고도화 되어 게임 클라이언트와 서버의 개념을 낯설지 않게 느끼는 독자들이 많을 것이다. 그래도 혹시 몰라서 게임 서버가 어떤 일을 하는지, 그리고 우리를 즐겁게 했던 게임들은 어떤 방식으로 서비스가 구성 되었는지에 대해 소개를 하기로 한다.
(우리 회사 담당 직원이 쉽게 써야 된다고 필자를 엄청나게 압박하고 있는데, 주변에 공돌이 밖에 없어서 민간인의 언어로 이야기하는 것에 어려움을 겪고 있는지라 시작도 하기 전부터 걱정이 앞서고 있다. ㅠ 아재개그와 더불어 이것도 넥슨 다니면서 얻은 산재리라..)
■ 눈에 보이는 것이 전부가 아니다: 게임 클라이언트 외에 게임 서버와 디비 서버
우리가 다운로드 받아서 설치하는 것이 바로 게임 클라이언트다. (이후에는 그냥 '클라'라고 부르겠다) 구글 플레이에서 휴대폰에 넷마블의 '모두의 마블'을 설치하든, PC 에 네오위즈 '블레스'를 설치하든, 다운로드 받아 설치하는 것은 모두 클라에 해당한다.
유저가 보고 듣고 조작하는 것이기 때문에 보통 클라를 '게임'으로 오해하게 된다. 사실 이런 오해가 나름 이유가 있는 것이, 서버 없는 게임은 있지만, 클라 없는 게임은 존재하지 않는다. 여러분이 게임 서버와 직접 교감을 하면서 희열을 느끼는 이상한 사람이 아니라면 말이다. 흠좀무..
유저들의 눈에 게임 서버는 보이지 않는다. 그 때문에 와 닿게 설명하기 위해 고민을 많이 했지만 필자의 언어적 표현력으로는 쉽지가 않다. 쉽게 이야기해서 서버는 유저들이 클라를 조작하는 것들을 받아다가 기획자가 의도한 게임 규칙대로 판정을 하고, 유저 정보나 길드 같은 공유 정보를 아래 설명되는 디비 서버에 저장하는 역할을 하는 것이라고 이해하면 되겠다.
만일 저장할 정보가 없다면 사실 서버는 필요없다. 실제로 초창기 싱글 플레이 게임들은 서버가 없었다. 그리고 서버는 물리적인 구분에 의한 것이 아니라 일종의 역할이라고 생각하는 것이 좋다. 아래 부분에서 설명하겠지만, 실제로 P2P 게임에서는 클라중 하나가 서버 역할을 한다.
데이터베이스 (이후 '디비') 는 정보를 모아둔 것을 의미한다. 엄밀히 말하면 그게 파일이 됐든, 별도의 서버가 됐든 모두 디비 라고 불리는 것이 맞는데, 보통 게임 서비스에서는 MS-SQL 이나 MySQL, 혹은 MongoDB 처럼 데이터를 저장하는 별도의 서버 프로그램을 사용한다. 그리고 그런 프로그램을 디비 서버라고 한다. 정보를 저장하는 역할을 담당하기 때문에 여러분이 빽섭이나 롤백을 경험했다면, 디비에 여러분이 최근에 플레이한 내용이 저장이 안된 것이다.
이제 이 3가지 구성 요소가 어떻게 조합이 되면서 게임 형태가 발전되었는지 살펴보자.
■ 싱글 플레이: 세이브 안 되는 게임들
필자보다 더 일찍부터 컴퓨터를 시작하고, 더 일찍부터 게임에 탐닉하던 사람들이 많을 텐데, 8비트 시절의 게임들은 ROM 형태의 팩에 담겨있었고 세이브가 되지 않았다. 그 때문에 몰래 게임을 하다가 들켜서 엄마가 전기코드를 빼버리면 그걸로 끝이었다. 사실 이건 ROM 이라는 이름이 Read Only Memory (읽기 전용 메모리) 의 약자기 때문에 어찌 보면 너무 당연하다. 오락실 게임들 역시 기판에 달려있는 ROM 을 통해서 동작했기 때문에 세이브가 안됐다.
이 형태를 위에 설명한 클라, 게임 서버, 디비 서버라는 용어를 이용해서 설명해보면 어떨까? 그렇다. 클라는 존재하지만, 게임 서버와 디비 서버는 없는 형태다.
■ 싱글 플레이: 세이브 되는 게임들
필자가 경험한 최초의 세이브 가능 게임은 KOEI 사의 삼국지1 이었다. 지금 보면 그래픽이 굉장히 저렴해 보이지만, 이렇게 세이브 되는 게임들은 이전 게임들과 달리 플레이하던 것을 이어서 할 수 있다는 면에서 혁신적이었다. 이로써 플레이 타임이 몇십 시간 몇백 시간 짜리 게임이 가능해졌다.
이 형태에서 클라는 존재하지만, 게임 서버는 없다. 그럼 디비 서버는 어떨까? 앞에서 디비라는 것이 '데이터를 모아두는 것이고 그게 별도의 서버로 존재하는 것이 디비 서버'라고 말한 것이 기억나는가? 그렇다면 이 경우는 디비 서버는 아니지만, 파일로 디비를 관리한 것이라고 생각할 수 있겠다.
■ 멀티 플레이: 세이브 안 되는 게임들
필자가 대학을 진학한 97년에는 지금처럼 초고속 인터넷이 없었다. 인터넷을 사용하기 위해서는 전산원에 가거나 전화 모뎀을 이용해야 했다. (그 때문에 수강 신청일에는 전산원 앞에 길게 줄을 서는 진풍경을 볼 수 있었다. 그립다. 필자의 스무살 시절이..)
그런 97년에 필자와 친구들을 기숙사 폐인으로 만든 게임이 있었으니 바로 워크래프트2 였다. 워크래프트2는 당시엔 혁신적이게 전화 모뎀으로 서로 연결해서 대전이 가능했다. 필자가 있었던 기숙사에는 기숙사 방끼리 내선 전화가 공짜였기 때문에, 많은 학우들이 워크래프트2 때문에 학점을 말아먹었다.
앞에서 게임 서버라는 것은 '판정을 하는 것'이라고 했다. 이 게임은 클라 중 하나가 판정을 담당했다. 따라서 클라 중 하나가 게임 서버 역할을 하는 형태다. (클라가 서버 역할을 하지 않고 퀘이크처럼 유저중 하나가 서버를 별도로 띄우는 경우도 있었다.)
하지만 내 정보가 저장되는 것이 없었기 때문에 디비는 없는 형태다. 2000 년대 하면 빼 놓을 수 없는 게임, 스타크래프트 역시 배틀넷에 붙지 않고 LAN 상으로 멀티 플레이를 할 때 이런 방식으로 동작한다.
■ 멀티 플레이: 클라가 서버에만 접속하면 되는 클라이언트-서버 모델
필자가 넥슨에 입사할 때는 바람의 나라의 동접이 세자리 숫자였다. 그리고 온라인 게임이라는 산업이 존재하지 않았고 그걸로 돈을 버는 것도 요원해 보였다. (나는 그런 점에서 넥슨 김정주 회장님이 대단해 보인다. 산업이 없는 상태에서 사업을 시작해서 산업을 만들어냈으니.)
그런데 불과 몇 년만에 리니지, 포트리스, 뮤, 레드문, 라그나로크 등등 수 많은 온라인 게임들이 쏟아져 나왔고 2000년대는 우리가 흔히 온라인 게임이라 부르는 MMOG 중흥기가 되었다.
온라인 게임이 유저들에게 강하게 어필한 것은 다른 사용자들과의 경쟁과 협업이 가능하다는 점이었다. 기존에 혼자 플레이하던, 혹은 단지 아는 사람 몇몇이 플레이하던 단계에서 임의의 수많은 사람과 플레이하는 단계로의 변화는 가히 혁신적이었다.
이 당시 게임은 대개 유저가 클라를 구동하면 게임 서버에 접속해서 로그인을 마치고, 게임 서버는 유저데이터를 디비 서버에서 불러다가 유저가 플레이함에 따라 게임 플레이를 진행하고 유저 데이터를 갱신해서 디비 서버에 업데이트해주는 형태였다. 이 때 요청은 내가 몬스터를 잡아서 내 경험치를 올리는 것도 있지만, 상대방이 나를 공격해서 내 HP가 깎이거나 힐을 해줘서 HP가 올라가는 것까지도 포함된다.
때문에 여러 유저 (클라) 들이 서로 통신하기 위해서 대규모 사용자를 처리할 수 있는 서버가 필요하게 되었고, 이때부터 게임 서버의 성능이 중요해졌다. (다음 글에서도 다루겠지만, 게임 서버 제작이 까다로운 이유는 많은 동접을 받았을 때의 처리 때문이다.)
온라인 게임에서 클라이언트-서버 모델이 선호된 이유는 게임의 규칙과 판정을 서버 한군데서 결정할 수 있어서 보안상 안전하고 서버 패치만으로 게임 규칙을 바꿀 수 있었기 때문이다. 이 구조에서는 위에 설명된 클라, 게임 서버, 디비 서버가 각각 별도로 존재한다.
■ 멀티 플레이: 게임 플레이 때는 클라끼리 접속하게 하는 P2P 모델
클라-서버 모델은 구조가 직관적이라는 장점이 있지만, 서버에 과부하가 걸리기 쉽고, 대규모 사용자를 지원할 수 있는 서버 제작이 어렵다는 단점이 있었다. 그리고 클라는 무조건 서버와 통신을 하는데, 경우에 따라서는 클라와 서버간의 통신이 느린 경우에 게임이 어렵다는 문제도 있었다. 이는 당시 일반 유저의 ADSL 초고속인터넷이 지금과 달리 3Mbps 정도였고, 서버 회선이 100Mbps 도 넘기 힘든 상황이기에 더욱 중요했다.
예나 지금이나 서버 회선 비용은 게임 서비스 운영 비용 중에서 높은 부분을 차지하는데, 이 때문에 가능한 게임 서버를 덜 거치고 클라끼리 직접 통신하는 P2P 모델이 시도되었다. 대표적인 예가 공전의 히트를 친 넥슨의 크레이지 아케이드 BnB 였다.
이 P2P 방식은 BnB 처럼 주로 방을 만들어서 게임을 하는 게임들에서 많이 사용되었는데, 게임 서버에 로그인하고 유저 데이터를 불러오는 것까지는 동일하지만, 이후의 게임 플레이는 방안의 클라 중에서 판정을 담당하는 클라를 선택해서 다른 클라들이 해당 판정 담당 클라와 통신하는 방식이었다. 판정 담당 클라를 리슨 서버 (listen server) 라고도 했는데, 클라 중 하나가 게임 플레이 시에는 게임 서버 역할을 한 것이다.
P2P 방식은 게임 서버를 거치지 않고 클라끼리 통신하기 때문에 통신 딜레이가 작을 확률이 높고 여러모로 서버에 부하를 주지 않는다는 장점이 있던 반면, 클라가 판정을 담당하기 때문에 해킹의 위험이 있었다. 즉 판정을 담당하게 되는 클라를 조작해서 자기가 모두 이기는 것처럼 할 수 있는 것이다. 실제로 '핵(hack)' 이라고 불리는 클라이언트 해킹이 문제가 되었고, 이를 방지하기 위해서 클라이언트 변조를 막는 다양한 방법이 시도 되었다.
■ 초창기 모바일 게임: 다시 싱글 플레이하던 시절로...
온라인 게임에서 서버의 역할은 상당히 중요했고 대규모 유저 처리를 위해서는 기술이 필요했다. 서버의 부하를 덜기 위해서 P2P 방식을 사용하기도 했지만 P2P 구현은 공유기를 넘어서 통신한다거나 리슨 서버 역할을 하던 클라가 갑자기 죽는 경우 같은 예외 처리 때문에 그 또한 전문적인 지식이 필요했다. 그 때문에 서버 개발자는 언제나 부족한 상태였다.
그런데 초창기 모바일 게임들은 초창기 PC 게임처럼 서버 없이 완전 싱글 플레이거나, 아니면 애니팡처럼 서버는 있더라도 유저의 개인 전적만을 관리하는 단순한 구조였다. 그 때문에 계속해서 서버와의 연결을 맺고 있을 필요도 없었다. 어차피 통신사망이 자꾸 끊길 수 있고 종량제라는 사실 때문에 계속 연결을 맺는 것이 선호되지 않았다.
이 때문에 기존 온라인게임 같은 TCP/UDP 소켓 방식이 아니라, 필요할 때만 통신하는 HTTP 를 이용한 방식이 선호되었고, 덕분에 온라인 서버에서처럼 C++, C#, JAVA 로 직접 게임서버를 만드는 대신 웹서버가 게임 서버로 널리 쓰이게 되었다.
이 방식은 서버를 바닥부터 작성하는 대신, 네트워크 처리에 신경을 덜 써도 되고 웹서버와 연동해서 쓸 수 있는 편리한 다른 기술들을 쉽게 가져다 쓸 수 있어서 게임 서버 개발 기간을 단축시키는데 많은 도움이 되었다.
■ 최근 모바일 게임: 실시간 레이드, 실시간 대전
웹서버를 활용한 게임 서버 개발은 웹서버의 뛰어난 확장성 때문에 널리 이용되었는데, 그냥 새 기계에 웹 서버를 깔고 추가하면 서비스를 계속 키울 수 있었다.
다만 이런 확장성은 웹 서버가 매번 디비 서버에서 데이터를 읽어오는 방식에 의존하기 때문에 온라인 게임에서처럼 클라간에 서로 데이터를 주고 받는 기능 (하다 못해 채팅 같은 기능) 도 디비 서버에 부하를 주는 문제점이 있었다. 또한 클라가 웹 서버로 만들어진 게임 서버에 요청을 보내야만 게임 서버가 응답하는 방식이기 때문에, 클라가 요청하기 전에 게임 서버가 클라에게 데이터를 보낼 수 없다는 문제가 있었다.
이 때문에 모바일에서도 실시간 대전이나 실시간 파티 레이드처럼 실시간성 게임들이 시도됨에 따라 다시 웹서버가 아닌 온라인 게임에서처럼 직접 소켓 서버를 만들어야 되는 경우들이 발생하고 있다. 이때의 구조는 온라인 게임에서의 클라-서버 구조와 거의 동일하다.
그런데 온라인 게임에서와 같은 P2P 구조는 상대적으로 선호되지 않는데, 그건 모바일 네트워크 특성상 리슨 서버와 통신을 못할 확률이 온라인 게임에서보다 훨씬 높기도 하고, 통신사 망에서는 클라끼리 직접 통신하는 것이 원천적으로 불가능하기 때문이기도 하다.
이 때문에 중간에 릴레이 서버를 두기도 하는데 그렇게 되면 결국 클라-서버 모델보다 통신 딜레이가 더 커지는 경우가 발생해서 P2P 의 매력이 떨어지게 된다.
이번 화에서는 좀 길게 게임 서비스 구성 방법이 어떤 식으로 바뀌어왔는지를 살펴봤다. 이미 게임을 개발하는 사람들에게는 지루했을지 모르겠다. 또한 게임 개발을 경험해보지 않은 사람들에게는 어려운 설명이라고 다가갔을 수도 있겠다.
하지만 우리는 그저 클라를 다운로드 받아서 설치하고 플레이하는 게임이 시대에 따라, 그리고 서비스 환경에 따라 필요한 구성 방법이 달라져 왔다는 것만 이해해주길 바란다.
만일 필자가 인벤으로부터 잘리지 않는다면, 다음 편에는 왜 게임 서버 개발이 클라 개발보다 까다로운지에 대한 설명을 지금 분량의 ⅓ 정도로 간략하게 설명하겠다.
KaEnn@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
