0
0
프로그래밍 : 실력의 부재
회 사가 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는 내가 돌이켜 생각해봐도 쓰레기일 정도로 복잡하고 일관적이지 못하다-에 대해서 반성하는 기회도 되었다). 다만, 똑같은 실수를 미래에 하지 않기만을 다짐하는 수 밖에는 아직은 내가 할 수 있는 일은 없다는 것은 마지막으로 남아있는 아쉬움이다.