사후검토: A 프로젝트

Views: 857

프로젝트 소개

A 프로젝트는 아케이드 업소용으로 제작된 터치 디바이스 기반 미니게임 모음 게임이다. 코나미 Konami 의 ‘비시바시 Bishibashi 시리즈’, 엑스포테이토의 ‘컴 온 베이비 Come on Baby’와 비슷한 구조의 아케이드 게임으로 터치 스크린을 이용한 미니 게임들을 새로 디자인 하여 게임 내에 삽입 하였다.

게임을 시작하면 캐릭터 선택 및 기기가 지정해주는 미니 게임을 선택하여 최대 3~4 개의 미니 게임을 연속으로 즐길 수 있다. 매장 내 동일 기기 간 네트워크 연결을 지원하여 점수 경쟁을 통한 ‘경쟁 모드’가 구현되어있다.

프로젝트는 베타 릴리즈 상태로 사내에서 잠정 중단 된 상태이다-현재 해당 프로젝트를 진행했던 인원 전원이 다른 프로젝트에 배속, 퇴사 등으로 인하여 팀이 흩어져 있으며, 사실상 프로젝트가 와해되어있는 상황이다.

• 프로젝트: A Project
• 플랫폼: 아케이드 업소용 – 윈도우즈 / PC 플랫폼
• 기기: 커스텀 PC / 터치 스크린
• 개발 기간: 2009. 06. ~ 2010. 05. (12 개월)
• 개발 인력: 약 110 M/M (월 평균 약 9 M/M, 최대 인원 Full Time: 9, Part Time: 3)
• 상태: 베타 릴리즈 / 프로젝트 잠정 중단1

잘 된 부분

프로젝트 개발 프로세스 정립

프로젝트 초창기에는 개발 프로세스라는 형태가 공식적으로 존재하지는 않았다. 나름 게임 개발 업계에서 십 수년간 몸 담은 사람들이 경영진에 포진하고 있고, 마니아 층을 형성한 게임을 제작하고, 온라인 게임 개발도 한 견실한 업체였음에도 불구하고, 프로젝트 관리는 거의 전무하였으며, 초창기 개발 현장에서 보여지는 주먹구구식 개발 환경이 난립하는 회사 상황에서 팀 내의 개발 프로세스를 확립하는 일은 그리 쉬운 일은 아니었다.

팀 내에 개발 프로세스를 도입 할 때의 팀원들의 저항(그런 것 없이도 우린 잘 해왔다 식의)이 있을 것이라 예상되었기 때문에, 팀 내에서 뜻을 가지고 있는 프로그램 – 게임 디자인 파트에서 먼저 프로젝트에 필요한 의사소통 라인을 만들었다. 회의 및 개별 면담 후, 개발 문서를 제작 이를 SVN을 이용하여 일괄 배포하였고, 지속적으로 수정하고 재배포 함으로써 개발 중 발생하는 커뮤니케이션 문제를 억제할 수 있는 환경을 만들었다. 그리고 개발 중 발생하는 이슈를 이슈 트래커 Issue Tracker 인 맨티스 Mantis 를 이용하여 모든 이슈 사항을 기록하였다.

기반 시스템이 완성 된 이후, 프로젝트를 진행하면서 개발 프로세스 관련 문제가 불거질 때 마다, 그래픽 파트, 기획 파트 등의 인력 들을 하나 둘 설득해 가면서, 개발 프로세스를 위한 관련 툴의 사용법을 교육하고, 프로세스에 대한 이해를 팀원 하나 하나에 넓혀가면서, 팀 전체가 하나로 정립된 프로세스에 맞춰 업무를 진행 할 수 있도록 하였다. 약 3~4개월에 걸쳐 이를 천천히 추진함으로써, 새로운 개발 프로세스에 대한 팀 내 저항을 최소화 하였으며, 개발 프로세스 정립으로 인한 장점들을 팀원들 하나 하나가 체득해 나가면서 프로젝트의 진행에 탄력이 붙기 시작했다.

프로세스에 대한 전체적인 관리는 각 개발 파트(게임 디자인, 프로그래밍, 그래픽)의 팀장들이 각 팀원들에 대한 업무 관리를 진행하였다. 이를 뒷받침하기 위한 협업 개발 툴(개발 페이지, SVN,맨티스)에 대하여 별도 관리 담당자를 지정하여 팀원들이 개발 툴을 100% 활용 할 수 있도록 서포트 하였다. 별도로 제작된 개발 페이지에서는 개발 일정, 최신 개발 이슈 현황, 일일 빌드 현황을 개발 팀원 누구라도 손쉽게 확인 할 수 있도록 하였다. 매 주 정기 회의에서는 통계 처리된 업무 진척 상황을 보여줌으로써 객관화 된 프로젝트 진척 상황의 공유가 가능하도록 하였다.

리소스 관리 및 배포

프로젝트 진행 중 발생하는 모든 리소스는 SVN Subversion 을 이용하여 관리/배포 하였다-팀 내 SVN을 도입 하기 이전에는 메일과 공유 폴더를 이용하여 리소스가 관리되고 있었다. SVN에서 프로그램 소스 뿐만 아니라 모든 문서, 그래픽 및 사운드 리소스, 심지어 일일 빌드 결과물까지 통합적으로 관리하여 개발 도중 리소스를 분실하여 시간을 버리는 일이 없도록 하였다-물론 모든 리소스를 SVN에 관리하다 보니 개발 후반부에 SVN이 점차 느려지는 현상이 발생하기도 하였다.

개발 문서의 경우 수정 사항이 발생 할 경우, 해당 수정 사항을 반영한 문서를 바로 커밋하여 팀원들이 항상 최신의 문서에 접근 할 수 있도록 하였다. SVN의 기록 기능과 문서 상에 수정 이력, 그리고 해당 이슈에 기록을 통하여 수정 사항에 대해서 팀원들이 놓치지 않도록 주의를 기울였다.

그래픽 리소스에 대해서도 기존 개인 작업 폴더 – 공유 폴더로 유지 되면서 버전관리 및 리소스 관리가 되지 않았던 부분을 SVN에 통합시키므로써, 리소스 분실, 중복, 과거 내용을 덮어 씌우는 사고 발생이 줄어들었으며, 이는 프로젝트 수행 시간을 절약하는데 많은 역할을 하였다.

SVN을 관리하는 담당자가 배정되어, 팀원들에 대한 SVN 이용법 교육, 사용자 문제 해결, SVN 저장소 관리 등의 업무를 진행하였으며, SVN 이용에 대한 가이드라인을 만들어 공유하고, 해당 가이드라인에 맞게 관리 함으로써, 효율적인 업무 진행을 이끌어내었다.

또한 빌드 자동화 시스템을 도입하여, 전날 작업 된 결과물을 바로 다음 날 확인 할 수 있도록 하였다. 게임 디자인 담당이 매일 아침 빌드 된 게임을 테스트 하면서 일반적인 버그 및 실행 오류 등의 문제를 잡아내고, 이를 즉시 처리했기 때문에 프로젝트 후반까지 자잘한 버그로 인하여 고생하는 경우는 거의 존재하지 않았다. 모든 팀원들은 매일 새로운 빌드를 가지고 30분 ~ 1시간씩 이른바 ‘개밥 먹기’에 동원 되어 게임을 테스트 하고 문제 사항을 수정하는 과정을 거쳤다.

프로토타이핑

미니 게임 제작 시의 기본 제작 프로세스는 제안 – 게임 디자인 검수 – 프로토타이핑 – 사내 테스트 – 실 제작의 형태로 진행되었다. 게임 1종 당 보통 1~3개월의 개발 기간이 소요 되었다. 미니 게임에 대한 프로토타이핑은 ‘재미있는 게임’과 ‘재미없는 게임’을 사전에 걸러내는 필터 역할을 충실하게 하였다. 제안서 상 재미있을 것 같은 게임이 막상 구현 시 재미없다는 사실을 사전에 알 수 있는 방법은 빠른 프로토타이핑 뿐이며, 덕분에 난립하는 제안서 중에서 제대로 된 미니 게임들을 선택하여 게임 내에 포함 시킬 수 있었다.

잘 되지 못한 부분

일관된 프로젝트 목표 부재

처음 프로젝트가 킥 오프 될 당시 제품 목표는 아케이드 업소를 찾는 라이트 유저-게임 소비 시간이 한정적이고 캐주얼 게임을 즐기는 층을 시장 목표로 잡고 이에 어필 할 수 있는 제품을 만드는 것이었다. 시장 목표의 특성으로 여성과 어린이, 그리고 복잡한 게임에 익숙하지 않고 경쟁보다는 즐거움을 소비하는 것으로 자체 리서치 결과 판단되었고, 이에 대한 팀원들의 이해와 공유가 이뤄진 상태에서 프로젝트는 진행되고 있었다.

파국이 찾아온 것은 게임 개발이 어느 정도 완료된 이후 제품에 대한 포커스 그룹 테스트가 진행된 이후였다. 테스트 결과 주요 항목 평균이 10점 만점에 7~8점을 기록했기 때문에 최종 발매 결정에 별 다른 장애가 없을 것으로 예상되었지만, 갑작스럽게 프로젝트 목표를 라이트 유저 및 헤비 유저(대전 액션 등의 게임을 즐기는 하드 코어 유저) 성향의 소비자들이 사용할 수 있는 게임으로 일방적으로 변경 된 것이다.

이미 제품의 개발이 막바지에 다다른 상황에서 있을 수 없는 일이지만, 결국 무리한 설계 변경과 게임 난이도 변경을 통하여 게임은 애초의 기획과는 다르게 색이 불분명한 게임이 되어버리고 말았다-게임은 지나치게 어려웠지만, 그렇다고 이를 지속적으로 즐기기 위한 도전 욕구를 불러일으키는 것도 아닌 형태가 되었고, 애초 프로젝트 목표였던 라이트 유저에게는 다가가기 힘든, 그리고 헤비 유저들에게는 난이도만 높고 따분한 게임이 되어버린 것이다.

비 상식적인 일정과 몰아 붙이기 식 팀 관리

프로젝트를 시작 할 때 제안서 상에 의하면 개발 예상 기간, 개발 예산, 소요 인력, 예상 매출액 등이 존재했지만, 사실 어느 항목 하나 제대로 된 ‘근거 자료’는 전무했다. 때문에 말도 안되는 개발 일정이 팀원들에게 떨어졌다. 초기 개발 예상 기간은 실제 실무자들의 예측에 비하여 반 이상 짧게 잡혀 있었고, 이에 대한 어필을 하더라도, 개발 기간 연장은 관행인 것 마냥 이 문제를 대수롭지 않게 생각하고 있었다-결국 이런 태도가 경영진의 팀 및 프로젝트에 대한 불신을 부채질 한 원인 중 하나였다.

제품 개발을 위한 연구/개발 활동이 일정상 불가능 한 상황에서 어처구니 없는 개발 스펙을 요구하는 일도 비일비재 했다. 개발 팀의 역량, 현재 상태, 필요 자원 등에 대한 고려는 일절 무시 한 체, 안되면 말지 식의 제안이 나오는 경우도 허다 했다. 개발 팀은 현실적인 개발 스펙 제시 및 이에 대한 수정 일정을 제시하고 이를 철저하게 지키는 데 역량을 집중했다. 때문에 최소한 ‘본인 입에서 나온 일정’은 지킬 수 있었다.

위기 관리 능력 부재

어떠한 프로젝트든 마찬가지로 위험은 존재하는 법이며, 이 프로젝트에서도 각종 위험 요소들이 존재하고 있었다. 가장 큰 문제는 프로젝트에 대한 경영진의 신뢰 여부였는데, 경영진과 팀간의 커뮤니케이션은 심각한 문제가 있었다. 나중에 확인 된 일이었지만, 경영진이 알고 있는 프로젝트와 개발 팀이 알고 있는 프로젝트는 전혀 다른 종류의 것이었다.

인적자원과 관련한 문제도 존재했다. 프로그램 팀장의 병역특례와 관련하여 훈련소 입소 문제는 프로젝트 시작 전부터 확인 된 문제였고 이를 회피 할 수 있는 상황이었음에도 불구하고, 아무런 조치를 취하지 않은 체 가장 중요한 프로젝트 막바지에 이르러 입소하게 하는 상황을 자초했다-덕분에 프로젝트는 프로그램 팀장의 군사 훈련 기간 동안 진척 없이 표류하기만 했다.

잘못 설정한 프로젝트 진행 기간으로 인하여 제작 필수 인력을 타 팀에 빼앗기는 상황이 발생하기도 했다. 무리한 일정을 기반으로 다른 팀과 인력 교류를 약속했다가, 역시 프로젝트 막바지에 해당 인력이 팀을 옮기는 상황이 발생하였는데도, 이에 대한 대체 인력 충원 등의 대책은 나오지 않았고 프로젝트는 그냥 속행 되었다.

결과

프로젝트는 정상적으로 진행되지 않았고, 사실상 실패(게임 업계에서 ‘잠정 중단’은 ‘영구 폐기’와 유의어)하였다. 팀 내/외에서 많은 문제점들이 있었기 때문에 당연한 결과였을지 모르지만, 덕분에 프로젝트 관리와 리더십에 대한 반면교사가 될 수 있었다고 생각한다. 프로젝트의 목표 설정, 관리, 리더십에 관하여 성찰을 하는 데 더 없는 기회가 되었다는 것은 이 성공하지 못한 프로젝트가 가진 가장 큰 성공이 아닐까.