분석 #3 분할 발주의 허구와 진실

소프트웨어는 이론적인 개발 단계가 있다. 이론이라고 무시하려고 할지 모르지만 이론이 아닌 실전에서 가장 중요한 개념이다, 단계적인 개발 방식을 외부의 개발사와 계약으로 할 때 분할 발주가 된다. 이 용어는 다 이해하겠지만 제대로  따라하지는 않는다. 역량 때문일 수도 있고 의지 때문일 수도 있다. 여기서는 외주 개발사를 가정하고 분할 발주로 얘기하자. 하지만 개발단계의 핵심은 동일하다. 먼저 분할 발주의 목적을 알아야 한다. 목적도 모르고 무조건 분할 발주를 하겠다는 것은 방향도 모르고 눈 감고 길을 가는 것과 같다. 분할 발주의 목적 중의 하나는 개발 단계를 나누어서 각 단계의 발주를 다른 회사에게도 줄 수 있게 하는 것이다.

분할발주를 하려면 당연히 분할을 해야 한다. 잠깐 여기서 IEEE의 SWEBOK (SW 지식체계)에서 세계 최고의 실전 전문가 수백명들이 말하는 분할의 첫 단계인 분석의 목적을 몇 개만 나열해 보자.

- 개발에 드는 비용을 정확하게 산정하기 위함이다.

- 정확한 개발 일정을 알고 싶다.

- 설계를 위한 기초가 된다.

여기서 보면 분할 발주의 목적이나 분석의 목적이 같다는 것을 알 수 있다. 결국 분할 발주의 목적을 이루기 위해서는 분석을 잘해야 한다. 프로세스도 아니고 오직 분석이다. 진리는 가까운 곳에 있다. 반면에 지옥으로 가는 길은 매력적으로 포장되어 있다는 격언이 있다. 유행따라 멋있어 보이는 프로세스, 기법, 방법론들이 매력적으로 보이지만 결국은 대부분 사라지고 분석이라는 추상적인 원칙 만이 영원히 살아남는다. 대부분의 새로운 것들은 마케팅 천재들이 만들어 낸 멋진 마케팅 패션용어에 불과했다는 것을 나중에 깨닫게 된다. Big Data, IOT, Machine Learning등도 갑자기 생겨난 기적이 아니고 과거에 있었던 것들이 환경에 맞게 필요해 진 것 뿐이다. 때에 맞추어  새로운 이름을 붙이니 매력적으로 보이는 것 뿐이다.

국내에서 늦은 감이 있지만 분할 발주가 중요하다는 것을 깨달았다고 하고 법으로까지 만든다는 것은 나쁘지 않다. 하지만 법으로는 충분하지 않다. 법을 바꾸는 것은 쉽지만 사람들의 마음 속에서 편견을 없애는 것이 훨씬 어렵다. 전세계에서 인종에 대한 차별이 법으로는 거의 다 없어졌다. 하지만 사람들의 마음 속에는 아직도 뿌리 깊은 편견이 남아 있고 행동에서도 나타난다. 법은 한계가 있고 마음속으로 받아 들여야만 진정한 변화가 올 수 있다.

지금까지는 신도 얼마짜리 인지 알 수 없는 몇백억짜리 계약을 용감하게 해 왔다. 그렇게 하는 방식 외에는 본 적이 없으니 그런 방식이 인생인 줄 안다. 마치 처음 알에서 깨어난 오리새끼가 최초에 본 물체가 자기 어미인줄 알고 평생을 따라 다니는 것과 같다.  한국에서 벌어지고 있는 갈라파고스 신드럼 중의 하나이다. 필자가 실리콘밸리에 있었을 때 한국회사가 와서 이런 방식으로 미국회사와 계약하고 사업을 하려다 소송 당하고 철수한 적도 있었다. 필자가 아직도 의아하게 생각하는 것은 미국회사가 어떻게 애초부터 그런 계약을 했을가 하는 것이다. 정상적인 미국 회사라면 그런 비상식적인 계약을 했을 리가 없다. 아마도 한국 회사의 브랜드와 파격적인 약속을 믿고 계약했을지 모르지만 결국 두 회사 모두 피해를 입었다. 실리콘밸리에서는 한국처럼 엉터리 계약후 적당히 넘어가는 것은 문화적으로 불가능하다.

게약은 외부 회사와의 계약서만 계약이 아니다. 내부에서 개발 프로젝트를 하겠다고 하는 것도 똑같은 계약이다. 내부라고 계약 없이 대충하는 것은 주먹구구식으로 일하는 회사라는 것을 증명한다. 혹시나 친구끼리 시작한 신생업체인 경우 개발 계획도 없이 열정으로 열심히 해 볼 수는 있다. 운이 좋아 한탕은 가능할 지 모르겠지만 지속적인 성장은 불가능하다. 혼자서 열심히 연습해서 세계적인 피아니스트가 되겠다는 것과 다를 바 없다.

그러면 구체적으로 정상적인 경우에 어떻게 계약이 진행되는 지를 살펴보자. 가장 먼저 확실히 인식해야 할  진리는 개발시작 당시에는 소프트웨어를 개발하는 데 드는 일정과 비용을 신도 모른다는 것이다. 전지전능한 신도 모르니 아는 척 하지 말기 바란다. 그러면 결국 단 하나 남은 선택은 얼마를 줄테니까 알아서 개발해 달라는 것이다. 그래서 소위 우선협상대상자라는 것을 선정하고 정해진 계약비용안에서 무엇을 해 줄 것인가를 협상한다. 아주 그럴듯하게 보이지만 역시 엉터리이다. 이런 방법 외에 어떤 방법도 없어 보이지만 실리콘밸리에서 계약은 그렇게 진행되지 않는다. 오리새끼처럼 처음부터 잘못된 길에 들어서 한국에 뿌리깊게 자리잡은 잘못된 방법일 뿐이다.

그러면 과연 어떻게 진행되는 지 진실을 보자. 실제 경험 없이는 지금은 이해할 수 없는 미묘한 것들이 있지만 먼저 설명할 수 밖에 없다. 1인 회사나 글로벌 대기업이나 마찬가지로 소프트웨어 개발은 (1) 비전 -> (2) 기획 -> (3) 분석 -> (4) 설계 -> (5) 구현 으로 진행된다. 아니 진행되어야 한다. 이는 폭포수 이론처럼 들릴지 모르지만 극히 현실적인 방법이다. 폭포수에 대한 이해를 잘못하고 있는 사람들이 많지만 실리콘밸리는 그렇게 한가하고 이론적인 곳이 아니다. 실리콘밸리는 경쟁이 극심한 곳이고 가장 현실적인 방법론을 사용하는 곳이다. 이 중에서 통상적으로 비전은 경영진의 역할이고 기획은 기획부서 혹은 마케팅부서의 업무이다. 여기서 첫 단추가 잘못 끼워지면 뒷 부분에서 제대로 되기는 힘들다. 한국에서 필자가 본 기획은 대부분 비전에 가까운 추상적인 문서이다. 즉 분석을 수행할 만한 충분한 정보가 없다는 이야기이다.

일단 제대로 된 기획이 있다는 가정하에서 진행해 보자. 그러면 개발팀이 "분석+설계+구현" 을 해야 한다. 외부냐 내부냐에 상관 없이 얼마에 계약을 해야 하는 문제가 생긴다. 이게 비로 불가능한 일이다. 그래서 먼저 계약후 우선협상대상자를 선정해서 개발범위를 얘기해 봐야 역시 무지에서의 토론일 뿐이다. 무지에서의 토론이니 어떤 협상도 신빙성이 없다. 그것은 절대적으로 잘못된 방법이다.

그러면 옳은 방법을 보자. 개발 일정은 전지전능한 신도 모르지만 희망하는 목표 일정은 있다. 그 목표 일정의 30% 정도를 나누어서 "분석" 업무에 관한 계약을 한다. 그러면 다음과 같은 질문이 생긴다.

- 분석에 대한 계약 금액은 얼마로 할까?

- 어떤 결과를 원할까?

- 분석의 결과물 (총칭해서 SRS라고 한다)의 내용과 품질은 어떻게 장담할 수 있을까?

이 문제들은 분할 없이 전체를 계약할 때 생기는 문제와 동일해 보인다. 하지만 큰 차이가 있다. 해법도 단순하다. 이 계약은 결과물을 정하는 것이 아니라 분석에 소비하는 시간에 대한 비용으로 계약을 한다. 이를 "Time and Material" 이라고 한다. 즉 계약한 시간 동안 일을 하는 것이다. 나중에 얘기할 다른 방식은 "Turn-key"라고 한다. 목표 일정이 완전히 엉터리가 아니라면 약 30% 정도의 시간을 들여서 분석의 목적은 이룰 수 있다. 20%를 하든 30%를 하든 40%를 하든 그 목적을 이룰 수 있게 진행하는 것이다. 목적은 다음 단계인 설계와 구현에 필요한 일정과 비용을 정하기에 충분한 정보를 명시하는 것이다. 제품 개발을 완성하는 것이 아니기 때문에 30%이건 40%이건 목적에 맞게 분석을 완성할 수 있다. 분석의 결과는 유연하게 조절이 가능하다는 것이다. 얼마나 자세하게 명시하는 가에 따라 시간을 조절할 수 있다. 분석가로서의 경험이 있다면 당연히 그 정도는 조정할 줄 알아야 한다.

이 분석의 결과물의 논리적인 이름은 총칭해서 SRS라고 한다. 물리적인 문서 이름은 천차만별이고 회사마다 다르다. 문서의 종류와 갯수도 다르다. 하지만 똑 같은 원칙에 의해서 작성된다. 필자가 몇십년동안 수행했던 크고 작은 수백개의 프로젝트가 똑같은 형식의 결과물이 나온 적은 한번도 없었다. 여기서는 아직 어떤 결과물이 나오는 지 궁금해 할 수는 있지만 나중으로 미룬다. 하여튼 분석이 완료된 이 시점에서는 "설계+구현" 단계에서 해야 할 일이 얼마나 되는지 알 수 있다. 즉 "설계+구현"을 얼마에 계약을 할 지를 비로서 아는 시점이 온 것이다. 여기에서의 계약은 Turn-key 게약이다. 몇 명의 개발자가 일을 하는 가는 전혀 신경쓰지 않는다. SRS에 명시된 대로 개발해 주는지 아닌지가 핵심이다. 이미 개발내용이 명시된 상태에서 하기 때문에 우선협상 같은 것은 당연히 필요 없다.

즉 분할 발주를 한다면 계약은 (1) "분석"과 (2) "설계+구현"의 두단계로 나눈다. 또 분석의 중요한 목적의 하나인 이 프로젝트를 계속할 것인다 포기할 것인가도 여기서 결정할 수 있다. 30%의 비용을 들여서 분석을 했다고 해도 과감히 매몰비용(Sunken Cost)으로 버리는 것이다. 30%의 투자가 아까와서 안해야 할 프로젝트에 남은 70%를 투자하는 것은 바보같은 직이다.

설계와 구현 단계는 계약에서는 나누지 않는다. 연속성이 훨씬 더 중요하기 때문이다. 그리고 설계와 구현의 경계선을 긋는다는 것은 거의 불가능하다. 설계에 참여하지 않은 상태에서 코딩을 할 수 있게 하려면 엄청난 양의 문서가 필요하다. 설계와 구현을 분할하겠다는 생각은 그럴듯해 보이지만 현실과는 거리가 멀고 착각에 불과하다. 단계는 나눌지 모르지만 대부분의 개발자는 연속적으로 투입된다. 설계와 구현을 나누어 계약하는 경우는 필자의 실리콘밸리 경험상 본 적도 없을 뿐더러 가능하다고 해도 엄청난 시간의 낭비이다. 설계까지 나간다는 것은 이미 개발을 포기하지는 않는다는 전제를 가지고 있다. 즉 어차피 구현까지 계속 한다는 가정인 것이다. 설계까지 했다면 거의 70%를 진행한 것인데 이제 와서 포기한다는 것은 애초부터 계획이 심각하게 잘못되었다는 것을 의미한다. 여기까지 오다 보면 마치 거대한 프로젝트를 대상으로 얘기하는 것 같지만 이 원칙은 학교숙제할 때도 적용된다. 규모에 상관 없이 가장 빨리 그리고 효율적으로 개발하기 위한 원칙은 동일하다. 단 같은 원칙하에서 프로젝트에 따라 응용법은 달라지며 이 응용역량이 높은 연봉을 받는 진정한 분석 역량인 것이다.

이제 두 단계로 계약을 하는 목적과 그 단계의 경계는 절대적으로 "분석"이 끝나는 시점이 되어야 한다는 것을 이해할 수 있을 것이다. 이런 진리를 확실히 이해했다면 그 목적에 적합한 역량을 키우는 것이 다음에 해야 할 일이다. 분석을 수행하면서도 항상 기억해야 하는 것이 분석의 목적이다.