gimmesilver's blog

Agbird.egloos.com

포토로그



재밌는 프로젝트를 원하세요? 단상

 제가 경험한 가장 재밌게 수행했던 프로젝트 이야기를 하나 해보겠습니다. 2004년 8월 부터 약 6개월 간 모 이동 통신사 컨텐츠 과금 팀의 과금 검증 프로그램을 개발하게 되었습니다. 정식 프로젝트는 아니었고 직전에 저희 팀이 단말기 서비스 자동 시뮬레이터를 개발했었는데 이를 사용해 본 이통사 과금 팀의 모 차장이 비슷한 컨셉으로 과금 검증을 위한 툴을 만들면 좋겠다 싶어 의뢰한 변칙 프로젝트였습니다(왜 변칙 프로젝트냐 하면 진행은 개발 프로젝트였지만 서류 상으로는 소프트웨어 구매로 처리되었기 때문입니다).

 금액적으로도 작은(1차 구매 6천, 2차 구매 6천~1억 정도) 프로젝트였고 팀장급 중에 여유 인력이 없었기에 제가 해당 프로젝트의 개발 책임을 맡았습니다. 시작은 그리 만만하지 않았습니다. 회사 입장에서는 과금팀을 상대로 한 첫 프로젝트였기에 개인적인 친분을 무기로 삼을 수도 없었고 이동 통신사의 과금팀은 회사 매출에 가장 직접적인 영향을 주는 부서이기 때문에 매우 까칠하다고 소문이 나 있었습니다(물론 그래도 자기들을 무슨 이동 통신계의 델타포스 쯤으로 생각하는 운영팀만큼은 아닙니다). 게다가 저와 같이 프로젝트를 진행하게 된 과금팀 담당자는 나이가 좀 있어 보이는 과장 한 분이었는데 첫 미팅에서 자기는 그리 호락호락한 사람이 아니니까 긴장하라고 대놓고 으름장을 놓더군요.

 그나마 다행이었던 것은 앞서 언급한대로 정식 프로젝트가 아니었기 때문에 정보 요청서(RFI)나 제안 요청서(RFP), 제안서 따위의 형식적인 문서나 절차가 필요 없었다는 점입니다. 대신 두 세차례의 기술 회의 및 담당자 인터뷰로 제품 컨셉을 잡았습니다.  심지어 요구 사항 명세서도 엑셀 파일로 만든 두 세 페이지 짜리 표로 대신했습니다. 

 프로젝트를 시작하고 첫 릴리즈가 나온 건 약 한 달 후 였습니다. 물론 모든게 완성된 버전은 아니었습니다. UI가 다듬어지지도 않았고 기능적으로도 미흡했지만 일단 담당자에게 사용해보도록 한 후 피드백을 받아가며 차츰 완성해나가는 식으로 진행했습니다. 릴리즈는 거의 1~2주에 한 번씩 이뤄졌는데 그 때마다 담당자를 찾아가 새 릴리즈 버전에 대한 피드백을 받았으며 그때마다 요구 사항 명세표의 항목들은 추가/변경/삭제 되곤 했습니다(때론 제가 적극적으로 아이디어를 내기도 했습니다). 예 맞습니다. 실용주의 프로그래머에 나오는 예광탄 기법 및 eXtreme Programming(XP)에서 강조하던 짧은 릴리즈 주기입니다. 

 이렇게 중간 결과물을 계속 확인해가며 프로젝트를 진행하니 장점들이 굉장히 많았습니다. 우선 요구 사항에서 미흡한 부분이나 잘못된 부분은 즉각 수정할 수 있어 요구 사항 명세서가 곧 기능 명세서가 될 수 있었습니다. 게다가 매주 만나 서로 아이디어나 의견을 주고 받게 되니 프로젝트에 애정을 갖게 되고 공감대가 형성될 뿐더러 미팅이 끝난 후 담배 한모금과 함께 주고받는 사적인 대화를 통해 인간적으로도 친해졌습니다. 

 담당자가 프로젝트 내내 프로그램을 사용하고 개발 진행 과정에 대해 명확히 이해를 하게 되니 따로 복잡한 메뉴얼을 만들거나 수백 페이지 짜리 인수 시험 절차서를 만들 필요도 없었습니다. 절차서를 대신한 것은 어느덧 기능 명세서가 되어버린 요구 사항 명세서였습니다. 게다가 담당자가 버그를 발견할 때마다 친절하게 알려주니 전 개발 기간 내내 따로 시간을 내서 테스트를 할 필요도 별로 없었습니다. 테스트와 디버깅이 마치 고객사 담당자와 저 사이에 하나의 게임처럼 진행됐습니다. 심지어 마지막 인수 시험 때는 (역시나 데모의 법칙에 따라) 버그가 하나 발견되었는데 그 쪽 담당자가 웃음을 터뜨리며 "앗싸 버그 발견~" 을 외칠 정도였다면 믿어지십니까?

 심지어 개발 과정도 참 재밌었습니다. 비록 빠른 버그 패치나 잦은 릴리즈를 위해선 일정을 빡빡하게 잡을 수밖에 없었고 그래서 야근을 피할 순 없었지만 그 대신 그만큼 프로그램이 완성되는 모습을 바라보는 보람도 컸습니다. 기능이 하나씩 구현될 때마다 요구 사항 명세표에 나열된 항목들을 하나씩 지워나가는 재미는 꽤 쏠쏠했죠. 저를 포함한 3명이서 개발을 했는데 회사에선 처음으로 페어 프로그래밍을 진행해봤고 동료 한 명은 CppUnit 이라는 툴을 사용해 TDD(Test Driven Development)를 꽤 적극적으로 도입했습니다. 어쨌든 이렇게 프로젝트는 그야말로  80년대 일일 아침 드라마를 연상케 하는 아름다운 모습으로 끝을 맺었습니다.

 그리고 저와 프로젝트 담당자는 그후로 오래오래 행복하게 살았답니다...면 좋겠지만 그건 아니고 아쉽게도 여기에는 극적인 반전이 남아 있습니다. 인수 시험까지 무사히 마친 그 프로그램은 허무하게도 그 직후부터 아무도 사용하지 않는 죽은 소프트웨어가 되고 말았던거죠.
 왜냐구요? 별것 아니고 사실 그 프로그램은 그다지 쓸모없는 프로그램이었거든요...-_-

 물론 그 프로젝트가 처음부터 완전 쓸모없는 프로젝트는 아니었습니다(그랬다면 애초에 시작조차 하지 않았겠죠). 다만 저희는 해당 프로그램의 목적 및 필요성에 대해 지속적으로 논의하고 검증하는 일을 하지 않았습니다. 왜냐하면 우리는 지금도 충분히 재미있었거든요! 

 그런 경험 해보신 적이 있을 겁니다. 명절날 오랜만에 친지와 모여 앉아 담소를 나누며 TV를 볼 때 그다지 웃기지 않은 썰렁한 유머에도 뒤집어지며 정말 재밌게 시간을 보내는 경우 말입니다. 이럴 때면 지금 보는 그 방송이 실제론 그다지 재미가 없더라도 쉽게 채널을 돌리지 못하죠. 지금의 이 즐거운 상황을 혹여나 깨버릴까봐서요(간혹 정말 썰렁한 순간이 찾아와도 우리는 끝까지 입가에 미소를 잃지 않습니다). 그리곤 나중에 이렇게 중얼거리죠. '아 맞다 아까 MBC에서 더 재밌는 영화했었는데...'

 자 이제 저 프로젝트의 가장 큰 문제가 무엇이었는지 감이 오시나요?  이를테면 당시의 저희 프로젝트가 그런 명절날 상황이었던 겁니다. 저와 제 동료들과 그리고 프로젝트 담당자의 가장 큰 실수는 바로 너무 진행과정에서의 재미에 홀딱 빠진 나머지 프로젝트의 목적 자체를 잊어버리고 말았습니다. 아니 알고 있었지만 당시의 그 알흠다운 상황을 깨뜨려버리고 싶지 않았던 나머지 그냥 무시하고 있었던 것입니다. 그래서 점차 프로그램이 쓸모없는 방향으로 개발되고 있는데도 그냥 그렇게 진행해 나갔던 겁니다. 
 그 나이많은 과금팀 과장은 그동안 수 십차례의 지겨운 프로젝트에서 느끼지 못한 재미를 계속 유지하고 싶었을 것이고 전 맨날 '갑'에게 끌려가 '이런 사기꾼들 어쩌구...' 하는 욕을 먹던 지난날의 일상으로 돌아가고 싶지 않았던 것이죠. 그래서 둘 다 그렇게 꿈을 꾸고 있었던 것입니다. 그리고 그렇게 꿈같은 프로젝트를 끝내고 현실로 돌아오고 나니 프로그램의 가치가 비로소 눈에 들어온 거죠...아뿔사 우리 그 동안 뻘짓 했구나...

 물론 프로젝트 진행 자체가 지옥인 경우도 많습니다. 그에 비하면 어쨌든 제가 경험한 저 프로젝트는 성공한 프로젝트라고 할 수 있을지도 모르겠습니다. 하지만 프로젝트란게 결과물이 성공적이어야 정말 성공한 것 아니겠습니까? 그런 의미에서 본다면 어쨌거나 저희 프로젝트는 여타 지옥같은 프로젝트와 다를바 없는 프로젝트였습니다.

 XP스크럼이니 이니 해서 좋은 방법론들이 많이 소개되고 있습니다. 여러 가지 감동적인 성공 사례도 있구요(전 가끔 그런 성공 사례를 읽다보면 무슨 신앙 간증을 보는 착각에 빠진다니깐요). 그런 사례를 간접적으로 접하다 보면 자연스레 자신의 프로젝트에도 적극적으로 활용하고 싶어집니다. 그리고 어떻게 하면 잘 적용할 수 있을까 고민하게 되고 어쩐지 그런 방법론들을 성공적으로 적용하면 곧 프로젝트도 성공할 수 있을 것 같습니다. 하지만 여기서 우리가 조심해야할 점은 바로 성공적으로 방법론을 적용했을 때 갖게 되는 보람이나 재미에 푹 빠진 나머지 혹은 방법론 도입에만 너무 애쓴 나머지 프로젝트의 본질인 결과물에 대해 망각하는 것입니다. 그러기 않기 위해 우리는 언제라도 필요할 때는 용기를 내서 채널을 돌릴 필요가 있습니다.
 어쨌든 우리는 썰렁한 유머를 참고자 모인게 아니라 즐거운 시간을 보내는 것이 목적이니까요!

덧글

  • 2008/08/16 20:18 # 답글 비공개

    비공개 덧글입니다.
댓글 입력 영역