구글 엔지니어는 이렇게 일한다.라는 책을 읽고 가장 좋다고 느낀 것을 정리해보았다.
첫 번째, (겸손, 존중, 신뢰) 이 단어였다. 개발자 문화중 코드 리뷰에 대해서 지적이 아니라 겸손, 존중, 신뢰 3가지를 기반으로 문화를 만들었다는 것에 매우 부러웠다.
두 번째, 지속 가능성. 소프트웨어를 개발할 때 목표, 설계 등 여러 가지 요소들이 있는데 가장 중요한 것이 지속 가능성이라고 생각한다. 당연한 말이지만 버그를 수정하며 사용자가 편한 기능을 만드는 것도 중요하지만 그 외적으로 버전 관리, 빌드 시스템 등 개발자들도 편하게 일할 수 있는 개발환경 요소도 중요하다. 개발자가 쉽게 다가갈 수 있어야 소프트웨어의 기대 수명과 지속 가능성이 연장된다고 생각된다.
세 번째, 포스트 모템 문화. 가장 좋다고 생각 들었다. 실패를 해도 비난하지 않으며 실수한 사람 또는 문제의 책임자에게 비난의 화살을 두지 앉는다. 만약 비난이 시작되면 그 조직은 점점 책임을 회피하기 위해 정보를 각 팀(혹은 각 개인)의 입장에서만 해석하게 된다. 이렇게 되면 진정한 원인 분석을 통한 다음 사고 예방을 한다던지 시스템을 팀 차원에서 개선하는 것이 어려워질 수 있다.
개발적인 요소 외에도 직원들에게 하여금 동기 부여를 할 수 있는 여러 요소들이 많다는 것을 알 수 있었다. 아래는 각 파트에서 중요하다고 생각하는 부분을 조금 정리해 보았다.
소프트웨어는 지속 가능성이 핵심이다. 하이림의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 리뷰가 뒷받침되더라도 공표한 계약(명세)나 모범사례로 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현한 말이다. 이에 따라 엔지니어는 시간에 따라 대처해야 한다.
규모 확장과 효율성 소프트웨어 조직에서 가장 중요한 자산인 코드 베이스 자체도 확장 가능해야 한다. 코드가 많아지고 변경 이력이 쌓이는 등의 이유로 빌드 시스템이나 버전 관리 시스템이 점점 느려진다면 어느 순간 더는 정상 운영할 수 없는 시점이 온다.
끓는 물속의 개구리처럼 서서히, 위험이 현실이 되는 순간까지 단 한 번도 눈치 채지 못할 수 있다.(깨진 유리창의 법칙)
구글의 소프트웨어 엔지니어링이라는 책을 읽다 보면 비욘세 규칙이라는 말이 나온다. 비욘세의 노래 Single ladies 중 가사 Cause if you liked it, then you shoulda put a ring on it (네가 나를 좋았했다면 프러포즈를 해줬어야지)라는 내용에서 기인한 규칙이다. 이걸 테스트 코드 작성과 연결해서 생각한다고 합니다. 구글에서 말하는 비욘세 규칙은 "필요했으면 테스트했었어야지" 정도로 의역할 수 있다.
코드의 기대 수명 동안 의존성, 기술, 제품, 요구사항 변경에 대응할 역량이 갖춰져야 지속 가능한 소프트웨어라고 할 수 있다. 코드는 흔희 간헐적 버그들의 집합이라고 말할 수 있다.
비난 없는 포스트모템 문화 정착하여 실패할 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심이다. 짝 프로그래밍 문제로 스타일 다른 개발자들은 오히려 의견 충돌이 나올 수가 있다. 이런 경우를 대비해야 한다.
버그를 각자 확인하고 사실 기반으로 토론하며 결점을 드러내는 것은 겸손을 겉으로 표현하는 일이며 책임을 지고 의무를 다하려는 의지를 표출하는 것이다. 한 명의 소프트웨어 개발자가 이룬 천재 신화가 여전히 만연하지만 그 누구도 홀로 이뤄내지 않았다는 것이 진실이다.
구글에서는 지식 공유를 배움의 문화로 표현한다. 배움에는 무언가를 실패해도 안전하다는 것을 강조한다. 이 말이 어려울 수 있는데 결국 새로운 도전을 하고 이를 공유하기 위해서는 심리적인 안정이 필요하다. 심리적 안정은 지식 공유 환경을 조성하기 위한 토대이며 팀의 리더는 새로운 멤버든 항상 무언가 배울 게 있는 환경에서 살아야 한다. 그렇지 않으면 더 이상 성장하지 못할 것이다.
리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고 팀워크와 협업 문화를 조성하며 긴장 해소와 팀의 가치를 만들 수 있어야 한다. 팀원들의 사기를 위해 보상과 인정을 위해 다양한 성과 인정제도 마련한다.
구글은 메일링 리스트에 모든 직원이 질문을 할 수 있는 그룹을 만들어 넣고 누구든 가입을 하고 메일을 보낼 수 있는 시스템을 구축하였다. 다만 불필요한 정보가 생길 수 있다는 단점이 있다. 구글은 YARS라는 질의응답 플랫폼을 사용하여 우리가 자주 사용하는 스택오버플로우와 같은 서비스를 직원들에게 제공한다.
또 한 눈이 많아야 버그가 줄어든다고 한다. 이는 협업의 중요성을 뜻하며 혼자 일하지 않기, 숨기지 않기, 자존심 버리기 등 소통을 중요시한다.
공정 사회를 위한 엔지니어링으로 제품 설계와 구현에 다양한 관점을 있다. 사람마다 가치관이 다르며 크게 본다면 나라마다 다양성과 편견이 있을 수 있다. 또한 오래된 관례를 깨기가 어렵다는 것을 인정함에서 그 시작이 있다
자신을 솔직하게 바라보고 성찰하자, 모두를 위한 제품을 만든다. 모두를 위해 만들지 말자. 모두와 함께 만들자
포용성은 모든 직원을 차별 없이 지원하는 근무 환경을 조성하는 데에도 아주 중요하다. 구글은 엔지니어링을 아는 사람만이 소프트웨어 엔지니어링 관리자가 될 수 있도록 한다. 전통적인 관리자는 일을 어떻게(How) 처리할지를 고민하지만 훌륭한 관리자는 무슨(What) 일을 처리할지를 고민한다. 팀원들이 안전하다고 느끼게 해주는 일이 팀을 촉진하는 좋은 방법이라고 안내한다.
하지만 현실에서는 대부분의 기업들이 작은 성공에 집중하는 보수적인 전략을 선택한다. 구글은 이러한 문화를 바꾸기 위해 팀이 위험을 감수하는 문화를 조성하는 멋진 방법으로 실패해도 괜찮음을 알게 하는 방법을 제시했다. 직원들에게 하여금 실패해도 괜찮다. 오히려 실패는 많은 것을 아주 빠르게 배울 수 있는 기회로 보게 한다.
성공에 기여한 개인을 축하해주는 것은 좋지만 반대로 실패 시 비난할 누군가를 찾으려면 안된다. 도전하는 문화에 찬물을 끼얹는 조치다.
안티 패턴 | 올바른 패턴 |
만만한사람 고용하기 저상과자 방치하기 사람 문제 무시하기 만인의 친구 되기(리딩과 우정은 다르다.) 팀을 어린이처럼 대하기 |
자존심버리기 마음 다스리기 촉매자 되기 장애물 치우기 선생이자 멘토되기 명확한 목표 세우기 정직하기 행복한지 확인하기 |
구글에서는 팀 리더 및 직원들에게 늘 결정하고, 늘 떠나고, 늘 확장하고 한다.
늘 결정하라. 필자도 업무를 진행하면서 의사결정이 명확하지 않아 고민이 많았다. 그리고 결정에는 책임이 따르기 때문에쉽게 생각하고 진행하면 안된다.
늘 떠나라. 자신의 업무가 최고 수준에 도달했을 때 현재 위치에만 머물지 말고 새로운 도전을 하라는 의미로 받아들였다.
늘 확장하라. 늘 떠나라랑 비슷하다고 느꼈는데 코드를 예를 들면은 언제나 확장 용이 가능하도록 설계하라는 의미로 받아 들였다.
일관성이 핵심이고 규칙은 최소화하며 가능한 규칙들이 자동으로 적용되도록 해야 한다. 새로운 것을 도입하는 것도 중요하나, 초기에 나온 방법은 실제 엔지니어들도 익숙하지 않아 오히려 안전하지 않을 수 있다. 시간이 지나고 엔지니어들이 익숙해질 때까지의 시간이 필요하다. 그리고 기존 방법에 익숙한 직원들의 교육 비용이 있다는 것을 명심하자.
프로그래밍 자체도 사람이 하는 것임으로 실수가 있을 수 있다는 것을 가정한다. 구글에서는 코드는 부채라고 말하며 공손하고 전문가답게 지식을 공유 하는 것을 지향 한다. 일반적으로 코드 리뷰에서 실수를 지적한다는 것을 느낄 수도 있는 데 자발적인 문화로 만들기 위해서 코드 리뷰의 역할, 정확성, 이해 용이성, 일관성 보장 등 여러 원칙을 사용한다. 개인적으로도 리뷰는 이점이 많다고 생각한다.
코드 리뷰는 단기가 아닌 장기적인 관점으로 엔지니어의 전문성을 향상하며 소프트웨어의 지속성을 연장하는 관점에서 장기적인 비용을 절약할 수 있다.
문서자료는 시간이 흐르고 조직 규모가 커질수록 더 중요하다. 문서자료 변경도 기존 개발자 워크플로처럼 하나의 문서는 하나의 목적에 집중해야 하며, 문서는 자신 보다는 독자를 위해 작성 해야 한다.
"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."
핸즈온 데이터 시각화 (0) | 2022.07.17 |
---|---|
AWS로 시작하는 인프라 구축의 정석 - 제이펍 (0) | 2022.07.15 |
머신러닝 실무 프로젝트 2판 - 한빛미디어 (0) | 2022.04.26 |
딥러닝 파이토치 교과서 (0) | 2022.04.06 |
프로그래머의 뇌 - 제이펍 (0) | 2022.04.03 |
댓글 영역