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

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

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

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

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

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

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

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

'개발&Development > 프로그래밍 일반' 카테고리의 다른 글

Event Driven과 Multi-Threading  (0) 2006.10.31
재개발  (1) 2006.10.30
기획자 vs. 개발자  (4) 2006.10.30
Quality Assurance  (1) 2006.10.30
수요와 공급  (2) 2006.10.23
코더의 길  (1) 2006.09.01
  1. Commented by Beowulf at 2006.10.30 12:15

    앞부분에 정리한 상황이 웬지 예전의 모회사와 흡사하다는 생각이 드는데.. -_-;;
    개발새발 딩구는 상황까지는 아니었던거 같긴 하다만; 쿨럭;

  2. Commented by CK at 2006.10.31 00:58

    "관리자"는 위에서 이야기 한대로 시간만 주면 되나요? ^^;;

  3. Commented by CK at 2006.10.31 01:02

    알다시피 웹 2.0 으로 오면서 "Lightweight programming" 이 강조되는 추세라서, 한국식으로(?) 3개월 안에 뚝딱뚝딱 만들어서 일단 코어 컨셉을 구현한 그 무엇인가가 하루라도 빨리 시장에 나온 뒤, 사용자들의 반응을 이끌어 내는 걸 강조하는 추세인 듯합니다...이러한 추세 속에서는 아무래도 개발도, 기획도 함께 머리를 모아서 어떻게 하면 "원자력 발전소" 를 "짓지 않을까" 고민해야 하는 게 맞을듯.... 즉 what to do 만큼이나 what not to do 를 고민해야 할 듯합니다

    • Commented by 겐도 at 2006.10.31 03:10

      무엇을 하려는지를 정확히 집어 내는게 가장 중요하겠죠. MS-WORD 1.0이 이세상에서 가장 훌륭한 워드프로세서로 만들겠다고 했다가 하마터면 사라질뻔 했다죠. MS가 그래도 최근에 잘 하는 것은 정확히 버전업을 하면서 핵심 기능들을 잘 뽑아내고 있는 것 같습니다.(물론 막강한 재력으로 기능 추가되는 양도 엄청나지만)
      헌데;; CK님도 이제 슬슬 코멘트 말고 트랙백을 해 보심이 :)