디지털 양피지
콘텐츠를 보기 위한 수단은 묶음으로 제공되어야 한다
나는 2014년에 넷마블 기술 조직의 모바일게임개발팀에 소속되어 있었다.
당시는 모바일 게임이 부흥하던 시기였다. 나는 넷마블 본사의 기술 조직에서 근무하며 여러 게임 스튜디오에서 공통으로 활용할 수 있는 게임 서버 관련 공통 기술을 연구하고 개발하는 일을 하고 있었다. 그때만 해도 대부분의 모바일 게임 제작사들이 영세했다. 게임 기획, 아트, 클라이언트 역량은 우수했지만 서버 기술은 보유하지 않은 곳이 많았었다. 우리 팀은 준비 중인 다양한 게임들이 적시에 론칭할 수 있도록 게임 서버의 코드 베이스와 배포 환경, 게임 서비스 아키텍처, 캐시, 영속적 저장공간 등에 대한 여러 사례들을 도출했다. 그리고 그 사례들을 토대로 개별 제작사에 맞춤형 엔지니어링 패키지를 제공했다.
우리 팀의 역할은 기술PM의 역할과는 좀 달랐다. 실제로 동작하는 코드레벨에서 부터 구동 가능한 프로세스를 구축하고 구성하는 쪽에 좀 더 포커스를 뒀었다. 아울러, 게임 서비스 중에 발생하는 여러 가지 백엔드 아키텍처 상의 문제(이를테면 성능, 분산, 스토리지 등)를 트러블슈팅해주기도 했다. 그때 내가 제작한 게임 서버 소스 패키지는 2019년에 론칭한 신작게임K에도 여전히 활용되고 있었다.
나의 커리어 상에서, 실무 엔지니어로서 가장 많은 성장을 한 것은 이 시기였다고 회고한다. 좋은 리더와 동료들과 일할 수 있었고, CTO의 챌린지는 혹독했다. 높은 목표와 좋은 지도자 그리고 훌륭한 선수들과 함께 뛸 수 있어서 행복한 시절이었다.
오랜만에 옛날에 적은 글들을 보다가 그 시절에 고민했던 글이 보여서 브런치로 옮겨 적는다. 아래 공유할 글은 '콘텐츠 또는 프로그램을 구동하기 위한 수단은 실행 가능한 상태로 제공되어야 한다'는 것에 대한 생각을 적었다. 이것 말고도 당시 얻은 인사이트에 대해 다루고 싶은 내용이 많지만 다음에 기회가 된다면 다루어 보고 싶다.
이하 2015년 2월에 작성한 글이다.
콘텐츠를 보기 위한 수단은 묶음으로 제공되어야 한다
빈트 서프 “디지털 데이터, 미래엔 못 읽을 수도라는 인터넷 기사를 보았다.
"디지털 양피지"에 관련된 내용인데 핵심 아이디어는 아래와 같다.
“콘텐츠와 그와 함께 작동하는 애플리케이션, 운영체제 구조를 한 번에 읽을 수 있는 스냅숏 데이터를 만들어야 한다”
특히 개발을 하다가 이런 생각을 하게 만드는 경험을 많이 하게 되었는데, 업무 특성상 게임 스튜디오들에 게임 서버 소스를 전달하거나 관련 기술 가이드를 해 줄 일들이 많이 있었다.
처음에는 정말 소스만 전달했다. 그렇게 하는 것이 당연하다고 생각했고 사실 그렇게 까지 밖에 생각할 수 없었던 게 더 컸던 것 같다. 그리하다가, 언젠가 게임 스튜디오의 게임 서버 소스를 검토할 일이 있었는데 내가 전달해 줬던 방식과 마찬가지로 소스만 전달받았다. 대부분의 개발자들은 잘 알겠지만, 소스만 가지고 동작하는 서버 소스는 사실 거의 없다고 봐도 무방하다. 그 이유는 다른 외부 시스템과의 연동 때문이다. Storage도 필요하고 외부 시스템과의 API 연동도 필요하기 때문에 대부분 없는 시스템과의 연결 시도를 하다가 애플리케이션이 죽어버리거나 심지어 구동되지 않는 경우도 많이 있었다.
이런저런 불편함을 겪던 중에 스튜디오 전달용 서버 소스에 Embedded database 중 하나인 h2를 추가해두었다. 기존에 Database가 다른 머신에서 돌아가고 있어야만 서버 소스 구동이 가능했는데, 그렇지 않아도 서버 애플리케이션 자체적으로만 동작하도록 소스 구조를 변경했던 것이다. 당연히 기존에 DB를 사용할 때와 똑같은 인터페이스로 구동되도록 했고 DDL과 약간의 DML 들만 앱이 구동하는 시점에 자동으로 생성되도록 하였다.
그 뒤로, 다시 서버 소스를 전달할 일이 있었는데 만족도는 예전과 확실히 달랐다. 일단 즉시 구동이 가능한 Executable과 Source과 제공이 되니 그쪽에서도 테스트 및 클라이언트의 연동을 하는 시간이 확실히 단축되었던 것이다.
내 입장에서는 그렇게 복잡한 일도 아니고 공수가 많이 들어가는 일도 아니었지만 실제로 소스를 받아보는 사람 입장에서는 분석하고 추측하는 시간을 대폭 줄여줄 수 있었다.
위의 사례는 내가 처음으로 경험을 통해 알게 된 계기였고, 사실 더 많은 곳에 이 아이디어를 적용할 수 있다. 가령 실시간으로 Scale-out이 되어야 하는 클라우드 서비스라던지 복잡한 구성과 환경설정을 통째로 스냅숏으로 만들면 반복되는 작업을 줄일 수 있는 것은 누구나 쉽게 생각할 수 있는 실 사례 중에 하나이다.
요즘에는 모바일 게임 쪽에도 좀 더 이 아이디어를 적극 도입하고자 한다. 모바일 게임은 특성상 격리된 수평 또는 수직의 존이 다수 필요하다. 스토어 검수, 현지QA 등 서로 다른 존과 격리된 환경에서의 테스트 및 검수 또는 서비스들이 많이 필요하게 된 것이다. 모바일 게임을 서비스하기 위해 필요한 백엔드 시스템은 상당히 많다. 인증, 빌링, 소셜, 게임 서버, 랭킹 등등 이 모든 것들을 바로 뽑아낼 수 있는 Portable & stateful snapshot이라고 생각해보자. 그렇다면 각기 다른 곳에서 애플리케이션을 이용하는 사용자들에게 격리된 경험을 확실하게 제공할 수 있게 될 것이다.
