티스토리 뷰

제임스 바크(James Bach)의 "Assess Quality, don't measure it"을 번역했습니다. 아이러니하게도 이 글을 보기 며칠 전 셀원들에게 "측정될 수 없는 품질은 관리될 수 없다. 따라서 모든 품질 지표를 객관적으로 측정하고 표시해야 한다" 고 이야기 했었습니다. 이 글을 통해 좀 더 많은 인사이트를 얻고 유연하게 생각을 바꿀 수 있을 것 같습니다. 번역과 블로그 게시에 대해서는 원 저자의 승인을 받았습니다. Happy Testing!


'품질을 어떻게 측정할 수 있는가'는 항상 인기있는 질문이다.
나의 답변은 무척 간단하지만 사람들이 그렇게 좋아하지는 않는 것 같다.

"품질은 측정될 수 있는 것이 아니야. 하지만 논의되고 평가될 수는 있지. '측정'이 아니라 '논의'와 '평가'에 집중하는 것이 좋아"

내 답변이 잘 먹히지는 않는데, 질문과 답에 사용한 단어들이 잘 구별되지 않기 때문이다. 대부분의 사람들은 '측정(measurement)'과 '평가(assessment)'를 같다고 생각한다. 숫자를 좋아하지 않는 사람들이 이런 답변을 할 것 같다. 내 고객들은 내가 대학에서 공학 대신 문헌학을 전공했다는 사실을 알고 나서 놀라고는 한다(하지만 난 숫자를 사랑한다. 다시 대학으로 돌아가도 문헌학을 전공하지는 않을 것이다).

어떻게 답변하는 것이 더 나을까? 두 가지 옵션이 떠오른다. 첫 번째는 이해하기 쉬운 데이터를 예로 드는 것이다. 사실 고객들은 이런 답변을 듣고 싶어 한다. 하지만 이는 정확하게 이 질문('품질을 어떻게 측정할 수 있는가?')에 대한 답변은 아니며, 명확하게 품질을 정의하고 제어해 이를 활용할 수 있도록 해주는 답변도 아니다. 또한 모든 중요한 일들이 사람이나 로봇에 의해 수행될 수 있다고 생각하는 공장식 기술 개발의 패러다임과도 어울리지 않는다.

두 번째는 좀 더 전문가다운 입장에서 측정과 평가의 차이를 설명하고 이 차이를 인지하는 것이 왜 중요한지 이해시키는 것이다. 이 글에서는 좀 더 전문가다운 방법을 사용해 보겠다. 마이클 볼튼(Michael Bolton)은 너무 어려운 글을 쓰면 아무도 읽지 않을 거라고 이야기해 줬다. 그가 옳을 수도 있다. 하지만 때론 사람들이 듣기 싫어하더라도 진실을 말해야 한다. 그렇지 않은가? 오늘 이 글을 쓰면서 느끼는 나의 감정이 딱 그러하다.

측정에 대해 알아보자

'측정'이란 어떤 현상이나 본질, 물질의 속성 중 숫자로 표현할 수 있는 속성의 한 개 혹은 그 이상의 값을 시험적인 방법을 통해 획득하는 과정이다. (시작이 이 정도면 괜찮은거지? 맞지? 살짝 표정이 굳은 것 같은데?) 이 단어의 정의는 International Vocabulary of Metrology 에서 발췌한 것으로 측정이라는 단어의 정의에 대해서는 더 이상의 논란이 없을 정도로 깔끔한 정의라고 할 수 있다.

핵심은 다음과 같다. 즉 측정이란 합리적인 방법으로 사물에 숫자를 할당하는 것이다. 따라서 이런 숫자를 활용한다면 합리적인 결정을 내릴 수 있을 것이다.

과학에서 측정이란 쉽지 않은 영역이다. 소프트웨어 개발에도 측정은 진중하게 수행되어야 하지만 마치 가벼운 연극처럼 보일 때도 있다. 비이성적인 관리 프로세스에서 좀 그럴듯한 과학적인 분위기를 내기 위해 숫자를 동원하는 경우도 있다. 사람들은 테스트 케이스처럼 세어봐도 아무 인사이트를 얻을 수 없는 것들을 세어보려고 한다. 테스트 케이스는 테스트 수행과 관련된 항목이 포함되어 있는 파일에 불과하다. 이는 곧 서류철이나 서랍, 캐비넷, 서류 봉투의 개수를 모두 카운트해 그 사업이 잘되고 있는지 판단하는 것과 같다.

"모두 42,564개의 비즈니스 컨테이너를 가지고 있군요! 사업을 잘하고 있군요!" 라고 하는 것과 같은 것이다.

이것이야말로 소프트웨어 품질 측정을 다시 한 번 생각해 봐야 하는 이유다.

품질은 객관적이고 포괄적으로 측정될 수 없다

측정은 대상의 상태를 알아낼 수 있는 하나의 방법이다. 우리가 만들고 있는 제품의 상태를 알고 싶어 하고, 또한 제품의 많은 것들이 측정될 수 있지만 제품의 품질은 측정될 수 있는 성질의 것이 아니다. 모든 고객과 사용자, 비즈니스 관계자들이 궁금해 하는 "제품의 품질이 좋은지" 혹은 "품질이 지난 달에 비해 좋아졌는지 나빠졌는지"라는 질문에 답이 될 만한 것을 측정한다는 것은 그 어떤 식으로도 불가능하다.

품질을 측정하는 데 가장 어려운 것은 과연 무엇일까? 품질에 대해 생각할 때 우리는 제품이 얼마나 좋은 지를 생각한다. 하지만 이 '좋다'라는 것은 사물이 본질적으로 가지고 있는 속성이 아니다. 이것은 사회적으로 만들어진 속성이라고 할 수 있다. 이 지점에서 우리는 아래 4개의 질문에 맞닥뜨리게 된다.좋다는 것의 정의는 기본적으로 사람의 감정에 기반한다. 그리고 이러한 감정은 다른 사람들과 공유하거나 나누기 힘들다. 인간이 가지고 있는 근본적인 한계다.

- 좋다는 것은 최소한 사람, 제품 그리고 맥락과 관계를 가진다. 사람들의 상태와 그를 둘러싼 환경은 늘 변하기 마련이다. 따라서 실제로는 변한 것이 없지만 품질이 바뀐 것처럼 느낄 수도 있다. 이런 사실은 소셜 미디어에서 극명하게 드러난다. 10년 전엔 그저 농담처럼 들렸을 트윗들이 오늘날 발견된다면 일자리를 잃을 만한 발언일 수도 있다.

- 좋다는 것은 다양한 가치의 신비한 상호작용에 의해 발생하는 하나의 현상이다. 우리가 가지고 있는 기억과 편견이라는 왜곡된 렌즈에 의해 사실은 필터링되고 그에 따라 가치가 달라지기도 한다. 단 하나의 데이터로 품질이 결정되는 것은 아니다. 여러가지 복잡한 데이터가 품질에 영향을 미친다. 측정 전문가들이 말하는 완벽한 "양적 계산(quantity calculus)"이 가능하며 다양한 가치들을 측정하는 기준으로 사용할 수 있는 불변의 공식은 존재하지 않는다. 양적 계산과 같은 방법을 도출해 낼 수 있는 측정 모델도 존재하지 않는다.

- 좋은 것을 판단하는 데에는 사회적 리스크가 감수된다. 우리는 보통 품질이 사람에 미치는 영향에 따라 품질에 관한 정의를 바꾸고는 한다. 예를 들어, 당신에게 단순히 제품이 나쁜지 그렇지 않은지 판단해 보라고 한다면 바로 그 자리에서 당신이 마음 먹은대로 이야기할 수 있을 것이다. 하지만 당신의 솔직하고 직설적인 답변으로 인해 프로젝트가 취소되고 당신의 친구들이 일자리를 잃을 수 있다면, 그래도 냉혹하게 진실만을 이야기할 수 있을까? 아니면 그냥 얼굴만 붉히고 있을 것인가? 이런 상황 역시 한 번쯤은 직면해 봤을 것이다.

품질은 일부분만 측정 가능하다

앞서 말한 내용이 당신을 괴롭게 만들지 않았으면 좋겠다. 다양한 방법으로 요구사항을 정의하고 분류하는 것이 결코 잘못된 일은 아니다. 앞서 말한 내용을 참조한다고 해도 객관적으로 "품질을 측정"할 수 있을지 모르지만 일단 한 번쯤 해보는 것은 의미가 있다. 이를 통해 품질을 평가하는 데 필요한 것이 무엇이지 알 수 있기 때문이다.

어떤 사람들은 품질을 측정한다는 문제에 아주 간단하게 대응한다. 이런 사람들은 고객들이 제한적이고 형식적으로 품질을 이해한다는 것에 착안해 '품질을 측정한다'는 명제를 재 정의해 버린다. 이들은 요구사항을 철저하게 계약 상의 문제로 치부해 버린다. 이들은 제품이 정상적으로 동작하는 것을 증명하기 위해 일련의 인수 테스트를 준비하고 이들 테스트에서 실패가 발생하지 않는다면 제품이 정상 동작한다고 간주한다. 이런 행동을 목표 대치(Goal displacement; 목표를 이루기 위한 수단이 오히려 목표가 되어 버리는 것)라고 부르며, 측정 전문가들이 대체 지표(Surrogate Measure)라고 부르는 결과가 도출되기도 한다. 고객들이 이런 방식에 동의하고 이를 통해 제품에 대한 행복을 느낀다면, 그리고 당신도 고객들이 정말 제품을 통해 행복을 느끼는지 관심을 가지지 않는다면, 이런 방식으로도 충분히 행복해 질 수 있다.

하지만 IT의 역사를 돌아보면 손에 잡히지 않지만 영속하는 존재인 품질을 무시한 결과 시장에서 방치된 제품과 이로 인해 망해버린 회사를 쉽게 찾아볼 수 있다. 나는 개인적으로 고객을 화나게 만들면서까지 부자가 되고 싶지는 않다. 다들 그렇지 않나?

부분적으로는 품질의 측정이 가능하다. 현재 우리에게 필요한 것도 딱 그 정도일 수 있다. 금 덩어리의 정확한 순도와 양을 잴 수 있는 방법을 안다면 기술적으로 이 금 덩어리가 진짜 좋은 것인지, 혹은 얼마나 좋은 것인지 알려줄 수 있는 방법이 없다고 해도 큰 상관이 없다. 단지 금 덩어리를 팔아서 경제적으로 얻을 수 있는 이득이 얼마나 되는지 궁금할 뿐이다.

품질을 측정한다고 말하는 대신, 품질에 관한 실마리를 측정할 수 있다고 말하는 것이 어떨까? 품질을 나타내는 지표를 수집하고 이를 통해 품질을 이해할 수는 있다. 이를 위해 측정 가능한 다양한 데이터를 활용하는 것이다.

제품의 상태에 대한 유용한 평가를 내리는 것이 진정한 목표일지 모른다

주관주의(主觀主義, subjectivity)가 이런 상황에 도움을 줄 것이다. 제품을 별 하나에서 별 다섯 개 까지 등급을 매겨 평가한다면 아마 쉽게 답할 수 있을 것이다. 이런 방법이야말로 감정의 상태를 잘 드러내고 이를 숫자로 표시해 준다. 즉 주관적인 평가를 내리게 만드는 것이다. 본인의 경험에 근거해 제품을 해석하고, 이를 본인만의 스토리텔링 시스템으로 필터링 하는 것이다.

하지만 사실 이런 방식으로 등급을 매기는 것은 신뢰할 수 없는 방식으로 악명이 높다. 만일 제품에 불만이 있다면 그 제품이 아무리 좋다고 해도 별 4개 짜리 리뷰를 쓰지는 않을 것이다. 이미 나는 나의 감정으로 편향되어 있고 부분적으로나마 나의 의견이 제품에 영향을 미치기를 바라기 때문이다. 트렌드와 불연속성, 맥락을 살펴서 좀 더 객관적으로 선택된 숫자에서 의미를 찾아낼 수도 있다. 이런 경우 등급 자체가 고정된 의미를 가지는 것은 아니며, 수집된 데이터에 하나의 정형화된 의미를 부여해 주는 것 뿐이다.

체계적으로 리뷰를 진행하고 데이터의 상대적인 차이에 대해 논의함으로써 단순한 주관적 평가의 가치를 높일 수 있다. 여전히 주관적인 데이터지만, 평가가 좀 더 신뢰할 수 있고 정확해 질 수 있다.

최근에 나는 평가(assessment)라는 말이 "함께 앉아있다(to sit with)"는 말에서 유래했다는 것을 알게 됐다. 그 어원과 용례에 따르면 평가는 어떤 값을 매기기 위한 근거를 찾는 것을 의미한다. 즉 평가라는 단어에는 단순한 측정 이상의 의미가 있는 것이다. 측정을 통해 평가하는 것도 가능하며 꼭 측정이라는 과정을 거치지 않고 도출된 다양한 형태의 근거를 통해 평가를 수행할 수도 있다. 예를 들어, 타이어의 바람이 빠졌는지는 압력 게이지나 별도의 측정기를 사용하지 않더라도 단순히 바람이 빠져보이는 것만으로도 평가가 가능하다.

측정은 목적을 달성하기 위한 하나의 방법에 불과하다. 품질을 평가하기 위해 필요한 양질의 근거를 얻어 사업적 의사 결정, 예를 들어 언제 제품을 배포할 것인지, 제품 팀은 얼마나 훌륭한지, 제품에 문제는 없는지, 문제가 있다면 그것이 수정되지 않고 남아있는지, 혹은 다른 문제가 더 누적되지는 않는지, 문제가 해결되었는지 등의 판단에 활용하는 것이 측정의 궁극적인 목적이다.

아래와 같은 근거를 수집해 품질을 평가할 수 있다.

- 어떻게 테스트를 수행했는가. 무엇을 테스트했고 어떤 것들이 테스트되지 못했는가? 커버리지에 대한 다양하고 흥미로운 해석이 존재한다. 그리고 커버리지에 대한 이해가 없다면, 우리가 이 과정을 통해 얻어낸 것들을 해석할 수 없을 것이다.

- 무엇을 찾아내었는가. 특정한 문제가 있다면 문제가 될 수 있다. 혹은 문제가 없는 것도 문제가 될 수 있다. 우리가 찾아낸 것들이 미치는 영향을 이해할 수 있어야 한다. 단순히 보고된 것들의 개수를 세는 것이 필요한 것이 아니다.

- 사업적 리스크는 어떤 것들이 있는가. 우리가 찾아낸 것들과 프로젝트의 목적을 연관시킬 수 있어야 한다. 또한 사업과 고객과 가지는 관계도 절대 무시해서는 안된다.

이런 문제들이 단순한 공식으로 해결되는 것은 절대 아니다. 사회적인 관계와 수많은 논의를 거쳐야 이런 문제를 해결할 수 있다.

평가를 수행하는 사람에 대한 측정은 결국 시스템적인 기만에 빠지게 된다

소프트웨어 품질을 측정한다는 것은 이를 만드는 사람들을 간접적으로 평가하는 것과 같다. 소프트웨어는 말 그대로 사람이 문제를 풀어가는 과정이 그대로 얼어붙은 흔적과 같다. 경영진이 직원을 감시하는 시스템을 만든다면 직원들 역시 그냥 이를 받아들이지는 않을 것이다. 이들은 시스템을 활용해 어떻게 자신의 장점을 부각시키고 단점을 감출 수 있는지 살펴볼 것이다. 경영진이 복잡하고 다중으로 구성된 근거를 마련하는 대신 그 대안으로 측정이라는 방법을 사용한다면 이런 일들이 더 쉽게 발생할 것이다. 경영진은 직원들이 어떤 것을 악용할 수 있는지에 큰 관심이 없다. 평가에 필요한 모든 측면들이 간단하게 수용 가능한 "KPI"로 좁혀지면 이를 영리하게 조작할 수 있는 여지도 더 많아질 수 밖에 없다.

테스트 자동화 업무를 경험한 사람이라면 모두 알고 있을 것이다. 자동화를 구현하는 작업에 얼마나 많은 시간을 쏟아 부었는지, 그리고 이를 동작하게 만들고 그 상태를 유지하기 위해 또 얼마나 많은 시간을 할애해야 하는지 공개하고 이를 인사 평가에 반영한다면 그 결과는 끔찍할 것이다. 결과물 확인을 자동화하는 것이 쉽다(모든 광고가 그렇게 말하지 않는가!)고 맹목적인 믿음을 갖고 있는 경영진들에 의해 당신은 무능력이나 태만으로 고소당할지도 모른다! 그럼 당연히 초과 근무 시간을 숨길 수 밖에 없을 것이다. 손쉽게 이 모든 것을 할 수 있다. 결국 이렇게 함으로써 경영진들은 자동화가 손쉽게 수행된다는 판타지를 그대로 유지하게 될 것이다. 테스트 케이스 자동화나, 각 유닛 별로 수행되는 자동화라는 측면에서 당신의 업무 진척 상황을 "측정하는" 사람이 없다면 발생하지 않을 기만이라고 할 수 있다.

이것이 오류 최적화(false optimization) 문제라고 하는 것이다. 사람의 판단이 필요한 모든 상황 - 암묵적인 프로세스가 존재하고 부분적으로만 측정이 가능한 - 이 이런 오류에 쉽게 노출될 수 있다. 사람들은 좋은 것을 내세우고 효과적으로 보이지 않는 것들을 숨기려는 경향이 있다. 집에서 파티 준비를 할 때를 떠올려보자. 어질러져 있는 물건을 그냥 뒷방으로 몰아넣고 문을 잠가버리지 않는가? 제품이나 프로젝트를 건강하게 만드는 대신 이들에게 손해가 되는 것들은 다양한 방법으로 최적화가 가능하다. 여기에 문제가 존재한다. 내 경험에 비추어 볼 때 이런 일들이 아주 흔하게 일어나지만, 그렇다고 이들을 명백한 사기로 치부할 필요는 없다. 더 중요한 문제는 "나쁜 숫자"들이 다양한 방법을 통해 "더 나아" 질 수 있다는 것이다. 이를 통해서만 시스템이 실제로 더 나아질 수 있다.

품질을 측정하기 위해 버그의 숫자를 세고 있나? 실제로 품질을 향상시키지 않으면서도, 더 품질이 좋아진 것처럼 보이게 만드는 몇 가지 방법을 소개한다.

  • 자주 버그 리포트를 열람하지 말고, 그들을 추적하지도 마라.
  • 필드에서 발생한 문제를 쉽고 믿을 만한 방법으로 고객에게 알려주지 마라.
  • 발견된 버그의 심각도를 낮춘 다음, 낮은 심각도는 무시하고 넘어가도 좋은 규칙을 만들어라.
  • 문서화된 요구사항을 위반하고 손쉽게 재현 가능하다는 확증을 가진 버그만 보고할 수 있다는 규칙을 만들어라.
  • 다양한 버그 리포트로 다양한 문제를 보고해라.
  • 주니어와 훈련받지 않은 테스터들만 고용하라.
  • 100% 자동화가 당신의 목표이며 수많은 간단한 체크를 자동화 할 수 있다고 말하라. 그러면서 "수 천 개의 테스트를 어떻게 수행하고 있는지" 한껏 뽐내며 자랑하라. 이를 통해 수많은 버그를 찾아낼 수는 없겠지만 아주 바빠 보이고, 보여주기 그럴듯한 수많은 코드를 만들어 낼 수 있을 것이다.
  • 버그가 보고될 때마다 분노하거나 슬픔을 드러내라. 그러면 테스터들은 아무것도 용기내서 보고하지 않을 것이다.
  • 테스팅 업무를 아웃소싱에 맡기고 당신이 품질에 대한 그 어떤 불만도 듣기 싫어 한다는 것을 알려줘라.
  • "품질과 테스팅은 모든 사람이 책임져야 한다"라고 말하면서 테스터들을 잘라라. 버그의 양이 줄어들고 수정하기 쉬운 버그들만 보고될 것이다.

측정하려는 욕구는 마치 사람이 무생물인 것처럼 생각하고 그들을 제어하려는 욕구에서 비롯된다

잘 알다시피 사람은 매우 복잡한 존재다. 사람들과 함께 일한다는 것은 결코 쉬운 일이 아니다. 누군가 "회의가 너무 많아"라고 불평한다면 그것은 예외없이 다른 사람들과 하는 회의와 관계가 있는 것이다. 때로 우리가 잘못된 문서화에 대해 불평을 한다면, 그것은 아마 다른 사람이 작성한 문서에 대한 불만이 있다는 이야기일 것이다. 관리자들은 그들의 의견과 스타일은 내세우지 않고 늘 웃지만 결단력 있으며 유연한 직원들만 채용 되길 바란다.

제품의 품질을 측정해야 한다는 생각은 냉정한 이성을 가진 사람이 아닌, 논쟁을 두려워 하는 사람들이 더 선호하는 명제다. "객관적인 측정"이 버그를 만들어낸 개발자나 불만 투성이 고객에게 향할 어색한 감정이나 분노를 미연에 방지해 줄 것이라고 생각하는 것이다. 근본적으로 사실 이런 생각 자체가 말이 안된다! 나는 수학과 통계학, 확률과 품질 엔지니어링을 좋아한다. 이 주제에 관한 책을 아주 많이 가지고 있다. 사실 이 책들을 모두 쌓아 올리려면 사다리와 안전 가이드가 필요할 정도다. 최소한 내가 숫자를 맹신하는 광신도라는 건 인정해야 할 것이다. 볼랜드 C++의 테스트 관리자로 근무할 때, 제품이 충분한 품질을 가지고 있는지 논의하기 위해 12명의 관리자와 팀을 이룬 적이 있었다. 하지만 그 누구도 지금 만들고 있는 제품의 품질을 측정해 보자라는 제안을 하지 않았다. 아마 우리가 서로 잘 지내왔기 때문에 그랬을거라 생각한다.

품질을 측정하는 대신, 친구를 만들어라.

요약하자면, 나는 데이터를 수집하는 것을 반대하는 것이 아니다.

- 유용한 여러 종류의 데이터가 존재하며 이 중 일부만 측정 가능하다.
- 사업을 운영하기 위해 품질에 대한 객관적인 측정이 필요하다는 개념은 합리적으로 정당화될 수 없다.
- 측정의 대안은 평가라고 할 수 있다. 실제로 누구나 수행하고 있는 것이다. 심지어 품질을 측정하자고 요구할 때도 이미 품질을 평가하고 있는 것이 대부분이다.
- 품질을 평가하는 것은 그 자체가 측정 프로세스가 아니고 측정을 통합할 수 있는 프로세스다.