[GeekNews] 개발자 생산성 측정하기: 구글, 노션 등의 실제 사례들

출처

- 원글 : Measuring Developer Productivity: Real-World Examples (pragmaticengineer.com)

- 번역 : 개발자 생산성 측정하기: 구글, 노션 등의 실제 사례들 | GeekNews (hada.io)

 

이 글은 원글과 GeekNews의 요약을 보고 개인 의견 메모를 위해 작성되었습니다.

---

요약

• 구글, 링크드인, 펠로톤, Amplitude, 인터컴, 노션, 포스트맨 등 17개 기술 회사들이 개발자 생산성을 측정하는 방법에 대한 심층 분석

1. 17개 기술 회사의 개발자 생산성 지표

• 개발자 생산성 측정은 복잡한 문제로, 지식 기반 작업인 소프트웨어 엔지니어링에서 "생산적"이라는 것의 의미 자체가 모호함
• 개발자 생산성(DevProd) 또는 개발자 경험(DevEx) 팀이라 불리는 팀들이 개발자들이 고품질 소프트웨어를 쉽게 배포할 수 있도록 지원함
• 이들 팀은 엔지니어링 팀의 생산성과 장애 요소를 측정하고, 그들의 작업이 실제로 영향을 미치는지 추적하기 위해 개발자 생산성 지표가 필요함
• 이들 회사에서 사용하는 개발자 생산성 지표
  • 딜리버리 용이성 (Amplitude, GoodRx, Intercom, Postman, Lattice)
  • 실험 속도 (Etsy)
  • 서비스/앱의 안정성 (DoorDash)
  • SPACE 지표 (Microsoft)
  • 엔지니어당 주간 집중 시간 (Uber)
• 회사 크기별로 4가지를 선정
  • Google : 직원 수 100,000명 이상
  • LinkedIn : 10,000명 이상
  • 펠로톤 : 1,000명 이상 10,000명 미만
  • 스케일업 (엔지니어 100명 이상 1,000명 미만): Notion, Postman, Intercom, Amplitude, GoodRx, Lattice

2. 구글의 접근 방식

• 구글은 개발자 생산성 측정의 모범 사례로 자주 언급되지만, 구글만큼의 투자를 모방하는 것은 대부분의 회사에게는 불가능하다는 주장도 있음
• 구글의 Developer Intelligence 팀은 개발자 생산성을 측정하고 리더들에게 통찰력을 제공하는 전문 부서임
• 구글은 단일 지표가 생산성을 포착하지 못한다고 믿으며, 속도, 용이성, 품질의 세 가지 차원을 통해 생산성을 바라봄
  • Speed 속도: 코드 검토가 완료되는 데 얼마나 걸리나요?
  • Ease 용이성: 개발자가 코드 리뷰 프로세스를 진행하는 것이 얼마나 쉽거나 어려운가요?
  • Quality 품질: 코드 리뷰를 통해 받은 피드백의 품질은 어느 정도인가요?
• 구글은 질적 및 양적 측정을 혼합하여 지표를 계산함

3. 링크드인

• 링크드인은 마이크로소프트 내에서 독립적으로 운영되며 10,000명 이상의 직원을 고용함
• 링크드인에는 개발자 생산성과 만족도를 측정하고 나머지 조직에 통찰력을 전달하는 Developer Insights 팀이 있음
• 링크드인은 분기별 설문조사, 실시간 피드백 시스템, 시스템 기반 지표를 사용하여 지표를 캡처함
  • 분기별 설문조사:
    • 개발자 인사이트 팀은 분기별 설문조사를 통해 다양한 도구, 프로세스 및 활동 전반의 개발자 경험을 평가
    • 설문조사에는 약 30개의 질문이 포함되어 있으며 개발자는 약 10분 이내에 답변 가능
    • 설문조사는 개발자 인사이트 팀이 개발하고 관리하는 독점 플랫폼을 통해 제공되며, 실시간 피드백 및 지표 시스템에서 수집한 데이터를 기반으로 설문조사 문항을 고급 사용자 지정 및 개인화할 수 있음
  • 실시간 피드백 시스템:
    • 분기별 설문조사 사이에 피드백을 수집하기 위해 LinkedIn은 개발자가 개발 도구 내에서 수행하는 이벤트와 작업을 추적하고 특정 트리거에 따라 대상 설문조사를 전송하는 실시간 피드백 시스템을 개발
    • 이 시스템은 스마트 스로틀링 메커니즘을 사용하여 개발자에게 피드백 요청이 과도하게 몰리지 않도록 함
  • 시스템 기반 지표:
    • LinkedIn은 또한 시스템 데이터를 사용하여 지표를 계산하여 빌드 시간 및 배포 빈도와 같은 항목에 대한 고정밀 측정치를 제공
    • 개발자 인사이트 팀은 이 데이터를 수집하고 분석하기 위한 글로벌 시스템을 유지 관리하며, 이를 개발자 인사이트 허브(또는 iHub)라고 부름
    • 이 시스템을 통해 LinkedIn의 모든 팀은 각자의 필요에 맞는 사용자 지정 대시보드와 메트릭을 만들 수 있음
• 링크드인은 질적 및 양적 지표를 모두 고려
  • 개발자 순 사용자 만족도(Developer Net User Satisfaction, NSAT) :개발자가 LinkedIn의 개발 시스템에 대해 전반적으로 얼마나 만족하는지를 측정. 분기별로 측정함
  • 개발자 빌드 시간(Developer Build Time, P50 및 P90): 개발자가 개발 중에 빌드가 로컬에서 완료되기를 기다리는 데 소요되는 시간을 초 단위로 측정
  • 코드 검토자 응답 시간(Code Reviewer Response Time, P50 및 P90): 코드 검토자가 작성자의 각 코드 검토 업데이트에 응답하는 데 걸리는 시간(업무 시간 기준)을 측정
  • 커밋 후 CI 속도(Post-Commit CI Speed, P50 및 P90): 각 커밋이 지속적 통합(CI) 파이프라인을 통과하는 데 걸리는 시간을 분 단위로 측정
  • CI 결정성(CI Determinism): 테스트 결함의 반대. 테스트 스위트의 결과가 오류가 아닌 유효한 결과일 가능성을 의미
  • 배포 성공률(Deployment Success Rate): 프로덕션 환경으로의 배포가 얼마나 자주 성공하는지를 측정
  • 윈저화 된 평균(Winsorized Means): 이상값 메트릭 내에서 개선 사항을 인식하는 방법. 최고값과 최저값을 가운데에 가까운 숫자로 대체하여 계산
  • 개발자 경험 지수(The Developer Experience Index): LinkedIn에서 팀에 제공하는 특별한 지표. 이 지수는 앞서 나열한 지표와 같은 여러 가지 지표를 기반으로 한 종합 점수

4. 펠로톤

• 펠로톤은 약 3,000-4,000명의 직원을 고용하는 큰 회사로, 링크드인보다 훨씬 작음
• 펠로톤의 측정 접근 방식은 개발자 경험 설문조사를 통해 질적 통찰력을 얻기 시작했으며, 나중에는 정량적 지표와 함께 사용함.
• 펠로톤은 참여도, 속도, 품질, 안정성의 네 가지 주요 영역에 초점을 맞추어 생산성을 측정함
  • 참여도(Engagement): 개발자 만족도 점수
  • 속도(Velocity): 모든 신입사원의 첫 번째 및 10번째 PR까지의 시간, 리드 타임, 배포 빈도
  • 품질(Quality): 250라인 미만 PR의 비율, 회선 커버리지, 변경 실패율
  • 안정성(Stability): 서비스 복구 시간
• 지표의 많은 부분을 측정하는 개발자 경험 설문조사는 제품 운영 조직의 일부인 Peloton의 기술 지원 및 개발자 경험 팀이 주도
• 기술 지원 및 개발자 경험 팀은 설문조사 결과를 분석하고 조직 전체의 리더와 공유하는 역할도 담당

5. 스케일업 및 소규모 회사들

• 노션, 포스트맨, 암플리튜드, 굿알엑스, 인터컴, 래티스와 같은 여러 스케일업 회사들은 100명에서 1,000명의 엔지니어를 고용함
• 이들 회사는 "이동 가능한 지표(Moveable Metrics)" 에 초점을 맞춤
  • 이동 가능한 지표는 개발자 생산성 팀이 업무에 긍정적 또는 부정적으로 영향을 미침으로써 "이동"시킬 수 있는 지표를 말함. 개발자 생산성 팀이 자신의 영향력을 보여주는 데 유용
• 공통 지표들
  • 딜리버리 용이성 (Ease of Delivery, moveable):
    • 대부분의 회사는 개발자가 작업을 수행하는 것이 얼마나 쉬운지 또는 어렵다고 느끼는지에 대한 정성적 척도인 제공 용이성을 측정
    • 여러 DevProd 리더는 팀의 목표가 개발자의 삶을 더 편하게 만드는 것이기 때문에 이 지표를 업무의 '북극성'으로 삼는다고 말함
    • 이 지표는 상당히 움직일 수 있기 때문에 영향력을 보여주는 데도 유용
    • 이론적 관점에서 볼 때 이 지표는 인지 부하 및 피드백 루프와 같은 개발자 경험의 주요 측면도 포착
  • 참여도 (Engagement)
    • 개발자가 업무에 대해 얼마나 흥미를 느끼고 자극을 받는지를 측정하는 참여도를 추적
    • 일반적으로 HR 참여도 설문조사에서 참여도를 측정하지만, DevProd 팀도 이러한 이유로 참여도에 집중하는 것을 꼽음
    • 개발자 참여도와 생산성은 밀접한 관련이 있음. 즉, "행복한 개발자가 생산적인 개발자"라는 말이 있듯이 개발자 참여도는 생산성의 지표로 볼 수 있음
    • 참여도 측정의 진정한 이점은 속도를 강조하는 다른 지표와 균형을 맞출 수 있다는 것. 소프트웨어를 더 빨리 제공하는 것은 좋지만, 개발자의 행복이 감소하는 것을 희생해서는 안 됨
  • 시간 손실 (Time Loss, moveable)
    • GoodRx와 Postman은 평균 시간 손실량에 주목함
    • 이는 작업 환경의 장애물로 인해 손실된 개발자의 시간 비율로 측정됨
    • 이 지표는 개발팀의 업무에 직접적인 영향을 미칠 수 있는 이동 가능한 지표를 제공한다는 점에서 딜리버리 용이성과 유사
    • 비용으로 환산할 수 있다는 점에서 큰 이점이 있고, 따라서 비즈니스 리더가 시간 손실을 쉽게 이해할 수 있음
    • 예를 들어 엔지니어링 인건비가 1,000만 달러인 조직에서 이니셔티브를 통해 시간 손실을 20%에서 10%로 줄인다면 이는 100만 달러의 비용 절감으로 이어짐
    • 이는 DORA(DevOps Research and Assessment) 연구 프로그램의 네 가지 주요 지표 중 하나
    • Amplitude와 Lattice를 비롯한 여러 회사에서 추적하는 최상위 지표
    • DORA 팀은 변경 실패율을 다음과 같이 정의:변경 실패율 (Change Failure Rate)
      • "프로덕션 릴리스 변경으로 인해 서비스 저하가 발생하고 이후 수정이 필요한 경우의 비율"

6. 흥미로운 발견들

• DORA 및 SPACE 지표는 선택적으로 사용되며, 모든 회사가 질적 및 양적 측정을 모두 사용함
  • DORA : DevOps Research and Assessment
  • SPACE : Satisfaction and wellbeing, Performance, Activity, Communication and collaboration, Efficiency and flow
• "집중 시간" 에 대한 큰 강조가 있으며, 스트라이프와 우버는 "충분한 집중 시간을 가진 일수"와 "엔지니어당 주간 집중 시간"과 같은 구체적인 지표를 공유함
• 독특한 지표들
  • Adoption Rate (DoorDash, GoodRx, Spotify)
  • Design Docs Generated per Engineer (Uber)
  • Experiment Velocity (Etsy)
  • Developer CSAT/NSAT (Chime, LinkedIn)

7. 자신만의 지표를 선택하는 방법

• 구글의 Goals, Signals, Metrics (GSM) 프레임워크를 사용하여 지표 선택을 안내하는 것이 좋음
• 문제를 해결하고자 하는 목표를 먼저 정의하고, 그 목표를 달성했다는 것을 알려주는 신호를 찾은 다음, 적절한 지표를 선택함
  • 목표 정의
    • Google: "개발자가 빠르고 쉽게 훌륭한 제품을 제공할 수 있도록 지원합니다."
    • Slack: "모든 엔지니어에게 원활한 개발 환경을 제공합니다."
    • Stripe: "소프트웨어 엔지니어링을 더 쉽게 만듭니다."
  • 목표로 부터 거꾸로 작업해서 최상위 지표를 정의하기
    • 개발자가 소프트웨어를 딜리버리하는 것이 얼마나 쉬운가?(Ease) : Ease of Delivery, Deployment Lead Time, Build Failure Rate
    • 개발자가 소프트웨어를 얼마나 빨리 딜리버리하는지 (Speed) : Perceived Delivery Speed, Perceived Productivity
    • 제공되는 소프트웨어의 품질 (Quality) : Incident frequency, Perceived Software Quality
• 당신이 CTO, VPE, 엔지니어링 리드라면
  • 가장 좋은 조언은 "문제를 재구성 하는 것(reframe the problem)"
  • 세가지 버킷에서 지표를 선택할 것
    • 비즈니스 임팩트
      • 지금 구축해야 하는 이유는 무엇인가요?
      • 이 프로젝트가 비즈니스에 어떤 방식으로 수익을 창출하거나 목표를 지원하는가?
      • 이 프로젝트가 순조롭게 진행되고 있나요, 아니면 지연되고 있나요?
    • 시스템 퍼포먼스
      • 엔지니어링 시스템은 빠르고 안정적인가요?
      • 인프라가 안전하고 잘 유지되고 있나요?
      • 사용자가 사용하는 서비스에 만족하고 있나요?
    • 엔지니어링 효율성
• 정성적 지표와 정량적 지표를 혼합하여 측정하는 것은 모든 회사에서 공통적으로 나타나는 현상
  • 각 기업이 사용하는 다양한 측정 항목에서 영감을 얻을 것
  • 각 기업의 우선순위와 엔지니어링 문화에 따라 중점적으로 측정하는 항목에는 큰 차이가 있음

 

---

개인 의견

나는 DevOps 관련 업무를 진행하면서 가끔 막연함과 두려움을 느낀다.

• 내가 하는 일이 정말 팀에 필요한 일인가?
• 이런 걸 한다고 정말 팀원들이 사용해줄까?
• 이 몇 초 아낀다고 이 시간을 들이는게 맞을까?

내가 하는 일이 얼마나 생산적인지 잘 모를 때가 많다.

아마 이 글과 같은 생산성 지표를 겪어보지 않아서 일지도 모른다는 생각이 들었다.

 

사람은 자유를 갈망한다.

때문에 다른 사람에 의해서 `측정` 당하는 것을 좋아하는 사람은 많지 않을 것이라고 생각한다.

하물며, 무형으로 존재하는 개발자의 생산성이라는 것을 측정하는 것은 더욱 어려운 부분이다.

 

반대로 생각해보면,

내가 하는 일이 정말 생산적인지, 얼마나 팀에 도움이 되었는지 명확하게 알 수 있을 것 같다.

다만, 글에도 나와있듯 속도와 수치로만 나타낼 수 없는 부분도 분명히 있다! (개발자의 행복이 곧 생산성!)

 

따라서, 여기 나온 모든 회사가 그러하듯

정량적 지표와 정성적 지표를 혼합하는 결론에 도달한게 아닐까 싶다.

 

내가 팀의 리더가 된다고 했을 때에는 어떤 목표와 어떤 지표를 선정해야 할까?

아직 확실하게 정의할 순 없지만, 분명한 한 가지는 알 것 같다.

이러한 지표가 필요하다는 것을 모두가 공감할 수 있도록 합치하는 작업이 분명 선행되어야 할 것이다.