어제 The Effective Enginner 라는 Google Talk을 아주 인상적으로 보고, 웹사이트(https://www.effectiveengineer.com)에서도 메일링 리스트 구독을 시작했다. 2주간 엔지니어 생산성에 대한 가이드 및 연습을 메일로 보내준다고 하는데, 한번 경험해보고 괜찮으면 이 웹사이트에서 제공하는 책이나 영상도 사볼까 한다.
아래는 오늘 아침에 메일로 온 첫번째 레슨 내용 요약이다. 요즘 생각하던 바와 비슷해서 공감이 많이 갔다. 그리고 금주의 하이 레버리지 작업으로 “나만의 ROI 판단 방법”을 글 하나로 정리해보기 시작했다.
레슨 1: 하이 레버리지 작업에 집중하라. (레버리지 = 소모한 시간당 얻은 임팩트)
하이 레버리지 작업의 예
- 신규입사자 멘토링하기
- 나만의 도구를 만들고 반복 작업 자동화하기
- 학습과 지속적 개선에 투자하기
- 아젠다가 불명확하거나 나를 꼭 필요로 하지 않는 미팅에 불참하기
- 인터뷰와 인터뷰 프로세스에 시간을 투자하여 좋은 사람을 채용하기
- 바퀴를 재발명하기보다는 재사용하기
연습: 다음주의 할일 목록에서, 20% 시간을 투자하여 80%의 이득을 볼 수 있는 작업이 무엇인가 생각해보라.
- 내가 ROI를 측정하는 방법, 프레임워크를 정리한다.
레슨 2: Pick the right metric to incentivize the behavior you want.
적절하게 선택된 측정 지표가 행동을 어떻게 달라지게 하는지의 예
- 주당 근무시간 vs 주당 생산성
- 전자는 더 많은 시간을 일하게 하지만 이게 더 많은 가치를 주는 걸로 이어지는 것도 아니며, 지속 가능하지 않음
- 생산성 = 집중하는 영역에 기반한 측정. 예를 들면 제품 품질, 웹사이트 속도, 유저 그로스 등
- 고쳐진 버그의 수 vs 미해결 상태인 버그의 수
- 평균 응답시간 vs 95(or 99) 퍼센타일 응답시간
- 전자는 인프라단 향상 등을 통해 모든 응답에서 몇 밀리세컨드를 줄이게 하고
- 후자는 시스템에서 최악의 경우를 찾게 함
- 유저 가입 수 vs 코호트별 주간 활성 비율
그리고 지표뿐 아니라 목표도 중요함.
연습: 내가 지금 집중하고 있는 프로젝트에서, 시간이 지남에 따라 수치가 올라가게 될 측정지표를 딱 하나만 고른다면, 어떤 측정지표가 나와 내 팀의 생산성에 가장 크고 지속 가능한 임팩트를 줄 것인가?
- 각 팀원들이 KCD의 각 파트에 얼마나 이해하고 있고 얼마나 다른 팀원을 대체할 수 있는지를 측정할 수 있다면..
레슨 3: Investing in time-saving tools.
시간은 한정되어 있다. 임팩트를 늘리는 데 시간을 더 쓰는 건 스케일하지 못한다. 반복작업을 자동화하고 생산성을 늘리는 너만의 도구를 만들어라.
CD가 대표적인 예인데, 개인 또는 팀의 이터레이션 속도를 올리는 방법은 그 외에도 많다. (→ 대부분 뻔한 얘기로군)
- 에디터나 IDE를 능숙하게 익혀서 자주 하는 작업을 편하게 하기.
- 생산적인 고수준 언어(e.g., Python, Ruby)를 익혀서 뭔가를 빨리 실험해보는 데 써라.
- 셸 커멘트에 익숙해져라.
- 마우스를 멀리하고 키보드 숏컷에 익숙해져라.
- 여러 단계의 수동 워크플로우를 자동화하는 스크립트를 짜라.
- 의존성을 줄이고, 병렬 빌드나 아웃풋 캐싱 등을 이용해 코드 빌드 속도를 줄여라.
연습: 지난 1주간 손으로 했던 작업 중, 새로운 툴을(만들거나, 기존 것을 찾아) 이용해서 그 프로세스를 좀 더 효과적으로 할 수 있는 방법이 있을까?
- 읽은 링크를 메모와 함께 워크플로이에 옮기기
- 아이폰 오토메이터 쓸 수 있지 않을까?
레슨 4: More effort DOES NOT imply more impact.
10배 더 빠르게 무언가를 완수하더라도, 80%는 잘못된 일을 했다면 효과성은 2배밖에 오르지 않은 것이다. 인스타그램이나 왓츠앱 등, 개발자 1인당 수십~수백만 유저를 감당했던 앱의 개발자들은:
- 의사결정에서 2-3배 덜 실수했다.
- 2-3배 더 임팩트를 낼 수 있는 문제들을 끊임없이 탐색했다.
- 만들고 유지보수하는 데 2-3배 적은 노력이 드는 패턴이나 해결책을 찾았다.
이 모든 것들은 곱셈이다.
레슨 5: Beware the one-person team
혼자 일하는 대신 팀으로서 효과적으로 일하면, 결과물의 품질과 사기가 훨씬 좋아진다.
Mythical Man-Month를 지나치게 맹신해서, 여러 1인 팀을 만듦으로써 커뮤니케이션 오버헤드를 없애버린다. 그러나 팀으로 일하는 것의 손해만큼이나, 혼자 일하는 것의 손해도 많다.
- 혼자 일하면 설계에 대한 피드백을 일찍, 자주 받기 어렵다.
- 팀에서는 동료와의 코드리뷰와 컨텍스트 공유로 잘못된 걸 훨씬 일찍 알아차릴 수 있다.
- 혼자 일하면 학습이 줄어든다. 위 포인트와 이유는 같고, 추가로 혼자 일하면 오래 걸리기 때문에 참여하는 프로젝트의 갯수(=다양성)가 줄어들어 학습 기회도 줄어든다.
- 팀으로 일하면 동기부여가 더 잘 된다. 동료 압력의 힘은 강력하다. 특히 당신이 존경하는 동료와 함께 있다면, 팀을 돕고자 하는 마음에서 더 힘을 내게 된다.
- 팀으로 일하면 버스 팩터가 높아진다. 누군가가 빠져도 다른 사람이 커버할 수 있고, 불분명하고 문서화되지 않은 작업들이 덜 생기게 하고, 지식과 경험이 더 잘 퍼지게 한다.
- 혼자 일하면 (작업 시간이 아닌) 총 시간이 오래 걸리고, 이게 동기를 떨어뜨린다.
- 프로젝트 모멘텀이 느려짐으로써 사기가 저하된다. 혼자 일하면 그 혼자만의 멈춤이 전체 프로젝트를 멈추기 때문.
- 혼자 일하면 저점을 찍을 때 헤쳐나오기 더 어렵고, 팀으로 일하면 고점을 찍을 때 더 기분이 좋다.
레슨 6: 엔지니어링 팀 스케일업하기
엔지니어링 팀 스케일을 위한 구글의 6가지 핵심 개발문화
- 개발 리소스를 공통 도구와 추상화에 집중한다.
- Protocol Buffers, MapReduce, BigTable
- 툴체인이 비슷하면 조직 전체의 효율이 올라감
- 신규 엔지니어 온보딩을 위한 재사용 가능한 교육 자료에 투자한다.
- 핵심 추상화, 그렇게 설계된 이유, 코드베이스의 주요 스니펫 강조, 몇 가지 구현 연습
- 코딩 컨벤션을 표준화한다.
- 코드리뷰를 통해 코드 품질을 높인다.
- 적절한 데이터를 많이 가지고 있으면 많은 (복잡한) 문제가 풀린다.
- 데이터는 유저를 이해하고, 사내 정치를 뚫고, 논쟁을 해결하고, 진척상황을 추적할 수 있게 해준다. 로딩과 데이터 인프라에 투자하라.
- 테스트를 자동화하면 코드의 스케일이 높아진다.
연습: 이 스케일링 레슨 중 하나를 당신 회사에 적용한다면? 당신이 취할 수 있는 첫번째 스텝은 무엇인가?
레슨 7: How to build a great engineering culture
- 이터레이션 속도를 최적화한다.
- 조직 측면에서는, 이터레이션 속도를 높이기 위해 엔지니어와 디자이너에게 매일매일의 의사결정에 대한 유연함과 자율성을 부여하여, 그들이 권한 요청을 할 필요 없게 만든다.
- 인프라 측면에서는, 이터레이션 속도를 높이기 위해 CI/CD, 테스트 커버리지, 빌드 속도 향상 등의 도구에 투자한다.
- 끊임없이 자동화를 추구한다.
- 코드 리뷰를 통한 고품질 코드에 집중한다.
- 코드에 대한 공통 오너십을 구축한다.
- 버스 팩터를 높일 수 있음
- 새로운 엔지니어가 신선한 인사이트를 줄 수 있고, 흥미와 동기가 유지됨
- 여러 팀 멤버가 함께 어려운 문제를 풀기 쉬움
- 학습과 지속적 성장 문화를 만든다.
질문: 현재 조직의 엔지니어링 문화를 개선하는 데 할 만한 한가지 일은 무엇인가?