Irene's Heart Complex

프로그래밍 : 실력의 부재

회 사가 Flash와 관련한 프로젝트를 시작한 것은 처음은 아니다. 웹 에이전시로 부터 시작되엇던 회사였기 때문에 상업적 용도의 웹 페이지를 제작하면서 기본적인 UI 등은 Flash를 이용하고 있었고, 다양한 Flash 기반 사진 편집 툴, 그래픽 툴, Flash 기반 아바타 서비스 등을 제작하고 있었다.. 하지만, Flash를 이용한 게임 제작에 필요한 기술력은 절대적으로 부족하였고, 지금도 그닥 실력이 나아졌다고 보여지진 않는다.

프로젝트가 진행되고 동시기에 일본에 진출해 있는 국내 게임 포털 기업의 자회사에 납품을 위한 Flash 게임 제작 프로젝트가 동시에 진행되고 있었지만, 그 프로젝트에서 얻은 교훈이 이번 프로젝트에 적용 된 것은 아무것도 없었다. 아니, 그러기는 커녕 게임 제작 프로젝트는 무려 4개의 게임을 제작했지만, 똑같은 실수를 되풀이하느라 자기 앞가림 하기에도 분주했다.

여러 실수들 중 가장 치명적인 것은 Flash 부분의 최적화가 전혀 이루어지지 않았다는 점이다. 회사에서 지급 받은 컴퓨터는 P4( 싱글 코어, HT 지원) 2.8Ghz CPU에 2Gb 메모리를 장착한 기종이었는데-이는 회사 내 평균 사양보다는 조금 못 미친 기종이었다-정원에 꾸미기 아이템을 6개 이상 얹어 놓으면 CPU 점유율이 90 ~ 100%에 육박하고 브라우저가 정지 상태에 놓이는 일이 빈번했다. 초기 기획시 회사의 컴퓨터에서 실행 시켰을 경우 50개 정도의 레이어를 깔아 놓는 것을 기본 목표로 설정했던 것을 생각하면 겨우 10% 정도의 목표를 달성한 것이다.

물론 국내의 현재 보급형 컴퓨터의 사양이 회사 보급 컴퓨터보다는 높을 것이지만, 문제는 동일한 기능이 들어간 서비스를 GSP(Global Server Project: 한국 소프트웨어진흥원 주관 해외 진출 지원 사업)에도 그대로 적용하여 이용하려 한다는 점이었다. 개인적인 의견으로는 최소 해외에 서비스 되어야 할 사양이라면 최근 발매되고 있는 넷북(Netbook)에서도 돌아가야 상업적으로 안전할 것이라 생각되어지지만, 그 정도의 퍼포먼스는 지금의 회사의 기술력으로는 도달 못할 벽 같은 것이다. 여튼, 지나치게 높은(?) 권장사양 덕분에 제대로 된 테스트 이전에 겨우 기능 동작 여부를 확인 하는데 급급할 수 밖에 없었다(애니메이션 프레임이 적어 동작이 지나치게 빠른 문제를 서비스 런칭 이후 집에서 처음 접속 해 본 이후 처음 알았다-집에서는 쿼드코어를 쓰고 있다). 최적화 문제는 현재 개발 중이며, 곧 추가 기능으로 붙게 될 여행지에서 문제가 되고 있는데, 초기 기획 사항에서 동시 접속 인원 240명을 목표로 잡았지만, 한 화면에 20명 정도만 넘어가도 클라이언트 부분에서 부하가 걸려 서버와 연결이 끊어지는 문제가 발생하고 있다.

사실 해결 방법은 플레이 해상도를 줄이거나(Flash 실행 영역의 크기는 660 * 490), CPU 연산을 잡아 먹을 수 밖에 없는 백터 이미지를 줄이고 비트맵 이미지를 추가하던가 하는 방법이 있을 수 있다(참고로 비트맵의 수를 늘리게 되면 CPU 부하는 적어지는 대신, 메모리 점유율이 기하급수적으로 늘어난다. 이 프로젝트가 아닌 다른 프로젝트에서 Flash 게임이 메모리 200Mb를 넘게 잡아먹으면서 IE와 충돌로 뻗어버리는 일도 경험했었다). 개발 기간은 그러한 추가 작업을 할 수 있는 여력을 남겨두지 않았다. 사실 그 이전에 최적화에 대한 문제가 P프로젝트 진행 이전 다른 프로젝트에서 부터 지속적으로 튀어나왔음에도 불구하고, 프로그래머 중 누구도 기획 단계나 작업 초기 단계에서 이러한 문제에 대해 조언하거나 나서서 이야기 하는 사람이 아무도 없었다-기획 초기에 내가 최적화 문제에 대한 의견을 내었을 때, 프로그래밍 팀장으로 부터 '문제 사항이 되질 않는다'라는 한마디만 들었던 것으로 기억한다.

개발 프로세스 : 임기응변

프 로그래밍 팀이 여태껏 시행해 온 개발 프로세스는 전형적인 폭포수 개발법으로, 프로젝트가 시작되면서도 당연하게 이를 (지나치게)충실히 따르고 있었다. 때문에 확정된 기획에 대하여 집착을 하고 있었고, 변경이나 수정에 대해서 민감했다. 문제는 프로그래밍 팀-정확히는 프로그래밍 팀장-이 원하는 기획서를 제공 할 여건이 되질 않았다. 세상의 다른 여러 프로젝트도 마찬가지이겠지만, P 프로젝트 역시 초기 기획중에 발주사의 요구는 매번 변경되었고 이는 '완성된' 기획서를 내 놓는 것을 불가능한 상황으로 만들어가고 있었다.

기획팀과 프로그래밍 팀이 바라보는 '기획서'의 정의가 다른 것도 커뮤니케이션을 가로막는 원인이 되었다. 프로그래밍 팀은 그간의 웹 개발에 근거한 스토리보드(Storyboard)에 기반한 기획서를 바라고 있었고, 기획팀은 기존의 게임 개발에 근거한 개발 문서를 작성하였다. 웹 개발과 게임 개발의 프로세스의 차이는 분명히 존재했지만, 서로간에 이에 대한 합의를 보려는 노력은 조금도 없었고, 되려 서로 무능하다고 헐뜯는 사태까지 벌어지기도 했다.

결국 당연하게도 프로젝트가 끝날 때 까지 양쪽이 모두 만족 할 수 있는 최종 기획서는 나오지 않았다. 기획과 프로그래밍 모두 서로의 고집을 피우는 바람에, 프로그래밍 팀은 소중한 개발 시간을 잃어버렸고, 기획 팀은 프로그래밍 팀과의 쓸모없는 소모전으로 인하여 좀 더 나은 서비스로 개선 할 수 있는 기회를 잃어버렸다. 프로젝트는 어정쩡한 기획서를 바탕으로 기본 골격만을 결정 한 뒤, 이후 발주사에서 떨구는 이슈들에 대한 무한 수정이라는 임기응변으로 진행되기 시작했다. 여기에 1편에서 이야기 했던 인력 문제도 겹치면서 프로젝트는 당장 오늘 하루 어떻게 얼마나 진행될 지도 모르는 일의 연속이 되어버렸다.

임기응변으로 일이 치뤄지면서 개발 프로세스는 완전히 무너져버렸다. 이슈는 수시로 발생하고, 어떤 경우에는 문서로 정리할 여력도 없이 구두로 일이 진행되기 시작했다. 이슈 트래킹 시스템의 도입은 꿈 꿀 수도 없었다(Mantis나 Trac을 쓰자는 내 의견은 바쁘다는 이유로 묵살되었다). 심심한 경우 동일 이슈가 반복해서 나오거나, 수정했던 이슈를 다시 복원하는 등의 일들이 수 없이 발생하기 시작했다. 개발 팀은 전체적으로 지쳐가고, 점차 서로에 대해서 믿지 않기 시작했다. 지금에 와서 생각해 보면 프로젝트가 일단 종료되었다는 사실이 신기 할 정도로 개발에 참여한 구성원들의 사기는 최악으로 치닫았고, 결국 프로젝트가 종료가 된 지금에서도 회복되질 않았다.

프 로젝트에 참여할 당시 애자일 개발 방법론에 대해서 공부를 하면서 이러한 문제에 대한 하나의 대안이 될 수 있을 거라 희망을 하였지만, 회사에서 이에 대해 그나마 이름이라도 들어본 사람은 다섯 손가락 안에 꼽을 정도로 애초에 이에 대해서는 완전히 무지한 사람들의 집합이었기 때문에 도입에 대한 이야기 자체를 시작하기 조차 힘들었다. 무엇보다 프로그래밍 팀의 개발 프로세스에서는 지금에서는 프로젝트 개발에서의 기본 중의 기본이라 할 수 있는 '형상 관리'조차 제대로 이루어지지 않은 상황에서 애자일 같은 이야기는 어디까지나 사치였다-아직도 SVN을 프로그래밍 팀 중 일부만 사용하고 있고, 웹 파트의 경우에는 소스를 여전히 로컬 디스크에'만' 저장하고 있다. 물론 애자일을 바로 도입했다고 해도 시행착오 없이 완벽하게 안착 시킬거라 생각치는 않는다. 하지만, 지금처럼 아무도 발견되는 문제를 바라보기만 하기만 하지 않고, 적극적으로 나서서 개선을 하려고 노력했다면 조금은 더 바람직한 방향으로 이동을 했을거라 믿는다.

끝. 그리고...

P 프로젝트는 여러가지면에서 실패 요인을 안고 있었다. 어떤 요인들은 개선이 가능 했지만, 그렇게 하지 못했고, 어떤 요인들은 여러 환경적인 요인으로 인해 개선 할 수 없었으며, 어떤 요인들은 개선을 바랬지만, 그렇게 되질 않기도 했다. 사실 몇번이라도 엎어질 뻔 한 프로젝트가 그나마 끝을 본것은 품질(Quality)과, 시간을 바치고 결과물을 얻어낸 '등가교환'의 결과일 뿐이다.

이 글을 작성하기 몇일 전 회사의 이사님과 면담을 가질 기회가 있었는데, 현재의 P 프로젝트의 품질에 대한 불만과 원인에 대해서 나름대로의 생각을 이야기 하는 것을 들었다. 나름 어떠한 부분에 있어서는 동조 할 만한 이야기가 있었지만, 그분의 의견 중 '계획만 확실하면 1명의 작업자가 동시에 대여섯개의 프로젝트를 진행하더라도 무리가 없다'는 이야기에는 실소를 금할 수 밖에 없었다. 완벽한 계획이라는 '이상'에 대해서 이야기 하는 것은 둘째 치고, 소프트웨어 프로젝트를 라인에서 생산하는 자동차 정도로 생각하고 있다는 사실에 경악이 아니라 그냥 헛웃음이 나올 뿐이었다.

적절하지 못한 인력 배치, 회사의 능력을 넘어서는 프로젝트 동시 진행, 개개인의 자질 부족, 모든 것은 적절한 상황 판단을 하지 못하는 지휘부의 무능이 가장 큰 원인이었다는 생각에 쐐기를 박아버린 사건 이후로, 개인적으로는 그나마 조금이라도 남아있던 회사에 대한 애정 자체가 완전히 사라져 버렸다. 암울한 것은 이후 상황은 되려 더 나빠져서 문제들은 해결이 되지 않은 상태에서 '형식적인 문서화', '책임 공방', '정치적인 싸움' 등의 새로운 문제들이 되려 더 추가되고 있다.

이 글을 남기는 이유는 다음 또는 다다음 프로젝트를 내가 직접 진두 지휘를 하게 될 때의 '거울'로 쓸 수 있기를 기대하면서 작성하였다. 결과는 실망스럽고 도중에 많은 문제점들이 도출되어 있는 프로젝트였지만, 덕분에 프로젝트 진행에서 해선 안될 일, 꼭 해야 할 일 등 많은 것들을 배울 수 있는 기회도 되었다(또한 글에서 언급을 하진 않았지만, 개인적으로는 UI 디자인에 대한 치명적인 실수-서비스의 UI는 내가 돌이켜 생각해봐도 쓰레기일 정도로 복잡하고 일관적이지 못하다-에 대해서 반성하는 기회도 되었다). 다만, 똑같은 실수를 미래에 하지 않기만을 다짐하는 수 밖에는 아직은 내가 할 수 있는 일은 없다는 것은 마지막으로 남아있는 아쉬움이다.

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

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 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

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

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

Posted by Irene