구글 엔지니어는 이렇게 일한다: 엔지니어링 생산성 측정 및 개선
in BOOK on 구글 엔지니어는 이렇게 일한다, Engineering-productivity, Gsm-framework, Google, Metrics, Data-driven, Performance-measurement, Team-culture, 엔지니어링-생산성, 개발자-생산성, 데이터-기반-의사결정, 성과-측정, 조직-문화
기업이 성장함에 따라 엔지니어링 조직의 규모는 자연스럽게 커진다. 하지만 조직이 두 배로 커진다고 해서 성과가 두 배로 늘어나는 것은 아니다. 오히려 소통에 드는 비용은 제곱으로 증가하며, 이는 조직의 성장을 가로막는 보이지 않는 벽이 되기도 한다.
이러한 문제를 해결하기 위해 많은 기업이 ‘개인의 생산성 향상’에 주목한다.
엔지니어 개개인의 생산성을 높일 수 있다면, 가파르게 증가하는 소통 비용을 억제하면서도 지속적인 사업 확장을 기대할 수 있기 때문이다. 이를 위해서는 현재 엔지니어링 프로세스의 비효율을 정확히 진단하고, 개선 사이클을 꾸준히 반복해야 한다.
구글 역시 이 문제에 깊이 공감하고, 엔지니어링 생산성을 이해하고 개선하기 위한 전담 연구팀을 운영했다.
이 팀은 소프트웨어 엔지니어뿐만 아니라 인지심리학, 행동경제학 등 다양한 분야의 사회과학자들이 함께하여 기술적 산출물을 넘어 개인의 동기, 성과 보상, 복잡한 업무 관리 전략과 같은 ‘인간적인 측면’까지 아우르는 깊이 있는 연구를 진행했다.
이번 포스트에서는 구글의 생산성 연구팀이 어떻게 의미 있는 지표를 찾고, 이를 통해 실질적인 생산성 개선을 이끌어냈는지 그 핵심 방법론인 GSM(Goals-Signals-Metrics) 프레임워크를 중심으로 알아본다.
- 1. 선별: 측정할 가치가 있는가?
- 2. GSM 프레임워크: 목표와 신호를 뒷받침하는 의미 있는 지표 선정
- 3. 목표(Goals)
- 4. 신호(Signals)
- 5. 지표(Metrics)
- 6. 데이터로 지표 검증
- 7. 조치 취하고 결과 추적
- 정리하며..
- 참고 사이트 & 함께 보면 좋은 사이트
1. 선별: 측정할 가치가 있는가?
“측정할 수 없다면 관리할 수 없고, 관리할 수 없다면 개선할 수도 없다. - 피터 드러커”
피터 드러커의 유명한 말처럼 개선의 첫걸음은 측정에서 시작된다. 하지만 우리는 이 명제에 숨겨진 중요한 전제를 잊지 말아야 한다.
바로 ‘측정할 가치가 있는 것을 측정해야 한다’는 것이다.
측정은 결코 공짜가 아니다. 데이터를 수집하고, 분석하고, 그 결과를 모두가 이해할 수 있도록 공유하는 데는 상당한 시간과 인적 자원이 소모된다. 만약 측정 프로세스가 번거롭고 성가시다면, 오히려 엔지니어링 조직 전체의 속도를 저해하는 역효과를 낳을 수도 있다.
따라서 본격적인 측정에 앞서, 이 측정이 정말로 의미 있는 행동으로 이어질 수 있는지를 판별하기 위한 질문 목록이 필요하다.
구글의 가독성팀이 “우리의 가독성 프로세스는 투입되는 비용 이상의 가치를 제공하는가?” 라는 질문을 던졌을 때, 연구팀은 아래의 질문들을 통해 측정의 가치를 함께 고민하였다.
<측정 전, 반드시 답해야 할 4가지 질문>
1.어떤 결과를 기대하며, 그 이유는 무엇인가?
측정을 통해 무엇을 확인하고 싶은지 명확해야 한다.
흥미롭게도 가독성 팀은 이 질문에 자신들이 무엇을 기대하는지 확실하지 않다고 했다. 과거에는 이 프로세스가 분명 가치가 있었지만, 자동 포맷터나 정적 분석 도구가 보편화된 지금도 그럴지는 미지수였기 때문이다.
막연한 기대가 아닌, 명확한 가설이 없다면 측정의 방향을 잃기 쉽다.
2.기대한 결과가 나온다면, 어떤 조치를 취할 것인가?
긍정적인 데이터가 나왔을 때, 아무것도 하지 않을 것이라면 측정은 무의미하다.
측정 결과와 상관없이 ‘현상 유지’가 유력하다면 굳이 자원을 낭비할 필요가 없다.
3.부정적인 결과가 나와도 적절한 조치를 취할 것인가?
데이터가 기존의 믿음이나 계획과 다르게 나왔을 때, 그 결과를 수용하고 계획을 수정할 의지가 있어야 한다.
많은 경우, 사람들은 불편한 데이터를 외면하거나 자신의 주장을 뒷받침할 또 다른 근거를 찾으려 한다.
가독성 팀은 이 질문에 “만약 비용이 이점보다 크다고 나오면, 프로세스를 폐지하겠다.” 고 명확히 답했기 때문에 다음 단계로 나아갔다.
4.결과에 따른 조치는 누가 결정하는가?
측정의 궁극적인 목표는 더 나은 의사결정을 돕는 것이다. 따라서 데이터를 요청한 사람이 최종 결정을 내릴 권한을 가졌는지, 혹은 결정권자가 신뢰할 만한 형태의 데이터를 우리가 제공할 수 있는지 확인해야 한다.
결정권자가 결과의 형태를 신뢰하지 않을 것이 뻔하다면, 측정은 시작할 가치도 없다.
<측정하지 말아야 할 합당한 이유들>
때로는 측정을 하지 않는 것이 더 현명한 선택일 수도 있다.
1.변경할 여유가 없을 때
더 빠른 빌드 툴이 명백히 좋다는 것을 알아도, 중요한 마일스톤 직전이라 모든 개발을 중단시킬 수 없다면 지금 당장 측정하고 교체할 이유가 없다.
2.결과가 곧 무의미해질 때
조직 개편이 예정되어 있다면, 현재 조직을 기준으로 한 측정 데이터는 곧 가치를 잃게 된다.
또한, 결정권자의 신념이 너무 확고해서 어떤 데이터로도 설득이 불가능하다면, 괜한 노력을 들일 필요가 없다.
3.계획을 정당화하기 위한 측정일 때
가장 흔한 함정이다.
이미 ‘A 방식으로 바꾸자’ 고 결정을 다 해놓고, ‘A 방식이 얼마나 좋은지 데이터를 뽑아줘’라고 요청하는 경우이다.
이는 진정한 의미의 개선이 아닌, 요식행위에 불과하다.
결론적으로 소프트웨어 프로세스 측정은 그 결과 데이터가 구체적인 결정에 직접적인 영향을 줄 수 있을 때, 그리고 그 결정을 내릴 권한을 가진 사람들에 의해서만 진행되어야 한다.
이것이 지켜지지 않는다면, 측정은 그저 보고서를 위한 보고서, 숫자를 위한 숫자로 전락하고 만다.
2. GSM 프레임워크: 목표와 신호를 뒷받침하는 의미 있는 지표 선정
측정의 가치를 확인했다면, 이제 ‘무엇’을 측정할지 정해야 한다.
구글은 이 단계에서 GSM(Goals-Signals-Metrics) 프레임워크를 활용하여 의미 있는 생산성 지표를 만들어 나간다.
GSM은 아래 3가지 요소로 구성된 하향식(Top-down) 프레임워크이다.
- 목표(Goals)
- 달성하고자 하는 최종 결과
- ‘무엇을 이해하고 싶은가?’에 대한 답이며, 구체적인 측정 방식을 명시하지 않고, 높은 수준의 언어로 표현됨
- 신호(Signals)
- 설정한 목표를 달성했는지 어떻게 알 수 있을지에 대한 답
- 목표 달성을 암시하는 긍정적/부정적 변화들이며, 신호 그 자체는 직접 측정하기 어려울 수 있음
- 지표(Metrics)
- 신호를 정량적으로 대변하는 값
- 실제로 측정하는 대상이며, 데이터를 통해 추적하고 관리하게 됨
<GSM 프레임워크의 3가지 핵심 장점>
1.가로등 효과(Streetlight Effect) 방지
많은 조직이 ‘가로등 아래에서만 열쇠를 찾는 사람’과 같은 실수를 저지른다.
가로등 효과(Streetlight Effect)
가로등 아래에서 열쇠 찾는 것을 비유하는 말로, 보이는 곳만 봐서는 정작 열쇠가 떨어진 곳은 살펴보지도 못할 수 있다는 뜻임
즉, 정말로 중요한 지표가 아닌, 단지 측정하기 쉽다는 이유만으로 특정 지표를 선택하는 것이다.
GSM 은 목표 → 신호 → 지표 순서의 하향식 접근을 강제함으로써, 우리가 당장 손에 쥐기 쉬운 지표가 아니라, 최종 목표 달성에 정말로 도움이 되는 지표가 무엇인지 먼저 고민하도록 이끌어준다.
2.지표 편향(Metric Bias) 및 왜곡 예방
명확한 원칙 없이 지표를 선정한 상태에서, 만약 측정 결과가 이해관계자의 기대에 미치지 못하면 어떤 일이 벌어질까?
사람들은 기존 결과를 부정하고, 자신들의 주장에 유리한 결과가 나올 때까지 다른 지표를 찾아 헤매고 싶은 유혹에 빠진다. 애초에 원칙 없이 선택한 지표들이었으니 다른 지표로 대체해도 이상할 게 없다.
GSM 은 결과를 보기 전에 ‘무엇을, 왜 측정할 것인지’에 대한 원칙을 먼저 세우게 함으로써 이러한 지표 편향과 왜곡을 막아준다.
모든 이해관계자가 사전에 합의한 지표는 결과에 대한 신뢰도를 높이고, 논의가 샛길로 빠지는 것을 방지한다.
3.측정 가능한 영역과 불가능한 영역의 명확화
GSM 을 따라 목표와 신호를 정의하다 보면, 어떤 신호를 명확한 지표로 측정할 수 있지만 어떤 신호를 그렇지 않을 수 있다.
이것은 실패가 아니라 오히려 중요한 발견이다. 우리가 무엇을 측정할 수 있고, 무엇을 측정할 수 없는지 명확히 인지하게 되기 때문이다.
이를 통해 현재의 데이터 공백을 채우기 위해 새로운 지표를 개발해야 할지, 아니면 해당 영역은 정성적인 평가로 남겨둘지 등 더 나은 의사결정을 내릴 수 있다.
이 모든 것의 중심에는 추적 가능성(Traceability) 이 있다.
잘 설계된 GSM 프레임워크 안에서는, 모든 지표(Metrics)는 그것이 대변하는 신호(Signals)로, 그리고 그 신호는 다시 최종 목표(Goals)로 거슬러 올라갈 수 있다.
이 추적 가능성 덕분에 모든 지표에 대해 ‘이것을 왜 측정하는가?’라는 질문에 답할 수 있게 된다.
3. 목표(Goals)
GSM 프레임워크의 첫 단계는 목표를 정의하는 것이다.
목표는 우리가 원하는 바람직한 상태를 설명하는 질적인 문장이다. 이 단계에서는 어떤 구체적인 지표도 언급하지 않기 때문에 목표 자체를 측정할 수는 없다. 하지만 명확한 목표 목록을 정의하고 모든 이해관계자의 동의를 얻는 것은, 이후 과정이 길을 잃지 않게 만드는 가장 중요한 과정이다.
균형 잃은 목표의 함정: 트레이드오프를 고려하라
만약 목표를 잘못 설정하면 어떻게 될까?
가독성 팀의 예를 다시 보자. 만약 이 팀이 코드 품질이라는 핵심 목표를 잊고, 오직 ‘가독성 프로세스를 빠르고 쉽게 만드는 것’에만 집중한다고 가정해보자. 이 때 한 팀원이 아래와 같이 제안한다.
“제가 리뷰 속도를 정말 빠르게 만들 수 있습니다. 코드 리뷰를 아예 안 하면 됩니다.”
극단적인 예시이지만, 핵심을 잘 짚고 있다. 많은 팀이 속도를 높이는 데 집중한 나머지, 그로 인해 희생될 수 있는 품질을 측정하는 것을 잊는 실수를 한다.
생산성에 영향을 주는 중요한 트레이드오프 관계를 고려하지 않으면, 측정 결과는 우리를 잘못된 길로 인도할 수 있다.
구글의 5가지 생산성 핵심 요소
이러한 함정을 피하기 위해 구글은 엔지니어링 생산성을 다각도에서 바라볼 수 있는 5가지 핵심 요소를 정의하고, 각 요소에 대한 목표를 모두 설정하도록 권장한다. 어느 한 요소를 개선하려다 다른 요소를 희생시키는 실수를 막기 위함이다.
- 코드 품질(Quality of the code)
- 코드는 버그를 막을 만큼 충분히 테스트되었는가? 아키텍처는 변화에 유연하게 대처할 수 있는가?
- 엔지니어들의 몰입도(Attention from engineers)
- 엔지니어는 얼마나 자주 하던 일을 중단하고 다른 일에 신경 써야 하는가? 불필요한 알림이 주의력을 얼마나 흩트리는가?
- 지적 복잡성(Intellectual complexity)
- 하나의 작업을 완료하는 데 얼마나 많은 인지적 노력이 필요한가? 엔지니어가 불필요한 복잡성을 감당하고 있지는 않은가?
- 박자와 속도(Tempo and velocity)
- 엔지니어가 아이디어를 실제로 코드로 구현하고 배포하기까지 얼마나 빠른 사이클을 유지할 수 있는가?
- 만족도(Satisfaction)
- 엔지니어는 사용하는 도구, 수행하는 업무, 그리고 최종 결과물에 얼마나 만족하는가? 번아웃의 위험은 없는가?
<예시: 가독성 팀의 균형 잡힌 목표 설정>
- 코드 품질(Quality of the code)
- 가독성 프로세스를 거치면 코드의 품질과 일관성이 높아진다.
- 엔지니어들의 몰입도(Attention from engineers)
- (가독성 프로세스는 몰입도와 직접적인 관련이 없다고 판단)
- 지적 복잡성(Intellectual complexity)
- 가독성 프로세스를 통해 엔지니어는 팀의 코드베이스와 모범 사례를 배우고 멘토링을 받는다. (오히려 긍정적 영향)
- 박자와 속도(Tempo and velocity)
- 가독성 프로세스를 거친 엔지니어는 장기적으로 일을 더 효율적으로 완료한다.
- 만족도(Satisfaction)
- 엔지니어는 가독성 프로세스의 이점을 이해하고 참여를 긍정적으로 생각한다.
이렇게 다각도로 목표를 설정함으로써, ‘속도’만을 위해 ‘품질’이나 ‘만족도’를 희생시키는 편협한 시각에서 벗어나, 엔지니어링 생산성에 대한 전체적인 그림을 보며 올바른 방향으로 나아갈 수 있다.
4. 신호(Signals)
목표를 세웠다면 다음은 신호를 정의할 차례이다.
신호는 목표를 향해 제대로 나아가고 있는지를 알려주는 증거이다. 모든 목표에는 그 목표의 달성 여부를 가늠할 수 있는 최소 하나 이상의 신호가 반드시 필요하다.
5. 지표(Metrics)
마지막 단계는 신호를 실제로 측정하기 위한 지표를 정의하는 것이다. 지표는 신호를 측정하는 구체적인 방법이며, 우리가 실제로 추적하고 분석할 데이터의 최종 형태이다.
하나의 신호를 더 정확하게 파악하기 위해 여러 지표를 종합해서 사용하기도 한다. 예를 들어 ‘코드 리뷰가 빨라졌다’는 신호를 측정하기 위해 시스템 로그를 통해 실제 소요 시간을 측정하는 정량적 지표와 설문 조사를 통해 개발자가 느끼는 속도감을 묻는 정성적 지표를 조합할 수 있다.
물론, 어떤 신호는 측정 자체가 불가능할 수도 있다. 그런 신호는 관련된 지표가 하나도 없을 것이다. 하지만 이 또한 의미 있는 발견이다. 우리가 무엇을 측정할 수 있고 없는지를 명확히 알게 되기 때문이다.
이처럼 GSM 프레임워크는 소프트웨어 프로세스를 측정하는 이유(Goals)와 실제 측정 방법(Metrics)을 명확하게 이어주는 훌륭한 수단이다.
이를 통해 우리는 길을 잃지 않고, 데이터에 기반한 의미 있는 개선을 추진해 나갈 수 있다.
6. 데이터로 지표 검증
GSM 프레임워크를 통해 지표를 정의했다면, 그 지표가 정말 현실을 올바르게 반영하는지 검증하는 과정이 반드시 필요하다.
예를 들어 ‘빌드 지연 시간에 대한 엔지니어의 일상 경험’을 포착하기 위해, 빌드가 끝날 때마다 설문을 보내는 지표를 만들었다고 가정해보자.
그런데 데이터를 살펴보니, 몇몇 엔지니어들은 빌드를 실행한 적이 없다고 응답했다. 원인은 바로 자동화 도구였다. 엔지니어의 개입 없이 백그라운드에서 실행된 빌드는 엔지니어의 ‘일상 경험’과는 무관했다. 따라서 연구팀은 지표를 수정하여 이런 자동 빌드를 측정에서 제외했다.
이 사례는 중요한 점을 시사한다.
정량적 지표는 우리에게 강력한 확장성을 주지만, 그 자체만으로 맥락을 설명하지 못한다.
데이터는 ‘무엇’이 일어났는지는 보여주지만, ‘왜’ 엔지니어가 낡은 도구를 썼는지, ‘왜’ 표준 프로세스를 따르지 않았는지는 알려주지 못한다.
이 ‘왜?’에 대한 대답은 오직 정성적 연구를 통해서만 얻을 수 있다.
설문, 인터뷰 등 엔지니어에게 직접 물어보는 과정을 통해 다음에 무엇을 개선해야 할지 정확히 알려주는 열쇠가 된다.
7. 조치 취하고 결과 추적
데이터를 통해 문제의 원인까지 파악했다면, 이제 행동으로 옮길 차례이다.
연구를 마치면 ‘추천 할 일 목록’을 제공하여 개선이 지속되도록 해야 한다.
이 목록에는 아래와 같은 실질적인 제안들이 포함될 수 있다.
- 개발 도구에 새로운 기능 추가
- 도구의 지연 시간 단축
- 문서 보강
- 낡은 프로세스 제거
중요한 것은 이러한 조치를 실행한 후에, 처음에 정의했던 지표를 통해 결과를 다시 추적하는 것이다.
이 ‘측정-분석-실행-추적’의 선순환 구조를 통해 조직은 지속적으로 성장하고 발전하게 된다.
정리하며..
- 측정의 가치를 먼저 따지자.
- 결과가 어떻게 나오든 아무런 조치를 취할 수 없다면, 그 측정은 시간과 자원의 낭비일 뿐이다. 긍정적이든 부정적이든, 결과가 반드시 ‘실행 가능한 조치’로 이어질 수 있을 때만 측정해야 한다.
- GSM 프레임워크로 의미 있는 지표를 선택하자.
- 좋은 지표는 목표(Goals)까지 명확하게 추적 가능해야 한다. 이를 통해 ‘왜’ 이 지표를 보는지 항상 잊지 않을 수 있다.
- 생산성의 모든 측면을 균형 있게 다루자.
- ‘개발 속도’를 높이려다 ‘코드 품질’을 희생하는 우를 범하지 않으려면, 생산성의 다양한 요소(품질, 속도, 만족도 등)를 종합적으로 고려하여 목표를 설정해야 한다.
- 정성적 데이터를 믿어야 한다. 때로는 그것이 진실이다.
- 정량적 데이터와 정성적 데이터(설문 등)는 장기적으로 같은 방향을 가리켜야 한다. 만약 두 데이터가 서로 다른 이야기를 한다면, 그것은 잘못된 것을 정량적으로 측정하고 있을 가능성이 매우 크다는 강력한 신호이다. 숫자에만 매몰되지 말고, 엔지니어의 목소리에 귀를 기울여야 진짜 문제를 발견할 수 있다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 구글 엔지니어는 이렇게 일한다 를 읽으며 정리한 내용들입니다.
