96. 상품 품질에 영향을 미치는 요인들
성공적인 소프트웨어 신상품 개발가이드
품질에 영향을 주는 요인들은 많다. 품질, 도구, 조직의 규율이 품질에 미치는 영향을 설명한다.
1) 납기가 품질에 미치는 영향
납기는 품질을 저하시키는 대표적인 요인이다. 대부분의 납기는 처음 설정할 때 그날이 아니면 안 되는 이유가 없다. 달성 가능성을 신중하게 고려하지 않은 경영층의 말 한마디 혹은 낙관적이고 의욕적인 분위기에서 무리하게 정해지는 경우가 많다. 우주선 챌린저호의 비극도 1986년 1월 28일을 맞추기 위해 품질이 희생된 대표적인 예이다.
프로젝트 상황실에 ‘납기는 생명, 품질은 자존심’이라는 현수막을 부착하는 경우가 흔히 있다. 현수막을 붙이는 사람은 납기도 중요하고, 품질도 중요하다는 메시지를 팀원에게 말하고 싶었을 것이다. 그러나 생명과 자존심을 바꿀 수 있는 사람이 몇이나 되겠는가? 역설적으로 이 말의 뜻은 ‘자존심이 상해도 일단은 살고 보자(납기를 위해서 품질을 희생하자)’는 것이 아닐까?
현실에서도 그러한 생각이 만연해있다. 관리자가 납기를 재촉하는 경우, 개발자는 프로그램의 품질을 희생한다. 이러한 행위를 ‘모서리 자르기(corner cutting, 필요한 코드 중 일부를 생략한다는 의미로 예외사항 미 반영이 대표적인 예)' 혹은 ‘지뢰를 만드는 작업’에 비유하기도 한다. 지뢰수가 적을 때는 터질 가능성이 낮지만, 납기에 쫓길수록 지뢰의 양이 많아지고 폭발력도 커져서 결국 프로젝트 팀원들이 감당하기 힘든 시점에 지뢰는 터진다. 짧은 기간에 감당하기 힘든 품질 이슈는 설계의 전면 재검토, 프로젝트 관리자 교체 등 프로젝트 팀원들에게는 정신적, 육체적 상처를 남긴다. 이러한 상황을 <애자일 프랙티스, 2007>에서 다음과 같이 이야기하고 있다.
소프트웨어 프로젝트는 시간 압박을 많이 수반하는 것 같은데, 그 압박이 무분별한 지름길로 가게 한다. 그러나 경험 많은 개발자라면 누구나 얘기하듯이 ‘땜질은 늪을 만든다.’ 근시안적으로 보면 땜질식 수정이 잘 동작하는 것 같다. 그러나 조금만 멀리 보면 땜질은 지뢰밭을 가로질러 뛰어가는 것과 같다.
이상의 예는 단기적 관점에서 납기를 위해 품질을 희생하는 이야기이다. 최초 상품출시는 납기를 위해 기술부채를 만들 수 있지만, 안정적이고 반복적인 유지보수는 품질이 뒷받침되지 않고서는 불가능하다. 즉 한 두 번은 속도를 위해 품질을 희생할 수 있지만 지속적으로 그럴 수 없다. 그러한 상품은 품질이슈로 고객이 외면하기 때문이다.
품질을 위해 속도를 희생할 때도 있지만, 그것이 일상이 되어서는 경쟁력이 없다. 속도를 위해 품질 수준을 높여야 기업이 경쟁에서 살아남는다.
2) 도구가 품질에 미치는 영향
자동화 도구를 활용하면 소프트웨어 품질이나 생산성을 향상시킨다는 주장은 대부분의 경영층과 개발자들을 유혹한다. 그러나 <맨먼스 미신, 2007>에서 이야기했듯이 소프트웨어의 생산성과 품질을 극적으로 향상시키는 은총알(silver bullet) 은 없다. 극적인 품질향상은 못해도 도구를 활용하여 더 적은 공수를 투입하고도 같은 수준의 품질을 유지할 수 있거나, 같은 공수를 투입하고 조금이라도 품질을 개선할 수 있으면 도구 적용의 효과는 있다. 이제 많은 사람들이 벤더들의 과대광고를 믿지 않는다. 소프트웨어 품질향상을 위하여 사용하는 자동화 도구(빌드, 형상관리, 테스트, 요구사항 관리)는 잘 사용하면 도움이 되지만 잘못 사용하면 부작용이 더 크다. 도구의 도입 비용 못지않게 도구를 교육하고 적용하는 비용도 비싸다. 자동화 도구 사용 시 유의할 사항은 다음과 같다.
- 중요한 프로젝트에 새로운 도구를 사용하지 않는다
단 납기 프로젝트 혹은 기술적 난이도가 있어 복잡한 프로젝트에서는 팀원들이 가장 익숙한 도구를 사용하는 것이 좋다. 도구를 원활하게 사용하기 위해서는 팀원의 숙련도가 무엇보다 중요하다. 팀원들이 익숙하지 않은 도구는 교육시간의 낭비뿐만 아니라, 시행착오 비용도 발생된다. 익숙하지 않은 도구는 적용하다가 흐지부지해지기 쉬우며, 그 결과 표준의 준수에 매우 부정적인 영향을 미친다. <소프트웨어 아키텍트가 알아야 할 97가지, 2011>는 새로운 도구를 사용할 때 유의할 사항을 다음과 같이 설명하고 있다.
여러분들이 익숙하고 믿음직한 무기에 너무 빨리 손을 떼지는 마십시오. 이전과 유사한 시행착오를 통해 검증되지 않는 한 그 대안 때문에 여러분의 무기를 던져버린다는 것은 위험천만한 생각입니다. 거품이 가라앉기를 기다리고 기술이 업계에 널리 유용하게 사용되는지 살펴보십시오. 많은 기술들이 사라지는 것을 확인할 수 있습니다. 여러분들이 사용할 무기를 주의 깊게 선택하고, 신중하게 내려놓으십시오.
- 도구 적용에는 공짜가 없다
경제학에서 “공짜 점심은 없다”고 하는 것은 도구 적용에서도 마찬가지이다. 도구에서 자동화한 결과를 제공하기 위해서는 무엇인가를 도구에 입력해야 한다. 같은 기능을 반복적으로 테스트하기 위해서는 스크립트를 입력해야 한다. 보기에 그럴싸한 결과물 뒤에 숨어있는 수면 아래의 백조 다리와 같은 노력이 무엇인지를 파악해야 한다. 물론 투입물(input) 대비 산출물(output) 효과뿐 아니라 팀원들의 동의도 중요하다.
- 도구를 올바르게 사용하는 기술이 중요하다
<프로젝트가 서쪽으로 간 이유는, 2009>에서 톰 드마르코(2009)는 “미켈란젤로가 집어 들기 전까지 조각 칼은 단순히 날카로운 금속조각에 지나지 않았다”라고 하였다. 말 그대로 도구는 도구일 뿐이다. 프로젝트 규모와 상황에 맞는 도구를 선정 시 해당 도구를 사용하기 위한 숙련도 수준과 도구학습을 위해 필요한 기간이나 지원도 고려해야 한다.
3) 규율이 품질에 미치는 영향
품질향상을 위해서는 규율(discipline) 준수가 필수적이다. 많은 사람들이 오해하는 것 중 하나가 전통적인 방법론은 규율을 강조하고 애자일이나 린 스타트업 방법론은 규율을 강조하지 않는다는 것이다. 아니다. 모든 방법론에는 준수해야 할 규율이 있다. 규율이 다를 뿐이다. 사람들이 모여서 일하는 방법을 정의하는 데 규율이 없을 수 없다. 규율이 없다는 것은 각자가 마음대로 작업하는 것을 허용하는 것이다.
하나의 방법론이나 프로세스를 모든 프로젝트가 준수하도록 하는 것도 규율이고, 각 프로젝트에서 테일러링 하여 적용하도록 하는 것도 규율이다. 프로젝트 상황에 따라 품질향상에 보다 효과적인 규율이 있을 수 있다. 예를 들어 테스트 주도 개발은 품질향상을 위해 매우 효과적인 기법이지만 개발팀의 역량이나 조직문화가 뒷받침되지 않으면 적용효과가 낮아진다.
테스트 자동화, 코드리뷰 등도 마찬가지이다. 해당 프로젝트에서 가장 효율적이고 효과적인 품질활동을 규율로 정의하고 규율을 철저히 준수할 때 품질 수준은 높아진다. 개발 후반부에 긴 시간의 테스트활동을 하는 것은 시간이나 비용 관점에서는 비효율적이지만 품질 성숙도가 낮은 조직에서는 그렇게 하는 것이 최선이다.
https://brunch.co.kr/@kbhpmp/160
