[개발 서적] 구글 개발자는 이렇게 일한다 - 3편 리더십과 생산성

본 글은 구글 엔지니어는 이렇게 일한다에서 각 파트별 요약 정리를 위한 내용을 담고 있습니다.

No	주제	책 해당 목차	주요 주제 요약
1편	소프트웨어 엔지니어링	1장	소프트웨어 엔지니어링의 정의, 지속 가능성, 하이럼의 법칙
2편	구글의 협업 문화와 팀워크	2장 ~ 4장	팀워크, 지식 공유, 공정성(다양성과 포용성)
3편	리더십과 생산성	5장 ~ 7장	기술 리더십, 성장하는 조직, 생산성 측정 철학
4편	품질을 위한 개발 프로세스	8장 ~ 11장	스타일 가이드, 코드 리뷰, 문서화, 테스트 개요
5편	테스트와 기술 부채 관리	12장 ~ 15장	테스트 심화 (단위, 통합, 대역), 기술 부채 및 폐기 전략
6편	개발 인프라와 도구: 구글의 자동화 시스템	16장 ~ 25장	빌드 시스템, CI/CD, 정적 분석, 의존성, 리뷰 도구 등 개발 인프라 전반

---

3편. 리더십과 생산성 – 구글은 어떻게 기술 리더를 키우는가

시작하며

기술이 아무리 뛰어나도, 그 기술을 어디로 끌고 갈 것인지를 결정하지 못하면 조직은 방향을 잃습니다.

『구글 엔지니어는 이렇게 일한다』의 5~7장에서는 기술 리더는 무엇을 해야 하고, 좋은 조직은 어떻게 성장하며,
생산성을 어떻게 바라봐야 하는가에 대해 구체적으로 이야기합니다.

개인의 능력보다 팀 전체가 얼마나 건강하게 일할 수 있는가가 구글이 말하는 기술 리더십의 핵심입니다.

---

Tech Lead의 역할은 ‘히어로’가 아니다

많은 조직에서 실력 좋은 개발자가 팀장을 맡곤 합니다.
하지만 구글은 이렇게 말합니다:

“리더는 문제를 혼자 해결하는 사람이 아니라,
문제를 해결할 수 있는 팀을 만드는 사람이다.”

구글의 리더십 구조: TLM (Tech Lead Manager)

• 기술 판단을 내리는 리더(Tech Lead)와 사람을 관리하는 리더(Manager)가 역할을 나누되, 긴밀하게 협력합니다.

즉, 코드를 가장 잘 짜는 사람이 아니라, 팀이 문제를 해결할 수 있도록 환경을 만드는 사람이 진짜 리더입니다.

 

 

성장하는 조직에는 시스템이 있다

소규모 스타트업과 대기업의 차이는 “일이 돌아가는 시스템”입니다.

구글은 다음과 같은 시스템을 통해 조직의 학습과 확장을 구조화합니다.

• 설계 리뷰, 코드 리뷰, 기술 문서, 아키텍처 위원회 등을 통해
  단순한 코드 수준이 아닌, 설계와 기술 방향성까지 팀이 함께 공유합니다.
• 팀이 커질수록 ‘말 안 해도 알겠지’는 통하지 않습니다.
  구글은 명확한 기준, 공통 언어, 자동화된 피드백 루프를 통해 혼란을 줄입니다.

 

 

생산성은 양이 아니다

많은 기업이 개발자 생산성을 측정하려고 합니다.
줄 단위 LOC? 기능 개수? 커밋 횟수?

하지만 구글은 전혀 다른 관점을 제시합니다:

“생산성은 개발자가 더 잘 일할 수 있는 환경이 갖춰졌는가의 문제다.”

구글이 말하는 생산성을 위한 환경은 다음과 같습니다:

• 코드 리뷰가 빠르게 돌아가고 있는가?
• 빌드/배포가 기다릴 만한 시간 안에 끝나는가?
• 문서가 부족해서 헤매는 일이 없는가?

즉, 생산성을 높인다는 것은 속도를 강요하는 게 아니라,
속도를 방해하는 요소를 제거하는 것입니다.

---

요약 정리

항목설명

기술 리더십	혼자 해결하는 사람이 아니라, 문제를 해결할 수 있는 팀을 만드는 사람
성장하는 조직	공통 기준과 공유된 시스템, 기술적 커뮤니케이션 체계가 갖춰진 팀
생산성 철학	양보다 환경, 속도보다 지속 가능성. 방해 요소 제거가 핵심

 

 

마무리

당신이 팀장이라면, 지금 팀원에게 코드 대신 방향을 주고 있는가?
당신이 팀원이라면, 지금 이 시스템 안에서 성장하고 있다고 느끼는가?

‘좋은 사람’을 뽑는 것도 중요하지만,
그 사람이 제대로 일할 수 있게 만드는 구조가 없다면
결국 실력도, 성과도 오래가지 못합니다.

기술 리더는 잘 짜인 코드보다 잘 짜인 팀을 먼저 만든다는 걸 잊지 않아야 합니다.