품질의 상대성과 정치·감정적 본질을 설명하며, 애자일에서 ‘품질’을 누구의 가치로 정의하고 어떻게 의사결정에 반영해야 하는지 사례와 휴리스틱으로 풀어낸다.
일부 애자일 저자들은 나를 "애자일의 할아버지"라고 부른다. 나는 그 말을 나이 든 사람에 대한 폄하가 아니라 칭찬으로 받아들이고 싶다. 할아버지로서, 내가 가장 영향력 있는 글의 상당수는 애자일 운동이 등장하기 훨씬 전에 쓰였다. 그 결과, 새로 등장한 사람들은 그 글들과 오늘날의 애자일 운동 사이의 연결을 종종 알아채지 못한다.
나는 이 블로그에서, 특정 내용을 애자일의 기본과 연결하는 일련의 글로 그 오해를 바로잡으려 한다. 우선 자주 인용되지만 늘 제대로 이해되지는 않는, 내가 정의하는 "품질"에 관한 이 글부터 시작한다. 이 에세이는 How Software is Built의 첫 장에서 발췌·보완한 것으로, 다시 Quality Software Management 제1권을 바탕으로 한 것이다. <_http://www.geraldmweinberg.com/Site/QSM_vol_1.html>
가족에게 일어난 버그
내 여동생의 딸 테라는 우리 집안에서 유일하게 삼촌 제리를 따라 작가가 된 사람이다. 그녀는 의학사의 흥미로운 책들을 쓰고, 나는 마치 내 작품인 것처럼 매번 그 진행을 지켜본다. 그런 이유로, 그녀의 첫 책인 _Disease in the Popular American Press_가 출간되었을 때 본문 일부가 통째로 사라지는 심각한 조판 오류가 여러 군데 발견되어 몹시 낙담했다. 알고 보니 그 오류는 그녀가 사용한 워드 프로세싱 소프트웨어, 즉 내 고객사인 미니코지 소프트웨어 컴퍼니가 내놓은 CozyWrite의 결함 때문이었다는 사실이 더 큰 충격이었다.
테라는 다음번에 미니코지를 방문할 때 이 문제를 이야기해 달라고 내게 부탁했다. 나는 CozyWrite의 프로젝트 매니저를 찾아갔고, 그는 그 오류의 존재를 인정했다.
"드문 버그입니다." 그가 말했다.
"글쎄요, 전 그렇게 보지 않습니다." 내가 맞받았다. "그녀의 책에서만 스물다섯 군데가 넘게 발견했거든요."
"하지만 그런 일은 책 한 권 분량의 대형 프로젝트에서만 일어납니다. 10만 명이 넘는 고객 중에서 저렇게 큰 규모를 단일 파일로 시도한 사람은 10명도 안 되었을 겁니다."
"하지만 제 조카는 알아챘습니다. 그녀에겐 첫 책이었고, 큰 상처를 받았죠."
"물론 안타깝습니다만, 10명의 고객을 위해 그 버그를 고치려는 건 합리적이지 않습니다."
"왜죠? CozyWrite는 책 규모의 프로젝트를 처리할 수 있다고 광고하잖아요."
"그렇게 하려 노력했지만, 그 기능들이 제대로 작동하지 않았습니다. 언젠가는 고치겠지만, 지금 당장은 더 나쁜 버그—수백, 수천 명의 고객에게 영향을 주는—를 만들어낼 가능성이 큽니다. 우리는 옳은 결정을 내렸다고 믿습니다."
이 프로젝트 매니저의 말을 들으면서 나는 감정의 덫에 걸린 자신을 발견했다. 미니코지의 소프트웨어 컨설턴트로서라면 그의 말에 동의해야 했지만, 작가의 삼촌으로서는 그의 논리에 격렬히 반대할 수밖에 없었다. 바로 그 순간 누군가 내게 "CozyWrite는 품질 좋은 제품인가요?"라고 물었다면, 나는 말문이 막혔을 것이다.
당신이라면 뭐라고 대답했겠는가?
품질의 상대성
내가 곤경에 빠진 이유는 품질의 상대성 때문이다. 미니코지 이야기가 명쾌하게 보여주듯, 어떤 사람에게는 충분한 품질이 다른 사람에게는 불충분한 품질일 수 있다.
상대성을 찾아내기
여러 가지 품질 정의를 살펴보면, 언제나 이 상대성을 발견할 수 있다. 다만 이 상대성은 종종 감춰져 있거나, 기껏해야 암묵적인 형태로 존재하므로 주의 깊게 살펴봐야 한다.
예를 들어 크로스비의 정의를 보자.
"품질은 요구사항을 충족하는 것이다."
당신의 요구사항이 하늘에서 직접 내려오지 않는 이상(일부 개발자들은 그렇게 생각하는 듯하지만), 더 정확한 서술은 이렇다.
"품질은 어떤 사람의 요구사항을 충족하는 것이다."
사람이 달라지면 같은 제품이라도 일반적으로 "품질"이 달라진다. 내 조카가 사용한 워드 프로세서가 그 예다. 미니코지에서의 내 딜레마는 다음을 인식하는 순간 풀린다.
a. 테라에게 중요한 사람들은 그녀의 독자들이었다.
b. 미니코지 프로젝트 매니저에게 중요한 사람들은 (대다수의) 그의 고객들이었다.
그 가면 쓴 사람은 누구인가?
요컨대, 품질은 비인간적인 진공 상태에서 존재하지 않는다. 품질에 대한 모든 진술은 _항상 어떤 사람(들)에 관한 진술_이다.
그 진술은 명시적일 수도, 암묵적일 수도 있다. 대부분의 경우 "누구"는 암묵적이며, 품질에 대한 진술은 마치 모세가 돌판에 새겨 시나이 산에서 내려온 계명처럼 들린다. 그래서 소프트웨어 품질에 대한 논의가 생산적이지 못한 경우가 많다. 내 돌판 대 너의 황금 송아지 싸움이 되는 것이다.
품질의 상대성을 포괄하면, 우리는 그런 논의를 더 생산적으로 만들 도구를 갖게 된다. 누군가 소프트웨어 품질의 정의를 주장할 때마다 이렇게 물어보면 된다.
"그 품질에 관한 진술의 뒤에 있는 사람은 누구인가?"
이 휴리스틱을 사용해, 소프트웨어 품질을 구성한다고 여겨지는 몇 가지 익숙하지만 종종 상충하는 생각들을 살펴보자.
a. "무결점이 높은 품질이다."
결함으로 인해 일이 방해받을 수 있는, 예컨대 외科의 같은 사용자에게는
그 결함 때문에 비난을 받게 될 관리자에게는
b. "풍부한 기능이 높은 품질이다."
그 기능들을 활용할 수 있고—또한 그것들의 존재를 알고 있는—사용자에게는
기능이 제품을 판다고 믿는 마케터에게는
c. "우아한 코드가 높은 품질이다."
동료들의 평가를 중시하는 개발자에게는
우아함을 즐기는 컴퓨터공학 교수에게는
d. "높은 성능이 높은 품질이다."
자신의 작업이 기계의 용량을 한계까지 밀어붙이는 사용자에게는
제품을 벤치마크에 제출해야 하는 영업사원에게는
e. "낮은 개발 비용이 높은 품질이다."
소프트웨어를 수천 카피씩 구매하려는 고객에게는
빠듯한 예산을 맡은 프로젝트 매니저에게는
f. "빠른 개발이 높은 품질이다."
자신의 일이 그 소프트웨어를 기다리고 있는 사용자에게는
경쟁자가 들어오기 전에 시장을 선점하려는 마케터에게는
g. "사용자 친화성이 높은 품질이다."
하루 8시간씩 화면 앞에 앉아 소프트웨어를 사용하는 사용자에게는
사용 간격이 길어 인터페이스 세부를 기억하기 어려운 사용자에게는
정치적 딜레마
품질의 상대성을 인식하면 의미론적 딜레마는 종종 해결된다. 이는 커다란 기여이지만, 여전히 정치적 딜레마는 해결되지 않는다.
한 사람의 품질을 더 높이면 다른 사람의 품질은 더 낮아질 수 있다.
예를 들어 우리의 목표가 "총체적 품질"이라면, 관련된 모든 사람들에 대해 합계를 내야 한다. 따라서 이 "총체적 품질" 노력은 모든 관련 인물을 식별하고 참여시키는 포괄적 요구사항 프로세스에서 _시작_해야 한다. 그다음 각 설계, 각 소프트웨어 공학적 접근에 대해, 각 사람별로 품질 척도를 부여해야 한다. 이렇게 부여한 척도를 합산하면 접근 방식마다의 총체적 품질이 산출될 것이다.
물론 실제로 어떤 소프트웨어 개발 프로젝트도 그렇게 정교한 프로세스를 쓰지 않는다. 대신, 의사결정을 내릴 때 다음을 미리 정하는 과정에서 대부분의 사람들이 배제된다.
의사결정을 할 때 누구의 품질에 대한 의견을 반영할 것인가?
예컨대 미니코지의 프로젝트 매니저는 테라의 주장을 듣지도 않은 채, 그의 "소프트웨어 공학적" 결정에서 그녀의 의견에 아주 작은 가중치를 부여했다. 이 사례에서 보듯, 소프트웨어 공학은 민주적 사업이 아니다. 더 나쁘게는 합리적 사업도 아니다. 왜냐하면 "누가 중요한가"에 대한 결정은 대개 감정적인 기반 위에서 내려지기 때문이다.
품질은 어떤 사람에게의 가치
품질의 정치적/감정적 차원은 약간 다른 정의에서 분명해진다. "요구사항"이라는 발상은 이 초기 단계에서 쓰기엔 다소 순진하다. 누구의 요구사항이 가장 크게 반영되는지를 말해주지 않기 때문이다. 더 실용적인 정의는 이렇다.
"품질은 어떤 사람에게의 가치다."
여기서 "가치"란, "사람들이 자신의 요구사항을 충족시키기 위해 기꺼이 지불(또는 수행)하려는 것"을 의미한다. 이를테면, 테라가 내 조카가 아니라 미니코지 소프트웨어 컴퍼니 사장의 조카였다고 해보자. 미니코지 사장이 충동적이고 감정적인 행동으로 유명하다는 걸 알고 있는 그 프로젝트 매니저라면, 워드 프로세서의 "품질"을 다르게 정의했을 것이다. 그 경우, 어떤 결함을 고칠지에 대한 결정에서 테라의 의견은 높은 가중치를 받았을 것이다.
애자일 실천에 미치는 영향
요컨대, "품질"의 정의는 항상 _정치적_이고 _감정적_이다. 왜냐하면 언제나 누구의 의견이 중요하며, 그 의견들이 서로에 비해 얼마나 중요한지에 대한 일련의 결정을 수반하기 때문이다. 물론 대부분의 경우 이런 정치적/감정적 결정—모든 중요한 정치적/감정적 결정이 그렇듯—은 대중의 시야에서 감춰져 있다. 우리 소프트웨어 사람들은 합리적으로 보이고 싶어 한다. 그래서 이 품질 정의가 애자일 접근법에 미치는 영향을 제대로 알아차리는 사람이 드물다.
더 어려운 점은, 대부분의 경우 이런 결정들이 그것을 내리는 사람들 자신의 의식에도 감춰져 있다는 사실이다. 그래서 애자일 팀이 하는 가장 중요한 행동 가운데 하나가, 비록 항상 대중에게 공개되지는 않더라도, 그런 결정을 의식 위로 끌어올리는 일이다. 그리고 개방형 프로세스(애자일처럼)로 일하는 개발 팀이, 혼자 일하는 한 명의 개발자보다 더 타당한 품질 정의에 이를 가능성이 큰 이유도 여기에 있다. 내게 있어서, 비밀스러운 구성 요소가 하나라도 있는 팀은 애자일이라고 보지 않는다.
고객 지원은 애자일 프로세스가 강조하는 또 하나의 영역이며, 이 품질 정의는 "고객" 선정에도 지침을 준다. 간단히 말해, "고객"은 의미 있는 모든 "품질"의 정의를 적극적으로 대표할 수 있어야 한다. 품질의 구성 요소 중 하나라도 빠져 있으면, 그 측면에서 결함 있는 제품으로 이어질 가능성이 크다. 내가 소위 애자일 팀을 컨설팅할 때마다, 그들이 제품의 품질에 대한 다양한 관점을 적절히 대표하는 사람들의 적극적인 참여를 확보하고 있는지 확인한다. 만약 그들이 "이렇게 많은 사람을 만족시키느라 신경 쓰지 않으면 우리는 더 agile해질 수 있다"라고 말한다면, 그들은 실제로 더 민첩해질 수는 있겠지만, 분명 대문자 'Agile'은 아니다.
