개인 ,커뮤니티 그리고 기업들에서 수 많은 IT 프로젝트가 만들어지고 사라진다. 어떤 것은 일정에 잘 맞추어 성공하기도 하고, 대부분은 일정이 연기되거나 그저 그런 프로젝트로 전락하여 결국 실패의 쓴맛을 보게 된다.
제가 경험한 수 많은 IT 프로젝트 중 불과 20%만이(그것도 대단 ^^) 계획한 목표 일정에 맞춰서 오픈이 되었습니다. 그런 프로젝트의 특징인 2가지더군요. 1. 무조건 강압적으로 일정을 제시하고 못하면 죽는다라고 협박 2. 참여자들이 애정을 가지고 프로젝트에 미쳐서 자발적으로 운영 – 지금 우리가 맡은 대부분의 프로젝트는 1번도, 2번도 아니고… 그냥 물에 술탄듯, 술에 물탄듯 그렇게 하고 있겠죠. -.- by 김지현 페이스북 중
개인적으로는 1번의 프로젝트 진행 방식을 매우 싫어하고 아마 대부분이 그럴 것이다. 2번처럼 동기 유발을 시켜 일정도 맞추고 프로젝트 품질도 성공적이라는 것은 거의 “이상적인 아름다움”과 크게 다르지 않을 것 같다.
이 문제는 그냥 1번이냐 2번이냐 피상적인 해결 방안 중 하나를 고르기 어렵다. 이는 프로젝트 내면에 있는 가장 기본적인 질문을 던져야 하기 때문이다. 이를 이해하기 위해 가장 성공적인 오픈 소스 프로젝트에 하나라고 여겨지는 ‘파이어폭스’의 개발 과정을 한번 살펴보자.
아래 그림은 1998년 부터 2007년까지 Mozilla 버그트래커에 있는 모든 버그를 상태별로 분류해 놓은 것이다. (각 버그는 프로젝트를 완결하기 위한 하나의 기능 및 작업으로 그 상태를 통해 프로젝트의 현재 상태를 가장 잘 파악할 수 있다.)
가장 많은 버그는 바로 DUPLICATE와 FIXED이다. 이는 사용자들이나 개발자들이 하나의 문제를 중복해서 버그 보고를 하게 되는데, 이를 중복 버그로 표시하면서 FIXED를 시키므로 거의 유사한 기울기를 보이게 된다.
NEW라고 표시된 버그는 정말 버그로 확인되는 것 중에 고치지 않은 버그이고, 그중에 ASSIGNED는 버그에 대해 담당자를 정해 준 버그로서 이들은 아직 FIXED되지 못한 버그들이다.
결과를 보면 다음과 같다. 사용자들 대다수는 중복 버그를 신고하게 되고, 그 중에 1/3 정도가 진짜 해야 할 버그라고 인정이 되며, 그 중에 1/6 정도가 담당자가 지정이 된다. (나머지는 그냥 담당자도 없이 그냥 여전히 문제가 있는 상태이다.) FIXED와 DUPLICATE의 차이가 바로 정말 최종적으로 고쳐지는 기능이라고 볼 수 있으며 이 량은 ASSIGNED되는 양이랑 비슷하다.
자! 이는 무엇을 의미할까? 바로 프로젝트의 가장 중요한 부분은 ‘기능 구현 미니멀리즘’이다. 오픈 소스 프로젝트는 요구 사항 분석을 하지 않는다. 그냥 버그를 고칠 뿐이다. 버그는 기능일 수도 있고 꼭 고쳐야 하는 자잘한 문제 일수도 있다. 그 숫자가 전체 버그의 1/6정도다.
대다수 프로젝트가 실패하는 가장 큰 원인은 바로 오버 스펙(Overspec) 때문이다. 일정을 맞추지 못하는 것도 그렇다. 미션 크리티컬한 중요한 기능에 선택과 집중을 하고, 이를 계속 빠르게 출시해서 사용자의 반응에 따라 우선 순위에 따라 꼭 필요한 것만 하는 것. 그게 바로 프로젝트의 성공 요인일 것이다.
“참여자들이 애정을 가지고 프로젝트에 미쳐서 자발적으로 운영하려면”, 쓸데없는 기능은 빼고 정말 애정을 가질만한 기능에 집중했을 때 나오는 결과가 아닐까? 많은 사람들이 이야기 하듯이 프로젝트에서 기능의 뺄셈을 계속해야 그런 선순환이 이루어질 것이다.
프로젝트 성공은 보상도 아니고 문화도 아니고, 그냥 기능 빼기이다. 아깝다고 생각하는 순간 프로젝트는 길어지고 복잡해져 실패하기 쉽다.
