필자는, 임베디드 시스템 분야에서의 10여 년 간 개발자로 일하였으며, 개발 프로세스 개선 활동을 해 왔다.(소속 프로젝트의 SW-CMM Lv.2 달성 및 Panasonic Software Forum 2008에서 해외DC 대표로 사례 발표) 지금은, 게임 개발사의 품질보증부서의 프로세스 개선 파트에 근무 중이다.
게임 개발사에 입사한 직후 몸소 느낀 자유 분방한 분위기는 쇼크였다. 게임 개발사는 엔터테인먼트사업이라는 간판 아래 개인의 자유와 창의성을 중시하였다. 프로젝트 관리, 게임 디자인, 소프트웨어 개발, 아트 등의 분야가 집결되어 50여명이 넘는 개발 인력이 3년 이상의 개발 기간을 갖고 진행하는 게임 개발은, 프로젝트의 규모가 거대했다.
하지만, 필자가 1년 넘게 개발 프로세스 개선 활동을 느낀 점을 한 마디로 표현하면, '아쉽다' 였다. 이 말은, 개발 프로젝트(게임)의 성공 여부와 관계 없이 안타깝다라는 말이다. 더 쉽게 얘기하겠다. 개발비가 줄줄 센다는 것이다.
대규모의 개발조직에서, 10명 내외의 인원만이 게임 서버와 클라이언트의 개발을 담당한다. 종합 엔터테인먼트 제작 조직의 10여명이 IT개발자라는 얘기다. 10여명의 개발자의 손에서 만들어지는 제품(게임)은, 컨텐츠의 양과 스케일에 비해서 영세적인 것이 일반적이다. 일반적인 벤처기업의 프로젝트 개발 조직의 규모와 비슷하고, 개발 성숙도 또한, 1인 중심적인 체제이다. 카네기 멜론 대학에서 창안한 개발 성숙도 레벨을 빌어서 표현하자면, CMM Lv.1에 해당할 것이다. 모든 개발 노하우는 개발자의 머리 속에 있으며, 소스코드, 설계문서, 요구사항의 이력 및 변경점의 관리가 되고 있지 않다. 그로 인해, 핵심 개발자가 전직을 하거나, 불의의 사정으로 조직에서 이탈할 경우, 이를 매울 수 있는 조직의 프로세스가 준비되어 있지 않는 것이다. 신규 프로젝트를 준비함에 있어서도, 재활용 가능한 개발 자원이 없음으로 인해, 맨 땅에 헤딩을 하는 상황도 발생하게 된다.
이에 필자는 다음의 해결책을 제안한다.
"개발방법론? 스크럼? 기본에 충실하자"
많은 개발 조직이, 저명한 외부의 개발방법론을 적용하고 있다. NC소프트의 모 개발팀도 스크럼의 변형 적용을 하여 효과를 봤다는 얘기도 있다. 스크럼과 같은 익스트림 프로그래밍 류의 개발방법론은, 불필요한 문서화를 없애고, 여러 번의 반복(iteration)을 통해서 항시 실행 가능한 버전을 보완해나가는 방법이다. 작은 스프린터를 뛰면서 백로그를 활용함으로써 설계 변화에 재빠르게 대응할 수 있는 이 방법들은, 한 순간에 설계(게임 디자인)이 확 뒤 엎어 지기도 하는 기도 하는 게임 개발에 알맞을 것이다. 하지만, 여기서 간과되는 것이 있다. 필수 불가결의 문서는 반드시 작성하고 관리해야 하며, 소스코드 리뷰 및 모든 문제점의 관리되어야 한다는 것이다. 그리고, 모든 것은 조직의 프로세스라는 전제가 필요하다는 것이다.
(1) 조직 프로세스의 정의 및 적용
업무를 진행함에 있어서, 어떤 표준을 따르며, 단계 별로 필요한 행위 및 산출물을 정의하는 것을 말한다. 명확한 조직의 프로세스는, 구성원 개개인이, 자신의 지금 어떤 위치에서 어떤 업무를 해야 하는지를 상시 파악하고 인지할 수 있게 도와준다.
(2) 문서화
시스템 아키텍쳐, 게임 서버-클라이언트의 설계서, 기능 설계서, 버그 대응서, 리뷰/회의록, 요구사항 관리서 등이, 소프트웨어 개발자로써 반드시 작성을 해야 하는 필수 문서이다. 모든 문서는 최신 상황으로 갱신되고 이력이 관리되어야 한다. 간혹, 간단한 버그를 대응하는 경우, 담당자 만이 이해할 수 있는 단순한 수치 조절을 했다고 하자, 당사자가 아닌 다른 멤버가 관련 부분과 연관된 기능 개선을 하는 경우, 소스코드 만으로 시스템 구조를 파악해야 하는 난감하고 짜증나는 상황이 발생한다. 자신의 머리 속에 있는 지식을 모두 문서화할 수는 없겠지만, 구현된 시스템의 소스코드를 보다 값진 개발자원으로 만들고 활용하기 위해서는 문서화가 반드시 필요하다. 문서화가 되지 않는 소스코드는 자칫 아무짝에도 쓸모 없게 될 수 있다.
(3) 소스코드의 변경 관리
형상관리. 왜 갑자기 이 단어를 꺼냈는지 알 사람은 알 것이다. 많은 개발자들이 Visual Source Safe, SVN, CVS등의 형상관리 툴을 통해서 소스코드를 관리한다. 멤버가 수정한 파일, 변경 내용 등이 이 형상관리 툴을 통해서 알 수 있다. 하지만 요점은 단지 '알 수 있다'라는 것이다. 특정 부분(예를 들어, 게임 클라이언트로부터 수신한 네트워크 패킷의 파싱 처리를 하는 부분)의 변경 의도 및, 최적화 되어 있는 소스코드의 이력을 파악하려면, 각 리비전 마다의 변경 내용을 하나하나 체크하면서, 때로는 수정 후 원복 되는 부분과, 관련 수정 부분의 모든 소스코드를 하나하나 찾아가야 할 것이다. 대응을 했던 당사자라면 모를까, 제3자가 이런 작업을 하려면 많은 공수가 필요하다.
한 마디로 정리하겠다. 형상관리 툴은 단순히 버전을 관리하기 위한 툴이다. 파일의 변경 내용 비교 및 커멘트는 보너스이며 제한적으로 제공되는 것이다. 특정 시점의 버전을 취득하고, 때로는 버전의 롤백과 브랜치 관리를 한다. 소스코드의 변경점은, 소스코드 자체로 해야 한다. 한번 추가한 소스코드는 #ifdef 등으로 무효화는 할 수 있으나 절대로 삭제할 수 없다. 잘못된 소스코드도 소중한 이력이다. 변경된 소스코드는, 조직 프로세스에서 규정된 일정 표준에 의해서 누가, 언제, 왜, 어떤 문제점으로 인해서 수정을 했는가를 명기 해야 한다. 해당 수정 부분과 Problem List가 연계되면 더 없이 좋다.
(4) 변화 관리
변화관리는, 소스코드의 변경관리하고는 다른 말이다. 어떠한 수정을 함에 있어서, 그에 영향을 받는 부분을 사전에 분석해서 확인 및 관리를 하는 것을 말한다. 변화관리의 가장 쉬운 적용 예로, 대응 내용의 리뷰 시 파급 범위를 한정하고 확인하는 방법이 있다. 자신 외의 멤버에 의한 동료리뷰에서, 미처 발견 치 못한 사항을 부작용을 발견하기도 한다.
(5) Problem List
제품의 버그를 관리하는 Problem List로써, BTS(Bug Tracking System)의 사용이 정착화 되었다. 여러분은 BTS를 통해서, 버그를 등록하고 폐쇄까지를 관리하고 있다. 하지만, 이것은 제한적인 활용이다. 시스템 설계를 리뷰 할 때, 대응된 소스코드를 리뷰 할 때, 버그 대응서를 리뷰 할 때 발생한 지적 사항 또한, 발생부터 폐쇄까지 누락 없이 관리를 해야 한다. 이른바 리뷰 지적 사항이 그것이다. 이에, 개발과 관련된 모든 이슈를 Problem List에 등록하여 관리하는 적을 추천한다. BTS라는 이름에 얽매이지 말고 활용하자.
이상, 게임 개발 조직의 소프트웨어 개발자가 지켜야 하는 기본 사항들을 설명하였다.
이 다섯 가지 사항의 준수가 도저히 불가능하다고 어렵게 느껴진다면, 여러분은 너무 편하게 개발에 임했다고 말할 수 있다. 지금 여러분이 여러분의 조직의 개발활동이 편할 지라도, 후임자, 후임프로젝트, 조직, 회사는 그로 인해 공수를 할애하고 개발비를 쏟아 붇게 되는 것이다. 여러분이 개발한 자원은 다른 프로젝트에 도움을 주지 못하고 그 자체로써 똥이 될 수도 있다.
"나는 창의적인 게임 개발자니까, 자원의 재활용, 프로세스, 그런 거 신경 쓰지 않고 내 방식대로 할거야"라고 생각한다면 어쩔 수 없지만, 개발자로써 개발 프로세스의 적용 및 개선 활동을 리드 하였으며 그로 인해서 개선사항을 경험한 필자의 제안을 귀담아 들어 줬으면 한다.
게임 개발사의 소프트웨어 개발자 여러분, 여러분은 엔터테인먼트의 제작자가 아니다. 개발자로서 지킬 것을 지키자.
Actoz Soft Co., Ltd. > Quality Assurance > Process Improvement 김남훈
출처 : http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNo=28&no=246
일전에 Dependency에 대한 고찰이라는 글로, Dependency의 종류와 xDepend 툴들을 소개한 적이 있습니다.
IoC를 이용하여 좀더 변화에 유연하며 확장 가능한 소스코드가 생성되었습니다.)
