0
0
개인적인 이야기를 먼저 해보자면 사실 게임 업계에 발을 살짝 담근 것은 1999년 초의 어느 추운 겨울날이 시작이었다. 일년 반 정도의 삽질과 후회 그리고 여러가지 경험들을 한 이후, 부족한게 많았다고 판단했었던 나는 한발짝 떨어져 다시 공부를 시작했다. 군대에서 3년 4개월-아는 사람만 아는 공군 장교로 전역했다-이라는 시간을 보내면서 나름 다시 게임 업계에서 일을 할 수 있기를 바라고 있었지만, 여러가지 사정-그 중 큰 것은 아무래도 개인적인 준비 미숙-으로 인하여 그리 쉽지 않은 구직 기간을 보냈었다. 그리고 지금의 회사에서 근무를 하게 되었다.
회사 입사 이후의 초반은 사업 전략 기획을 담당하는 것 부터 시작해서, 기획서 정리, 문서 작업 등의 전반적인 기획 업무를 맡아 처리하게 되었지만, 사내에 존재하는 별개의 게임 제작 프로젝트에 여기 저기 끌려다니면서 정신 없이 일한 것 밖에는 기억이 나질 않는다. 기억나는 일이라고는 이미 정신을 차렸을 때에는 신혼여행을 가는 비행기 안이었다는 것 정도 였으니깐. 여전히 정신을 놓은 상태에서 신혼여행을 다녀왔을 때, 회사에서는 지금의 프로젝트를 담당하라는 지시를 내렸다.
프로젝트 소개
P 프로젝트(가칭)은 국내 모 포탈 회사에서 발주한 Web/RIA(Flash)기반 SNS(Social Network Service)로, 해당 포털 내에 서비스 중인 어린이 맞춤형 포털에서 서비스 되고 있다(2008년 12월 22일 런칭). 기본 컨셉은 게임을 기반으로 한 Virtual World의 구성과 Cyworld의 미니룸과 동일한 개념의 Private 공간 제공, 서비스 전용의 메시지 전달 기능 등을 제공하여 어린이들이 쉽고 간편하게 쓸 수 있으면서 게임 처럼 재미있는 SNS를 만드는 것이다.
사실 프로젝트에 참여하면서 가장 애매모호한 설정이 ‘게임 처럼 재미있는 SNS’라는 부분이었다. 이미 내가 참여하기 전 부터 몇달간 발주사의 PM과 함께 서비스의 방향에 대해서 많은 논의가 있었던 것으로 전해 들었지만, 여전히 게임이 우선인지 아니면 어린이들이 쓰기 쉬운 SNS가 우선인지에 대한 방향성 조차 제대로 잡히지 않은 상태에서 서로 자신만의 이해를 바탕으로 디자인을 진행시키고 있었다. 지금에 와서 개인적으로 파악하기로는 결국 재미요소가 양념으로 들어가 있는 ‘SNS’가 원래 목표였던 모양이었던 듯 하다. 다만, ‘이었던 듯 한’ 까닭은 서비스의 기본인 Social Network가 친구 수를 기반으로 한 레벨 업 시스템과 결부 되어 있기 때문에, 입소문을 통한 회원 수 확장을 지나치게 노렸고 때문에 SNS 본연의 서비스 보다는 자기 세력 불리기라는 이상한 모양세가 되어버렸기 떄문이다(발주사 쪽에서는 공공연하게 이를 ‘피라미드 형 게임’이라고 불렀다.
기본적인 서비스에서의 사용자 행동 양식은 다음과 같았다.
- 서비스에 가입 한 후, 친구 맺기를 통한 다른 사용자와의 인위적인 관계 설정
- 관계를 맺은 친구들과 메시징, 게임, ‘여행지’라 불리우는 Virtual World의 사용을 통한 관계 개선
- 수치로 ‘계산’되는 관계에 따라서 레벨 및 등급의 향상(각 친구간의 친밀도가 높으면 많은 경험치를 받는 구조이다)
- 자신에게 주어지는 집과 정원을 꾸밈으로써 각 개인에 대한 차별화 시도
- ‘요정’이라는 존재를 삽입하여 육성 게임으로서의 기능 추가
프로젝트 참여 – 인력
프 로젝트의 기획은 2007년 12월 경 부터 시작 되었던 것으로 알고 있으며-추정인 것은 회사에 제대로 검토 할 수 있는 개발 데이터가 전혀 남아있지 않기 때문이다-나의 경우에는 2008년 5월 중순 부터 본격적으로 작업에 투입되기 시작했다. 기획이 정리되고 개발이 시작 된 것은 2008년 6월 경 부터였으나, 그때까지 관련하여 투입 된 MM은 기획자 1명 뿐이었고, 커뮤니케이션 문제로 인하여 그 기획마저도 진척이 지지부진한 상황이었다. 내가 프로젝트에 들어온 후 한달 즈음 정도 뒤에, 프로그래밍 팀과 그래픽 팀이 투입 되기 시작하였는데, 주로 웹 어플리케이션이나 아바타 디자인만을 전문적으로 담당했던 인력들이었기 때문에 서로 다른 관점에서 프로젝트를 이해하기 시작한 것이 잘못된 단추를 끼워넣는 첫번째가 되어버렸다. 일단 가장 큰 시각 차를 보였던 것은, 기획팀에서는 프로젝트를 게임으로 규정하고 일을 진행시킨 반면, 직접적인 개발을 담당하고 있던 프로그래밍 팀은 웹 어플리케이션으로 규정하고 서로 상이한 제작 시스템에 대해서는 서로간의 이해도 없이 무조건적으로 자신들이 익숙한 프로세스를 강요하고 있었다는 점이었다-그리고 이 문제는 새로운 프로젝트를 진행할 때에도 발목을 잡고 있다.
프 로젝트 인력 구성은 회사의 사정에 따라 그때 그때 달라졌다. 프로그래밍 팀의 경우, 초기에 무려 7명이나 투입되어 각각 어떠한 조율도 없이 무작정 모듈을 나눠 프로그래밍 작업을 들어가기 시작했다. 코드가 제대로 작동을 하기도 전에 적절한 신송도 없이 관련자들 중 세명이 퇴사, 한명이 다른 프로젝트에 투입되어야 했다. 그나마 남아있던 사람들도 시시 때때로 회사의 결정에 따라서 프로젝트를 한번에 두개, 세개 씩 나가는 경우가 있었고, 심한 경우 QA 기간 중 코드를 수정 할 수 있는 인력이 없어서 그냥 프로젝트를 버려두다시피 하기도 하는 상황도 발생했다.
그래픽 팀의 경우는 프로그래밍 팀 보다 더 사태가 심각했다. 주로 캐릭터나 아바타 디자인을 전문으로 하는 팀이었기 때문에 UI 디자인의 퀄리티는 기대하기 힘들었던 면도 있긴 하지만, 그렇다고 해서 모자란 전문성을 보충 할 여력이 있지도 않았다. 잦은 프로젝트 이외의 업무 때문에 작업과 결과물은 지지부진하기만 했고, 적절한 디자인 가이드가 전혀 없었기 때문에 각 개별 작업자들의 디자인은 전부 제각각 놀고 있었다. 이런 문제들을 더욱 부채질 했던 것은, 프로젝트 팀 내에 아트 디렉터 같은 그래픽 디자인을 총괄하고 책임을 질 만한 인력이 전혀 지정되지 않았었고, 아에 프로젝트 중반에 그래픽 담당 부서가 업무량 과다-그것도 프로젝트가 아닌 다른 업무들 때문에 디자인을 게임 사업부가 아닌 웹 사업부의 디자이너들에게 맡겨야만 하는 일이 발생해 버렸다.
웹 사업부가 전담을 하게 되었다고 해서 사정이 나아진 것은 하나도 없었다. 이들 역시 게임 제작과는 별로 연관이 없는 사람들의 집합이었고, 그들 사업부가 진행하고 있는 프로젝트도 과다하게 많은 상황이었다. 기본적인 플레시 개발에 대한 이해도 없었고 그것을 설명할 여유도 없었기 때문에 항상 프로그래머는 웹 사업부의 결과물에 불만족스러워 했고, 웹 사업부는 웹 사업부 나름대로 반복되는 수정 요구에 지쳐 항의를 하는 모습도 지속적으로 보였었다-그리고 중간 개발 점검에서 그래픽 퀄리티는 발주사의 가장 큰 불만이 되어버렸다.
인력과 관련하여 프로젝트에 가장 큰 위기는 런칭 1달전에 갑작스럽게 끼어든 공공기관 발주 프로젝트(기능성 게임 제작)를 시작하게 되면서 부터였다. 회사의 위험한 재정 상태를 해결하기 위해 급하게 시작된 프로젝트에 PM을 포함한 우리 프로젝트의 모든 인력들이 이 갑작스럽게 끼어든 프로젝트에 모두들 달려들어버렸기 때문에 마지막 QA에 나온 심각한 문제들만 겨우 수정 한 후 서비스가 내포하고 있는 여러가지 문제들은 그대로 안고 서비스를 런칭 할 수 밖에 없었다. M/M이 0이 되어버린 상황에서 복잡하게 꼬여있는 UI나, 용도가 모호하기만 한 기능들을 정리하거나 적절한 수정을 가할 기회를 놓쳐버렸고, 결국 서비스는 런칭 직전(계약상정식 버전이 런칭되어야 함에도 불구하고)에 Beta 버전으로 명명되어 서비스를 시작했다.
인력 문제는 말단이었던 내가 결정할 수 있는 문제도 아니었기도 했지만, 상황을 지켜보면서 안타까운 면이 적지 않았다. 적절하고 확실한 인력 배치가 이루어졌다면 사람들이 자신의 업무에 좀 더 책임감을 가지고 집중을 할 수도 있었지만, 지나치게 잦은 인력 교대와 프로젝트 중복(심한 경우 한 사람이 네 다섯개의 프로젝트에 동시에 참여하고 있는 경우도 발생했다)으로 인하여 각 참여자 전체의 책임감은 함께 분산되어 결국 프로젝트는 아무도 책임지지 않는 상황까지 와 버렸다. 또한, 프로젝트에 대한 집중도도 떨어져 퀄리티 저하라는 치명적인 결과를 불러왔으며, 퀄리티를 높이기 위한 부단한 노력마저도 인력이 없는 문제로 인하여 제대로 손 써 볼 기회마저 상실했다.
회사의 입장에서는 급한 상황을 타개하기 위한 어쩔 수 없는 결정이라고 변명할 지 모르겠지만, 회사의 인적자원 관리 시스템은 분명히 프로젝트를 적절하게 서포트하지 못했고 있었고 그로 인하여 막대한 시간과 금전적 기회비용을 날려버렸다고 생각한다. 다수의 프로젝트를 순차적으로 진행 할 수 있는 프로젝트 팀 조직으로 전환하였다면 한 명의 인력이 다수의 프로젝트를 신경쓰느라 결국 아무런 성과도 내지 못하는 일을 막았을 수 있었을 것이다. 아니 하다못해 조직 개선이 아니라 처음 프로젝트에 참여했던 인력이 끝까지 프로젝트를 진행할 수만 있었다고 하더라도 지금 보다는 좀 더 나은 결과물이 나올 수 있지 않았을까?
