CUBRID 2008 R1.3이 이번 주에 릴리스되었다. 메이저 버전 릴리스도 아닌데 뭐 그리 힘들까 하고 생각할 수도 있지만, 메이저든 마이너든 릴리스는 릴리스이기 때문에 준비할 것은 비슷할 것이라고 생각하고 분량의 차이만 있을 것으로 본다. 사실 난 아직 CUBRID의 메이저 릴리스를 해 본 적이 없다. ^^
CUBRID 2008 R1.2의 릴리스 후기를 쓰고 난 직후, 난 릴리스 노트의 후폭풍을 맞고 쓰러졌었다. 팀장님이 R1.2의 릴리스 노트를 별로 챙기지를 않는다는 느낌을 받았기 때문에, R1.2의 릴리스 노트 작성은 연습이고 본 판은 유경험자인 팀장님이 작성하실 것이라는 안일한 생각을 했기 때문이다. 난 수련 과정이라는 생각이 컸지 않았을까 싶다. 내가 어리버리 하고 있으면 팀장님이 일필휘지로 후다닥 써서 “릴리스 노트는 이렇게 쓰는 거야” 하면서 주실 것만 같았다. 거짓말 하나도 안 보태고 바이너리를 먼저 릴리스하고 릴리스 노트는 토요일 하루 종일 작업해서 마무리하였다. 지금 생각해보면 왜 그리 철없는 생각을 한 것인지 모르겠다.
결론적으로 내겐 R1.2 릴리스는 1월 17일이었다. 사용자들은 1월 16일부터 파일을 받기 시작했을텐데… 어찌보면 1월 17일에 릴리스 노트가 나간 것은 PM으로서 창피한 사건이었다. 만약 바이너리 파일도 같이 늦게 릴리스되었다면 팀 전체가 창피하지 않았을까? 내 릴리스가 늦었기 때문에 다음 릴리스에서 일찍 시작해야 할 것들이 머릿속에 각인되었다.
릴리스하자마자 CUBRID 오픈 소스 프로젝트에서 코드 리뷰 프로세스를 도입하는 것을 준비하여야 했고, 긴 설날과 CUBRID Inside를 준비하고 참석해야 하는 일들이 날 기다리고 있었다. 코드 리뷰 프로세스를 만드는 것은 아직 개발 프로세스에 익숙하지 않은 초보 PM에게는 큰 부담이었고 작문 실력이 뛰어나지 않다는 핸디캡까지 한 번에 극복해야 했다. 막상 릴리스를 준비하면 잡념없이 일할 수 있지만, 릴리스 준비 기간이 되기 직전엔 불과 2주전의 악몽이 계속 떠올라서 CUBRID Inside를 한 다음 날부터 마음이 무거웠다.
사실 매뉴얼의 어려운 일들은 이미 설날이 되기 전에 처리했고 남은 내용들은 매뉴얼의 내용 보강과 문구, 포맷 수정 같은 것이었다. 첫 릴리스에는 손에 익지 않은 프로세스와 매뉴얼에 치중하였는데, 이번 릴리스에는 앞에서 좀 고생을 해서 그런지 크게 프로세스나 매뉴얼에 대해선 걱정되지 않았었다. 매뉴얼을 볼 때마다 내용을 좀 많이 고쳤으면 하는 욕심이 계속 들었다. 매뉴얼을 한 판 정리하고 나서 블로깅 하는 날이 빨리 와야 할텐데…
역시 지난 릴리스에서 고생을 해서인지 이번엔 릴리스 노트에 가장 많은 시간을 투입한 것 같다. 릴리스 1주일 전부터 이슈 트래커에서 해결된 이슈를 계속 쫓아다녔다. 1건이 해결될 때마다 실제 증상을 묻고, 대략적인 설명을 개발자를 귀찮게 하면서 배웠다. 모르는 곳을 가려면 대략의 길이 떠오를 때까지 물어볼 수 밖에 없는 것 아닌가? 내가 아무리 초보 PM이라지만 생각이 있고 원하는 방향이 있는데, 개발자들이 만들어온 초안이 마음에 들 리가 없다. 역시 난 까탈스런 사람인가? 아니면 포매팅이 안 된 그냥 텍스트라서 그런 겐가? 개발자들을 괴롭혀서 초안을 적고 초안을 개발자들에게 다시 검사 받기를 매일 하였다. 또 1주일 동안 작업한 것을 CUBRID 대표 사용자들에게 보여주고 내용 검토를 하였다. 그 뒤로 팀장님의 몇 번의 검수를 거쳤다. ^^ 이쯤되니 내 스스로 만족감이 들었다. 게다가 릴리스 노트의 끝이 보이는 듯했다.
이번엔 수정된 내용이 적어서 그런지, 아니면 릴리스 노트 작성에 시간을 많이 들여서 그런지 릴리스 직전까지 몰려서 릴리스 노트를 작성하는 사고가 재발되지 않았다. 그리고 무엇보다도 접대성 칭찬 한마디에 릴리스 노트를 더 잘 쓰고 싶다는 충동이 불끈 솟았다. 칭찬은 고래도 춤추게 하고 Invisible Employee인 게 틀림이 없다.
PM의 업무 중에서 가장 중요한 스펙 작성이 아직까지 자리를 잡지 못하고 있다. 스펙을 정확하게 작성해서 들을 칭찬이 남은 것 같다. 이 칭찬을 들으려면 지금보다 더 많은 고민을 담아야 하지 않을까 싶다.
