구글 엔지니어는 이렇게 일한다(타이터스 윈터스, 톰 맨쉬렉, 하이럼 라이트) - 06
공감되거나 인상 깊었던 문장들은 다음과 같다.
- ‘항상 배우고 항상 질문하라!’ (P.98)
- 초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것이다. 혼자서 극복해내고 싶다거나 ‘너무 기초적인’ 질문이란 소리를 듣는 게 두려워서일 수 있다. 혹은 ‘도움을 청하기 전에 최대한 노력해봐야 해’라고 생각할지 모른다. 이 함정에 빠지지 말라. 동료가 가장 훌륭한 정보 소스일 경우가 많다. 귀중한 자원을 충분히 활용해라. (P.98)
- 인간이라면 언제나 아는 것보다 배워야 할 것이 많다. (P.98)
- 팀의 리더든 새로운 멤버든 항상 무언가 배울 게 있는 환경에서 살아야 한다. 그렇지 않으면 더 이상 성장하지 못할 것이다. 그리고 새로운 환경을 찾아 떠나게 된다. (P.98)
- 새로운 것을 이해하는 일 뿐 아니라 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함된다. (P.99)
- ‘무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자’라고 말하는 체스터슨의 울타리(chesterson’s fense) 원칙을 떠올려라. (P.100)
- 엔지니어들은 너무 성급하게 ‘이건 잘못됐어’라고 결론 짓는 경향이 있다. 생소한 코드, 언어, 패러다임을 접했을 때는 더욱 심하다. (P.100)
- 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해야 한다. 우선 코드의 목적과 맥락을 이해하고, 그런 다음 변경하려는 방향이 여전히 더 나은지 고민해야 한다. 더 낫다고 판단되면 고치고, 그렇지 않다면 미래에 다시 그 코드를 살펴볼 후임들을 위해 근거를 남겨라. (P.100)
- 일대일 도움은 밀도가 높지만 확장하는 데는 필연적으로 한계가 있다. 배우는 쪽에서도 상세 내용을 모두 다 기억하기란 쉽지 않다. 미래의 자신을 위해서라도 무언가를 일대일로 배울 때는 ‘기록하는 습관’을 길러라. (P.101)
- 가르친다는 건 전문가의 전유물이 아니며, 전문성이라는 게 ‘초심자 아니면 전문가’처럼 이분법적으로 나눠지지도 않는다. 전문성은 다차원 벡터다. 누구나 영역별로 다양한 수준의 전문성을 갖추고 있다. 조직이 성공하려면 다양성을 반드시 갖춰야 하는 이유가 여기 있다. (P.104)
- 엔지니어들에게 각자가 한 일을 문서화하도록 장려하기가 쉽지 않다. 문서 자료를 작성하려면 시간과 노력이 드는데, 코딩할 시간에서 뺏어와야 하기 때문이다. 문서화한 효과가 바로 나타나지도 않고 그마저도 대부분 자신이 아닌 다른 사람들에게도 돌아간다. 문서화는 소수가 시간을 들여 다수에게 이득을 주므로 조직 전체에 도움을 주지만, 기본적으로 기여자와 수혜자가 달라서 적절한 보상 없이는 사람들을 움직이게 하기 어렵다. (P.107)
- 지식을 공유할 때는 상냥함과 존중을 담아야 하고, 또 그래야만 가능하다. 기술 업계에서는 ‘뛰어난 괴짜’를 용인하는 (심지어 숭배하는) 경향이 있지만, 해로운 현상이다. 상냥한 전문가도 얼마든지 가능하다. (P.109)
- 높은 수준의 기술 리더십을 요구하지만, 모든 리더십이 기술 문제와 관련된 것은 아니다. 리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 구글 문화의 가치를 설정하며, 구글을 더 활기차고 신나는 일터로 가꿔야 한다. 괴짜는 좋은 리더가 아니다. (P.109)
조직 내 지식이 공유되기 위해선 질문할 수 있는 용기, 겸손함 그리고 친절함이 필요하다. 우리 회사에서도 강조하는 코어 밸류와 같다. 조직이 크든 작든 결국 사람이 하는 일이다 보니 중요하게 여기는 것은 같을 수밖에 없는 것 같다.
이번에 읽은 내용 중 ‘무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자’라는 글이 크게 공감됐다. 내 경험상 애플리케이션의 크기와 관계없이 이를 지키지 못해서 문제가 발생하는 경우가 많았다. 충분히 이해하지 못한 변경은 테스트 코드를 통해 방지할 수 있다. 코드도 지식을 표현하는 방법이다. 테스트 코드들을 통해 어째서 이 코드가 필요한지 컨텍스트를 남길 수 있다. 하지만 충분하지 못한 테스트 커버리지나 테스트마저 잘못되었다며 코드를 읽을 생각 없이 지워버리는 누군가도 있었기 때문에 완벽히 막을 수 있는 문제는 아니다. 함께 일하는 팀원의 성향에 따라 발생 여부가 결정되는 것 같다. 잘못된 변경으로 문제를 일으켰다면 이에 대한 적절한 피드백을 해야 한다.
나는 누군가 작성한 코드를 변경할 때 의존 관계가 있는 코드, 커밋 히스토리, 팀원들로부터 관련된 컨텍스트를 최대한 파악한 후 작업을 시작한다. 그럼에도 문제가 발생한다. 충분한 커버리지의 테스트 코드를 통해 해당 코드가 필요한 컨텍스트를 남기고, 페어 프로그래밍, 코드 리뷰 혹은 문서 정리를 통해 지식을 다른 팀원들에게 전파하는 것이 중요하다는 생각이 들었다.
댓글남기기