기획자 vs. 개발자

늑대와 양만큼이나 서로 으르렁 거리는 관계가 있다면 바로 기획자와 개발자이다. 개발자 출신의 기획자나 기획자 출신의 개발자가 도움은 되지 못한다. 언제나 상황은 한쪽에 서게 만들기 때문이다.

요즘은 오픈소스조차 빌어먹을 상용 소프트웨어를 박살낼 획기적인 기능을 내포하길 원한다. 그리고 발표시기도 상당히 정치적이다. 자선단체도 이윤을 내야 영속할 수 있는 상황인 것이다. 경쟁중인 분야의 소프트웨어는 신기능이 빠른 시간 안에 나와야 하고 그것이 상대를 압도할 정도로 획기적이어야 한다. 개인적으로는 그냥 영리업체가 돈 펑펑 쓰면서 개발해 낸 기능을 낼름 카피하는게 더 효과적일 것이라고 생각하지만....

아무튼 이런 상황에서 기획자가 쉽게 하는 실수는 너무나 강력하고 획기적인 기획을 내어 놓아 기존 버전의 프로그램이 가지고 있던 기능과 충돌하게 만드는 것이다. 그리고 자신의 능력을 검증해야 하는 듀가 있기 때문에, 뭐 기업체의 경우 연봉협상 전이나 분기 평가를 압두고일 것이고 비영리 단체라 하더라도 알력같은 것이 아니더라도 순전히 타오른 전투 열의에 너무 앞서 나가게 되는 것이다. 사실 신 기능이라는 것이 기존에 생각을 하지 못했던 거이니 당연히 시스템 설계에 영향을 주는 것은 당연하지만 기존 기능과 반대거나 해치거나 시스템 전체를 새로 만들어야 하는 경우를 만들기도 한다. 그러면서 듀는 꼭 분기나 경쟁업체 발표일 전날로 맞춘다.

이런 상황에서 개발자는 크게 두가지 방향으로 대응한다. 배를 째거나 날밤을 까거나.
우선 새로운 기능을 넣기 위해서는 시스템을 새로 만들어야 한다거나 개발자가 100명쯤 필요하다고 일단 뻥카를 날린다. 그러다가 저 위에서 호통이 내려오면, 아니면 아예 처음부터 힘이 없던 조직이라 되든 안되든 작업을 시작하고 본다. 영업사원 2~30명을 가졌으나 개발인원 5명의 조직 구조에선 후자쪽이 보통 발생한다. 날밤을 까서 어떻게든 기능이 동작하게는 만들었다. 당장의 매출은 일어난다. 영업사원이나 기획은 실적을 올리고 이윽고 불어닥치는 버그의 홍수는 개발자들이 당한다. 개발자들이 모여서 술을 마시고는 개발 새발 뒹군다. 그리고 다음 기획이 도착하면 배를 째기 시작한다.

Software Engineering에서 일정한 목표를 세우고 처음 개발되는 프로그램에 대한 개발 방법론에 대해서는 Water Fall 모델을 세워서 아주 강력하게 수행할 수 있는 방법을 제시하고 있다. 물론 완벽하지는 않지만 돈만 부어낸다면 원자력 발전소는 상당히 수준높은 완성도로 프로그램을 완성해 낼 수 있다. 하지만 이것이 계속 신기능을 첨가하는 순환구조를 가지게 되면 마땅히 할말이 사라지곤 한다. 기능성이 변경되고 아예 목표가 수정되면 프로그램의 구조 자체가 흔들릴 수 밖에 없게 된다. 그리고 최종 완료만이 있는 것이 아니라 다음 버전까지 고려해야 하므로 Product Manager 혹은 뭔가 관리자 직책을 맡고 있는 사람의 머리는 좀더 황폐화 되는 것이다.

Long-Term Application을 제작하는 상황에서 위의 기획자와 개발자간의 다툼은 일어나게 되는 것이 당연하다 그 누구도 제품의 영속성을 걱정하는 사람은 없기 때문이다. 당장 닥친 일만을 보게 된다. 신기능을 넣는 다고 하자. 근시간에는 듀와 시장효과가 중요하지만 그다음에 손털 것이 아니라면 듀와 기능성은 한낮 제안에 불과하다. 즉 고려의 대상이 되는 것이다. 이런 상황에서는 기획팀은 큰 기능을 작은 기능으로 나누고 각각의 중요성과 시장성을 평가해야 한다. 개발팀은 각 기능의 개발 코스트를 예상해야 한다. 각 기능을 언제까지 만들 수 있고 몇가지 기능들은 셋트 효과, 즉 같이 하면 시간이 단축될 수도 있으며 기존 구조에 어떤 영향을 주는지도 판단해야 한다. 이런 자료들이 모이면 다같이 모여서 듀를 미루던가 기능을 축소 내지 선별 하는 작업을 해야 하는 것이다. 처음 제안한 기능이 듀에 맞추어 나왔으면 좋겠지만 보통은 제한될 것이고 듀가 늘어날 수도 있다. 그래도 트레이드 오프를 통해 훌륭한 프로그램을 유지해야 하는 것이다.

스티브 잡스가 일전의 졸업식 연설에서 아이맥을 만들때 안된다고 한 사람들은 다 짤랐다고 하는데 정확히는 되도록 노력하는 사람들을 남겨두었을 것이다. 무턱대고 yes-man만을 남겼다면 그 제품이 나왔을리 만무하다. 그리고 처음의 기획과는 많이 수정이 이루어 졌을 것이다.

신기능이 주는 장점은 기획자의 의도대로 엄청날 것이다. 하지만 기존의 프로그램에서 돌아가는 것을 잊어서는 안될 것이다. 장점보다 새로 생성되는 단점이 늘어난다면 그것은 장점이 아니다. 반대로 개발자는 이런 것들을 충분히 검토해 주어야 한다. 그리고 관리자는 이들에게 검토할 시간을 주자.