글쎄, 이런 질문은 마치 "사람과 동물의 차이는 무엇인가?"와 마찬가지로 추상적이고 철학적인 질문이라고 할 수 있다. 하지만 사람과 동물의 차이를 구분할 수 있듯이, 소프트웨어 개발이 (공장의) 생산 공정인지 또는 (새로운 타입의 독창적인) 창조인지를 구분하는 것 또한 충분히 가능하다.사람은 영(靈)적인 존재이다. 그것이 바로, 동물과 사람을 구분 짓는 핵심 요소이다. 사람은 영적인 활동을 한다. 단순히 의식주의 충족을 초월하여, 음악을 만들고 그림을 그리고 문학 작품을 창작한다. 그렇게 만들어진 작품들이 수세기를 거쳐 후대의 사람들에게까지 전달되어 감동을 주고 누군가의 인생을 바꾸기도 한다.그렇다면 소프트웨어 개발은 어떠한가?소프트웨어 개발을 생산 공정을 통해 물품을 만들어 내는 것, 또는 공사장에서 블루프린트 대로 건물을 짓는 것으로 보는 관점을 먼저 살펴보자. 해당 관점 하에서는 개발자(또는 엔지니어)를 대체 가능한 부품 내지는 공사장의 인부로 볼 수 있는데, 그러한 현실을 김국현씨의 풍자 만화(http://www.goodhyun.com)-추운 새벽에 장작불을 쬐며 일감을 기다리는 개발자를 향한 외침, "자바 2명 타요"-는 잘 담아내고 있다.공사장의 십장(인부를 직접 감독하고 지시하는 사람)과 같은 마인드로 개발자를 관리하려는 매니저들이 있는 것이 사실이다. 그들은 통제를 원한다. 통제하지 않으면 부하 직원들이 일을 제대로 수행하지 못하거나, 또는 일하지 않고 농땡이를 피울 것이라고 생각한다.전문가라 불리는 일부 사람들은, 제조업 및 토목/건축업과 같은 관점을 소프트웨어에도 그대로 적용하려고 한다. 그렇게 함으로써 불확실한 소프트웨어 개발을 좀 더 명확하게 통제하려는 희망을 갖고 있는 것이다. 수십 년 동안 그러한 희망을 갖고서 수많은 방법론과 기법이 만들어졌지만, 그 어느 것도 명쾌하게 문제를 해결한 적은 없다.예를 들어, CMMI을 만든 IBM 품질관리자 출신의 와츠 험프리를 생각해보자. 그는 소프트웨어 개발에도 마치 공장에서와 같은 품질 관리 개념을 적용할 수 있다고 보고, 거의 모든 것을 정량적으로 측정하고 통제하고자 하였다. 팀원들에 대한 교육 등 사람에 대한 내용이 전혀 없는 것은 아니지만, 그 사상의 바탕에는 합리적인 프로젝트 상황을 전제하고 개발자들을 대체 가능한 부품으로 생각하는 컨셉을 담고 있다.왜냐하면 CMMI에는 유능한 개발자와 평범한 개발자의 수십 배의 생산성 차이, 개발자들의 열정과 동기부여, 조직 역학 및 프로젝트의 사회/정치적 요인, 그로 인한 개발자들의 이직률 등에 대해서는 전혀 다루어지지 않고 있기 때문이다. 단기적 생산성이 높다 하더라도, 이직률이 높다면 결국 엄청난 손실이 뒤따를 것이다. 그런 것은 아무도 측정하지 않는다.솔직히 대부분의 프로젝트는 기술적인 문제 또는 프로세스적인 문제 때문에 실패하는 것이 아니다. 예를 들어, 평범한 데이터베이스 응용프로그램은 수십 년 동안 만들어졌음에도 여전히 종종 실패한다. 프로젝트 실패의 주요 요인은 이해관계의 상충, 거짓 데드라인, 고객의 무모한 욕심, 핵심 개발자의 퇴사, 커뮤니케이션 문제 등 사회/정치적인 요인임을 우리는 경험에 의해 잘 알고 있다.그러므로 생산 공정과 같은 개념으로 소프트웨어를 다루려고 하는 접근 방법은 대개의 경우 그 가치가 과대평가되어 있다고 볼 수 있다. 그러한 접근이 매력적이기 때문에 흔히 선택될 뿐이다. 그들은 말한다. "포드시스템(조립 라인 방식에 의한 양산체제)과 같은 체계를 구축하면, 마치 소프트웨어 개발을 생산 공정과 같이 통제할 수 있어요."아, 관리자의 입장에서는 얼마나 매력적인가?개발자들을 부품 취급함으로써 "김대리는 불량품이었어. 일주일에 80시간 일했다고 해서 금새 고장이 나다니. 고장난 김대리는 버리고, 좀 더 성능 좋은 새로운 김대리로 대치하자고."라는 식의 접근을 할 수 있는 것이다.오해가 없기를 바란다. 필자의 이러한 말이 품질 관리 전부를 부정하는 것은 아니다. 소프트웨어의 특수성을 인정하고, 좀 더 사람 중심으로 품질 관리의 방향을 잡을 필요가 있다는 뜻이다. 개발자들의 역량과 생산성에 대한 가치는 진지하게 재평가되어야 한다.프로젝트에 있어 수많은 사회/정치적인 요인은 무시한 채로, 통제 가능한 것처럼 보이는 일부의 요인에만 집중함으로써 프로젝트가 성공할 수 있다는 식의 주장은 실제보다 훨씬 과장되어 있다고 볼 수 있다.프로젝트 착수는 대개 합리적이지 않으며 데드라인은 말도 안되며 예산은 부족하며 적절한 인적자원은 주어지지 않는다. 그러한 현실을 무시하고, 선한 사람들과 함께, 합리적인 일정, 적절한 예산, 명확한 목표를 갖고서 일한다는 전제를 통해 만들어진 방법론들은 전혀 경험이 없는 사람들에 의해 만들어졌다는 의심이 들게 한다.이제, 창조의 관점에서 소프트웨어 개발을 생각해 보자. 아, 알고 있다. 물론 SI 프로젝트는 예술이 아니며, 체계적이고 정량적으로 관리될 필요가 있는 것이 사실이다. 하지만 소프트웨어 개발에 있어 SI만 존재하는 것은 아니다. 애플 아이튠스 또는 구글 데스크톱 같은 것도 있다. 그것들은 생산 공정의 통제 기법을 통해 언제든지 만들어질 수 있는 것인가? 그렇지 않다.그러한 유형의 소프트웨어를 개발하는데 있어, 가장 중요한 요소는 개발자의 영감(靈感, 머리에 번득이는 신묘한 생각)이다. 그리고 그것을 기반으로 한, 동기부여와 창조적 실행력의 극대화이다.물론, 어떠한 유형의 소프트웨어를 개발하는가에 따라 접근 방법은 다를 것이다. 크게 구분하여, SI성 소프트웨어와 영감에 의한 소프트웨어가 있다. 한쪽은 제조에 가까운 반면, 한쪽은 창조에 가깝다. 두 가지 속성을 모두 가진 소프트웨어도 있을 것이다. 중요한 것은 소프트웨어에는 한가지 유형만 있는 것이 아니라는 점이다.현실에서 소프트웨어의 유형에 따른 특성 차이, 개발자들의 본질적 속성, 작업 환경, 창조력, 프로젝트의 사회학 등에 대한 내용은 흔히 간과되고 있다. 그 이유는 아마도 그것이 일반적인 경영학이나 사회학, 심리학에서 다루어질 수 있는 분야가 아니고, 그렇다고 컴퓨터 공학이나 소프트웨어 공학에서 다루어 질 수 있는 분야도 아니기 때문일 것이다.결론적으로 말해, 필자는 소프트웨어 개발의 본질이 창조 작업이라는 것을 주장한다. 생산 공정의 개념을 일부 적용할 수는 있겠지만, 그것이 창조적 실행력보다 우선할 수는 없다.왜 그럴까? 그 모든 개발의 시작과 끝이 모두 사람으로부터 시작하여 사람으로 끝나기 때문이다. 사람의 지적 능력과 정서, 기쁨과 희생을 통해 만들어진 결과가 바로 소프트웨어다. 우리는 소프트웨어 개발을 단지 생산 공정으로 바라보려는 통제적 관점을 경계해야 한다.필자의 대안은, 기업들이 생산 공정 식의 투자보다는 개발자의 작업 환경을 개선하고 창조적 실행력을 극대화하고 자기계발을 독려하고 동기부여를 하는데 더욱 투자해야 한다는 것이다. 구글, 어도비와 같은 몇몇 기업들은 그것의 성공 사례를 명백히 증명하고 있다.필자는 이 문제에 대해서 강의를 하든, 집필을 하든, 그 무엇을 하든 지속적으로 다룰 것이다. 그것이 바로 필자가 몸담은 소프트웨어 업계에 대한 깊은 애정을 증명하는 방법이라고 믿기 때문이다. @
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.
