분리 발주 분할 발주 차이가 모꼬?

분리 분할 발주는 프로젝트는 원청, 시행코자 하는 회사는 분리와 분할 발주의 차이는 두가지 모두 '을' 또는 '병정' 입장을 좀더 생각하는 것이 소프트웨어 업계는 오랜동안 병정 놀이를 해왔다. 지금도 그러고 있다.

분리 발주는 소프트웨어 분리를 발주는 하는 것이다.
하드웨어 납품업체, 또는 솔루션 납품업체가 원청에 독자적으로 납품을 하는 것이다. 이를 전체 통으로 한 SI업체에 주고 그 SI업체가 하드웨어 납품업체, 솔루션 납품업체 이런식으로 끼고 들어오는 것이 아니라 발주 자체를 별도로 분리하는 것이다. 이러므로써 대형 SI업체의 횡포를 막고, 중간에 챙겨가는 마진도 줄이는 효과들이 있다. 물론 전체를 책임질 수 있는 범위가 아니게 되면서 이슈나 문제 발생 가능성이 있지만, 사실 각각의 하드웨어나 솔루션이 문제가 된다면 각각 납품업체에서 책임을 져야 할 것이고, 다만 연동 시 문제라든가 하드웨어나 솔루션 선택의 문제등은 이슈가 될 수 있겠지만, 갑도 좀 고민을 하고 전체 SI업체와 협력을 통해서 풀어가야 하지 않을까 싶다. 중간에 마진을 챙겼던지, 이해관계를 가지고 가던 SI업체야 별로 좋지는 않겠지만, 그렇게라도 맞춰주지 않으면 고객이 떠날테니 말이다.

분할 발주는 분리 발주와 다르다. 소프트웨어 개발을 위한 설계와 개발을 나누는 것이다.
설계회사, 개발 회사 이렇게 역할을 나뉘어서 진행을 하라는 의미이다. 발주자는 소프트웨어의 특성을 악용하여 매번 요구사항을 바꿀 수가 있다. 요구사항을 바꿀 수 있는 이유는 건축물과는 달리 바꿀 수 있다는 것이다. 문제가 없는대도 바꾸는 것이 과연 옳은가? 그리고 바뀐 요구사항을 맞춰주느라 용역회사가 밤샘일을 하고 납기일을 못맞춘다면 그것이 용역회사의 잘못인가? 결정적인 결함이 아니고서야 발주사도 분명 잘못이 있는 것이다. 물론 계획 자체나 잘못되었거나 변경이 불가피 하다고 하면 적절하게 일정이나 비용도 시 산정을 하여 맞추는 것이야 필요할 수 있다. 그래서 이렇게 갑의 횡포를 막기 위한 것이 분할 발주이다. 아무래도 설계회사와 개발회사가 나뉘면 설계를 다 마친 내용으로 개발을 하기에 쉽게 변경이 어렵다. 변경을 어렵게 하고 전문적인 역할을 함으로써 부실하게 설계되는 것을 막고, 변경도 통제를 하는 것이다.

하지만 이 발주 방식에 대해서는 논의해야 할 부분이 많을 것으로 보인다. 문제 발생 시 설계와 개발간의 책임 회피라든가 협업 문제가 있을 수 있고, 실제 변경이 필요할 때 어떤 절차를 통해서 진행이 되어야 하나 등의 문제가 있을 수 있다. DevOps형태의 개발 방법론이 나오는 마당에 설계와 개발까지 분리되는 것이 맞느냐는 것도 생각해볼만 하다. DevOps는 또 얘기하기로 한다. 

책처럼 전체를 보기를 원하시면 아래 링크를 클릭하시고 북마크 하셔서 보시면 편리합니다. 

https://wikidocs.net/22340