- 엔지니어링 생산성 자체에 집중하는 전문가팀을 별도로 꾸려두면 회사 성장 과정에서 아주 중요하고 값진 통찰을 얻을 수 있다.
- 조직이 두 배 커지면 소통 비용은 제곱으로 늘어난다.
- 개선 사이클 자체를 만들고 관리하는 데도 인력이 투입된다. 구글은 소프트웨어 엔지니어링 생산성 개선과 더불어 개선 업무 자체의 효율까지 높이는 목표를 세웠다.
- 엔지니어링 생산성을 이해하기 위한 전담 연구팀을 꾸려 트레이드오프에 대응했다.
- 측정 자체에도 비용이 많이 든다. 의미 없는 측정을 하느라 시간과 자원을 낭비하지는 말아야 한다.
- 생산성 측정 시 질문에 대해 고려해볼 것
- 우리 모두는 어떤 일이 일어나야 하는지에 대한 선입견을 가지고 있다. 이 사실을 인정하고 시작하면 무의식 속에서 의도한 결과를 억지로 만들어내는 실수를 막을 수 있다.
- 아무런 조치를 취하지 않을 거라면 측정을 해봐야 의미가 전혀 없다. 측정 결과에 상관없이 어차피 현상 유지할 계획인지를 주의해야 한다.
- 이 질문을 던지는 이유는 부정적인 결과가 나와도 결정이 바뀌지 않는 경우가 흔하기 때문이다.
- 결정권자들은 연구 결과를 알고는 싶어 하지만 다른 이유들을 들어서라도 이미 정해진 진로를 잘 틀지 않는다.
- 측정 의뢰자가 조치를 취할 권한이 있는지(혹은 권한자를 대신해 직접 수행할 사람인지)를 확인한다.
- 소프트웨어 프로세스를 측정하는 궁극적인 목적은 사업적인 결정을 내리는 데 도움을 주기 위함이다. 그래서 결정을 내릴 사람이 누구이고 또 그에게 확신을 주려면 어떤 형태의 데이터가 필요한지를 이해해야 한다.
- 결정권자를 만나서 설문 결과나 로그 데이터를 신뢰하는지, 복잡한 통계 분석에 익숙한지, 인터뷰에서 공감되는 이야기가 나오면 결정에 큰 영향을 주는지 등을 확인해야 한다. 결정권자가 결과의 형태를 신뢰하지 않는다면 이 역시 프로세스를 측정할 필요가 없다.
- 어떤 도구나 프로세스가 생산성에 미치는 영향을 측정하지 말아야 할 합당한 이유는 많다.
- 더 빠른 빌드도구로 바꾸면 매주 몇 시간씩 절약할 수 있지만, 당장 달성해야할 급한 마일스톤이 있는 경우 등
- 조직 개편을 앞두고 소프트웨어 프로세스를 측정하는 상황, 폐기한 제품의 기술 부채를 평가하는 일 등
- 이해관계자가 해당 문제와 맞지 않는 특정 방식만을 신뢰한다면 고생해서 데이터를 모을 이유가 없다.
- 개선 정도가 작더라도 일을 계획대로 진행하고자 하는 경우
- 필요한 지표를 측정할 수 없는 경우, 정확도는 떨어지더라도 코드 라인 수 같은 다른 지표들을 측정해볼 수 있다. 하지만 지표의 정확성이 떨어진다는 이유로 원래대로 일을 진행시킬 것이므로 의미가 없어질 수 있다.
- 구글이 지표를 만들 때 사용하는 프레임워크, GSM: 목표(Goal), 신호(Signal), 지표(Metric)
측정자가 원하는 최종 결과. 측정을 통해 이해하고 싶은 내용을 고차원의 어휘로 표현하되 특정한 측정 방식을 명시해서는 안 된다.
원하는 최종 결과를 이루었는지 판단하는 방법. 우리가 측정하고 싶어 하는 것이지만 신호 자체는 측정하지 못할 수도 있다.
실제로 측정하는 대상. 신호를 대변한다. 이상적인 측정법은 아닐 수 있으나 충분히 가깝다고 믿는 것이어야 한다.
- 목표를 세우고, 신호를 정한 다음, 마지막으로 지표를 만드는 순서 덕분에 가로등 효과를 없애준다.
가로등 효과(streetlight effect): 가로등 아래에서 열쇠 찾기. 보이는 곳만 봐서는 정작. 열쇠가 떨어진 곳은 살펴보지 못할 수 있다는 의미. 예를들어 진짜 필요한 지표인지와 관계. 없이 쉽게 구할 수 있고 측정하기 쉬운 지표를 사용하는 것.
- GSM은 손쉽게 이용할 수 있는 지표가 아니라 목표를 이루는 데 실제로 도움이 되는 지표가 무엇인지를 생각해보게 이끌어준다.
- GSM은 실제로 결과를 측정하기 앞서 원칙에 입각하여 적절한 지표들을 산정하게 해줌으로써 지표 크리프(metrics creep)와 지표 편향(metrics bias)을 예방해준다.
- GSM은 '목표를 측정할 수 있는 능력'을 기준으로 지표를 선정하게 해준다. 이해관계자는 GSM에 따라 선택된 지표들이 원래 목표와 관련이 깊으며 결과를 측정하기 위한 최선의 지표들이라는 데 쉽게 동의할 것이다.
- GSM은 측정이 되는 영역과 그렇지 않은 영역을 알려준다.
-
먼저 모든 목표를 나열한 다음 각 목표를 포착할 수 있는 신호들을 찾아낸다.
-
모든 신호가 다 측정할 수 있는 것은 아니다. 그리고 측정할 수 없더라도 괜찮다. 최소한 측저할 수 없는 것이 무엇인지는 알 수 있기 때문이다. 누락된 지표가 무엇인지 알고 있으니 새로운 지표를 만들어야 할지 아니면 측정 자체를 그만두는 게 나을지를 판단해볼 수 있다.
-
중요한 것은 추적 가능성(traceability)를 잃지 않는 것이다. 각각의 지표로부터 관련된 신호를 찾아낼 수 있고, 나아가 그 신호가 대변하는 목표에까지 거슬러 추적할 수 있어야 한다. 그래야만 어떤 지표가 무엇을 측정하고 왜 측정하는지를 알 수 있다.
- 목표는 원하는 속성을 설정하되 어떠한 지표도 명시해서는 안 된다. 따라서 목표 자체는 측정이 불가능하다.
- 목표 목록을 잘 정의하면 신호와 지표 선정 단계로 들어서기 앞서 모든 이해관계자의 동의를 얻을 수 있다.
- GSM의 효과를 보려면 가장 먼저 측정할 목표 목록을 올바로 작성해야 한다.
- 생산성에 영향을 주는 트레이드오프들을 다 감안하지 못해서 측정 결과가 잘못된 길로 인도되는 경우도 많았다.
- 이를 방지하기 위해 트레이드오프가 일어나는 다섯 개 목표(QUANTS)를 고안했다.
- 작성된 코드의 품질은 어떤가?
- 회귀 버그를 예방하기에 충분한 테스트 케이스가 갖춰졌는가?
- 아키텍처는 위험과 변경을 받아들일 수 있을 만큼 유연한가?
- 엔지니어들은 얼마나 자주 몰입 상태에서 깨어나는가?
- 알림은 엔지니어의 주의력이 얼마나 흐트리는가?
- 도구는 엔지니어들이 작업 맥락을 전환하는데 도움을 주는가?
- 작업을 완료하는데 인지 부하가 얼마나 걸리는가?
- 해결해야 할 문제에 내재된 복잡성은 어느 정도인가?
- 엔지니어들이 불필요한 복잡성을 처리해야 하는가?
- 엔지니어들이 작업을 얼마나 빨리 완수할 수 있는가?
- 릴리스를 얼마나 빨리 밀어낼 수 있는가?
- 주어진 시간에 얼마나 많은 작업을 완료하는가?
- 엔지니어가 도구에 얼마나 만족하는가?
- 도구가 엔지니어에게 필요한 기능을 얼마나 잘 지원하는가?
- 엔지니어들이 주어진 업무와 완성한 제품에 얼마나 만족하는가?
- 엔지니어들이 번아웃되지는 않는가?
가독성 팀이 작성한 목표
- 가독성 프로세스를 거친 엔지니어는 품질이 더 좋은 코드를 작성한다.
- 가독성 프로세스를 통해 일관성이 높아진다.
- 가독성 프로세스는 건실한 코드 문화에 기여한다.
- 가독성은 몰입과 관련이 없다.
- 가독성 프로세스를 거친 엔지니어는 구글의 코드베이스와 최선의 코딩 모범 사례를 배우고, 프로세스 중에는 멘토링을 받는다.
- 가독성 프로세스를 거친 엔지니어는 일을 더 빠르고 효율적으로 완료한다.
- 엔지니어는 가독성 프로세스의 이점을 확인하고 프로세스 참여를 긍정적으로 생각한다.
- 신호는 목표 달성 여부를 알 수 있는 방법이다.
- 모든 신호를 측정할 수 있는 것은 아니지만 신호와 목표가 1:1 상태가 아닌 지금 단계에서는 괜찮다. 모든 목표에는 신호가 최소한 하나는 필요하다 (둘 이상이 좋긴하다).
- 어떤 목표들은 신호를 공유하기도 한다.
| 목표 | 신호 |
|---|---|
| 가독성 프로세스를 거친 엔지니어는 품질이 더 좋은 코드를 작성한다. | 가독성 승인을 얻은 엔지니어가 작성한 코드가 그렇지 않은 엔지니어가 작성한 코드보다 품질이 좋다. 가독성 프로세스가 코드 품질에 긍정적인 영향을 준다. |
| 가독성 프로세스를 거친 엔지니어는 구글의 코드베이스와 최선의 코딩 모범 사례를 익히게 된다. | 엔지니어가 가독성 프로세스로부터 배운 것이 있다고 보고한다. |
| 가독성 프로세스를 거친 엔지니어는 작업을 더 빠르고 효율적으로 완수한다. | 가독성 승인을 얻은 엔지니어는 그렇지 않은 엔지니어보다 더 생산적이라고 스스로 여긴다. 가독성 승인을 얻은 엔지니어가 작성한 변경은 그렇지 않은 엔지니어가 작성한 변경보다 리뷰가 더 빨리 끝난다. |
| 엔지니어들이 가독성 프로세스의 이점을 확인하고 프로세스 참여를 긍정적으로 생각한다. | 엔지니어들이 가독성 프로세스가 가치있다고 생각한다. |
- 지표는 신호를 측정하는 방법의 최종 형태이다.
- 신호 자체가 아니라 측정 가능한 프록시이다. 대리하는 개념이다 보니 신호를 완벽하게 측정해내지는 못할 수 있다.
- 예) 가독성 프로세스를 거친 엔지니어들의 코드 리뷰가 빨라졌는지를 측정하기 위해 설문과 로그 데이터를 조합해 사용한다.
- 애초에 측정 불가능한 신호라면 연관 지표가 하나도 없을 것이다.
- 예) 코드 품질 측정. 구글도 엔지니어들에게 코드 품질을 스스로 평가하라고만 요청하고 정량적인 측정은 포기함.
- 경험표집법(Experience Sampling Method, ESM): 일상 생활 중 특정한 사건을 경험한 직후에 즉각적인 응답을 요구하는 연구 방법.
- 정량적 지표는 힘과 확장성을 주기 때문에 유용하나, 맥락 정보나 설명이 빠져있다.
- 세 가지 지표를 조합하여 가독성 프로세스가 생산성에 미치는 영향을 평가했다.
- 가독성 프로세스에 특화된 설문조사를 수행했다. 이 설문은 프로세스를 갓 끝마친 엔지니어를 대상으로 수행하여 프로세스에 관한 즉각적인 피드백을 얻을 수 있었다. 즉각적이라는 점에서 회상 편향을 피하는 데 효과적이지만 최신 편향과 표본 편향이 나타날 수 있다.
- 가독성과 직접 관련은 없는 대신 가독성 프로세스가 영향을 줄 것이라 기대되는 지표들을 추적하기 위해 분기별로 대규모 설문조사를 수행했다.
- 개발자 도구를 활용하여 엔지니어들이 특정 작업을 완료하는데 걸리는 시간을 알려주는 정밀한 로그 지표를 이용했다.
- 주어진 주제로 연구를 마친 뒤에는 언제나 개선을 멈추지 않고 지속하는 방법을 담은 '추천 할 일 목록'을 제공했다.
- 올바른 데이터와 도구를 제공한다면 엔지니어들 스스로 합리적인 트레이드오프를 찾아낸다.
- 생산성 전문가로 구성된 팀을 두는 것이 소프트웨어 엔지니어링의 다양한 측면에서 아주 유익하다는 사실을 깨달았다.
- 생산성 연구팀은 항상 데이터 중심으로 판단하면서 주관적인 편향을 제거하는 걸 목표로 삼아야 한다.
- 생산성 측정에 앞서 결과가 긍정적이든 부정적이든 실행 가능한 조치로 이어지는지 확인해야 한다. 결과를 보고도 취할 수 있는 조치가 아무것도 없다면 측정할 가치가 없다.
- GSM 프레임워크를 활용하여 의미 있는 지표를 선택해야 한다. 좋은 지표라면 측정하려는 신호를 잘 대표하며, 연관된 목표까지 추적해 올라갈 수 있다.
- 지표는 생산성의 모든 측면(QUANTS)를 다루도록 선택해야 한다. 그래야 기껏 개선한 생산성 요인(예: 개발자 속도)이 결국은 다른 요인(예: 코드 품질)을 희생한 대가로 얻어지는 우를 방지할 수 있다.
- 정성적 지표도 지표다. 엔지니어의 믿음(생각)을 장기간에 걸쳐 추적하는 설문 메커니즘을 고려해보자. 정성적 지표가 나타내는 결과가 정량적 지표와 일치해야 한다. 그렇지 않다면 잘못된 정량적 지표일 가능성이 크다.
- 개발자 워크플로와 보상 제도에 영향을 주는 제안을 찾아내는 걸 목표로 삼아야 한다. 추가 훈련이나 문서화를 추천해야 하는 경우도 있지만, 개발자의 습관을 고쳐줘야 실질적인 변화로 이어져 정착될 가능성이 크다.