Irene's Heart Complex

지난번 회사에서 퇴사를 한 이후 3주 뒤 가까스로 새로운 직장을 얻어서 근무하게 되었다. 사실 조금 더 놀아볼까? 라는 건방진 생각이 없었던 것은 아니었지만, 여튼 지금은 요즘 같은 시절에 일을 할 수 있다는 것 만으로 감사하면서 열심히(?) 근무중인 상태. 그럭저럭 오늘자로 벌써 4주라는 시간이 흘러버렸다. 그간 기획 관련 일을 맡아서 게임 내의 사소한 시스템들의 기획서 정리를 했고, 지난주 부터 게임에 들어가게 될 퀘스트 시스템의 디자인을 맡게 되었다. '일을 맡기고 전담시키겠다'는 기획 팀장의 말과 함께 부담 반, 의욕 반으로 일을 시작하고, 3일 정도 뒤에 컨셉안을 잡고 팀장에게 검토 상신을 했다. 초기의 기획안은 스포츠 온라인 게임이라는 장르 특성상 온라인 RPG 게임의 퀘스트 처럼 스토리텔링을 하는 것 보다는 XBOX360의 도전과제의 컨셉으로 가야 된다는 나름의 소신의 의견을 냈다.

사실 MO 형태의 스포츠 게임에서 퀘스트의 역할은 그 의미가 많이 축소 될 수 밖에 없다고 판단은 나름 논리에 기인한 것이었다. PvC 보다는 PvP가 주가 될 수 밖에 없는 스포츠 게임의 구조 상 퀘스트는 부차적으로 흐를 수 밖에 없으며, 단순히 게임을 하드하게 즐기는 플레이어들에게 하나의 과제를 만들어 그들의 게임 소비 시간을 늘리는데 의미가 있을 뿐이었을 터였다(AI 패턴 제작 능력이 없는 회사의 기술력 부족도 큰 요인이 될 것이기도 했다). 때문에 모두가 즐길 수 있는 형태의 퀘스트가 아니라, XBOX360의 도전과제 시스템을 대안으로 들고 나왔던 것이었다.

초안의 검토를 마친 팀장은 몇가지 사항에 대해서 지적을 했다. 퀘스트를 습득하는 로직에 대한 설명 부족(XBOX 360의 경우에는 게임에 설정되어있는 도전 과제 전체를 한번에 불러오고 있으며. 때문에 컨셉 안에는 '게임 계정 생성과 동시에 목록을 자동 생성'이라고 단 한줄을 적었더란다). 퀘스트의 종류가 세분화 되어있지 않음. 개인적으로 3대 악 퀘스트라고 생각하는 반복, 수집, 일일 퀘스트의 존재 여부가 그 지적 사항이었다. 나는 순진하게도 이를 해당 부분에 대한 문서의 보강 지시라고 판단하고는 기존 문서에 각종 로직 세부 서술을 붙이고, 문서의 편집을 다시 한번 손 보고, 삽화와 순서도를 추가하는 고생을 해서 최종 문서를 제출했다(3대 악 퀘스트에 대해서는 고려조차 하지 않았다). 그리고 금일 검토 회의......

"음, 일단 퀘스트를 분류하고 리스팅 하는데 문제가 있어보이는데요?" 라는 팀장님의 질문에 리스팅은 각 레벨 등급에 나눠서 카테고리별로 한번에 내 놓는 것이 좋을 것 같다는 의견과 함께 도전과제 형태의 진행에서는 이전 레벨에서 완료하지 못한 퀘스트도 수행 할 수 있도록 해야 되지 않느냐는 의견을 냈다. 거기에 팀장님이 응수한 대답에서 나는 말문이 막히고 말았다.

"그런 개념 보다는 퀘스트는 어차피 반복적으로 해야 되는거고 유저들은 보상이 없으면 퀘스트를 안해요. 때문에 분량과 구분이 중요한거고, 연퀘라던가 일일퀘같은게 들어가 줘야 유저들이 즐길텐데요. 레벨 등급이 아닌 레벨 단위로 세분화 시켜서 각각 리스팅에 나타날 목록을 설정해 줘야 할 것 같고 이에 대한 설정을 좀 더 자세하게 해 주세요"

처음에는 이게 무슨 소린가 했다. 여러가지 이유들을 바탕으로 기존의 MMORPG에서 많이 볼 수 있는 퀘스트 형태를 피해보고자 한다는 이야기를 분명히 기획서에 적었고, 시스템 구조도 그런 식으로 서술해 둔 마당인데다, 이미 해당내용에 대한 초안의 검토까지 같이 마친 마당에서 갑작스러운 이야기라 당황스러웠지만, 그래도 조심스럽게 물었다.

"그건, 기존의 MMORPG 형태의 퀘스트 시스템으로 가자는 건가요? 우리 게임의 특성 상 그렇게 갈 필요가 있느냐는 생각입니다만?"

"꼭 RPG 게임의 퀘스트가 아니더라도 그렇게 가는게 맞는게 아닐까 싶어요. 거기에 덤으로 NPC를 대상으로 스토리를 얹는것도 어떨까 하는데요. 여튼 이 기획서에는 퀘스트 종류라던가, 진행 방법 등에 대한 세부적인 내용이 없네요. 업무 능력을 100이라고 가정했을 때 70 정도 밖에 보여주지 못한 것 같아서 좀 아쉽네요."

아차 싶었다. 팀장은 문서의 내용을 자신이 원하는대로 해석을 해 버렸다. 이미 그의 머릿속에는 퀘스트 시스템에 대한 롤 모델(기존 MMO 게임들의 퀘스트 시스템의 전형, NPC에게 말을 걸어 이야기를 주고 받은 뒤, 죽어라 같은 패턴의 퀘스트를 단지 레벨 업을 위해서 진행하는 형태)이 있는 상태였다는 것을 그제서야 알아차린것이다. 기획서에는 분명 퀘스트 리스트를 자동으로 받고, 그것을 완료하는 조건과, 그에 따른 보상 방법에 대한 내용이 서술되어 있었지만, 단순히 기존 MMO 게임들의 퀘스트 시스템을 살짝 비껴갔다는 것만으로 팀장의 머릿속에서 간단하게 무시되어 버렸다(졸지에 업무능력 마이너스라는 평가가 덤으로 붙었다). 거기에 대 놓고 기존 퀘스트 시스템의 단점 같은 것을 늘어 놓아봐야 소용없는 일이었다. 그저 '젠장, 언제는 맘대로 만들어보라며'라며 속으로 투덜거릴 수 밖에는 할 수 있는 일은 그닥 없어보였고. 결국 그렇게 회의가 끝내버렸다-문서에 대한 보강 지시(라고 하지만, 실상은 전면 재 작성이 필요한 상황)와 함께.

어차피 밑에서 일하는 사람의 입장에서는 윗 사람의 의도를 파악하고 이를 따라주기 위해서 노력을 해야 되는 것이기 때문에 내용이 내가 원하는 방향으로 결정되지 않았다고 배알이 뒤틀리거나 할 것은 없다(다만, 나중의 그 일에 대한 책임을 아랫사람에게 전가시키지 않는다는 전제가 붙는다. 나는 분명 기존 MMOG의 퀘스트 시스템이 우리 게임과 잘 어울릴 것이라 여전히 생각하지 않는다). 다만, 그것보다 가장 크게 실망한 부분은 커뮤니케이션 문제다. 우선 나로써는 팀장의 의도를 적절하게 파악하지 못했다는 가장 큰 문제가 있었다. '알아서 맡아서 만들어보라'는 이야기를 과신하고, 너무도 속 편하게 '남들과 다른 걸 만들 수 있다'고 생각하고는 이에 대한 이견이 없을 것이라는 생각을 해 버린 것도 문제였다. 팀장의 경우에도 (감히 이야기를 하자면) 상황을 보면 업무 지시 능력이 그다지 좋은 편은 아니라고 생각 된다. 자신이 의도한 바를 명확하게 설명 할 수 있고, 이를 바탕으로 업무 지시를 내려야만 정확하고 간결한 업무 지시를 내리고 빠른 결과를 얻을 수 있다(이건 경영학 전공을 하면서 배운게 아니라, 3년간의 군 생활에서 아랫사람들을 부리면서 채득한 노하우다). '알아서 만들라'는 이야기를 내 뱉은 이상은 자신의 의도 보다는 아랫 사람의 의도를 파악하려고 했었던 것이 옳았다. 그게 아니라면 초기에 자신의 의도(기존 MMOG 형태의 퀘스트 시스템을 게임에 도입 할 것)를 확실하게 전달하고 업무를 진행시켰어야 했다.

검토 회의 이후, 오전 내 충격으로 인하여 아무 일도 못한...척을 하면서 시간을 죽이다가 결국 기획서를 완전히 뜯어고치는 일을 반나절 만에 끝내고 깔끔하게 퇴근을 해 버렸다. 다음번 상황에서도 얼마나 커뮤니케이션이 잘 이루어질지는 모르겠지만, 일단 내 잘못을 다시 저지르지 않겠다는 다짐 정도는 해 줘야 할 것 같다. 뭐, 안되면 별 수 없지만서도.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by Irene

개인적인 이야기를 먼저 해보자면 사실 게임 업계에 발을 살짝 담근 것은 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 본연의 서비스 보다는 자기 세력 불리기라는 이상한 모양세가 되어버렸기 떄문이다(발주사 쪽에서는 공공연하게 이를 '피라미드 형 게임'이라고 불렀다.

기본적인 서비스에서의 사용자 행동 양식은 다음과 같았다.

1. 서비스에 가입 한 후, 친구 맺기를 통한 다른 사용자와의 인위적인 관계 설정
   
2. 관계를 맺은 친구들과 메시징, 게임, '여행지'라 불리우는 Virtual World의 사용을 통한 관계 개선
   
3. 수치로 '계산'되는 관계에 따라서 레벨 및 등급의 향상(각 친구간의 친밀도가 높으면 많은 경험치를 받는 구조이다)
   
4. 자신에게 주어지는 집과 정원을 꾸밈으로써 각 개인에 대한 차별화 시도
   
5. '요정'이라는 존재를 삽입하여 육성 게임으로서의 기능 추가
   

프로젝트 참여 - 인력

프 로젝트의 기획은 2007년 12월 경 부터 시작 되었던 것으로 알고 있으며-추정인 것은 회사에 제대로 검토 할 수 있는 개발 데이터가 전혀 남아있지 않기 때문이다-나의 경우에는 2008년 5월 중순 부터 본격적으로 작업에 투입되기 시작했다. 기획이 정리되고 개발이 시작 된 것은 2008년 6월 경 부터였으나, 그때까지 관련하여 투입 된 MM은 기획자 1명 뿐이었고, 커뮤니케이션 문제로 인하여 그 기획마저도 진척이 지지부진한 상황이었다. 내가 프로젝트에 들어온 후 한달 즈음 정도 뒤에, 프로그래밍 팀과 그래픽 팀이 투입 되기 시작하였는데, 주로 웹 어플리케이션이나 아바타 디자인만을 전문적으로 담당했던 인력들이었기 때문에 서로 다른 관점에서 프로젝트를 이해하기 시작한 것이 잘못된 단추를 끼워넣는 첫번째가 되어버렸다. 일단 가장 큰 시각 차를 보였던 것은, 기획팀에서는 프로젝트를 게임으로 규정하고 일을 진행시킨 반면, 직접적인 개발을 담당하고 있던 프로그래밍 팀은 웹 어플리케이션으로 규정하고 서로 상이한 제작 시스템에 대해서는 서로간의 이해도 없이 무조건적으로 자신들이 익숙한 프로세스를 강요하고 있었다는 점이었다-그리고 이 문제는 새로운 프로젝트를 진행할 때에도 발목을 잡고 있다.

프 로젝트 인력 구성은 회사의 사정에 따라 그때 그때 달라졌다. 프로그래밍 팀의 경우, 초기에 무려 7명이나 투입되어 각각 어떠한 조율도 없이 무작정 모듈을 나눠 프로그래밍 작업을 들어가기 시작했다. 코드가 제대로 작동을 하기도 전에 적절한 신송도 없이 관련자들 중 세명이 퇴사, 한명이 다른 프로젝트에 투입되어야 했다. 그나마 남아있던 사람들도 시시 때때로 회사의 결정에 따라서 프로젝트를 한번에 두개, 세개 씩 나가는 경우가 있었고, 심한 경우 QA 기간 중 코드를 수정 할 수 있는 인력이 없어서 그냥 프로젝트를 버려두다시피 하기도 하는 상황도 발생했다.

그래픽 팀의 경우는 프로그래밍 팀 보다 더 사태가 심각했다. 주로 캐릭터나 아바타 디자인을 전문으로 하는 팀이었기 때문에 UI 디자인의 퀄리티는 기대하기 힘들었던 면도 있긴 하지만, 그렇다고 해서 모자란 전문성을 보충 할 여력이 있지도 않았다. 잦은 프로젝트 이외의 업무 때문에 작업과 결과물은 지지부진하기만 했고, 적절한 디자인 가이드가 전혀 없었기 때문에 각 개별 작업자들의 디자인은 전부 제각각 놀고 있었다. 이런 문제들을 더욱 부채질 했던 것은, 프로젝트 팀 내에 아트 디렉터 같은 그래픽 디자인을 총괄하고 책임을 질 만한 인력이 전혀 지정되지 않았었고, 아에 프로젝트 중반에 그래픽 담당 부서가 업무량 과다-그것도 프로젝트가 아닌 다른 업무들 때문에 디자인을 게임 사업부가 아닌 웹 사업부의 디자이너들에게 맡겨야만 하는 일이 발생해 버렸다.

웹 사업부가 전담을 하게 되었다고 해서 사정이 나아진 것은 하나도 없었다. 이들 역시 게임 제작과는 별로 연관이 없는 사람들의 집합이었고, 그들 사업부가 진행하고 있는 프로젝트도 과다하게 많은 상황이었다. 기본적인 플레시 개발에 대한 이해도 없었고 그것을 설명할 여유도 없었기 때문에 항상 프로그래머는 웹 사업부의 결과물에 불만족스러워 했고, 웹 사업부는 웹 사업부 나름대로 반복되는 수정 요구에 지쳐 항의를 하는 모습도 지속적으로 보였었다-그리고 중간 개발 점검에서 그래픽 퀄리티는 발주사의 가장 큰 불만이 되어버렸다.

인력과 관련하여 프로젝트에 가장 큰 위기는 런칭 1달전에 갑작스럽게 끼어든 공공기관 발주 프로젝트(기능성 게임 제작)를 시작하게 되면서 부터였다. 회사의 위험한 재정 상태를 해결하기 위해 급하게 시작된 프로젝트에 PM을 포함한 우리 프로젝트의 모든 인력들이 이 갑작스럽게 끼어든 프로젝트에 모두들 달려들어버렸기 때문에 마지막 QA에 나온 심각한 문제들만 겨우 수정 한 후 서비스가 내포하고 있는 여러가지 문제들은 그대로 안고 서비스를 런칭 할 수 밖에 없었다. M/M이 0이 되어버린 상황에서 복잡하게 꼬여있는 UI나, 용도가 모호하기만 한 기능들을 정리하거나 적절한 수정을 가할 기회를 놓쳐버렸고, 결국 서비스는 런칭 직전(계약상정식 버전이 런칭되어야 함에도 불구하고)에 Beta 버전으로 명명되어 서비스를 시작했다.

인력 문제는 말단이었던 내가 결정할 수 있는 문제도 아니었기도 했지만, 상황을 지켜보면서 안타까운 면이 적지 않았다. 적절하고 확실한 인력 배치가 이루어졌다면 사람들이 자신의 업무에 좀 더 책임감을 가지고 집중을 할 수도 있었지만, 지나치게 잦은 인력 교대와 프로젝트 중복(심한 경우 한 사람이 네 다섯개의 프로젝트에 동시에 참여하고 있는 경우도 발생했다)으로 인하여 각 참여자 전체의 책임감은 함께 분산되어 결국 프로젝트는 아무도 책임지지 않는 상황까지 와 버렸다. 또한, 프로젝트에 대한 집중도도 떨어져 퀄리티 저하라는 치명적인 결과를 불러왔으며, 퀄리티를 높이기 위한 부단한 노력마저도 인력이 없는 문제로 인하여 제대로 손 써 볼 기회마저 상실했다.

회사의 입장에서는 급한 상황을 타개하기 위한 어쩔 수 없는 결정이라고 변명할 지 모르겠지만, 회사의 인적자원 관리 시스템은 분명히 프로젝트를 적절하게 서포트하지 못했고 있었고 그로 인하여 막대한 시간과 금전적 기회비용을 날려버렸다고 생각한다. 다수의 프로젝트를 순차적으로 진행 할 수 있는 프로젝트 팀 조직으로 전환하였다면 한 명의 인력이 다수의 프로젝트를 신경쓰느라 결국 아무런 성과도 내지 못하는 일을 막았을 수 있었을 것이다. 아니 하다못해 조직 개선이 아니라 처음 프로젝트에 참여했던 인력이 끝까지 프로젝트를 진행할 수만 있었다고 하더라도 지금 보다는 좀 더 나은 결과물이 나올 수 있지 않았을까?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by Irene