Irene's Heart Complex

개인적인 이야기를 먼저 해보자면 사실 게임 업계에 발을 살짝 담근 것은 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

최근, 직장에서 얼마전 완료 된 프로젝트의 확장과 관련된 문서가 나에게도 전달 되었다. 문서에는 언제나 그렇듯, 프로젝트 개요와 방향에 대한 진부한 이야기가 적혀있었고, 중반 이후의 내용 부터 프로젝트 결과 산출에 필요한 자원-시간, 인력, 투자 금액-에 대한 투입 계획이 있었다. 별 달리 이상할 것도 없어보이는 깔끔한 문서였지만, 내 눈에 거슬리는 것이 하나 있었는데, 프로젝트에 투입 되어야 할 예상 인력에 대한 부분이었다.

해당 부분에는 각 파트별 필요 인력의 인원 수가 적혀있었고, 그 중 그래픽과 관련한 총 두개의 세부 파트의 인력 구성이 '0.5'로 표기 되어 있었다. 이 내용을 보고 마음이 심란 할 수 밖에 없었는데, 이는 현재 우리 회사가 처해있는 상황과도 연관이 있다.

간단하게 회사의 상황을 이야기 하자면 이렇다. 회사는 규모나 능력에 비해서 지나치게 많은 프로젝트를 동시 다발적으로 나가고 있었고, 그 와중에 그나마 기간에 맞춰 끝난 것은 지금의 확장 계획과 연관있는 프로젝트 하나 정도였다. 지나치게 많은 프로젝트를 지나치게 적은 수의 인원 동시 다발적으로 나간다는 의미는 결국 구성원 모두가 모든 프로젝트에 조금씩은 발을 담그고 있었다는 이야기였고, 당연히 제대로 돌아가는 것은 아무것도 없었다. 그나마, 이 확장 프로젝트의 원 프로젝트가 어찌되었든 종료가 되었던 것은, 적절하게 들어맞았던 아웃소싱과 이 프로젝트에만 몰입할 수 있는 인력을 적절하게 배치했었기에 가능했다는 것인데, 사실 이것은 의도했다기 보다는 순전히 운이었고, 게다가 이 프로젝트를 마무리하기 위해 투입된 인력은 사실 다른 프로젝트에 먼저 쓰였어야 했었다-이 결정으로 인해 다른 프로젝트들은 지금 커다란 댓가를 치루려고 하는 조짐을 보이고 있다.

어찌되었든 이 확장 프로젝트 역시 다른 프로젝트와 함께 동시에 진행되어야 하며, 회사의 인력 상황은 사실 악화되면 악화되었지 그다지 좋아지진 않은 상태이다. 이런 상황에서 인력을 0.5로 구성한다는 것은 결국 다른 프로젝트에 투입되어 있는 사람을 끌어다가 쓰겠다는 의미로 밖에는 해석 되질 않는데, 다른 프로젝트는 이미 적절한 시기에 자원 투입이 늦어져서 이것 저것 마구 연기 되어 있는 상태임에도 불구하고 프로젝트 책임자는 뻔뻔하게도 이를 먼저 끌어다 쓰겠다고 선언한 셈이다.

얼핏 생각을 해 보면 생산성이 좋은 인력에게 이 일도 시키고 저 일도 시키고 하면 0.5라는 계산이 나올 법도 하겠지만, 사람은 절대 멀티테스킹이 가능한 존재가 아니며, 더군다나 0.5로 쪼갤 수 있는 존재도 아니다. 게다가 프로젝트 공정의 특성상 프로젝트에 한번 투입 된 인력은 프로젝트가 종료되기 직전까지는 어떠한 형태로든 그 프로젝트에 묶여있을 수 밖에 없는 상황이기 때문에 '지정된 일만 처리하고 다른 일을 한다'라는 전제는 이미 한참 잘못된 것일 수 밖에 없다. 어떠한 한 사람이 하나의 작업에 투입 되면 그것은 1이 투입이 된 것이지 절대 0.5가 투입이 된 것이 아닌것은 당연함에도 불구하고, 0.5라고 적는 것은 산술적 기만 밖에 되질 않는다.

더 큰 문제는 이런 계획안을 보고 자칫 잘못된 판단을 내리기라도 하는 날에는 회사 전체의 전략 상황에 문제를 일으킬 수 있다-게다가 우리 회사 처럼 규모가 작은 회사에서의 전략의 실패는 결국 회사 자체의 존폐를 좌우한다-이 계획안이 아무런 비판 없이 받아들여지게 되면, 분명히 다른 프로젝트에 투입 되어 있는 인력이 이 프로젝트에 투입이 되고, 자원을 빼앗긴 다른 프로젝트는 빠진 만큼의 인력난에 허덕일 수 밖에 없다.

여러개의 프로젝트에 투입된 인력은 그 나름대로 고충을 겪게 된다. 가치가 동일한 두 프로젝트의 우선순위가 확정적이지 않으면 업무는 두배로 늘어난 상태에서 결국 이도저도 못하는 상황에 처하기 일쑤가 되며, 하나에 집중 할 수 없는 분위기가 상시로 발생하게 되어 작업 결과물도 그다지 신통치 않은게 나올 수 밖에 없고, 결국에는 그 인력이 투입되었던 프로젝트 전반적인 품질의 하락도 각오를 해야 한다.

이런 사태를 막기 위해서는 인력 투입 계획을 세울 때 인원이 아닌 Man/Month 같은 인력 대비 시간 자원을 기준으로 계획을 수립하고 이를 의사 결정 자료로 써야 한다. 하다못해, 이런 사항이 없이 단순히 인력 투입 계획을 세운다고 하더라도사람을 소숫점으로 쪼개어 얄팍한 숫자로 현실을 기만하려는 행위는 반드시 그만 두어야 한다. 투입 인원은 어디까지나 인원이지 능률을 나타내는 숫자가 아니며, 0.5의 인간은 어디까지나 0 또는 1일 뿐 아무런 의미를 가지진 못하기 때문이다.

#. 하지만 계획서의 어디에서도 M/M 기준의 자료를 찾아볼 수는 없었고, 더 큰 문제는 우리 회사의 경영진들은 사람 쪼개기를 너무도 좋아하는 것 같다는 것이다.

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

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

Posted by Irene