Last Updated on 9월 25, 2023 by Jade(정현호)
구글 엔지니어는 이렇게 일한다.
구글러가 전하는 문화, 프로세스, 도구의 모든 것
서적 정보
원제 : Software Engineering at Google
출판사 : 한빛미디어
저자명 : 타이터스 윈터스, 톰 맨쉬렉, 하이럼 라이트
역자명 : 개앞맵시
출간일 : 2022년 05월 10일
ISBN13 : 9791162245620
ISBN10 : 116224562X
이번에 리뷰해볼 책은
"구글 엔지니어는 이렇게 일한다"
라는 책이고 원제는
"Software Engineering at Google"
입니다.
책은 IT기술서적으로 분류되고 있어요
다만 이 책에서 서두 부분에서는 이렇게 표현하고 있습니다.
"소프트웨어 설계를 다루지는 않습니다.
코드가 약간 등장하지만 전달하려는
핵심 원칙은 프로그래밍 언어와 관련이 없습니다.
....
실제로 프로그래밍 관련 조언은 거의 없습니다."
표현과 같이 이 책은
특정 프로그래밍 언어에 대한 코딩 방법이나 설계,
API 설계, 사용자 인터페이스,
기타 언어별 주의사항 과 같은 내용은 다루지 않으며,
구글에서 일하는
방향이나 방법론 적인 부분에
대해서 기술 되어있습니다.
특정 언어 또는 코딩 방법, API 설계 등과
같은 내용이 있지 않더라도
스타일 가이드와 규칙, 코드 리뷰, 단위 테스트,
버전 관리와 브랜치 관리, 지속적 배포 등과 같은
개발 또는 소프트웨어를 잘 운영하기
위한 여러 좋은 내용의 담겨 있습니다.
챕터는 25챕터, 페이지는 약 700페이지로
내용이 작다고는 할 수는 없을 것 같아요
구글이 소프트웨어 엔지니어링을
바라보는 주된 시각에 따라서
주제를 세가지로 나눠서 얘기하고 있어요
• 문화
• 프로세스
• 도구
문화를 다루는 2~7장에서는
소프트웨어 개발은 팀에 의해
이루어지므로 조직이 성장하고
건실하게 유지되기 위한
올바른 원칙에 대해서 소개하고 있어요
프로세스를 다루는 8~15장에서는
구글이 버텨낸 시간과 규모에서 효과적으로
작동한 프로세스들과 아직도 답을 찾고 있는 영역에
대해서 기술되어 있어요
도구를 다루는 16~25장에서는
나이를 먹어가는 코드베이스를
말끔하게 관리하기 위한
구글이 도구 인프라에 어떻게 투자해왔는지
무엇을 하였는지 등에 대해서
이야기하고 있어요
내용이 많고 다양한 만큼
한 번 정도는 다양한 관점과
경험해보지 못한 다른 곳의
일하는 방식에 대해서 간접적으로
경험해 보는 것도 좋다고 생각됩니다.
시간 위를 걷는 프로그래밍
"소프트웨어 엔지니어링 은
단순히 코드를 작성하는 행위에 더하여
시간에 흐름에 발맞춰한 조직이
그 코드를 구축하고 유지 보수하는데
이용하는 모든 도구와 프로세스를 포괄합니다."
이 책의 제목이자
책의 전체적인 내용을 가장 함축적으로
표현한 내용이 이라고 생각을 하고 있어요
또한 프로그래밍과 소프트웨어 엔지니어링의
차이를 설명해주는 것이라고 생각해요
"소프트웨어 엔지니어링이란
흐르는 시간 위에서 순간순간의
프로그래밍을 모두 합산한 것이다"
이 책에서 공유하고자
핵심이라고 설명하고 있습니다.
소프트웨어 엔지니어링이란?
프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이에 대해서
책에서는
시간(time),
(규모) 확장(scale),
실전에서의 트레이드오프(trade-offs at play)
이렇게 세가지로 표현하고 있습니다.
즉, 소프트웨어 엔지니어링에서는
시간의 흐름과
언젠가 변경될 가능성에 대해서 신경 써야 함을
얘기하고 있습니다.
시간이라는 요소가 더해지면 프로그래밍에는
중요한 차원이 하나 늘어서 더 입체적으로 바뀌며,
코드의 예상 수명 또는 생애주기(Life Cycle) 와도 연관이 되게 됩니다.
수명이 길어 질수록 변경이라는 요소가 점점 중요 해진다는 의미가 됩니다.
소프트웨어 엔지니어링 과 프로그래밍 가르는 핵심은
소프트웨어 지속 가능성(sustainability)
이라고 할 수 있습니다.
그 다음 다른 관점으로는
규모
에 대해서도 생각해 볼 수 있습니다.
소프트웨어 엔지니어링은 팀 업무이며
초기에는
"여러 버전의 프로그램을 여러 사람 참여해 개발하는 것"
이라고 정의하곤 했습니다.
팀 업무라는 관점이 중요함을 의미하고 있습니다.
그래서 소프트웨어 엔지니어링 과
프로그래밍은 시간과 규모(참여 인원) 면에서 차이가 납니다.
문화
Part II 인 문화에서는 다양한 주제로
구글의 일하는 문화를 소개하고 있으며
공통적으로 소개되는 내용은
팀워크와 팀 빌딩,
팀 또는 조직에 대한 내용이 소개되어 있습니다.
같이 잘 일할 수 있는
문화적인 방향성과 방법론
그리고 팀을 잘 이끌어 내기 위한
리드의 마인드와 행동
등이 기술되어 있습니다.
몇 가지 주제와 짧은 내용으로
간추려 보도록 할게요
팀 워크 이끌어 내기
버스 지수
몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때
프로젝트가 망하게 되는지를 나타내는 지수
여기에서는 프로젝트에서 필요한
지식과 노하우가 얼마나 분산되어 있는지
그리고 왜 분산되어 있어야 하는지를 설명하고 있습니다.
사회적 상호작용의 세 기둥
- 겸손, 존중, 신뢰
사회적 갈등의 근본 원인을 분석해보면
결국 겸손, 존중, 신뢰 가 부족하여
일어났음을 알 수 있으며,
세 기둥을 실천하기 위한 방법에 대해서
소개하고 있습니다.
자존심 버리기 : 회의실에서 가장 중요한
인물인 것처럼 행동하는 사람과
함께 일하기를 좋아하는 사람은
없습니다.
.. 대신 여러분은 팀이라는 '집단'으로서의
자존심과 정체성을 강화해야 합니다.
신뢰는 '자존심' 버리기'의 한 축입니다.
팀을 믿으세요
팀원들의 능력과 기존에 이룬 성과들을
존중해야 한다는 뜻입니다.
마음을 열고 받아들이자: 다른 이 이로부터 배우는 데
열려 있을수록 여러분의 영향력도 커집니다.
... 하지만 주변 사람들이
아무리 설득해봐도 고집을 굽히지 않는
사람이 껴 있는 팀을 상상해보세요
... 더 이상 귀 기울이지 않고
대신 공인된 장애물 취급하며 피해 다닙니다.
'다른 사람이 내 생각을 바꿔도 괜찮아'
라는 생각을 항상 머리 속에 담아 두시 길 바랍니다.
구글답게 하기
구글다움이 갖춰야 할 기준을 명확히 정의하였으며
이로 인하여 강력한 리더십을 보이고
겸손, 존중, 신뢰 를 드러내는 태도와
행동 등을 정의한 것 입니다.
- 모호함을 뚫고 번창한다
- 피드백을 소중히 한다.
- 저항(항상성)을 극복한다.
- 사용자를 우선한다.
- 팀에 관심을 기울인다.
- 옳은 일을 한다.
팀 이끌기
안티패턴 : 팀을 어린이처럼 대하기
팀을 신뢰하지 못함을 보여주는 가장 대표적인 예가
팀원들을 어린이처럼 대하는 것입니다.
사람들은 자신을 대하는 방식대로
행동하는 경향이 있습니다.
팀원을 어린이나 죄수처럼 대한다면
그들이 그렇게 행동한다고 놀라지 마세요
신뢰를 보여준다면 보통은 그들도
능력을 발휘할 것입니다.
올바른 패턴 : 행복한지 확인하기
팀의 생산성을 장기적으로 더욱 끌어올리려면
팀원이 행복해하는지를 확인하는 데도
신경을 써야 합니다.
우리가 일해본 최고의 리더는
모두 반은 심리학자였습니다.
'뭐 필요한 것 없어요?'
'더 필요한 건 없고요?'
간단한 질문이죠.
하지만 팀원들의 생산성과
행복 증진에 필요한 것을
갖춰주는 데
아주 효과적인 멘트입니다.
프로세스
Part III 에서는 프로세스에 대해서
이야기하고 있습니다.
프로세스에는 스타일 가이드 규칙,
코드리뷰, 문서자료, 테스트
폐기 등의 내용이 담겨 있습니다.
코드 리뷰
코드베이스 전반의 정확성, 이해 용이성,
일관성 보장 등으로
코드 리뷰를 하였을 때 주어지는 장점에
대해서 소개하고 있으며,
피드백을 주는 방식과 방법에
대해서 얘기하고 있습니다.
물론 구글에서 하는 코드리뷰를 하는 방법과
프로세스 등도 소개 되어있습니다.
구글에서 어떤 변경이든
승인을 얻으려면
세 가지 측면에서의 리뷰를 통과해야
한다고 합니다.
1) 다른 엔지니어로부터 정확성(correctness)과 이해용이성(comprehension)을 평가
2) 변경되는 코드 영역을 관리하는 코드 소유자(code owner)로부터 변경 코드가 적절하다는 승인
3) 가독성 승인
가독성 이라는 것은
단순히 용이성만을 뜻하지 않으며
다른 엔지니어들도
유지보수 가능하도록 코드 스타일과
모범 사례 준수여부 까지를
포함한다는 의미입니다.
공손하고 전문가 답게 : 구글의 신뢰와 존중 문화를 조정하기 위해 심혈을 기울입니다.
이 문화는 구글이 코드 리뷰를 수행하는 방식까지 영향을 주게 됩니다.
코드의 이해 용이성 요건을 충족하려면
단 한명의 엔지니어만 LGTM이라고
선언해줘도 충분하지만, 이 한번의 리뷰가 통과되면
코드베이스에 반영될 수 있음을 알고 있기 때문에
가볍게 보고 LGTM을 남발하지 않는다는 뜻이며
리뷰어들은 작성자가 선택한 방식을 존중하고
오직 그 방식에 결함이 있을 때만
대안을 제시해야 합니다.
변경 설명 잘쓰기 : 변경 설명의 첫 줄은 어떤 종류의
변경을 하였는지
잘 요약해야 합니다.
그래서 첫 번째 줄은 정말 중요한 자리라고
설명하고 있습니다.
변경 설명에 달랑 '버그 수정' 이라고만 적어 놓으면
리뷰어는 물론이고
나중에 변경 이력을 살펴보는 사람들에게도
아무런 도움이 되지 못합니다.
코드 리뷰를 거치면서 처음 코드와 달라지는 점은
변경 설명과 코드 주석에도 반영해야 합니다.
코드 리뷰는 지금 당장만이 아니라 후대를 위해
현재하고 있는 일을 기록하는 행위 입니다.
테스트 문화
구글의 테스트 문화는 2005년 부터
먼 길을 걸어왔습니다.
신규 입사자 오리엔테이션에서는
여전히 테스트를 가르치고 있습니다.
구글에서는 코드가 변경할 때마다
코드 리뷰를 거쳐야 합니다.
그리고 모든 변경에는
테스트 코드가 포함되어 있어야 하고요
이렇게 시간이 흐르면서 테스트는
구글 엔지니어링 문화의 필수 요소로 자리 잡았습니다.
폐기
"코드는 자산이 아니라 부채다"
라는 기본 전제에서 시작하고 있습니다.
코드가 자산이라면 낡은 시스템의 비중을 줄이고
제거할 이유는 없을 것이지만,
코드에는 비용이 따라오게
된다고 설명하고 있습니다.
비용의 일부는 시스템을 구축 과정에서 발생되고
대부분의 비용은
구축 후 생이 끝날 때까지
유지보수하는데서 발생합니다.
시스템을 운용하는데 드는 운영 자원
그리고 주변 생태계의 진화를 발맞춰
코드베이스를 업데이트하는 노력 등의 비용이
계속 투입된다는 사실은
낡아가는 시스템을 계속 운영할지
아니면 폐기시킬지를 놓고 저울질을
해봐야 한다고 설명하고 있습니다.
폐기는 왜 그리 어려운가?
폐기가 쉽다면 책에서도 별도의 챕터로
폐기에 대해서 언급을 하지는 않았을 것입니다.
시스템을 운영하면서 예전 시스템 흔희
레거시 라고 부르는 시스템을 페기 하기 까지는
많은 시간과 노력이 필요함을 느껴 보셨을 거라고 생각 합니다.
구글에서도 폐기의 어려움을 잘 알고 있기에
잘 폐기하기 위한 프로세스와 방법론 등을 설명하고 있습니다.
"폐기는 축제 행렬이 휩쓸고 지나간 거리를 청소하는 지저분한 일처럼 느껴질 수 있습니다.
하지만 이런 노력 덕분에 유지보수 부담이 줄고 엔지니어가 알고 신경 써 할 정보량이 줄어서
전체적인 소프트웨어 생태계가 개선됩니다"
도구
Part IV 에서는 구글에서
소프트웨어 엔지니어링을 위해서
사용하고 개발하고
고민한 여러 가지 내용이
이야기되어 있습니다.
버전관리, Code Search,
빌드시스템과 빌드 철학, 코드 리뷰 도구,
의존성 관리, 대규모 변경 등의 내용이 담겨 있습니다.
버전 관리 @구글
구글의 소스 코드 대부분은
하나의 리포지터리
즉 모노리포에서 관리되며
약 5만여 엔지니어에게 공유되고 있다고 합니다.
크로미움 과 안드로이드
같은 오픈소스 프로젝트를 제외하고
구글이 주관하는 프로젝트는
거의 모두가 이 안(모노리포)에서
이루어진다고 합니다.
자체 개발한 중앙집중형 VCS를 이용하며
이름은 Piper이고,
80TB가 넘는 콘텐츠와
메타데이터를 담고 있다고 합니다.
Code Search
버전 관리에 대해서 내용을 읽다 보면
구글의 코드베이스의 크기를 알 수 있게 됩니다.
그 많은 코드에서 내가 원하는 부분을 정확하고
빠르게 찾는다는 것은
쉽지 않은 것이라고 생각 하고 있어요
그래서 이번 챕터에서는
수많은 코드에서
엔지니어가 원하는 코드
또는 라이브러리 또는 내용을 찾기 위한
구글의 Code Search 시스템의 변천사와
고민 사항에 대해서 기술되어 있어요
구글의 Code Search 는 구글이 이용하는
코드 브라우징 및 검색 도구이고,
프론트엔드 UI와 다양한 백엔드 요소로
이루어져 있다고 합니다.
처음에는 grep 과 유사한 코드 검색 도구와
대외용UI의 조합으로 시작했다고 합니다.
이렇게 통합된 덕분에 단순한 코드 검색에서
브라우징으로 초점이 옮겨졌으며,
나중에는 '클릭 한 번으로 다음(예상) 질문에 답해주기' 가
code search 개발 원칙의 하나가 되었다고 합니다.
구글은 어떻게 구현했나?
초기에는 grep 과 유사한 툴을
이용하여 사용하였으나,
구글 코드베이스에 업데이트나
신규로 추가되는 코드의 량은 상당할 것이며,
시간이 지날 수록 검색 속도와
검색의 부하는 계속 늘어날 것입니다.
그리고 구글이 성장함에 따라서
이 code search 시스템을 사용하는
엔지니어도 늘어날 것이고요
빠른 검색을 위해서 인덱싱을 생성하고
관리하는 것이 필요 하였고
초기에는 트라이그램(trigram) 기반 방식으로
사용하였다고 합니다.
랭킹 처리나 수만 개의 컴퓨터를 연동하는 데
드는 커뮤니케이션 부하 등의 어려운 점 있지만
구글의 code search 팀이 인덱싱 개선을 꾸준히 하고 있다고 합니다.
수년이 흐른 뒤 초기의 트라이그램 기반 방식을 버리고
커스텀한 접미사 배열 기반을 도입하였습니다.
그리고 현재는 희소 n-그램(sparse n-gram) 방식까지 진화했습니다.
현재는 예전의 grep 보다 500배 이상의
효율적인 정규식 표현식 검색을
동시에 처리할 수 있는 놀라운
성능을 보여주고 있다고 합니다.
n-그램 기반 방식으로 전환한 이유는
구글의 기본 인덱싱 및 검색 스택의
장점을 활용하기 위함이었습니다.
그래서 '표준' 기술로 눈을 돌렸으며
그 결과 역 인덱스 생성과 인코딩,
코어 검색팀이 개발한 서빙(serving)
등의 장점을 그대로 수용할 수
있었기 때문이라고 설명하고 있습니다.
서비스형 컴퓨트
열심히 코드를 작성하였다면
이를 실행해줄 하드웨어가 필요 합니다.
하드웨어를 구입하거나 임대를 해야 할 것이며
이것이 서비스형 컴퓨트(compute as a service, CaaS)
의 본질이라고 설명하고 있습니다.
어떻게 '조직의 발전과 성정에 발맞추어 확장되어 나가는 시스템'
으로 만들어지는 것에 대해 이야기하고 있습니다.
구글에서 이용하는 Borg 시스템은
쿠버네티스나 Mesos 같은
많은 CaaS 아키텍처의 선구자 입니다.
컴퓨트 서비스 선택하기
현대적인 컴퓨트 서비스가 다양하게
이미 출시 되어있고
오픈소스 진영에는 쿠버네티스, Mesos 가 있고
다른 수준의 추상화를 제공하는
OpenWhisk 와 knative 도 있습니다.
구글 클라우드 플렛폼의 MIGs 와 AWS 의 EC2 자동확장이 있으며
Borg 와 비슷한 관리형 컨테이너로는 MS의 Azure kubernates Service
구글의 Google Kubernetes Engine 등이 있습니다.
나아가 서비리스 서비스에는 AWS Lamda 와 구글의 Cloud Functions 도 있죠
이 많은 컴퓨트 서비스중에서
조직이 하나의 컴퓨트 서비스를 선택할 것입니다.
이때 컴퓨트 인프라는 강력한 종속(lock-in)
요인임을 충분히 감안해야 한다고 설명하고 있습니다.
VM, 컨테이너, 서버리스까지 각각의 장단점과
그에 따른 트레이드오프에 대해서 설명하고 있습니다.
이번 책 "구글 엔지니어는 이렇게 일한다" 에 대해서 간략하게 소개 및 리뷰를 해보았습니다.
서두에 이야기한 것처럼
특정 언어의 기술이나 설계 등의 내용은 없지만
구글의 프로세스와 도구 파트에서는
다양한 내용이 설명되기 때문에
해당 부분에 대해서 경험이나
기반지식이 적다면 조금은 내용이 어렵거나
이해가 덜 될 수도 있는 점도 있을 것 같습니다.
다만, 그런 챕터나 내용은 가볍게
읽어보고 넘어갈 수도 있으니
크게 걱정은 하지 않아도 될 것
같다고 생각하고 있습니다.
앞쪽에 있는 문화 2~7장의 경우는
회사 또는 조직에서의
IC, IC이면서 Lead,
또는 M 등 각각의 역할에서
좋은 방향으로 나아가기 위한
여러 도움이 되는 내용이 있고
이 부분은 기술적인 부분은 아니다 보니
편하게 읽어 볼 수 있었던 것 같고,
다양한 관점과 내용으로
성공하고 성장하는 조직에
대한 내용 부분에 대해서
인사이트를 받을 수 있었던
내용이었다고 생각하고 있어요
구글이 성장하면서 소프트웨어 엔지니어링을 위한
여러 가지 노력과 고민 그리고
과거부터 지금까지의 도입된 여러 장점 등을
간접적으로 알 수 있는 계기였으며,
내용은 다소 많을 수 있지만
한 번 정도는 편한 마음으로
읽어보셔도 좋을 것 같다고 생각하면서
이번 글을 마무리하도록 하겠습니다.
해당 리뷰는 책을 구매 후 읽고 난 소감을 주관적으로 작성하였습니다.
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
