[IT 도서 리뷰] 구글 엔지니어는 이렇게 일한다 (CH. 7)

728x90

CH.7 엔지니어링 생산성 측정하기

소프트웨어 엔지니어링 측면에서 엔지니어링 생산성 자체에 집중하는 전문가팀을 별도로 꾸려두면 회사 성장 과정에서 아주 중요하고 값진 통찰을 얻을 수 있다.

7.1 엔지니어링 생산성을 측정하는 이유

사업을 키운다는 건 소통 비용이 증가한다는 것을 의미한다. 이를 개개인의 생산성을 높이는 것으로 소통 비용 증가를 억제할 수 있다.

생산성을 늘리기 위해서는 엔지니어링 프로세스에서 비효율적인 부분을 찾아 고쳐야 한다. 하지만 개선 사이클 자체를 만들고 관리하는 데도 인력이 투입된다.

구글은 엔지니어링 생산성을 이해하기 위한 전담 연구팀을 꾸려 이 ㅌㅌ트레이드오프에 대응했다.

우선 문제를 분류하는 일부터 시작한다.

예시: 가독성 프로세스

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

생산성 측정을 해도 될지를 결정하는 데 도움되는 질문 목록

어떤 결과를 기대하고, 왜 그런가? : 우리 모두는 어떤 일이 일어나야 하는지에 대한 선입견을 가지고 있으며 처음부터 이 사실을 인정하고 시작하면 무의식 속에서 의도한 결과를 억지로 만들어내는 실수를 막을 수 있음
데이터가 기대한 결과를 뒷받침한다면 어떤 조치를 취하겠는가? : 아무런 조치도 취하지 않을 거라면 측정을 해봐야 의미가 전혀 없음
부정적인 결과가 나온다면 적절한 조치를 취할 것인가? : 부정적인 결과가 나와도 결정이 바뀌지 않는 경우가 흔함
결과에 따른 조치는 누가 결정하고, 언제 수행하는가? : 측정 의뢰자가 조치를 취할 권한이 있는지를 확인

어떤 도구나 프로세스가 생산성에 미치는 영향을 측정하지 말아야 할 합당한 에시

당장 프로세스/도구를 변경할 여유가 없다.
어떤 겨로가가 나오든 곧 다른 요인에 의해 의미가 없어질 것이다.
측정 결과를 이미 확정된 계획을 뒷받침하는 용도로만 쓴다.
측정할 수 있는 지표들이 문제를 평가하기에 충분히 정확하지 않으며, 다른 요인들 때문에 혼탁해질 우려가 크다.

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

구글은 지표를 만들 때 GSM이라는 프레임워크를 쓴다. G는 목표 / S는신호 / M은 지표

목표: 측정자가 원하는 최종 결과
신호: 원하는 최종 결과를 이루었는지 판단하는 방법
지표: 신호를 대변. 우리가 실제로 측정하는 대상

GSM 프레임워크는 지표를 만들 때 유용한 지침이 되어준다.

첫째, 가장 먼저 목표를 세우고, 신호르 정한 다음, 마지막으로 지표를 만드는 순서 덕분에 가로등 효과를 없애준다.

가로등 효과
'가로등 아래에서 열쇠 찾기' 즉, 보이는 곳만 봐서는 정작 열쇠가 떨어진 곳은 살펴보지도 못할 수 있다는 뜻

둘째, GSM은 실제로 결과를 측정하기 앞서 원칙에 입각하여 적절한 지표들을 선정하게 해줌으로써 지표 크리프와 지표 편향을 예방해준다. (GSM을 통해 선택된 지표들은 원래 목표와 관련이 깊음)

셋째, GSM은 측정이 되는 영역과 그렇지 않은 영역을 알려준다.

중요한 것은 추적 가능성을 잃지 않는 것이다.

7.4 목표(goal)

목표는 원하는 속성을 설명하되 어떠한 지표도 명시해서는 안된다. GSM의 효과를 보려면 가장 먼저 측정할 목표 목록을 올바르게 작성해야 한다.

구글은 속도를 높이는 데 집중하느라 품질 측정을 놓치는 사태를 방지하기 위해 생산성을 다섯 개의 요소로 나누고 퀀츠(QUANTS)라고 지었다.

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

7.5 신호(signal)

신호는 목표 달성 여부를 알 수 있는 방법이다.

7.6 지표(Metric)

신호를 측정하는 방법의 최종 형태이다. 대리하는 개념이다 보니 신호를 완벽하게 측정해내지는 못할 수 있다.

7.7 데이터로 지표 검증하기

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

7.9 마치며

의도치 않은 결과로 이어지지 않기 위해서는 주어진 데이터를 정확하게 이해하여 주관적인 편향을 제거하는 걸 목표로 삼아야 한다.

7.10 핵심 정리

생산성 측정에 앞서 결과가 긍정적이든 부정적이든 실행 가능한 조치로 이어지는지 확인해야 한다. 결과를 보고도 취할 수 있는 조치가 아무것도 없다면 측정할 가치가 없다.
GSM 프레임워크를 활용하여 의미 있는 지표를 선택해야 한다. 좋은 지표라면 측정하려는 신호를 잘 대표하며, 연관된 목표까지 추적해 올라갈 수 있다.
지표는 생산성의 모든 측면(QUANTS)을 다루도록 선택해야 한다. 그래야 기껏 개선한 생산성 요인(예: 개발자 속도)이 결국은 다른 요인(예: 코드 품질)을 희생한 대가로 얻어지는 우를 방지할 수 있다.
정성적 지표도 지표이다. 엔지니어의 믿음(생각)을 장기간에 걸쳐 추적하는 설문 메커니즘을 고려하라. 정성적 지표가 나타내는 결과가 정량적 지표와 일치해야 한다. 그렇지 않다면 잘못된 정량적 지표일 가능성이 크다.
개발자 워크플로와 보상 제도에 영향을 주는 제안을 찾아내는 걸 목표로 삼아야 한다. 추가 훈련이나 문서화를 추천해야 하는 경우도 있지만, 개발자의 습관을 고쳐줘야 실질적인 변화로 이어져 정착될 가능성이 크다.