[구글 엔지니어는 이렇게 일한다더라] 1부, 문화

한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다...만
진심이 담겨있습니다. 허위 사실 유포는 😎일절 없음.

 

 

 

"구글 엔지니어는 이렇게 일한다."이 내 주변에서 조금 핫하다. 이 책을 모르는 개발자가 드물었다. 아마 제목이 큰 역할을 한게 아닐까 싶기는 하다. 어그로는 아니지만 "구글 엔지니어"라는 단어가 딱 들어가니깐 이직이나 성장에 목마른 사람들에게 자극적이었을 것이다. 나 역시도 그러했기에 이 책을 이번주까지 다 읽으려고 했었다. 맥락으로 느꼈을 것이다. 나 역시도 타이슨에게 한대 맞았다.

 

 

계획대로 되지 않았다. 본 글에서 변명이 중요한건 아니지만 그럼에도 변명 하나를 꺼내보자면... 이번 책은 꼭꼭 씹어 먹었다. 다른 포스팅에 "함께 자라기"라는 서적을 언급하면서 내 취향이 아니라고 한 적이 있다. 개발자의 조직과 성장과 관련된 서적은 정말 많지만 내 입맛에 맞는 것을 찾기는 쉽지 않다. "구글 엔지니어는 이렇게 일한다."는 내 입맛에 딱이었다. 그렇다보니 평소보다 한장의 무게감이 더 묵직했다.

 

이렇게 된 이상 이번 리뷰는 좀 디테일하게 해보기로 했다. 책 제목을 약간 비틀어서 "구글 엔지니어는 이렇게 일한다더라"라는 이름으로 3회의 포스팅을 할 예정이다. 크게 3개의 파트로 나누어진 이 책을 꼭꼭 씹어먹고 소화한 내용을 공유해본다.

 

이 드립을 생략하기에 너무 아쉽다

 

전제. 소프트웨어 엔지니어링이란 (Chapter.1)

이 책은 소프트웨어 엔지니어링을 소개하는 전제 파트와 전제 파트에서 상세하게 다룰 내용을 소개하는 3개의 파트로 구성된다. 소프트웨어 엔지니어링이란 무엇일까? "흐르는 시간 위에서 순간순간의 프로그래밍을 합산한 것"이라고 저자는 설명하는데 쉽게 와닿지 않는다. 프로그래밍과의 차이를 통해 대략적인 정의를 확인할 수 있다.

 

프로그래밍 작업 : 개발
소프트웨어 엔지니어링 작업 : 개발 + 수정 + 유지보수

 

이 차이를 저자는 지속 가능성에 두었다. 지속이라는 키워드에서 봤듯이 소프트웨어 엔지니어링에는 시간 개념을 염두해야 한다. 하이럼의 법칙을 통해 얼마나 심각해질 수 있는지 알 수 있다. 

 

API에 충분한 수의 유저가 있다면, 명세에서 지정된 것은 아무런 상관이 없다.
시스템에서 관측될 수 있는 모든 행동 양식은 다른 이들에게 달려있을 것이다.
- Hyrum's Law

 

API는 시간이 흐를수록 사용자가 늘어나고 사용자는 API의 의도나 명세와 관계없는 형태로 활용할 가능성이 올라간다. 그렇게 된다면 개발자는 API를 수정하기가 어려워진다.(낮은 지속가능성) 높은 지속가능성을 유지하기 위해서는 소프트웨어 엔지니어링적인 시각으로 작업이 되어야 한다. 이 때 중요한 것이 문화, 프로세스, 도구다.

 

 

 

문화. 팀워크와 지식공유 (Chapter.2~3)

저자가 문화 파트에서 첫번째로 강조한 것은 "숨기지 말 것"이다. 조직의 모든 사람이 천재가 아니기에 본인의 역량이 그대로 드러나는 코드가 부끄러울 수 있다. 하지만 이를 숨긴다면 조기 감지와 장애, 속도면에서 해롭다고 언급한다. 특히 버스 지수에 대해 설명한게 인상적이다. 버스 지수는 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수다. 예전에 어느 대기업은 이런 경우를 차단하기 위해 핵심 인물들이 대량 이동할 때 의도적으로 비행기 2대 이상 나누어서 이동한다고 들었던 적이 있다. 여기서는 특정 인물에게 중요한 작업이 집중되어 있는지 조직원들에게 잘 분산되어 있는지를 언급하기 위해 버스 지수를 설명하고 있다.

 

이런 팀워크를 마들기 위해서 다음 3가지를 강조하고 있다.

 

1. 겸손 humility
2. 존중 respect
3. 신뢰 trust

 

 

저자는 단순히 조직 내부 뿐 아니라 거의 모든 사회적 갈등의 근본 원인이 여기에 있다고 얘기한다. 그러면서 어떻게 실천할 수 있는지 방법을 제시하고 있다. 비평하고 비평받는 법 배우기, 빠르게 실패하고 반복하기, 포스트모템 문화 등. 그 중 가장 중요해 보이는 실천 방법은 "자존짐 버리기"가 아닐까 싶다. 앞에서 "숨기지 말 것"이 나온 이유도 이 자존심 때문이 아닐까. 그렇다고 이 책에서 바짝 엎드리라고 하지는 않는다. 생산성을 떨어뜨리는 자존심보다는 팀의 성취와 단체의 자부심을 높이길 권하고 있다.

 

팀워크는 단순히 업무에서만 작용하지 않는다. 배움의 문화를 통해서도 팀워크는 강화된다. 배움을 가로막는 장애물(심리적 안전 부족, 정보 섬 등)이 있다면 이를 극복해서라도 지식 공유는 필요하다. 그럴려면 앞에서 얘기한 장애물을 치워야 한다. 심리적 안전은 숨기는 것을 줄여줄 것이다. 멘토를 두어도 좋고 구성원 그룹 단위로 쉽게 도움을 청할 수 있는 분위기를 형성하는 방법도 있을 것이다.

 

 

찾아보니 이런 자료도 있었다. 가장 하단 참고 링크 클릭

 

 

지식은 스터디, 컨퍼런스를 통해서만 전달되는 것은 아니다. 가장 기본이 되는 것은 질문이다. 어떻게 질문을 하고 맥락을 이해하고 대답을 해주느냐에 따라 지식의 폭이 넓어질 수도 좁아질 수도 있다. 물론 지식을 확장하는 방법에는 여러가지가 있다. 오피스 아워, 기술 강연과 수업, 문서자료 등. 특히 스타트업에 종사하는 분들에게는 이 문서자료를 갱신하고 새로 작성하는데 소홀할 수 있다. 하지만 문서가 때론 사람을 통할 때보다 더 효율적일 때도 있다. 문서에 관한 내용은 2부에서도 다루도록 하겠다.

 

구글에서는 조직의 지식을 확장하기 위해 많은 노력을 했다. 지식 공유 문화를 자리잡도록 했고 표준 정보 소스라고 해서 전문가의 지식을 표준화하고 전파하는 수단을 만들기도 했다. 누구도 소외되지 않게 하기 위해 뉴스레터나 커뮤니티를 활용하는 방법도 제시한다. 가독성 제도라는 것도 소개한다. 내용을 보면 코드리뷰보다 10배는 더 귀찮을 것같은 제도이다. 프로그래밍 언어 모범사례를 전파하기 위한 구글 전사 차원의 '표준 멘토링 프로세스'라고 한다. 표준화와 개인화가 융합된 방식의 지식 확장 수단으로 문서화된 지식과 현장 시직을 보완하는 매력적인 방식이다. 저자는 이런 방식이 본인이 다니는 조직에도 어울리는지를 먼저 파악하라고 말한다. 뭐, 당연하다. 인력 여유가 되지 않는다면 엄두도 내기 힘든 방법이니깐. 하지만 기억해두었다가 언젠가 이런 방법을 건의해도 좋지 않을까 싶다.

 

 

 

문화. 공정사회를 위한 엔지니어링 (Chapter.4)

문화파트에서 가장 인상적인 챕터다. 아무리 구글이라도 차별 이슈에서 자유롭지 못했다. 하지만 스스로 이를 인정하고 인지하며 반성하고 개선하려는 노력을 했다. 이 책을 읽은 독자 입장에서 구글이 모든 차원에서 옳은 결정을 했다고 생각하지 않는다. 하지만 이런 내부 반성의 모습은 부럽다. 이 챕터에서는 다양성이 왜 필요하고 어떻게 갖출 수 있는지 다루고 있다. 그들은 이 부분에 대해 이토록 고민하고 지금도 연구하고 있음을 엿볼 수 있다.

 

가장 짧은 챕터 중 하나다. 그렇지만 불공정이 얼마나 위험한지 강하게 설명한다. 단순히 일만 잘하는 개발자보다 가치있는 엔지니어링이 무엇인지 고민하는 개발자가 더 가치있음을 알려준다. "관심을 잃지 말고 전진하자". 이 챕터의 핵심 문장이 아닐까.

 

구글이 발간한 2021년도 다양성 보고서에 조직 구성원의 성비 및 인종 비율에 대한 통계가 담겼다.(구글 다양성 보고서 갈무리) &copy; 뉴스1

 

 

 

 

 

문화. 팀 그리고 성장하는 조직 이끌기 (Chapter.5~6)

나는 관리자도 리더도 아니다. 하지만 언젠가는 이 둘 중 하나는 될 것이다. 그럼 어떤 역할이 어울릴지 생각해보는 것도 나쁘지 않다. 여기서는 엔지니어링 관리자, 테크 리드, 테크 리드 매니저를 소개하고 있다. 어떤 역할을 맡게 되든 관리를 하는 입장이 되는 것에 거부감만 느끼지말고 맡은 역할과 그 주변을 두려워하며 맡겨진 입장에서는 섬기는 리더십을 가질 필요가 있다.

 

엔지니어링 관리자는 과거의 단순한 노동을 관리하는 역할이 아니다. 안티 패턴으로 본인 행동 양식을 경계하며 올바른 패턴으로 구성원의 촉매제 역할이 되어야 한다. 안티 패턴으로는 만만한 사람 고용, 저성과자 방치, 사람 문제 무시 등이 있다. "희망은 전략이 아니다."라는 말을 빌려 저성과자나 사람 문제를 희망적으로만 바라보다간 오히려 고효율 인력을 낭비하는 상황으로 만들 수 있다. 그럼 올바른 패턴은 무엇일까. 자존심을 버리고, 본인의 마음을 다스릴줄 알며, 조직원의 장애물이 되는 것을 치우고, 때론 선생이나 멘토가 될 수 있으면 훌륭한 엔지니어링 관리자라고 할 수 있다. 물론 기술 부분을 책임지는 테크 리드도 동일하게 적용된다.

 

그럼 성장하는 조직을 이끌려면 어떻게 해야할까? 저자는 3A 리더십을 언급했다.

1. 늘 결정하라 Always Be Deciding
2. 늘 떠나라 Always Be Leaving
3. 늘 확장하라 Always Be Scaling

 

리더는 선택의 연속이다. 눈가리개가 되는 것을 찾고 핵심 트레이드오프를 파악하고 결정하고, 이를 반복해야 한다. 이로서 작업의 사이클이 돌아간다. 작업 사이클이 더 원활하게 돌아가려면 자율주행팀이 되어야 한다. 버스 지수에서 얘기한 것처럼 리더가 부재하다고 해서 업무가 마비되면 안된다. 그래서 리더의 역할을 위임하는 능력도 필요하다. 여기서 위임에 대한 얘기가 자주 나오는데 그만큼 혼자서 해결하기보다 팀에서 같이 해결하는 것이 더 효율적임을 강조하는 것이다. 마지막으로, 작업의 확장은 피할 수 없기에 무엇이 중요한지 이해하고 구성원의 시간과 에너지를 잘 관리해야 한다.

 

 

문화. 엔지니어링 생산성 측정하기 (Chapter.7)

어디든 엔지니어 조직의 생산성을 측정하고 싶어할 것이다. 하지만 쉽지 않다. 단순히 코드 라인 갯수로 파악할 수 있는게 아니기 때문이다. 이런 방식은 부작용이 더 크다. 쓰레기 코드만 늘어날 수 있기 때문이다. 그렇다면 생산성 측정은 어떻게 진행하는게 좋을까?

 

먼저 측정하려는 대상이 정말 가치있는 대상인지 확인을 해야한다. 어떤 결과를 기대하고 결과에 따라 행동이 바뀌는지 등을 체크하여 가치있다고 판단했을 때 생산성 측정을 위한 목표를 설정한다. 구글 사례로 GSM 프레임워크를 소개했다. Goal(목표), Signal(신호), Metric(지표). 목표는 원하는 속성을 설명해야지 어떠한 지표도 명시되면 안된다. 신호에서는 목표 달성 여부를 알 수 있는 방법이 나와야 한다. 그리고 지표에서 정성적, 정략적 측정으로 검증을 진행한다. GSM 프레임워크는 어디까지나 구글에서 사용한 방식이다. 충분히 표준적인 형태로 소개하여 다른 조직에서도 사용가능하겠지만 충분히 사전 검토를 하고 적용을 해야겠다. 물론 목표 결과까지 나온 뒤 결과를 추적하여 정말 가치있는 엔지니어링 생산성 측정이였는지도 잊지말고 해야한다.

 

HEART Framework라는 이름으로 발전한 모양이다

 

 

 

---

 

이렇게 문화적인 측면에서 구글이 일하는 방식을 확인해 보았다. 2부에서는 프로그래밍 스타일 가이드, 코드리뷰, 테스트가 포함된 프로세스에 대해 소개해보겠다.

 

 

구글 엔지니어는 이렇게 일한다 - YES24

 

참고 링크
- 업무 수행 기준과 심리적 안점감과 관련한 이미지
- 하이럼의 법칙 (암시적 인터페이스의 법칙)

 

📕