진정 하고 싶은말

수십 년간, 수많은 학자들이 소프트웨어 공학을 연구하였으며, "소프트웨어 위기"라는 말이 나온 지도 40여 년이 흐른 지금의 우리에게도, 40여 년 전 세대의 소프트웨어 종사자들이 겪었던 문제가 그대로 답습되고 있다.

한 세대를 풍미했던 수 많은 방법론, 그 방법론이 나왔을 땐 마치 모든 문제를 해결할 것만 같았던 - 구조화 프로그래밍, 객체지향 프로그래밍, CBD, 최근의 SOA까지 - 정말 그럴 듯 했던 그 많은 방법론을 적용하여 왔지만 왜 아직도 이 모양일까? 아직 시도해 보지 못한 방법론이 남아서일까? 그렇지 않다면 이 문제들은 이 산업계에 영원히 풀 수 없는 숙제일까?

소프트웨어 위기에서 통상적으로 얘기되는 예산 초과, 개발 지연, 낮은 품질 등의 문제는 거꾸로 생각하면, 예산을 프로젝트 규모에 비해 적게 잡은 것이며, 개발일정을 규모에 비해 짧게 잡은 것이다. 적은 예산과 짧은 일정, 이 속에서 개발된 프로그램이 높은 품질이 될 수 없음은 이미 예견된 사실일 것이다.

끊임없이 반복되는 이 문제들의 근본적 원인은 프로젝트가 우리의 예측 범위 안에 있지 못함에 있으며, 이 적중률을 떨어뜨리는 데에는 소프트웨어 개발 프로젝트를 바라보는 우리의 시각이 한 몫을 차지하고 있다.

그렇다면 프로젝트를 바라보는 우리의 시각은 어떠한가?

첫째, 소프트웨어 개발 프로젝트는 개발을 하는 것이지 생산을 하는 프로젝트가 아니다.

흔히 간과되는 점 중의 하나가, 마치 공장의 생산라인을 생각하듯 개발자를 바라보는 점이다. 생산라인을 24시간 운영하면 생산량이 늘 듯, 개발자 또한 오래, 오래 컴퓨터 앞에 앉아 있을수록 생산성이 높아진다고 생각한다. 소프트웨어는 기계에 의한 생산이나 반복적 노동의 산물이 결코 아니다.

둘째, 우리의 기억력은 물고기 같아서 3초 이상을 기억치 못한다.

지난 번에 수행했던 프로젝트가 예산 부족과 짧은 일정으로 힘들었지만, 새로운 프로젝트를 시작할 무렵이면 이 모든 것을 아주 까맣게 잊어 버리고 잘 되겠지 하는 마음으로 낙관적으로 프로젝트를 계획한다. 이 낙관적인 계획에도 여유를 다소 가져가지만 그마저도 영업팀, 사업팀과의 협의 과정에서, 거품처럼 사라지고, 최초 생각했던 예산마저 깎이면서 계획단계부터 무임의 초과 근무를 고려한 체 시작된다. 이 경우 빠지지 않는 것이, 프로젝트팀의 영웅심 유발인데, 마치 구국의 일념으로 프로젝트에 투입되는 듯한 분위기를 조성한다. "하면 된다"의 해병대 정신, 이 또한 빠지지 않는다.

셋째, 우리에겐 거울이 없다.

거울을 통해 나의 모습을 바라볼 수 있어야 하는 데, 거울이 없으니 손으로 얼굴을 더듬어 대충 추정하는 수 밖에 없으며 이마저도 극히 부정확하다. 프로젝트팀이 서로의 얼굴을 처음 확인하는 자리가 프로젝트 첫날이다. 그마저도 같은 회사도 아니고, '을', '병', '정', '무' 소속된 회사도 제 각각이다. 이러한 프로젝트팀이 생산성이 얼마나 되는 지, 프로젝트팀의 성격은 어떠한 지를 제대로 이해할 때쯤이면 프로젝트의 개발이 한참 지났을 때이다. 팀워크, 팀원간의 의사소통을 가장 프로젝트 성공의 가장 중요한 요인 중 하나로 꼽지만, 수많은 사람들이 서로를 이해하기엔 너무나도 짧은 시간이 주어지는 것이다.

고객에게, 우리 소프트웨어의 최종 사용자에게 정말 제대로 된 소프트웨어를 전하고 싶다. 그러나 이는 앞에서 전술한 몇 가지 이유 외에도 많은 원인이 복합되어 우리의 바램을 이루기 어렵게 한다.

이들 문제의 해법으로 생산성을 들곤 하는 데, 개발 생산성이 2배로 증가로 증가된다고 해서 우리가 바램이 이뤄질 것으로 생각되진 않는다. 아마 처음 한, 두 프로젝트에서는 목표가 이뤄질 지 모른다. 그러나 그 후부터는 2배로 증가된 생산성을 기준으로 프로젝트 계획이 이뤄질 것이며, 이에 따른 일정의 지연, 예산 초과, 품질 저하 등이 반복 될 것이다.

소프트웨어 위기의 문제는, 프로젝트를 제대로 예측할 수 없게 하는 많은 요인들에 의한 이 산업계 전반의 구조적인 문제이지, 결코 개발 도구, 방법론 등으로 해결될 수 있는 것이 아니다. 개발 도구, 방법론 등에는 프로젝트를 성공으로 이끄는 가장 중요한 요소, "사람"이 빠져있다. 성공적인 프로젝트에는 이 프로젝트를 헌신적으로 수행했던 사람이 있다. 사람들을 도외시하고선 성공적인 프로젝트의 완수란 있을 수 없는 것이다.

성공적인 프로젝트, 좀 제대로 된 소프트웨어를 만들기 위해선 프로젝트가 우리의 예측 범위 안에 있어야 하며, 이를 위해 다음 몇 가지를 제시할 수 있을 것이다.

첫째, 훈련된 우리팀이 있어야 한다.

우리팀, 우리 프로젝트라는 생각을 가질 수 있는, 공동의 목표를 위해 함께 일할 수 있는 프로젝트팀이 구성되어야 하며, 이 팀은 적절히 훈련되어 있어야 한다.

비용을 이유로 프로젝트 개발의 많은 부분을 아웃소싱하게 된다. 특정모듈을 아웃소싱하는 경우도 있고, 프로젝트팀 자체를 다국적군 형태로 구성해서 개발을 진행하거나, 개발조직 자체를 아웃소싱하고 단순히 관리조직만 참여하는 경우도 있다.

이러한 아웃소싱이 단기적으로는 회사에 이득일 수 있으나 이러한 것이 반복되다 보면 회사 내에 개발인력은 없고, 관리인력만 있게 되는 순간이 온다. 회사는 프로젝트를 수행할 능력을 잃어버리고 허울뿐인 소프트웨어 개발회사로 자리매김하게 되는 것이다. 전문화, 분업화의 이름 하에 프로젝트 전체를 한 회사가 수행하기는 어렵다. 그러나 프로젝트에 참여하는 사람이 많을수록 의사소통을 위한 경로의 수가 많아지듯, 참여하는 회사가 많을수록 회사간의 책임소재와 이해관계 조정을 위해 허비해야 하는 시간이 증대되며, 이는 프로젝트팀의 갈등을 유발하고, 프로젝트팀내의 반목으로 인해 험악한 분위기가 연출되기도 한다.

군인에게 있어 사기가 중요하듯, 프로젝트 팀의 사기와 동기 그리고 팀원간의 팀워크는 어느 무엇보다 중요하다. 프로젝트의 팀워크는 오랜 시간 같이 일한 팀에서 우러나온다. 설령, 여러 가지 이유로 인해, 다국적군 형태로 프로젝트팀이 구성된다 할지라도, 지난번에 함께 일했던 사람들을 중심으로 프로젝트팀을 꾸려야 한다. 그리고 고객에게 전하고자 하는 핵심 가치는 직접 수행해야 한다. 핵심 가치마저도 아웃소싱하게 되면 고객이 물어올 것이다. "무슨 역할을 하는 회사예요?" 만약 추가로 진행되는 프로젝트가 있다면, 특별한 정치적인 이유가 없는 한, 고객은 추가사업에서 배제하려고 할 것이다.

구성된 프로젝트팀은 훈련되어 있어야 한다. 프로젝트의 방법론을 제대로 이해하고 따르기란 정말 어렵다. 이에 대한 충분한 교육이 있지 않으면, 아무리 좋은 방법론일지라도 제대로 수행되기 어렵다. 그간 많은 회사들이 조직의 프로세스를 개선하기 위해, TQM, QFD, CMMi, 6시그마, ISO9001등 수 많은 시도를 하였다. 그러나 이러한 기법은 조직 전체가 그 내용에 집중하여 적용할 때만 가치를 가지는 것이지, 담당자 몇 명의 작업에 의해, 매 년마다, 유행이 바뀔 때 마다 획득된 인증서는, 대외적 홍보물 이상의 의미가 없다. 과연 이렇게 획득된 인증서가 그 조직의 품질을 담보하는가? CMMi 5 레벨의 회사는 CMMi 3 레벨의 회사보다 좋은 품질의 소프트웨어를 훨씬 저렴한 가격에 제공할 수 있다고 장담할 수 있나? 시장에서 연출되는 가장 코믹한 상황중의 하나는, ISO9001등의 인증서를 획득한 업체가 제안한 프로젝트를 인증과는 아무 관계가 없는 업체가 수행하는 것이다.

프로젝트팀이 사용해야 하는 방법론, 개발도구 등이 있다면 충분히 교육되어야 한다. 회사의 프로세스 개선을 위해 도입한 기법이 있다면 지속적으로 훈련되어야 하며, 이러한 기법이 조직 내에 스며들어 효과를 발휘할 수 있을 때까지 꾸준히 추진되어야 한다.

프로젝트는 사람이 한다. 아무리 좋은 도구와 방법론, 이를 지원하는 훌륭한Back-Office가 있다고 해도, 프로젝트팀이 훈련되지 않고, 팀워크를 갖추지 못한다면 프로젝트는

해 저문 벌판에서 돌아갈 길을 잃고 헤메이는 어린 양^[각주:1]

이 되고 만다.

둘째, 재활용, 자동화 그리고 단순화해야 한다

지난 프로젝트의 산출물, 즉 검증된 라이브러리, 모듈 등은 최대한 재활용해야 한다. 아주 사소한 버그로 인해 하룻밤을 꼬박 세운 날이 하루 이틀이 아니다. 이러한 실수는 누구나 할 수 있으며, 이러한 실수를 줄이려면 되도록 이미 검증된 산출물을 사용하는 것이 최선의 방법이다. 재활용은 단지 프로그램 라이브러리 등에 국한되는 것이 아니다. 사용자 요구사항부터 테스트 케이스 등에 이르기까지 프로젝트를 수행하면서 만든 모든 것을 재활용하고자 노력해야 한다.

재활용도를 높이기 위해선, 프로젝트가 완료된 후, 재활용이 가능하게끔 정리하고 다듬는 작업이 필요하다. 경우에 따라서는 신규로 매뉴얼을 작성하는 등의 투자 또한 필요하다. 오픈 소스를 선정할 때, 주요 선정기준의 하나가 제대로 된 매뉴얼이다. 매뉴얼 없는 프로그램 소스를 보고서 분석하는 데 드는 시간이 신규로 개발하는 시간보다 긴 경우가 많다. 정리 안된 수십 기가의 자료를 복사해 주며 프로젝트 기간에 재활용을 해 보라는 건 HDD의 낭비일 뿐이다.

반복되는 작업은 자동화하려고 노력해야 한다. 반복되는 빌드, 반복되는 테스트, 반복되는 배포, 반복되는 자료의 입력, 주위를 둘러보면 수많은 작업들이 반복되지만 목수 집에 비 새는 격으로 프로그램 개발을 업으로 하는 우리지만 우리의 환경을 자동화하는 것에 많이 소홀하다. 농부가 호미를 갈지 않으면 수고로움이 더한 법이다.

복잡한 프로세스, 복잡한 문서, 그리고 양식만 바꿔서 계속 만들어야 하는 것들은 단순화 해야 한다. 프로세스를 계획하는 사람의 입장에선 복잡다단한 것을 만드는 것이 뭔가 일을 한 것처럼 보이겠지만, 프로세스를 복잡하게 만드는 순간 이미 프로세스를 따르지 말라고 공표하는 것과 같다. 마치 따라 해 볼 테면 따라해 봐라고 말하는 것이나 같다. 프로세스는 프로젝트팀원이 누구나 쉽게 이해하고 따를 수 있는 수준에서 정해져야 하며 이들 프로세스는 시스템을 통해서 자동으로 이뤄지게 해야 한다.

A4용지 수십 장을 한꺼번에 봐야 되는 복잡한 다이어그램을 주위에서 쉽게 본다. 과연 이 다이어그램을 누가 볼 것이며, 본다고 한들 제대로 이해나 할 수 있을까? 오히려 핵심이 될 부분만 간략히 기술된 것이 훨씬 이해하기가 수월하다. 복잡한 다이어그램을 그리느라 시간만 소모되고, 쓸모 없는 복잡한 문서를 만들기 보단 사람이 이해하기 편한 간략한 문서를 만들도록 해야 한다. 내용보다 산출물의 두께로 승부하지 않았으면 한다.

그림 21 복잡한 다이어그램은 사람들의 이해도를 떨어뜨린다. (Martin, UML for Java Programmer, 2002, p.14)

셋째, 프로젝트 수행을 위한 지침이 필요하다.

프로젝트 수행지침은 리스크 대응지침, 프로젝트 체크 리스트 등 프로젝트 관리를 위한 지침 또는 Apache 설정 Guide 라인, 웹 보안 가이드 라인 등 프로젝트 수행을 위한 기술지침을 말한다. 이러한 지침은 프로젝트에서 우리가 몸으로 때워가며 배워야 했던 소중한 교훈을 채워나감으로써 그 가치를 높여 나가야 한다.

프로젝트를 마쳤다는 안도감에 프로젝트에서 얻은 지식과 자료에 대한 정리가 소홀하기 마련이다. 이로 인해 정말 우리가 몸으로 때워 가며 배워야 했던 교훈이 소실되고 만다. 회사 내의 지침이 5년 전이나 10년 전이나 별 다른 차이가 없다면, 아마도 이 지침은 지침을 만든 사람이 인터넷 또는 외부 자료를 통해 발췌한 자료를 통해서 만든 것일 것이다. 이 지침마저도 항시 교육되고 공유되지 않는다면 아무 소용이 없다. 프로젝트 수행 지침은 프로젝트가 수행될 때 마다 새로이 갱신되어야 하며, 조직원들에게 공유되고 정기적으로 교육되어야 한다.

어떤 회사가 수년 전에 특정 프로젝트를 수행했으나, 그 프로젝트를 수행한 사람들이 모두 퇴사했다면, 과연 그 회사가 그 분야에 경험이 있는 회사라고 얘기할 수 있을까? 프로젝트를 통해 얻은 교훈에 의한 지침은 회사가 진정 그러한 프로젝트를 수행했음을 증명할 것이다.

넷째, 프로젝트팀의 특성과 생산성에 대한 측정이 필요하다.

프로젝트팀의 특성과 생산성에 대한 측정을 통해서 프로젝트 예측의 정확도를 높이도록 해야 한다. 프로젝트팀 개개인에 대한 측정이 아니다. 프로그램 개발엔 뒤처지더라도 고객과의 커뮤니케이션 능력이 출중하거나 팀원들에게 다양한 아이디어를 제공함으로써 프로젝트 성공의 밑거름을 제공하는 사람을 많이 보아왔다. 이 모든 사람들의 아우러져 하나의 팀을 형성하고 시너지를 발휘하게 된다. 바로 이 "팀"에 대한 평가가 필요하다. 프로젝트에 필요한 예산과 자원은 아래의 공식으로 단순화 할 수 있다.

고객의 요구사항이 가변적일 수 밖에 없다면 프로젝트팀의 생산성 자료만이라도 보다 정확한 값을 제시할 수 있을 때, 우리가 보다 현실적인 계획을 마련할 수 있을 것이다.

<출처:http://blog.chosun.com/blog.log.view.screen?userId=xqon&logId=2960908>

장판교에서 장비가 조조의 100 대군을 막던 시대, 출중한 장군 몇 명이 전쟁의 승패를 좌지우지하던 시대는 아주 오래 전에 지났다. 소프트웨어 업계에서도 천재적인 개발자 몇 명이 창고에서 프로그램을 개발하여 히트시키던 얘기도 과거 10여 년 전까지의 일이다. 지금은 조직의 힘으로써 프로젝트를 수행해야 하는 시기이며, 조직적인 힘을 발휘하기 위해선 지속적인 노력과 함께 투자가 병행되어야 한다.

소프트웨어 개발자를 구합니다. – Homeless 우대, 회사를 집으로 생각하고, 주변에 친구나 가족이 없고, 컴퓨터 프로그램 개발 외에는 별다른 취미도 없는 분. 하루 18시간 이상 꼼짝 않고 일할 수 있는 체력의 소유자 우대.

제발 이런 상황이 계속 되지 않았으면 한다.

인용 자료

Boehm, B., Horowitz, E., Westland, C., Madachy, R., Selby, R., & Clark, B. (1995). Cost Models for Future Software Life Cycle Processes: COCOMO 2.0. In J. Arthur, & S. Henry (Eds.), Annals of Software Engineering Special Volume on Software Process and Product Measurement. Amsterdam: J.C. Baltzer AG, Science Publishers.

Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.

DeMarco, T. (1982). Controlling Software Projects. New York: Yourdon Press.

DeMarco, T. (1997). The Deadline : A Novel About Project Management. 김덕규, 류미경 역(2005). 『죽음의 행진』. 서울: 인사이트.

DeMarco, T., & Lister, T. (1999). Peopleware. 박승범 역(2003). 『피플웨어』. 서울: 매일경제신문사.

DeMarco, T., & Lister, T. (2003). Waltzing With Bears: Managing Risk on Software Projects. 김준식 역(2004). 『소프트웨어 프로젝트에서의 리스크 관리』. 서울: 인사이트.