[ 서평 ] 구글 엔지니어는 이렇게 일한다.

안녕하세요! 제이덥입니다. 오늘의 포스팅은<구글 엔지니어는 이렇게 일한다>라는 내용에 대한 서평입니다. 언젠가 실리콘밸리에서 일하고 싶다라는 열망을 가진 사람으로써 “구글”이라는 회사는 어떤 문화를 가지고 있는지 어떤 방식으로 일하고 있는지 궁금해서 읽어보자는 생각을 가지고 있었고, 글또의 독서모임이라는 기회를 통해 책을 완독하게 되었습니다. 구글만의 조직 문화 뿐만 아니라 “프로그래밍”이 아닌 “소프트웨어 엔지니어링”은 무엇인지 배울 수 있었던 시간이었습니다.

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

 

📖 책을 읽게 된 계기

“우리는 4일은 해야할 일을 하고, 하루는 우리가 하고 싶은 프로젝트를 진행한다.”

-7th Pseudo Con의 GenAI 과도기 구글 표류기 세션에서-

 

7th Pseudo Con에서 구글 개발자 분께서 연사로 나서서 문화를 설명해주셨었는데, 가장 인상적이게 들었던 말입니다. (이렇게 하고 싶은 프로젝트를 통해서 만들어진 결과물 중 하나가 Gmail이라고 하셨습니다.) 기업에 속해있다면 조직의 이익을 극대화 하는 일에 모든 근무시간을 투자하는게 당연한 것인데, 일정 시간을 개인이 관심있는 프로젝트에 투자할 수 있는 시간을 보장한다는게 신선했고, 새로웠습니다. 또한 현재 구글은 기술을 리딩하는 기업 중 하나인데 어떻게 이런 방식으로도 세계에서 계속 경쟁력을 유지하는지 궁금했고, 자연스럽게 이 책에 관심을 가지게 되었고, 읽어야 할 책으로 리스트업을 해두었습니다. 그리고 “글또” 커뮤니티에서 훌륭한 개발자분들과 함께 책에 대해 읽고 대화를 할 수 있는 시간을 가지게 되었습니다.

 

💬 책을 통해 깨달은 점

💻 프로그래밍과 소프트웨어 엔지니어링을 구분하라

“소프트웨어 엔지니어링은 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다.”

 

저는 컴퓨터전자공학부를 나와 관련 전공자 임에도 불구하고, 소프트웨어 엔지니어링과 프로그래밍의 차이를 인지하지 못하고 있었습니다. 책 또한 그 지점을 명확하게 짚어내고 있었습니다. 많은 학교에서 프로그래밍을 하는 방법을 가르치고 소프트웨어 엔지니어링을 가르치지 못한다는 점을 말이죠.

 

프로그래밍과 소프트웨어 엔지니어링은시간, 규모와 실전에서의 트레이드 오프에서 큰 차이점을 가지고 있다고 말합니다. 소프트웨어 엔지니어는 기능에만 초점을 두는 것이 아니라 시간의 흐름에서 변경된 가능성과 커져가는 규모에 어떻게 진화해야하는지 트레이드 오프를 고려해서 개발해야 한다는 부분이 책에서 말하는 차이점입니다. 정리하면 프로그래밍은 개발에만 초점에 두지만 소프트웨어 엔지니어링은 프로그래밍을 포함하여 수정, 유지보수를 포함하는 개념입니다. 많은 기업은 서비스를 만들고 지속적으로 개선해 나가야하기에 소프트웨어 엔지니어링이 필요로 한다고 말합니다. 그리고 구글은 이러한 소프트웨어 엔지니어링을 문화/프로세스/도구라는 큰 세가지 측면에서 바라보며 자신만의 스타일을 확립했습니다.

 

그리고 이런 내용을 읽어나가면서 구글의 문화, 프로세스를 간접적으로 배울 수 있었을 뿐만 아니라 “소프트웨어 엔지니어링”을 바라보는 시야를 넓힐 수 있었던 계기가 되었습니다. 졸업한 학생의 신분으로써 “어떻게 하면 유지보수가 가능한 좋은 코드를 짤 수 있을까?”, “좋은 개발자는 어떤 사람인가?”라는 질문을 가지고 살았었는데, 책을 통해 나름의 해답을 찾은 것 같아 만족감을 느꼈습니다.

 

✍🏻 책을 통한 회고

• 작년에 AI 부스트 캠프에 참여하며, GitHub 관리자로 있으며 코드 버전 관리를 진행한적이 있었습니다. 소프트웨어의 기능 개발과 다르게 부스트캠프라는 짧은 기간(2~3주마다 새로운 Task 진행)과 딥러닝 모델 개발이라는 특수성 때문에 단기간에 여러 실험을 진행해야하는 상황이었습니다. 모두 다른 베이스라인(실험코드)를 사용하는 상황에서 어떻게 코드를 통해 실험 내용을 공유하고 쌓아나갈 수 있을지 의문이 많이 들었습니다. 또한 이렇게 관리자를 두어 관리하는 것이 올바른 결정인지 의심도 많이 되었던 것 같습니다.
  
  9장 코드 리뷰를 읽고, GitHub 관리자를 두어 코드를 관리하게 한 부분이 좋은 결정이 되었다는 결론을 내릴 수 있었습니다. 다만, 구글에서는 특정 기능에 대한 전문성을 가진 관리자를 두고 관리를 했습니다. 이런 부분을 보며 관리자가 적어도 10개 이상의 실험코드를 관리를 해야되었기 때문에 비슷한 실험들끼리 묶어 책임자 여러명 두어 코드를 관리 했다면 더 좋은 결과를 얻을 수 있지 않았을까라는 인사이트 또한 얻을 수 있었습니다.
  
  또한, 완벽한 코드 리뷰가 이루어지지 않은 것 같아 스트레스를 받았었습니다. 하지만, 책을 읽으며 교육을 받는 훈련생은 가독성을 갖춘 코드, 도메인에 대한 지식이 완전하지 않기 때문에 완벽하지 않다고 큰 스트레스를 받지 않았어도 됐을 것 같다라는 위로도 얻을 수 있었던 것 같습니다.

 

• 코드 리뷰를 할 때, 결함을 발견하면 미안하다고 생각해 평범한 코드라도 LGTM을 남발하거나 칭찬을 가득한 피드백을 적은적이 있었습니다. 하지만, 리뷰를 통해 피드백을 제공하는 것이 성장에 도움이 되고, 지나친 피드백은 효율성을 떨어뜨림으로 구글에서는 올바르게 코드를 짰다면 LGTM 마크를 단 한 번 표시한다는 것을 알게 되었습니다. 코드 리뷰에 대해 다시 생각해보는 계기가 되었으며, 더 나아가 내 자신이 혹시 비판받는게 두려워 남들의 성장에 도움이 주는 피드백에 집중하지 않고, 좋은 사람으로만 남고 싶지 않았나 자신을 돌아보게 되었습니다.

 

• 부스트캠프 프로젝트에서 서비스를 개발할 때에는 리뷰어를 팀원 5명 중 3명으로 두었는데, 리뷰가 오래걸린다는 생각이 들었습니다. '리뷰어를 최소한으로 두자'가 곧 리뷰의 효율성 향상이 될 수 있음을 명심해야겠습니다.

 

• 프로젝트를 통해서 Black Formatter를 이용하거나, pytest를 이용해 테스트 자동화를 적용하였는데 개인적으로 리뷰에서 큰 도움을 주고 있다는 생각이 들었습니다. 구글에서도 자동화할 수 있는 부분은 최대한 자동화를 진행했다고 했는데, 리뷰를 할 때 자동화를 할 수 있는 부분에 대해서도 고민해보는 계기가 되었습니다.

 

• 구글의 문화, 개발 프로세스는 구글이라는 회사를 고려해서 적용했습니다. 따라서 브랜치 관리 전략(Git을 활용하지 않음)과 같은 몇몇의 프로세스나 툴은 매우 새로운 내용이었습니다. 구글이 본인 회사의 규모, 특성을 고려해서 프로세스를 도입했듯 프로젝트의 규모, 인원들을 고려해서 프로세스를 만들어 나가는 것이 적합할 수 있다는 생각을 하게 되었습니다.

 

책을 일고 제가 느낀 것들을 중점적으로 정리해봤습니다. 사실 책의 길이가 700페이지나 되기도 하고 각 주제마다 생각할 거리가 많아 하나의 챕터를 하나씩 정리해도 괜찮다고 생각합니다. 저는 코드 리뷰와 버전관리에 대해 고민을 많이 하고 있었고, 그 부분에 대해서 중점적으로 정리했습니다. 

 

*도서 지원을 받지 않고 작성한 리뷰입니다. 

 

책 : 구글 엔지니어는 이렇게 일한다(한빛 미디어)