프로젝트에서 얻은 교훈 (1) 수직 vs 수평개발

 

시리즈

1. ✅ 수직개발 vs 수평개발
2. Open Source vs 유료 기성 소프트웨어 vs 자체 제작
3. 백엔드 아키텍쳐 설계시 고려 3요소
4. 개발자가 Yes 보다 No를 외쳐야하는 이유
5. 귀찮지만 필요한 Doucmentation & Issue Tracking
6. 실제와 비슷한 수준의 테스트

 

 

수평 개발

앱이나 서비스 업데이트에서 새 기능 추가는 이런 수평 개발 프로세스로 이뤄진다.

 

 

 

 

수평 vs 수직 개발 비교

항목	수평 개발	수직 개발
수익성	높음	낮음
재미	재미있음	지루함
성과 가시화	티가 잘 남	티가 잘 나지 않음
소요시간	상대적으로 적음	상대적으로 많음
서비스 퀄리티	?	높아짐
개발 복잡도	높아짐	상대적으로 낮음
예시	신규 기능 추가	기능 개선, 오류 수정, 성능 향상, 호환성 향상, 테스트 디버깅, 문서화

 

조직 전체로보면 또 기획자, 사업가 입장에서 보면 수평 개발이 항상 좋은 것 처럼 느껴진다.

돈을 벌수 있고, 유저의 유입 유인책이 생기면서 성과가 눈에 보이기 때문이다. 반면에 수직개발은 당장 돈도 안되고, 개발자 입장에서도 상대적으로 지루한데다가 티도 안난다.

 

그래서 프로젝트 계획 일정은 항상 소요 기간은 짧으면서 기능은 마구마구 추가하는 그림으로 흘러가기 마련이다. 

이런 일정에서 개발자들은 사용하기 편한 라이브러리, 오픈소스를 덕지덕지 끌어다 붙이고 , "일단 돌아가는 기능을 구현하는것" 에 혈안이 될 수 밖에 없다.

 

 

수직 개발을 해야하는 이유

수평 개발의 문제는 만드는 도중에 혹은 만들고 난 후 나중에 터진다. 그리고 그때 뒤집기는 매우 어렵다. 급하게 추가한 컴포넌트가 많아 복잡도가 증가했기 때문이다. 어디서 툭 건들면 저기서 팡 터지는 스파게티 코드가 즐비한다. 일단 수평 개발을 해놓고 유지보수하려고 들면 '대형 수술'을 해야한다. 완성도가 떨어졌을 수록, 복잡도가 높을 수록, 마감기한이 짧아서 터진 문제일수록 이런 생각이든다

 

"이거 고칠바엔 그냥 새로 만드는게 낫겠는데? "

 

기능이 많아질수록 서로 다른 기능을 연결(Coupling) 해야 하기 때문이다.

그래서 사소한 기능 하나라도 완성도있게 만드는 '수직 개발'이 필요하다.

 

하나의 기능을 오랜시간 완성도있게 만드는 방식

당장은 진행이 더디고 성과가 눈에 띄지 않아도 장기적인 관점에서보면 높은 퀄리티와 유지보수 비용이 확 줄어들고 재사용성이 높은 제품을 만들 수 있다.

 

 

 

모든 기능을 수직 개발하는 것도 문제다.

수직 개발은 수평 개발에 비해 훨씬 오래걸린다. 근데, 그 기능이 사용자 입장에서 어차피 쓰지 않는 기능이었다면?

곧바로 무용지물이된다. 이때는 수평 개발 했을때 보다 시간과 노력은 훨씬 들이고 성과는 없는 최악의 케이스가 탄생한다.

 

📝 결론

프로젝트 초반에는 퀄리티에는 신경쓰지 않고 일단 수평개발로 여러 기능을 만들어서 프로토타입을 제작한다.

=> 사용자가 필요로하는 필수 기능만 남기고 나머지는 다 걷어낸다.

=> 필수 기능을 하나씩 수직 개발한다.

 

 

 

 

 

다음편

Project에서 얻은 교훈 (2) 오픈소스가 만능은 아니다.