1.1 소프트웨어 공학을 왜 측정하는가

개요 및 동기

소프트웨어 공학은 제조업과는 다른 방식으로 측정에 저항한다. 공장 생산 라인은 동일한 단위를 생산하므로, 그 수를 세는 것은 실제적인 의미를 알려준다. 소프트웨어 작업은 끊임없이 변화하는 요구 사항 아래서 저마다 유일무이한 산출물을 만들어 내므로, 커밋 수, 코드 줄 수, 닫힌 티켓 수 같은 순진한 계수는 전달된 가치에 대해 거의 아무것도 말해 주지 않는다. 소프트웨어 작업을 측정하는 어려움과 그것이 잘되어 가고 있는지 알아야 한다는 매우 실질적인 필요 사이의 그 간극이야말로 이 책 전체가 자리하는 곳이다. 이 주제는 그 간극을 정직하게 메우는 일을 다룬다. 소프트웨어 작업이 부품처럼 셀 수 있는 척하는 것이 아니라, 측정이 엔지니어링 조직을 위해 무엇을 할 수 있고 무엇을 할 수 없는지 정밀하게 밝히는 방식으로 말이다.

측정은 조직이 그렇지 않으면 자신 있게 답할 수 없는 질문에 답하기 위해 존재한다: 우리의 전달 속도는 빨라지고 있는가 느려지고 있는가, 품질은 개선되고 있는가 악화되고 있는가, 엔지니어들은 번아웃을 겪고 있는가, 이 투자는 성과를 내고 있는가. 메트릭이 없으면 이러한 질문은 그 자리에서 가장 자신 있게 말하는 사람, 보통은 가장 고위이거나 가장 설득력 있는 사람이 대답하게 되며, 그 대답은 자주 틀린다. 소프트웨어 공학 팀이 측정을 건너뛴다고 해서 자신의 성과에 대한 판단을 회피하는 것은 아니다. 그들은 단지 증거 대신 분위기와 일화, 최근성 편향에 기대어 그 판단을 내릴 뿐이다.

대규모 팀에게 이것은 있으면 좋은 것에서 구조적인 것으로 바뀐다. 여섯 명으로 이루어진 팀은 매일의 대화를 통해 일이 어떻게 되어 가는지에 대한 공유된 심상 모델을 가질 수 있다. 시간대와 사업부에 걸쳐 흩어진 육백 명 규모의 부서는 그럴 수 없다. 그 규모에서는 공유되고 신뢰받는 일련의 수치야말로 소규모 팀이 공짜로 얻는 비공식적 인식을 대체할 유일하고 실용적인 수단이다. 엔터프라이즈 리더십은 같은 예산을 두고 경쟁하는 수십 개 팀에 투자를 배분하기 위해 메트릭이 필요하다. 정부 엔지니어링 조직은 배정된 자금이 단순한 활동이 아니라 실질적인 역량을 만들어 냈음을 입법부와 대중에게 입증하기 위해 메트릭이 필요하다. 두 상황 모두에서 “우리는 열심히 일했다”는 증거가 아니다. 방어 가능한 수치가 증거다.

핵심 원칙

판단하기 위해서가 아니라 배우기 위해 측정하라. 엔지니어링 메트릭의 일차적인 목적은 의사 결정을 알리는 것이지, 사람이나 팀에 점수를 매기는 것이 아니다.
결정이 붙어 있지 않은 수치는 장식이다. 메트릭의 어떤 값도 다음에 할 일을 바꾸지 않는다면, 그것은 대시보드에 있을 자격이 없다.
측정은 수단이지 목표가 아니다. 목표는 지속 가능한 팀에 의해 더 신뢰성 있게 전달되는 더 나은 소프트웨어다. 메트릭은 오직 그 목표에 봉사하기 위해서만 존재한다.
모든 메트릭에는 비용이 든다. 계측, 검토 시간, 그리고 주제 1.2에서 다루는 행동 왜곡 위험은 모두 무언가의 대가를 치른다. 메트릭은 그 비용을 되갚아야 한다.
침묵 역시 하나의 결정이다. 무언가를 측정하지 않기로 선택하는 것은 결과를 수반하는 선택이지, 중립적인 기본값이 아니다.

권장 사항

대시보드가 아니라 결정에서 시작하라

무언가를 계측하기 전에, 그 메트릭이 알려줄 결정에 이름을 붙여라. “새로운 배포 파이프라인이 장애율을 줄였는지 알고 싶다”는 결정 형태의 질문이다. “도구가 내보낼 수 있는 모든 것을 추적하자”는 그렇지 않다. 결정에서 거꾸로 작업하면 메트릭 집합을 작게 유지할 수 있고, 누군가 왜 그것이 존재하는지 물을 때 모든 타일을 방어할 수 있다. 어떤 메트릭이 알려줄 결정의 이름을 댈 수 없다면, 아직 그것을 만들지 마라. 이 규율의 결과-대-산출물 버전은 주제 1.3에서 더 깊이 다룬다.

진단적 사용과 평가적 사용을 분리하라

시스템 문제를 진단하는 데(왜 우리의 리드 타임이 서서히 늘어나고 있는가) 쓰이는 메트릭은 동일한 메트릭이 사람이나 팀을 평가하는 데(누구의 리드 타임이 가장 나쁜가) 쓰일 때와 완전히 다르게 작동한다. 전자는 조사와 개선을 유도한다. 후자는 은폐와 게임을 유도하는데, 이제 그 수치에 평판이나 금전적 결과가 딸려 있기 때문이다. 어떤 용도로 메트릭을 쓸 것인지 명시적으로, 서면으로 결정하고, 진단용 메트릭이 위험을 의도적으로 재검토하지 않은 채 평가용 사용으로 슬며시 넘어가게 두지 마라. 이 구분은 이 책 전체에서 계속 반복되며, 주제 1.4에서 설명하는 메트릭 헌장의 비-목표 절에서 공식화된다.

측정을 사실이 아니라 가설로 다루라

메트릭은 당신이 실제로 관심을 두는 것에 대한 대리 지표이지, 그 자체가 아니다. 배포 빈도는 전달 역량에 대한 대리 지표이지, 전달 역량 그 자체가 아니다. 모든 메트릭을 지속적으로 검증되어야 할 가설로 다루라: 이 수치가 여전히 우리가 신경 쓰는 것을 추적하고 있는가, 아니면 세상이 변해서 대리 지표를 뒤에 남겨 두고 떠났는가? 특히 도구, 팀 구조, 혹은 (7부 참조) 작업 자체의 성격이 변화함에 따라, 2년 전에 잘 선택된 메트릭이 오늘날에도 여전히 잘 선택되어 있다고 가정하기보다는 이 질문을 정해진 주기로 다시 검토하라.

측정의 부재를 가시화하라

대규모 조직에서 가장 위험한 간극은 나쁜 메트릭이 아니라, 계측하기 어렵다는 이유로 아무도 측정하지 않는 영역이다: 개발자 경험, 팀 간 의존성 마찰, 조직 지식의 침식. 이러한 간극이 기본값으로 보이지 않게 남아 있게 두는 대신, 메트릭 헌장에서 명시적으로 이름을 붙여라. 무엇을 측정하지 않고 있는지, 그리고 왜 그런지 아는 조직은 그런 영역이 존재한다는 사실을 조용히 잊어버린 조직보다 훨씬 더 강한 위치에 있다.

트레이드오프: 장단점

접근법	장점	단점
무거운 계측, 많은 메트릭	폭넓은 가시성, 적은 사각지대	대시보드 피로, 더 넓은 게임 표면, 더 높은 유지 비용
최소한의, 결정 주도형 메트릭	집중, 낮은 오버헤드, 모든 메트릭이 방어 가능	선택된 집합 밖에서 떠오르는 문제를 놓칠 위험
진단 전용 메트릭	정직한 보고와 조사를 장려	리더십이 여전히 비공식적으로 평가적으로 사용할 수 있음
개인 평가와 연동된 메트릭	책임감이 느껴지고 경영진에게 설명하기 쉬움	강한 게임 유인; 신뢰 훼손; 보통 잘못된 것을 측정함

핵심 긴장은 범위 대 집중이며, 이는 진단 대 판단에 의해 더욱 날카로워진다. 메트릭이 너무 적으면 위기로만 드러나는 사각지대가 생기고, 너무 많으면 아무도 그중 어느 것에 대해서도 행동할 수 없으며, 평가적 무게를 부여한 모든 메트릭은 왜곡을 초래한다. 최소한의, 결정 주도형으로 시작하여 특정한, 이름 붙여진 결정이 필요로 할 때만 메트릭을 추가하고, 진단 전용 경계가 기본값으로 침식되게 두는 대신 주제 1.4의 거버넌스 작업에서 명시적으로 그것을 방어함으로써 해결하라.

팀과 논의할 질문

우리의 현재 대시보드에 있는 각 메트릭에 대해, 좋은 값과 나쁜 값은 각각 어떤 결정을 촉발하는가? 두 값이 같은 행동으로 이어지거나, 혹은 아무 행동으로도 이어지지 않는다면, 그 메트릭은 장식이다. 대시보드를 타일 하나하나 훑으며 각각에 대해 정직한 답을 강제하라. 이 훈련은 보통 단 한 번의 자리에서 부풀어 오른 대시보드를 절반으로 줄이는데, 대부분의 난립은 누군가 의도적으로 추가한 여전히 유효한 이유가 있는 메트릭이 아니라 아무도 결코 제거하지 않는 메트릭에서 쌓이기 때문이다.
우리의 메트릭 중 어느 것이 진단적으로 사용되고, 어느 것이 조용히 평가적으로 바뀌었는가? 시스템 제약을 이해하기 위해 만들어진 메트릭은 아무도 의도적으로 결정하지 않은 채 팀이나 개인을 순위 매기는 데 쓰이도록 표류할 수 있으며, 종종 검토 회의에서의 무심한 발언이 습관이 되면서 그렇게 된다. 그런 표류가 일어나면 그 수치는 더 이상 신뢰할 수 없게 되는데, 이제 사람들이 그것을 정확하게 만들기보다 좋아 보이게 만들 이유가 생기기 때문이다. 모든 메트릭의 의도된 용도를 서면으로 명시하고 현재 관행을 그에 비추어 확인하라.
계측하기 어렵다는 이유로 우리가 측정하지 않는 것은 무엇이며, 그 간극은 우리에게 어떤 비용을 치르게 하는가? 가장 위험한 사각지대는 바로 쉬운 측정에 저항하기 때문에 대시보드에 결코 올라가지 않는 것들이다: 팀 간 의존성 마찰, 조직 지식의 침식, 또는 취약한 임시방편의 조용한 축적. 모두가 은밀히 걱정하지만 아무도 추적하지 않는 것들의 목록을 가져와, 왜 그런지 솔직해져라.
만약 우리가 내일 이 메트릭을 삭제한다면, 누가 알아챌 것이며, 그들은 무엇을 잃을 것인가? 아무도 그리워하지 않을 메트릭은 어떤 결정도 알려주지 않는 메트릭이다. 이 질문은 순전히 관성으로 살아남은 허영 타일을 드러낸다. 수십 개의 팀 대시보드를 보유한 대규모 조직에서는 새로운 메트릭을 추가하는 규율만큼이나 이러한 가지치기 규율이 중요하다.
계측 뒤에 있는 엔지니어링 시간을 포함하여, 우리 대시보드의 각 메트릭을 생산하고 유지하는 데 실제로 얼마나 비용이 드는가? 메트릭은 공짜가 아니다. 파이프라인, 대시보드, 그리고 수치를 논의하는 데 쓰인 검토 시간은 모두 반복되는 비용을 수반하는데, 이는 하나의 눈에 띄는 항목이 아니라 여러 작은 작업에 분산되어 있어 과소평가하기 쉽다. 실제 계측 및 유지 보수 노력을 가져와 질문 1의 결정 가치와 견주어 보라.
측정이 판단을 대체해 버린 곳은 어디이고, 판단이 측정을 대체해 버린 곳은 어디인가? 두 실패 양상 모두 실재한다. 모든 결정을 대시보드에 외주하는 팀은 수치가 놓치는 것을 잡아내는 맥락적 판단력을 잃는다. 이용 가능한 데이터를 무시하고 그 자리에서 가장 목소리 큰 사람을 따르는 팀은 이 주제가 문을 여는 바로 그 문제를 반복한다. 목표는 판단을 알려주는 메트릭이지, 판단을 대체하는 메트릭이 아니다.

분야별 관점

스타트업. 소수의 엔지니어만 있다면, 이 주제가 경고하는 대부분의 것들, 즉 평가적 사용으로의 표류, 사각지대, 대시보드 팽창은 모두가 매일 대화를 나눈다는 단순한 이유만으로 피하기 쉽다. 위험은 정반대다: 팀이 감당할 수 없는 오버헤드처럼 느껴져 측정을 아예 건너뛰는 것이다. 두세 개의 결정 형태 질문을 골라(우리는 충분히 빠르게 출시하고 있는가, 품질은 유지되고 있는가) 그것만 계측하라.

중소기업. 전담 플랫폼 팀이나 데이터 팀 없이는, 맞춤형 계측을 구축하기보다 이미 가지고 있는 도구가 보고하는 것에 기대라. 결제 처리업체의 대시보드, 지원 도구의 응답 메트릭, CI 제공업체의 빌드 이력은 보통 가장 중요한 결정을 다룬다. 그것이 알려주는 것에 따라 행동할 것임을 입증하기 전에 전담 엔지니어링 분석 플랫폼을 구매하고 싶은 유혹을 물리쳐라.

엔터프라이즈. 핵심 위험은 관리 계층을 거쳐 올라가면서 진단에서 평가로 조용히 표류하는 메트릭과, 가지치기의 책임을 아무도 지지 않아 축적을 통해 성장하는 대시보드다. 이 규모에서 거버넌스(주제 1.4)는 선택이 아니다. 사업부 전반에 걸쳐 정의를 표준화하고, 정기적인 은퇴 검토를 메트릭 프로그램 자체에 구축하라.

정부. 여기서 메트릭은 종종 법적 또는 예산상의 무게를 지니며, 이는 그것을 제대로 얻는 것의 가치와 잘못 얻는 것의 비용을 모두 높인다. 입법부나 감독 기구에 보고되는 수치는 문서화된 방법론, 보고 기간에 걸쳐 안정적인 정의, 그리고 그 한계에 대한 정직함을 필요로 한다. “우리는 현재 이것을 측정하지 않는다”를 숨겨야 할 개인적인 결함이 아니라 방어해야 할 수도 있는 답변으로 취급하라.

사례

엔터프라이즈. 한 글로벌 보험 회사의 엔지니어링 조직은 예순 개가 넘는 스크럼 팀으로 성장했고, 각각 자체적인 비공식 대시보드를 가지고 있었으며, 서로 비교할 수 있는 것이 없었다. 리더십은 기본적인 질문에 답할 수 없었다: 우리의 열 개 전략적 플랫폼 투자 중 실제로 더 빠른 소프트웨어를 전달하고 있는 것은 어느 것인가. 해결책은 더 많은 메트릭이 아니라 더 적고 더 나은 메트릭이었다: 조직은 동일한 파이프라인 데이터로부터 어디서나 동일하게 계산되는, 공유되고 결정 주도적인 DORA 메트릭(주제 2.10)의 핵심을 정의하고, 마흔 개의 팀별 대시보드를 은퇴시켰으며, 두 분기 만에 마침내 투자 영역을 공통된 기준으로 비교할 수 있었다.

정부. 한 국가 세무 기관의 디지털 서비스 팀은 감독 위원회로부터 다년간의 현대화 프로그램의 수익을 입증하라는 요청을 받았다. 팀의 기존 메트릭은 전적으로 내부적이고 활동 기반이었다: 완료된 스토리 포인트, 종료된 스프린트. 그 어느 것도 위원회의 실제 질문에 답하지 못했다. 팀은 대신 작은 결과 메트릭 집합을 구축했다: 시민의 신고 문제를 해결하는 중앙값 시간, 디지털 채널 채택률, 그리고 새 시스템의 누락 결함률이었으며, 이를 문서화된 방법론과 함께 분기별로 보고했다. 위원회의 질문은 “당신이 일하고 있다는 것을 증명하라”에서 “이것을 다음 기관에서 어떻게 복제할 것인가”로 바뀌었는데, 이것이야말로 잘 선택된 메트릭 집합이 만들어 내야 하는 결과다.

비즈니스 사례: 동기, ROI, TCO

의도적인 측정의 수익은 의사 결정의 질이다. “플랫폼 투자 이후 리드 타임이 30% 개선되었다”고 증거를 가지고 말할 수 있는 조직은 그 투자를 방어하고, 효과가 있었던 것을 반복하며, 효과가 없었던 것을 멈출 수 있다. 일화에 의존하는 조직은 이 중 어느 것도 자신 있게 할 수 없으며, 양측이 모두 신뢰하는 수치를 아무도 제시할 수 없기 때문에 매 예산 주기마다 같은 논쟁을 다시 벌이게 된다.

측정의 비용은 대시보드가 아니다. 그것은 지속적인 규율이다: 계측, 정의 유지 보수, 그리고 이 주제가 권장하는 정기적인 가지치기. 그 총 소유 비용은 실재하지만, 그 자리에서 가장 설득력 있게 주장한 사람을 근거로 수백만 달러 규모의 기술 결정을 내리는 대규모 조직이라는 대안의 비용에 비하면 미미하다. 메트릭 프로그램의 수익은 메트릭 그 자체가 아니다. 그것은 메트릭 덕분에 더 잘 내려진 결정이다.

안티패턴과 함정

도구가 내보내는 모든 것을 측정하기: 대시보드를 잡음으로 바꾸고, 상응하는 결정 가치 없이 거대한 표면에 걸쳐 게임을 초대한다.
이름 붙여진 결정이 없는 메트릭: 유지 보수 노력을 소모하면서 아무에게도 실행 가능한 것을 알려주지 않는 장식.
진단에서 평가로의 조용한 표류: 수치에 대한 신뢰를 파괴하는 가장 빠른 단일 방법.
메트릭을 가설이 아니라 사실로 취급하기: 2년 전에 옳았던 대리 지표가 오늘은 틀릴 수 있으며, 아무도 확인하지 않는다.
나쁜 수치의 부재를 좋은 수치의 존재로 착각하기: 결코 들여다보지 않는 메트릭은 무언가가 잘못되었다고 말해 줄 수 없다.
무엇을 결정할지 정하기 전에 측정 역량부터 구축하기: 질문을 찾아다니는 계측은 실제 엔지니어링 시간을 낭비한다.

성숙도 모델

1단계, 시작: 메트릭이 존재한다면, 그것은 즉흥적이고, 그것을 만든 사람에게만 개인적이며, 아무도 그중 어느 것이 어떤 결정을 알려주는지 말할 수 없다.
2단계, 개발: 일부 팀에 기본적인 메트릭 집합이 존재하지만, 대부분 프레임워크나 도구의 기본값에서 복사된 것으로, 결정으로의 명확한 연결이 없다.
3단계, 표준화: 추적되는 모든 메트릭은 문서화된 목적과 명시적인 진단-대-평가 분류를 가지며, 조직 전반에 걸쳐 일관되게 적용된다.
4단계, 관리: 메트릭은 그것이 알려주는 결정에 비추어 정해진 주기로 검토되며, 더 이상 자기 몫을 하지 못하는 메트릭은 은퇴하고, 전체 집합은 가치뿐 아니라 비용으로도 측정된다.
5단계, 조율: 측정은 살아 있는 역량이다: 조직은 스스로의 사각지대를 정기적으로 식별하고, 자신의 대리 지표가 여전히 현실을 추적하고 있는지 검증하며, 메트릭 프로그램 자체를 그저 유지할 것이 아니라 개선할 대상으로 취급한다.

논의를 위한 아이디어

오늘 당장 물어본다면 우리가 유지하는 것을 정당화하기 가장 어려울 대시보드 메트릭은 무엇인가?
지난 분기에 우리가 의견이 아니라 메트릭을 이용해 내린 결정은 무엇인가?
우리 조직의 어디에서 진단용 메트릭이 조용히 평가용으로 바뀌었는가?
우리가 측정하기를 두려워하는 것은 무엇이며, 왜 그런가?
만약 우리의 메트릭 프로그램이 내일 사라진다면, 어떤 결정이 더 나빠질 것인가?

핵심 요약

측정은 그 자체를 위해 존재하는 것이 아니라 결정에 봉사하기 위해 존재한다. 결정이 붙어 있지 않은 메트릭은 장식이다.
진단적 사용과 평가적 사용을 서면으로 분리하고, 그 사이의 조용한 표류를 경계하라.
모든 메트릭을 확정된 사실이 아니라 그것이 나타내는 것에 대한 가설로 취급하고, 그 가설을 정기적으로 다시 검토하라.
침묵, 즉 무언가를 측정하지 않기로 선택하는 것 그 자체가 결과를 수반하는 결정이다. 사각지대가 기본값으로 보이지 않게 남아 있게 두는 대신 가시화하라.
메트릭 프로그램의 총비용은 실재한다. 각 메트릭이 제공하는 결정 가치에 비추어 그것을 명시적으로 저울질하라.

참고 문헌 및 추가 자료

Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
Hubbard, Douglas W. How to Measure Anything: Finding the Value of Intangibles in Business. Wiley, 2014.
Austin, Robert D. Measuring and Managing Performance in Organizations. Dorset House, 1996.
Kahneman, Daniel. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.
Google DevOps Research and Assessment (DORA) 프로그램, dora.dev.