회사에서 개발하고 있는 product의 codebase가 점점 커지다보니 ‘품질’이 이슈로 떠올랐다. ‘성능’과 ‘기능’ 그리고 ‘초고속 개발’이 전부였던 몇해 전을 생각하면 격세지감을 느끼게 된다.
오늘
Alex Stepanov의 Industrializing Software Development 라는 자료를 접했다. 생각할 거리를 많이 던져주는 멋진 이야기이다. 그의 이야기를 재료로 내맘대로 (비빔밥처럼 내 의견을 섞어서) 비벼보자면:
- S/W개발은 원래 Industrialization이 안되는것이다. (Industrializing Software Development p8.) Industrialization이 되는 것은 햄버거가게 같은 종류의 산업일뿐(Peopleware)
- 일반 상품의 품질은 지난 30년간 굉장히 상승했지만, 소프트웨어 자체의 품질은 계속 저하되고 있다. 그 이유는 결국 S/W산업이 햄버거 가게와 다른 종류의 산업이기 때문이다.
- SW가 소비자한테 공급될때, 대다수가 간과하지만 항상 들어가는 이야기가 “AS-IS” aggreement이다. 있는 그대로 쓰는것에 동의한다 - 버그가 있건 말건. 자동차업계와는 달리 절대 리콜 안해준다는 이야기.
- GLUE vs SUBSTANCE: SW의 10%미만이 차별성을 가지는 부분이고 나머지는 그것을 동작시키는 부분이다.
- 따라서, SW를 잘 만들기 위해서는, SUBSTANCE를 잘 만들고, GLUE는 재사용하거나 아니면 Social mechanism- Open Source 등 -을 이용한다.
개발을 잘 하는 교수에게 Tenure를 주어야한다, 개발을 못하는 사람이 좋은 개발자를 만들수 있을텐가 라던가, 소프트웨어의 라인수, 변경의 양, 버그수에 대해 세금을 매겨야한다는 웃지만은 못할 이야기도 있다.
회사 입장에서 어떻게 풀어나가야 더 좋은 품질의 제품을 만들 수 있을 것인지는 영원한 숙제겠지만, 최근 드는 생각은 역시 소프트웨어 개발은 소위 굴뚝산업의 제품 개발과는 다른 종류다라는 것. 그렇지 않으면 소프트웨어 개발 방법론 책들이 이렇게 아직까지 많이 나오고 있을 리가 없잖은가.
굴뚝산업의 제품 생산에 있어서 중요한 것은 불량이 없는 것이다. 하지만 소프트웨어 제품의 개발 (소프트웨어의 경우 개발이 곧 생산이다)에 있어서 중요한 것은 오류는 있어도되지만 (있을수 밖에 없다고 인정하고 들어가는 것이 나의 견해) 오류가 발생할 경우 시스템에 중대한 해를 끼치지 않는 것이다. 즉, 필연적인 오류의 존재를 인정한다면 결국 설계에서부터의 “Fault-tolerance”가 (외부적 요인이건 내부적 요인이건.) 중요하다는 것.