imays님의 이글루

1997. 12월 출시 : 판타랏사, 소프트맥스
1998. 03월 출시 : 서풍의 광시곡, 소프트맥스
1998. 10월 출시 : 드로이안 넥스트, KRG소프트
2000. 01월 출시 : 드로이얀 2, KRG소프트
2001. 06월 출시 : 열혈강호, KRG소프트
2005. 02월 OBT : 블리츠 1941, 모웰소프트

2006년 4월을 기준으로 블리츠는 상업적으로 실패한 게임이다. 실패의 기준이 무엇이냐고 묻는다면 많은 기준이 나올 수 있겠지만 지난 3년간 블리츠의 제작 총괄 및 게임 디자인을 맡았던 프로듀서로서 내가 할 수 있는 대답은 간단하게 ‘low CCU’라고 이야기할 수 있다. 한게임 퍼블리셔 담당자들은 블리츠의 ARPU가 매우 높아 고무적이라고 애써 위로해 주지만 결국 동접자가 낮으면 캐쉬풀도 적어지기 때문에 아무런 의미가 없다. (현재는 블리츠 라이브팀으로 업무가 인수되어 많은 부분에 있어 과감한 수정 작업을 진행 중이며 이는 충분한 가능성의 여지를 가지고 있다.)

2005년도 내부 매체 집행 실적 분석에 따르면 광고 배너를 클릭해서 블리츠 홈페이지에 접한 방문자중 73%가 다운로드도 하지 않은채 그대로 빠져 나갔다고 한다. 어째서 이 많은 사람들이 게임을 해보지도 않고 이탈하게 되었을까? (한게임 요청에 의해 상세 자료는 표기하지 않도록 수정되었습니다.) 

여기에는 여러 가지 이유가 있었을 것이다. 우선 정통 밀리터리 분위기가 가득한 블리츠 홈페이지에서 우리의 게임이 평소 자기들이 골치 아파하는 밀리터리 장르일 것이라고 판단하여 흥미를 잃었을 수도 있었을 것이며, 혹은 꽤나 인내심을 요구하게 되는 설치 파일 다운로드 속도로 인해 중간에 포기할 수도 있었을 것이다. (인터넷 회선의 상태마다 다소 차이가 있었지만 약간 시설이 낙후된 PC 방 같은 곳에서는 길게는 40-50분을 기다려야 하는 경우도 있었다.) 어쨌거나 방문자 중에 73%는 블리츠라는 생소하게 생긴 이 게임을 다운받지도 않았고, 설치하지도 않았으며, 플레이를 해보지도 않았다는 것이다. 더욱이 초반기에 우리는 우리의 서버 성능에 대해 보다 주밀한 스트레스 테스트가 있었어야 함에도 불구하고 5시간 정도의 스트레스 테스트 결과를 믿고 오픈 베타를 강행하여 서비스 론칭 후 거의 한 달이 지나도록 DB 쪽에 LOCK 현상이 발생하는 서버 락다운에 대해 효과적인 대처를 하지 못했다.

[imays] 다운로드 지연의 원인이 마치 덩치가 너무 큰 클라이언트 크기라고 오인할 여지가 있다. 실제로 블리츠를 다운로드받아보시라. 몇백메가 정도의 크기이다. 기가급을 치는 요새 게임의 크기와 비교했을 때 작은 크기다. 더욱이 초반기에... DB LOCK 어쩌구라는 어투에서, 다운로드 지연의 문제가 마치 서버프로그래머의 잘못처럼 지적되고 있다. 이것은 파일 서비스를 제공하는 업체측 문제이지, 서버프로그래머의 잘못이 아니다.블리츠의 서버 프로그램을 개발한 사람으로서 이는 잘못된 표현임을 지적하지 않을 수 없다. 더욱이 초반기에... 라는 어투를 갖고 말꼬리를 설령 잡지 않는다 하더라도, 블리츠가 상업적으로 실패한 이유에 대해 '우선 어쩌구... 혹은...'으로 기재, 상업적 실패의 이유를 밀리터리 장르이거나 프로그램의 불안정인 것처럼 적으면서도 은근히 밀리터리 장르에 관한 내용은 한마디로 끝나면서 프로그램 불안정에 대해서는 몇 문단에 걸쳐서 까대고 있다. 독자를 충분히 오해시킬만 하다.

결국 OBT 시범 서비스가 시작되고 클로즈 베타 테스트 때하고는 비교가 안 되는 수십 배에 가까운 트래픽이 발생하고 있었다. 우리는 폭주하는 트래픽을 조심스레 모니터링하며 동접 1000명, 동접 1000명에서 2000명, 2000명에서 3000명이 넘어서는 과정을 오후 4시 프라임 타임때 접하게 되었고 오후 8시부터 시작되는 저녁 프라임 타임 때 서버에서 더 이상 접속할 수 없도록 강제 제한해놓은 포화 상태가 찍힌 것을 보고 그 때까지 게임, DB, 인증 서버가 별 탈 없이 잘 돌아간다는 점에 자축하며 환호성을 질렀다. 하지만 우리는 그로부터 불과 몇 시간 뒤 찾아오게 될 끔찍한 시간에 대해서는 예측하지 못했다.

문제는 싱글 플레이 혹은 협력 플레이가 가능한 작전실이었다. 당시 우리의 유동 세션은 작전실에 생성된 방 하나 하나의 안정성에 깊이 관여를 하고 있었다. 이처럼 독립적이지 않은 구조를 가지기 때문에 하나의 유동 세션이 파괴될 경우 연쇄적으로 DB 및 게임 서버에 무리를 주게 되어 연쇄적으로 다른 게임 세션까지 다운되는 경우가 발생하게 되었다. (유동세션의 논리적 결함을 뒤늦게 발견하게 되었고 이에 따른 유동세션의 독립적인 운영이 가능한 모듈화 작업을 몇 달이 지나서야 할 수 있었다.)

[imays] 물론 저 내용이 틀린 말은 아니다. imays는 그당시 매우 고통스러운 경험을 하였으니까. 하지만 블리츠가 상업적으로 실패한 주된 요인처럼 yadd가 말을 이끌어가는 것은 확실한 비약이다. 블리츠는 초기 개발시 PW MMO에 맞춰진 서버 구조로 개발된 상태이었다. 그러나 기획에서 유동 세션 작전실이 중도 요구되었는데, 이를 구조가 다 잡혀진 프로그램에 억지로 넣지 말았어야 했다.

어쩔 수 없이 우리는 작전실을 임시적으로 차단한 채 게임서버를 다시 가동했으며 당분간 게임 서버에는 큰 무리가 없어 보이는 듯 했다. 하지만 문제는 이윽고 다른 곳에서 또 발생하게 되었다. 전투 스킬 사용의 과중한 자원 사용과 일부 코드들의 불안정성이 동접 최대치에 가까워지며 잦은 버그를 발생시켜 그야말로 최악의 상황으로 치닫고 있었던 것이다.

우리는 우선 이 문제를 사용자의 분산을 유도하여 일단은 모면하려 하였다. 다음날 사전에 준비된 장비들을 이용해 서버 확장을 하였으며 이러한 노력에도 불구하고 추가된 서버를 사용자가 선택할 수 없는 등의 이런 저런 문제들로 인해 만족할 만한 해결을 거두지 못했다. 블리츠의 네트워크 코어는 다이렉트 플레이 기반이다. 많은 사람들이 다이렉트 플레이 기반의 MMO 게임이 검증되지 않았다는 이유로 사용을 꺼리고 있었으며 그러한 사람들의 우려는 서비스 초반 우리들이 겪은 어려움들을 고려해본다면 100% 현실이 되어버렸다. 실제 directx 문제로 인해 많은 사용자들이 오픈베타 초기에는 로그인조차 하지 못하는 경우가 많았다.

이러한 연쇄적인 서비스의 불안정은 결국 우리 의도와는 달리 demarketing이라는 최악의 상황으로 이어졌으며 서비스의 불안정은 우리나 퍼블리셔인 한게임측의 예상보다 길어지게 되어 결국 몇 개월이 지나서야 안정적인 형태로 돌아서게 되었다. 클라이언트 역시 우리가 예상한 것보다 상당히 무거워서 대부분의 PC에서는 굳이 100대 100의 상황이 안되고 50대 50대 정도의 전차들이 전투를 하게 되도 화면조작 조차 힘들 정도로 느려졌다. 대표적인 오버클럭 정보 사이트인 파코즈에선 오버클럭후 돌려보는 벤치마킹 프로그램으로 우리 블리츠 1941을 띄워볼 정도이니 그야말로 웃을래야 웃을 수 없는 심각한 상황이었던 것이다. (클라이언트의 무거움 역시 우리는 수개월이 지난 후에야 저사양 패치를 통해 어느 정도 해소시킬 수 있었다.)

[imays] demarketing 납셨다! 즉 프로그램 불안정은 블리츠를 시장에서 망하게 한 주범이 되었다는 토를 단 셈이다! imays는 블리츠 이전 프로젝트에서 자체 MMO 네트웍 엔진을 만들어 썼고, 안정성도 이미 검증되었다. (동접자는 블리츠보다 예전 프로젝트가 더 높으니까.) 본인이 만든 엔진이라 해도 소유권은 전 회사에 있기 때문에 그걸 가져다 쓸 수는 없었다. imays는 추후 DirectPlay를 대체할 네트웍 엔진을 개발할 계획은 갖고 있었지만 계속 일정이 빡빡하게 진행되는 상황에서 DirectPlay를 MMO 스트레스 테스트로 가용성을 검증한 후 선택한 것은 불가피한 상황이었다. imays가 실수한 것은 DirectPlay를 MMO 스트레스 테스트까지는 검증했지만 더미 클라이언트가 아니라 실제 유저들이 붙어서 플레이되는 상용화된 MMO 게임에 적용된 사례까지 검토하지 못한 점이었고, 이와 관련해서 여러가지 문제점이 발생했었다. 불행하게도 그 시점 즈음에 DirectPlay는 Microsoft에서 퇴역을 시키기로 선언됐고 DirectPlay의 소스코드도 당연히 없는지라 문제를 해결할 방법도 없었다. (심지어 imays는 이 문제 때문에 Microsoft에 DirectPlay의 소스 코드 라이센싱 또는 공개를 요청한 적도 있다.) imays는 이 사건 이후로 DirectPlay건 뭐건 문제 해결이 신속하게 해결할 방도가 없는 엔진이면 안쓰겠다는 원칙을 가지게 되었다. 각설하고, 블리츠 서버 불안정의 가장 주된 원인은 DB LOCK 문제였다.

사실 블리츠는 개발 초기부터 무척이나 애를 먹였던 게임이었다. 오픈베타 당시의 블리츠  프로그래머는 5명이었다. 하지만 그 이전에 3명의 프로그래머가 중도에 이탈하게 되었던 쓰디쓴 과거를 가지고 있었다. 개발 초기의 프로그래머는 단 둘이었다. 2002년도 봄 당시 내 개인적인 선택은 우리 팀이 빠르고 효과적으로 개발할 수 있는 2D로 개발할 것을 원하였으나 당시 3D 게임이 아니면 투자나 퍼블리셔를 구하기도 힘든 상황이었고 개발팀 내부에서도 3D 게임 개발에 대한 높은 의욕을 가지고 있었기에 어쩔 수 없이 3D로 개발하기로 결정하게 되었다. 개발은 몇 달의 R&D 기간을 거쳐 프로토타입을 향해 순조로운 진행을 하는 듯 했지만 프로그래머들간의 의견 충돌 및 대립으로 (서로 호형호제하던 좋은 사이였음에도) 결국 한 명이 회사를 그만두는 사태까지 가게 되었고, 중간에 들어온 프로그래머도 결국 퇴사하여 프로그래머는 한 명으로 줄어들게 되었다.

[imays] imays를 포함하여 7명이 회사를 공동 설립할 당시 어느 누구도 직위를 두지 않았다. yadd 또한 '기획자'였고 imays 또한 '프로그래머'였다. 이때도 마찬가지였다.

나가게 된 프로그래머들의 빈자리를 메우고자 다른 프로그래머들을 구하게 되었고 우리는 3명의 프로그래머를 다시 채용하게 되었다.

문제는 여기서 그치지 않았다. 새로 들어온 프로그래머 중 한 명이 의욕에 넘쳐서 원래 메인을 잡고 있던 프로그래머의 기술적 방식에 의문을 품고 반기를 들게 되었고 우여곡절 끝에 결국 초기 리드프로그래머에게 클라이언트 메인 자리를 양보 받게되었고 팀 내부적으로 워크샵을 떠나서 업무분장을 하는 등 의욕적인 재출발이 가능한 듯 보였다.

[imays] imays는 한번도 리드프로그래머라는 직함을 들은 적이 없다. imays의 기술적 방식에 의문을 품은게 아니라 imays가 초기 설계가 너무 오래 걸리다보니 문제의 프로그래머가 나선 것이다. 물론 imays가 초기 설계가 너무 오래 걸린것 자체도 잘한 짓이 아님은 잘 안다. 하지만 어 다르고 아 다르다고, 말은 똑바로 하자. 우여곡절이라고 거론됐기에 좀 얘기좀 끌어보고자 한다. 어느날 문제의 프로그래머들이 imays를 제외한 임원들과 회사 근처 카페에 모인채로 imays를 불렀다. 가봤더니 imays에게 그는 클라이언트 설계를 자기에게 맡겨달라고 말했다. 황당한건, 그래픽 담당 임원은 'DirectPlay를 쓰는게 문제다'라는, 클라이언트 메인이 할 수 없는 말을 듣고 내게 한 것이다. 그 문제의 프로그래머는 게임 개발 경력이 없는 신입이었다. (imays는 그 당시 이미 7년차였다) 모든 임원들은 imays를 불신임하는 분위기였다. 신입 프로그래머보다 더 무시당하는 입장인 셈이었다. 결국 그의 손을 들어준 후 imays는 분위기 절망을 느끼고 퇴사를 신청했고, 그당시 imays는 임원들로부터 업무 실책에 관련한 소송 및 게임업계에서 매장해버리겠다는 협박까지 받은 마당이었다. 한편 그 문제의 프로그래머는 imays가 사표낸날 '서버프로그래머 모집. 담당 자기'라는 공채를 싱글벙글 올렸다고 한다. imays가 그런 수모를 당하면서도 그냥 블리츠를 계속 만든건 그동안 해온 열정과 성공에 대한 의지 때문이었지, 절대 나머지 사람들이 이뻐서는 아니었다. 그 프로그래머의 월권 행위는 여기서 끝난게 아니다. 이사 불신임 합의각서를 서명하는 조건하에 사표를 취소한 후 다시 들어온 후, 그 문제의 프로그래머는 imays가 소집한 프로그램팀 업무 회의도 일방 거부하는 등 시끄러운 일이 몇차례 있었다. 아무튼... 그 프로그래머의 월권 행사 이후 타 임원들은 이 상황을 더 이상 둘 수 없다고 판단, 각 임원들에게 직함을 붙이기로 했다. yadd는 기획팀장, imays는 프로그램팀장직을 달았다.

하지만 두어 달이 지나자 새로이 클라이언트 메인 자리에 있는 프로그래머에 문제가 생겼다. 회사에 와서 아무 일도 하지 않고 하루 온종일 책상에 누워있다가 퇴근을 하는 것이었다. 처음에는 감기 몸살과 같은 가벼운 병인 줄 알고 휴가도 주어서 회복되길 바랬지만 며칠 뒤에도 상황은 달라진 게 없었다. 무슨 영문인지 걱정이 된 나는 그와 함께한 자리에서 충격적인 이야기를 듣게 되었다. 자신이 빙의가 잘되는 영매체질이라는 것이었다. 이전 직장에서도 이런 문제로 회사를 그만 두게 되었다고 고백했다. 본인도 쉬고 싶다고 해서 우리는 그렇게 하는 것이 서로에게 좋을 것이라고 판단했다.

결국 우리는 서버 프로그램 출신의 팀장을 클라이언트 및 서버 총괄 팀장으로 내정하고 각고의 리팩토링 작업에 들어가야만 했다. 프로그램에서 가장 중요한 기본적인 구조가 3번이나 바뀌는 심각한 상황 중에서도 우리의 팀원들은 동요하지 않고 자신의 맡은 일들을 충실히 해내주었다.

[imays] 앞서 언급했듯이 팀장이란 직함은 모웰소프트 내에서 각 임원간의 합의하에 의해 한순간에 그래픽 팀장,프로그램 팀장,기획 팀장이 만들어진거다. '우리가 imays를 내정했다'라는 표현은 잘못된 것이다. 토좀 달자면, '리팩토링'이라는 표현은 잘못됐다. 리팩토링은 결과물을 거의 그대로 유지하는 것을 전제로 하니까. 그 문제의 프로그래머는 자기가 클라이언트 메인을 쥐고 나서 imays가 만들었던 클라이언트 소스를 완전히 날려버렸다. 심지어 폴더 구조까지 다 바꿔놨다. (근데 왜 빌드 시간은 몇배 더 걸리냠...) imays는 남이 만든 소스라도 가급적 다 쓰는 습관을 갖고 있다. 우습게도, 그걸 만든 사람에 대한 예우라는 생각까지 하기 때문이다. 지금 블리츠에서 그 문제의 프로그래머가 만든 부분은 0.1% 정도밖에 안남았을 것이다. 그 문제의 프로그래머가 설계를 하겠다고는 했지만 정작 그 설계는 알맹이가 없었으니까. 사실상 별 설계가 없는 마당에서 리팩토링이라고 할 것도 없이, 처음부터 만드는 셈이나 다름없었다.

이러한 중에 우리는 첫번째 퍼블리셔 대상인 넷마블과의 미팅에서 우리가 만든 알파 버전이 여러모로 문제가 있다는 것을 깨닫게 되었고 비쥬얼적인 부분의 디폼과 조작의 편의성을 높이기 위한 재수정 작업에 착수하게 된다. 사실 개발팀 내부에서는 실제로 블리츠의 개발 기간은 18개월 만에 만들어진 게임이라고 이야기하는 이유가 이 때 리팩토링 작업과 연계된 모든 구조 변경 작업 및 디자인 변경 작업량이 상당했기 때문이다. (어쨌든 블리츠의 개발 착수부터 오픈 베타까지 소요된 개발 기간은 34개월에 달한다.)

[imays] 다시 한번 언급하지만, 리팩토링이라고 할것도 없다. 그 문제의 프로그래머가 만든 것은 DX SDK 데모 수준에 불과했으니까. 무리도 아니다. 그 프로그래머는 왜 풀스크린에서 60FPS를 못 넘는지를 모를 정도였다. 어쨌거나 그 프로그래머가 퇴사한 이후 99.9%를 프로그램팀이 다시 만든거라고 보면 된다.

이런 혼란을 겪으면서도 다행히도 개발팀은 집중력을 잃지 않았다. 특히 리팩토링을 결정한 프로그램팀은 근 1년간 야근을 계속하게 되었을 지경이었다. 장기적인 크런치 모드가 가진 단점을 너무나 잘 알고 있었고 또 그런 불합리한 개발 관리는 지양해야 하는 것이 프로듀서로서의 제 1 사명이라는 것을 너무나 잘 알지만 당시 우리의 사정으로서는 달리 방법이 없었다. (이 자리를 빌어 1년이 넘도록 리팩토링 작업에 집중해준 6명의 프로그램팀 모두에게 진심으로 감사의 말을 전한다.)

[imays] 다시 언급하지만 리팩토링은 그 문제의 프로그래머 퇴사 이후 한달도 안돼 다 끝났다. 나머지 기간은 신규 개발이었다. 모웰소프트의 재정 상황을 감안했을때 당시 경력자 클라이언트 프로그래머를 채용하는 것은 불가능했다. 게다가 당시 imays는 Direct3D 기반 클라이언트 프로그램을 개발해서 출시해본 경험이 없었다. 결국 신입 여럿을 뽑아서 억척같이 진행하는 수밖에 없었다. 집에서는 Direct3D를 공부하느라 놀지도 못했다. 6명이 모두 모여 야근을 밥먹듯이 했다. 치지도 못하는 당구도 같이 치면서 분위기 도모해주고, 못 마시는 술 무댓뽀로 마시면서 피로를 풀어주기도 했다. 1년간의 블리츠 프로그램 개발중 imays가 신경쓴 쪽의 80%는 클라이언트쪽 개발이었던 것 같다. 
그 모든 난관을 겪으면서 결국 블리츠는 자의반, 타의반 2월 22일 오픈베타테스트에 돌입하게 된다. 더 이상은 시간을 끌 수 없다는 자금적인 압박도 있었고 한게임 퍼블리싱 팀 내부의 론칭 자원 예약 문제도 있었기 때문에 연기를 더 할 수는 없었기 때문이다. 사실 오픈 베타 이후 며칠 동안은 한게임 관계자 모두 회색이 만연했었다. 별 기대를 하지 않은 게임이 뚜껑을 열어보니 실적이 상당하더라는 것이었다. 예상치보다 높은 일일방문자수와 오후시간 내내 서버는 포화상태였으니 (당시 아크로드 지원이 우선이어서 블리츠 서버 확장 준비에 차질이 생겼고 동접이 폭주한 첫째 날 계획대로 서버를 추가하지 못했다.) 서버만 확장해가면서 광고만 조금씩 더 터트려주면 한게임 외부 퍼블리싱 게임 중 최고 동접 기록이 나오겠다는 기대가 모락모락 피어 오르고 있었다.

서버를 추가하고 기대를 했지만 하루 하루 지날수록 동접은 우리가 생각하는 만큼 올라가주지 못했다. 이미 전 절에 이야기한 서비스의 불안정도 분명한 이유였겠지만 블리츠가 가진 게임플레이적인 단점들이 드러나게 된 것이다.

[imays] 이미 신나게 imays를 까댄 마당이니, 이제부터 진짜 상업적 실패 이유를 들이밀어도 된다고 생각했나보다.
지금부터 제시하는 블리츠가 가진 6가지 단점들은 오픈 베타 테스트가 시작된 시점에서 상당한 시간이 지나서야 사용자 DB 지표 등의 객관적인 자료를 통해 알게 되었던 것들이었다. 서비스의 안정화라는 기본적인 요소 이외에 블리츠의 상업적 실패에 있어서 가장 큰 영향을 준 것들이기 때문에 공유의 차원에서 게재한다. (개인적으로 이러한 정보에 대해 세미나 형태의 정보 교환이나 자료 공유가 있었으면 하는 바램이 있다. 마치 의사들이 자신들이 맡은 특수한 질병을 가진 환자를 치료하는 데 있어서의 소중한 경험을 학회나 논문이라는 형태로 공유하는 것처럼 말이다.)

1. 낮은 EPH에 따른 초반 대량 이탈

EPH는 exp. per hour의 줄임말로 시간당 획득 경험치라 할 수 있다. 이 지표는 실제 게임을 플레이 한 블리츠의 사용자들을 대상으로 전체 사용자들의 평균 1시간당 획득하는 경험치이다. 이러한 블리츠 사용자들의 평균 EPH는 상상을 초월할 정도의 낮은 수치가 나왔다. 이는 클로즈베타 테스트 사용자들의 평균 EPH의 5%도 되지 않는 수치였으며 실로 이러한 EPH를 얻는다고 했을 때 만렙인 20레벨까지는 고사하고, 게임의 재미를 붙여나가게 되는 7레벨까지도 꼬박 2주의 게임플레이타임이 필요했다. 우리는 이러한 심각한 낮은 경험치 획득 현상을 바로잡기 위해 2레벨-6레벨의 추가적인 경험치 보너스 곡선이 필요하다고 판단했으며 그에 따른 조치를 4차에 걸쳐 하게 되었다. 1차로 준 보너스 곡선이 사용자들의 평균 EPH를 20%가량 높여줄 것이라는 추정을 했지만 그 예측은 보기 좋게 빗나갔다. 실제 블리츠는 ‘적을 맞추어 적을 죽여야만 경험치를 획득한다’라는 게임 메커니즘을 가지고 있었으나 대다수의 플레이어들은 움직이는 적 전차를 맞추는 것 조차 버거워했기 때문이었다.

우리는 경험치 곡선을 건드리지 않고 구간별 탄력을 줄 수 있는 경험치 보너스 시스템을 넣어주었지만 실제 사용자들은 적 전차를 맞추어 파괴할 수가 없으니 지표상의 큰 변화가 없었던 것이었다. 오히려 조작에 익숙해지는 플레이어들과 그렇지 못한 대다수의 평범한 플레이어들과의 경험치 격차가 커질 수 밖에 없었기 때문에 이런 현상은 벌어지는 부익부 빈익빈 모양의 레벨 차이의 격차가 심해져서 또 다른 부작용이 발생하지 않을까 하는 우려도 있었다.

2차로 들어간 EPH 올려주기 계획은 프로그램팀장의 아이디어에서 시작되었다. 요는 적 전차를 맞추기 힘들다면 맞추기 쉽게 바꾸어주자는 것이었고 결국 마우스 우클릭을 자동으로 클릭해주는 것으로 하여 조작을 쉽게 해주는 caps lock 시스템이 들어가게 되었다. 이 패치는 상당히 효과가 있어서 EPH가 의도한 대로 증가하였지만 이 caps lock 시스템은 결국 나중에 또 다른 논란거리를 불러오게 되었다.

이 2번째 패치를 통해 평균 EPH는 다소 증가하였으나 계속 악화되고 있는 저레벨층의 이탈율에 그다지 영향을 주지는 못했다. 전체 사용자중 66% 에 해당하는 인원이 여전히 2-3레벨,7레벨에 이탈되고 있었다. 이는 해당 전장의 막내 레벨 때 전장에서 생존하는 법을 채 익히기도 전에 게임을 포기하는 형태가 되었기 때문이라고 판단한 우리는 각 전장의 막내레벨을 파티로 참여시켰을 때 추가적인 파티 보너스가 파티 전체에게 가게 함으로써 막내레벨들을 고레벨 플레이어들이 챙겨줄 수 있도록 하였고 또 파티의 최소레벨과 최고레벨의 차이가 클수록 더 많은 경험치 보너스가 해당 파티에게 주어지도록 준비하였다.

이 3번째 패치를 통해 전장의 막내 레벨대의 이탈율이 약 8% 가량 줄어들었다. 다소 고무적이긴 했으나 이 역시 낮은 EPH에 대한 직접적인 해결책은 아니었다. 우리는 마지막으로 자신의 전차가 파괴되어도 기본 경험치를 얻게 해주었고 어느 정도 적전차에게 데미지를 주고 파괴되었다면 추가적인 보너스 경험치를 얻게 해주는 패치를 준비하였다. 또한 하나의 전차가 파괴될 때 나누어주는 저레벨 구간 경험치의 배분량을 기존의 양에서 25-50% 이상 올려서 보다 낮은 레벨의 플레이어가 보다 쉽게 경험치를 얻을 수 있도록 수정하였다.

이러한 일련의 수정 작업을 통해 우리는 기존 사용자들의 EPH를 보다 효율적으로 관리할 수 있었으며 특정 구간대의 기형적으로 집중된 이탈율을 다른 레벨 구간 대의 일반적인 수준으로 통제할 수 있었다.

• 여기에서 우리가 배운 점
  시간당 경험치 획득량은 매우 중요하다. 보다 정확히 표현하자면 획득량 그 자체보다 [획득경험치/레벨업까지경험치]의 비율이 중요하다 할 것이다. 똑같은 누적 경험치 량을 가지고도 20레벨로 구간을 나누는 것과 100레벨로 구간을 나누는 것은 플레이어가 느끼는 체감으로는 결국 레벨업이 빠른가 혹은 더딘가로 받아들여진다. 레벨업이 느리다고 느껴진다면 유져는 서서히 질식하듯 게임에서 이탈하게 된다.

2. 비합의형 PVP 구조

비합의형 PvP 지지자들은 언제라도 다른 플레이어에 의해 공격 받을 수 있고, 이 공격에 대해 아무런 예측을 할 수 없는 점이 ‘갈등을 통한 드라마’를 만들어 낸다고 말한다. 또 부수적으로 호감을 가진 플레이어들끼리 공통의 적에 대응하기 위해 모이는 커뮤니티 생성효과를 가진다고 말한다. 이들은 지난 30년간 비합의형 PvP가 효과적이지 못했던 이유를 아무도 이 시스템을 제대로 구현하지 못했었기 때문이라고 말한다. 즉 이들이 말하는 내용은 ‘비합의형 PvP 시스템은 좋은 것’이라는 관점에서 출발한다.

반면 비합의형 PvP에 반대의견을 가지는 사람들도 존재한다. 이들은 역사적으로 비합의형 PvP가 제대로 돌아간 적은 한번 도 없는데다 오히려 많은 수의 플레이어들을 게임에서 멀어지게 한다고 말한다. 이들의 그것에 대한 예로 종종 울티마 온라인의 초창기를 거론하곤 한다. 즉 이들이 말하는 내용은 ‘비합의형 PvP 시스템은 나쁜 것’이라는 관점에서 출발한다.

온라인 게임 역사상 가장 공격적인 비합의형 PvP 게임에 속하는 쉐도우베인 개발팀은 실제 PW 게임 개발과 디자인의 경험이 없는 팀이라는 특징이 있다. 즉 이들은 수많은 플레이어들의 욕구나 비전이 아닌 개발팀 자신들만의 욕구와 비전을 보고 있는 것이다. 따라서 비합의형 PvP 를 선호하지 않는 플레이어에게는 ‘게임을 할 것인가 말 것인가’의 선택만 주어진다. 이들이 공개한 FAQ에는 다음과 같은 것이 있다. “한편으로 우리가 바라는 것 중의 하나는 월드 맵의 상당 부분이 사람이 살지 않는 곳(no man’s land)으로 되는 것입니다.”

글쎄 과연 어느 누가 위험을 무릅쓰면서 그 곳을 여행하고 싶을까? 우리가 만들어야 하는 게임은 영구적인 세상(PW)이지 영구적인 죽음(persistent death)이 아니다.

디자인과 개발에 관한 여러 쟁점들 중 – 제시카 멀리건

제시카가 지적했듯이 게임 초반에 물리적인 폭력을 거부할 수 없는 비합의적인 적대적 환경을 조성하는 것은 상당한 모험이라고 할 수 있다. 더군다나 쉬운 게임, 가벼운 게임을 표방하며 캐쥬얼 유져층을 노린 블리츠의 타깃을 감안한다면 비합의형 PvP 구조는 상당한 부작용들을 초래할 수 있었다. 블리츠의 유져는 처음 튜토리얼을 끝내고 곧바로 PW 전장에 투입된다. 그 곳에는 자신보다 레벨이 높고 훨씬 더 숙련된 적 플레이어들이 자신들의 먹이감을 찾고 있기 때문에 처음 접한 유져는 자신이 싫던 좋던 간에 도무지 정체를 알 수 없는 다수의 적들에게 포신을 겨누며 싸우도록 강요받는다.

대부분 방을 만들어서 자신과 대전할 대상을 자신이 선택하고 자신이 동의(혹은 합의)해야만 비로소 대전이 진행되는 합의형 PvP 와는 달리 블리츠의 신규 유져들에게 게임에 익숙해질 수 있을 만한 시간과 공간도 주지 않은 채 전형적인 비합의형 PvP 대전으로 유도하고 있었던 것이다. 당초 그런 이유로 인해 혼자 플레이가 가능한 작전실을 두어 연습과 익숙해질 수 있는 장치를 만들어 놓았던 것이었는데 서비스 초반에는 안정성에 문제가 있어서 작전실을 가동할 수 없었고 시간이 흐른 뒤에 작전실을 가동하였을 때에는 작전실에서 벌어들일 수 있는 경험치가 필드에서 벌어들일 수 있는 경험치보다 매우 적었었고, 또 작전실의 시나리오 콘텐츠가 단조로운 전멸전 하나 밖에 준비되지 않았기 때문에 대부분의 사용자들이 작전실 사용을 외면하게 되었다.

나중에 이르러 우리는 초보자들인 1-2 레벨들만을 위한 연습장을 상설 전장으로 두어 이 곳에서 전차 조작 연습과 게임에 대한 기초 이해를 익힐 수 있도록 하였다. (3레벨이 되었을 때 점령과 관련된 정보를 전달하는 튜토리얼 2 stage 도 추가하였다.) 이러한 조치는 전체 사용자들의 평균 레벨대를 1-2 레벨 대에서 보다 높은 4-5 레벨대로 유도하게 되었다.

• 여기에서 우리가 배운 점
  PvP 대전 게임에서 그 것이 강제적인 것인지 합의적인 것인지를 따져야 한다. 내가 상대와합의한 상태에서 게임에서 지는 것과 나의 합의를 무시한 채 이루어진 대전에서 지는 것은 그 결과가 판이하게 다르다. 만약 우리가 다시 PW를 기반으로 하는 대전 게임을 만든다면 우리는 PW 라는 선택지 이외에도 플레이어가 충분히 연습할 수 있는 곳을 준비하여 필요한 만큼 적응할 수 있는 장치와 공간을 제공할 것이다. 사용자들에게 있어서 연습은 충분한 가치가 있다.

3. 고사양을 요구하는 PC 사양

기획 초기의 블리츠는 multi resolution 을 구현할 계획이었다. 즉 사용자의 PC 사양에 맞게 사용자가 자신의 게임 해상도를 자유롭게 변경할 수 있도록 할 계획이었으나 제작 기간 중 발생한 악재들로 인해 빠른 결과물을 위해서 우리는 다중 해상도를 우리의 TODO LIST에서 빼야만 했다. 프로그램팀에서는 해상도를 결정해 줄 것을 내게 요청했고 2003년 당시 국민해상도라 불리웠던 1024*768을 별다른 검증과정 없이 기본 해상도로 잡게 되었던 것이다. 우리는 블리츠 그래픽 어셋들을 게임 성능을 높이기 위해 적은 폴리곤을 가지고 작업했기 때문에 2년 정도 뒤에는 그 정도 해상도로 무리가 없을 것이라는 모호한 기대를 가졌던 것이다. 실제 블리츠가 제 모습을 가지게 되면서부터 클라이언트의 무게가 불어나기 시작해서 최종적인 클로즈 베타테스트 버전 때에는 지포스2나 지포스4MX 초기 모델 같은 그래픽 카드는 물론, 일반적인 권장 사양의 그래픽 카드에서조차 대규모 접전 시에는 게임 플레이가 힘들 정도로 클라이언트의 성능이 떨어졌다.

우리는 서비스 안정화라는 작업과 추가 컨텐츠 업데이트 이외에 지속적인 최적화 작업을 일정에 포함시켜 작업을 했으나 그 효과가 미비하였다. 결국 오픈베타가 시작된 지 6개월이 되어서야 저해상도에서도 게임이 가능하도록 해상도 선택 기능을 억지로 집어넣게 되었고 기능이 뒤늦게 구현되었지만 이미 일일 방문자의 수가 현격히 떨어진 이후였기 때문에 그야말로 소 잃고 외양간을 고친 셈이 되어버렸다.

[imays] 서버 프로그램의 불안정에 대해서는 본론(1,2,3)에 포함되지 않고 이 글의 서론에서 거론됐다. 이유는 간단하다. imays는 서버 프로그래머 출신이니까. 그런데 말이지... 기왕 imays를 까댈거면 좀 더 확실하게 까대시라. imays는 그 '느려터진' 블리츠 클라이언트의 엔진도 설계한 장본인이다. 나같으면 클라이언트 프로그램의 느린 성능도 서론에서 거론해서 한번 더 imays를 까댔을 것이다.

• 
  여기에서 우리가 배운 점
  MMORPG와 같은 성숙한 게임 시장의 사용자들을 제외한 대다수 게임 사용자들의 PC 사양은 개발팀이 예상하는 것보다 매우 낮다. 2006년을 기준으로 인터넷을 즐기는 평균 PC의 사양이 펜티엄 1.4 , 512 MB, 비디오메모리 64M, HDD 40기가 라는 점을 잊지 말아야 한다. 게다가 국내 사용자들이 오래된 PC의 부품을 교체/구입하는 기간은 최소 1.6년 이상이다. 개발팀은 평균 사양 이상을 기대하고 게임을 개발하지만 대다수의 사용자들은 평균 사양 이하에서 개발팀이 만든 게임이 잘 돌아가길 기대하고 있다.