소프트웨어 엔지니어링 메트릭이란 무엇인가

소프트웨어 엔지니어링 메트릭은 소프트웨어 개발 프로세스, 제품, 팀의 품질, 효율, 영향을 평가하고 추적하고 개선하는 데 쓰는 정량적 척도다. 잘 쓰면 체계적인 진단 도구로 작동한다. 운영상의 병목을 드러내고, 기술 부채 상환을 정당화하며, 엔지니어링 활동을 구체적인 비즈니스 성과와 정렬한다. 잘못 쓰면 행동을 왜곡하고, 신뢰를 갉아먹고, 바로 그릇된 것에 보상을 준다.

이 책이 존재하는 이유는 대부분의 팀이 메트릭이 무엇을 위한 것인지 정하기도 전에 메트릭부터 집어 들기 때문이다. 대시보드는 세기 쉬운 모든 것으로 채워지고, 경영진은 “이 숫자가 올랐나요, 내렸나요”를 묻기 시작하며, 한 분기가 지나면 팀은 숫자가 대표해야 했던 성과가 아니라 숫자 그 자체를 최적화하고 있다. 이 실패에는 이름이 있다. 굿하트의 법칙이다. 측정 지표가 목표가 되면 더 이상 좋은 측정 지표가 아니다. 이 책의 모든 주제는 이 법칙을 뒤에 두고 쓰였다.

두 가지 기초 프레임워크

업계는 엔지니어링 전달과 팀 건강을 측정하는 데 연구에 기반한 두 가지 프레임워크로 대체로 수렴했다.

DORA 메트릭(DevOps Research and Assessment 프로그램에서 나왔다)은 시스템의 처리량과 안정성을 측정한다. 배포 빈도, 변경 리드 타임, 변경 실패율, 실패한 배포로부터의 복구 시간이다. 이 책의 2부는 이 네 가지를 하나의 전용 참조 주제에서 다루며, 전달과 플로우 메트릭을 더 넓게 조직하는 데 쓰는 플로우 프레임워크(Flow Framework)도 함께 다룬다. DORA는 파이프라인의 기계적 작동을 잘 측정하지만, 그 파이프라인을 통해 어떤 종류의 가치가 흐르는지는 아무것도 말해 주지 않기 때문이다.

SPACE 프레임워크는 Microsoft, GitHub, 빅토리아 대학교의 연구자들이 만들었으며, 원시 처리량을 개발자 경험의 다섯 차원으로 균형 잡는다. 만족과 웰빙, 성과, 활동, 소통과 협업, 효율과 플로우다. 3부에서 깊이 다룬다.

이 두 프레임워크 너머에서 팀은 영역별로 묶인 로컬 메트릭을 추적한다. 코드와 품질 메트릭(4부), 제품과 비즈니스 메트릭(5부), 신뢰성, 운영, 보안 메트릭(6부)이다. 7부는 이미 진행 중인 변화를 다룬다. 생성형 AI 도구가 원시 코드 출력을 사실상 무료로 만들었고, 그 결과 업계가 10년 동안 의존해 온 몇몇 메트릭이 예전과 같은 의미를 갖지 못하게 되었다.

이 책의 독자

주된 독자는 팀이 무엇을 왜 측정할지 고르는 사람들이다. 엔지니어링 리더, 스태프 및 프린서펄 엔지니어, 플랫폼 및 DevOps 팀, 그리고 처음으로 메트릭 대시보드나 스코어카드를 만들거나, 행동을 왜곡하기 시작한 것을 고치려는 프로그램 및 제품 관리자다. 부차적인 독자는 자기 조직이 왜 지금 추적하는 것을 추적하는지, 메트릭이 오용될 때 어떻게 반박할지 이해하고 싶은 모든 엔지니어다.

읽는 방법

여기서 시작해서, 책이 어떻게 구성되어 있는지 보려면 서론을 읽거나 곧바로 목차로 건너뛰어라. 각 주제는 독립적으로 읽힌다. 원칙을 먼저 서술하고, 구체적인 권고를 제시하고, 다루는 메트릭이 어떻게 조작되는지 짚고, 성숙도 모델, 토론 질문, 참고 문헌으로 끝난다. 활용하려고 책을 처음부터 끝까지 읽을 필요는 없다.