일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 객체설계
- 실해하지 않는
- 자바개발
- LAN WAN
- LG그램2017
- ASUS 공유기
- tvheadend
- 소프트웨어설계
- angular 6
- sonoff
- SW설계
- 네트워크 기본개념
- EXK
- USB-C충전
- docker 네트워크
- Value Object(VO)
- 경력개발자
- CBD 단점
- SpringBoot
- 자바스크립트 JQuery
- 구글캘린더 검색
- maven #junit
- USB-C to HDMI 아답터
- open cursors
- 자바튜닝
- SI와 SM 차이점
- 프로젝트관리
- Data Transfer Object(DTO)
- SW분석
- Tomcat error-page version
- Today
- Total
대빵's Blog
소프트웨어 컴포넌트 설계의 단점 본문
거의 대부분의 소프트웨어 관련 의사결정자들이나 관리자들은 개발자들이 소프트웨어를 만들때 컴포넌트화 하여 만들기를 원한다.
실제로 개발을 해본적이 거의 없고 컴포넌트화 하면 이곳저곳에 약간만(?) 변경하면 소프트웨어를 재사용할 수 있다는 원론적인 얘기와 컴포넌트 찬양들만 들었기 때문에 가끔 거의 맹신도처럼 컴포넌트를 신봉하는 사람들도 존재한다.
개발자들은 뭔가 이게 현실적으로 어렵다는 것을 몸으로 느끼고 알고 있지만 실제로 이론적인 공부를 하거나 체계적으로 정리한 적인 없으니 정확하게 설명하지 못하고 그냥 끌려다니는 경향이 있다.
소프트웨어 컴포넌트는 정말 좋은 것일까? 단점들과 고려사항들을 알아보자.
컴포넌트 소프트웨어의 단점은 사실 단 하나이다. 비용이 많이 들어간다. 하지만 단순히 비용이라고 하면 다들 개발비용만 생각하기 때문에 좀 더 명확하게 어떤 비용이 발생되는지 들여다 봐야 된다.
1. 분석/설계 비용
- 소프트웨어 컴포넌트 예제에서 자주 등장하는 전기콘센트를 보자. 220V 방식 전용으로 만들지 않고 컴포넌트 방식으로 만들어서 여러나라 여러 콘센트 방식으로 사용하기 위해서는 일단, 다른나라는 어떤 방식의 콘센트를 확인해봐야 한다.
쉽게는 인터넷에서 찾아볼 수도 있지만 제품을 만들기 위해서 인터넷 검색만 해서 대충만들수는 없는 법. 그 나라에 가서 전기콘센트도 써보고 해당 나라 관련 기관 문서도 보고 관련 공무원이나 기관들도 방문해서 기술적인 이슈나 검토사항들이 있는지 여부를 확인해야 할 것이다.
따라서 소프트웨어를 컴포넌트 분석/설계 하려면 당연히 여러가지 상황과 변경가능한 부분에 대한 분석/설계 비용이 발생된다.
2. 개발/테스트 비용
- 당연히 코드가 복잡해 질 수 밖에 없다. 사실 복잡하다기 보다는 인터페이스가 분리되고 동적인 메모리 할당에 대한 처리방식이 최근 개발언어들이 컴포넌트들을 처리하는 방식이기 때문에 이러한 방식으로 코드를 작성해야 한다.
또한, 각각의 경우에 대한 테스트가 필요하다. 장비도 구입해야 하고 테스트 환경들도 여러개 준비해야 한다.
사실 여기까지는 일반적으로 생각할 수 있는 비용목록이다. 의사결정자들은 위의 비용들이 발생되는 것만 생각하기 때문에 특정 프로젝트의 비용으로 포함시키거나 약간의 비용투자만으로도 소프트웨어 컴포넌트들을 만들어 날 수 있다고 생각한다. 하지만 진짜는 따로 있다.
3. 유지보수 비용
- 일반적으로 소프트웨어의 가장 큰 비용은 유지보수 비용이다. 컴포넌트로 만들었을 때 유지보수는 어떻게 될까?
컴포넌트화 하면서 기존에 100개의 코드가 120개로 늘었다. 당연히 유지보수비용이 20% 늘은 것이다. 늘어난 비용은 월 20%의 고리대금 이자처럼 시스템에 유지보수 비용을 발생시킨다.
쉽게 생각해서 220V 전용으로 만들면 될 물건을 무조건 돼지코젠더를 꽂아야만 사용할 수 있도록 물건을 만들었다고 생각해 보자. 만약 해당 물건을 매일 마다 하루 2번씩 사용한다면 하루 두번씩 불필요한 돼지코젠더 뺐다 꽂았다를 반복해야 한다..........물건 고장나서 버릴때까지....
만약 단순한 방식으로 개발해도 되는 소프트웨어를 전체 컴포넌트화 해서 개발했다면 적어도 소프트웨어 규모가 1.5~2배 정도 될 것이고 해당 시스템 파기할 때까지 매달 유지보수비용이 1.5~2배 이상 발생된다.
이곳 저곳에서 컴포넌트를 조금씩만 바꿔서 재사용할 수 있기 때문에 컴포넌트 방식으로 해야 된다는 건 실제로 물건이 팔린 이후에나 알 수 있는 일이다. 그 소프트웨어를 그렇게 팔 수 있는 능력과 영업능력을 먼저 갖추고나서 컴포넌트화를 주장해도 늦지 않다.
4. 장애처리 비용
- 사실 이부분은 유지보수 비용에 포함해서 생각할 수도 있지만 엄밀히 얘기해서 다른 얘기로 생각해야 한다. 개발자들은 모두가 각각의 수준차가 있고 모두다 컴포넌트화 설계를 이해하고 실제로 실현해서 구현할 수 있는 개발자들은 열에 하나 될까 말까 한다.
바꿔말하면 열에 아홉은 컴포넌트가 뭔지 모르고 이것은 아무리 잘 설계된 소프트웨어라도 시간이 지날 수록 소프트웨어가 망가진다는 의미이다. 하물며 초기에 잘 설계된 소프트웨어라도 그럴진다. 처음에 잘 설계되지 않은 소프트웨어는 말할 필요도 없다.
나중에 실력있는 개발자와 설계자가 들어오더라도 이미 만들어진 소프트웨어를 전면적으로 수정하는데 있어서 한계가 있을 수 밖에 없다.
따라서 소프트웨어 컴포넌트화는 소프트웨어 복잡성을 증가 시키고 이것은 현실적으로 시스템에 장애 확률을 높이게 된다. 우리 시스템의 장애시간당 발생비용을 계산해 보자. ........담에 하자.......
결론. 소프트웨어를 만들기 전에 남발하는 이상과 꿈들은 그러한 것들을 이룰 수 있는 능력이 있는 조직과 투자가 가능한 경우에만 의미있는 행위가 된다. 능력없이 꿈과 이상을 쫒는 것은 그냥 집에서 해야지 업무에서 하면 다른 많은 사람들에게 민폐만 부리는 꼴이 된다.
'개발관련' 카테고리의 다른 글
높은 신뢰성 소프트웨어의 첫단추는 개발자의 신뢰성 이다. (0) | 2018.03.16 |
---|---|
Redis 수정에 관계없이 정해진 시점에 데이터 삭제시키기. (0) | 2018.03.16 |
소프트웨어 개발에서의 Agile (0) | 2018.03.01 |
Async 멀티쓰레드 환경에서의 jMeter 사용팁(RPS vs TPS) (0) | 2018.02.10 |
택시운전기사의 자동차설계(SW 분석과 설계의 차이) (0) | 2018.02.03 |