▲ 넥슨 아메리카 김영현 개발자

개발사와 퍼블리셔. 개발사는 말 그대로 개발을 하는 회사이고, 퍼블리셔는 개발한 게임을 서비스하는 곳이죠. 서로 떼려야 뗄 수 없는 관계이지만, 서로 친해지기는 어려운 관계입니다.

퍼블리셔는 아무래도 게임으로 돈을 버는 데 필요하다고 생각되는 부분을 개발사에 개발 요청을 하는 경우가 빈번히 발생하게 됩니다. 그러면 개발사는 게임 서비스를 위해 그 요구를 어느 정도 들어줘야 하고, 이 과정에서 자주 충돌이 일어나게 됩니다.

21일 판교에서 열린 NDC 2015에서 '개발사'와 '퍼블리셔'의 관계를 다룬 ‘개발사는 모르는 퍼블리셔의 뒷이야기 : 프로그래머의 시선으로 바라본다.’라는 주제로 강연이 열렸습니다.

강연을 맡게 된 넥슨 아메리카 김영현 개발자는 "재밌고 즐거운 게임을 만들어보자는 의미로 준비하게 됐습니다. 항상 발생하는 개발사와 퍼블리셔 사이의 오해를 서로의 관점에서 이해했으면 합니다."라며 "게임 서비스를 위해서 필요한 개발요소들, 개발사에서 이해하기 어려운 퍼블리셔의 요구사항들을 엔지니어 입장에서 바라보고 풀어나가는 방식으로 강연을 진행하려고 합니다"라고 말하며 강연을 시작했습니다.


■ 왜 게임은 재미있는데 서비스가 엉망일까?




게임에서 소리 없이 사용자 및 매출이 감소하는 현상이 벌어집니다. 왜 이런 일이 벌어지는지 원인분석에 나서지만 난항을 겪게 되죠. 결국 서비스를 종료하게 됩니다. 유저들은 '게임은 재밌는데 서비스가 엉망이다.' '사후관리가 엉망이다.' 이런 얘기가 나오게 됩니다.

왜 이런 일이 벌어질까요? 게임이 정말 재미가 없을 수도 있지만, 이걸 두 가지로 바라보면 첫 번째로 비즈니스, 즉, '돈' 때문입니다. 그리고 두 번째로는 처음에 개발자들이 만든 기반이 무너져 내리면서 서비스 질이 안 좋아지는 이유가 있습니다.

첫 번째로 돈에 관해서 이야기를 해보면 연 매출액 120억 원인 게임이 평균 2주에 한 번 업데이트를 한다고 가정했을 때, 1년에 130시간의 점검을 하게 됩니다. 그럼 점검으로 인해 연 1억 7천 8백만 원의 손실을 보게 되는 거죠. 이것은 연봉 5천만 원 개발자 3명의 급여와 팀의 회식 비용을 합한 금액이 점검으로 인해서 소진됩니다.



두번째 상황을 보면 서비스를 위한 개발 요청을 퍼블리셔에서 개발사 측에 하게 됩니다. 그러면 콘텐츠를 만드는 개발사라고 하더라도 게임의 서비스적인 기반이 부족하면 안 되니까 요청받은 서비스 부분부터 개발하게 됩니다. 이런 현상이 반복되면 콘텐츠 개발은 지연이 되고, 완성도, 생산성도 떨어지게 되죠.

그러면 퍼블리셔는 매출을 올리기 위해 자극적인 업데이트를 준비합니다. 밸런스를 조금 붕괴시키더라도 좋은 아이템을 만들어 넣어달라고 하고, 결과적으로 매출을 끌어 올릴 수 있게 됩니다. 개발사는 추가되는 업데이트 때문에 스트레스를 받게 되고, 이 스트레스는 고스란히 유저들에게 전가되는 현상이 발생합니다.

또, 유저들이 스트레스를 받게 되면 매출과 동시접속률은 떨어지게 되죠. 그러면 퍼블리셔가 스트레스를 받고, 다시 자극적인 업데이트를 진행하는 악순환이 반복되면 게임이 망하게 됩니다.


■ 게임에 접속하는 유저의 흐름을 따라가보자.


1. 가입&다운로드




퍼블리셔에서는 주로 하는 일은 유저 가입을 유치하고 플레이를 많이 할 수 있게끔 해서 선순환을 만드는 역할을합니다. 하지만 현실은 가입 - 인스톨 - 로그인 - 플레이. 각 과정마다 유저가 빠져나게 됩니다. 이것을 잔존율이라고 하는데요. 이런 흐름을 쭉 따라가 보면서 퍼블리셔에서 어떤 이야기를 하는지 한번 얘기를 해보겠습니다.

2. 인스톨



파일을 유저에게 전달하는 것은 택배 방식이랑 비슷합니다. 택배 물건이 손상되거나 배달이 늦으면 화가 나고, 유저는 이 물건을 그 업체에 다시 주문할지 고민을 하게 되겠죠. 전달되는 과정 자체가 간결하게 되어야만 유저들이 편하게 생각합니다.

파일 수가 너무 많으면 설치가 느려집니다. 느려지면 설치 과정 중에 유저들이 많이 포기하게 됩니다. 또한, 패치 중에 문제가 발생할 수도 있고요. 파일이 많으면 설치에 한 시간이 넘게 걸릴 수도 있습니다. 열심히 마케팅으로 비용을 투자해서 유저를 끌어모았는데 설치에서 유저가 나가버리면 안타깝겠죠. 그래서 많은 개발사가 압축 라이브러리를 사용합니다. 압축하면 파일의 수가 줄어드니까요.

3. 패치



패치는 유저의 편의를 위해 진행하는 것도 있지만, 관리상의 용이성을 위해 하는 패치 시스템도 있습니다. 이 경우 개발사에서도 사용하지만, 퍼블리셔에서도 자체적으로 패치 시스템을 만드는 경우가 있죠.

패치를 하는 방법에서 두 가지 비교를 해보죠. 첫 번째로 버전을 비교하는 것인데 이 경우 버전이 오래되었을 경우 전체 버전을 재설치하는 문제점이 발생할 수 있습니다. 파일이 손상되었을 경우에도 재설치를 진행해야 할 때도 있고요. 그리고 패치 클라이언트 새 버전을 만드는데도 많은 시간이 소요됩니다.

그래서 두 번째 방법을 사용하는데, 버전 검사와 파일검사를 같이 진행하는 겁니다. 파일 리스트를 만들어서 버전과 파일 리스트를 같이 확인해서 다른 파일만 패치를 진행하는 거죠. 이 경우 파일 손상이 있더라도 해당 파일만 복구할 수 있고, 오래된 버전도 다른 파일만 패치할 수 있습니다. 패치 클라이언트의 제작 시간도 축소되고요.

4. 게임 로그인




이건 마케팅 입장에서 이야기를 해보면 맨 처음에 광고를 해서 유저를 유치한다고 했는데요. 그러면 어떤 광고를 어떻게 해야 할지 전략을 세우게 됩니다. 그리고 가입을 한 유저의 모든 트래킹을 조사를 합니다.

광고를 보고 유저가 가입을 했다. 로그인하고 플레이를 했다. 그런데 가입하고 로그인을 하는 중간 부분이 연결이 안 되는 거에요. 그래서 끊어진 부분을 이으려고 시도를 했습니다.

제가 했던 방법이 아까 보여드렸던 두 과정을 다 뽑아서 DB에 복원을 한 다음에 비교를 해봤는데요. 수동으로 비교하니까 데이터가 맞지 않는 경우가 상당수 있었고, 시간도 오래 걸렸습니다.

그래서 퍼블리셔한테 그 유저가 특정 광고를 보고 들어왔다면 조사할 수 있게 계정 DB 안에 한필드만 넣어달라고 요청했습니다. 근데 구조를 변경해야 해서 어렵다고 하더라고요. 6개의 회사에 요청했는데, 1개 회사만 해줬습니다.

이런 경우 개발사의 이해가 좀 더 있었다면 좋겠다는 것이 사실 '추가해 주세요'가 아니라 '이런 부분이 필요하다'고 얘기를 하면 개발하는 입장에서 더 좋은 방법을 조언을 해줄 수 있고, 좀 더 좋은 방향으로 발전할 수 있는 시스템이 나오지 않을까 생각을 했습니다.

5. 게임서버 접속



유저가 게임 접속을 했는데 문제가 발생했습니다. 그래서 서버가 다운되고, 서버는 운영 담당에게 메시지를 보냅니다. 메일을 본 담당자는 자고 있던 개발자에게 연락해서 일단 서버를 살리죠. 근데 개발자가 서버를 살리고 문제를 살피는 데 별다른 문제가 없었어요. 그럼 새벽 2시에 일어난 담당 개발자는 다음날 졸게 됩니다.

그래서 이러한 인력 낭비를 없애기 위해 스스로 재시작을 하는 서버가 필요했습니다. 예를 들어 서버에서 120MB를 보통 사용한다고 할 때, 재시작 조건을 200MB로 설정합니다. 그래서 200MB 이상 넘어가게 되면 더는 할당을 받지 않고, 자동으로 재시작하는 구조로 만들어서 지속해서 서비스할 수 있는 거죠.

6. 크래시 발생



크래시는 어디서 발생하는지 알아야 하고, 얼마나 발생하는지 알아야 합니다. '어디서' 발생하는지는 해결을 하는 데 필요하고, '얼마나' 발생하는지는 심각하면서 많이 나는 것부터 우선순위로 해결하기 위해서입니다.

해결을 위해서는 유저의 모든 이동을 인덱스로 서버에 기록하면 크래시가 '어디서', '얼마나' 나는지 알 수 있습니다. 그다음엔 크래시가 어디서 나는지 코드를 수집해야 하죠.

코드 수집의 경우 크래시가 나면 수집 서버에 정보를 전송하는 방식을 택했습니다. 그런데 디스크 에러가 나거나 유저가 그냥 작업관리자에 가서 끄는 방식 때문에 약 50% 정도의 수집률을 보였습니다.

조금 더 정확한 정보가 필요해서 개선한 정보 수집 방식은 크래시가 나서 접속이 끊긴 유저는 바로 접지 않고 다시 로그인하는 것에 착안했습니다. 로그인을 할 때 크래시 정보가 있으면 전송 후, 삭제하는 방식을 사용했더니 90% 수집률을 보였습니다.

7. 이벤트



마지막으로 오류가 나도 플레이해주는 유저들에게 고마움의 표시로 이벤트를 하게 됩니다. 그러면 아이템 지급 이벤트를 한다고 할 때 인벤토리에 바로 넣으려면 점검이 필요한데요. 그래서 대안으로 우편함에 아이템을 넣어주는 방식으로 진행합니다.

그런데 지속시간이 3일짜리면서도 14일 안에 소진이 필요한 아이템을 지급해준다고 할 때, 인벤토리에 넣어주면 지급 3일 이후에 접속해서 사용을 못 하는 유저가 발생하고, 우편함에 넣어준다고 할 때는 늦게 가져가는 유저 때문에 14일 안에 소진할 수 없습니다.

이때 추천하는 것은 로그인을 했을 때 받아갈 수 있게 지급 테이블에 넣어서 유저가 로그인 시 선택할 수 있도록 하면 점검 없이 지급이 가능하고, 대규모 지급에도 서비스 영향이 적어집니다.