How Software is Built (Quality Software Book 1)

4권으로 구성된 Quality Software Management 시리즈가 Quality Software로 이름을 변경하면서 9권으로 분권되었어요. Management가 관리자를 위한 책이라는 오해를 불러일으켜서 뺏다고 합니다.

머리말에서는 어릴 적 “생각하는 기계”라고 오해했던 컴퓨터가 사실은 사용하는 이의 지능을 그대로 반영하는 거울이고, 여럿이 작업할 때는 단순한 거울이 아니라 확대해서 보여주는 거울이었음을 알게 된 사례를 소개하면서, “생각하는 기계"를 잘 사용하려면 우리의 생각을 향상시킬 필요가 있음을 설명합니다.

저자의 조카가 사용하는 워드프로세서에 버그가 있었는데 마침 저자가 컨설팅하는 회사의 제품이었어요. 회사의 관리자에게 버그 수정을 건의했지만 해당 버그를 겪는 사람은 매우 소수이기 때문에 우선순위가 높지 않다고 했어요. 컨설턴트로서는 관리자의 판단에 동의하지만, 삼촌으로서는 동의할 수 없는 상황이 된 거죠. 이때 누군가 “이 워드프로세서는 품질이 좋은 제품인가요?”라고 물어봤다면 대답할 수 없었을 거라고 하네요. 여러분의 생각은 어떤가요?

이 딜레마는 품질의 상대성에 기인해요. 누군가에게 적절한 품질이 다른 이에게는 아닐 수 있죠.

Crosby의 정의에 따르면 “품질은 요구사항을 충족시키는 것"이지만 요구 사항이 하늘에서 떨어지는 것은 아니기 때문에 “품질은 누군가의 요구사항을 충족시키는 것”이 좀 더 맞는 표현일 거예요.

품질은 사람을 빼놓고 얘기할 수 없어요. 품질을 언급하는 모든 서술은 어떤 사람에 대한 서술이에요. 그것은 대부분 겉으로 드러나지 않아요. 이것이 바로 소프트웨어 품질에 대한 많은 토론이 비생산적인 이유예요.

누군가 소프트웨어 품질의 정의를 단언할 때마다 이렇게 질문한다고 해요.

품질의 상대성을 인식하는 것은 종종 의미론적인 딜레마 semantic dillema를 해결해요. 하지만 아직 정치적인 딜레마 political dillema를 해결하지는 못해요. 누군가에게는 더 많은 품질이 다른 이에게는 적은 품질을 의미할 수 있어요.

이것이 보다 실용적인 정의일 거예요.

“품질은 누군가에 대한 가치다.”

여기서 “가치"는 “사람들이 그들의 요구사항을 위해서 기꺼이 지불하려는 무엇"을 의미해요.

요약하면, “품질"의 정의는 언제나 정치적이고 감정적이에요. 일련의 결정에 있어서 누구의 의견이 중요한지, 그리고 다른 이의 의견에 비해 얼마나 중요한지를 항상 내포하고 있기 때문이죠. 물론 이런 정치적/감정적 결정은 대부분 드러나지 않게 숨어있어요. 대부분의 우리 소프트웨어 업계 사람들은 이성적으로 보이길 바래요.

많은 경우 이런 결정은 결정을 내리는 사람들조차 의식하지 못하기 때문에 우리가 하는 일을 어렵게 한다고 합니다. 그래서 품질 관리자의 가장 중요한 작업 중에 하나가 그런 결정을 의식의 영역으로 가져오는 것이라고 해요. 우리의 주요 작업이 될 거라고 하네요.

저자는 Precision Cribbage라는 게임에 버그가 있었지만 자신은 충분히 만족했다는 이야기를 들려줍니다.

Precision Cribbage의 예를 보면 “요구사항의 충족"은 품질의 적절한 정의가 아닙니다. 아래와 같이, 오류에 기반한 품질의 정의도 부적절하다는 보여줍니다.

“품질은 오류가 없는 것이다”

이러한 정의들이 수년 동안 양질의 소프트웨어에 대한 생각을 지배해왔고, 이는 소프트웨어 개발자와 관리자들이 “소프트웨어 품질 개선" 요청을 무시하기 쉽게 만들었어요. 누군가 시키지 않더라도 자존심을 위해서 품질을 향상시키고 싶어 했을 텐데 왜 아무 일도 일어나지 않았을까요?

실제로 개발자에게 개선을 요구한다면 이런 답이 돌아올 거예요. “하지만 이미 좋은 품질의 제품이에요. 물론 버그가 있지만, 모든 소프트웨어는 버그가 있어요. 게다가 경쟁 제품보다 좋다고요.”

그러나 사용자가 제품을 사용하거나 구매하는 것을 멈춘 다음에 개발자가 “품질을 개선" 하려고 해도 그때는 이미 늦어요.

Phil Crosby는 Quality is Free에서 품질 개선의 동기는 늘 “품질의 비용"을 연구하는 것으로 시작한다고 말해요. (저자는 “품질의 가치”라는 용어가 더 좋지만 같은 개념이라고 해요.) 저자가 컨설팅을 하면서 소프트웨어 비용을 삭감하거나 개발 시간을 줄이는데 집착하는 관리자와는 자주 얘기해 봤지만, 품질을 개선하는데 집착하는 관리자는 찾기 어려웠다고 합니다. 그들에게 비용 절감이나 일정을 빨리 처리하는 것의 가치를 설명하는 것은 쉬었을 거에요. 하지만 개선된 품질의 가치는 측정할 생각을 해본 적이 없는 것이었죠.

저자가 그들에게 품질의 가치를 측정하려고 제안했을 때, 종종 키가 2.5미터로 자라는 것의 가치를 측정하라고 말한 것처럼 반응했다고 해요. 어차피 달성할 수 없는 것을 측정해봤자 무슨 의미가 있냐는 것이죠.

이 도표는 낙관적으로도 비관적으로도 읽힐 수 있어요. 낙관적으로는, 조직이 한 번 품질의 진짜 가치를 이해하기 시작하면, 개선 동기를 높이고, 개선 방법의 이해를 유도하고, 차례로 품질 가치에 대한 깊은 이해로 이어집니다. 이것이 Crosby가 “품질의 비용" 연구로 조직의 변화를 시작하려고 했던 이유에요.

비관적으로 보면, 품질의 가치에 대한 이해가 없으면, 품질을 달성하려는 동기도 없어지고, 따라서 품질을 어떻게 달성할지에 대한 이해도 개선되지 않아요. 그리고 품질을 달성할 방법을 모른다면, 그것의 가치를 측정하려 할 이유가 없겠죠?

그림 1-3은 “락온" 효과의 간단한 예입니다. 락온 시스템은 변화해야 할 “논리적인" 이유에도 불구하고 기존 패턴을 유지하는 경향이 있어요. 저자는 표준 프로그래밍 언어의 선택을 락온의 훌륭한 예로 설명해요. 하나의 언어를 고수할수록 변경 비용이 증가하고, 다른 언어를 공부할 동기가 줄고, 다른 언어를 배우는 법에 대한 지식이 사라져, 결국 조직은 해당 언어에 “락온”되어버려요.

하나의 언어에 락온 되면, 그 외의 다른 요소에도 락온이 된다고 해요. 툴셋을 비롯해 인력, 커뮤니티, 소프트웨어 공학의 철학, 유저 인터페이스 철학 등이 그 예가 될 수 있어요.

저자가 컨설팅을 위해 새 조직을 방문하면 아래의 두 가지 본질적인 사실을 빠르게 알아차린다고 합니다.

(1)로 인해서, 정말 중요한 소프트웨어 관리 문제에 대해 미리 준비된 해결책을 가질 수는 없어요. 그러나 (2)로 인해서, 새 조직을 만날 때마다 처음부터 시작할 필요는 없어요.

이 관찰을 인류학적인 방식으로 다시 말하면, 시대와 공간과 환경을 초월하는 어떤 “소프트웨어 문화”가 있다고 합니다. 영어로 쓰인 소프트웨어 서적이 전 세계에서 잘 팔리는 것이 하나의 증거가 될 수 있겠죠.

모든 소프트웨어 문화는 몇 개의 다른 패턴으로 귀결되는 것 같다고 해요. 이 패턴을 구별하는 한 가지 방법은 조직이 만드는 소프트웨어의 품질을 관찰하는 것이에요. 소프트웨어 조직은 몇 가지 특정한 수준의 품질에 락온 되어 있고, “문화의 보수적인 본성"이 변화를 방해한다고 해요. 이 보수성이 나타나는 예는 아래와 같아요.

품질은 가치이기 때문에 품질은 중요합니다. 품질을 제어하는 능력은 여러분의 소프트웨어 노력을 제어하는 능력이에요. 양질의 소프트웨어 대한 새로운 문화에 도달하려면, 개발자와 관리자는 이 요소들은 효과적으로 다루는 법을 배워야만 해요. 이것이 이 책의 주제입니다.