1.10 엔지니어링 효과성과 개발자 생산성

개요와 동기

큰 소프트웨어 조직의 모든 리더는 결국 같은 질문의 변형을 던집니다. 우리는 소프트웨어를 만드는 일을 점점 더 잘하고 있는가, 그리고 어떻게 알 수 있는가? 이 장은 그 질문에 정직하게 답하는 이야기입니다. 엔지니어링 효과성은 조직이 엔지니어링 노력을 가치 있고 믿을 수 있는 소프트웨어로 얼마나 잘 바꾸는가입니다. 개발자 생산성은 그 개인과 팀의 측면입니다. 개발자가 얼마나 유용한 산출물을 낼 수 있는지, 그리고 작업 환경이 개발자의 시간과 주의를 빼앗는 대신 얼마나 돌려주는지입니다.

누군가 이것을 하나의 숫자로 줄이려는 순간 문제가 시작됩니다. 코드 줄 수를 세면 사람들은 더 많은 코드를 씁니다. 스토리 포인트를 세면 추정이 부풀려집니다. 커밋, 풀 리퀘스트, 책상에 앉은 시간을 세면 진전이 아니라 움직임에 보상하게 됩니다. 지식 노동자의 생산성은 부품 개수가 아닙니다. 죽은 코드 만 줄을 지운 개발자, 동료가 프로덕션 장애를 피하도록 하루 종일 페어링한 개발자는 어떤 순진한 지표도 포착하지 못하는 훌륭한 일을 한 것입니다. “우리는 얼마나 생산적인가?”에 대한 정직한 답은 다차원적이며, 일에 대한 개발자의 경험을 부드러운 신호가 아니라 실제 신호로 다룹니다.

규모가 커질수록 이것은 덜 중요해지는 게 아니라 더 중요해집니다. 수십 개 팀을 가진 기업에서는 작은 마찰(느린 빌드, 불안정한 테스트 스위트, 환경을 얻기 위한 이틀의 대기)이 수백 명의 엔지니어에 걸쳐 곱해져 막대한 역량 손실이 됩니다. 산출물에 시장 가격이 없는 정부에서는 “산출물 연극”의 위험이 있습니다. 생산된 문서나 종료된 티켓을 측정하면서 공공 가치는 측정되지 않은 채 남습니다. 이 장의 목표는 조작도, 감시도, 사람들을 서로 비교해 순위를 매기는 일도 없이 엔지니어링 조직의 효과성과 개발자의 일상 경험을 측정하고 개선하도록 돕는 것입니다.

핵심 원칙

생산성은 다차원적입니다. 어떤 단일 숫자도 이를 담지 못합니다. 그 척도라고 제시되는 모든 지표는 틀렸습니다.
사람의 순위를 매기려는 것이 아니라 마찰을 제거하려고 측정하십시오. 측정의 대상은 개인이 아니라 시스템입니다.
삼각 측량하십시오. 개발자가 일이 어떻게 느껴진다고 말하는 것과 시스템이 실제로 기록하는 것을 결합하십시오.
개발자의 경험은 데이터입니다. 피드백 고리, 인지 부하, 몰입은 측정할 수 있고 개선할 가치가 있습니다.
모든 지표는 조작될 것이라고 가정하십시오. 여러 차원과 정직한 의도로 굿하트의 법칙에 대비해 설계하십시오.
성과와 신중하게 연결하십시오. 효과성은 부패시키는 목표가 되지 않으면서 사업 가치로 이어져야 합니다.

권장 사항

단일 지표의 함정을 거부한다

첫 번째 규율은 하나의 숫자를 생산성이라 이름 붙이기를 거부하는 것입니다. 코드 줄 수, 커밋 수, 스토리 포인트 속도(velocity), 기록된 시간은 모두 치명적인 결함을 공유합니다. 가치가 아니라 활동을 측정하며, 활동은 부풀리기 쉽습니다. 이것이 굿하트의 법칙이 작동하는 모습입니다. 척도가 목표가 되면 좋은 척도이기를 그친다는 원칙입니다. 속도는 팀 스스로의 예측 도구로 발명되었습니다. 관리자가 한 팀의 포인트를 다른 팀과 비교하는 순간, 팀들은 추정의 크기를 조용히 재조정하고 그 숫자는 의미를 잃습니다. 누군가 단일 생산성 KPI를 요구하면, 충족해야 할 요청이 아니라 재구성해야 할 요청으로 다루십시오. 대신 균형 잡힌 소수의 집합을 제시하고, 왜 하나의 숫자가 그들을 오도하는지 설명하십시오.

SPACE로 무엇을 측정할지 구조화한다

SPACE 프레임워크는 함께 쥐고 있을 가치가 있는 다섯 차원을 줍니다. 만족과 웰빙(Satisfaction and well-being), 성능(Performance), 활동(Activity), 의사소통과 협업(Communication and collaboration), 효율과 흐름(Efficiency and flow)입니다. SPACE의 요점은 적어도 몇 개의 차원을 골라야 하며, 하나만 고르지 말고, 모두 같은 범주에서 고르지도 말아야 한다는 것입니다. 활동 지표(커밋, 배포)는 수집하기 쉬워서 솔깃하지만, 단독으로는 왜곡합니다. 다른 차원이 드러내지 않고서는 어느 한 차원도 조작할 수 없도록 만족 신호와 성능 신호를 짝지으십시오. 만족도가 바닥으로 떨어지고 변경 실패율이 오르는데 더 많이 배포하는 팀은 더 생산적인 것이 아니며, 균형 잡힌 집합은 그것을 즉시 보여 줍니다.

개발자 경험을 피드백 고리, 인지 부하, 몰입으로 다룬다

개발자 경험(DevEx)은 여기서 엔지니어링 일을 하는 것이 어떻게 느껴지는가이며, 들리는 것보다 구체적입니다. 측정하고 개선할 수 있는 세 가지에 기댑니다. 피드백 고리는 개발자가 무언가가 동작했는지 알 때까지 기다리는 시간입니다. 로컬 빌드 시간, 테스트 스위트 소요 시간, 코드 리뷰 회신 시간, 배포 시간입니다. 느린 고리는 맥락 전환과 멍하니 기다리는 시간을 강요합니다. 작업이 요구하는 총 정신적 노력인 인지 부하는 개발자가 단순한 변경을 하려고 너무 많은 도구, 문서화되지 않은 시스템, 뒤엉킨 의존성을 저글링해야 할 때 커집니다. 몰입(flow)은 쪼개진 캘린더와 끊임없는 방해가 파괴하는, 집중하고 생산적으로 빠져드는 상태입니다. 피드백 고리를 줄이거나, 개발자가 머릿속에 담아야 했던 개념 하나를 없애거나, 집중 시간 블록을 보호할 때, 어떤 활동 수치로도 기록되지 않는 방식으로 생산성을 개선한 것입니다. 이는 플랫폼 엔지니어링이 포장된 길과 셀프서비스(8.4장)를 통해 섬기는 바로 그 DevEx의 관심사입니다.

인식을 시스템 지표와 삼각 측량한다

어떤 단일 데이터 출처도 홀로 신뢰할 수 없으므로 두 종류를 결합하십시오. 인식 데이터는 개발자 경험 설문을 통해 개발자 본인에게서 옵니다. 출시에 얼마나 자신감을 느끼는지, 어디서 시간을 잃는지, 무엇이 불만인지를 묻는, 정기적이고 대부분 익명인 설문입니다. 시스템 데이터는 도구에서 옵니다. 파이프라인 소요 시간, 리뷰 지연, 인시던트 빈도입니다. 각각이 서로를 보정합니다. 설문은 사기를 꺾는 온콜 순환이나 두려운 레거시 서비스처럼 계측기가 놓치는 고통을 잡습니다. 시스템 지표는 사람들이 일상화하여 보고를 멈춘 문제를 잡습니다. 설문이 빌드가 고통스럽다고 하고 파이프라인 데이터가 중앙 15분 빌드를 확인해 주면, 우선순위가 정해진 방어 가능한 투자가 생깁니다. 꾸준한 주기로 설문을 실시하고, 짧게 유지하고, 그 결과로 무엇이 바뀌었는지 보여 줌으로써 항상 고리를 닫으십시오.

DORA를 순위표가 아닌 전달 신호로 쓴다

네 가지 DevOps Research and Assessment(DORA) 지표(배포 빈도, 변경 리드 타임, 변경 실패율, 서비스 복구 시간)는 속도와 안정성을 짝지어 어느 한쪽이 다른 쪽을 희생하지 않게 하는, 연구에 기반한 전달 역량의 강력한 판독입니다. 이에 대한 깊이는 11.5장이, 그것이 측정하는 전달 파이프라인은 11.2장이 다루니 거기서 쓰십시오. 여기서의 안내는 그것을 어떻게 쥐는가에 관한 것입니다. DORA를 팀이나 개인의 순위를 매기는 점수판이 아니라, 전달 시스템이 개선되고 있는지 보여 주는 팀 단위 건강 신호로 다루십시오. DORA 수치가 누군가의 성과 평가에 나타나는 순간, 팀은 빈도를 부풀리려 배포를 쪼개고 실패율을 지키려 인시던트를 숨기기 시작하며, 신호는 죽습니다.

시스템을 측정하되, 개인을 감시하지 않는다

이것이 넘지 말아야 할 선입니다. 지표를 팀과 조직 수준으로 집계하고, 마찰을 찾아 제거하는 데 쓰십시오. 커밋, 시간, “생산성 점수”로 개발자의 순위를 매기는 대시보드를 만들지 말고, 개인 텔레메트리가 보상이나 승진에 반영되게 하지 마십시오. 감시는 효과적인 엔지니어링이 의존하는 심리적 안전과 신뢰를 파괴하고, 사람들에게 일이 아니라 지표에 최적화하도록 가르칩니다. 개인의 성장과 평가는 커리어 사다리와 관리자 면담(1.3장)이라는 별개의 인간적 메커니즘에 속합니다. 효과성 측정은 “무엇이 우리 팀을 느리게 하는가?”를 묻습니다. “우리의 가장 느린 엔지니어는 누구인가?”는 결코 묻지 않습니다.

잡무와 마찰을 직접 공략한다

시간이 새는 곳을 볼 수 있게 되면, 그 시간을 되돌려 쓰십시오. 효과성을 제한하는 것의 상당수는 잡무(toil), 즉 성장에 따라 늘어나고 지속적인 가치를 전달하지 못하는 수동적이고 반복적이며 자동화 가능한 작업입니다(9.1장). 느린 리뷰도 마찰이므로, 더 작은 변경과 분명한 기대로 코드 리뷰(2.5장)를 간소화하면 핵심 피드백 고리가 짧아집니다. 포장된 길과 셀프서비스 플랫폼(8.4장)은 대기와 인지 부하의 범주 전체를 한꺼번에 없앱니다. 또한 과거 지름길의 누적된 비용으로서 모든 미래 변경에 세금을 매기는 기술 부채에 대해서도 예산을 잡으십시오. 아무도 안전하게 수정할 수 없는 코드베이스는 가장 깊은 생산성의 늪입니다.

장단점

접근 방식	장점	단점
단일 생산성 지표 (LOC, 속도, 커밋)	싸고 쉬움. 리더에게 하나의 숫자	즉시 조작됨. 가치가 아닌 활동을 측정. 신뢰를 부식시킴
SPACE 방식의 균형 집합	조작에 강함. 현실을 반영	수집할 일이 더 많음. 하나의 수치로 요약하기 어려움
DevEx 설문 (인식)	계측기가 놓치는 체감 고통을 포착	주관적. 정직함을 유지하려면 신뢰와 후속 조치가 필요
시스템 지표 (DORA, 파이프라인 소요 시간)	객관적, 지속적, 집계에서 위조하기 어려움	사기와 맥락에 눈이 멂. 개인에게 적용하면 위험
둘을 삼각 측량	각 출처가 다른 쪽을 보정. 견고	도구와 설문 규율에 대한 투자가 필요

핵심 긴장은 엄밀함 대 정직함입니다. 단일 숫자는 보고하기 쉽고 부패시키기도 쉽습니다. 풍부한 다차원적 그림은 정직하지만 바쁜 경영진에게 전달하기 더 어렵습니다. 균형 잡힌 소수의 집합(몇 개의 SPACE 차원, 설문, 전달 판독으로서의 DORA)을 고르고, 스냅숏이 아니라 추세를 보고하고, 숫자가 사람의 점수를 매기려는 것이 아니라 시스템을 개선하려고 존재함을 분명히 하여 해결하십시오. 리더십이 “차트 하나”를 원하면, 몇 개의 보완적 신호의 추세를 주고 그것들을 거짓된 합성 지표로 합치려는 유혹을 거부하십시오.

팀과 논의할 질문

내일 리더가 단일 생산성 숫자를 요구한다면 무엇을 주겠습니까? 이 질문은 조직이 함정을 이해하는지 드러냅니다. 정직한 답은 안전한 단일 숫자는 없으며, 여러분의 일은 요청을 조작에 강한 균형 잡힌 소수의 집합으로 재구성하는 것입니다. 이미 보고하는 지표들을 가져와서 각각에 대해 “영리하고 냉소적인 팀이 더 나은 일을 하지 않고 이것을 어떻게 부풀릴까?”를 물으십시오. 답이 쉽다면 그 지표는 목표가 되는 순간 위험합니다. 대신 무엇을 제시할지, 그리고 왜 하나의 숫자가 잘못된 것에 최적화하도록 그들을 오도하는지 리더십에 어떻게 설명할지 논의하십시오. 그 대화의 질이 측정이 여러분을 도울지 부패시킬지를 예측합니다.
가장 느린 피드백 고리는 무엇이며, 매일 그것이 얼마나 비용이 듭니까? 피드백 고리는 생산성이 조용히 새는 곳입니다. 15분 빌드, 이틀의 리뷰 대기, 모든 초록 체크에 대한 신뢰를 갉아먹는 불안정한 테스트 스위트입니다. 개발자 경험 설문과 파이프라인 계측기의 실제 숫자를 가져와, 인식된 고통과 측정된 지연이 일치하는지 보십시오. 대기 시간에 그것을 겪는 개발자 수와 빈도를 곱해 일일 비용을 추정하면 투자의 논거는 보통 저절로 생깁니다. 어느 고리를 먼저 줄일지, 누가 수정을 소유할지 정하십시오. 가장 느린 고리를 말할 수 없는 팀은 가장 중요한 것을 측정하기 시작하지도 않은 것입니다.
측정이 감시처럼 느껴질 위험이 있는 곳은 어디이며, 어떻게 막겠습니까? 시스템을 측정하는 것과 사람을 감시하는 것의 차이는 신뢰와 두려움의 차이이며, 알아채지 못한 채 넘기 쉽습니다. 모든 대시보드와 보고서를 살펴보며 그중 어느 것이 개인의 순위를 매기거나 성과 평가에 반영될 수 있는지 물으십시오. 무엇이 집계된 채로, 무엇이 익명으로 남는지, 무엇이 금지인지 명시적으로 정하고, 측정 대상이 되는 팀에 공개적으로 말하십시오. 감독과 감사의 압력이 강한 기업과 정부 환경에서는 개인으로 파고들고 싶은 유혹이 끊임없으므로, 가드레일은 희망이 아니라 명시된 원칙이어야 합니다. 개발자들이 숫자가 자신에게 불리하게 쓰인다고 믿으면 숫자에 최적화하고 진실은 사라질 것입니다.
마지막으로 개발자들에게 일이 어떻게 느껴지는지 물었을 때 그 결과로 무엇이 바뀌었으며, 그들이 그것을 알았습니까? 눈에 띄는 조치를 낳지 않는 설문은 개발자에게 정직하게 답하기를 멈추라고 가르치므로, 두 번째 침묵하는 설문은 첫 번째보다 더 적고 더 밋밋한 응답을 얻고, 의존하는 도구가 확장하는 바로 그 순간 쇠퇴합니다. 큰 조직에서 낭비는 복리로 쌓입니다. 수백 명이 마찰을 보고하는 데 시간을 쓰고, 보고서가 돌고, 아무것도 출시되지 않습니다. 지난 설문의 상위 세 가지 발견, 각각이 촉발한 구체적 작업, 제기한 사람들에게 결과를 어떻게 전달했는지 가져오십시오. 가장 큰 불평에 대응할지 가장 널리 퍼진 불평에 대응할지 사이의 상충하는 끌림을 저울질하십시오. 그 둘은 종종 다른 문제이기 때문입니다. 설문 피로와 의견 수렴 과부하가 이미 높은 기업과 정부 환경에서는 고리를 닫는 것을 거버넌스의 약속으로 다루십시오. 대응의 소유자를 정하고, 무엇이 바뀌었는지 공개하고, 응답받지 못한 설문이 아예 없는 것보다 나쁘다는 것을 받아들이십시오.
정직함에 벌을 주는 순위표를 만들지 않고 팀을 어떻게 비교하겠습니까? 큰 조직의 리더는 자연스럽게 어느 팀이 번성하고 어느 팀이 막혀 있는지 알고 싶어 하지만, 팀을 원시 속도, 배포 빈도, DORA 수치로 순위 매기는 것은 강하게 규제받는 결제 팀과 새로 시작하는 프로토타입 팀이 다른 세계에 산다는 사실을 무시합니다. 상충하는 고려는 실제입니다. 곤경에 빠진 팀을 알아채고 잘 되는 것을 퍼뜨려야 하지만, 비교가 점수판이 되는 순간 팀은 추정을 재조정하고, 인시던트를 숨기고, 자기 지위를 지키려 배포를 쪼갭니다. 조직에서 팀의 맥락이 어떻게 다른지에 대한 구체적 예와, 이웃과 비교하지 않고 각 팀을 시간에 따른 자신의 궤적과 비교하자는 제안을 가져오십시오. 감사와 감독의 압력이 팀 간 순위 매기기를 강하게 밀어붙이는 기업과 정부 환경에서는 무엇이 비교될 수 있는지, 무엇이 팀별 추세로만 읽힐지, 불공정한 비교를 거부할 권한이 누구에게 있는지 미리 합의하십시오.
전달 지표를 부패시키는 목표로 바꾸지 않고 효과성을 실제 성과와 어떻게 연결하겠습니까? 가치로 이어지지 않는 효과성은 리더십에게 자기 배꼽 들여다보기로 보이지만, 리드 타임이나 배포 빈도 같은 전달 신호가 성과 평가에서 목표가 되는 순간 팀은 숫자에 최적화하고 그것이 대리하려던 성과를 버립니다. 큰 조직에서 긴장은 첨예합니다. 경영진은 엔지니어링 노력에서 사업 성과까지 깔끔한 선을 원하지만 정직한 선은 지저분하고 시차가 있기 때문입니다. 현재의 성과 척도, 그것에 연결할 전달 신호, 각각이 목표가 되면 어떻게 조작될 수 있는지에 대한 명시적 설명을 가져오십시오. 리더십이 다시 말할 수 있는 단순한 이야기와 왜곡에 저항하는 진실한 그림 사이의 끌림을 저울질하십시오. 앵커로 삼을 수익이 없는 정부나 비시장적 내부 플랫폼에서는 성과를 원시 활동이 아니라 서비스 신뢰성, 수정의 사이클 타임, 공공의 이익으로 정의할 준비를 하고, 세기 쉬운 산출물을 선호할 수 있는 감독 기관에 그 선택을 변호할 준비를 하십시오.

분야별 관점

스타트업. 엔지니어 몇 명과 짧은 런웨이라면 대시보드를 아예 건너뛰고 가장 빠르게 움직이는 두 가지를 측정하십시오. 열 개 문항의 개발자 경험 설문과 기본적인 파이프라인 소요 시간입니다. 가장 큰 생산성 위험은 느리거나 불안정한 테스트 스위트와 끊임없는 맥락 전환이니, 최악의 피드백 고리를 찾아 줄이고 넘어가십시오. 운영할 사람이 없는 측정 프로그램을 세우지 마십시오. 하루가 어디서 새는지에 대한 정직한 대화 한 번이 이후 유지해야 할 어떤 도구보다 낫습니다.

소기업. 측정 전문가도 빠듯한 예산도 있으니, 이미 비용을 내는 시스템에서 기존 도구가 기록하는 빌드 시간, 리뷰 지연, 인시던트 수에 의지하십시오. 설문 도구를 직접 만들지 말고 가벼운 것을 사고, 개인 생산성 대시보드를 팔려는 벤더에 저항하십시오. 그것은 여러분이 아낄 수 없는 신뢰를 대가로 치르게 합니다. 누구의 하루도 낭비할 수 없는 작은 팀을 위한 마찰 제거로 전체 노력을 구성하십시오.

대기업. 수십 개 팀에 걸쳐 상은 대규모로 되찾는 역량이며, 위험은 중앙 대시보드가 사람 순위 매기기로 조용히 미끄러지는 것입니다. 균형 잡힌 프로그램(분기별 DevEx 설문, 몇 개의 SPACE 차원, 팀별 전달 추세로 읽는 DORA)을 표준화하고 개인 텔레메트리가 절대 수집되지 않도록 다스리십시오. 각 팀을 자기 궤적과 비교하고, 데이터가 드러내는 마찰에 대해 플랫폼 투자(8.4장)를 정당화하고, 순위표가 될 어떤 지표든 거부할 권한을 한 명의 책임 있는 소유자에게 주십시오.

정부. 산출물에 시장 가격이 없고 감독 압력이 강하므로, 산출물 연극(문서와 종료된 티켓 세기)으로 향하는 끌림이 끊임없고, 감사 아래 이름 있는 개인을 감시하려는 끌림은 더 강합니다. 대신 성과와 전달 역량을 측정하십시오. 서비스가 수정을 얼마나 빨리 출시하는지, 얼마나 믿을 수 있는지, 직원과 계약자가 익명 설문을 통해 일을 어떻게 경험하는지입니다. 공무원과 계약자를 같은 시스템 수준에서 측정하고, 측정이 무엇을 위한 것인지 공개하고, 팀별 전달 추세가 어떤 개인 점수보다 공공 가치에 대한 더 정직한 판독임을 입법부에 논증할 준비를 하십시오.

사례

스타트업. 20명 규모의 스타트업이 모두가 바쁜데도 출시가 느려졌음을 알아챕니다. 생산성 대시보드를 설치하는 대신 엔지니어링 리드가 열 문항의 DevEx 설문을 실시하고 기본 파이프라인 소요 시간을 끌어옵니다. 설문과 데이터가 일치합니다. 테스트 스위트가 22분 걸리고 무작위로 실패해서 사람들이 변경을 묶고 기다리는 동안 맥락을 전환합니다. 팀은 2주를 들여 불안정한 테스트를 고치고 스위트를 병렬화해 4분으로 줄입니다. 배포 빈도는 저절로 오르고, 다음 설문에서 만족도가 뛰며, 이를 위해 누구의 순위도 점수도 매겨지지 않았습니다.

대기업. 40개 엔지니어링 팀을 가진 은행이 사내 플랫폼에 대한 지속적 투자를 정당화하고자 합니다. 플랫폼 그룹은 균형 잡힌 측정 프로그램을 채택합니다. 모든 팀에 걸친 분기별 DevEx 설문, SPACE 방식의 신호, 전달 건강 추세로서 팀 단위로 읽는 DORA 지표(11.5장)입니다. 결정적으로, 팀의 맥락이 크게 다르므로 팀들을 서로 비교하지 않고 시간에 따른 각 팀 자신의 궤적과 비교하여 공정하게 벤치마크합니다. 데이터는 포장된 길(8.4장)에 있는 팀이 신규 엔지니어를 몇 주가 아닌 며칠 만에 온보딩하고 훨씬 낮은 인지 부하를 보고함을 보여 줍니다. 수백 명의 개발자에 걸쳐 되찾은 역량으로 설명된 그 증거가 플랫폼에 1년 더 재원을 대 줍니다. 개인 텔레메트리는 의도적으로 수집되지 않습니다.

정부. 한 연방 디지털 서비스 기관은 산출물에 시장 가격이 없는 환경에서 엔지니어링 지출이 가치를 전달함을 입법부에 보여야 합니다. 산출물 연극(문서나 종료된 티켓 세기)을 거부하고 대신 성과와 전달 역량을 측정합니다. 서비스가 수정을 얼마나 빨리 출시할 수 있는지, 얼마나 믿을 수 있는지, 인력과 계약자가 익명 설문을 통해 일을 어떻게 경험하는지입니다. DORA 방식의 전달 신호는 현대화가 처리량과 안정성을 실제로 개선하는지 보여 주며, 원시 활동이 아니라 공공의 성과(11.5장)와 연결됩니다. 측정이 개인의 순위를 매기지 않고 계약자와 공무원이 같은 시스템 수준에서 측정되므로, 기관은 이런 노력을 가라앉히는 감시와 사기 문제를 피하고 감독 기관에 가치에 대한 정직한 판독을 줍니다.

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

효과성을 측정하고 개선하는 수익은 되찾는 역량이며, 규모에서 그 숫자는 큽니다. 작은 마찰은 큰 조직에서 곱해집니다. 백 명의 엔지니어가 하루 여러 번 겪는 10분 빌드는 한 해에 수천 엔지니어 시간을 기다리는 데 쓰는 것입니다. 그 고리를 줄이면 아무도 채용하지 않고도 의미 있는 역량을 더한 것입니다. 여기서의 지배적 ROI는 플랫폼 엔지니어링(8.4장)과 같습니다. 비싼 엔지니어링 시간이 기다림과 잡무에서 가치 있는 일로 돌려지는 것입니다.

총소유비용은 소소하지만 실제입니다. 설문 도구와 그것을 운영하는 규율, 파이프라인 계측, 추세를 읽고 행동하는 경영진의 관심에 비용을 지불합니다. ROI에 더 큰 위험은 측정을 잘못하는 것입니다. 단일 조작된 지표나 감시 프로그램은 음의 수익을 낼 수 있습니다. 실제 성과는 정체되는 동안 숫자를 최적화하는 몇 달의 노력과, 앞으로의 모든 변화를 더 어렵게 만드는 신뢰의 부식입니다. 전혀 측정하지 않는 비용은 분산되어 있고 막대합니다. 마찰과 잡무가 보이지 않게 쌓이고, 시니어 엔지니어가 피할 수 있는 낭비에 소진되며, 리더십은 투자가 도움이 되는지 알 수 없습니다. 리더십에게는 지렛대와 정직함으로 논거를 세우십시오. 큰 인력이 시간을 어디서 잃는지 찾아내고, 첫 발견에 따라 행동하는 순간 몇 배로 본전을 뽑는, 작고 신뢰받는 균형 잡힌 측정 프로그램입니다.

안티패턴과 함정

단일 생산성 지표. 어떤 하나의 숫자(LOC, 속도, 커밋, 시간)든 목표가 되는 날 조작됩니다.
개인 순위 매기기. 순위표와 개인 “생산성 점수”는 신뢰를 파괴하고 사람들에게 지표에 최적화하도록 가르칩니다.
감시로서의 측정. 평가에 반영되는 세밀한 개인 텔레메트리는 효과적인 일에 필요한 심리적 안전을 부식시킵니다.
후속 조치 없는 설문. 개발자에게 일이 어떻게 느껴지는지 묻고 아무것도 바꾸지 않으면 정직하게 답하기를 멈추도록 가르칩니다.
팀의 원시 수치 비교. 팀의 맥락은 다릅니다. 팀 간 속도나 DORA 비교는 정직함에 벌을 주고 조작에 보상합니다.
산출물 연극. 실제 성과가 측정되지 않는 동안 생산된 산출물(문서, 티켓, 출시된 기능)을 세는 것. 시장 가격이 없는 곳에서 흔합니다.
성과 평가에 올라간 DORA. 전달 지표가 사람의 점수를 매기는 순간, 팀은 인시던트를 숨기고 배포를 쪼개며 신호는 죽습니다.

성숙도 모델

1단계, 시작: 생산성이 직감이나 코드 줄 수, 속도, 시간 같은 조작 가능한 단일 지표로 판단됩니다. 측정은 그때그때 반응적이고, 마찰은 보이지 않으며, 불만은 일화적이고, 조직이 나아지고 있는지 아무도 말할 수 없습니다.
2단계, 발전: 일부 팀이 기본 관행을 채택합니다. 몇 개의 지표(흔히 활동 수치)와 이따금의 개발자 경험 설문입니다. 관행은 팀마다 일관되지 않고, 데이터는 수집되지만 거의 활용되지 않으며, 팀 간 원시 비교가 스며들고, 개인을 순위 매기기로부터 보호하는 공유 원칙이 없습니다.
3단계, 표준화: 균형 잡힌 측정 프로그램이 문서화되어 조직 전체에 적용됩니다. SPACE 방식의 차원, 정기적인 DevEx 설문, 전달 신호로서의 DORA(11.5장)를 사용합니다. 지표는 정책에 따라 팀 단위로 집계되고, 개인의 순위는 매겨지지 않으며, 발견은 피드백 고리를 줄이고 잡무를 줄이는(9.1장) 구체적 작업을 이끕니다.
4단계, 관리: 프로그램이 기준선에 대해 측정되고 통제됩니다. 피드백 고리 시간, 설문 점수, DORA 추세에 합의된 목표가 있고 시간에 따라 추적됩니다. 각 팀은 이웃이 아니라 자기 궤적과 비교됩니다. 플랫폼과 잡무 감소 투자는 되찾은 역량에 대한 전후 데이터로 정당화됩니다. 어떤 신호든 후퇴하면 알아채지 못하고 지나가는 대신 검토를 촉발합니다.
5단계, 오케스트레이션: 측정이 신뢰받고, 일상적이고, 적응적입니다. 인식 데이터와 시스템 데이터가 삼각 측량되고, 추세가 지속적 개선에 공급되며, 마찰과 인지 부하를 적극적으로 찾아 제거하고, 측정 집합 자체가 조직이 변함에 따라 개정되며, 어떤 지표도 부패시키는 목표가 되도록 허용하지 않은 채 효과성이 사업과 공공의 성과에 통합됩니다.

논의를 위한 아이디어

현재 지표 중 냉소적인 팀이 더 나은 일을 하지 않고 부풀릴 수 있는 것은 무엇이며, 무엇으로 대체하겠습니까?
조직 전체에서 정확히 하나의 피드백 고리를 줄일 수 있다면, 어느 것이 가장 많은 되찾은 역량을 돌려주겠습니까?
맥락이 다른 많은 팀을 정직함에 벌을 주는 순위표를 만들지 않고 어떻게 공정하게 벤치마크하겠습니까?
시스템 측정과 개인 감시 사이의 선은 어디에 있으며, 조직에서 누가 그것을 시행할 권한이 있습니까?
정부나 내부 플랫폼처럼 산출물에 시장 가격이 없는 환경에서, 활동이 아닌 실제 가치를 어떻게 측정합니까?
이번 분기 설문이 무언가를 바꿨음을 증명하려면 개발자에게 무엇을 보여 주겠습니까?

핵심 요점

엔지니어의 생산성은 다차원적입니다. 굿하트의 법칙이 조작을 보장하므로, 어떤 단일 숫자(코드 줄 수, 속도, 커밋, 시간)도 그 척도로 거부하십시오.
SPACE 프레임워크(만족과 웰빙, 성능, 활동, 의사소통과 협업, 효율과 흐름)를 써서 여러 차원을 함께 쥐어, 어느 한 차원도 홀로 조작될 수 없게 하십시오.
개발자 경험은 피드백 고리, 인지 부하, 몰입으로 귀결됩니다. 고리를 줄이고 부하를 덜어내는 것은 활동 수치가 결코 보여 주지 못하는 진짜 생산성입니다.
DevEx 설문의 인식 데이터와 도구의 시스템 데이터를 삼각 측량하십시오. 각각이 서로를 보정합니다.
DORA 지표를 순위표가 아닌 팀 단위 전달 신호로 다루십시오. 깊이는 11.5장에, 파이프라인은 11.2장에 있습니다.
시스템을 측정하되 개인은 측정하지 마십시오. 팀으로 집계하고, 평가는 1.3장의 별개의 인간적 경로에 두며, 측정이 감시가 되게 하지 마십시오.
되찾은 시간은 잡무를 줄이고(9.1장), 코드 리뷰를 빠르게 하고(2.5장), 길을 포장하는(8.4장) 데 쓰십시오. 어떤 지표도 부패시키는 목표가 되게 하지 않으면서 효과성을 사업 성과와 연결하십시오.

참고 문헌과 더 읽을거리

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): the multidimensional framework.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): feedback loops, cognitive load, and flow.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (the DORA metrics and their research basis).
DORA, Accelerate State of DevOps Report (annual): the ongoing research programme behind the four metrics.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (toil and its elimination).
Matthew Skelton and Manuel Pais, Team Topologies (cognitive load as a first-class design concern).
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (the origin of flow state).
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (focus, interruption, and the human side of productivity).
Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): the origin of Goodhart’s law; see also Marilyn Strathern’s widely quoted formulation.
U.S. Government Accountability Office (GAO) guidance on performance measurement: measuring value in non-market public-sector settings.