글로벌 서비스를 위한 시간 정보 관리

몇 년 전만 해도 게임 개발 시 처음부터 해외 서비스를 고려하는 경우는 드물었다. 그만큼 국내 시장이 빨리 성장하기도 했고, 해외 서비스를 위해서는 클라이언트 배포, 서버 설치를 위한 IDC 확보 등의 문제가 있었기 때문이기도 하다. 그러나 COC, 도탑전기 등의 글로벌 서비스를 통해 크게 성공하는 게임들의 등장과, 각종 마켓 및 클라우드 서비스의 활성화, 국내 시장 내의 경쟁 심화 등으로 인해 개발 시작 시점부터 글로벌 서비스를 염두에 두는 게임들이 많아지고 있다.

1
▲ 가장 성공한 글로벌 서비스 게임 중 하나인 COC
(출처 : http://clashofclans.co.kr/)

글로벌 서비스를 위해서는 언어 문제, 현지화 문제 등 고려해야 할 사항들이 많지만, 의외로 간과하는 경우가 많으면서도 대처하기 쉽지 않은 문제가 시차, 정확히 말하면 시간대와 관련된 문제이다. 단순히 클라이언트에서의 시각 표시 정도의 문제부터 각종 게임 내 이벤트의 일정 설정 문제, 운영 위탁 등의 이유로 특정 시간대에 맞춰 시간을 표시해야 하는 경우 등, 게임 내에서 시간 표시가 사용되는 경우는 적지 않다. 본 칼럼에서는 시간대를 다루는 것이 어려운 이유와 개발 시 고려해야 할 사항들을 정리하려 한다.

시간대란, 정치적이나 경제적인 이유 등으로 같은 기준으로 시간을 계산하는 지역을 말한다. 정오라는 단어의 의미를 생각한다면 태양이 가장 높이 떠 있을 때, 즉 낮 12시이겠지만, 한국의 경우 일본에 맞춰진 시간대를 사용하기 때문에 실제로는 일본 – 정확히는 일본 내의 특정 지역 – 에서 태양이 가장 높게 떠 있는 시간이 정오가 된다.

2

▲ 시간대가 다르기 때문입니다. (출처 : 나무위키 )

따라서 시각을 정확히 기록하려면 해당 시각이 어느 시간대를 기준으로 하였는지에 대한 정보가 필요하다. 매일 한 번씩 진행되는 이벤트가 있을 경우 시작 시간을 단순이 오전 9시로만 기록한다면 중국이나 동남아에서 접속하는 사용자들에게 해당 이벤트가 현지 기준으로 몇 시에 시작하는지 표시해 줄 수 없다. 최소한 9시가 한국이 속한 시간대를 기준으로 한 시각이라는 정보라도 있어야 중국 시간대와의 차이를 계산하여 보여줄 수 있다.

그렇다면 시간대에 대한 정보는 어떻게 기록해야 하는가? 우선 생각해 볼 수 있는 방법은 모든 시각 관련 정보를 기록 시, 해당 시각 산정에 사용된 시간대에 대한 정보와 함께 기록하는 것이다. 하지만 이는 한 서비스 내에서 두 개의 시각 정보를 비교 시 반드시 양쪽의 시간대 정보를 확인해야 하기에 운영 중 실수가 발생할 여지가 많고, 저장 공간이나 통신 용량도 더 차지하며 무엇보다도 귀찮다. 어차피 동일 서비스에서 사용할 거라면, 사용할 시간대 정보를 지정해 두고 모든 시각 정보를 해당 시간대 정보에 맞추는 편이 혼선을 줄일 수 있을 것이다.

그렇다면 어느 시간대를 기준으로 삼는 것이 좋을까? 이 칼럼을 읽는 독자분들은 대부분 한국에서 게임 개발을 진행하실 테니 한국 시간대를 사용하는 게 편하리라 생각하시는 분들도 있을 것이다. 하지만 대부분의 환경에서 제공되는 시간대 관련 개발 라이브러리에서는 시간대 별 시차 정보 등을 모두 UTC를 기준으로 하여 계산, 제공한다. 이러한 상황에서 한국 시간대를 사용한다면 필요한 시간대로의 변환을 위해 UTC로 변환하는 과정이 한 번 더 필요할 것이다. 요즘에는 해외 서비스 시 운영이나 이벤트 진행 등을 현지 파트너와 진행하는 경우 등 동일 서비스를 운영하더라도 둘 이상의 시간대 관리가 필요한 경우도 많아지고 있으며, 최소한 클라이언트에서 표시되는 시각은 대부분 변환이 필요한 만큼 보다 변환이 쉬운 UTC 시간대를 이용하는 것을 추천한다.

UTC로 시각을 기록 및 전송한다면, 필요에 따라 특정 시간대에 맞게 변환하는 과정도 필요하다. 그렇다면 시간대는 어떻게 관리하는 것이 좋을 지에 대해서도 알아보자. 시간대를 표시하는 가장 흔한 방법은 영국 표준시를 나타내는 시간대인 GMT 시간대와 몇 시간 차이가 나는지 기술하는 것이다. 예를 들자면 한국이 속한 시간대는 GMT+9, 미국 서부 지역이 속한 시간대는 GMT-7 로 표시한다. 하지만 이러한 시간 차이에 대한 정보만으로는 변환할 수 없는 경우가 있다.

우선 작은 문제부터 살펴보자면, 모든 시간대가 GMT와 시간 단위로 차이가 나지 않는다는 것이다. 예를 들어, 아마 게임을 서비스하려는 분은 없겠지만, 북한이 GMT+8:30 시간대를 사용한다. 이 칼럼을 작성하는 시점에, 이러한(시간 단위로 시차가 딱 떨어지지 않는) 시간대를 사용하는 지역 중 게임 서비스를 고려할 만한 시장은 별로 없기에 큰 문제는 아닐 수 있다. 하지만 시간대는 변할 수 있기 때문이 미리 고려해서 손해 볼 부분은 없을 것이다. 예를 들자면, 최근 높은 스마트폰 보급률로 주목을 받는 이란은 GMT+4:30 시간대를 사용한다.

좀 더 큰 문제는 일광절약 시간제가 적용되는 지역의 경우이다. 일 년 중 특정 기간에만 GMT와의 시차가 바뀌며, 하루 중에도 시차가 바뀐다. 일 년 중 일광절약 시간제가 적용되는 기간도 나라마다 다르다. 같은 국가 내에서 같은 시간대를 사용하더라도 특정 지방에서만 시행하는 경우도 있다. 따라서 단순히 시간 차이만을 기록해서는 정확한 변환은 불가능하다. 일광절약 시간제는 미국이나 유럽 등 글로벌 서비스 시 고려할 만한 주요 지역들에서도 사용되므로 무시하기도 어렵다.

따라서 일광적약 시간제 관련 정보를 포함하는, 별도의 시간대 표시 방식을 사용하는 것이 좋다. 이러한 용도로 널리 사용되는 시간대 표시 방법에는 크게 영문 대문자 3~4글자로 시간대를 표현하는 time zone abbreviation 과 주로 지역/도시 or 국가 형태로 시간대를 표현하는 IANA time zone, 일명 Olson time zone이 있다.

time zone abbreviation 은 다음과 같은 문제점이 있기에 권장하지 않는다. 우선 동일 지역, 동일한 시간대라도 일광절약 시간제의 적용 여부에 따라 별도의 약어가 존재하는 문제가 있다. 예를 들면 호주 중부 시간대의 경우 일광절약 시간제가 적용되는 경우에는 ACDT, 적용되지 않는 경우에는 ACST라 표시하며, 미국 서부의 시간대의 경우에는 적용 여부에 따라 PDT/PST로 표시한다. 그리고, 몇몇 시간대의 경우 분명 다른 시간대임에도 이름이 같은 경우가 있다. CST라는 시간대의 경우, Central Standard Time( 미 중부 시간대 ), CST( China Standard Time )등 4개( 일광절약 시간제를 고려하면 5개! )의 다른 시간대를 나타내는 약어이다.

IANA timezone은 위에서 언급한 대로 일반적으로 지역/도시 형태로 해당 지역에서 사용하는 시간대를 표시한다. 예를 들면 유럽 내 프랑스 파리의 시간대는 Europe/Paris, 아시아 내 싱가포르의 시간대는 Asia/Singapore 로 표시하는 식이다. 따라서 사용하려는 시간대와 일치하는 이름을 찾아서 지정해 줘야 하는 문제가 있지만 위의 abbreviation 과는 달리, 해당 지역의 일광절약 시간제 관련 정보( 연중 적용 기간, 하루 중 적용 시간 등 )를 포함하고 있기 때문에 적용 여부와 관계 없이 동일한 이름을 사용한다. 그 외에 윤초 등 시각 표시에 관련된 많은 정보들을 포함하여 관리되기 때문에 수고를 들일 만한 가치가 있다.

정리하자면 글로벌 서비스를 목표로 하는 게임에서 시간 관련 정보를 다룰 때에는
1. DB나 통신 프로토콜 내에서의 시각 표시는 UTC 를 사용을 권장
2. 변환 등을 위해 시간대를 지정할 경우에는 IANA timezone 사용을 권장
정도로 정리할 수 있겠다.

글로벌 서비스를 고려하지 않더라도 시간과 연관된 개발은 복잡하다. 특히 시각만이 아닌, 날자 요일 등을 같이 고려해야 하는 경우, 시간대가 바뀌면 날자 역시 바뀔 수 있기 때문에 더욱 더 어려운 문제가 된다. 모든 기능이 마찬가지이지만, 시간대 관련 기능은 구현 시작 시부터 고려하지 않으면 변경 비용이 매우 비싸질 수 있다. 당장은 국내 서비스만을 고려하더라도 시간과 관련된 기능 구현 시 시간대와 관련된 내용을 고려한다면 이후의 상황 변화에 좀 더 유연하게 대처할 수 있을 것이다.

아이펀팩토리 아이펀 디플로이 테크니컬 디렉터 민영기

2016 아이펀팩토리 Dev Day 시작합니다!

안녕하세요, 아이펀팩토리 사업팀입니다.

지난해에 이어 두 번째 Dev Day를 준비하였습니다. 올해도 서버 개발 관련 개발자들이 번뇌는 줄여드리고, 해결책을 제시하는 으리파!! 아이펀팩토리의 ‘2016 Dev Day’ 많은 관심과 참여 부탁 드립니다.

 

부제 : 게임 서버 개발 마무으리!!!

– 일시 : 2016년 9월 28일(수) 12:00~14:20

– 장소 : 넥슨 판교 사옥 지하 1층 교육실

– 참가비 : 무료 / 점식 식사 제공 참가자 전원 기념품 드림

– 주최 : 아이펀팩토리

– 후원 : 넥슨

– 참가 신청 : 참가신청하러 가기

– 참가 신청 기간 : 2016년 8월 24일(수)~9월 27일(화)

시간

세션

발표자

11:00~12:00(60)

참가 등록 및 점심 식사

 

12:00~12:05(05)

웰컴 스피치

문대경 대표님

12:05~12:50(’45)

Make “PONG” : 아키텍팅과 동기화 테크닉

박근환 TD

12:50~13:30(’40)

게임 운영에 필요한 로그성 데이터들에 대하여

민영기 TD

13:30~14:10(’40)

Docker 로 Linux 없이 Linux 환경에서 개발하기

김진욱 CTO

14:10~14:20(’10)

경품 추첨 및 폐회식

문대경 대표님

[이벤트] 아이펀팩토리 설문 조사 이벤트 당첨자 발표

안녕하세요,  아이펀팩토리 사업팀입니다.

지난 한달간(2016.07.07~2016.08.07) 진행된 아이펀팩토리 설문조사 이벤트 당첨자를 발표합니다!!

손으로 하나하나 꼼꼼히 접어서 준비한 추첨지입니다.

어젯밤 좋은 꿈을 꾸신 분이 누구인지 지금부터 공개하겠습니다.

1

 

축하합니다!!! 설문에 참여했지만 아쉽게도 아래 경품에 당첨되지 못한 분들 너무 실망하지 마세요. 참여해주신 분들 모두에게 기재해주신 핸드폰 번호로 스타벅스 아메리카노 기프티콘을 보내드립니다. 경품에 당첨되신 분들은 경품 수령을 위해 개별 연락 드릴 예정이오니 조금만 기다려 주세요.
설문 이벤트 당첨자 공지_페북용_최종
당첨자

 

가장 많은 분들이 당첨되길 기대한 리얼포스 키보드  당첨자!
키보드

 삼성전자 SSD 1TB 당첨자!SSD

두근두근 아이패드 당첨자!
아이패드

 

설문 조사에 참여해 주신 여러분 모두 감사 드립니다.

아이펀팩토리에서는 많은 이벤트를 준비중이오니 앞으로도 많은 관심과 참여 부탁 드립니다.

아시아 최대 글로벌 게임 전시회! 차이나조이 2016 현장공개!

중국 최대 글로벌 게임 전시회, 차이나조이 2016(ChinaJoy , China Digital Entertainment Expo & Conference)에 아이펀팩토리 다녀왔습니다. 올해로 14번째 개최를 맞는 차이나조이는 아시아 최대 규모의 게임축제로 해마다 기록을 갱신하는 규모와 다양한 콘텐츠로 무장하여 세계적인 축제로 자리매김하고 있는 중국 게임전시회입니다. 올해 역시 뜨거운 여름 열기만큼 더 뜨거운 중국의 열정을 느낄 수 있었습니다.

 

차이나조이 탐방기 지금부터 시작합니다!

 

우선 차이나조이의 평면도를 볼까요? 차이나조이는 모바일 게임 시장의 노하우를 공유할 수 있는 컨퍼런스가 열리는 WMGC, 중국 게임 개발자 컨퍼런스 CGDC, 중국 디지털 엔터테인먼트 회의 CDEC와 비즈니스 미팅 공간인 BTB 그리고 전시공간인 BTC를 볼 수 있습니다. 한국의 지스타의 10배 규모라고 할 만큼 대륙의 스케일에 압도되는 전시규모입니다.

1. 차이나조이 평면도▲ 차이나조이 평면도 (출처 : 차이나조이 공식 홈페이지)

먼저 BTB관부터 가볼까요?

비즈니스 미팅을 위한 BTBBTB라고 알고 보지 않았다면 일반 전시장인 BTC관으로 착각 할 만큼 화려한 모습이었습니다.

첫 번째 탐방 부스는 검과마법 for KaKao로 멋지게 도약하고 있는 룽투게임 부스입니다. 룽투게임부스에서는 한국의 크로스파이어의 IP를 활용한 철월화선 : 중반전장과 뮤의 IP를 활용한 뮤 ; 최강자와 열혈강호 등으로 부스를 꾸며 눈길이 가는 부스였습니다.

2

▲ 룽투게임 부스

BTB관에 있던 홍콩 퍼블리셔 오아시스 게임스 부스입니다.

3

▲ 오아시스 게임스 부스

이번 차이나조이에서도 VR은 굉장히 한 콘텐츠였습니다. VR전용관이 따로 있을 정도로 큰 관심을 볼 수 있었습니다.

5

▲ 다양한 VR체험이 가능했던 차이나 조이

 

이보다 더 뜨거울 수 없다! BTB관을 나와서 야외행사장입니다. 40도에 육박하는 체감온도, 에어컨을 빵빵하게 튼 행사장 내부 온도가 36도를 기록할 만큼 최고로 열정적인 차이나조이를 느낄 수 있는 더위였습니다. 야외 행사장에는 에반게리온 초호기를 설치 중이었습니다. 전시된 에반게리온 초호기의 높이는 약 25m로 설치전임에도 엄청난 규모를 자랑하는 대륙의 엄청난 스케일을 볼 수 있었습니다. 얼핏 보면 더위에 쓰러진 것으로 착각될 정도로 혼이 나갈 정도의 더위가 느껴지는 현장을 보여주는 사진입니다. 아쉽게도 설치가 완성된 사진을 찍지 못했네요.

6

▲ 야외 행사장 에반게리온 초호기를 설치중인 모습

 

라그나로크의 포링들이 가득한 심동 네트워크 부스입니다. 심동네트워크 부스에서는 라그나로그를 주인공으로 보기만해도 상큼한 핑크색 포링들이 천장 가득 장식되어 있고 바닥에도 귀여운 모형으로 가득하여 멀리서도 눈에 띄는 부스였습니다. 부스 가득 핑크색 포링이 인상 깊은 심동 네트워크 부스에서는 특별히 제작한 라그나로크의 IP를 활용한 VR 게임 시연을 볼 수 있었습니다.

▲라그나로크의 포링으로 가득찬 심동 네트워크 부스

 

이곳은 반다이남코의 부스입니다. 이번 반다이남코 부스에서는 일본 IP를 활용한 세일러문 모바일(가칭입니다)과 인기 개그 만화 은혼의 모바일 게임을 볼 수 있었습니다. 이 밖에도 나루토, 드래곤볼, 건담 등의 IP를 활용한 모바일, 웹게임을 볼 수 있었는데요. 눈에 띄는 점은 각 시연 코스마다 게임의 캐릭터로 변신한 부스걸들과 캐릭터들의 피규어가 전시되어 있어 다양한 볼거리를 볼 수 있었습니다.

9

▲ 반다이남코 부스

 

가까이 갈 엄두가 나지 않을 정도로 많은 인파가 있었던 블리자드 부스입니다. 부스걸 없이도 가득 찬 블리자드의 부스를 보니 진정한 게임쇼같다는 생각이 들었습니다. 여러 가지 게임 시연과 함께 시연 대기줄 중간에는 오버워치의 캐릭터로 변장할 수 있는 아이템들이 놓여있어 멋진 사진을 남길 수 있었습니다.

10

▲ 엄청난 인파를 자랑하는 블리자드 부스

 

11

▲ 엄청난 인파에 앞으로 나가기 힘든 차이나조이 전시장 모습

이곳은 스네일 게임즈 부스입니다. 중국 퍼블리셔 스네일 게임즈 부스에서는 익숙한 게임을 볼 수 있었습니다. 바로! 모바일로 구현된 리니지2 : 혈맹입니다. 리니지 이외에도 많은 한국 게임의 IP가 활용된 게임들을 볼 수 있어 반갑고 뿌듯한 마음으로 가슴이 벅차 올랐습니다. 스네일 게임즈 부스에는 이 밖에도 아크 서바이벌’, ‘구음진경’, ‘태극팬더2’ 등의 게임 시연대가 많이 마련되어 있어 다양한 게임 시연을 할 수 있었습니다.

▲ 스네일 게임즈 부스

 

JJ MATCH 부스입니다! JJ MATCH 부스에서는 추억이 새록새록 떠오르는 킹오브파이터, 워크래프트3, 도타 등의 게임을 볼 수 있었습니다. 게임보다 많은 부스걸들로 중국의 미녀들을 한자리에서 볼 수 있었습니다.

15

▲ JJ MATCH 부스

 

차이나조이 2016, 엄청 대륙의 규모와 진정한 여름의 열기를 느낄 수 있는 게임쇼였습니다. 내년 차이나조이를 기대해보며 포스팅은 이만 줄이겠습니다.

사례 연구: ‘Pong’을 만들어보자

처음 쓰는 컬럼을 이런 진부한 설명으로 시작하고 싶지는 않았지만, 어쩔 수 없을 것 같다. ‘Pong’은 게임 역사상 처음으로 흥행에 성공한 게임이다. 게임 자체는 지금도 오락실 등에서 볼 수 있는 아이스하키 게임과 비슷하다. 두 명의 사람이 각자 단순한 컨트롤러를 사용하여 상대방 쪽으로 공을 넘겨 통과시키면 이기는 게임이다.

그림1

▲(Pong, 출처: 위키피디아)

하고 많은 게임 중에 이 게임을 선택한 이유는, 실시간 동기화를 구현하기 좋은 게임이라고 판단했기 때문이다. 다르게 말하자면 이 게임은 재미있고, 구현하기도 쉬워 보인다. 그렇다면 어떤 게임이 실시간 게임으로 만들기 쉬운지 어떻게 판단해야 할까? 이 컬럼은 이에 대한 부분을 다룰 예정이다. 추가로 사례 연구를 통하여 어떤 식으로 동기화를 만들어 가는지, 그 꼼수와 우회로 이루어지는 향연에 있어서 전채의 맛을 살짝 느끼는 것도 목표로 삼는다.

실시간 멀티플레이를 구현하기 위해 가장 먼저 고려해야 할 부분 중 하나는 바로 무엇을 동기화 할 것인가 하는 것이다. ‘Pong’은 아마도 화면을 돌아다니는 ‘공’, 그리고 플레이어가 공을 튕겨내기 위해 움직이는 ‘막대’ 부분이 될 것이다. 이 컬럼에서는 공을 어떻게 동기화 할 것인가에 대하여 집중적으로 이야기할 것이다.

공은 게임의 시작부터 끝까지 계속 움직이는 물체이다. 이는 동기화 해야 하는 정보가 쉬지 않고 변한다는 것을 의미한다. 현재의 좌표, 속도, 벽이나 막대에 충돌했는지 끊임없이 파악하고 동기화 해야 한다. 보편적으로 이렇게 끊임없이 변화하는 데이터를 가진 객체를 동기화 하는 것은 매우 어려운 일이다.

하지만 ‘Pong’은 물리 엔진을 사용할 수 있는 게임이다. 어느 한 쪽 막대에 공이 충돌했을 때의 좌표와 속도만 동기화 하면, 같은 환경에서 같은 물리 엔진임을 활용해, 이후의 진행을 추가 작업 없이 자동으로 똑같이 맞출 수 있다. 실시간 게임을 만들 때 동기화 해야 하는 정보와 순간을 최소화하는 것은 매우 중요하다. ‘Pong’은 이를 극단적으로 줄일 수 있기 때문에 상당히 구현하기 쉬운 편이다.

그림3

▲(직접 만든 멀티플레이 Pong의 모습, 양쪽의 위치가 조금은 다를 수 밖에 없다.)

 그러나 네트워크를 통한 데이터의 송수신은 시간을 소모한다. 특히 모바일 기기의 무선망은 최소 수십 밀리세컨드 이상의 지연 시간을 감안하는 것이 정석이다. 이 것도 국내는 아주 좋은 편이라 이 정도, 만약 미국이나 심지어 중국이라면 더 긴 시간이 걸린다고 보는 것이 맞다. 이런 상황에서 Player A의 공 정보를 아무리 빠르게 전송한다 한들, Player B의 정보가 맞춰지는 시간에는 차이가 생기기 마련이다.

그렇다면 어떻게 해야 할까? 가장 먼저 떠오르는 아이디어는, 양 쪽이 같은 정보를 공유할 때까지 잠시 기다리는 것이다. 흐름을 생각하면 다음과 같다.

  1. Player A > 서버 : ‘나의 공이 지금 좌표 (100,100)에 있다’
  2. 서버 > Player B : ‘A의 공이 지금 좌표 (100,100)에 있다고 한다’
  3. B > 서버 : ‘공의 좌표를 (100,100)으로 설정했다’
  4. 서버 > A : ‘B의 공 좌표가 업데이트 되었다’
  5. 이제 다시 A의 공 좌표를 업데이트 한다

여기서 센스 있는 개발자 분들은 바로 ‘어 이러면 안되지 않나?’하고 생각하실 것이다. 맞다. 이렇게 끊임없이 정보를 갱신하는 객체, 특히 그게 바로 화면에 보이는 것은, 이렇게 여러 번 통신을 하면서 지연 시간이 길어지면 바로 플레이의 불편함(랙)으로 이어진다. 위와 같은 방식은 상대적으로 덜 활동적인 장르나 게임 시스템 내부의 처리가 턴제 형태로 이루어지는 게임에서 사용한다.

그렇다면 다시, 어떻게 해야 할까? 다음으로 할 수 있는 방법은 네트워크를 통해 수신하는 데이터에 보정을 가하는 방법이다. 네트워크의 지연 시간을 측정 혹은 추정하고, 그 만큼의 시간이 지난 후의 상태를 계산해서 ‘적절히’ 맞춰 놓는 식이다. 이 것은 실제로 자주 쓰이는 방법이지만, 경험이 많은 개발자라면 알 것이다. ‘적절히’라는건 개발자에게 세상에서 구현하기 제일 어려운 것 중 하나 이다. 마치 ‘플레이어가 느끼기에 적절한 난이도로 몬스터 AI를 만들어 주세요’ 같은 요구랄까..

이제 마지막으로, 그럼 어떻게 하면 좋을까? 실시간 게임을 만들어보지 않은 개발자라면 이 결론이 아주 어색할지도 모른다. 그건 바로 ‘굳이 딱 맞출 필요 없다’이기 때문이다. 어차피 물리 엔진이 계산해주는 공의 이동과 충돌은, 같은 위치에 같은 방향만 맞춰 놓는다면, 결국 같은 곳으로 움직이기 마련이다. 어느 한 쪽의 화면이 조금 늦을 수는 있지만, 최종적으로 보는 화면이 같아진다면 문제가 되지는 않는다.

하지만 여기서 구현을 마무리하면 문제가 생긴다. 바로 앞의 이야기를 뒤집는 것 같지만  ‘최종적으로 보는 화면이 같아’져야 한다는 것이 중요한 기준이 된다. 예를 들어 공의 속도가 매우 빨라진 상태에서 네트워크 지연 시간이 늘어나는 경우, A의 화면에서는 이미 승리한 상태로, B의 화면에서는 아직 공이 다가오는 상태로 보일 수 있다. 이런 상황을 방지하는 것을 보장할 필요가 있다. 단, 네트워크 지연 시간이 수백 밀리세컨드 이상 비정상적으로 계속 늘어나거나, 아예 끊기는 경우는 여기서 고려하지 않는다.  물론 이런 상황의 예외 처리도 게임의 상용화를 위해 꼭 필요하지만, 네트워크에 문제가 생긴 다른 플레이어를 기다릴 지, 패배 처리를 할지, AI를 투입할지 같은 식으로 기술보다는 게임 정책의 문제가 된다.

그렇다면 네트워크 지연 시간을 보정하는 것은 어떻게 접근해야 할까. 이 것 역시 개발자가 단독으로 처리하기 보다는 기획과 유기적으로 이야기를 나누며 진행하는 것이 더 좋은 결과물을 만드는 경향이 있다.

다시 ‘Pong’으로 돌아오자. 플레이어 A가 공을 보내 B가 반응 해야 하는 거리까지 도달하는 동안, 벽에 두 번 부딪히면서 가는 일반적인 상황을 생각해보자. 네트워크 전송이 제대로 이루어지고 있는지, 네트워크 지연 시간은 얼마나 되는 지를 확인하기 위해 벽에 충돌할 때에도 정보를 전송한다고 가정하면, 흐름은 다음과 같다.

  1. 공이 A의 막대에 충돌했을 때의 위치와 속도의 변화를 서버를 통해 B로 보냄
  2. B는 해당 정보를 물리 엔진에 적용
  3. 공이 벽에 충돌한 위치와 속도를 서버를 통해 B에 보냄
  4. B는 해당 정보를 물리 엔진에 적용
  5. 공이 벽에 충돌한 위치와 속도를 서버를 통해 B에 보냄
  6. B는 해당 정보를 물리 엔진에 적용
  7. 이제부터는 B가 충돌했을 때의 위치와 속도의 변화를 A에게 보냄

위 흐름에서 네트워크 지연은 모든 부분에서 발생할 가능성이 있다. 1)에서 상대적으로 높은 네트워크 지연이 발생하고, 3), 5)에서 점점 더 빠르게 도착하는 경우에는, 공이 벽에 충돌할 즈음에 순간 이동을 하여 예상보다 더 빠르게 움직이게 되고, 1)보다 3), 5)에서 네트워크 지연이 커지는 경우, 진행하던 공이 다시 벽으로 돌아가는 현상이 발생한다.

솔직히 말하자면, 실시간 게임에서 종종 순간 이동이 일어나는 것은 사실 심각한 문제는 아니다. 모든 실시간 게임은 일정 부분 이런 문제를 가지고 있고, ‘Pong’역시 마찬가지로 볼 수 있다. 하지만 잦은 순간 이동은 플레이를 불편하게 만든다. 좀 더 보기 좋게 만드는 방법은 없을까?

여기서 게임의 특성, 재미 요소와의 조율이 이루어진다. 네트워크 지연 시간으로 인한 순간 이동이 피할 수 없는 것이라면, 그건 가능한 플레이어가 막대로 반응하기 최대한 이전에 이루어지는 것이 좋다. 플레이어가 막대로 반응하기 바로 직전, 벽에 충돌하면서 보정이 일어나 순식간에 공이 앞으로 다가온다면 당연히 짜증이 날 수 밖에 없을 것이다.

이에 따라 B에서 1)은 정보가 날아오는 순간 바로 적용하고, 3)과 5)는 내용과 현재 공의 위치에 따라 큰 차이가 나는 것이 아니라면 적용을 하지 않고 넘어가는 것도 좋은 방법이다. 다시 말하자면, 어떤 상황에서는 정보의 업데이트를 최대한 빠르게 하기보다는 오히려 뒤로 미루는 것이 더 나은 게임성을 제공하기도 한다는 것이다. 아이러니하지 않은가. 이와 같이 실시간 게임의 동기화 정책은 기본적으로 기술적인 문제이지만, 결정은 개발자 뿐 아니라 기획자는 물론, 팀원 전체가 플레이를 통해 다듬어 가는 것이 가장 좋은 결과물을 만드는 길이다.

지금까지 나온 이야기를 세줄 요약한다면, 다음과 같이 할 수 있겠다.

  • 실시간 멀티 플레이 게임은 동기화 해야 하는 정보와 빈도가 적을 수록 만들기 쉽다.
  • 네트워크 지연 시간이 존재하기 때문에, 이론적으로 완벽한 동기화는 불가능하다.
  • 완벽한 동기화를 추구하기 보다는, 게임을 플레이하기 좋은 방향으로 접근해야 한다.

물론 이 외에도 개선해야 할 사항은 얼마든지 남아있다. 이는 꾸준한 고민과 테스트를 통해서 찾아내고 다듬는 작업이 된다. 그 것은 개발 초기에 발견할 수도 있고, 런칭 직전에나 떠오를 수도 있으며, 심지어 출시하고 꽤 긴 시간이 지난 이후에 알게 될 수도 있다. 시기와 상관 없이, 위의 큰 틀을 따른다면, 아마도 좋은 게임을 만들 수 있지 않을까 생각한다.

아이펀팩토리는 곧 위에서 설명한 ‘Pong’ 게임의 소스코드 전체를 공개할 예정이다. 또한 향후 개발자 세션을 통하여 어떤 식으로 구현했는지, 이 컬럼에서 언급하지 않는 막대는 어떻게 다루었는지, 추가로 최적화 할 수 있는 여지는 어디에 있는지도 함께 이야기 나누는 시간을 가질 예정이다.

또한 아이펀 엔진을 정식으로 사용한다면, 위와 같은 초기 아키텍팅에 대한 고민도 개발자와 함께 나눈다.

감사합니다.

아이펀팩토리 박근환 아이펀 엔진 테크니컬 디렉터

[인벤기고컬럼 4] P2P vs 클라이언트-서버 모델, 각각의 장단점은?

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

첫 회에서 게임 서비스를 구성할 때 사용하는 네트워크 모델들에 대해서 간단하게 언급했었는데, 이 중에서 클라이언트-서버 모델과 P2P 모델에 대해 두 회에 걸쳐 좀 더 깊이 살펴보도록 하자. 이번 회에서는 클라이언트-서버 모델에 대해 설명을 하고 다음 회에 이어서 P2P 모델에 대해서 설명을 하도록 하겠다.

클라이언트-서버 모델: 중앙 집중 방식

집집마다 ADSL 인터넷이 설치된 것은 채 20년도 되지 않는다. 그전에 인터넷이라는 것은 학교 전산실에서나 경험해 볼 수 있었고, 컴퓨터 전공자들에게만 익숙한 것이었다. 지금은 컴퓨터를 사도 메인보드에 랜 포트가 달려나오고, 노트북 컴퓨터 같은 경우는 유선 랜 포트가 거추장스럽다고 아예 WiFi만 지원할 정도로 네트워크 연결 측면에서 많은 진보를 이루었지만, 당시에 랜카드는 당연히 별도로 사서 설치하는 것이었고, 그나마도 OS에서 이를 인식시키는 것은 나름 까다로운 작업이었다. 조금 더 쉽게 설명하면, 컴퓨터에 랜 카드를 설치해주는 것만으로도 컴퓨터 잘하는 동네 오빠로서 이성에게 호감을 얻을 수 있는 정도? (물론 나에게는 그런 여자 후배는 없었다… 왜냐면…. 나는 공대니까…)

인벤기고컬럼4.png
▲ 예전에는 랜카드를 별도로 설치해야했다. 크고 아름다운 랜카드의 위용(출처 : wikipedia)

이런 초고속 인터넷 (영어로는 broadband Internet) 의 대중화 과정은 비단 우리나라에서만 그런 것이 아니었고, 그 때문에 일반적으로 서버라는 존재는 압도적인 계산 능력을 갖춘, 특별히 관리되는 존재로 인식되었다. 우리가 일반 컴퓨터에서 사용하는 인텔 x86 CPU가 서버에도 활용되기 시작한 것 역시 역사가 그다지 오래되지 않았다.

이런 배경 때문에 대부분의 인터넷 서비스는 가장 직관적이고 일반적인 형태로, 정보를 몰아넣고 중앙에서 관리하는 강력한 컴퓨터가 빈약한 사용자 컴퓨터에 서비스를 제공해주는 형태로 갖춰지게 되었다. 정보를 제공(서빙)해주는 사람이라는 뜻에서 ‘서버’라고 불리게 되었고, 정보를 활용하는 고객이라는 의미에서 ‘클라이언트’라고 불리게 되었다. 그러니 클라이언트-서버 모델은 컴퓨터 네트워크 초창기부터 가장 일반적으로 활용되어온 서비스 구성 방식이다.

인벤기고컬럼 본문 더보기>