[기고칼럼] 냅스터 부터 P2P까지, PC와 모바일의 클라이언트-서버 모델

칼럼 | 정재훈 기자 | 댓글: 10개 |



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

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

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

그 다섯 번째 시간으로 P2P vs. 서버-클라이언트 모델Part II란 타이틀을 가지고 설명하도록 하겠습니다.

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


P2P vs. 클라이언트-서버 모델 Part 2

지난 칼럼에서는 게임 서비스 구성을 위한 네트워크 방식 중에 서버-클라이언트 방식에 대해 살펴봤다. 이 방식은 중앙 집중식이기 때문에 “중심”에 해당하는 서버와 서버 네트워크에 과부하를 유발할 수 있지만, 구현 방법이 직관적이고 간단하다는 장점 때문에 게임뿐만 아니라 네트워크 프로그래밍에 보편적으로 많이 사용되는 방식이라고 했다. 이번 회에서는 서버-클라이언트 방식과 더불어 많이 사용되는 방식 중 하나인 P2P 방식에 대해서 살펴보도록 하자. 그러기에 앞서 파일 공유에 많이 사용되던 P2P가 어떤 방식으로 동작했으며, 그게 어떻게 해서 게임 서비스 환경에 도입되어 사용되게 되었는지 살펴볼 필요가 있다.

요즘은 음악이나 비디오 같은 멀티미디어가 소유보다 소비의 관점으로 인식되는 것 같다. MP3 나 영화 파일을 내려받아서 소유하기보다는 벅스나 멜론, IPTV 혹은 YouTube 같은 스트리밍 서비스를 이용하는 경우가 더 일반적인 게 되었다. 이는 모바일 디바이스와 모바일 네트워크의 비약적 발전 때문에 파일을 복사하는 것이 귀찮아진 것도 있고, 즉각적인 것을 선호하는 사회 변화의 속도와 스트리밍 방식의 실시간적 편리함 때문이기도 하고, 팀 과제에 참여 안 한 선배 이름을 빼겠다는 음료 광고 및 그 광고의 “그런데 그것이 실제로 일어났습니다" 일화에서 보듯 저작권에 대한 사회 전반적 인식의 성숙 때문이기도 한 것 같다.

그러나 몇 년 전까지만 해도 멀티미디어 파일에 대한 저작권 인식은 지금보다 훨씬 흐릿해서 어둠의 경로를 통한 불법 다운로드는 굉장히 공공연한 일이었다. 심지어 습관적으로 스마트폰을 들여다보는 것처럼 인터넷이나 CD/DVD writer가 놀고 있으면 초조함을 느껴서 열심히 다운로드 받고 구워놓는 사람들도 많았다. (비록 그때 구워 놓은 CD/DVD 중에 대부분은 그 이후로 열어보지도 않았지만….) 그리고 그런 일이 가능했던 것은 수많은 파일 공유 프로그램 덕이었다. 그 중 가장 중요했던 프로그램이 냅스터다.

냅스터 (Napster)

파일 공유 프로그램의 역사에서 냅스터를 빼놓고 이야기할 수는 없다. 냅스터는 1999년에 서비스되기 시작되어, 편리한 음악 파일 검색 기능으로 급속도로 확산하였다가, 메탈리카와 닥터 드레 (헤드폰의 그 닥터 드레가 맞다) 그리고 미국 음반 산업 협회 (RIAA) 등이 제기한 저작권법 위반 소송으로 2001년 서비스를 내리게 되었다. (국내에서는 “소리바다" 라는 유사한 음악 공유 프로그램이 2000년도에 큰 인기를 얻었다.)




냅스터는 실제 파일은 각 사용자 컴퓨터에 그대로 두고, 음악 파일 이름과 이를 보유한 사용자 컴퓨터의 IP를 냅스터 서버에 저장하는 단순한 방식으로 동작했다. 그리고 해당 이름의 파일을 검색하면 냅스터 서버에 저장된 정보를 통해 실제 그 파일을 보유한 컴퓨터의 IP를 알려주고, 그 컴퓨터로부터 직접 파일을 다운로드 받게끔 했다. 그리고 이렇게 사용자 (Peer) 가 다른 사용자 (Peer) 에게 데이터를 전송해주는 방식 때문에 Peer-to-Peer 라고 표현되었고, 줄여서 P2P 가 되었다. (굳이 설명충 빙의를 하자면, to가 two와 발음이 비슷하다고 해서 2라고 줄이는 경우가 많다. B2B, B2C, O2O...)



▲ 냅스터 서비스 구성도.

위의 그림 1에서 볼 수 있듯, 이 서비스는 1) MP3 파일 정보를 인덱스 서버에 등록하는 과정과 2) 이를 이용해 파일의 위치 (컴퓨터) 를 찾는 과정, 3) 실제로 파일을 전송받는 과정으로 이루어진다. 그리고 실제로 파일을 전송받는 과정은 peer 들 끼리 통신을 하는 것이지만, 나머지 과정은 (파일 이름을 등록하고, 파일을 보유한 컴퓨터를 찾아내는 과정) 냅스터 서버와 통신하는 클라이언트-서버 모델이다.

비록 냅스터는 실제로 음악 파일을 전혀 보관하지 않았지만, MP3 파일을 보유한 사용자 IP 주소 정보를 제공해서 파일을 전송받을 수 있게 도왔다는 이유로 저작권 위반 혐의를 받게 된 것이다. 즉, 앞에서 설명한 파일의 위치를 찾기 위한 클라이언트-서버 부분이 문제가 되었다. 그리고 비단 저작권법 문제뿐만 아니라 몇천만의 사용자를 처리하는데 이 클라이언트-서버 부분은 당연히 서버에 큰 부하를 주게 되었다.

그 때문에 gnutella, eDonkey, eMule, Overnet, BitTorrent, Vuze 등 이후의 파일 공유 프로그램들은 파일의 위치를 찾는 부분을 계층화하거나 P2P 화하거나 하는 등 많은 개선의 시도를 하게 되었다. 그리고 이런 노력의 결과로 2000년대 중반까지는 컴퓨터 네트워킹 관련된 학술 연구에서도 P2P는 굉장히 활발한 주제였다. 단순해 보이는데, 대체 뭐 더 팔 게 있다고 활발한 주제가 된 것일까? 이런 연구 주제들을 보면 P2P 통신 방식의 구현에서 중요하게 고려해야 할 점들을 시사한다. 그리고 이 점들은 게임 서비스에 P2P를 적용할 때도 중요한 고려 사항이 될 수 밖에 없다.

과제 1. 상대방 찾기

냅스터의 경우 음악 파일 이름을 사용자들로부터 수집해서 냅스터 서버가 보관하고 있다가 필요한 파일을 검색하면 그걸 소유한 사용자 IP 를 알려주는 방식을 썼다고 했다. 그리고 이는 당연히 클라이언트-서버 모델이고 사용량이 많아질 수록 서버 쪽에 큰 부하를 주게 되므로 확장 가능한 방법이 아니다. 그리고 다루는 데이터가 저작권물이라면 법적인 책임까지 떠안게 된다.

이를 피하기 위해서 Gnutella 같은 경우는 원하는 파일을 찾는 요청을 전체 사용자들에게 다 뿌리는 방식으로 구현을 하였다. 이렇게 모든 사람에게 다 뿌리는 것을 “방송”이라는 영어 단어를 써서 브로드캐스팅 (broadcasting) 이라고 한다. 브로드캐스팅은 공중파 방송처럼 뿌리는 쪽이 소수일 때에는 단 한 번의 발송으로 모두에게 전달되는 효과적인 방식이 될 수 있지만, 브로드캐스팅하는 쪽이 많아질수록 급속도로 비효율적이 된다. 이 방법으로 천만 명이 파일 공유를 한다면 나는 아무것도 안 하고 있어도 약 천만 개의 쓸데없는 패킷을 받아야 하고 그 때문에 네트워크가 풀 나서 오버워치를 할 수 없게 된다.



▲ Gnutella 는 모든 사용자들에게 요청을 뿌리는 방식으로 확장성에 큰 문제가 있었다. (출처: http://computer.howstuffworks.com/file-sharing3.htm)

이 때문에 완전히 클라이언트-서버 방식을 택하기도 어렵고, 마구잡이 브로드캐스팅 방식도 어려워지기 때문에 사용자들 간에 체계화된 방식으로 연결관계를 맺는 방안들이 제안되었다. 이를 분산 환경에서 해시 테이블 구현한 것과 같다고 해서 Distributed Hash Table (DHT) 라고 하는데, 굳이 이 용어를 기억하지 않더라도 사용자가 많아짐에 따라 상대방 찾기는 복잡해지고 이를 구조화 할 방법이 필요하다는 것을 알 수 있을 것이다. 그리고… 세상에 좋은 것만 취할 수 없듯이, 이렇게 구조화하게 되면 사용자들이 들락날락거림에 따라 그 구조가 깨지지 않게 유지하는 것이 어려운 문제가 된다.

과제 2. 사용자가 들락날락하는 문제 (Churn)

사용자가 자신의 위치를 서버에 저장하는 클라이언트-서버 방식이나, 아니면 마구잡이로 필요할 때마다 브로드캐스팅을 날리는 방식이라면 다른 사용자가 들락날락 거려도 큰 문제는 안 될 것이다. 하지만, 앞에서 이 두 방법은 모두 확장성에 문제가 있는 방식이기 때문에 “일정 규칙대로 클라이언트들끼리 통신하게” 만들어야 한다고 했다. 그리고 이렇게 일정 규칙대로 통신하는데 중간에 있는 사용자가 갑자기 나가거나 새로운 사용자가 갑툭튀한다면 문제는 복잡해진다.

예를 들어, 우리가 전체 사용자를 줄을 세우고 파일을 찾을 때까지 차례로 물어보는 방식을 썼다고 하자. 이 경우에 다음 사용자가 나가버린다면 어떻게 될까? 단순히 생각하면 그런 경우를 대비해서 다음 사용자의 그다음 사용자를 기억하면 될 것 같지만, 이는 그마저도 나가버리면 다시 그다음 사용자가 필요해지는 한도 끝도 없는 방식이 되어버린다.

이렇게 사용자가 들락 날락 거리는 것을 Churn이라고 하는데, P2P에서는 이런 churn 을 다루는 것이 매우 중요하다. 그리고 이는 단순히 통신할 상대방을 찾기 위한 경우만 필요한 게 아니라, 실제 상대방과 통신을 하고 있을 때도 중요하다는 점을 기억해주기 바란다. 내가 진또배기.mp3 를 내려받고 있었는데 나에게 파일을 주던 사용자가 나가버린다면 나는 다른 사람으로부터 그 파일을 받아야 하기 때문이다.



▲ 사용자간 연결 관계를 구조화해서 관리하는 대부분의 P2P 프로토콜은 이웃 사용자 리스트를 관리하는데, 이때 churn 발생 시 이웃 사용자 리스트를 얼마나 적게 바꿔도 되는지가 중요한 요소이다. 그림은 P2P 프로토콜 중 하나인 Chord 의 “이웃 사용자 테이블” 예시. (출처: http://www.slideshare.net/GertThijs/chord-presentation)


과제 3. 사용자가 정정당당하게끔 강제하기 혹은 그렇게 되도록 동기 부여하기

P2P는 사용자(peer)가 다른 사용자(peer)로부터 서비스를 받는 것이라고 했다. 그리고 이 방법이 잘 동작하기 위해서는 다른 사용자에게 성실하게 서비스를 제공할 수 있게 강제하거나 최소한 그렇게 하는 것이 좋다고 인식하게끔 동기를 유발할 필요가 있다.

예를 들어 BitTorrent 을 실행하고 있으면 CPU와 네트워크를 잡아먹기 때문에, 원활한 오버워치 플레이를 위해 나는 아마도 진또배기.mp3 를 내려받자마자 BitTorrent 를 꺼버릴 것이다. 그런데 P2P는 모든 사용자가 이렇게 이기적인 행동을 하는 경우 제대로 동작할 수 없다. 그러니 오버 워치를 희생하더라도 계속해서 파일 공유를 하게끔 강제하거나 적어도 공유할 수 있는 동기부여를 하는 것이 필요해진다. 이를 위해 업로드 양에 따른 다운로드 양이나 속도를 조절하는 방식 등 다양한 방식이 동원됐다. 그러나 이걸 강제하는 것은 지극히 어렵다. BitTorrent 는 Tit-for-tat 전략이라는 것을 이론적인 배경으로 쓰고 있지만, 이걸 좀 더 잘 바꾸겠다면서 변형한 연구 논문만도 수도 없이 많다.

그리고 그나마 지금까지의 예는 P2P의 룰을 안 지키긴 했지만 그다지 파괴적이지는 않았다. 그런데 만일 해킹한 클라이언트가 있다면 어떻게 될까? 해!킹!클!라! 이 부분은 파일 전송에서뿐만 아니라 게임 서비스 구축에서도 직접적인 충격이 되기 때문에 아래에서 다시 살펴보겠다.

과제 4. 사용자간 연결 보장하기 (NAT traversal)

앞의 세 가지 과제가 시스템 디자인적인 문제였다면, 사용자 간에 실제로 연결을 맺고 통신을 하는 것은 좀 더 현실적이고 테크닉적인 문제다.

우리가 사용하는 인터넷의 주소 체계는 마음대로 배정하는 32bit 숫자로 이루어진다. 그리고 이 덕분에 배정 가능한 IP의 전체 수는 2의 32 승인 약 43억개 정도 된다. 그러나 안타깝게도 특정 용도로 배정된 주소들 때문에 실제로 사용 가능한 IP의 숫자는 이보다 적다. 그리고 이미 우리는 사실상 이 IP 주소를 모두 소진한 상태다.

이런 문제를 극복하기 위해서 고안된 것이 128bit 주소 체계인 IPv6 인데, 안타깝게도 IPv6 스펙이 발표된 지 20년이 다 되어가지만, 아직까지 완벽하게 IPv6 가 도입되지는 못했다. 주요 이유로는 아무리 표준안이 제안되더라도 시스코 같은 장비 업체가 이를 장비로 만들어 줘야 되고, 그리고 기업들이 막대한 돈을 들여 백본을 포함한 기존 장비들을 모두 교체해줘야 되고, IPv4 만 사용하게끔 된 프로그램들이 모두 수정되어야 되기 때문이다. 애플이 IPv6를 지원하지 않는 앱들을 앱스토어 심사에서 떨어뜨리기 시작했는데, 이와 같은 강제가 없다면 아마 앞으로도 오랫동안 IPv6 가 주류가 되기는 어려울지도 모른다.

필요는 발명의 어머니라고, 이 때문에 중간 단계로 사설 IP 가 활용되기 시작했다. 사설 IP 는 어떤 곳에서든 인정되는 공인 IP 가 아니라 그 안에서만 통용되는 IP 라고 생각하면 된다. 예를 들어 우리 회사의 “미친개”는 나 하나지만, 회사별로 “미친개" 는 서로 다른 사람을 지칭하는 것과 유사하다고나 할까…. (예를 들어 놓고 보니 참 슬프군염…)

이 때문에 사설 IP는 해당 네트워크에서만 접근 가능하게 된다. 그럼 사설 IP는 인터넷으로 연결이 안 되는가? 물론 그러면 안 되기에 사설 IP를 공인 IP 로 매칭해주는 방식이 사용된다. 우리가 흔히 말하는 “공유기" 라는 역할인데 정확히는 Network Address Translation (NAT) 이다. 공유기는 이런 NAT 기능이 들어가 있는 장비라고 생각하면 된다.

그런데 NAT 는 내부에 있는 사설 IP 가 외부로 통신을 시작할 때 <사설 IP, 사설 포트, 공인 IP, 공인 포트> 이런 형태로 기억하고 이후에 외부에서 패킷이 들어오면 역으로 해당 사설 IP 에게 보내주는 방식으로 동작한다. 이 때 중요한 것이 반드시 내부에서 외부로 먼저 통신을 해야 되고, 외부에서 먼저 들어올 수는 없다는 것이다.

이렇게 외부에서의 선진입을 허용하지 않는 NAT 의 동작 방식은 보안적인 이점이 되기도 하지만, P2P 통신에서는 상당한 장애가 된다. 공유기 보급으로 이미 상당 경우 컴퓨터/스마트폰 등이 공유기 안에서 NAT 의 영향을 받고 있는데 서로 통신해야 되는 두 기기가 모두 각각의 공유기에 물려 있다면 어느 쪽도 먼저 상대방에 닿을 수 없는 교착 상태에 빠지기 때문이다.

이 때문에 NAT 를 뚫고 통신하는 테크닉이 필요하고 그걸 NAT traversal 이라고 한다. 게임 등에서 많이 쓰이는 홀 펀칭 등이 NAT traversal 의 한 방식이다. (외부로 패킷 한방만 날려주면 거기에 구멍이 뚫리듯 외부에서 들어올 수 있다고 하여 이런 이름이 붙었다) 그런데 안타깝게도 NAT의 구현에 대해서는 표준이 없으므로 모든 장비가 같은 NAT 방식을 쓰지는 않는다. 다시 말해 어떤 경우든 동작하는 NAT traversal은 사실상 존재하지 않는다는 뜻이다.

PC 온라인 게임에서 P2P 기술의 적용 동기

지금까지 파일 공유에서의 P2P에 대해서 설명했다. 그런데 파일 공유의 세상에 있던 P2P가 왜 게임 구현에 사용되게 된 것일까?

내가 기억하는 바로 게임에 P2P를 사용한 거의 최초의 경우이면서 상업적으로 성공을 한 것은, 모글루의 박세희 대표가 넥슨 재직 시절에 프로그래밍한 크레이지 아케이드 BnB 일 것이다. (참고로 남자다.)



▲ 당시 폭발적인 인기를 끈 넥슨의 크아 BnB

크아 BnB 는 사용자 간 움직임에 대한 빠른 동기화와 이에 따른 손맛이 재미요소였기 때문에 움직임 패킷을 신속하게 전달하는 것이 중요했고, 이 때문에 P2P가 시도되었다. (같은 패킷을 서버로도 전송했는데 서버 쪽으로 전송하는 것은 검증을 위한 처리로 사용되었다.) 이런 이유에는 우리가 사용하는 인터넷이 동작하는 방식과 연관이 있다.

우리가 독일의 현 난민 정책을 알아보기 위해서 독일 정부 사이트에 접속한다고 해보자. 아마 많은 사람이 가장 빠른 경로로 패킷이 갈 것으로 생각한다. 하지만 안타깝게도 그렇지 않다.

빠른 경로로 가는 것이 아니라 망 사업자 간의 이해관계와 정부 규제 등 다양한 정책적인 영향을 받아서 경로가 결정된다. 가령, 대한민국의 패킷들은 북한과 관련이 있을 나라는 거치지 않게끔 전송될 것이고, 경로도 중국을 통해서 가는 방법과 해저 광케이블로 미국을 거쳐 가는 방법 중 내 통신망 사업자가 더 싸게 쓸 수 있는 회선을 따라간다. 아래 가상의 시나리오를 그린 그림을 보자.



▲ 인터넷은 정책 기반으로 패킷을 전송한다. 미국을 거쳐 가는 것이 더 느리더라도 통신망 사업자로서 그게 비용을 줄일 수 있다면 느린 길을 택할 수도 있다. (주의: 위 그림의 통신 사업자 이름은 임의로 작성된 것이며, 딜레이와 트래픽 단가 역시 가상의 숫자임)


이 때문에 인터넷은 정책 기반 (policy-based) 방식으로 패킷을 전달한다고 한다. 반면 회사 안의 인트라넷에 접속하는 경우는 딜레이나 적은 횟수의 전달 같은 산술적 기준으로 패킷을 전달하며 이를 메트릭 기반 (metric-based) 방식이라고 한다.

인터넷이 정책 기반으로 패킷을 전달하기 때문의 경우에 따라 클라에서 서버로 갔다가 다른 클라로 가는 것보다 클라 간에 직접 통신하는 것이 더 빠를 수도 있다. 여기서 주의할 것은 “빠를 수도 있다."이지 “빠르다" 가 아니라는 것이다. 대부분은 서버는 회선이 잘 갖춰진 데이터센터 안에 있기 때문에 클라와 서버 간의 통신 속도는 둘 사이가 물리적으로 상당히 멀리 떨어진 경우가 아니라면 그다지 나쁘지 않다. 그렇기 때문에, 속도 때문이라면 P2P와 서버를 거쳐서 통신하는 두 경우를 재보고 더 빠른 경로를 택하는 것이 더 맞는 선택이다. 다만 한국처럼 지역이 좁고 클라들이 같은 통신사를 쓸 가능성이 큰 경우, 서버를 거치는 것보다 클라끼리 통신하는 것이 더 빠를 가능성이 큰 것도 분명히 사실이다.

그런데 속도는 보장할 수 없지만, 확실하게 보장할 수 있는 것이 있다. 지금까지의 내용을 잘 따라온 분이라면 쉽게 예측할 수 있다. 뭘까? 그렇다. 서버 트래픽을 쓰지 않기 때문에 서버 쪽 부하가 줄어든다는 것이다. 따라서 서버 부하가 P2P 도입 목적이라면 이는 적절한 선택이다.

어쨌거나, 파일 공유의 영역에만 있던 P2P 가 게임에 도입되기 시작한 것은 인터넷이 가장 빠른 길을 택해서 패킷을 전달하는 것이 아니라는 사실 때문에 클라끼리의 직접 통신이 더 빠를 수도 있어서였다. 그럼 게임에서는 앞에서 언급했던 과제들을 어떤 방식으로 극복했을까?

PC 온라인 게임에서의 P2P 도입 시 작용한 환경

PC 온라인 게임에서의 P2P는 유선 인터넷이라는 점을 깔고 들어갔기 때문에 구현에 상당히 유리한 점이 많았다.

통신 상대방 찾기: P2P 방식으로 구현되는 게임들은 아케이드 게임이나 FPS 처럼 게임이 한 판 단위로 나뉘는 경우이고, 이 경우에 상대방을 찾는다는 것은 매치 메이킹을 의미한다. 그 때문에 게임에 P2P 가 도입되는 경우 대부분은 로비 서버나 매치 메이킹 서버를 이용한 클라이언트-서버 방식으로 상대방을 찾는 방식이 이용되었다. 비록 서버에 부하가 걸리긴 하지만, 매칭을 위해서는 괜찮은 방식이다. 매칭 규칙도 클라이언트 패치 없이 변경할 수 있다는 장점이 있다. 또한, 클라끼리 통신하는 것도 서버 역할의 클라를 정하고 그 클라와 통신을 하는 방식과 그냥 모든 클라에게 브로드캐스팅 하는 방식 모두 통용되었다. 일반적인 파일 전송 P2P에서는 모든 클라들에게 브로드캐스팅하는 방식은 말도 안 되는 일이지만, 판 단위 게임의 특성상 통신에 관여하는 클라 숫자가 적기 때문에 게임에서는 충분히 가능하다.

들락날락 하는 문제: PC는 대부분 유선 인터넷에 연결된다. 그 때문에 네트워크가 끊기는 문제는 사실상 흔하지 않았다. 그래서 특정 클라이언트가 끊겨서 나가는 경우 아예 판을 깨버리는 간단한 방법도 괜찮았다. 그리고 끊기는 일이 많은 경우 의도적일 수 있으므로 유저에게 패널티를 줄 수도 있었다. 좀 더 정교하게 만드는 경우 끊긴 사용자 대신 AI 가 플레이하게 하는 것도 가능하지만, 모든 클라가 각자 판정하는 것이 아니라 특정 클라가 서버 역할로 판정을 전담하고 있었다면, 판정을 담당하던 클라가 튕기는 경우 판을 깰 수밖에 없었다. 어쨌거나 유선 인터넷은 그렇게 자주 끊기는 게 아니었기 때문에 이게 크게 문제가 되지는 않았다.

서버 역할을 하게 하는 동기 부여 및 해킹 방지: 이 역시 유선 인터넷이라는 좋은 특성이 있었기 때문에 자연스럽게 해결이 되었다. 유선 인터넷은 종량제가 아니며, 일반적으로 대역폭이 충분하다. 그 때문에 클라가 서버 역할을 하는 것에 크게 거부감을 가질 이유가 없었다. 이때 서버 역할의 클라가 더 유리한 위치를 차지할 수 있는 이유는 자신은 딜레이 없이 판정하지만, 상대방 패킷은 자신에게 도착해야만 판정이 시작된다는 점 때문이다. 이를 이용해 상대방 패킷을 의도적으로 지연시키는 방식을 생각할 수 있는데, 유선 인터넷은 빠르고 안정적이기 때문에 일정 이상의 딜레이가 넘어가면 치팅 의심 행동으로 튕겨버리는 간단한 방식으로도 방지할 수 있었다. 다만, 클라이언트 자체를 해킹해서 판정을 잘못하게 하는 것은 여전히 별도의 보안 솔루션이 필요했다.

NAT 극복: 비록 NAT 자체가 표준이 없다고는 하지만, 가정이나 회사에서 사용되는 공유기는 거의 비슷한 방식으로 동작했고, 그 때문에 일단 내부에 있는 컴퓨터가 패킷을 보내서 공유기에 <사설 IP, 공인 IP> 쌍을 저장하게 하는 홀 펀칭 기술이 가능했다.

모바일 게임에서의 P2P 도입 시 환경적 어려움

반면 모바일 게임은 네트워크적인 가정에서 받을 수 있는 도움이 없었다. IP는 기지국을 옮겨가거나 모바일 망과 WiFi를 오가면서 수시로 바뀔 수 있었고, 무선이라는 특성 때문에 패킷의 딜레이도 더 크다. 이 때문에 이를 이용한 해킹 등도 가능하다.

통신 상대방 찾기: 이는 궁극적으로 PC 온라인에서처럼 매치메이킹을 위해 클라이언트-서버 방식을 쓰기 때문에 모바일 게임이라고 큰 차이는 없다.

들락날락 하는 문제: WiFi는 상대적으로 문제가 덜하지만, 모바일 망은 네트워크 간 이동 등의 이유 때문에 순간이 많이 발생한다. 이 때문에 PC 온라인에서는 처리할 필요가 없었던 들락날락거림 (churn) 을 처리해줘야 하는 상황이 되었다. PC 온라인처럼 마구잡이로 판을 깨버리면 사실 거의 플레이할 수 없게 되기 때문이다. 특히 서버 역할을 하는 클라이언트가 안정적이지 못하고 들락날락하게 되는 경우 문제는 아주 복잡해진다.

서버 역할의 동기 부여: 모바일 망은 유선 인터넷과 달리 종량제다. 비록 무제한 요금제라고 하더라도 일정 트래픽 이후로는 속도가 급격히 줄어든다. 그 때문에 클라이언트가 서버 역할을 하는 것은 비용적으로 부담될 수밖에 없다. 개발사가 내야 할 서버 비용을 내가 추가적인 데이터 요금으로 부담하는 꼴이 되기 때문이다. 그러나 안타깝게도 무선망의 종량제는 계속 유지될 것으로 보인다. 통신 사업자로서 이미 전 세계적으로 자리 잡은 종량제 데이터 요금제를 풀어줄 이유도 없고, 케이블만 깔면 대역폭을 확보할 수 있는 유선 인터넷과 달리 무선 통신은 비싼 비용을 내고 주파수를 정부로부터 추가 임대해야 대역폭을 늘릴 수 있기 때문이다. 그나마도 남는 주파수가 있을 때 경매로 임대한다.



▲ 무선망은 차세대 이동 통신 기술로의 전환이 아닌 한 고가의 주파수 확보를 통해서만 대역폭을 늘릴 수 있다. 그러나 주파수는 국가적/지구적으로 희소한 자원이다. (출처: http://www.mt.co.kr/view/mtview.php?type=1&no=2016050209085838153&outlink=1)

해킹 방지: 무선망 환경에서 안정적인 딜레이가 보장되지 않기 때문에, 무선망에서 동작하는 P2P 게임은 특정 이상의 딜레이가 그냥 느린 것인지 아니면 의도적으로 느리게 만든 것인지 알기 어렵다. 가령 와이파이에 연결해서 플레이하는 클라이언트가 자신이 서버라는 사실을 알게 되면 공유기 랜선을 뽑아버리는 단순한 행동만으로도 스마트폰에서는 와이파이 네트워크는 연결된 것으로 잡히지만, 나는 다른 클라들의 패킷을 모두 지연시킬 수 있게 된다. 극단적으로는 이 틈을 타서 본인 혼자 상대방을 전부 킬 하는 것도 가능하다.

NAT 극복: 앞서 설명한 대로 무선망은 주파수라는 굉장히 희소한 자원을 기반으로 한다. 이 때문에 망 사업자 입장에서는 보다 정교하게 네트워크를 제어하기를 원한다. 이 때문에 무선망 사업자들이 사용하는 수억 원의 장비는 가정용 공유기보다 훨씬 복잡한 방식으로 NAT을 관리하며, 단순히 외부로 홀 펀칭 패킷을 보냈다고 그 구멍을 타고 내부 장비와 통신하게 해주지 않는다. (이를 Symmetric NAT이라고 한다)

이런 문제들을 극복하기 위해서 릴레이 서버를 통해 통신하게 하는 경우도 있지만, 릴레이 서버를 두는 경우는 결국 P2P의 최대 이점인 클라이언트 간의 직접 통신에 따른 서버 부하 감소와 통신 속도 개선이라는 것을 기대할 수 없게 된다. 릴레이 서버가 병목이 되고, 릴레이를 거치면서 불필요한 딜레이가 추가될 수 있기 때문이다.




▲ 릴레이를 이용하는 경우 릴레이 서버 과부하 문제가 발생할 수 있고, 패킷 전달 단계가 더 추가된다.


결론: 기술의 적용은 서비스 환경에 대한 고려를 통해서 이루어져야 한다.

P2P는 파일 공유에서부터 시작됐지만, 서버에 부하를 주지 않는다는 확실한 이점과 클라이언트끼리의 직접 통신이 더 빠를 수도 있다는 잠재적 메리트로 게임에 도입되기 시작했다. 이런 면에서 P2P는 게임 서비스 구현을 위한 굉장히 매력적인 도구임이 분명하다. 다만, 어떤 도구든 그 도구가 사용되는 상황을 고려해야 하는 것처럼 클라이언트-서버 방식이나 P2P 방식 모두 막연한 기대나 환상이 아닌 내가 만드는 게임이 어떤 서비스 환경에서 동작할지에 대한 정확한 판단에 따라 선택되어야 한다. 어떤 경우든 항상 옳은 설계는 존재하지 않는다.

본회 칼럼은 10월 6일 판교에서 개최되는 인벤의 IGC 컨퍼런스에서 직접 들으실 수 있습니다.

댓글

새로고침
새로고침

기사 목록

1 2 3 4 5