구글 엔지니어는 이렇게 일한다
개요
회사 동료분께 추천받아 읽게 된 책이에요. 생각보다 너무나 많은 양질의 내용들이 들어있어서 너무 좋았어요. 커뮤니케이션 스킬, 좋은 매니징 방법 등 조직 문화와 사회생활부터 코드 스타일, 코드 리뷰, 좋은 테스트 코드, 문서화 등 디테일한 업무 스킬까지.. 읽으면서 배울 점도 많았지만 스스로 생각해볼 거리도 너무나 많이 던져주는 책이었어요. 몇 문단 읽다가 생각해보게 되고, 몇 문단 읽다가 다시 이전으로 돌아가서 생각하고. 내 경험과 연결지어서 생각을 많이 해보게 되어서, 읽는 시간이 엄청 길어졌어요. 출퇴근 시간에 짬내서 읽다보니 두 달 정도 걸렸던 것 같아요.
정적이던 머릿속을 휘젓는 느낌
읽으면서 되게 머리가 신선해지는 느낌이었어요. 항상 자연스럽고 당연하게 생각하고 있던 개념들을 콕 한 번 짚어주거나, 니가 생각하는 건 좀.. 틀리단다~? 하고 알려주는 느낌이었어요.
1. 코딩 스타일 지킴이와 이번 주의 코드 팁…!?
구글에는 각 언어 별로 사내 모든 코드의 일관성을 지켜주는 지킴이 팀이 있데요. 해당 팀에서 언어별 코딩스타일 정책들을 정하고 관리하고 일관되게 유지하는 일을 한데요. 그리고.. 게임 로딩화면에서 게임 팁이 나오는 것 처럼.. 항상 일주일 마다 짧게 코딩팁이 발표된데요…!!!!! 항상 실력좋고 뛰어난 사람에게 코드리뷰를 받고 왕창 혼나보고 싶다는 생각을 많이 했었어요.. 왜냐면 저는 권장되는 코드스타일이나, 사용수칙, 디자인패턴, 아키텍쳐 등에 대해서 정말 본능적으로 인지하고만 있지 따로 자세하고 깊게 파본 적은 없거든요. 요즈음 그런 것들을 깊게 파보려고 여러 책들을 사고 읽고 있지만요.. 사내에 이러한 조직이 있다면.. 정말 잘 배워볼 것 같아요.
2. 자체 제작한 VCS(버전관리시스템) Piper와 코드리뷰툴 Critique와.. 코드 검색툴 Code Search
저는… 당연히… 그냥 모든 회사가 Git을 사용할 줄 생각하고 있었어요. 아니..? 생각한 적은 없긴 해요. 근데 그냥 그렇게 어렴풋이 자연스럽게 인지하고 있었던 것 같아요. Git이 곧 버전관리시스템이다. 라고. 하지만 구글은 자체제작한 VCS를 쓰고 거기에 더해 자체제작한 코드리뷰툴을 쓰고 있었어요. 거기에 더해, 코드의 주인도 몽땅 다 명시해놓았데요. 해당 코드를 수정하면 해당 주인에게 리뷰를 받아야 하는 방식… 역시.. 코드에 진심이구나.. 너무 재밌을 것 같아요.
이 내용에서 요즈음 제 관심사인 브랜치 전략에 대해서도 나왔어요. 회사 동료들이 자연스럽게 사용하고 있는 브랜치 전략(기능브랜치에 개발 후 develop에 merge, master에 merge)을 그대로 흡수해서 사용하고 있다가, 요즘은 제가 좀 더 편한 방식으로 바꾸어 보면서 이래저래 여러가지 브랜치 전략을 사용해보는 중이에요. 자동 빌드, 자동 배포를 적용해서 배포 phase(dev, stage, real)별로 브랜치를 만들어 해당 브랜치에 코드가 push되기만 하면 자동 빌드 배포되게끔.. 하지만 너무 관리 포인트가 많아지는 것 같아 고민하고 있어요.
책을 읽으면서 저희 조직에서 사용하고 있는 브랜치 전략이 Git Flow 전략(feature, hotfix, develop, master 브랜치를 사용하는 전략)이라는 것을 알게되었어요. 조금 검색해보니 Git Flow를 2010년에 처음 제안했던 Vincent Driessen이, 2020년에 와서는 해당 전략을 제안할 때에 웹 앱개발을 염두에 두지 않았다고, 해당 전략은 웹 앱 개발에 적합하지 않다고 했데요.. …엥?
출처 : https://nvie.com/posts/a-successful-git-branching-model/
구글은 트렁크 기반 개발이라고 부르는 전략을 사용한데요. 메인으로 사용하는 브랜치 단 하나만 두고, 해당 브랜치에만 빠르게 커밋하고 머지하고, 빠르게 실제 환경에 배포하는 방법이죠.
Git Flow에서 사용하는 feature브랜치, hotfix브랜치, develop브랜치 등 다양한 브랜치로 인해 관리 포인트가 늘어날 일이 없어요. 대신에… 하나의 브랜치로 관리하다 보니 검증 환경(dev phase) 배포 후 테스트하는 작업을 하기에는 적합하지 않을 것 같아요. 바로바로 운영환경에 배포되어 버리니깐요. 하지만 그만큼 완벽한 테스트 코드와 자동 검증/빌드/배포 환경이 갖추어져 있다면 정말 편리하고 빠른 개발이 가능할 것 같아요!!
대규모 브랜치와, 실 배포 일정이 자꾸 미루어져 develop에만 배포되어 있는 기능 브랜치와, 대규모 merge conflict 등… 해당 문제로 골치 아플 때가 많았는데.. 하나의 브랜치로 완벽한 테스트 CI/CD와 함께 지속되는 구글의 VCS.. 언젠가는 저도 경험해보고…….싶습니다.
3. 사내 모든 코드를 하나의 repository에 저장
이건 진짜 머리를 한 대 얻어맞은 느낌이었어요. 하나의 repository에 사내의 모든 코드를 저장…..???? 이게 어떻게 가능한가..? 기술적으로 가능한가..? 분산 저장? 어떻게든.. 기술적으로 가능할 것 같긴 하지만.. 이게… 이게…!?
그런데 정말 이 방식을 생각해보니, 실제로 사용해보면 너무 간편할 거라는 생각이 들었어요. 의존성, 버전관리 등 모두가 하나의 버전으로 단순화 되고 프로젝트 이동 등등 그냥 로컬에 있는 폴더를 이동하듯이 단순화되는게 머릿속에 그려지면서 뭔가 새로운 세상이 열리는 느낌이었어요. 내 프로젝트와 모듈과 사내의 모든 프로젝트가 하나의 repository에 있으면.. 물론 IDE와 빌드하는 컴퓨팅 성능이 완벽하게 받쳐만 준다면.. 엄청 편하겠다… 하고.. 마치 Web GitHub 자체가 로컬에 있는 느낌일 것 같아요.
사실은… 하나의 repository 방식을 우리 조직에서도 사용한 적이 있었어요. 모듈형 프로젝트 수십개를 하나의 GitHub Repository에 모아놓고 사용하는 방식. 다만 IDE가 빌드 성능을 따라와주지 못했고.. 결국 최근에 몇 개의 모듈을 각각의 repository를 새로 생성해서 분리했죠. 우리 조직은 제대로 사용하는 방법을 알아가는 와중이었던 것 같아요. 구글은… Bazel이라는 빌드 툴을 따로 사용해서 비약적으로 빠르다던데.. 재밌겠다..
- 이에 대해서 검색하다가 좋은 내용의 블로그를 발견해서 기록해요. 구글의 단일 repository에 대해서 되게 자세하고 재미있게 작성된 블로그 글이에요!
- 이건 모노리포 관련해서 구글에서 발표한 논문이에요! 참고용
매니징과 리더십
1. 섬기는 리더십
매니징과 리더십 관련한 업무 내용 중에 책을 읽고 나서도 계속 기억나는 단어에요. “섬기는 리더십”.. 관리자들은 어느덧 자신도 인지하지 못한 채 사람들을 ‘관리’하게 된데요. 근데 관리자가 관리하는 건.. 당연한 거 아닌가? 근데 이 행동은 팀 전체를 죽일 수도 있는 질병과 같은 거래요. 팀원이 안전하다고 느끼게 해주고, 정말 모든 일을 잘한다고 느끼게끔 섬긴다면 팀은 성장할 수 있데요.
사실 이 내용을 듣고서는 아직은 잘 모르겠어요. 물론 저는.. ㅎㅎ 칭찬받으면 몇 배로 잘하는 스타일이긴 한데.. 때로는 채찍질도 필요한 사람이거든요. 현실에 잘 안주하기 때문에 주변에서 누군가 채찍질을 해주거나, 엄청나게 잘하는 사람에게 자극을 받거나.
아직은 주니어 단계이고 사람을 매니징한다, 사람을 관리한다는 전제 자체를 생각해보지 않아서 와닿지 않는 것 같기도 해요. 그런데 이건 어떻게 보면 사회생활, 인간관계와도 연관이 있는 것 같아요. 보통 모든 조언들, 책들에 보면 나쁜 말은 절대로 하지 말고 좋은 말만 하라고 하잖아요? 허허
2. 안티패턴 : 만만한 사람 고용하기
이 내용은 조금 웃겼어요..ㅋㅋ 최근에 친구에게 추천받은 인물지 라는 책에 나오는 내용이 떠올랐어요. 무조건 A급 인재를 뽑아야 하는 이유가 뭔지 아세요? 사람은 자신보다 능력이 부족한 사람 밑에서 일하지 않으려고 하고, 사람은 자신보다 능력이 뛰어난 사람을 뽑지 않으려고 해서 그래요. A급 인재를 뽑아놓으면 A급 인재가 A급 인재를 불러오게 되지만, B급 인재를 뽑아 놓으면 B급 인재는 절대 A급 인재를 뽑지 않고 B급, C급을 뽑게 된데요. 그 다음 뽑힌 C급은 그 아래 인재를 불러오게 되구요. 다단계 피라미드… ㅋㅋㅋ
자신이 관리자이고, 자리 보전이 여의치 않다고 느낄 때면 만만한 사람을 고용해서 자신의 위치를 넘볼 수 없도록 하고 자신이 돋보이게 할 수 있데요. 하지만 이 방법은 자신에게 닥칠 일의 양만 늘릴테고, 팀의 생산성은 나락으로 떨어지고, 팀 인원의 수준은 점점 낮아지게 하는 지름길이래요.
저는 제가 사람을 뽑을 위치에 있을 수 있다면.. 무조건.. 무조건 실력이 돋보이는 사람…! 배울 점이 많은 사람…!! 혹은 논의했을 때 재미있는 논리공방이 될 것 같은 사람..! 배울 점이 많은 사람을 뽑고 싶어요.
3. 가능하면 위임하세요. DIY(Do It Yourself) 자제!
이건 제가 너무 못하는 거에요. 다른 사람에게 내 일을 부탁하지 못하겠어요. 가장 큰 요인은 다른 사람을 믿지 못한다는 것 같아요. 두번째로는 나의 코드에 내 스타일과 맞지 않는 코드가 덮어씌워졌을 때 많이 슬퍼요.. 제가 제 일을, 심지어는 다른 동료의 일까지도.. 제가 제일 잘할 수 있고 제일 잘 알고있다고 생각하는 것 같아요. 협업의 가장 중요한 자세가 되어 있지 않네요.. 동료를 전적으로 믿고 맡겨야 내 업무도 편해질텐데.. 믿고 맡기는 작업이 지속되어야 동료도 내 코드를 보고 나도 동료 코드를 보고 서로가 익숙해지고 담당이 분산되고..
요즘은 많이 고치고 신경을 안쓰려고 노력하는 중이에요.
나는 배울 것이, 깨우칠 것이, 읽을 것이 많다.
결론이에요. 어떤 개발 책을 읽든지 간에 나의 부족함이 여실히 드러나는 것 같아요. 가장 기본적인 브랜치 전략 부터 다양한 버전 관리 시스템, Mono Repository 전략(?) 등.. 새롭게 알게되는 것이 너무 많아서 재밌기도 하지만.. 부족함이 조금은 부끄럽기도 해요. 다만 반대로 생각해보면 모르는 것이 많기 때문에 새로 알아가는 재미도 많이 남았다는 뜻이죠.
아아 세상의 모든 개발 지식을 알고파.. 하지만 내 하루는 24시간이니..
의식의 흐름에 따라 이리 갔다 저리 갔다 독후감 -끝-