소프트웨어 개발의 특징
이 글은 소프트웨어를 만들려고 하는 경영자, 정치인, 비영리 재단 등 소프트웨어 비 전문가들을 위해 쓰는 글입니다
2014년 삼성전자는 신성장 산업으로 사물인터넷, B2B(기업 간 거래), 의료기기, 소프트웨어 등을 키우겠다고 했습니다. 이 기사를 보고 정말 헛웃음이 나왔습니다. 소프트웨어가 별도의 항목으로 나와 있었기 때문입니다. 요새 뭘 만들어도 다 소프트웨어로 만듭니다. 사물인터넷의 핵심은 데이터 수집/전송/자동화된 실시간 분석입니다. 뭘로 합니까? 소프트웨어로 합니다. B2B 역시 결국 사업 간 거래로 오가는 게 바로 ‘데이터'입니다. 이 ‘데이터’ 전송에 대한 것, 소프트웨어로 합니다. 의료기기는 이미 하드웨어는 싸게 만들고 소프트웨어로 중요한 기능을 다 개발해서 계속 판올림 하고 있습니다. 이처럼 소프트웨어는 ‘어디에나' 이용되고 ‘모든 것'속에 녹아 있습니다. 이것은 그 개발인력 역시 모든 사업분야에 다 필요하다는 뜻입니다.
그런데 왜 삼성전자는 소프트웨어를 다른 사업분야와 따로 분류해서 ‘다른 것들과 구분되는 무엇 인양' 기사를 냈을까요? 소프트웨어 인력 늘린 것을 자랑하던데, 구글이 소프트웨어 인력수를 자랑하던가요 그들이 개발하는 제품을 자랑하던가요?
요새 가전제품뿐 아니라 전투기를 개발하는데 조차 소프트웨어가 핵심입니다. 그런데 위의 기사에서 보았듯이 삼성전자의 의사 결정권자들이나 언론조차 지금 소프트웨어가 뭔지도 모르고 어떻게 사용할지도 모르고 있습니다. 어찌 된 것입니까? 한국 사회의 기업/언론들이 다 소프트웨어 산업의 본질을 모르는 것은 아닐까요?
미국 국방성(DoD) 보고서에 의하면 60년대에 개발된 F-4 전투기가 수행하는 기능의 약 8%가 SW에 의해 이루어지는데 최신예 전투기 F-35는 90%나 된다고 하니 SW가 얼마나 큰 비중을 차지하고 있는지 알 수 있습니다. SW는 비단 군용 무기뿐만 아니라 우리가 일상생활에서 사용하는 각종 기기나 원전, 자동차, 조선, 로봇 등 모든 분야에서 차지하는 비중은 점점 커질 것입니다. - 이성남 전문위원, “무기체계 SW는 무엇이며 왜 중요한가?”, 소프트웨어 공학센터
여러분이 빌딩을 새로 짓는 사업을 한다고 합시다. 땅의 면적, 층수, 거기에 용도와 예산이 나오면 건축 회계에 의해서 ‘몇 명을 투입해서 며칠 만에 공사 완료 가능'여부가 나옵니다. 그에 따라 건축업자를 찾아서 맡기면 거의 예상한 날에 입주공사를 합니다. 인테리어도 비슷합니다. 창조적인 일이긴 하지만 거의 날짜를 맞추는 게 어렵지 않습니다. 설사 늘어나도 초기에 준비를 많이 잘 해 놓고 중간에 바꾸지만 않으면 하루, 이틀 정도죠. 이런 경우 적어도 기간 안에 어느 정도 나올 성공률 약 90% 이상이라고 봐도 괜찮을 것입니다.
그런데 소프트웨어는 어떠한가요? 주위에 많은 사업가들이나 비영리단체 분들이 저에게 이런 호소를 해오는 경우가 많습니다. “왜 맨날 개발자들은 오래 걸린다고 하냐? 하루 이틀이 아냐! 적어도 몇 달, 아니 몇 년이 넘어가냐!”
그럼 평균적으로 소프트웨어 개발 프로젝트의 성공률은 얼마일까요? 공식적으로 이에 대해 집계한 보고서가 있습니다. 바로 Standish group CHAOS report입니다. 2015년, 최신 집계에 따르면 아래와 같이 나옵니다. 결론적으로 2015년에는 약 29%만 성공했습니다. 대충 봐도 평균 30% 안쪽의 성공확률입니다. (여기서 성공했다는 뜻은 일정과 예산에 맞고 만족할만한 결과를 보여줬다는 뜻입니다.)
이 성공확률은 앞서 말한 건물 올리는 것이나 인테리어 하는 것과 비교해보세요. 90% 대 30%. 엄청난 차이입니다. 이 뜻은 우리가 시작하는 소프트웨어 프로젝트들 대부분은 실패할 거라는 것입니다. 문제는 여러분이 하고자 하는 일 대부분을 소프트웨어로 할 수밖에 없습니다. 그 이야기는 여러분이 하는 일의 성공률도 최대 30% 이하로 떨어진다는 뜻입니다. 이것은 성공을 기대하는 게 아니라 일어날 수 있는 실패를 관리하는 것이 소프트웨어 프로젝트의 본질이라는 것입니다.
이 사실을 깨달았을 때, 저는 정말 무서웠습니다. 게다가 소프트웨어로 하는 스타트업은 아래 공식을 보면 정말 할게 못됩니다. 일반 사업보다 더 성공률이 떨어질 것이기 때문입니다.
소프트웨어의 개발 성공률 X 사업 모델 자체의 성공률 = 현재 하고 있는 소프트웨어 사업의 성공률
앞서 말했듯 실패 확률을 관리하는 것이 소프트웨어 프로젝트의 본질이라는 것을 생각하고 계셔야 합니다. 더 답답한 것은 현재 거의 50년 이상 소프트웨어 엔지니어링을 연구해온 수많은 연구자 누구도 이를 해결할 방법을 제시하고 있지 않습니다. 오히려 ‘은탄환이 없다'(모든 경우에 적용될 수 있는 법칙이 없다는 뜻)라는 말만 계속할 뿐입니다.
지금 이 글을 읽으시는 독자분들은 인류가 해온 일들 중에 ‘가장 실패 확률이 높은 일을 하고 있다’라는 사실을 먼저 마음에 품고 있어야 합니다. 그렇기 때문에 최고 의사 결정권자가 직접 챙겨야 합니다. 그냥 밑에 사람에게 던져 놓고 결과만 본다는 것은 있을 수가 없습니다. 회사나 조직의 운명을 좌지우지하는 일을 말단 사원에게 던져 놓고 나중에 보겠다는 경영자는 제정신이 아니죠.
특별히 한국/일본의 품의에 의존하는 일처리 문화에서는 가장 많은 권한과 자원을 가지고 있는 최고 결정권자가 챙기지 않으면 더 느려집니다. 왜냐하면 밑에 갈수록 의무는 많아지고 권한이 없는 품의 기반으로 조직이 운영되기 때문에 말단 실무자는 어떤 의사 결정도 혼자 할 수 없기 때문입니다. 갑-을-병-정으로 계속 하청으로 내려가는 프로젝트가 망하는 이유가 바로 여기 있습니다. (최동석, '똑똑한 사람들의 멍청한 짓' 참고)
그러므로 소프트웨어 프로젝트를 진행한다면 반드시 최고 의사 결정권자가 직접 챙기는 프로젝트여야 합니다. 아무리 바쁘고 다른 중요한 일이 있어도 챙겨야 합니다. 이것이 당신을 살리고 죽일 것이기 때문입니다.
셰어하우스 우주(http://woozoo.kr/)의 CEO 김정헌 님이 이런 이야기를 했습니다. “내가 기술을 모르기 때문에 가장 좋은 기술 전문가에게 맡겼다. 내가 기술 전문가였다면 내 기술이 최선이 아닐 수가 있다는 생각을 하지 못한다. ” (출처:벙커원 특강)
지금 이 책을 읽는 독자분들은 소프트웨어를 오래 개발해 오신 전문가일 수도 있습니다. 하지만 대부분의 경우 그렇지 못한 분들이 많습니다. 그럼 비 소프트웨어 전문가들은 소프트웨어 프로젝트의 최고 결정권을 가지면 안 되나요? 그것은 아닙니다.
여러분들은 ‘어떠한 기능'이 만들어져야 ‘고객을 만족'시키고 ‘매출'을 만들거나 문제를 '해결'할 수 있을지 알고 있습니다. 이것에 집중하면 됩니다. 이것들을 개발팀에 잘 전달하고 고객의 반응을 살피고 어떻게 개선해야 할지 결정을 해서 소프트웨어를 지속적으로 발전시키면 됩니다. 그러므로 당신은 훨씬 능동적으로 움직여야 하고 빠른 의사결정을 내려주어야 합니다. 그것이 당신의 역할입니다. 그럴 수 없다면 그냥 안 만들면 됩니다. 고생 사서 하지 마세요.
이번 장을 요약하면 이렇습니다.
소프트웨어 프로젝트의 실패 확률은 매우 높다. 성공을 기대하는 게 아니라 일어날 수 있는 실패를 관리하는 것이 소프트웨어 프로젝트의 본질이다.
그러므로 의사결정권자가 직접 챙겨야 한다.
당신이 소프트웨어 프로젝트의 전문가는 아닐 수 있다. 그렇다면 어떤 기능이 만들어져야 고객을 만족시키고 매출을 만들 수 있을지 정확히 알아야 한다. 이를 기술전문가들과 당신의 고객 사이에 지속적으로 의사소통하고 결정을 빨리 해주어야 한다.