NDC Replay

<야생의 땅: 듀랑고> 중앙 서버 없는 게임 로직
최호영
넥슨
	현재 <듀랑고: 야생의 땅>에 테크니컬 디자이너로 참여하고 있는 8년차 게임 프로그래머 입니다.
	MMORPG 장르로 개발 중인 <야생의 땅: 듀랑고>는 주변 플레이어들과 월드, 시스템과 지속적으로 소통하고 동기화되어야 합니다. 하지만 확장성과 안정성을 위해서 택한 분산 환경은 지속적인 동기화가 쉬운 편은 아니었습니다. 분산 환경 속에서 겪은 여러 가지 사례들을 공유하고자 합니다.
[새 창에서 슬라이드 보기]
먼저 시작하기 앞서서 제가 준비해온 PT가 약간 해상도가 안 맞아서 제 잘못으로 좀 일그러져 있습니다. 미리 양해 말씀 부탁드립니다. 제가 오늘 발표할 주제는 중앙 서버 없는 게임 로직이고요. 좀 프로그래밍 관련된 내용이다 보니까 아무런 프로그래밍과 관련된 지식이 없으신 분들에겐 좀 어렵고 지루한 얘기가 될 수 있어요. 그래서 그런 분들께서는 다른 세션을 찾아가셔도 저는 마음의 상처를 받지 않겠습니다. 기존에 게임 로직을 다루셨지만 서버 쪽은 안 하셨던 분이라면 아 서버 쪽에선 저런 고민도 하는구나. 이 정도로 봐주시면 좋을 것 같고요. 서버 로직을 많이 개발하셨던 분들은 뭐 Case Study를 한다는 느낌으로 “저런 일을 했네? 그러니까 나중에 나도 한 번 참고해볼까?” 정도의 마음으로 가볍게 봐주시면 감사하겠습니다. 먼저 듀랑고 제가 개발하고 있는 게임에 대해서 살짝 설명을 먼저 하고 그다음에 몇 가지 피처 별로 어떤 문제들이 있었고 어떻게 극복했는지 이런 이야기들을 제가 하려고 합니다.

네 저는 왓스튜디오라는 곳에 소속된 최호영이라는 8년 차 프로그래머고요. 맡고 있는 역할은 테크니컬 디자이너입니다. 테크니컬 디자이너는 그렇게 큰 의미가 있는 건 아니고 프로그래머로써 좀 더 디자이너와 협업하는 쪽으로 가깝게 가고자 해서 아주 자세한 명세 없이도 대충 이야기를 들으면 제가 구조를 제안하고 이런 식으로 같이 인터랙티브하게 일한다는 의미에서 저렇게 저희는 부르고 있습니다.

오늘 제가 할 이야기에서 제가 개발하고 있는 게임에 대한 서버 구조 자체에 대한 이야기는 사실 많이 하지 않을 거예요. 기본 설명이 조금 필요하기 때문에 가벼운 이야기들은 하겠지만 이 구조 자체가 궁금하시고 왜 그런 구조를 짰는지 어떤 고민이 있었는지 이런 것이 궁금한 분이 있으시다면 2014년도에 한 발표가 하나 있고요. 그다음에 오늘 오전 11시에 있었던 발표가 하나 있는데요. 둘 다 이흥섭 님께서 발표하신 거고요. 저쪽에 그런 쪽 고민이 많이 들어 있으니까 NDC 리플레이나 혹은 추후에 올라오는 사이트를 통해서 참고해주시면 좋을 것 같습니다.

네 제가 개발하고 있는 게임은 야생의 땅: 듀랑고라는 게임입니다.

저희 게임의 비전은 공룡시대 야생 환경에서 현대인들이 생존, 탐험, 사냥, 개척 이런 걸 하는 MMORPG고요. 모바일에서 돌아가는 게임입니다. 

저희는 이 중에서 가장 중요한 특징을 탐험, 개척 쪽으로 생각을 하고 있고요. 그래서 이 탐험의 매력을 통해서 게임에 빠져들기를 바라고 있습니다.

탐험을 중요한 피처로 삼다 보니까 되도록 넓은 땅을 유저에게 제공해주고 싶어요. 넓어야지 탐험하는 즐거움도 있고 내가 개척하는 즐거움도 있을 거잖아요. 그리고 최대한 많은 사람들이 모여서 나를 자랑도 하고 같이 소통도 하고 사회도 이루고 이런 거를 저희는 하고 싶어서 하나의 세계를 만들어서 제공하고 싶습니다. 

요건 약간 기술적인 목표인데요. 디자인적인 목표 외에 저희가 분산 서버, 제가 서버라고 해놨지만 꼭 서버만 얘기하는 건 아니고 DB 같은 거나 여러 가지 서비스에 필요한 요소들을 분산화해서 뭔가 하나의 문제가 생겼을 때 전체가 장애가 일어나는 그런 일이 되도록 적고 안정적이고 이런 구조를 저희가 하고 싶어서 분산 서버라는 그런 기술적인 도전도 같이 하고, 도전이라고 하긴 약간 크지만 단어가 좀 과하지만 어떤 그런 목표를 가지고 있습니다.

그래서 저희가 이런 목표를 달성하기 위해서 어떤 서버를 구성했는지 간단하게 먼저 설명을 드리고 이야기를 계속할게요.

저희는 객체가 중심이 되는 서버라는 거를 만들고 있습니다. 일반적까진 아니지만 많은 경우에 물리적인 서버에 지역적인 위치가 바인딩 되는 경우가 꽤 많이 있죠. 그래서 하나의 서버에, 그러니까 하나의 지역에 내가 옆에 있는 사람과는 웬만하면 물리적인 서버가 같은 서버에 있을 확률이 높습니다. 그런데 이렇게 디자인을 하면 서버가, 땅의 크기가 서버의 성능에 제한될 수가 있어요. 그래서 이런 거를 극복하기 위해서 채널을 나누기도 하고요. 지역을 쪼개기도 하고요. 여러 가지 방편을 하는데 저희는 좀 다른 방법을 해보고 싶어서 지역에다가 바인딩을 하지 않고 객체에다가 바인딩을 했습니다. 이 객체 바인딩을 하다는 거는 나중에 다시 설명이 나올 텐데요. 뭔가 저희가 휴리스틱하게 생각하는 좋은 최적화된 방법으로 어떤 서버에 유저들이 접속하면 다양한 많은 분산된 서버 중에 한 군데에 그냥 배정이 됩니다. 그러면 서버에 배정이 된 객체는, 서버는 자기에게 배정이 된 개체에만 관심을 갖고 그것만 적극적으로 컨트롤하는 방식입니다.

좀 그래피컬하게 보여주고 싶어서 이렇게 준비를 했는데요. 어떤 지역에 여러 개의 주황색 객체들이 보이죠. 그런데 사실 저희는 지리적인 위치에 서버가 바인딩이 되지 않기 때문에 눈에 보이는 것들이 

상당수 다른 서버의 객체들입니다. 그래서 얘네들은 다른데 있기 때문에 좀 다른 동작을 해야겠죠. 나랑 같이 있는, 그러니까 나의 서버에 있는 애들만 좀 추려서 보면 

시야라는 개념이 있습니다. 나한테 멀리 있는 애들은 내가 관심을 가질 필요가 없겠죠. 그래서 내 서버에 있는 애들, 내가 관리하고 있는 애들의 시야만큼을 저희는 합쳐서 서버의 시야라고 부르고 있습니다.

이 다른 서버에 있지만 나랑 근처에 있는, 시야 내에 있는 애들은 내가 관심을 갖고 있지만 다른 데에 있는 애들은 관심을 가질 필요가 없잖아요. 아예 신경을 끄고 사는 겁니다. 그렇게 한 상태에서 만약에 다른 서버에 있는 객체가 움직여요.

그러면 당연한 얘기지만 얘는 실체가 그쪽 서버에 있기 때문에 내 서버에는 얘의 환영만 있습니다. 저희는 그거를 내부적으로 고스트라고 부르고 있는데요. 이 환영이 언제나 거기에 대기하고 있고 얘가 움직이면 그 동기화된 정보를 받아서 “내가 움직였어”라는 신호를 받으면 그때 조용히 따라서 움직입니다. 다른 것들도 이동할 때 이렇게 되는 거죠. 제가 이동을 예시로 들었지만 꼭 이동만 그런 건 아니고요. 내가 피가 깎였다든지, 죄송합니다. 제가 간간이 물을 좀 마시겠습니다. 피가 깎였다든지 다른 변화가 있을 때마다 똑같은 과정을 통해서 내 실체가 다른 서버에 있는 나한테 관심이 있는 지역에 있는 애들한테 내 고스트에 대한 정보를 끊임없이 동기화를 하는 방식입니다.

네 뭐 요런 거를 찍어 왔는데요. 엄밀히 말하면 이거를 정확히 표현하는 영상은 아니에요. 이거는 클라이언트와 서버 간에 격차 때문에 생기는 문젠데 이 서버와 서버 간의 격차도 포함이 된 내용이긴 하거든요. 지금 보시면 먼저 뛰어가는 애는 내가 클라이언트에서 직접 조작하는 애고 뒤에서 쫓아가는 애는 나의 그런 모습을 다른 서버 혹은 다른 클라이언트에서 보는 겁니다. 그래서 내가 하는 거보다 살짝 늦은 모습을 보게 되겠죠. 하지만 지속적으로 동기화되고 결과적으로는 같은 위치에 있게 됩니다.

요런 서버 디자인을 하면은 장점이 몇 가지가 있는데요. 대표적으로 소속된 서버에 객체에만 관심이 있기 때문에 멀리 있는 것들은 관심을 아예 갖지 않아요. 그래서 이 세계가 얼마나 큰지 전혀 알 필요가 없습니다. 그래서 이론적으로는 물론 현실적으로는 제약이 있습니다만 이론적으로는 무한한 크기의 세계를 표현할 수 있고요. 또 그냥 분산 서버에 그냥 단순한 특징이죠. 안정성이 매우 좋습니다. 지역의 위치에 바인딩 된 게 아니기 때문에 어떤 서버에서 문제가 생기면 그거 바로 재접속하면 다른 서버에 붙어서 똑같은 위치에서 똑같이 그냥 다시 플레이할 수 있어요. 그래서 그런 장애에도 좀 관용적인 그런 모습을 보여줄 수 있습니다.

그래서 저희가 이런 시스템을 기반으로 올해 4월에 LBT를 한 번 진행을, Limited Beta Test라고 하고요. 저희가 진행을 했는데요. 작게는 0.25km²에서 크게는 4km²의 크기의 섬들 지형들을 836개를 제공했습니다. 7000명이 플레이하는데 이 정도 섬을 제공한 것이고요. 저는 꽤 넓다고 생각하고 있는데 저희의 목표는 이후에는 조금 더 디자인적인 기반이나 이런 걸 탄탄하게 해서 100km²의 크기의 섬까지 제공하는 것을 목표로 하고 있고요. 그것보다 더 크게 가고 싶은 마음도 있습니다. 단지 너무 크게 지르긴 조금 그래서 10km²로 적어 놨습니다.

간단한 구조를 제가 설명을 드린 거고요. 이제 조금 한 번 살펴보겠습니다. 아까 제가 어떤 객체가 움직일 때마다 다른 서버에 있는 환영들한테 지속적으로 동기화를 시킨다 그랬잖아요.

동기화라고 하는 거는 대부분 다 알고 계시겠지만 뭔가 변화가 일어났을 때 그것에 관심 있는 다른 것들한테 그 결과를 전파하는 거예요. 그래서 서버에서 변화가 일어나면 그걸 DB에도 저장하고요. 클라이언트에도 보내줍니다. 일반적으로 이 동기화가 잦으면 잦을수록 이 DB도 부담이 되고요. 그다음에 패킷 양도 늘어나기 때문에 클라이언트 입장에서도 사실 좋은 게 아니에요. 그래서 잦은 동기화는 분명히 최적화의 대상이지만 그렇다고 이게 안 된다고 당장 플레이가 안 되고 도저히 접속이 안 되고 이런 것까지는 아니거든요.

그런데 저희가 분산 환경에서 이런 구조를 만들다 보니까 새로운 부담이 늘어났어요. 방금 말씀드린 객체와 고스트 간의 환영의 동기화에요. 그래서 같은 곳을 보고 있는 서버, 물리적인 서버가 많으면 많을수록 그만큼 동기화가 부담이 늘어나는 거죠. 그래서 동기화에 대해서 저희가 조금 더 민감하게 느끼게 됐어요. 

예를 한 번 들어볼게요. 저희가 작년 12월에 1차로 LBT Test를 한 번 진행을 했는데요. 처음 오픈한 직후에 딱 괜찮아 보였어요. “아이 생각보다는 잘 되는데” 이러고 기분 좋아하고 있는데 유저가 늘어나니까 갑자기 애들이 확 증가하면서 도저히 플레이할 수 없는 상황이 된 거죠. 그래서 모니터링을 해봤더니 “동기화가 너무 많구나. 우리가 예상한 것보다 더 많구나 했어요.” 서버 지연의 원인은 플레이어가 이동할 때마다 에너지를 조금씩 깎는 거였어요. 되게 단순해요 사실. 문제가. 근데 저희는 계속 동기화를 주변에다 전파하기 때문에 깎을 때마다 동기화가 발생하는 거예요. 그래서 이게 일부러 제가 수치를 좀 크게 보여주고 싶어서 10,000회라고 써놨는데 사실 실제로는 1명당 하나의 객체가 초당 한 4~5회 정도의 동기화를 유발해요. 그런데 한 서버에서 여러 객체를 담당하고 있기 때문에 물리적인 서버에게는 이 정도의 부담이 이상이 발생하거든요. 그래서 굉장히 부담스러운 상황이 맞았습니다. 그래서 렉이 많았고요.

그래서 당연히 동기화를 최적화를 해야겠죠. 이제 패킹도 하고 언패킹도 하고 동기화하는 과정에서 이런 것들 하니까 이런 것도 가볍게 해야 되고 동기화하는 정보 자체도 최소한으로 딱 줄여서 동기화를 해야 되고 이런 작업들이 있는데요. 저는 로직 프로그래머니까요. “제가 할 일이 좀 아닌 것 같다.”해서 조용히 회피를 시도하고 저는 조금 다른 방법으로 개선을 시도했습니다. 동기화 자체를 줄여보자. 

일반적으로 어떤 게 지속적으로 감소할 때 저는 지금 에너지를 예시로 들고 있는 건데요. 에너지가 지속적으로 감소할 때 어떻게 구현하죠? 루프를 돌면서 지정된 시간마다 지정된 것만큼 조용히 깎아요. 이 방법이 전혀 나쁜 게 아니에요. 굉장히 단순하면서도 확실하기 때문에 간단하고 버그도 없어요. 그런데 문제는 이렇게 깎으면 그냥 쭈우욱 내려가는 것보다 동기화 횟수가 훨씬 많아요. 깎을 때마다 내려야 되거든요. 사실 잘 보면 저거는 이미 다 알고 있는 정보에요. 10초간 10이 그냥 천천히 내려갈 거예요. 우린 다 알고 있어요. 그래프도 Linear해요. 근데 왜 우린 저거를 굳이 나눠서 보낼까요?

뭐 이런 걸 예로 들어보죠. 에너지가 확 떨어지고 있다가 물약 좀 먹어서 좀 떨어지는 게 감소했다가 다시 그 물약 효과로 떨어지는 건 끝나고 그 물약 때문에 다시 증가가 된다. 이런 변화에요. 그래서 이걸 하나하나 뜯어보면 처음에는 10초간 10초부터 초당 1씩 해가지고 에너지가 이렇게 떨어지고 있어요. 10초간 이렇게 떨어지고 있고 중간에 제가 물약을 먹어가지고 이걸 좀 복구했어요. 그러면서 이 경향이 생기고 이게 끝난 다음에는 적절한 그냥 무한에서 무한, 언제나 증가하고 있는 자연적인 에너지 회복 속도가 있어요. 이런 것들이 적용이 되면 저런 모양의 그래프가 나오겠죠. 근데 이걸 다 합치면 요 그래프가 나오는 건데 

이걸 매번 언제 계산하고 있겠어요. 사실. 하나의 영향을 매번 해야 되는데 이게 겹치면 겹칠수록 굉장히 복잡하잖아요. 수학적으로도, 수학 관둔지 오래됐는데 계속 생각해야 되고 그래서 저희는

뛰어난 사람에게 시켰습니다. 이거는 Github에 저희가 공개한 라이브러리이고요. 저희가 서버를 Python 기반으로 짜고 있기 때문에 Python으로 되어있는 라이브러리입니다. 그래서 언제부터 언제까지 얼마만큼의 변화량이다. 이거를 계속 입력해주면 자기가 알아서 그래프를 그려줘요. 그래서 그거를 동기화할 수 있는 겁니다.

그래서 이런 언제, 언제까지, 속도 이런 거를 잘 모아두면 그것만 동기화하면 받는 쪽에서도 보내는 쪽에서도 그래프를 알아서 그릴 수 있는 거죠. 그거를 저 라이브러리가 자동으로 해줍니다. 그러니까 이제 그래프 자체를 동기화하는 게 가능해진 거예요.

그래프 동기화, 이렇게 하는 거죠. 한 번 쾅 떨어지고 있다가 바닥을 치고 나서 자연 회복으로 조금씩 증가가 될 예정이었는데 물약을 먹었네요. 물약을 먹으면 그래프의 추이가 바뀌겠죠? 바뀌는 순간부터 그래프를 딱 바꿔서 이거를 보내주면 돼요. 저거는 그래프가 뭔가 더 복잡해진 것처럼 보이지만 사실 제 입장에선 딱 저것만 더한 거거든요? 15초부터 10초간 5를 총 올려라. 그거를 계속 덮어 씌우면 되는 거죠. 이 방식은 또 다른 장점이 하나 있는데요. 분산된 서버는 각기 시간이 조금씩 다를 수밖에 없어요. 네트워크 딜레이도 있고 동시에 모든 일을 딱 처리하기가 힘든데 얘는 추이를 보냈잖아요. 내가 받은 시간이 조금 뒤라도 이게 과거에 일어난 사건이니까 과거의 시간을 바로 읽어서 쓸 수가 있어요. 그래서 수치 동기화보다 그래프 동기화가 이런 면에서 장점이 있습니다.

그런데 이게 당연히 언제나 다 잘 통하는 건 아니고요. 이 until, 언제까지 그러니까 미정인 경우가 있어요. 움직이는 에너지 소비, 아까 문제가 되었던 예시죠. 움직임이 언제 끝날지 사실 알 수가 없어요. 이건 유저의 조작이잖아요. 접속 중이지만 피로도가 오르고 싶어요. 이것도 언제 접속을 해지할지 알 수가 없죠. 그래서 이 끝나는 이벤트를 잡아서 이 변화를 until이 무한이었던 애를 얘를 탁 잘라서 “여기까지야”라고 바꿔주는 어떤 순간이 필요한데요. 이 이벤트를 놓치면 이건 영원히 지속되는 거예요. 피로도는 영원히 오를 거고. 움직임은 영원히 내려갈 거예요.

그래서 약간 변칙적인 운영을 좀 해야 돼요. 그래서 손해를 보면서 하는 건데 정해진 시간만큼만 계속하게 하고 이거를 일정 주기마다 계속 연장하는 방식을 쓰는 거죠. 크게 어려운 해결책은 아니죠. 실수로 이벤트를 놓쳤다면 딱 until까지만 동작해서 손해를 조금 보더라도 많이는 안 보게 되도록이면 이벤트를 잡아서 처리해주는 쪽으로 이런 식으로 작업을 했고요. 이렇게 하면 처음에 그냥 한 번 동기화하고 끝내는 거보다는 훨씬 더 많은 동기화가 필요합니다. 하지만 초당 몇 번 일어났던 과거에 비하면 몇 초에 한 번 정도이기 때문에 몇 분의 1로 굉장히 줄어듭니다.

그래서 이런 방식을 저희는, 아 잠시만요. 가까운 미래의 예측이라고 하고 있어요. 수치가 지속적으로 변하거나 상태가 일시적으로 변하거나 일정 시간 동안만 모션을 잠깐 이거 취했다 돌아오라든지 이런 거 우리가 매번 바뀔 때마다 해줄 필요가 없이 그냥 추이가 바뀌는 순간 그거를 다 동기화해주면 재생하는 쪽에서 알아서 재생하는 거죠. 그런 방식으로 하면은 동기화가 매우 줄어듭니다. 이 방식의 단점은 아까 얘기했다시피 미리 계산해야 되기 때문에 계산 비용은 비싼데 그거를 일반화 시켜서 저희는 라이브러리로 통합하면서 어느 정도 해결을 본 것이죠.

그래서 아까 얘기했던 10,000회 그러니까 초당 4~5회 정도의 동기화 수가 이거를 개선한 뒤에는 이미 다른 곳은 쓰고 있었는데 저희가 사실 실수를 에너지에만 그걸 빼먹은 거예요. 그걸 바꾸고 나니까 바로 1,000회 이하로 떨어졌고요. 이거는 하나의 캐릭터가 초당 한 0.5회 정도 이하로 떨어진 거예요. 그래서 굉장히 큰 개선을 보였다고 할 수 있죠. 그래서 문제가 생겼던 LBT, 첫 번째 LBT보다 한 달 전에 했던 LBT의 서버 비용을 계산해 봤어요. 저희가 실제로 비슷한 유저를 대상으로 숫자를 계산했을 때 AWS를 통해서 저희가 서버 페이스 하고 있는데 그 비용이 얼마 들었는가? 가격이죠. 그걸 비교해봤더니 같은 수의 고객이라면 다섯 배 정도 절약이 됐다. 물론 다른 개선도 여러 가지 있었지만 저는 이 요소가 제일 크다고 생각하거든요. 그래서 아 이런 확실한 효과가 있다라는 거를 보여드리려고 자료를 가져왔습니다.

제가 피처를 이렇게 몇 가지 나열하면서 진행할 텐데요. 그래서 살짝 산만할 수 있지만 제가 하는 의도 자체가 그런 거라서 약간 양해해 주셨으면 합니다. 이번에 얘기할 거는 농사와 날씨에요. 

이거 전에 앞서서 약간 저희의 시스템을 설명할 필요가 있는데요. 저희 세계 스샷이거든요. 보면 자연물이 굉장히 많아요. 저거 다 인터렉션 가능한 애들이에요. 내가 가서 걔 건드려서 나무에서 채집할 수도 있고 풀에서 갈대 뽑아낼 수도 있고 다 할 수 있거든요. 그런데 이게 다 서버에 로딩이 돼 있다고 생각하면 메모리가 별거 아니지만 꽤 커져요. 이런 문제들도 있고 여러 가지 문제가 있기 때문에 자연물과 건축물, 움직이지 않는 애들이죠? 움직이는 애들은 계속 동기화를 해줘야 되기 때문에 어쩔 수 없고요. 움직이지 않는 애들은 실체가 없습니다. 얘네는 메모리에 올라와 있지 않고 그냥 DB에만 존재해요. DB에만 어떻게 존재하냐?

저희가 신기루 그리드라는 이름으로 부르고 있는데요. 물 같은 경우 저장된 건 아니고 그냥 약간 풍취상 넣어 봤고요. 자연물 같은 경우는 심지어 더 자세한 것도 필요 없어요. 얘가 무슨 자연물인지만 알면 돼요. 갈대면 갈대. 나무면 나무. 사과나무에 사과가 한 개 열렸는지 두 개 열렸는지 옆에서 뛰어가는 사람은 크게 관심이 없어요. 그렇기 때문에 종류만 저장을 해놓습니다. 건축물은 약간 복잡한데요. 재료에 따라서 룩도 바뀔 수 있고 뭐 여러 가지 우리가 예상할 수 없는 일들이 있기 때문에 외형 패킷을 팩킹해서 패킷 자체를 캐싱을 해줍니다 그리드 안에다가 그래서 시야에 들어오는 순간 그냥 팩킹할 필요도 없이 바로 그 패킷을 보내버리는 거죠. 이런 방식을 취해서 저희가 일종의 캐시 레이어라고 할 수 있겠죠. 신기루 그리드라는 거를 이용해서 캐싱을 하고 있고요.

이 신기루가 실체화하는 순간은 내가 그것에 실제 관심이 생겼을 때에요. 그래서 내가 사과를 따야지. 그럼 사과나무를 건드려야겠죠. 산딸기 덤불은 원래는 산딸기 덤불이라고 그냥 타입만 있었는데 건드리는 순간 생기고 심지어 섬이 생긴 이후에 태초부터 아무도 건드리지 않은 자연물이라면 DB에 그 인스턴스가 존재할 필요도 없어요. 그냥 그 위치에 산딸기 덤불이라는 게 있다는 것만 알면 되고 얘를 건드리는 순간 아 얘가 없는데 거기에 있긴 있지 이제 만듭시다. 이런 식으로 진행을 하면 되는 거죠. 이렇게 하고 나서 내가 일정 시간 동안 인터렉션을 하지 않으면 조용히 메모리에서 내려갑니다. 현재 상황은 객체 DB에 저장이 되기 때문에 나중에 다시 꺼낼 땐 복구가 되고요. 메모리에서만 내리는 거죠.

이 신기루 장점은 당연히 메모리 사용량이 최소화가 되고요. 그리고 약간 부가적인 효과랄까? 저희도 의도한 거긴 하지만 아까 말씀드렸던 시야의 개념에 의해서 정적인 객체들도 시야 안에 있기 때문에 언제나 주변에 움직이는 것들에 관심이 있어요. 근데 메모리에 있으면 나는 사실 그냥 지나가기만 하는 건데 동기화를 계속 받아야 되잖아요. 그래서 그럴 필요가 없으니까 내려가 있으면 동기화 자체도 훨씬 줄어들게 되는 거죠. 그래서 이런 장점들이 있습니다.

그런데 이 신기루라는 게 사실 모든 걸 다 커버해주는 건 아니에요. 이제 얘를 들면 시간이 변하면 외형이 변하는 것들, 캐시 레이어잖아요. 캐시가 의미가 없어지게 될 수가 있는 거죠. 그래서 불타버린 모닥불, 모닥불이 켜져 있었는데 아무도 건드리지 않았어요. 하지만 시간이 다해서 얘가 조용히 꺼졌습니다. 내구도가 다해서 건물이 무너졌어요. 아니면 작물이 다 자라가지고 얘가 짠 열매가 열렸어요. 우리가 건드리지 않아서 인터렉션하지 않았기 때문에 메모리에 한 번도 올라온 적이 없는 애가 모습이 바뀌어야 돼요. 그래서 더 쉬운 방법을 저희가 선택을 했죠. 외형 캐시에 만료 시간을 넣는 거예요. 딴 하고 만료가 되면 각자 서버에서 알아서 아 내가 관심 있는 부분에 만료된 애가 있네? 그러면 내가 잠깐 DB에서 걔만 불러와서 캐시만 바꿔놓자. 그런 식으로 처리를 하는 거죠.

그래서 저희가 한 지역을 여러 개의 서버가 보고 있을 수 있잖아요? 그래서 각자 알아서 음 그래 바뀌었으니까 처리해야지. 이런 식으로 해서 자기가 관여하고 있는 클라이언트들한테 이거 바뀌었으니까 클라이언트에서 바꿔줘. 이렇게 동기화를 시켜줍니다. 그런데 여기까진 괜찮았는데

농사의 경우, 우리가 얘기하려 그러던 이 경우에는 약간 문제가 있었어요. 농사는 씨앗을 심으면 토양 적합성과 물을 얼마나 잘 줬는가 이런 거에 따라서 얘가 성공적으로 발아할 것인가에 대한 확률이 매겨져요. 확률 자체는 이미 있는 데이터를 기반으로 내려지는 거기 때문에

어떤 서버에서 봐도 똑같은 확률입니다. 그런데 외형 캐시를 바꾸는 건 각자 알아서 하죠. 그러다 보니까 확률은 같은데 혼자 다른 애, 어떤 애는 피고 어떤 애는 안 피고 이런 문제가 생기는 거죠. 그래서 다 죽어 있는 것 같아서 에이 버려야지 그러고 눌렀는데 어? 사실 잘 자라있었네. 이런 일이 생길 수 있는 거예요. 

그래서 요거를 해결하기 위해서 저희가 결정론적이라고 하는, 그러니까 태초부터 언제나 결정이 돼 있어서 얘넨 언제나 그 결과가 날 거야. 이런 느낌으로 만들었는데요. 랜덤이긴 랜덤인데 언제 어디서 확인하더라도 같은 결과가 나와야 하기 때문에 랜덤 시드를 저희가 임의로 고정을 했어요. 작물마다 작물이 완성되는 순간은 완전히 다르겠죠? 보는 작물마다 이거는 초 단위까지 달라야 되니까요. 마이크로 초까지도 다를 테니까요. 그래서 이거를 랜덤의 시드로 삼아서 랜덤을 구하면 당연히 시각이 다 다르면 다양한 결과가 나오겠지만 어쨌든 시각이 완전히 같은 경우에 대해서는 난수가 똑같은 난수가 나오기 때문에 어떤 서버에서 계산을 해도 똑같은 결과를 가져올 수 있는 거죠. 

이런 접근은 저희가 날씨에서도 비슷하게 썼어요. 지금 사진에서 보시면 집중 호우 같은 건데요. 한쪽은 그냥 구름만 껴있고 한쪽은 비만 오죠. 우리 되게 당연해요. 내가 비가 지금 여기 오고 있으면 내 옆에 있는 사람도 같이 비가 오고 있어요. 우리에겐 당연한 일이지만 분산 서버에서는 당연한 일이 아니에요. 왜냐하면 그 지역을 다양한 데서 다 보고 있기 때문에 날씨를 누군가가 중앙에서 컨트롤해서 자 비가 오기 시작합니다. 촤악 뿌리고 이런 일들을 해야 돼요. 그런데 이거는 동기화를 계속해야 되고 신경 써야 되고 중앙이 되는 우리 중앙 서버 없는 거 만들려 그랬는데 뭔가 억지로 중앙을 만들어야 되고 그런 일들이 있잖아요. 그래서 그것도 결정론적 날씨다. 그래서 어떤 지역이면 같은 결과가 나와야 하지만 시간대별론 적당히 랜덤하게 만들기 위해서 지리적 위치와 그다음에 현재 시각에 적당히 가공해서 어느 정도 구간마다 변해야 되니깐 그런 것들을 반영해서 랜덤을 구하면 시기적으론 랜덤이지만 지리적으론 언제나 같은 결과가 나오는, 동기화가 필요 없이 누구나 공식을 거치면 똑같은 날씨가 나오는 그런 방식으로 구현을 했습니다. 이런 걸 결정론적이라고 얘기를 하고 있는데 이런 방법을 적극적으로 활용할 필요가 있었습니다.

저희 게임의 또 가장 주요한 피처 중 하나가 개척이었죠. 개척 같은 걸 재밌게 하게 하고 싶다. 개척의 가장 핵심은 건설입니다. 아무도 없는 땅에 내가 나만의 뭔갈 만들고 거기다 모여서 마을을 만들고 사회를 만들고 이게 개척의 핵심이죠.

건설을 해야겠는데요. 건설이란 거는 이제 제작, 도구 좀 만들고 나무 좀 따오고 이런 것보다 훨씬 더 오래 걸리는 일이에요. 현실 속에서도. 게임 속에서도 그거를 막 빠르게 해줄 순 없어요. 너무 빠르게 하면 막 난개발이 일어나가지고 보기에도 지저분하고 유저들도 귀찮아져요. 그래서 시간을 어느 정도 길게는 줘야겠는데 우리 개척이고 사회적인 것도 만들고 싶고 하니까 협동을 하면 그 시간을 조금은 줄여주자. 이런 식으로 저희가 건설을 구현하기로 했습니다.

내부적으로 저희는 원기옥이라고 부르고 있어요. 다들 나에게 힘을 줘. 그래서 누군가가 건설을 시작하면 요거를 같이 옆에서 도와주면 그냥 빨라지는 거죠. 스타크래프트1 같은 것도 비슷한 방식이죠. 이거는 저희가 현재 채용하고 있는 방식은 아니고 프로토타입이에요. 저희가 이런 식으로 개발을 시작했고요.

그런데 그냥 같이 모여줘! 까지는 괜찮았는데 알고 보면 숨어있는 요소들이 몇 개 있어요. 당연한 얘긴데 건설하면 에너지도 좀 써야 되고 도구 쓰면 내구도도 좀 써야 되고 그다음에 또 하나에서 좀 특이한 거는 이게 오래 걸리잖아요. 오래 걸리는데 모바일은 네트워크가 불안정해요. 언제 끊길 수도 있어요. 내가 실수로 눌러서 전화를 받아야 될 수도 있고요. 그럴 때마다 이걸 다 끊어버리면 신경질이 많이 나요. 그러니까 접속이 끊어져도 내가 하고 있던 행동은 좀 그냥 하게 해주세요. 이런 요구가 있습니다. 이런 요구를 만족시키기 위해서

할 수 있는 쉬운 방법이 있어요. 루프를 돌면서 도구 내구도 깎고 에너지 소모한 뒤에 아 다 잘 됐네? 그러면 이제 진행도 조금 올려. 이거를 플레이어마다 다 돌면서 해주면 돼요. 근데 아까도 얘기했지만 루프라는 방법은 저희가 쓰기 쉬운 방법이 아니에요. 왜냐하면 중앙 서버라는 게 없거든요. 어떤 시스템이 중앙이 되는 애가 없어요. 이건 내 담당이야. 이런 게 별로 없어요. 모두가 합의해야 됩니다. 다들 객체가 다른 서버에 흩어져 있기 때문에 이거를 한 번에 루프를 돌면서 장기적으로 잘 관리해주면서 이걸 해줄 애가 없는 거예요. 그리고 그것뿐만 아니라 루프를 통해서 하는 것 자체가 저희는 계속 동기화를 유발하기 때문에 회피하고 싶었죠. 

그래서 “그래프 동기화 쓰면 되지 않겠어? 우리가 게이지라는 것도 열심히 만들어 뒀는데”라고 생각을 해서 쓰기로 했습니다. 건설력 그러니까 “내가 얼마나 건설을 잘 하는가?” 이걸 속도 삼고 “도구의 내구도가 얼마 남았는가?” “남은 에너지가 얼마인가?”를 가지고 끝날 시간을 계산할 수 있겠죠. 내가 얼마나 더 참여할 수 있는지를 계산할 수 있고 이거에 따라서 참여하는 사람들의 이것들을 다 합쳐가지고 이게 언제 끝날지 진행이 얼마나 빠르게 됐다가 느려졌다 빨라졌다 느려졌다 이걸 다 계산할 수 있겠죠. 그래서 “이렇게 하면 되겠지”라고 생각을 시작을 했어요.

그런데 막상 진행을 하니깐 문제가 있는 거예요. 예를 들어서 참여자가 자의로 중단했어요. 내구도가 떨어지거나 그런 게 아니고 자의로 중단했어요. 그러면 완성이 아무래도 더 늦어질 수밖에 없겠죠. 그러면 그래프를 다시 그려야 돼요. 그런데 이 진행 그래프만 다시 그리는 게 아니고 에너지와 내구도의 소모도 그래프가 달라지거든요? 그러니까 각 객체한테 귀속된 건축물한테 귀속된 것 말고 각 객체에게 귀속된 수치들도 다 그래프를 다시 그려줘야 되는 거예요. 내가 한 명이 빠졌지만 참여하고 있는 모든 사람들의 데이터를 한꺼번에 수정해야 되는 거죠.

할 수 있어요. 못하는 건 아니죠. 또 나가면 다시 그리면 돼요. 그런데 심지어 그중에 한 명이 오프라인이에요. 우린 오프라인일 때도 이 작업이 진행됐으면 좋겠다고 생각했거든요. 그런데 나는 다 온라인일 때는 그냥 아 이거 어떻게 반영해 줘 이렇게 해서 시켰는데 한 명이 오프라인이면 오프라인인 애를 굳이 끄집어 올려서 DB에만 있는 애를 다시 끄집어 올려서 반영시키고 내려줘야 되나? 그 사이에 접속하면 어떡하지? 그 동시에 둘이 초과해서 둘이서 다 얘를 변형하려 하면 어떡하지? 이런 여러 가지 복잡한 문제들이 생기는 거예요. 아 혼란해요.

무엇이 혼란한가? 분산된 환경에서는 객체들이 다 다른 프로세스에 흩어져있습니다. 행동의 여파가 여러 객체에게 동시에 영향을 주는 경우에 시간이 좀 걸려요. 뭐 좀 맞추고 순서도 맞추고 정합성도 맞춰야 되고 다 해야 되는데 물론 이게 하나의 서버 안에서 물리적인 서버 안에서 일어난 일이면 단순하겠죠. 같은 메모리에 모여있으니까 같이 고쳐버리면 되잖아요. 그런데 분산이라서 좀 문제가 생기는 거예요. 이 행동이 더군다나 동시에 여러 곳에서 겹쳐서 온다면 아 이거 더 복잡하죠. 그리고 메모리에도 안 올라와 있어. 아 힘들어.

다행히 그 시점에서 저희가 디자인적으로 방향을 좀 선회하기로 했어요. 건설을 오랫동안 붙어있으면 유저가 아무 행동을 할 수가 없잖아요. 그러면 플레이 진행의 흐름도 끊기고 아 지루하고 그만할까? 이런 생각이 들겠죠? 그래서 아 이거는 모바일 게임의 특성과 맞지 않다. 차라리 PC 게임이면 켜두고 잠깐 책 보다가 이거 해도 되는데 모바일엔 맞지 않다. 그러니까 앞에 붙어서 건설하는 시간은 짧게 하지만 협동의 느낌은 내주세요. 이런 식으로 디자인적으로 약간 선회를 했습니다.

그래서 개선된 원기옥은 이런 방식이에요. 현재 저희가 선택하고 있는 방식이고요. 건설 자체는 한 명이 합니다. 짧은 시간 수초 내에 끝내기 때문에 내가 혹시 뭔가 문제가 생겨서 도중에 튕겼다가 다시 들어와서 다시 한다 그래도 크게 불만이 있을 정도의 시간은 아니에요. 몇 초 정도면 되거든요. 그렇게 하되 건축물이 완성된다고 해서 건설이 됐다고 해서 바로 내가 사용할 수 있는 건 아니고요. 뭔가 풀이 말라야지. 약간 이런 느낌인 거죠. 나무가 잘 말라서 잘 꽉 끼워져야지. 이런 느낌으로 건설한 뒤에 마무리 시간이 필요하다는 개념을 넣었어요. 그래서 일정 시간이 흘러야지 이게 사용할 수 있는데 친구들이 지나가다가 어? 쟤가 만들었네? 좀 줄여줘야지. 비동기적으로 액션을 취하면 그 시간을 줄여주는 거죠. 조금 더 모바일스러운 방법이죠? 우리가. 그래서 이런 식으로 디자인을 선회하면서 실제 앞에 붙어야 되는 시간은 짧으면서 협동의 느낌을 냈죠. 이 방법의 가장 큰 장점은 모든 행동이 1:1이라는 거예요. 내가 하는 행동의 여파가 다른 객체들에게 영향이 없고 나랑 건축물만 소통하면 돼요. 그렇기 때문에 행동의 여파가 매우 좁아서 비슷한 느낌이고 비슷한 결과를 가져왔지만 훨씬 더 시스템의 입장에서는 감당할 수 있는 거죠.

동시에 여러 객체를 막 변조하는 일은 분산된 서버에서는 굉장히 힘든 일이에요. 그래서 이거는 구현 비용도 비싸고요. 비싸게 해서 할 수는 있어요. 하지만 그러고 나서 버그는 많아요. 그러고 나서 수정할 때마다 아 힘들어요. 이런 방법은 애초에 회피하는 게 좋습니다. 분산된 환경이라는 거 자체에 아예 맞지 않는 시스템이었던 거예요. 그래서 이런 하나의 행동으로 인해서 여러 개의 데이터가 동시에 변경되는 일들은 분산 서버에서는 되도록 하지 않고 하나씩 행동을 끊어서 최대한 1:1로 모든 일, 뭔가 약간 Stateless하다고 할까요? 그런 느낌으로 동작이 진행될 수 있게 구현을 해야 됩니다.

다음 피처로 한번 넘어가 볼게요. 저희 게임에 건설이 있으니까 건설을 내 거로 만들고 싶잖아요. 나만 쓰고 싶잖아요.

그래서 사유지라는 개념이 있어요. 저희 베타테스트에 참여하셨던 유저분이 그려주신 건데요. 잘 보일지 모르겠는데 공룡을 잡았는데 머리만 사유지에 들어가 있는 거예요. 남의 사유지에. 캘 수가 없어. 아 암 걸려. 이런 거를 만화로 그려주셨어요. 이 상황 자체가 아주 긍정적이고 그런 건 아닌데 사유지를 표현할 수 있는 되게 단면이라고 생각해서 제가 가져왔어요. 저희가 가지고 있는 사유지는 영역이에요. 내 영역을 선포하고 그 안에서 배타적인 권리를 갖게 되어있습니다. 

이 배타적인 권리는 당연히 주변에 나눠주고 싶겠죠. 그래서 친구, 외부인, 아직 저희가 구현해서 제공하고 있진 않지만 부족원들에게도 제공할 수 있습니다. 원하면 일부만 줄 수도 있고요. 전체 다 줄 수도 있고요. 이런 식으로 할 수도 있는데요.

요즘 무서운 세대에요. 가족 간에도 범죄가 생기는 문제에요. 가족 간에도 범죄가 생기는 시댑니다. 나는 친구를 믿고 권한을 줬지만 내가 생각했던 것만큼 그 친구가 착하지 않을 수 있어요. 내 사유지에서 무슨 일이 일어나는지 난 알아야겠어요. 

그래서 저희가 만든 시스템은 사유지 이력 시스템입니다. 내가 사유지 주인일 때는 내 사유지 안에서 일어나는 일에 대해서 제가 이력을 조회하고 관람할 수 있어요. 그래서 오케이, 내가 담아 논 거 싹 빼가는 나쁜 놈. 제가 이걸 보고 잡을 수 있죠. 뭐 요거까진 좋았는데

이게 수동적인 시스템이잖아요. 내가 가서 언제나 확인을 해야 돼요. 문제가 생겼을지 모르니까 언제나 확인을 하고 있든지 아니면 뒤늦게 뭔가 어? 내가 찾는 게 없네 하고 가서 그걸 확인해야 돼요. 이런 수동적인 시스템이라 문제를 발견한 이후엔 이미 늦을 수가 있으니까 이거를 빠른 피드백을 하고 싶어서 너 빼갔지? 하기 위해서 실시간으로 알림을 받고 싶어요.

그래서 접속 중인 애한테는 그냥 빼가면 이력 이렇게 기록 남길 때같이 써주면 돼요. 너 이런 이력을 쌓았는데 이런 게 있어. 너도 실시간으로 봐. 이러면 되는데 오프라인인 캐릭터는 여전히 좀 문제가 돼요. 이거를 어떻게 해야 될까? 오프라인이니까 얘를 온라인으로 임시로 끌고 오는 것까진 좀 부답스럽고 얘를 그냥 얘만 살짝 고쳐야겠는데 만약에 그 사유지에서 동시에 누가 활동을 하고 있다면 고치고자 하는 사람이 여러 명일 수 있겠죠. 그러면 또 이렇게 저장이 겹치니까 이런 경우에 좀 안전하게 처리할 수 있어야 될 것 같아요. 하나의 데이터를 여러 명이 접근을 시도할 때 안전하게 하는 방법 

우리가 흔히 아는 낙관적 트랜잭션이라는 방법이 있죠. 낙관적 트랜잭션을 간단히 얘기하면 어떤 문서를 내가 수정하고자 할 때 DB에서 읽어와요. 고치고 고친 걸 가지고 저장하려 그래요. 그런데 거절당했어요. 왜냐하면 내가 확인해보니까 네가 알고 고친 데이터는 이미 누가 갱신해서 그건 옛날 거야. 그건 믿으면 안 돼. 그러면 어떡해요? 낙관적이잖아요. 그래 다시 할게. 그리고 다시 데이터를 불러와서 그걸 다시 합니다. 그리고 나서 계속해서 내가 이걸 작업하는 동안 누가 갱신시키지 않았다는 걸 확실히 할 때까지 계속 다시 작업을 해요. 또 방법은 동작 자체는 사실 뭐 단계가 있는 것 같지만 사실 단순하거든요? 단순하고 구현도 그렇게 어려운 편이 아니에요. 대신 하나의 문서만을 대상으로 하는 그런 방법입니다.

근데 낙관적 트랜잭션을 쓰고 싶은데 낙관적 트랜잭션에는 약간 특징이 있어요. 언제나 재실행이 가능해야 돼요. 당연하죠? 그리고 사이드 이펙트가 없어야 돼요. 내가 이걸 실행하는 도중에 다른 사이드 이펙트를 뿌리면 나는 이게 계속 재실행 될 거기 때문에 사이드 이펙트가 누적이 돼요. 그런 문제가 있기 때문에 사이드 이펙트가 없는 코드임을 확실히 해야 되거든요? 그런데 우리가 지금 낙관적 트랜잭션의 대상으로 삼고 싶은 건 객체죠. 대표적인 예로 플레이어죠. 플레이어는 거대한 로직 덩어리에요. 얘를 상대로 모든 행동들이 다 재실행이 가능하고 사이드 이펙트가 없고 이거 보장하는 거는 굉장히 스트레스받는 일일 거예요. 그래서 저희는 객체를 대상으로는 낙관적 트랜잭션을 안 하고 있습니다.

그러다 보니까 그럼 우리는 낙관적 트랜잭션 못 쓰겠네? 그러면 어떻게 하냐? 저희는 어떤 객체에다가 뭔가를 변형을 할 때 주인이 있잖아요. 담당하고 있는 서버한테 소유권까지 줍니다. 베타적인 권리에요. 어떤 다른 서버도 그 객체를 건드릴 수 없고 그 객체에다가 뭔가 변경하고 싶은 게 있으면 걔를 찾아서 그 서버한테 물어봐야 돼요. 나 이거 하고 싶은데 피 좀 10 좀 대신 깎아줄래? 그래 나 맞아줄게. 이런 식으로 깎아야 되는 거죠. 그런데 우리는 접속 중이 아닐 때 얘기를 하고 있었잖아요.

그래서 접속 중이 아닐 때 약간 변칙적인 방법을 쓰기로 했어요. 객체마다 태스크 큐를 DB에다 만들고 거기에다 작업을 큐잉하는 거죠. 그래서 오프라인인 애들은 이 태스크 큐 자체는 되게 단순한 구조잖아요. 낙관적 트랜잭션 할 수 있어요. 작업을 넣는 정도니까. 그래서 이 큐잉하는 부분과 실제 객체를 따로 띄워 놓고 큐에다가 DB에다 직접 계속 낙관적 트랜잭션을 하면서 작업을 푸시 해 두면 접속 중이라면 rpc를 통해서 질러주고요. 내가 큐잉 해놨으니까 알아서 꺼내서 가서 해하고 접속 중이 아니었다면 내가 접속할 때마다 밀린 우편을 좀 볼까? 이러면서 처리를 합니다.

그래서 요런 시스템을 이용해서 사유지 알림을 할 수 있어요. 그래서 이런 오프라인인 애를 대상으로 할 때는 복잡한 행동까지는 조금 힘들고 간단하게 큐잉해서 그거를 실행만 보장해주는 방식으로 저희는 작업을 했습니다.

마지막 피처인데요. 부족, 사실 아까 저희가 지원 안 하고 있다고 제가 아까 얘기했었죠.

하지만 저희가 완성도를 올려서 보여주고 싶은 마음에 아직 LBT에는 추가는 안 했지만 기반 작업까지는 저희가 해놨어요. 그런데 이게 기반 작업을 하다 보니까 나름 독특한 면이 있네? 라고 생각해서 오늘 발표에 하나 더 넣기로 했습니다. 

부족과 플레이어의 관계는 서로 참조하는 관계에요. 부족도 제가 내 부족이 있는 걸 알고 나도 내가 저 부족에 있다는 걸 알고 있어야 돼요. 서로 상호 참조 관계고 가입과 탈퇴는 양쪽 문서를 동시에 수정해야 돼요. 들어가면 들어갔다고 동시에 탁 써줘야 되고 나오면 나왔다고 둘 다 탁 써줘야 돼요. 정합성이 보전이 돼야 되겠죠. 언제나 확실히 해야 돼요.

이거 보장이 안 되면 막 이상한 상황이 생기겠죠. 나는 가입된 줄 알았는데 부족은 모르고 있었다느니 부족은 가입된 줄 알았는데 나는 모르고 있었다느니 탈퇴 뭐 가입했는데 이런 식으로 여러 가지 깨지는 상황이 나오기 때문에 요런 걸 보장할 필요가 있어요.

그래서 여러 개의 문서를 대상으로 DB가 저장하는 작업을 수행하는 우리가 ACID 트랜잭션이라 하죠. 그래서 이런 특성들 많이들 아시는 거일 텐데요. 이런 거를 보장을 하면 이렇게 해서 잘 할 수 있는데 저희는 DB도 분산화했어요. 일반적인 RDB는 분산에 조금 불리한 부분이 있기 때문에 저희는 NoSQL을 사용하고 있습니다. NoSQL에서는 ACID가 조금 힘들어요. 

그래서 그것에 근사한 버전인 BASE 트랜잭션이란 거를 쓰고 있어요. 내용은 그렇게 약자가 그렇게 중요한 건 아니고 중요한 건 Eventual Consistency거든요? 그래서 이게 약간에 관용성을 보여서 ACID 보다 결과적으로는 대충 다 맞을 거야. 이런 식으로 하는 방법이에요. 그런데 요 방법 자체는 ACID 트랜잭션이라는 건 DB에서 제공하는 거예요. DB 솔루션에서 그거를 보장해줘요. 우리가 정해진 방법대로 잘 넣기만 하면 그런데 BASE 트랜잭션은 NoSQL을 대상으로 어플리케이션 레벨에서 그걸 비슷하게 구현하겠다는 거거든요. 그러니까 어플리케이션 레벨에서 그걸 신경을 써줘야 돼요. 게임 로직도 어플리케이션이죠. 그러니까 두 개가 연결돼 있기 때문에 이것저것 처리하려면 좀 비싸요. 신경도 좀 써야 되고 조금 더 복잡하고 안 되는 거 아니지만 좀 신경 쓰기 싫어요.

그래서 아 이거 상호 참조 관계기는 한데 BASE 트랜잭션까지 안 쓰고 낙관적 트랜잭션만으로 쓰면 안 될까? 낙관적 트랜잭션은 아까 설명했다시피 가볍고 단순한 구조지만 몇 가지 특성만 지키면 하나의 문서를 대상으로 잘 할 수 있는 그런 방법이에요.

그래서 아 그러면 우리 상호 참조 관계로 만들지 말고 가리키는 관계 그러니까 두 개가 동시에 정보를 가지고 있는 방식 말고 서로 잘 가리키는지만 확인하게 하자. 그래서 가입을 신청할 때 부족 문서는 건드릴 필요 없이 내가 아 나는 A라는 부족에 가입하고 싶어라고 내가 써놓으면 부족 입장에서는 DB에다가 쿼리를 날려서 검색해요. 나한테 나는 모르고 있는데 나한테 관심 있는 애가 있나? 검색하면 아 이 사람이 가입 신청한 사람이구나라는 걸 알 수 있죠. 예를 들어서 얘를 가입시킨 애를 부족장이 얘를 쫓아내고 싶어 그러면 조용히 내 부족에 있는 정보만 끊으면 돼요. 짠 끊으면 가입이 탈퇴가 됩니다. 왜냐하면 저쪽에서 가리키고 있지만 이쪽에서는 안 되니까 상호 참조가 아니잖아요. 그런데 문제는 이게 가입 신청한 상황과 다르지가 않아요. 모양이. 그러니까 내가 누군가를 쫓아내면 걔가 자동으로 가입 신청한 상태가 되는 거예요. 되게 이상한 상황이죠. 

그래서 요걸 좀 해결하고자 약간 로그인 세션 같은 느낌의 것을 도입했습니다. 그래서 가입 신청 시에 나는 임의의 토큰을 발행하고요. 그걸 같이 보내요. 수락할 때도 그걸 같이 저장합니다. 그러면 화살표에 토큰이란 이름이 붙어있는 거죠. 사실상. 그래서 요거를 붙여놓으면 이제 해결이 돼요.

퇴출 시에는 저 가리킴을 삭제하는 게 아니고 만료시킵니다. 만료를 시키면 가입 신청과는 달라요. 정보는 있는데 만료된 거예요. 아 얘는 가입 신청이 아니고 내가 쫓아낸 애구나라는 걸 알 수 있죠.

자진 탈퇴는 탈퇴는 똑같아요. 그냥 내가 내걸 지우면 돼요. 그러면 한쪽만 가리키고 있기 때문에 얘는 여전히 무효한 상태가 됩니다. 뭐 다시 가입할 때는 가입하면서 언제나 유니크한 토큰을 재발행하기 때문에 토큰이 달라서 이 화살표는 부족에서 가리키는 거는 의미가 없다는 걸 우리가 잘 알 수 있어요. 그래서 명확합니다.

초대도 비슷한데요. 초대는 부족 쪽에서 토큰을 발행해서 미리 보내놔요. 나는 이때 낙관적 트랜잭션을 위해서 나한테만 부족한테만 정보를 저장해놓고 쟤한테 비동기를 이렇게 메시지를 날려두면 받는 애가 어? 그래 나 가입하고 싶어라고 수락을 누르는 순간 부족 데이터와 상관없이 내 정보만 수정하면 나는 같이 상호 참조 상태가 되는 거죠.

BASE 트랜잭션 싸야 된다고 생각했는데 잘 하니까 낙관적 트랜잭션만으로도 잘 수행이 되더라고요. 그래서 가입 신청, 탈퇴, 초대 수락 이런 거는 플레이어 데이터만 수정하면 되고 수락, 강제 탈퇴, 초대는 부족 데이터만 수정하면 되고 모든 액션을 다 낙관적 트랜잭션으로 해결하는 방향으로 했습니다. 아까 얘기했다시피 일반적인 웹 같은 데서 쓰는 로그인 세션과 크게 다른 방식은 아니에요. 그냥 차용한 정도에 불과합니다.

이런저런 되게 좀 산만하게 살짝 진행을 했는데요.

저희 중앙 서버가 없다는 거는 약간 원탁의 기사 같은 거라고 생각을 하고 있어요. 되게 좋아요. 민주적이고 다들 의견을 잘 낼 수 있어요. 하지만 느려요. 모두가 합의를 해야 되고 절차도 복잡할 수 있고요. 이거를 극복하려면 되게 많은 일을 해야 될 것 같아요. 아 저거 생각만 해도 골치가 아파요.

그런데 사실 분산은 이미 여러 곳에서 활용하고 있는 서비스거든요. 오늘 얘기했던 많은 아이디어들이 웹 서비스의 경험들을 참고해서 저희가 반영을 시킨 결과에요. Stateless한 것처럼 액션을 하나씩 쪼개서 이렇게 해라. 언제나 정보를 추가적으로 보내고 그래서 그거 하나만으로 완결성 있게 행동이 이루어지게 해라라든지 아니면 로그인 세션 같은 거를 차용한다든지 그래서 왜냐하면 이 분산 서비스라는 거는 안정성과 가용성을 위해서는 굉장히 탁월한 선택이에요. 어쩌면 당연해요. 그렇기 때문에 이미 많은 데서 쓰고 있는데 MMORPG라는 분야에서 사실 잘 안 쓰고 있는 것뿐이거든요.

그래서 이런 제가 구조들을 설명을 했죠? 복잡한 계산은 한 곳에서만 하고 퍼트리고 모든 서버가 꼭 계산을 해야 될 일이 생기면 결과가 언제나 똑같을 수 있도록 잘 보장해 주고 동기화는 최대한 하지 말고 좀 뜨문뜨문할 수 있도록 노력하고 그다음에 모든 객체에 여파를 주는 일은 최대한 하지 말고 1:1로만 잘 얘기합시다. 이런 방식으로 구조 자체를 좀 분산 쪽에 맡게 짜는 게 필요하다라는 얘기를 오늘 한 건데요.

처음에 저희가 이걸 그냥 다한 건 아니고요. 제가 뭘 이렇게 분산 전문가여서 난 할 수 있지. 라고 생각해서 한 건 아니고 저희가 해야 되니깐 그냥 한 거예요. 그래서 처음에는 익숙한 방식으로 평범한 방식으로 하다 보니까 계속 제작을 많이 하고 작업 방향 자체가 일반 사람들의 멘탈 구조와 다른 방향이 있어서 매번 생각을 새롭게 해야 돼요. 아 내가 생각했던 그냥 자연스럽게 생각하는 대로 하면 안 되는구나. 이런 문제가 있는데 하지만 오늘 발표한 사례로 볼 수 있다시피 되게 일반론적인 해결 방법들이 있어요. 그냥 되게 복잡한 방법도 아니거든요. 보시면서 그렇게 생각하신 분도 있을 것 같아요. 아니 뭐 저런 걸 굳이 발표를 하고 있어. 그냥 하면 되지 않아? 약간 이런 생각도 드실 거예요. 맞아요. 그런 거예요. 

단지 오늘 오전에 있었던 이흥섭 님의 발표에 올라왔던 질문인데요. “아 이거 이렇게 디자인하면 로직 만들기 힘들 텐데 이거 생산성 괜찮나요? 이거 너무 힘들지 않아요?”라고 하는 질문에 제가 답하고 싶은 거예요. 고비용인 건 맞아요. 하지만 이 고비용의 핵심은 적응 비용이에요. 우리가 MMORPG를 개발하면서 분산 환경이라는 걸 별로 접해본 적, 실제로 그걸 내가 지식적으론 알고 있지만 막 해본 적이 없기 때문에 실제 작업하려 그러면 게임 로직과 충돌하는 부분들이 생겨요. 이미 많은 사람들이 시도해서 다들 “어 그래 저기도 저런 거 해봤데 저기도 저런 거 해봤데 내가 저번에 들어봤더니 이런 일이 있었어.” 이런 게 자연스럽게 공유가 돼 있었다면 저희도 지금보다 더 쉽고 더 빠르게 개발을 했을 거라고 생각합니다. 제가 오늘 얘기하고 싶었던 거는요. 분산 서버 환경이라는 건 생각보다 그렇게 어려운 건 아니거든요. 처음에는 되게 어려울 것 같았어요. 아 내가 이걸 하는데 정말 골치 아파요. 게이지 아까 그래프 동기화 처음에 지금 얘기는 쉽게 했지만 처음엔 이거 매번 하라고? 이거 매번 고민하라고? 이랬지만 지금은 굉장히 자연스러워요. 모든 시스템에 자연스럽게 할 수 있거든요. 그냥 처음에 사고방식만 살짝 바꾸는 데만 비용이 들 뿐이지 의외로 할만합니다. 그리고 분산 특성이 가지고 있는 안정성이나 가용성은 매우 좋은 특징이에요. 매우 좋습니다. 저희도 득을 많이 봤거든요. 여러분들도 MMORPG 개발 계획이 있을 때 이런 분산 구조를 택함에 있어서 망설임 없이 할 수 있겠구나라고 하고 이런 NDC 같은 걸 통해서 다들 많은 공유해주셨으면 좋겠습니다. 감사합니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
