예전에 운영하던 블로그에서 "일정은 줄어들지 않는다"라는 제목의 글을 썼던 기억이 납니다. 고급 개발자 또는 전문가를 둔다고 하여도, 일정이 줄어들지는 않으며, 다만 리스크를 줄일 수 있다는 내용의 글이었습니다.
이번에는 비용에 대한 이야기인데, 특히 프레임워크, 솔루션, 오픈소스 등에 대한 이야기입니다.
10년 전 읽었던 게임 개발 관련 서적의 내용 중, 수억 원 대의 솔루션 엔진을 도입한다고 하여도, 사실 상 비용의 증감은 없다는 것이 그 내용이었습니다. 다만, 일정을 크게 단축할 수 있다는 점이 장점이라고 하더군요.
제 경험 상, 일반적인 소프트웨어 개발에서도, 프레임워크나 상용 또는 오픈소스 솔루션 역시 마찬가지의 내용이 적용되는 것 같습니다.
우선 오픈 소스
네. 대부분의 경우, 무료라는 것이 장점입니다.
그런데, 많은 사람들이 오픈소스 솔루션 도입의 장점이란 말을 사용하면서, 생략하는 긴 수식어가 있습니다. '수년 간 안정성을 검증받고, 장기간 널리 사용되고 있어 이미 인터넷에 수많은 질문답변 기록이 존재하며, 또 언제든지 헌신적으로 대답해줄 사용자층을 다수 보유하고 있는, 그리고 그 기능이 현재 구현하려는 시스템의 기능 범위에 정확히 맞아 떨어지면서 현재 프로젝트 내 개발자들과 최소한 비슷하거나 더 나은 수준의 개발자들이 참여한' 정도의 수식어일 것입니다. 물론, 더 길게 쓸 수도 있긴 합니다만, 여하간 오픈소스를 도입하여 이득을 볼 수 있는 상황은 전체적으로 보았을 때 그리 비중이 크진 않습니다.
예를 들어, 잘 알려지지 않은 오픈 소스 솔루션을 도입하였다가, 문제가 발생하면, 어떻게 해결해야 할까요? 본 프로젝트와 하등의 책임 관계가 없는 해당 오픈소스 프로젝트의 관리자에게 당장 해결하라고 큰소리를 칠 수도 없고, 구글신 역시 알 수 없는 페이지들을 잔뜩 나열하며 당신을 비웃습니다. 결국 그 문제를 해결하기 위하여, 다행히도 오픈된 소스를 분석하기 시작합니다. 근데, 이제보니 이 개발자들, 완전 개판입니다. 1년차 개발자를 데려다 써도, 이것 보단 잘 만들었을 겁니다. 그러고 보니, 이 오픈소스 프로젝트는 왜 또 이렇게 큰지요? 정작 제가 쓸 기능은 전체 코드 중 5%도 채 되지 않는데 말이지요. 하지만 코드가 여기저기 마구 얽혀있어, 결국에는 해당 오픈소스 프로젝트의 모든 코드를 다 분석하고 말았습니다.
그렇게 한 달이라는 시간이 흘렀고, '차라리 직접 개발했으면 이틀이면 끝났을 텐데'라며 후회를 합니다. 그리고 허탈한 마음으로 패치를 마치고, 해당 오픈소스 프로젝트를 분석하며 발견한 몇 가지 문제점을 해당 오픈소스 프로젝트의 관리자에게 보냅니다. 다음 날 메일 한 통이 와 있습니다. "와 이런 개떡같은 녀석을 정말 쓴단 말입니까?" 라던가, 또는 "혹시 저희 프로젝트에 참여하실 생각은 없으신지요?"라던가.
좀 씁쓸하지만, 제가 직접 겪은 이야기입니다.
그리고 상용 솔루션
다행히도 상용 솔루션은, 일단 대부분의 경우, 기술 지원을 받을 수 있습니다. 하지만 그 역시도 문제는 있습니다.
일단, 많은 분들이 이미 깨닫고 계시겠지만, 해당 솔루션을 개발한 개발자들의 수준이 생각만큼 아름답진 않습니다. 한 명의 고급 개발자가 설계한 솔루션을 수십 수백명의 초급 개발자들이 나누어 개발하는 것은, 어느 회사나 마찬가지입니다. 해외 유명 기업이라고 한 회사 내에 고급 개발자만 수백명씩 둘 수는 없습니다. 그나마 일부는 합리적인 비율로 관리되긴 합니다만, 그 역시도 매우 수가 적습니다. 유명한 글로벌 기업들 중에서도 대부분은 아직까지도 이와 같은 문제를 가지고 있습니다.
별 생각 없이 열심히 해당 솔루션을 이용해 개발을 했는데, 프로젝트가 어느 정도 진행되는 시점에 갑자기 문제를 발견하고 이를 고쳐달라고 기술지원팀에 전화하니, 이 문제를 해결하는데 아마도 한 2년 정도 걸릴 것 같다는 답변을 들어본 적 있으신지요? 결국 처음부터 다시 다 만들어야 한다는 사실을 뒤늦게 깨닫고, '아 내 개발자 인생은 여기서 끝이구나'라는 생각을 해본 적 있으시다면, 아마 지금쯤 세차게 고개를 끄덕이고 계실 것입니다.
마침내 프레임워크
상용 또는 오픈소스를 막론하고, 프레임워크는 추가적인, 그리고 공통된 문제점이 있습니다. 바로 '학습 기간'이라는 녀석입니다.
물론 여러분들이 많이 사용하는 몇몇 프레임워크들은 다행히도, 많은 개발자들이 미리 다른 프로젝트를 열심히 말아먹으면서 이 학습 기간을 미리 지불하고 들어옵니다. 하지만 역시 학습 기간이란 비용이 있습니다. 그리고 지금 고용하신 개발자 중 일부는 그 학습 기간을 열심히 겪으며 귀하의 프로젝트를 말아먹고 있을 지도 모릅니다.
그리고 결과적으로 프레임워크란, 결국에는 일부 관리 용이성을 위하여 다른 무엇인가를 희생하는 방안입니다. 그 각각의 비용을 정확히 계산하지 않으면, 도입의 요지를 흐리는 것이며, 또한 비용의 증가로 이어질 수도 있습니다.
하지만
그렇다고 해도, 오픈 소스나 상용 솔루션, 그리고 프레임워크의 도입이 나쁘다는 것은 아닙니다. 다만, 'Silver Bullet'은 아니라는 말이지요. 그저 좋다는 말만 듣고, 무조건적으로 도입하는 것을 주의해야 합니다.
이와 같은 문제점들을 잘 분석하고, 해당 솔루션이나 프레임워크 도입 시에 충분히 고려하고 결정한다면, 분명 도움이 될 때가 많을 것입니다.
하지만, 그래도 다시 한 번 짚고 넘어가자면, 결과적으로 그리고 총체적으로, 비용이 줄어들지는 않습니다.
다만, 비용을 줄일 수 있는 가능성을 제시할 뿐입니다.
관련글
2008/09/30 - [Software Engineering] - 일정은 줄어들지 않는다
마치며 덧붙임
간만에 글을 길게 썼더니 적응이 안 되네요. :')
분명 apache web server와 같은 오픈 소스를 떠올리며 오픈소스에 대한 호감을 여전히 가지고 계신 분들이 계실 것입니다. 위에서 이야기 했듯, 이러한 솔루션은 상기 '수식어'를 충족하므로, 비용 절감을 이룰 수 있는 오픈 소스에 해당합니다. 하지만 또 한 가지 생각할 것은, 일반적인 소규모 프로젝트에서, 통상적인 웹 페이지를 띄우는 간단한 웹 서버를 만드는 데 걸리는 시간도 한 번 생각해보십시오.
정말, 생각하셨던 것만큼, 많은 비용을 절감하고 있습니까?
'Software Engineering' 카테고리의 다른 글
| 비용은 줄어들지 않는다 (2) | 2011/10/10 |
|---|---|
| 개발은 개발자에게, 투자는 투자자에게. (2) | 2011/06/18 |
| 오래 전 있었던 일 1 (1) | 2010/08/01 |
| 디자인 패턴과 셰익스피어 (0) | 2010/03/13 |
| 옹알이와 방송 사고 (2) | 2010/03/13 |
| 정석은 익히는 즉시 잊어라 (1) | 2010/03/13 |
댓글을 달아 주세요
고려되야 할 좋은 사항들입니다. 좋은 의견 잘 읽고 갑니다.
자주 들러주셔서 감사합니다. :')