제랄드 와인버그 옹의 책 Quality Software Management의 스터디 기록. 이 책은 모든 챕터에 Helpful Hints and Suggestions, Summary, Practice가 있다.

Chapter 1. What is Quality? Why is it Important?

품질은 가치이기 때문에 중요하다. 품질을 통제하는 능력은 소프트웨어의 가치를 통제하는 능력이다.

챕터 요약

  • 품질은 상대적이다. 누군가에게 가치있는 무언가가 다른 사람에게는 완전히 무가치할 수 있다.
  • 품질의 상대성을 찾아내는 행위는 품질에 대한 주장 안에 숨어있는 사람들을 찾는 행위다. “품질에 대한 그 주장을 뒷받침하는 사람이 누구인가?”
  • 품질은 누군가에게 주어진 가치, 그 이상도 이하도 아니다. 이 관점에서는 다음 주장들이 모두 동시에 옳을 수 있다.
    • 결함이 없어야 품질이 높은 것이다.
    • 기능이 많아야 품질이 높은 것이다.
    • 코드가 아름다워야 품질이 높은 것이다.
    • 성능이 좋아야 품질이 높은 것이다.
    • 개발 비용이 낮아야 품질이 높은 것이다.
    • 개발 속도가 빨라야 품질이 높은 것이다.
    • 사용자 친화적이어야 품질이 높은 것이다.
  • 품질은 거의 언제나 정치적이면서 감정적인 문제지만, 우리는 품질을 이성적으로 정의내리는 척 한다.
  • 품질이 높은 것과 오류가 없는 것은 동치가 아니다. 정식 요구사항조차 충족하지 못하는 소프트웨어 제품이라도 어떤 사용자들에게는 고품질로 여겨질 수 있다.
  • 품질 향상이 무척 어려운 이유는 조직이 특정 패턴에 고착화되는 경향이 있기 때문이다. 많은 조직은 현재 품질 수준에 적응하여, 다음 수준으로 나아가기 위해 무엇이 필요한지 알지 못하고, 실제로 찾아내고자 노력하지도 않는다.
  • 소프트웨어 조직이 사용하는 패턴들을 몇 가지 클러스터, 또는 하위문화로 분류할 수 있으며 각 문화는 특징적 결과를 만들어낸다.
  • 문화는 본질적으로 변하지 않으려 한다. 이러한 보수성은 특히 다음 것들에 나타난다.
    • 특정 품질 수준에 대한 만족
    • 더 낫게 하려는 시도를 통해 그 수준을 잃는 것에 대한 두려움
    • 다른 문화에 대한 이해의 부족
    • 그들 자신의 문화의 비가시성

실천

  1. What evidence can you produce to indicate that people in your organization are indeed satisfied with the level of quality they produce? How does the organization deal with people who express dissatisfaction with that level?

아래와 비슷한 대화를 종종 들은 기억이 있다.

  • 개발자: 코드 가독성을 개선하고 오래된 코드를 삭제하는 리팩토링에 시간을 쓰고 싶다.
  • 관리자: 물론 그것도 중요한데, 그보다는 제품 배포 주기를 지키기 위해서는 이 이슈를 처리하는 게 좋지 않을까?

이런 대화를 들으면 뭔가 답답함을 느꼈는데 답답함의 원인이 뭔지 몰랐다. 지금 생각해보면 둘다 맞는 말이었다. 조직에서의 가치 기준, 또는 품질 기준이 합의되지 않은 상태였는데 그걸 몰랐을 뿐. 내가 속한 조직에서는 품질을 제대로 정의내린 채 개발을 진행한 적이 있었던가? 지금부터라도 그런 질문을 할 수 있도록 해보자.

스터디에서 나온 대화 중, ‘품질은 누군가에게 주어진 가치이며, 품질은 상대적이고, 또한 정치적/감정적이다’와 관련된 이야기가 있었다. 대화는 내 기억에 따라 맘대로 각색해서 기록해본다.

  • 정훈: 개발 조직에서 클라이언트 팀과 서버 팀의 리더가 다른 경우가 많은데, 이 책을 읽으니 이렇게 나누는 게 정말 좋은 걸까 하는 생각이 강해진다. 서로의 품질 기준이 상충되는 일이 많아서.
  • 휘동: 그러고보니 이런 게 생각난다. 예를 들면, API에서 리스트 데이터를 fetch해와서 보여주는 페이지를 만들 때, 정렬을 서버에서 할지 클라이언트에서 할지 결정하는 문제.
  • 지민: 우리도 딱 그런 사례가 있었다.
  • 휘동: 재밌는 건 이게 단순히 하나의 페이지를 어떻게 구현할지에 대한 문제가 아니고, 순수하게 기술적인 문제도 아니라는 것이다. 예를 들어 기존의 모든 리스트 페이지에서 클라이언트는 서버가 보내주는대로 페이지를 렌더링했었다고 하면, 일관성 때문에라도 앞으로의 모든 정렬을 서버에서 하는 게 맞다는 결정이 내려질 수 있다.
  • 지민: 그렇게 되면 클라이언트 입장에서는 로직이 단순하고 아름다운 코드가 되면서, 서버 입장에서는 코드가 복잡해진다. 즉 코드 가독성이라는 가치에서 하나의 결정이 양쪽 팀에서 반대되는 품질 결과를 가져온다. 그리고 기능을 사용하는 유저 입장에서는 어떻게 결정하든 차이는 별로 없을 것이다.
  • 정훈: 정치적인 문제가 될 수도 있을 것이다. 예를 들어 서버 팀의 리더가 더 경력이 많다거나, 통합 개발 팀의 리더가 서버 측이라거나 하면 거꾸로 앞으로 모든 정렬은 클라이언트가 하게 할 수도 있다.
  • 휘동: 결국 다시 결론은, 조직에서 합의된 품질 기준을 가지는 게 중요하다는 건데 그런 조직은 별로 못 본 것 같다.