3.0 3부 소개: 개발자 경험과 SPACE 프레임워크

2부는 전달을 외부로부터 측정했다: 코드가 파이프라인을 통해 얼마나 빠르고 안전하게 이동하는지. 이 부는 그 코드를 만드는 사람들의 경험을 측정하며, 전달 메트릭 집합만으로는 그 배후의 사람들이 번아웃을 겪거나, 방해에 빠져 허우적대거나, 조용히 이탈하는 동안에도 훌륭해 보일 수 있기 때문에 존재한다. DORA 메트릭만 지켜보는 조직은 이직, 품질 붕괴, 혹은 번아웃이 그 이득을 한꺼번에 지워 버리기 직전까지 1~2년 동안 팀을 더 세게 쥐어짜서 그것들을 개선할 수 있다. 이 부는 그 균형추다.

중심에는 Microsoft, GitHub, 빅토리아 대학교의 연구자들이 코드 줄 수나 커밋 수 같은 단일하고 게임하기 쉬운 대리 지표로 개발자 생산성을 측정하는 업계의 습관에 대한 교정책으로 특별히 개발한 SPACE 프레임워크가 있다. SPACE는 다섯 가지 차원에 걸쳐 있다: 만족도와 웰빙, 성과, 활동, 소통과 협업, 그리고 효율과 플로우. 이 프레임워크의 핵심 규율, 그리고 이 부가 2부가 그 자체의 플로우 메트릭에 적용하는 것과 동일한 엄격함으로 그것을 다루는 이유는, 어떤 단일 차원도 그 자체로는 신뢰할 수 없다는 것이다. 가치는 특별히 다섯 가지 모두를 함께 염두에 둘 때 오며, 그래야 팀이 다른 축을 조용히 손상시키면서 한 축에서 좋아 보일 수 없다.

대규모 팀에게 개발자 경험 메트릭은 DORA가 답할 수 없는 질문에 답한다: 이 전달 성과는 지속 가능한가, 그리고 조직은 그것을 만들어 내는 사람들을 유지하고 있는가. 이 부를 무시하는 엔터프라이즈 조직은 흔히 피해가 이미 이루어진 한참 후, 이직 데이터와 퇴사 인터뷰를 통해 그 비용을 발견한다. 순전히 보상만으로 경쟁할 능력을 제한하는 공공 부문 급여 제약 아래서 운영되는 경우가 흔한 정부 조직은 개발자 경험을 뒷전이 아니라 일급의, 능동적으로 관리되는 관심사로 취급할 특히 강한 이유를 가지고 있다.

이 부의 주제

3.1 SPACE 프레임워크: 다섯 가지 차원을 함께, 왜 어느 하나도 홀로는 신뢰할 수 없는지, 그리고 그것들로부터 진정으로 균형 잡힌 메트릭 집합을 구축하는 방법.
3.2 만족도와 웰빙 메트릭: 성취감, 좌절, 번아웃 위험을 측정하는 것, 어떤 시스템 텔레메트리도 직접 관측할 수 없는 차원.
3.3 성과 메트릭과 결과 대리 지표: 활동과 가장 쉽게 혼동되는 차원, 그리고 대신 진정한 결과 기여를 측정하는 방법.
3.4 활동 메트릭과 그 한계: 커밋 수, 코드 줄 수, 그리고 이것이 왜 과도하게 가중치를 두기 가장 위험한 차원인지.
3.5 소통과 협업 메트릭: 정보가 사람과 팀 사이를 실제로 어떻게 흐르는지, 그리고 건강한 패턴이 어떻게 보이는지.
3.6 효율과 플로우: 깊은 작업과 방해: 실제 엔지니어링 작업이 필요로 하는 방해받지 않는 시간을 보호하는 것, 그리고 그것을 침식하는 마찰을 측정하는 것.
3.7 개발자 경험 설문과 DevEx 메트릭: 인기 콘테스트가 아니라 신뢰할 수 있는 신호를 만들어 내는 설문을 운영하는 방법, 그리고 그것을 객관적인 데이터와 결합하는 방법.

이 주제들이 서로 연결되는 방식

주제 3.1은 다섯 가지 SPACE 차원 모두를 함께 소개하고, 주제 3.2부터 주제 3.6까지는 SPACE 연구자들이 제시하는 순서로 각 차원을 차례로 실제 깊이 있게 다룬다. 주제 3.7은 만족도, 성과, 협업 모두 부분적으로 자가 보고 데이터에 의존하기 때문에(주제 1.5의 계측 대 자가 보고 구분이 이 부 전체에 직접 관련된다) 그리고 잘못 설계된 설문이 앞선 모든 주제를 무너뜨리기 때문에, 설문 설계의 실용적인 메커니즘으로 이 부를 마무리한다.

이 부의 핵심 규율, 즉 하나에서의 강점이 아니라 차원 전반에 걸친 균형은, 전달 파이프라인이 아니라 사람에게 적용된 주제 1.3의 산출물보다 결과 원칙에 대해 이 책이 가진 가장 명확한 실제 적용 사례다. 활동(주제 3.4)은 순수한 산출 메트릭에 가장 유사한 SPACE 차원이며, 이 부는 그것을 그에 맞게 취급한다: 다섯 중 하나의 입력으로서는 유용하지만, 독립형 신호로서는 위험하다. 2부와 함께 읽으면, 이 부는 DORA만으로는 제공할 수 없는 그림을 완성한다: 단지 소프트웨어가 빠르고 안전하게 출시되는지뿐 아니라, 그것을 출시하는 사람들이 그 속도를 지속할 수 있는지.