블로그 이미지
Every unexpected event is a path to learning for you.

카테고리

분류 전체보기 (2307)
Unity3D (564)
Programming (470)
Unreal (4)
Gamebryo (56)
Tip & Tech (182)
협업 (34)
3DS Max (3)
Game (12)
Utility (114)
Etc (92)
Link (31)
Portfolio (19)
Subject (90)
iOS,OSX (37)
Android (12)
Linux (5)
잉여 프로젝트 (2)
게임이야기 (1)
Memories (19)
Interest (37)
Thinking (36)
한글 (26)
PaperCraft (5)
Animation (408)
Wallpaper (2)
재테크 (19)
Exercise (3)
나만의 맛집 (2)
냥이 (9)
육아 (5)
Total1,332,123
Today226
Yesterday172
Statistics Graph

달력

« » 2019.10
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

공지사항

태그목록

필자는임베디드 시스템 분야에서의 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

Posted by blueasa

댓글을 달아 주세요