GitHub의 엔지니어링 시스템 성공 플레이북

• 엔지니어링 성공을 위해서는 품질(Quality), 속도(Velocity), 개발자 만족도(Happiness) 세 영역이 조화를 이루는 것이 중요함
• ESSP(Engineering System Success Playbook) 는 이를 통합적으로 개선하여 비즈니스 성과를 극대화 하기 위한 3단계 프레임워크를 제공함
• SPACE, DevEx, DX Core 4, DORA 등 여러 프레임워크에 기반하여 설계된 12개의 핵심 지표를 통해 조직의 현황을 파악하고, 개선 목표에 따른 우선순위를 설정하며, 점진적으로 변화를 구현하고 조정
  • 이들 12개 지표는 각 영역을 정량적으로 추적할 수 있도록 구성되며, 조직마다 상황에 따라 맞춤화 가능
• 모든 개선은 팀 단위의 지속가능성과 시스템적 사고를 기반으로 하며, 선행지표와 후행지표를 함께 고려하는 균형 잡힌 접근을 강조함
• 빠른 개선 대신 지속가능한 장기적 변화를 추구
• ESSP는 자체 측정 도구 없이도 시작할 수 있으며, 설문조사 등 정성적 방법을 통한 초기 진단도 쓸모 있음
• GitHub는 자체 사례를 통해 품질 중심 개선이 궁극적으로 속도와 개발자 만족에도 긍정적 영향을 준다는 점을 강조함

GitHub의 엔지니어링 성공 메트릭들

• Quality
  • Change failure rate: 변경 실패율
    → 장애나 문제를 일으킨 변경의 비율
    • 계산법: (실패한 배포 수 / 전체 배포 수) × 100
    • 팁: 어떤 기준에서 실패로 간주할지 팀 내에서 명확히 합의할 것 (예: 롤백 여부, 모니터링 경고 등)
  • Failed deployment recovery time: 배포 실패 복구 시간
    → 실패한 배포를 되돌리거나 정상 상태로 복구하는 데 걸린 시간
    • 계산법: 각 실패 배포의 복구 완료 시점 − 실패 발생 시점의 중앙값
    • 팁: 알림 시스템이나 로그에서 자동 추출하는 방식 추천. 평균보다 중앙값 사용 권장 (극단치 영향 방지)
  • Code security and maintainability: 코드 보안성과 유지보수성
    • 계산법: 정적 분석 도구, GitHub Advanced Security, CodeQL 등을 통해 취약점 수, 복잡도, 커버리지 등 종합 평가
    • 팁: 주기적인 자동 스캔 설정. 리팩토링이나 보안 정책 변화의 효과 측정에 활용
• Velocity
  • Lead time: 리드 타임
    → 코드 변경이 프로덕션에 반영되기까지의 시간
    • 계산법: PR이 작성된 시점부터 머지 후 배포까지의 시간
    • 팁: 평균이 아닌 중앙값을 쓰는 것이 왜곡을 줄임. 리드 타임이 길 경우 PR 대기 시간 또는 리뷰 지연을 따로 측정
  • Deployment frequency: 배포 빈도
    → 얼마나 자주 프로덕션 배포가 이루어지는지
    • 계산법: 일정 기간 동안의 배포 횟수 (일/주 단위)
    • 팁: 자동화된 배포도 포함할 것인지 명확히 해야 하며, 소규모 팀은 주간 기준이 더 적절할 수 있음
  • PRs merged per developer: 개발자당 병합된 PR 수
    • 계산법: 전체 PR 병합 수 / 기여한 개발자 수
    • 팁: 비교 수단이 아니라 팀 워크플로우 효율 측정용으로 활용. PR 크기나 복잡도와 함께 해석 필요
• Developer Happiness
  • Flow state experience: 몰입 상태 경험
    • 계산법: 개발자 설문으로 “최근 몰입 경험 빈도/지속시간” 평가
    • 팁: 월 1회 이상 정기적 조사 추천. 자유 서술형 응답 포함 시 질적 통찰 확보 가능
  • Engineering tooling satisfaction: 엔지니어링 도구 만족도
    • 계산법: 개발자 설문을 통해 도구 사용의 만족도 및 개선 희망사항 수집
    • 팁: 툴 별 상세 항목(IDE, CI, 이슈 트래킹 등)으로 구분하면 실질적 개선 포인트 도출 가능
  • Copilot satisfaction: Copilot 사용 만족도
    • 계산법: Copilot 라이선스 보유자 대상 만족도 조사 (NPS 또는 점수)
    • 팁: 도입 직후와 3개월 후 등 시점별 비교 추천. 피드백을 통해 교육/활용 사례 개선 가능
• Business Outcomes
  • AI leverage: AI 활용도
    • 계산법: Copilot 커밋 비중, AI 코드 추천 채택률, 사용 시간 등
    • 팁: GitHub의 Copilot Telemetry API 또는 내부 계측 활용 가능. 정성 피드백과 함께 분석 시 더 유효
  • Engineering expenses to revenue: 엔지니어링 비용 대비 매출 비율
    • 계산법: 엔지니어링 관련 지출 / 총 매출
    • 팁: 내부 회계 기준 정비 필요. 비교를 위한 월별 또는 분기별 추세 분석 추천
  • Feature engineering expenses to total engineering expenses: 기능 개발 비용 비중
    • 계산법: (기능 개발 관련 지출 / 전체 엔지니어링 지출)
    • 팁: 유지보수, 인프라, 테스트 등 기능 외 비용 분류 기준을 사전에 명확화 해야 정확한 측정 가능

[엔지니어링 성공을 위한 3단계]

Step 1: Identify the current barriers to success

• 현재 개발 프로세스의 문제점과 엔지니어링 성공을 가로막는 장애물을 식별하는 것이 핵심
• 이는 향후 개선 방향과 우선순위를 설정하기 위한 기초선(baseline) 역할을 함
• 접근 방식
  • SDLC(Sofware Development Life Cycle) 전체 흐름을 분석하여 병목 지점을 파악
  • GitHub에서는 12개의 표준 지표를 기준으로 분석하지만, 조직 특성에 맞춰 일부만 활용 가능
• 팀 참여
  • 단일 리더가 아닌 팀 구성원 전체가 개선 프로세스를 함께 정의해야 함
  • 소수의 지표만으로 의미 있는 대화를 시작하는 것도 충분함
• 방법론

  • 1. 기본 흐름 이해

    • 전체 엔지니어링 흐름을 다음과 같이 나눠 살펴봄:
      • 계획(Plan) → 개발(Develop) → 검토(Review) → 빌드(Build) → 테스트(Test) → 릴리스(Release) → 운영(Operate)

  • 2. 정량적 신호 수집

    • 다음과 같은 정량적 데이터를 분석함:
      • 배포 주기: 얼마나 자주 배포되는가
      • 리드 타임: 코드를 작성한 시점부터 배포까지 걸리는 시간
      • 변경 실패율: 배포 후 오류가 발생하는 비율
      • MTTR (평균 복구 시간): 문제 발생 후 복구까지 걸리는 시간

  • 3. 정성적 신호 수집

    • 개발자 및 팀의 경험 기반 피드백을 수집:
      • 팀원은 언제 비효율을 느끼는가
      • 어떤 도구나 절차가 반복적으로 문제를 일으키는가
      • 어떤 활동이 가장 큰 심리적 부담을 주는가
    • 방법:
      • 설문조사, 회고, 1:1 인터뷰 등을 활용
      • 사전 정의된 ESSP 질문 목록을 사용해도 됨

  • 4. 핵심 문제 정의

    • 수집된 데이터를 통해 장벽(Barrier) 을 정의
    • 예시:
      • "리드 타임이 길어 새로운 기능 개발이 지연됨"
      • "빌드 실패가 잦아 배포 신뢰도가 낮음"
      • "개발자가 자주 맥락 전환(Context switching)을 겪음"
    • 문제는 구체적이고 관찰 가능한 형태로 진술해야 함

  • 5. 지표 우선순위 선정

    • 모든 지표를 한꺼번에 개선하기보다, 가장 큰 영향력을 가진 하나 또는 두 개의 지표에 집중
    • 이 우선순위는 향후 Step 2와 Step 3에서 개선 시도 및 성과 측정 기준이 됨
• Step 1을 성공적으로 수행하기 위한 팁
  • 1. 겉모습이 아닌 근본 원인에 집중할 것
    • 표면적 증상만 보고 판단하지 말고, 문제의 뿌리를 깊이 파고들어야 함
      • 예: 속도가 느린 이유가 '수동 테스트' 때문처럼 보이지만, 실제 원인은 자동 테스트에 대한 신뢰 부족일 수 있음
    • 이를 위해 소프트웨어 엔지니어링에서 흔히 나타나는 안티패턴(antipattern) 을 참고하는 것이 유익함
  • 2. 안티패턴 참고
    • 안티패턴이란 자주 쓰이는 해결책이지만 실제 문제를 해결하지 못하고, 오히려 부작용을 일으킬 수 있는 방식을 의미함
    • GitHub에서는 팀 내에 존재할 수 있는 안티패턴 예시를 별도 리소스로 제공하므로, 자체 검토 도구로 활용 가능
  • 3. 적절한 사람들을 참여시킬 것
    • Step 1의 Task 1 에서는 다양한 역할의 구성원들로부터 입력을 받는 것이 중요
      • 예: 개발자, 테스터, 운영, 보안, 프로덕트 매니저 등
    • 이렇게 하면 전반적인 워크플로우를 입체적으로 이해할 수 있고, 특정 관점을 놓치지 않게 됨
  • 4. 정량 데이터와 정성 데이터를 균형 있게 활용할 것
    • 메트릭(지표)만으로는 전체 맥락을 이해할 수 없음
    • 정량 분석에 더해 팀원들의 심리적, 문화적, 협업 문제에 대한 정성 피드백도 수집해야 함
    • 예: 팀 사기 저하, 커뮤니케이션 부재, 회고에서의 불만 등은 수치로는 드러나지 않음
  • 5. 장벽을 너무 많이 선정하지 말 것
    • 모든 문제를 한 번에 해결하려 하지 말고, 가장 영향력이 크고 시급한 장벽에 집중
    • 초기에 너무 많은 개선 과제를 잡으면 실행력과 모멘텀을 잃을 위험이 있음
  • 6. 심리적 안전을 확보할 것
    • 팀원들이 불이익이나 보복을 두려워하지 않고 솔직하게 의견을 말할 수 있는 환경을 조성해야 함
    • 이는 진짜 문제를 드러내는 데 핵심적인 조건이며, 개선 활동의 신뢰성과 효과를 높임
  • 7. 비교는 학습을 위한 것이지 평가가 아님
    • 팀 간 지표 비교나 워크플로우 차이는 정량적 성과 평가보다는 인사이트 도출용으로 활용해야 함
    • 팀마다 상황, 목표, 기술 스택, 제약 조건이 다르므로 단순 비교는 오해를 불러일으킬 수 있음
    • 대신, 무엇이 잘 작동하는지 공유하고 교훈을 도출하는 학습 문화를 장려해야 함

Step 2: Evaluate what needs to be done to achieve your target goal

• 목적
  • Step 1에서 정의한 핵심 문제(Barrier) 를 해결하기 위해 어떤 변화를 실행해야 하는지 분석하는 단계
  • 단순한 기능 도입이나 도구 변경을 넘어, 조직적·기술적·문화적 차원의 근본 원인과 해결책을 파악

• 1. 현재 상태의 뿌리 원인 분석

  • 단순히 "속도가 느리다", "만족도가 낮다"는 결과를 넘어서,
    • 왜 느린지,
    • 어떤 구조적·조직적 이유가 있는지,
    • 변경 가능한 것과 아닌 것을 구분해야 함
  • 사용 가능한 도구:
    • 5 Whys 기법
    • 피시본(원인-결과) 다이어그램
    • 팀 회고에서의 질적 피드백 분석

• 2. 가능한 해결책 도출

  • 문제에 대한 기술적, 문화적, 프로세스적 해결책을 브레인스토밍
  • 예시:
    • 기술적: 테스트 속도 향상, CI/CD 파이프라인 개선
    • 문화적: 코드 리뷰 관행 정비, 온보딩 개선
    • 프로세스: PR 크기 제한, 병합 기준 변경
  • GitHub의 추천 기법:
    • 관찰 기반 해결책과 사람 중심 개선안을 혼합하여 도출

• 3. 효과 및 리스크 평가

  • 각 해결책에 대해 다음 요소를 평가:
    • 기대 효과: 어떤 개선 지표에 영향을 줄 수 있는가
    • 실현 가능성: 팀 리소스와 현실적인 실행력
    • 조직적 수용성: 변화에 대한 저항 수준
    • 단기/장기 효과 구분: 빨리 결과가 나오는지, 지속적인 변화인지
  • 이를 위해 Pilot (시범 운영) 을 권장
    • 적은 팀 단위로 시험해보고 피드백 수집 후 확장 여부 결정

• 4. 우선순위 선정 및 커뮤니케이션

  • 여러 해결책 중에서 다음 기준으로 우선순위화:
    • 가장 큰 임팩트를 줄 수 있는 것
    • 가장 실행 가능한 것
    • 가장 시급한 고통 포인트를 해결하는 것
  • 이 결정은 팀원과 함께 공유하고 동의를 이끌어내야 하며,
    • OKR이나 개선 목표 형태로 명확하게 명시하는 것이 좋음
• Step 2를 성공적으로 수행하기 위한 팁
  • 1. 장기적 지속 가능성을 반드시 고려할 것
    • 단기 성과에만 집중하면 오히려 장기적 문제를 유발할 수 있음
      • 예: 새 도구 도입으로 속도를 즉시 개선할 수 있지만, 교육, 지원, 변화 관리가 수반되지 않으면 오히려 실수와 혼란을 유발
    • 따라서 어떤 개선 시도든 유지보수와 확산 가능성까지 고려한 전략이어야 함
  • 2. 각 영역(zone) 간의 트레이드오프 고려
    • 한 영역(예: 속도)을 개선하는 변화가 다른 영역(예: 개발자 만족도, 품질)을 희생시키지 않도록 주의
      • 예: 리뷰 기준 완화로 속도는 오르지만 코드 품질이나 개발자 피로도가 악화될 수 있음
    • 항상 영향 범위가 복수 영역에 걸쳐 있음을 감안하고 균형 잡힌 접근 필요
  • 3. 초기부터 팀을 참여시킬 것
    • 팀이 직접 참여하고 함께 만든 변화일수록 성공 확률이 높음
    • 변화가 상향식(bottom-up) 으로 이루어질 수 있도록 구성원 의견을 수렴
    • 일방적인 지시형(top-down) 변화는 저항과 무관심을 초래할 수 있음
  • 4. 성공 지표를 명확히 정의할 것
    • 변화 시행 전 무엇이 성공인지 합의해야 함
    • 예: “배포 시간 단축”이 목표라면,
      • 후행 지표: 실제 배포 시간 감소
      • 선행 지표: PR 대기 시간 감소, 개발자 설문에서 'PR 속도 향상 체감' 응답 증가
    • 선행지표(Leading Indicator) 와 후행지표(Lagging Indicator) 를 함께 정의하는 것이 이상적
  • 5. 완벽한 계획보다 빠른 실험을 지향할 것
    • 작은 변화라도 빠르게 시도하고 피드백 받아 개선하는 반복적 접근이 효과적
      • 초기에는 불완전한 시도라도 작은 단위로 시험하고, 효과가 입증되면 확장
    • 실패 가능성을 낮추고, 변화에 대한 팀의 민첩성과 적응력을 강화하는 데 유리
  • 6. 적은 노력으로 큰 효과를 내는 변화부터 시도할 것
    • 변화 항목이 많고 복잡할 때는, 먼저 “고효과-저비용” 영역의 개선안부터 선택
    • 예: 간단한 리뷰 가이드 도입, 불필요한 알림 제거 등은 빠르게 적용 가능하면서도 만족도에 큰 영향을 줄 수 있음
    • 초기 성공 경험은 팀에 자신감을 부여하고 더 어려운 문제로 나아갈 수 있는 동력을 제공

Step 3: Implement your changes, monitor the results, and adjust

• Step 2에서 도출한 개선 시도(Intervention) 를 실제 조직 내에 실행하고,
  그 성과를 측정하고, 필요 시 조정하거나 반복 개선함으로써 지속적인 엔지니어링 성공을 추구하는 단계

• 1. 실행(Implement the change)

  • 실행 전에 다음을 명확히 해야 함:
    • 어떤 변화가 이루어지는가?
    • 누가 책임을 질 것인가?
    • 어떤 지표를 기준으로 평가할 것인가?
    • 언제부터 언제까지 측정할 것인가?
  • 실행 시 고려사항:
    • 책임자 지정: 오너십 명확화
    • 팀 온보딩 및 교육: 변화가 왜 필요한지, 무엇이 달라지는지를 팀원 모두가 이해해야 함
    • 변화 문서화: 기록을 남겨 향후 회고 및 반복 시 참고 가능
  • 도입 예시:
    • CI/CD 속도 개선을 위한 빌드 캐시 전략 변경
    • 코드 리뷰 정책 변경 (예: 1일 내 응답 룰 도입)

• 2. 모니터링(Monitor the change)

  • 개선안 실행 이후, 사전에 정한 지표로 효과를 추적 관찰
    • 리드 타임 단축 여부
    • 실패율 감소 여부
    • 개발자 만족도 향상 여부 등
  • 도구:
    • GitHub Insights, Copilot Telemetry, 내부 BI 시스템
    • 주간/월간 리포트 대시보드
    • 개발자 설문조사 또는 회고 피드백
  • 중요한 포인트:
    • 기초선(baseline) 과 비교 가능해야 함
    • 단일 수치가 아닌 트렌드(추이) 를 보는 것이 중요함

• 3. 피드백 수집(Collect feedback)

  • 정량적 지표 외에도 개발자 관점에서 변화가 실제로 도움이 되었는지 피드백 수집 필요
    • 회고, 익명 설문, 1:1 미팅 등을 활용
    • 개선의 "체감도"가 높은지, 오히려 피로감을 주는 변화는 아닌지 확인
  • 조직적 합의 없이 성급하게 실행한 변화는 저항과 반발을 일으킬 수 있음

• 4. 조정 또는 반복(Adjust as needed)

  • 개선 시도 결과가 기대에 미치지 못하거나 부작용이 있는 경우, 다음과 같이 대응:
    • 변경을 되돌리거나 보완
    • 일부 요소만 유지하고 범위를 축소
    • 더 큰 범위로 확장 적용
  • 변화의 성공/실패와 상관없이 항상 다음을 학습해야 함:
    • 어떤 요소가 효과적이었는가?
    • 어떤 점이 방해 요인이었는가?
    • 다음에는 무엇을 바꿔야 할까?
• Step 3을 성공적으로 수행하기 위한 팁
  • 1.즉각적인 완벽을 기대하지 말 것
    • 모든 변화가 바로 눈에 띄는 개선을 만들지는 않음
      • 효과가 나타나기까지는 시간이 걸릴 수 있음
      • 팀도 변화에 적응하는 과정이 필요하므로 인내와 지속적 관찰이 중요함
    • 초기에는 설문조사 등 정성적 피드백 도구를 활용하여 변화의 체감을 파악하는 것이 유효
  • 2.변화를 계속 반복·개선할 것
    • 한번 성공했다고 그대로 유지하는 것이 아니라, 변화도 끊임없이 진화하고 조정되어야 함
    • 새로운 문제나 외부 환경 변화에 따라 기존 개선안도 다시 검토할 필요가 있음
    • 팀이 이를 정기적인 활동으로 인식하고 개선 사이클을 지속할 수 있도록 장려해야 함
  • 3.의도치 않은 부작용에 주의할 것
    • 일부 변화는 다른 영역에 예상치 못한 마찰을 유발할 수 있음
      • 예: 배포 속도 향상은 좋은 변화지만, 품질 검증이 약하면 버그 증가로 이어질 수 있음
    • 지표뿐 아니라 워크플로우 전반의 흐름 변화도 함께 살펴야 하며, 이상 징후 발생 시 즉시 조치 필요
  • 4.심리적 안전 상태를 계속 점검할 것
    • 변화 이후에도 팀이 자유롭게 문제를 제기할 수 있는 환경을 유지해야 함
    • "말하지 않는 문제"가 쌓이지 않도록, 팀원들이 솔직한 피드백을 낼 수 있는 분위기 조성 필요
    • 변화된 프로세스에 대한 불만, 과도한 업무 증가, 예상치 못한 스트레스 등
  • 5.장기적 효과를 지속적으로 평가할 것
    • 단기 성과가 아니라 지속적인 성과와 팀 사기 향상이 핵심
    • 시간이 지남에 따라:
      • 변화가 정착되었는지
      • 새로운 부작용이나 문제가 생기지 않았는지
      • 성과 유지 또는 하락이 있는지를 지속적으로 점검
  • 6.피드백을 학습 기회로 활용할 것
    • 실패한 변화도 귀중한 학습 자산
    • 무엇이 잘못되었는지 데이터와 피드백을 기반으로 분석하고, 다음 시도에 반영해야 함
    • 팀에게도 실패를 학습의 기회로 인식하도록 독려하는 문화가 중요

Beyond the steps: Make the playbook work for you

• Tailoring

  • 조직 특성에 맞게 측정 대상 지표와 방법(텔레메트리 vs 설문)을 선택함
  • 측정 자체를 목적으로 하지 말고 실질적인 개선을 위한 도구로 활용해야 함

• Change management

  • ADKAR, Kotter 모델 등 변화 관리 프레임워크를 활용하여 조직이 변화에 잘 적응하도록 돕는 것이 중요함

• Growth mindset

  • 모든 시도는 학습의 기회로 보고, 실패를 수용하는 태도가 지속적 개선에 핵심임

• Gamification

  • 동기부여 기반 보상 설계는 긍정적인 효과를 낼 수 있으나, 잘못 설계되면 오히려 품질 저하나 불균형 유발 가능

Alternatives to the GitHub Engineering System Success Playbook

• 상황에 따라 ESSP가 아닌 간단한 피쳐 사용 중심 분석이나 개별 도구 기반 개선 전략도 가능함
• 중요한 것은 팀과 조직에 맞는 현실적 접근과 지속적인 개선 노력