개발을 확실하게 파탄 내는 세 가지 방법

게임 크리에이터가 알아야 할 97가지 Part.2 - 두 번째 이야기

by - 中林寿文 (나카바야시 히사후미)
1974년생으로 1999년에 싸이 버즈 주식회사를 창업했다. 커뮤니티 서비스 운영과 컨설팅, 온라인 게임, 소셜 게임 개발 지원을 하고 있다. 일을 하며 대학원을 다녔고 석사(공학)를 수료했다. 2012년 12월에 IGDA JAPAN이 NPO법인화에 따라 부이사장으로 취임했다. 후쿠시마 GameJam T/F 고문으로 활동하고 있다.

게임에 온라인 요소가 더해진 지 이미 많은 세월이 흘렀고, 세간의 관심도 PC에서 스마트폰과 같은 모바일 기기로 옮겨가고 있다. 필자의 본업인 커뮤니티 서비스가 온라인 게임과 친화성이 높아서 PC뿐만 아니라 피처폰, 스마트폰, 브라우저 등 다양한 플랫폼에서 온라인 게임의 구축과 개발에 참여해 왔다. 또, 유연함이 요구되는 게임과는 얼핏 정반대라 생각되는 엔터프라이즈 시스템의 설계, 구축 경험도 있어서인지, 최근에는 릴리스 직전이나 납품 예정일이 지난 이른바 '파탄 프로젝트'의 소방수 역할을 부탁받는 일도 자주 있다. 이러한 파탄 현장에서 공통으로 보이는 파탄 원인에 관해 설명하려 한다.

원인 1: 인간은 실수하는 동물이라는 원칙을 잊고 있다.
PC용이든, 모바일이든, 컨슈머 게임기든 모든 종류의 디지털 게임이 소프트웨어로 구현된다는 사실에는 변함이 없다. 또, 그 모든 것은 인간이 설계하고, 코딩도 한다는 사실도 변함이 없다. 인간은 망각의 동물이라 메모를 하는데, 이것은 시스템 개발로 빗대어 설명하면 설계서와 같은 문서에 해당한다. 그리고 인간은 자주 실수를 하는 동물이라 만에 하나 틀리더라도 최악의 사태가 일어나지 않도록 예방조치를 취하게 된다. 그것을 프로그래밍에 빗대어 설명하면 테스트라고 할 수 있다. 함수에 전달되는 파라미터의 타당성을 체크하고, 부정한 값이 전달되면 에러로 처리하고, 이를 통해 불량을 조기 발견할 수 있도록 하는 것에 해당한다.

소방수로 프로젝트에 불을 끄기 위해 투입되어 코드 리뷰를 해보면, 대부분 문서는 초기의 기획서 정도밖에 없고 "설명서 = 소스 코드"인 상황이다. 그 소스코드라는 것도 주석과 테스트 코드가 불충분해서 애초에 기대하고 있던 동작이 무엇인지 추측하기조차 쉽지 않다. 개발자끼리 공유할 수 있는, 즉 공통 인식의 토대가 되는 문서가 없는 것이 인식 차이와 오류 확대의 원인일 때가 많다.

원인 2: 방법론에 현혹되어 있다.
소프트웨어 공학은 역사가 깊은 분야이지만 게임 개발 현장에서는 최근에 이르러서야 다루어지게 되었다. 최근 들어 가장 자주 듣는 키워드는 애자일이다. 애자일 소프트웨어 개발 기법은 1~4주 정도의 비교적 짧은 기간에, 계획, 요구 분석, 설계, 구현, 문서화라는 공정을 반복하는 것이 특징이다. 그리고 1988년경에는 설계에서 프로토타입까지 6개월에서 2년 정도로 반복 실시하는 스파이럴 모델이라고 하는 개발 기법이 제창되었다. 또, 소프트웨어 개발뿐만 아니라 프로젝트 관리의 일반적인 기법으로 Plan(계획)/Do(실행)/Check(평가)/Act(개선)를 반복적으로 실시하는 "PDCA 사이클"도 있다. 이 방법론은 모두 "설계/계획→코딩/실시→개선"을 반복한다는 본질적인 특징이 공통적일 뿐만 아니라, 개발 분야에선 지극히 당연하게 이루어지는 공정이다. 방법론은 어디까지나 수단으로써 베스트 프랙티스의 하나일 뿐 방법론이 정의됨으로써 그 목적이 최적화되는 만능이 아님에도 프로젝트 관리, 설계 방법 등 다양한 국면에서 하나의 방법론에만 너무 집착하는 경향이 있다.

원인 3: 왜 해야 하는지 목적을 공유하지 않는다.
소프트웨어를 제품이라는 측면에서 보면 스케줄, 매출, 예산 등 달성해야 할 목표가 있다. 대부분 그 목표 달성에 필요한 배경을 가진 멤버로 팀이 구성되지만, 개발이 진행되면 진행될수록 각자의 전문성이 높은 국소적인 부분에 집중한 나머지 국소 최적화에 빠지기 쉽다. 팀으로서의 목적과 이를 위해 각각이 무엇을 하고 있는지 항상 강하게 인식이 공유되지 않으면 과도한 국소 최적화를 초래하고 사양 개선의 경직화 혹은 과도한 변경이나 스케줄 지연 등 프로젝트 완료에서 멀어지는 경우가 많다.

이처럼 무엇을 위해 일하는지 항상 목적을 공유하고, 공유를 확실히 하기 위해 문서를 만들고, 그리고 목적을 달성하기 위한 최적의 방법을 선택하는 유연함을 가지기 위해 노력하지 않으면 개발은 확실하게 파탄에 이르게 된다.