오픈 베타 전의 리스크 관리 법 - 프로그래머 편

출처: http://blog.naver.com/testcode/80014736300

오픈 베타 전에 많은 리스크가 있다. 불시의 다운, 알 수 없는 에러... 사람을 잡는 일은 한두가지가 아니지만 시간은 늘 촉박하기 쉽상이다. 게임은 항상 시간과의 싸움이지만 리스크 관리가 중요하다.

 

물론! 프로그래머인 testcode가 추천하는 방법이다.

 

1. cvs나 sourcesafe를 통해서 원격으로 소스를 백업 받으라. 늘 그렇지만 하드는 백업이 없을 때 부숴진다.

 

2. 하루에 한번 릴리즈 버전을 Build All 하라. 빌드가 되지 않는다면 심각한 문제이다. 팀 작업에서 제대로 실행되지 않는 상황을 의외로 몇주 뒤, 몇 달 뒤에 발견할 수 있다.

 

3. cvs를 사용하고 있더라도 소스를 시디로 구워라. 그런데 분명히 해야할 것은 라이브러리까지 백업하라. 가끔 라이브러리를 빼놓고 해서 버전 혼동이 일어나거나 라이브러리를 구할 수 없게 되는 경우가 있따.

 

4. 밤새지 마라. 코딩 퀄리티와 사실상의 일의 능률을 떨어트린다. 밤새서 프로젝트를 한달 이상 단축한 예는 드믈다. 웃기게도 밤새면 그 다음 날 오후나 점심을 기점으로 일어난다. 아크로드 프로그래밍 팀의 경우 주야가 바뀐 생활을 했다 모든 팀이 몇년 이상 그런 생활을 한다면 뭐라하기 힘들지만 낮도깨비 생활은 평균적인 개발 퀄리티를 떨어트린다.

 

5. 시간이 촉박하다면 인터넷을 뽑아라. 네트워크 게임이라면 내부 사설 망만 가동해라. 효율 증가가 일어난다. 하지만 금단 증상은 각오해야 한다. 가끔 오우거로 돌변하는 이가 있고 개발 팀이 점심 시간에 pc 방으로 놀려가는 일도 생긴다. 하지만 효율은 좋아진다.

 

6. 개발 환경 pc를 노턴 고스트와 같은 프로그램으로 저장해 놓아라. 시스템의 말썽이 있으면 언제라도 복구할 수 있게 하라. 운영체제와 개발 환경 셋팅만해도 하루 해가 다 간다. 빌 케이츠가 경쟁 회사의 개발 능률을 떨어트리기 위해 인스톨 시간을 늘렸다는 풍문도 있다.

 

7. 남들이 들어오는 FTP나 와레즈를 운영하지 마라. 해커의 표적이 될 수 있다. 당하면 안다.

 

8. 백신은 사실 시스템을 느리게 만들지만 늘 사용하고 최신 버전을 유지하라.

 

9. 릴리즈 버전을 만들고 나면 백신으로 검사하라. 바이러스를 배포하는 경우도 있는데 무시 못할 경우이다. 심지어 어떤 게임의 경우 바이러스를 배포하기까지 했다.

 

10. 시간이 급할 때는 검증된 소스를 사용하라. 만일 검증되지 않은 소스를 카피하여 사용하면 그 만한 대가를 치룰 것이다. 필자가 만들었던 과거 도스 시절 이미지 패킹 소스의 경우 지금도 돌아다니는데 솔직히 '버그'가 있다 TcPack이라 불리는 이미지 패킹 소스를 가지고 있다면 폐기하라. 100MB 이상의 이미지를 처리한다는 가설 없이 만든 DOS 시절 소스이다.

 

11. 사무실 pc의 게임을 삭제하라. 식후 땡 한판은 평균 30분이다. 점심, 저녁 두 차례만 하면 1시간이 들어가고 1주일이면 7시간이다. 한달이면 무려 30시간을 개발에 투자할 수 있다.

 

12. 하루에 5개 이상의 버그를 잡는 프로그래머는 본적이 없다. 버그가 나타나면 미루지 마라. 어느 게임의 경우 alt + tab이나 윈도우 키만 누르면 다운된다. 나타나는 즉시 잡으면 상관 없었을 텐데 시간을 질질 끌고 추가 개발을 했다. 이 버그는 잘 알듯이 메모리 리스토어 문제인데, 결국 나중에 이걸 수정하는데 상당한 시간을 나중에 투자하는 우를 범했다.

 

13. 소스가 지저분해도 메모리 릭 없고 보틀랙 없이 실행되면 놔둬라. 코드 최적화는 프로젝트가 끝나고 하는 것이다. 솔직히 일본 게임 소스는 지저분의 극치이지만 실행에는 문제가 없다. 게임을 보면서 게임의 재미와 비주얼을 이야기하지 누가 소스의 퀄리티를 이야기하는가? 당신이 만드는 게임은 퀘이크나 둠이 아니다. 카멕과 같은 엔진 개발자를 지원한다면 당신은 프로젝트를 몇 개 말아먹고 지연되어도 상관 없다는 것인가? 엔진은 제품의 마무리 후 정리가 된 상태에서 나오는 것이다. 그 이상도 이하도 아니다. 검증된 게임이 없는 엔진은 누구도 안 산다. 단돈 백 달러라도...

 

14. 남의 엔진이나 모듈 사는 것에 배타적이지 말자. 당신이 사운드 라이브러리를 하나 구현하는데 얼마나 걸리는지를 생각하라. 하루? 이틀? 일주일? 한달? 정답은 평균 2달이상이다. 왜 상용 온라인 게임에서 RAD Game Tools(www.radgametools.com)의 사운드 엔진을 사서 쓰는줄 아는가? 사운드가 먹통이 되거나 노이즈가 나는 현상을 겪게 되면 알게 될 것이다. 블리자드의 프로그래머가 능력이 없는가? 왜 Bink Video로 동영상을 만드는지 알면 될 것이다.

 

15. 오픈 베타나 내부 클로우즈 베타가 당일날 급작스럽게 연기되는 일이 종종 있다. 사실 당일날 연기되는 일은 없다. 이미 개발자 내부에서는 그 사실을 알고 있다. 오픈 베타 십분 전에 완벽한 게임이 릴리즈 되는 건 영화에서나 있는 일이다. 완성된 게임 실행 버전은 인스톨 버전을 만들고 내부 테스트를 거쳐 배포된다. 그 순수한 시간은 하루를 잡아 먹기 충분하다. 최소 1주일 전에 제대로 게임이 실행되지 않는다면 출시는 불가능하다. 평균적으로 말하면 3주 전에 제대로 돌지 않으면 클베던 오픈 베타던 성공적일 수 없다.

 

16. 빌어먹을 사항이지만 로컬 파이어월과 서버 사이드 파이어월을 셋팅하여 사용하라. 이 것 역시 클라이언트 프로그래머의 업무를 가중 시키는 놈인데, 해킹 당하는 것보다 낫지 않은가? 당하고 나서 처리하면 뒤처리가 더 걸린다.

 

17. 게임 판에는 잘난 놈들이 무지 많다. 너무 잘나서 놀랄 지경이다. 그런데 회의록을 정리하지 않는 인간과 오늘 내가 무슨 일을 할지를 모르는 인간(to-do-list)은 쓰레기다. 머리 좋고 코딩 실력도 좋겠지만 결국은 머리 믿다가 프로젝트 망칠 인간이다.

 

18. 게임 기획서 하나 제대로 만들어 놓지 못한 기획자와 일하지 마라. 기획문서는 항상 추가될 수 있지만 버전 관리도 안되는 예가 허다하다. 개발하다보면 참조해야 하는 문서들이 집체만하게 나온다. 인쇄된 기획서도 어제 버전과 오늘 버전이 어떻게 다른지 모른다. 효율적인 기획자는 기획 문서를 배포하면서 구 버전 문서를 자신이 모두 폐기한다. (조선의 형법은 그렇게 처리되었다고 한다. 관리들이 낮익은 구버전의 형법으로 처리할까봐 구버전의 법은 신법전이 나올 때 태웠다고 한다.)

 

19. to - do - list를 가지고 하루 이틀 일정을 관리하라. 프로그래머는 우선 순위 설정을 잘 못한다. 평균적으로 쉬운 일을 먼저하고 어려운 일은 뒤로 미룬다. 그래서 작업을 나눌 때 필자는 이렇게 한다.

 

작업명 - 설명 - 작업 난이도 - 우선 순위 - 구현 우선 순위 - 필요 기술

 

설명을 안해도 알겠지만 작업에 대한 명칭은 공개적인 부분이고 설명은 그래도 필요하다. 작업 난이도는 본인이 평가하면 된다. 우선 순위는 담당 PM이 설정하는 것이다. 구현 우선 순위는 기획자가 평가하는 내용이다. 프로그래머는 필요 기술을 솔직하게 기록한다. <초절정 노가다> <픽셀 쉐이딩으로 화면 효과의 구현, 아직 한 적 없음> 앞의 필요 기술과 뒤의 필요 기술은 다르기 때문에 작업 리스크를 평가하기 좋다.

 

버그 로그 시스템 개발 - 하 - 최종 개발 낮음 - 상(도저히 버그를 못 잡겠어요) - <로그를 남기는 클래스와 기존 코드에서 충돌이 날 때 덤프를 뜰 수 있는 모듈이 필요함, 아직 안해봄>

 

이런 to - do - list라면 프로그래머의 입장, PM의 입장, 기획자의 입장, 기술의 레벨을 입체적으로 조망할 수 있다.

 

20. 남의 코드가 이상하더라도 실행이 되면 수정하지 마라. 마치 코카콜라와 바닐라 라떼를 섞어서 먹는 것처럼 알 수 없는 결과가 나타날 수 있다. 돌면 놔둬라. 프로그래머가 수정하는 이유는 웬지 그 일은 결과물이 나와있고 마무리하면 뭔가 이쁘게 나올 것 같기 때문이다. 더구나 자신의 코드와 다른 이질적인 문법과 논리, 사유를 제거하는 배타적인 마음이 있기 때문이다. 늘 그렇지만 남의 코드는 항상 보기 힘들고 더럽다. 내 코드는 안 그렇지만...

[출처] 오픈 베타 전의 리스크 관리 법 - 프로그래머 편|작성자 컴맹고양