0. 잡소리
제목을 포스트모템이라고 해놓고 보니 뭔가 거창해보이네요(...) 실은 저 단어가 생각이 안 나서 영어 사전까지 뒤져봤어요. ('부검'이라는 의미는 어러케 알고 있던거지?!)
일단은 제가 지난 2년간 몸담았던 프로젝트를 주제로 삼습니다만, 게임의 내용에 대해서 보다는 프로젝트 매니징에 대해 다뤄보려고 해요. 그게 제 역할이기도 했고요.

1. 기록 - History
때는 2005년 8월초, 프로젝트를 함께 시작한 멤버들은 모두 릴(http://rylonline.com/) 개발부터 라이브까지 산전수전 다 겪은 친구들이었고, 무엇보다 '기록을 남기는게 중요하다!'라는 공통된 주장을 하고 있었지요. '어떻게 하는게 좋을까?'
그 와중에 발견한 웹 프로그램이 있었으니... Trac!!! (http://trac.edgewall.org/)
위키 + 버그트래킹 시스템에 svn과도 연동이 되다니... 이런 킹왕짱 프로그램을 봤나!

하지만 이 녀석을 사용하기까지는 약간의 진통이 있었어요. 우선은 처음 써보는 시스템이다보니 팀원들이 적응하는데까지 시간이 제법 걸렸고, 특히 그림 그리는 아찌들이 위키로 뭔가 작성하는 걸 엄청 부담스러워 한다는거...

그래서 이쁜 오구라 유코도 친근감있는 로고도 달아보고, 위키 페이지에 간단히 코멘트를 달 수 있게끔 매크로(애드온)도 만들어 보았습니다.

또 티켓 페이지가 한 눈에 들어오지 않는다는 의견에 레이아웃도 손보고, 이미지도 올리기 쉽게끔 매크로를 제작해보았지요.

손수 한글 번역도 했었는데, 나중에는 저보다 더 잘 해주신 분(http://kldp.net/projects/trac-ko/)이 계셔서 감사히 사용했습니다(...) 이런 정성이 있었기에, 지금은 신입 팀원도 편하고 빠르게 우리 시스템에 녹아들 수 있게 된게 아닌가 생각해 봅니다.

제가 화이트 보드를 관리 시스템에 채용하지 않는 가장 큰 이유는 히스토리의 중요성을 여러번 뼈저리게 느꼈기 때문입니다. '나중에 문서로 옮기면 되지 않느냐?'라는 반론에 전 '중간에 누군가 어떤 내용을 지운 행동마저도 중요하다.'라고 답변해주고 싶습니다. 그리고 추후에 누구라도 손쉽게 이 기록에서 원하는 내용을 찾아낼 수 있게끔 해주는 것이 더욱 중요하겠고요.

2. PM의 역할?
프로젝트 초창기부터 지금까지 저는 꾸준히 삼권분립(...)을 주창해 왔습니다. 각각 프로듀서(Producer), 프로젝트 매니져(Project Manager), 디렉터(Director)라는 직책이 되겠는데요. 그 역할은 아래와 같습니다.

• 프로듀서 : 얼굴 마담입니다. 팀 외부 세력(?)과의 포트 역할이 됩니다. XP에서 언급되는 '고객'이기고 하고, SCRUM에서의 '닭'과도 흡사하네요.
• 프로젝트 매니져 : 프로젝트 진행이 막힘없이 되도록 윤활유 역할이 되어줍니다. 스케줄을 총책임집니다. SCRUM에서의 Scrum master와 비슷한 역할인 듯 합니다.
• 디렉터 : 컨텐츠의 퀄리티를 책임지고, 각 모듈 간의 우선 순위를 결정합니다. 즉, SCRUM에서의 Product owner 역할을 일부 수행합니다.

다른 분들이 사용하는 의미와는 좀 다를 수도 있겠습니다만, 마땅한 용어가 없으니 저는 이렇게 정의내려 봤습니다. 디렉터를 좀 세분화해서 아트 디렉터(그래픽 아티스트)와 테크니컬 리더(프로그래머)가 추가되서 오권분립(...)도 그럴싸.

전 PM으로서 무엇보다 팀원들이 작업을 하는데 불편함이 없도록 하는데 최우선 가치를 두었습니다. 업무적으로는 앞서 밝힌 바와 같은 시스템외에도 일일 빌드 및 테스트, 백업 자동화 시스템을 구축(python, 쉘 스크립트 이용)하였고, 이를 Trac에서 매일 확인할 수 있게끔 하였습니다. 그리고 맥스 스크립트를 잘 다루는 '테크니컬 아티스트'의 충원을 매우 원했는데, 오늘 이시간까지도 성취하지는 못했습니다...llorz

업무 배정에 있어서도 모듈의 우선 순위 내에서 각 개인이 원하는 일을 할 수 있게끔 배려하였습니다. (사기충전에 도움이 되고, 보다 정확한 일정이 나옵니다.) 그리고 이건 작은 팀이었기에 가능한 일이었을 수도 있지만, 각 분야의 팀장을 따로 두지 않고 모든 팀원의 스케줄을 직접 관리하였고, 공유할 수 있도록 노력하였습니다. 무엇보다 팀원 각자가, 옆 사람이 지금 뭘 하고 있는가를 손쉽게 파악할 수 있게 하는 것이 중요했다고 생각합니다.
Trac의 티켓 시스템을 버그 트래킹만이 아닌 작업일지의 용도로도 사용하였는데, 각자 매일 업데이트하고 다른 이들이 이를 손쉽게 볼 수 있음으로서 서로간의 삽집도 방지할 수 있었고요. (불필요한 작업을 하고 있을 때 빠르게 캐치할 수 있지요.) 요즘 괜히 애자일 방법론에서 의사소통의 중요함을 강조하고 있는게 아니지요.

또한, 주간/월간으로 각 팀원간의 진척 사항과 이후의 할 일을 기록으로 남겨 공유하였습니다. 매주 금요일에 검토 시간을 가졌는데, 이 때는 제가 초안을 작성 후 각 팀원들의 자리를 돌면서 개인 면담을 가지면서 수정해나가는 형태였습니다. 그렇게 정리된 안에 디렉터와 프로듀서의 의견을 받아 다음 작업들의 우선 순위가 재정리되고 분배되었지요. 월간 검토 회의는 모두 모여서 이야기하는 형태였습니다. 하고보니 일종의 '스프린트 검토 회의'였는데, 지금 생각해보면 주간 검토 시간에도 짧게라도 모두 모여서 이야기하는 형태가 되었다면 압박을 주는 면에서(...) 괜찮지 않았을까 생각됩니다. 제가 좀 만만해서 아무래도 느슨해지는 감이 있더군요.

3. 그래서...
그래서 이 프로젝트는 어떻게 되어가고 있을까요? 아직은 뭐라고 평할 수 없는 ing 상태입니다만, 프로젝트만 놓고 봐서는 팀원들 모두 즐겁게 일하고 고객 만족도를 높이면서 조금은 느리게(...) 진행중입니다. 뭐 여튼, 거창하게 포스트모템을 작성하기에는 이른 시기이지요.
하지만 요즘 화두가 되고 있는 SCRUM이라는 녀석과 제가 진행해온 방식에 일맥상통하는 부분이 많다고 느껴져 사례 보고의 일종으로 글을 작성해보고 싶었습니다. 또 이를 바탕으로 다시금 돌아볼 수 있는 계기도 되고요.

* 좀 다른 이야기
지난주 kgc2007에 참석해서 애자일에 대한 이런저런 이야기를 들으면서 느낀바가 많았습니다. 남기룡님(http://mypage.sarang.net/tt/)이 보여주신 화이트보드의 일정판을 보니, 그걸 웹프로그램으로 옮긴 형태가 떠올랐고요. (Trac도 로드맵과 리포트 기능을 잘 커스터마이징하면 될 듯 하지만, 아무래도 한 눈에 들어오지는 않지요. 요건 나중에 따로 기획안을 포스팅해보고 싶네요.) 김창준님(http://agile.egloos.com/)이 언급하신 'Hourly Scrum'도 신선했고요. 긴장감 유지에 좋을 듯 하네요. (우리 팀은 아무래도 이게 좀 부족...) 박일님(http://parkpd.egloos.com/)의 TDD 강의도 즐거웠습니다. 글로만 봤을때는 두리뭉실했던 mock 객체, 저희 팀에 정말 필요한 것이었고 확실히 입력되었습니다.