오래전부터 개발자로서 품질에 대한 고민이 많았다. 나에게 좋은 품질이라고 한다면 버그가 없는 코드를 의미했고, 유지보수하기 쉬운 설계와 코드, 기획 의도가 잘 구현된 것을 의미했다. 나는 품질이 높은 코드를 만들고 싶었지만, 현실은 항상 녹록하지 않았다. 항상 시간에 쫓겨서 만들어야 했고 품질을 유지하기 위해서는 비개발자 뿐만 아니라 동료개발자도 설득해야만 했다. 나에겐 명확하게 보이는 것들이 많은 설득을 하거나 내 개인 시간을 할애하면서까지 품질을 유지해야 한다는 것이 이해가 되지 않았다.
오늘은 이런 여러 고민을 해결하기 위한 몇 가지 실마리를 안겨준 QSM(Quality Software Management) Vol1 에 있는 ‘What is Quality? Why is it important?’라는 챕터의 내용을 요약 및 내 생각을 정리해보고자 한다.
품질의 정의
- 결함이 없는 것이 고품질이다
- 많은 기능이 있는 것이 고품질이다
- 우아한 코드로 만들어진 것이 고품질이다
- 빠르게 개발할 수 있는 것이 고품질이다
- 유저 친화적인 것이 고품질이다
여러분은 어떤 것이 품질을 가장 잘 나타낸다고 생각하는가? 혹은 어떤 것은 품질을 나타내는 것이 아니라고 생각이 드는 것은 있는가? 아니면 모든 것을 종합적으로 고려된 것이 품질이라고 생각이 들 수도 있겠다.
품질의 상대성
Quality is value to some person
품질을 정의하는 여러 관점이 있지만, 개인적으로 이 표현이 품질을 가장 잘 표현한 문장이지 않나 싶다. 품질이라는 것은 어떤 절대적인 기준을 가진 것이 아니라 누군가에게 어떤 가치를 주는 것이라는 의미이다. 그런 관점에서 동일한 제품이라도 제품 사용자, 개발자, 기획자, 디자이너, 영업 등 각각의 사람마다 중요시하는 가치가 다르며 그 가치의 우선순위에 따라 제품의 품질을 판단 내리게 된다. 그리고 어떤 품질을 우선한다는 것은 다른 품질을 희생하는 것일 수 있다. 예를 들어 많은 기능을 빠르게 만드는 것을 우선함으로 인해 결함이 증가하거나 유지 보수하기 어려운 코드를 생산할 수 있다. 반대로 유지 보수하기 좋은 코드, 낮은 결함, 높은 보안을 유지하기 위해 속도를 희생해야 할 수 있다.
품질의 정치적 딜레마
위의 특성 때문에 생기는 딜레마는 품질에 대한 정의를 내리는 여러 사람 중에 누구의 영향력이 가장 큰지가 영향을 끼치게 된다. 어떤 서비스에 작은 버그가 하나 있다고 생각해보자. 그 버그에 대한 익명의 유저 CS와 대표님 자녀의 의견은 무게감이 다르다. 지나친 비약이라고 생각될 수 있을 텐데 만약 대표님 자녀가 아니라 우리 회사의 매출에 상당 부분을 기여하고 있는 고객사의 의견이라면 어떨까? 이러한 부분은 사실 합리적인 결정이라기보다는 감정에 기초하는 경우들이 많다. 개발자들은 절대적이고 합리적인 가치 기준에 의해 품질을 정의하고 싶겠지만 현실은 다르다. 품질에 있어 이러한 현실적인 부분을 인식하지 못하면 품질을 개선하는 일은 매우 어렵게 된다.
품질을 개선 시키기 어려운 이유
이미 적당히 쓸만하다
몇 가지 버그나 불편한 점이 있긴 하지만 그럼에도 불구하고 사용하는 사용자가 많다면 굳이 품질을 더 개선할 의미를 느끼지 못한다. 사용자들이 그러한 요소로 떠나기 시작한다고 판단되면 그제서야 품질을 개선하기 시작할 수는 있겠지만 이미 그때는 이미 늦은 시점이다. 보통 이런 문제들을 잘 해소한 경쟁업체가 나타나 시장 점유율을 뺏기기 시작하면 그제서야 인식하게 되는 경우가 많은 것 같다.
품질 향상의 가치를 알기 어렵다
가치를 측정하려면 두 가지의 측면을 이해해야 할 것 같다. 어떤 품질을 향상시키기 위해 들어가는 비용과 얻게 되는 가치의 크기일 것이다. 이 두 가지를 이해해야 품질 향상에 동기가 생길 것이다. 반대로 이것을 알 수 없다면 품질 향상을 위한 동기가 생기기 어려울 것이다.
문화의 보수성
조직에 형성되어 있는 문화는 기존의 문화를 고수하려는 경향이 있다. 가족 치료로 유명한 버지니어 사티어는 이런 말을 했다고 한다.
“People will always choose the familiar over the comfortable.”
편안함보다 익숙함을 선택한다는 것이 무슨 의미일까? 언뜻 보면 이해가 안 될수 있지만 생각보다 우리 주변에서 자주 볼 수 있다. 단축키를 익히면 훨씬 효율적이고 편하게 익힐 수 있는 방법이나 코드로 자동화 하면 훨씬 쉽고 편하게 할 수 있음에도 기존에 익숙한 수동 작업 들이 대표적일 것이다. 어떤 조직에서는 테스트 코드를 작성하는 것이 일상적이고 당연한 반면, 어떤 조직에서는 테스트 코드를 작성할 수 없는 백만가지의 이유가 있다. 그러나 사실 이유는 무엇이든 상관이 없다. 그저 기존에 그렇게 해오지 않았던 것이 크게 작용한다. 그들은(양쪽 모두) 기존의 품질에 적응한 상태이며 더 높은 수준으로 향상 시키는데 필요한 것이 잘 모른다. 또한 찾으려고 노력하지도 않는 경우가 많다.
품질 향상을 위한 조언
책에서는 품질을 향상에 대해 아래의 두 가지 관점의 조언을 한다.
- 품질의 가치를 완벽하게 산정하기는 어렵지만 그렇다고 가치를 산정하기 위한 노력이 아무런 이점이 없는 것은 아니다. 그런 시도를 통해 어떤 가치가 어떤 사람에게 중요한지에 대해 잘 이해할 수 있다.
- 문화의 보수성 때문에 변화를 시도하는 것은 항상 저항에 부딪힌다. 변화를 시도할 때에는 기존 문화의 가치를 인정하고 좋은 점을 보존하고 더 향상시키고자 하는 시도로 접근하는 것이 저항을 줄이는 방법이다.
글을 마무리 하며
최근에 마틴 파울러가 강연한 리팩토링에 대한 영상을 본 적이 있다. 마지막에 마틴 파울러가 왜 리팩토링을 해야 하는가에 대해 설명한 부분이 인상적이었기에 인용해본다.
일부 팀들은 ‘매니저가 리팩토링할 시간을 안 줘요. 중요하다고 말했는데도요.’ 라고 개발자가 말하면서 혼란스러워하는데요. 매니저는 ‘그건 나중에 하시죠’라고 합니다. 팀에서 리팩토링을 하려고 좋은 소프트웨어 설계에 대해 논의하고 모듈화에 대해 더 다가가고 전문성에 대해 이야기하면서 코드를 깨끗하게 만들려고 할 때는 이미 끝난 뒤입니다. 리팩토링에 대해 이야기할 때 이 단어들(Quality, Clean Code, Professionalism, Right thing)을 언급하면 그땐 망한 거죠. 이 단어들은 무시해도 좋습니다. 대신 리팩토링을 이야기할 때 경제성에 대해 이야기하는 것이 좋습니다. 개발자가 하는 모든 것들이 더 많은 기능을 더 빠르게 적용하기 위해서죠. 이게 바로 유일한 ‘리팩토링을 적용해야 하는 이유’ 입니다.
<중략>
만약 개발자가 코드를 깨끗하게 만들지 않는다면 그것은 고객을 도둑질하는 것과 같습니다. 회사로 하여금 새로운 기능을 만들 때 더 많은 돈을 쓰게 하고 더 많은 시간이 걸리게 하는 짓이죠. 그렇기 때문에 개발자가 하는 일이 어떻게 경제적으로 영향을 미치는지 판단해야 합니다. 그러므로 기억하세요. 리팩토링은 경제성 때문에 하는 겁니다. 깔끔한 코드는 더 빠른 기능 개발을 할 수 있습니다. 이게 바로 리팩토링의 이면입니다.
마틴 파울러는 품질은 곧 가치이며 정치적이라는 것을 잘 이해하고 있는 개발자때는 생각이 들었다. 나는 여전히 어떻게 품질을 향상시킬 수 있는지, 그리고 그것이 어떤 가치를 지니고 있는지 판단하는 것이 어렵다. 하지만 나는 전문가로서 사람들에게 많은 가치를 주는 높은 품질의 제품을 만들고 싶다. 그러기 위해 앞으로도 품질을 향상 시키기 위한 시도와 학습을 하려고 한다.