Ch07 엔지니어링 생산성 측정하기

한 줄 정의

엔지니어링 생산성 측정은 “측정 결과가 실제 결정을 바꿀 때만” 수행할 가치가 있으며, 측정하기로 했다면 GSM 프레임워크(목표 → 신호 → 지표) 로 ‘구하기 쉬운 지표’가 아니라 ‘목표를 대변하는 지표’를 고르고, 생산성의 다섯 측면(QUANTS)을 모두 다뤄 한 요소의 개선이 다른 요소의 희생으로 얻어지는 일을 막아야 합니다.

쉽게 말하면

엔지니어링 생산성 측정의 핵심은 두 문장으로 압축됩니다.

첫째, 측정은 공짜가 아니므로 결과가 실제 결정을 바꿀 때만 측정합니다. 프로세스를 측정하고, 데이터를 분석하고, 결과를 공유하는 데 전부 사람이 들어갑니다. 그런데 결과가 어떻게 나오든 어차피 하던 대로 할 거라면 그 비용은 전부 낭비입니다. 그래서 측정 방법을 고민하기 전에 “이 측정, 할 가치가 있나?”부터 걸러냅니다.

둘째, 측정하기로 했다면 ‘재기 쉬운 것’이 아니라 ‘알고 싶은 것’을 재야 합니다. 코드 라인 수처럼 손에 잡히는 숫자부터 집어 들면, 열쇠를 잃어버린 곳이 아니라 가로등 밑에서 열쇠를 찾는 꼴이 됩니다. 그래서 측정 방식(지표)에서 출발하지 않고 알고 싶은 것(목표)에서 출발해 신호 → 지표 순으로 거꾸로 내려옵니다. 이것이 GSM 프레임워크 입니다.

두 원칙이 실제로 작동하는 모습은 가독성(readability) 프로세스 라는 사례 하나로 처음부터 끝까지 확인할 수 있습니다. “이 비싼 프로세스, 계속할 가치가 있나?”라는 질문을 받아 측정할 가치가 있는지 선별하고, GSM으로 지표를 만들고, 데이터로 지표를 검증하고, 조치하는 전 과정입니다.

왜 중요한가?

사업이 번창하면 엔지니어링 조직도 커집니다. 그런데 조직이 두 배 커지면 소통 비용은 제곱으로 늘어납니다 (『맨먼스 미신』). 충원은 피할 수 없는데 소통 비용이 더 가파르게 늘어나므로, 조직 덩치에 비례해 사업을 키워갈 수는 없습니다. 다른 풀이법이 개개인의 생산성을 높이는 것 입니다. 각자의 생산성이 높아지면 소통 비용 증가를 억제하면서 사업을 키울 수 있습니다.

하지만 개선 사이클 자체를 만들고 관리하는 데도 인력이 들어갑니다. 매년 엔지니어 50명 치 노력을 투입해서 조직 생산성을 10명분만큼 개선하는 건 넌센스입니다. 그래서 구글의 목표는 생산성 개선과 더불어 개선 업무 자체의 효율까지 높이는 것 이었고, 그 답이 전담 연구팀이었습니다. 개별 팀이 자신만의 방식으로 생산성 개선에 힘쓰는 대신 하나의 팀이 복잡한 문제를 여러 방면에서 집중적으로 연구하는 것입니다.

구글은 제품·설계 결정 대부분을 데이터로 뒷받침하는 데이터 주도(data-driven) 회사지만, ‘사람’과 관련해서는 데이터를 수집하고 분석하기가 만만치 않습니다. 그래서 연구팀은 소프트웨어 엔지니어링 연구자와 일반 엔지니어에 더해 인지심리학·행동경제학 같은 분야의 사회과학자 들로 꾸려졌습니다. 덕분에 산출물 연구에 그치지 않고 개인의 동기, 성과 보상 구조, 복잡한 작업 관리 전략 같은 인간적인 측면까지 이해할 수 있게 되었습니다.

핵심 내용

선별: 측정할 가치가 있는가?

측정 방법을 정하기 전에 해당 지표가 측정할 가치가 있는지 부터 따져야 합니다. 측정 자체에 비용이 많이 듭니다. 프로세스를 측정하고, 데이터를 분석하고, 결과를 회사 전체에 공유하는 데 사람이 필요합니다. 측정 프로세스가 성가시다면 다른 조직들의 작업 속도를 늦추고, 속도를 늦추지 않더라도 측정이 개입하면서 작업 방식이 달라져 원래 작업 방식에 있던 근본적인 문제를 감춰버리는 상황도 생깁니다.

구글의 가독성 프로세스 가 바로 그런 검토 대상이었습니다. 다른 엔지니어가 작성한 코드를 검토해 가독성 자격을 승인하는 이 제도는 자동 포맷터와 린터가 보급되기 전부터 있었고, 승인에 수백 명의 엔지니어가 투입될 만큼 비용이 큽니다. 일부는 더 이상 필요 없는 꼰대 프로세스라 여겼고, 점심 식탁에 가장 빈번히 올라오는 토론 주제이기도 했습니다.

구글은 팀이 생산성 측정을 해도 될지 결정하도록 돕는 질문 목록을 마련했습니다. 먼저 구체적인 질문을 던져 측정하고 싶은 것을 설명하게 하는데, 구체적으로 답할수록 측정에서 얻는 것도 많아집니다. 가독성팀의 질문은 단순했습니다 — “엔지니어들이 가독성 프로세스를 밟는 데 들이는 비용 이상의 가치를 회사가 얻고 있을까요?”

어떤 결과를 기대하고, 왜 그런가?

우리 모두는 어떤 일이 일어나야 하는지에 대한 선입견 을 갖고 있습니다. 중립적인 척하고 싶지만 실제로는 그렇지 않습니다. 처음부터 이 사실을 인정하고 시작해야 무의식 속에서 의도한 결과를 억지로 만들어내는 실수를 막을 수 있습니다.

가독성팀은 무엇을 기대하는지 확실하지 않다고 답했습니다. 한때는 비용만큼의 가치가 있다고 믿었지만 자동 포맷터와 정적 분석 도구가 등장하자 아무도 확신하지 못했고, 가독성 프로세스가 사람들을 괴롭히는 악습처럼 작용한다는 믿음이 번지고 있었습니다. 혜택이 모두 사라진 건 아니었지만(뒷받침하는 설문 데이터도 있었습니다) 그 혜택이 코드 작성자와 리뷰어가 투자한 시간만큼의 값어치를 하는지가 불분명했습니다.

데이터가 기대한 결과를 뒷받침한다면 어떤 조치를 취하겠는가?

아무런 조치도 취하지 않을 거라면 측정해봐야 의미가 전혀 없습니다. 측정 결과에 상관없이 어차피 ‘현상 유지’할 계획인지를 주의해야 합니다. 가독성팀의 답은 간명했습니다 — 이점이 비용을 정당화할 만큼이라면 연구 설명과 결과 데이터를 가독성 제도 FAQ에 추가하고 홍보할 계획이었습니다.

부정적인 결과가 나온다면 적절한 조치를 취할 것인가?

부정적인 결과가 나와도 결정이 바뀌지 않는 경우가 흔합니다. 부정적인 데이터를 압도하기 위해 또 다른 근거를 찾아 추가하곤 하죠. 이 질문은 구글 연구팀이 착수하려던 연구 프로젝트 대부분을 중지시킨 주인공 입니다. 결정권자들은 연구 결과를 알고는 싶어 하지만, 다른 이유들을 들어서라도 이미 정해진 진로를 잘 틀지 않는다는 사실을 알아냈습니다.

가독성팀은 확실한 답변을 줬습니다. 비용이 이점보다 크거나 이점 자체가 크지 않다면 가독성 프로세스를 폐지하겠다 고 했습니다. 프로그래밍 언어마다 포맷터·정적 분석 도구의 성숙도가 다르므로 평가는 언어별로 구분해 진행했습니다.

결과에 따른 조치는 누가 결정하고, 언제 수행하는가?

측정 의뢰자가 조치를 취할 권한이 있는지(혹은 권한자를 대신해 직접 수행할 사람인지)를 확인합니다. 소프트웨어 프로세스를 측정하는 궁극적인 목적은 사업적인 결정을 내리는 데 도움을 주기 위함 입니다. 그래서 결정권자가 누구이고 어떤 형태의 데이터가 그에게 확신을 주는지 이해해야 합니다. 결정권자를 직접 만나 설문·로그 데이터를 신뢰하는지, 복잡한 통계 분석에 익숙한지, 인터뷰의 공감되는 이야기에 크게 영향받는지 확인합니다. 결정권자가 결과의 형태를 신뢰하지 않는다면 이 역시 측정할 필요가 없습니다.

선례(anecdata)와 정성 데이터

IT 업계는 선례를 경계하고 ‘데이터 기반’으로 판단하려 하지만, 선례의 힘은 무척 강합니다. 숫자가 주지 못하는 맥락과 서사를 제공하고 개인의 경험을 반영해 깊이 있는 설명으로 공감을 끌어내기 때문입니다. 구글 연구자들은 선례를 의사결정에 활용하지 않지만, 현상을 깊이 이해하고 정량 데이터에 맥락을 더하기 위해 구조화된 인터뷰와 사례 연구 같은 기법을 활용하고 권장합니다.

가독성 사례에서는 언어별 결정권자가 명확했습니다. 자바팀과 C++팀이 먼저 연락을 취했고 다른 언어팀들은 결과를 지켜보기로 했습니다. 결정권자들은 행복도와 배움 측면에서는 엔지니어들의 자체 평가를 신뢰했지만, 속도와 코드 품질 평가는 로그 데이터에서 뽑아낸 ‘명확한 숫자’도 보고 싶어 했습니다. 정성적 분석과 정량적 분석이 모두 필요하다 는 뜻이었습니다. 기한은 몇 달 후의 내부 콘퍼런스 전으로 잡았습니다.

측정하지 말아야 할 합당한 이유들

이상의 질문들을 던져보면 측정해볼 가치가 없는 경우가 꽤 많다는 사실을 알게 됩니다. 괜찮습니다. 합당한 이유는 많습니다.

• 당장 프로세스/도구를 변경할 여유가 없다. 더 빠른 빌드 도구로 교체하면 매주 몇 시간씩 절약되지만 교체 기간 동안 개발이 일시 중단되는데, 중요한 마일스톤이 코앞이라면 잠시의 중단도 감당하기 어렵습니다. 엔지니어링 트레이드오프는 진공 상태에서 단독으로 평가되지 않습니다 — 여러 관점에서 맥락 전체를 넓게 고려해야 합니다.
• 어떤 결과가 나오든 곧 다른 요인에 의해 의미가 없어질 것이다. 조직 개편을 앞두고 프로세스를 측정하거나, 폐기한 제품의 기술 부채를 평가하는 경우입니다. 또한 결정권자의 신념이 확고하다면 그 믿음을 바꿀 만큼의 증거를 제공하기 어렵습니다 — 청중을 잘 파악해야 합니다.
• 측정 결과를 이미 확정된 계획을 뒷받침하는 용도로만 쓴다. 구글에서 측정하지 말라고 권하는 가장 흔한 상황입니다. 릴리스 도구팀이 워크플로 체계 변경을 미리 확정해두고 개선 효과를 측정해달라고 요청한 적이 있는데, “개선 정도가 작더라도 어쨌든 계획대로 진행할 건가요?”라고 묻자 ‘네’라는 답이 돌아왔습니다. 생산성 개선은 거대한 변경에 따라오는 부수 효과 정도였던 것입니다.
• 측정 가능한 지표들이 충분히 정확하지 않고 다른 요인으로 혼탁해질 우려가 크다. 필요한 지표를 측정할 수 없을 때 코드 라인 수 같은 다른 지표를 쓸 수는 있지만, 이런 지표에서 얻은 결론은 결정에 영향을 주지 못합니다. 지표가 믿음을 뒷받침하면 정확성은 신경 쓰지 않고 진행하고, 뒷받침하지 못하면 지표가 부정확하다는 이유로 (마찬가지로) 원래 계획대로 진행할 것입니다.

측정의 성공 = 가설 증명이 아니라 '결정에 쓰이는 데이터 제공'

측정에 성공했다고 해서 가설이 옳거나 틀렸다고 증명되는 게 아닙니다. 여기서 성공이란 이해관계자가 결정을 내리는 데 필요한 데이터를 제공했다 는 뜻입니다. 이해관계자가 측정 결과를 활용하지 않으면 측정 프로젝트는 무조건 실패한 것입니다. 가독성팀은 명확한 결정(공표 또는 폐지)이 준비되어 있었고, 더 중요하게는 그 결정을 내릴 권한을 본인들이 갖고 있었습니다.

GSM 프레임워크: 목표와 신호를 뒷받침하는 의미 있는 지표 선정하기

측정하기로 정했다면 지표를 선정해야 합니다. 물론 코드 라인 수(LOC)는 거론할 가치가 없습니다.

에츠허르 데이크스트라, 〈the cruelty of really teaching computing science〉(EWD 1036)

“LOC를 사용하면 엔지니어들이 무미건조한 코드를 쏟아내기 시작하므로 치러야 할 비용이 무척 큽니다. (…) LOC를 세고 싶다면 라인 수를 ‘생산된 라인’이 아니라 ‘허비한 라인’이라는 개념으로 받아들여야 한다는 것입니다. 현재의 통념은 너무 어리석어서 잘못된 측면을 바라보고 있습니다.”

구글은 지표를 만들 때 GSM 이라는 프레임워크를 씁니다. 목표(goal) / 신호(signal) / 지표(metric)의 약자입니다.

• 목표 는 측정자가 원하는 최종 결과입니다. 측정을 통해 이해하고 싶은 내용을 고차원의 어휘로 표현하되 특정한 측정 방식을 명시해서는 안 됩니다.
• 신호 는 원하는 최종 결과를 이루었는지 판단하는 방법입니다. 우리가 측정하고 싶어 하는 것이지만 신호 자체는 측정하지 못할 수도 있습니다.
• 지표 는 신호를 대변합니다. 우리가 실제로 측정하는 대상입니다. 이상적인 측정법은 아닐 수 있으나 충분히 가깝다고 믿는 것이어야 합니다.

graph LR
    G["목표(goal)<br/>원하는 최종 결과<br/>측정 방식 명시 금지"] --> S["신호(signal)<br/>달성 여부 판단 방법<br/>측정 불가할 수 있음"]
    S --> M["지표(metric)<br/>실제 측정 대상<br/>신호의 프록시"]
    M -.->|추적 가능성| G

GSM이 유용한 이유는 세 가지입니다.

첫째, 목표 → 신호 → 지표 순서 덕분에 가로등 효과(streetlight effect) 를 없애줍니다. ‘가로등 아래에서 열쇠 찾기’ — 보이는 곳만 봐서는 정작 열쇠가 떨어진 곳을 살펴보지 못합니다. 진짜 필요한 지표인지와 관계없이 쉽게 구할 수 있고 측정하기 쉬운 지표를 사용하는 게 가로등 효과의 예입니다. GSM은 손쉽게 이용할 수 있는 지표가 아니라 목표를 이루는 데 실제로 도움이 되는 지표 를 생각하게 이끌어줍니다.

둘째, 측정에 앞서 원칙에 입각해 지표를 선정하게 함으로써 지표 크리프(metrics creep)와 지표 편향(metrics bias) 을 예방합니다. 원칙 없이 지표를 골랐다가 측정 결과가 기대를 충족하지 못하면, 이해관계자가 원하는 결과를 내어주리라 기대되는 다른 지표로 갈아타고 싶은 유혹에 흔들립니다. 애초에 원칙으로 선택한 지표가 아니었으니 바꿔도 딱히 틀렸다고 할 근거도 없죠. GSM은 ‘목표를 측정할 수 있는 능력’을 기준으로 지표를 선정하게 해주므로, 이해관계자도 선택된 지표가 목표와 관련이 깊은 최선의 지표라는 데 쉽게 동의합니다.

셋째, 측정이 되는 영역과 그렇지 않은 영역을 알려줍니다. 모든 목표를 나열한 다음 각 목표를 포착할 신호를 찾는데, 모든 신호가 측정 가능한 건 아닙니다. 그래도 괜찮습니다 — 최소한 측정할 수 없는 것이 무엇인지는 알 수 있으니까요. 누락된 지표를 알게 되면 새 지표를 만들지, 측정 자체를 그만두는 게 나을지 판단할 수 있습니다.

중요한 것은 추적 가능성(traceability) 을 잃지 않는 것입니다. 각각의 지표로부터 관련 신호를 찾아낼 수 있고, 나아가 그 신호가 대변하는 목표까지 거슬러 추적할 수 있어야 합니다. 그래야만 어떤 지표가 무엇을 측정하고 왜 측정하는지를 알 수 있습니다.

목표(goal): 생산성의 다섯 요소 QUANTS

목표는 원하는 속성을 설명하되 어떠한 지표도 명시해서는 안 됩니다. 목표 자체는 측정이 불가능하지만, 목표 목록을 잘 정의하면 신호·지표 선정 단계에 들어서기 앞서 모든 이해관계자의 동의를 얻어낼 수 있습니다.

함정은 생산성에 영향을 주는 트레이드오프를 다 감안하지 못해 측정 결과가 잘못된 길로 인도하는 것 입니다. 가독성팀이 원래 목표(코드 품질 개선)를 잊고 프로세스를 빠르고 쉽게 만드는 데 집중한다고 가정해보죠. 리뷰 통과 시간과 만족도를 추적하면, 한 팀원이 이렇게 제안할 수 있습니다.

Quote

“제가 리뷰 속도를 진짜 빠르게 만들 수 있습니다. 코드 리뷰를 아예 안 하면 됩니다.”

극단적인 예지만 대부분 팀은 중요한 트레이드오프를 잊은 채 측정을 하곤 합니다. 속도를 높이는 데 집중하느라 품질 측정을 놓치는 식이죠(혹은 반대). 이를 방지하기 위해 구글은 생산성을 다섯 개의 요소 로 나눴습니다. 다섯 요소 사이에는 서로 트레이드오프가 일어나며, 생산성을 높이려는 팀에게 모든 요소 각각에 대한 목표를 정하라 고 안내합니다. 특정 요소를 개선하느라 실수로 다른 요소를 희생하는 일을 막기 위함입니다. 기억하기 쉽도록 이름은 퀀츠(QUANTS) 입니다.

요소	핵심 질문
코드 품질 (Quality of the code)	작성된 코드의 품질은 어떤가? 회귀 버그를 예방하기에 충분한 테스트 케이스가 갖춰졌는가? 아키텍처는 위험과 변경을 받아들일 수 있을 만큼 유연한가?
엔지니어들의 몰입도 (Attention from engineers)	엔지니어들은 얼마나 자주 몰입 상태에서 깨어나는가? 알림은 주의력을 얼마나 흐트리는가? 도구는 작업 맥락 전환에 도움을 주는가?
지적 복잡성 (Intellectual complexity)	작업 완료에 인지 부하가 얼마나 걸리는가? 문제에 내재된 복잡성은 어느 정도인가? 불필요한 복잡성을 처리해야 하는가?
박자와 속도 (Tempo and velocity)	작업을 얼마나 빨리 완수할 수 있는가? 릴리스를 얼마나 빨리 밀어낼 수 있나? 주어진 시간에 얼마나 많은 작업을 완료하는가?
만족도 (Satisfaction)	엔지니어가 도구에 얼마나 만족하는가? 업무와 완성한 제품에 얼마나 만족하는가? 번아웃되지는 않는가?

가독성팀이 이 지침에 따라 작성한 목표는 다음과 같습니다.

• 코드 품질 — 가독성 프로세스를 거친 엔지니어는 품질이 더 좋은 코드를 작성한다. 가독성 프로세스를 통해 코드 일관성이 높아진다. 가독성 프로세스는 건실한 코드 문화에 기여한다.
• 엔지니어들의 몰입도 — 가독성은 몰입과 관련이 없다. (모든 생산성 문제가 다섯 영역 전부와 관련된 것은 아닙니다)
• 지적 복잡성 — 가독성 프로세스를 거친 엔지니어는 구글의 코드베이스와 최선의 코딩 모범 사례를 배우고, 프로세스 중에는 멘토링을 받는다.
• 박자와 속도 — 가독성 프로세스를 거친 엔지니어는 일을 더 빠르고 효율적으로 완료한다.
• 만족도 — 엔지니어는 가독성 프로세스의 이점을 확인하고 프로세스 참여를 긍정적으로 생각한다.

신호(signal)

신호는 목표 달성 여부를 알 수 있는 방법입니다. 모든 신호를 측정할 수 있는 것은 아니지만 이 단계에서는 괜찮습니다. 신호와 목표가 1:1 관계는 아닙니다 — 모든 목표에는 신호가 최소 하나는 필요하고 둘 이상일 수 있으며, 어떤 목표들은 같은 신호를 공유하기도 합니다.

표 7-1 신호와 목표 (가독성 프로세스 측정)

목표	신호
가독성 프로세스를 거친 엔지니어는 품질이 더 좋은 코드를 작성한다	가독성 승인을 얻은 엔지니어가 작성한 코드가 그렇지 않은 엔지니어의 코드보다 품질이 좋다. 가독성 프로세스가 코드 품질에 긍정적인 영향을 준다
가독성 프로세스를 거친 엔지니어는 구글 코드베이스와 코딩 모범 사례를 익히게 된다	엔지니어가 가독성 프로세스로부터 배운 것이 있다고 보고한다
가독성 프로세스를 거치는 동안 엔지니어는 멘토링을 받는다	엔지니어가 가독성 프로세스 동안 리뷰어 역할을 해준 숙련된 구글 엔지니어와의 소통이 긍정적이었다고 보고한다
가독성 프로세스를 거친 엔지니어는 작업을 더 빠르고 효율적으로 완수한다	가독성 승인을 얻은 엔지니어는 그렇지 않은 엔지니어보다 더 생산적이라고 스스로 여긴다. 가독성 승인을 얻은 엔지니어가 작성한 변경은 그렇지 않은 변경보다 리뷰가 더 빨리 끝난다
엔지니어들이 가독성 프로세스의 이점을 확인하고 프로세스 참여를 긍정적으로 생각한다	엔지니어들이 가독성 프로세스가 가치 있다고 생각한다

지표(Metric)

지표는 신호를 측정하는 방법의 최종 형태입니다. 신호 자체가 아니라 측정 가능한 프록시(proxy, 대리자) 입니다. 대리하는 개념이다 보니 신호를 완벽하게 측정해내지는 못하며, 그래서 어떤 신호는 마치 삼각측량하듯 여러 개의 지표를 종합하여 정확도를 높이기도 합니다.

예를 들어 가독성 프로세스를 거친 엔지니어들의 코드 리뷰가 빨라졌는지를 측정하기 위해 설문과 로그 데이터를 조합할 수 있습니다. 두 지표 모두 완벽한 진실을 알려주지는 못합니다 — 인간의 인식에는 오류가 스며들기 쉽고, 로그 지표는 전체 그림을 담아내지 못할 수 있습니다(엔지니어가 로그에 기록된 시간을 온전히 리뷰에 쏟지 못했거나, 변경된 코드의 양·복잡도처럼 ‘시간’ 개념에 담지 못하는 복합적인 요인이 있을 수 있습니다). 하지만 지표들이 서로 다른 결과를 보여준다면 그중 하나는 잘못되었을 수 있으니 더 연구해보라는 신호 로 해석할 수 있고, 모든 지표가 같은 방향을 가리킨다면 측정 결과가 진실에 가깝다는 확신을 굳힐 수 있습니다.

한편, 애초에 측정 불가능한 신호라면 연관 지표가 하나도 없을 것입니다. 코드 품질이 그렇습니다. 학계에서 다양한 품질 기준을 제안하지만 그중 어느 것도 진정한 품질을 대표하지 못합니다. 가독성팀은 빈약한 지표에 기대 판단하는 안 과 당장은 측정할 방법이 없음을 인정하는 안 중 선택해야 했고, 결국 엔지니어들에게 코드 품질을 스스로 평가하라고만 요청하고 정량적인 측정은 포기했습니다.

데이터로 지표 검증하기

GSM으로 지표를 골랐어도 그 지표가 의도한 신호를 정말 포착하는지는 별개 문제입니다. 구글은 정성적인 데이터를 사용하여 지표를 검증 합니다.

사례 — 빌드 지연시간 지표와 경험표집법

개별 엔지니어의 빌드 지연시간 평균을 측정하는 지표를 만든 적이 있습니다. 목표는 빌드 지연에 대해 엔지니어들이 느끼는 ‘일상 경험(typical experience)‘을 포착하는 것이었고, 검증에는 경험표집법(Experience Sampling Method, ESM) — 일에 집중하고 있는 엔지니어의 흐름을 끊고 질문을 던지는 방식 — 을 사용했습니다. 엔지니어가 빌드를 실행하는 순간을 포착해 빌드 지연시간에 관한 느낌을 묻는 작은 설문지를 자동 전송했죠.

그런데 드물게 자신은 빌드한 적이 없다고 응답하는 엔지니어들이 나타났습니다. 범인은 자동화 도구 였습니다. 도구가 알아서 빌드를 실행했고, 엔지니어는 중단 없이 — 즉 빌드로 인한 지연시간 없이 — 일에 매진하던 중이었습니다. 이런 빌드는 ‘일상 경험’에 포함될 수 없었기에 지표를 수정하여 제외시켰습니다. 정량적 지표와 정성적 지표가 가리키는 결과가 다른 경우는 흔했는데, 정량적 지표가 기대한 결과를 포착해내지 못했기 때문이었습니다.

정량적 지표가 유용한 이유는 힘과 확장성 입니다. 엔지니어들의 경험을 회사 전반에 걸쳐 오랜 기간 측정할 수 있어서 결과를 신뢰할 수 있습니다. 하지만 맥락 정보나 설명이 빠져 있습니다 — 엔지니어가 왜 구식 도구를 사용하기로 했는지, 왜 표준 프로세스를 우회해 비정상적인 워크플로를 따랐는지 같은 설명을 해주지 못합니다. 오직 정성적 연구만이 이런 정보를 제공해주며, 정성적 연구로 얻은 맥락을 통해서만 프로세스 개선을 위해 취해야 할 다음 단계가 무엇인지 말해줄 수 있습니다.

최종적으로 가독성팀은 세 가지 지표를 조합 하여 가독성 프로세스가 생산성에 미치는 영향을 평가했습니다.

1. 가독성 프로세스 특화 설문조사 — 프로세스를 갓 끝마친 엔지니어 대상. 즉각적인 피드백을 얻어 회상 편향(recall bias)을 피하는 데 효과적이지만, 최신 편향(recency bias)과 표본 편향(sampling bias, 완료한 사람만 설문하므로 완료하지 못한 사람의 이야기는 들을 수 없음)이 나타날 수 있습니다.
2. 분기별 대규모 설문조사 — 프로세스가 영향을 줄 것이라 기대되는 지표들을 추적.
3. 정밀한 로그 지표 — 개발자 도구를 활용해 특정 작업 완료에 걸리는 시간을 측정.

생산성 지표를 개인 성과 평가에 쓰지 말 것

이 지표를 엔지니어별 평가나 고성과자/저성과자 식별에 이용하고 싶은 유혹에 빠질 수 있습니다. 하지만 이렇게 하면 역효과만 납니다. 생산성 지표를 성과 평가에 사용하려 들면 엔지니어들이 지표를 손쉽게 조작해버릴 것 이기 때문이죠. 그러면 이 지표는 조직 전반의 생산성 측정과 개선에는 더 이상 활용할 수 없게 됩니다.

표 7-2 목표, 신호, 지표 (가독성 프로세스)

퀀츠	목표	신호	지표
코드 품질	가독성 프로세스를 거친 엔지니어는 품질이 더 좋은 코드를 작성한다	가독성 승인을 받은 엔지니어가 작성한 코드가 그렇지 않은 코드보다 품질이 좋다	분기별 설문: 자신의 코드 품질에 만족한다고 응답한 엔지니어의 비율
		가독성 프로세스가 코드 품질에 긍정적인 영향을 준다	가독성 설문: 가독성 리뷰가 코드 품질에 영향이 없거나 부정적이라고 응답한 비율. 가독성 설문: 프로세스 참여가 소속 팀의 코드 품질을 개선한다고 응답한 비율
	가독성 프로세스를 거친 엔지니어는 더 일관된 코드를 작성한다	가독성 리뷰어의 코드 리뷰로부터 일관된 피드백과 가르침을 받는다	가독성 설문: 가독성 리뷰어의 조언과 가독성 기준이 일관되지 않다고 응답한 비율
	가독성 프로세스를 거친 엔지니어는 건전한 코드 문화에 기여한다	가독성 승인을 받은 엔지니어는 코드 리뷰 때 코딩 스타일·가독성 조언을 규칙적으로 해준다	가독성 설문: 코드 리뷰 때 관련 조언을 규칙적으로 받는다고 응답한 비율
엔지니어들의 관심	해당 없음	해당 없음	해당 없음
지적 복잡성	가독성 프로세스를 거친 엔지니어는 구글 코드베이스와 코딩 모범 사례를 익히게 된다	엔지니어가 가독성 프로세스에서 학습한 내용을 보고한다	가독성 설문: 네 가지 관련 주제에 대해 배웠다고 응답한 비율. 가독성 설문: 전문 지식을 배운다는 점이 강점이라고 응답한 비율
	가독성 프로세스를 거치는 동안 멘토링을 받는다	숙련된 구글 엔지니어(리뷰어)와의 교류가 긍정적이었다고 보고한다	가독성 설문: 가독성 리뷰어와 함께 일하는 경험이 강점이라고 응답한 비율
박자와 속도	가독성 프로세스를 거친 엔지니어는 생산성이 더 높다	가독성 승인을 얻은 엔지니어는 스스로 더 생산적이라고 여긴다	분기별 설문: 자신의 생산성이 높아졌다고 응답한 비율
		가독성 프로세스를 완수한 엔지니어는 팀의 엔지니어링 속도가 빨라졌다고 보고한다	가독성 설문: 프로세스를 거치지 않으면 팀의 속도가 느려진다고 응답한 비율
		가독성 승인자가 작성한 변경 목록(CL)은 아닌 자의 CL보다 검토 시간이 짧다	로그 데이터: 승인자/비승인자 CL 리뷰 시간 중간값(median)
		승인자가 작성한 CL은 코드 리뷰를 통해 원하는 방향으로 유도하기가 수월하다	로그 데이터: 승인자/비승인자 CL의 평균 유도 시간
		승인자가 작성한 CL은 코드 리뷰 통과 시간이 짧다	로그 데이터: 승인자/비승인자 CL의 평균 서브밋 시간
		가독성 프로세스는 엔지니어링 속도에 부정적인 영향을 주지 않는다	가독성 설문: 작업 속도에 부정적 영향을 줬다고 응답한 비율. 리뷰어가 신속하게 응답했다고 응답한 비율. 리뷰의 적시성이 강점이라고 응답한 비율
만족도	엔지니어는 가독성 프로세스의 이점을 깨닫고 프로세스 참여에 긍정적이다	가독성 프로세스가 전반적으로 긍정적인 경험이었다고 여긴다	가독성 설문: 전반적으로 긍정적이었다고 응답한 비율
		가독성 프로세스가 가치 있다고 생각한다	가독성 설문: 가치 있다고 응답한 비율. 가독성 리뷰의 품질이 강점이라고 응답한 비율. 철저함이 강점이라고 응답한 비율
		가독성 프로세스가 실망스럽지 않다고 생각한다	가독성 설문: 프로세스가 불확실하고, 불명확하고, 느리고, 실망스럽다고 응답한 비율. 분기별 설문: 자신의 엔지니어링 속도에 만족한다고 응답한 비율

서브밋(submit)

구글에서 서브밋은 변경 목록(CL)이 코드베이스에 통합되는 단계입니다. 깃허브에서라면 풀 리퀘스트(pull request) 병합(merge)에 해당합니다.

조치를 취하고 결과 추적하기

측정의 출발점은 무언가 조치를 취해서 생산성을 끌어올리는 것이었습니다. 구글의 생산성 연구팀은 연구를 마친 뒤 언제나 개선을 멈추지 않고 지속하는 방법을 담은 ‘추천 할 일 목록’ 을 제공합니다. 개발 도구에 새 기능 추가, 도구 지연시간 단축, 문서 보강, 낡은 프로세스 제거, 심지어 성과 보상 제도의 구조를 바꾸라는 제안까지 있었습니다.

가장 이상적인 방식은 도구 개선 입니다. 도구의 지원 없이 엔지니어들에게 업무 프로세스나 사고방식을 바꾸라고 요구하는 것은 좋지 않습니다. 올바른 데이터와 도구를 제공한다면 엔지니어들 스스로 합리적인 트레이드오프를 찾아낼 것입니다.

가독성 프로세스의 경우, 연구 결과 프로세스가 전반적으로 가치 있음 을 보여줬습니다. 완수한 엔지니어들은 프로세스에 만족했고 배운 게 많다고 느꼈으며, 로그 데이터도 완수자들의 코드 리뷰·서브밋 속도가 빨라졌고 필요한 리뷰어 수도 적어졌다는 사실을 뒷받침했습니다. 연구 과정에서 프로세스를 더 빠르고 즐겁게 바꿔줄 개선안도 찾아냈고, 언어팀들은 추천안을 채택하여 도구와 프로세스를 더 빠르고 투명하게 개선했습니다.

비교 / 트레이드오프

정량적 지표 vs 정성적 지표

관점	정량적 지표 (로그 등)	정성적 지표 (설문·인터뷰)
강점	힘과 확장성 — 회사 전반·장기간 측정, 결과 신뢰 가능	맥락과 설명 — ‘왜’ 그렇게 행동했는지, 다음 개선 단계가 무엇인지
약점	맥락 부재 — 비정상 워크플로의 이유를 설명 못 함	인식 오류, 회상·최신·표본 편향
역할	신호의 프록시	정량 지표의 검증 장치 — 둘이 어긋나면 정량 지표가 잘못됐을 가능성이 큼

어느 한쪽이 우월한 게 아니라 삼각측량의 두 축 입니다. 가독성 측정도 설문(즉시·분기별)과 로그를 조합했고, 결정권자들 역시 행복도·배움은 자체 평가를, 속도·품질은 ‘명확한 숫자’를 요구하여 양쪽 모두를 필요로 했습니다.

내 생각

• “부정적 결과가 나와도 행동이 바뀌는가”는 측정뿐 아니라 모든 기술 검토의 리트머스입니다. PoC, 부하 테스트, A/B 테스트를 시작하기 전에 “결과가 반대로 나오면 정말 계획을 접을 건가?”를 먼저 물으면, 결론이 정해진 채 근거 수집용으로 도는 작업을 초기에 걸러낼 수 있습니다.

• GSM은 모니터링 대시보드 설계와 동형입니다. SLO(목표) → SLI(신호) → 실제 수집 메트릭(지표)의 구조와 같습니다. 가로등 효과는 “수집하기 쉬운 CPU 사용률만 대시보드에 올리는 것”이고, 추적 가능성은 “이 그래프가 어떤 사용자 경험을 대변하는지 답할 수 있어야 한다”는 원칙과 정확히 대응합니다.

• 지표가 평가에 쓰이는 순간 굿하트의 법칙이 발동합니다. “측정 대상이 목표가 되면 좋은 측정이기를 멈춘다” — 생산성 지표를 성과 평가에 연결하면 엔지니어들이 지표를 조작하게 되어 조직 측정 도구로서의 가치가 사라진다는 본문의 경고 그대로입니다. DORA 메트릭을 팀 비교·평가에 쓰지 말라는 권고와 같은 맥락입니다.

• QUANTS는 ‘개발 생산성 도입’을 요구받았을 때의 방어 프레임입니다. 배포 횟수나 PR 처리량 같은 속도 지표만 요구받으면, 품질·만족도 목표를 같은 테이블에 올려 “속도 개선이 품질 희생으로 얻어진 것인지 어떻게 알 것인가”를 되물을 수 있습니다.

관련 개념

• Ch03 지식 공유 — 측정 대상이 된 가독성 프로세스의 배경(문서화·멘토링·코드 문화)
• Ch06 성장하는 조직 이끌기 — 검색 지연시간 사례에서 데이터 과학자들이 ‘지연시간 vs 참여’ 지표를 만든 과정이 같은 데이터 주도 측정 접근법

핵심 정리

• 생산성 측정에 앞서 결과가 긍정적이든 부정적이든 실행 가능한 조치로 이어지는지 확인해야 합니다. 결과를 보고도 취할 수 있는 조치가 아무것도 없다면 측정할 가치가 없습니다.

• GSM 프레임워크 를 활용하여 의미 있는 지표를 선택해야 합니다. 좋은 지표라면 측정하려는 신호를 잘 대표하며, 연관된 목표까지 추적해 올라갈 수 있습니다.

• 지표는 생산성의 모든 측면(QUANTS)을 다루도록 선택해야 합니다. 그래야 기껏 개선한 생산성 요인(예: 개발자 속도)이 결국은 다른 요인(예: 코드 품질)을 희생한 대가로 얻어지는 우를 방지할 수 있습니다.

• 정성적 지표도 지표입니다. 엔지니어의 믿음(생각)을 장기간에 걸쳐 추적하는 설문 메커니즘을 고려해보세요. 정성적 지표가 나타내는 결과가 정량적 지표와 일치해야 합니다. 그렇지 않다면 잘못된 정량적 지표일 가능성이 큽니다.

• 개발자 워크플로와 보상 제도에 영향을 주는 제안 을 찾아내는 걸 목표로 삼아야 합니다. 추가 훈련이나 문서화를 추천해야 하는 경우도 있지만, 개발자의 습관을 고쳐줘야 실질적인 변화로 이어져 정착될 가능성이 큽니다.