구글 엔지니어는 이렇게 일한다.
구름 COMMIT
안녕하세요! 오랜만에 인사 드리네요 .. 😅 일욜 괴물 소깡이입니다.
시간이 많이 지나긴 했지만 작년(2023년) 6월 21일 구름 COMMIT에서 ‘구글 엔지니어는 이렇게 일한다.’의 번역가 이복연님의 세미나가 있었습니다.
이후로 최근 다른 개발 서적을 읽으면서 세미나 때 들었던 내용이 생각이 나고 공유하면 좋을 것 같아 글로 적어보려고 합니다. :)
궁금하신 내용과 추가로 공유하면 좋을 내용이 있으시다면 언제든지 댓글로 남겨주세요!
세미나에서는
이복연님이 개발자로서 거쳐오신 커리어와 함께 그 경험에서 겪은 느낀점을 짧게 말씀해 주셨습니다. 또한, 구글에서의 사례로 개발자로서 어떻게 성장하는 것이 좋은가에 대한 이야기를 말씀해 주셨습니다.
구글이 무엇이 / 왜 / 어떻게 다른가?
구글에서의 개발 방식과 문화를 설명해 주셨는데 그 중 인상 깊은 부분만을 정리해 보았습니다.
개발
코드 리뷰
리뷰어의 종류가 크게 세 가지로 구분
- 같이 프로젝트를 개발한 사람 (팀원)
- 코드 소유자 (테크 리드)
- 코드 가독성 리뷰어 : 해당 프로젝트에 함께 소스레벨로 참여하지 않아 플로우를 알고 있는 사람 X, 전반적인 컨벤션/가독성을 봐줄 수 있는 사람을 의미
위 세 종류의 리뷰어의 모든 리뷰를 받은 뒤 배포 진행
main 브랜치 하나에서 관리
위 코드 리뷰 과정에서 알 수 있는 것처럼 매우 빡세게(?) 코드 리뷰가 이뤄지기 때문에 여러 브랜치에서 배포 관리를 진행하지 않고 최소화된 브랜치에서 배포 진행
동일한 버전으로 관리
회사 서비스 중에서 여러 프로젝트(A, B, C .. )가 존재하는 경우,
그리고 각 프로젝트 별로 ‘가’라는 라이브러를 의존하고 있을 때 A는 ‘가’의 v1.1.0을 B는 v1.2.0을 C는 v1.0.0을 바라보고 있으면 안되고
A, B, C 모두 ‘가’라는 라이브러리의 같은 버전을 바라보고 개발 진행
문화
팀 내 소통이 가장 중요
소통이 잘 되기 위해서는 심리적인 안정감이 필요
- 심리적인 안정감이 만들어지기 위해서는 겸손 / 존중 / 신뢰가 필요
- 이 세 가지 요소 중에서 가장 중요한 것은 ‘신뢰’
팀은 간혈적인 버그의 집합이다.
그렇기 때문에 프로젝트의 방향성을 제대로 잡는 것이 중요
천재 1명이 있는 것이 좋은가?
그 천재 1명도 결국 뒤에서 같이 협업한 팀이 있었기 때문에 가능했던 일 .. 그러므로 팀이 더 중요하다!
서로 신뢰하는 팀이 되기 위해서
신뢰할 수 있는 팀원을 채용하는 것이 좋지만, 현실적으로 어려운 일 .. 그러므로 서로 신뢰할 수 있도록 노력해야 한다!
- 개인의 자존심 X -> 집단적 자존감
- 비평을 받아들이기 : 중요한 점은 사전에 비평에 대한 규칙을 만들어 두고 공감하면서 비평하는 것 (공감을 이끌어 내는 것도 중요)
- 신뢰하는 실력이 되도록 키우기 : 스터디 / 세미나 / 코드리뷰
심리적 안정을 어떻게 부여할 수 있는가?
‘모른다는 것을 인정’할 수 있는 분위기
: 모르는 것을 모른다고 했을 때 나에게 불이익이 되지 않는다는 믿음이 전제
제대로 질문하기
- 스스로 고민하는 시간 필요 : 이 때 고민하는 시간에 대한 제한도 필요
- 어디까지, 어떻게 시도했는지 공유
- 동료 방해 X
- 비동기식으로, 멀티 테스킹으로 공유
- 상황적인 이유로 동기식의 질문이라면 한 번에 진행
여기까지가 인상 깊었던 부분입니다.
그 외로 세미나 관련 후기가 많이 있으니 (Q&A 등 ..) 관심 있으신 분들은 찾아보시면 좋을 것 같습니다! :)
그리고 마지막으로 세미나를 통해 가장 기억에 남은 말은
본인이 영향력 있는 사람이 되거나, 만약 그렇지 못한다면 영향력 있는 사람을 곁에 두어야 한다.
입니다. 저는 .. 후자를 택할게요 😇 (w/ 데일리몬스터즈)
이번 글도 읽어주셔서 감사드리고, 아마도 .. 일욜에는 당분간 (어쩌면 계속 .. ) 개발 서적 관련된 책이나 세미나 위주의 글이 올라갈 것 같습니다!
개발 관련된 좋은 글이나 내용을 공유할 수 있도록 하겠습니다! 🤓🔥
그럼 다음에 뵈어요 ~~ 👋🏻👋🏻
