[IT 도서리뷰📘] 구글 엔지니어는 이렇게 일한다 - 주요 내용 정리 및 나의 생각 2️⃣ (2)

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

 

 

• 저자 : 타이터스 윈터스, 톰 맨쉬렉
• 출판사 : 한빛미디어
• 2022년 05월 출간

 

---

Code Search

code search 란 구글이 이용하는 코드 브라우징 및 검색 도구입니다. 문서화 관련 검색을 go/링크 를 이용해서 했듯이, 코드 관련 검색들을 통합해서 할 수 있다고 합니다. 검색창이 존재해서 웹 검색처럼 타이핑을 시작하면 '제안' 및 '자동완성' 이 나오기도 하고, 코드 관련 정보들이 모두 나온다고 하네요. 그 외에도 '코드 리뷰 도구로 점프하기', '다른 버전과 비교하기', 'blame 뷰로 확인하기' 등 많은 기능을 지원하는 것 같습니다. 스크린샷이 있으면 직관적으로 바로 느낌도 오고 좋을텐데, 웹 상에서 찾기가 힘들어 아쉽네요.

 

구글이 code search를 독립된 웹 도구로 만든 이유

 

1. 코드베이스가 거대하면 코드베이스 전체를 로컬에 복사하는 것이 불가능하다.

2. 따로 설정을 하거나 범위를 좁힐 필요 없이 모든 코드를 브라우징 할 수 있다.

3. 다른 도구와 연동, 통합이 더 수월해진다. (API로 다른 도구에 제공할 수 있다.)

 

구글이 code search를 구현할 때의 핵심

 

아마 일반적인 회사에서는 이렇게 거대한 코드 브라우징 도구를 구현할 일이 없겠지만, 그래도 이런 솔깃한 도구 구현 방법은 알아둘만 하죠 ㅎㅎ. 어마어마한 코드베이스를 전체검색하는 만큼, 구현하는 데에도 많은 노력과 좋은 설계가 필요했을 겁니다.

 

아마 이런 검색 기능에 핵심은 단연코 인덱싱의 구현 일 것입니다. 구글의 CodeSearch 팀도 인덱싱 개선에 꾸준히 투자하고 있다고 합니다. 저는 FE 개발자기 때문에 자세한 내용은 모르지만, 제가 이해한 데 까지만 정리해보았습니다.

 

1. 희소 n-그램 방식을 사용한다.

2. 글로벌 리포지터리와 차이가 적은 로컬 작업 공간용으로 간단한 무차별 검색을 수행하는 머신을 여러대 둔다.

 

코드베이스가 클 수록, 검색 결과의 랭킹 중요성이 커집니다. 구글은 각 파일의 여러 특성을 점수로 환산하는 함수를 만들어, 랭킹을 매기는 데에 사용했습니다. 

• 쿼리 독립적 시그널 : 쿼리와 독립적으로 조회하는 방식
  • 점수 측정 기준들 : 파일 조회수, 파일로의 참조량, 파일을 가리키는 참조의 수 등등
  • 주의할 점 : 참조 정보를 안정적으로 추출할 수 있어야함. 대규모 리팩토링 도중 간접 참조가 만들어져 파일이 이동되었다는 것이 감춰지는 케이스를 조심해야함. 
• 쿼리 의존적 시그널 : 쿼리마다 조회하는 방식
  • 점수 측정 기준들 : 검색어와 콘텐츠가 토큰 수준에서 깔끔하게 일치하는 지, 대소문자 일치 여부, 쿼리어에 대해 검색할 파일 범위 제한 등등
  • 검출 : 쿼리어에 따라 일치할 가능성이 있는 후보를 찾는다.
  • 결과 다양성 : 검색 결과를 다양하게 보여줘야 한다. 사용자의 현재 작업 공간에서 가능성 높은 파일 이름과 정의를 조합하여 사용

 

구글은 자원 절약보다 검색의 완벽성 을 더 중요하게 생각하고, 인덱싱을 더 많이 하는 쪽을 택했다고 합니다.

또한, 필터링 여부에 따라, 모든 결과를 보여줄 것인지, 가장 관련성 높은 결과만 보여줄 것인지 직접 결정 가능하게 했다고 합니다.

 

 

코드 리뷰

구글은 코드리뷰 시스템으로 'Critique' 라는 자체 시스템을 사용한다고 합니다. 

 

아래에 구글의 코드 리뷰 흐름을 정리해보았는데요, 일반적으로 사용하는 github 를 이용한 코드리뷰 흐름과 크게 다르지는 않은 것 같습니다.

 

Github 코드리뷰 흐름 예시

pre-commit hook을 통해 커밋 전 분석 -> 커밋 -> Github PR 요청 -> 변경내역에 대한 설명 작성 및 리뷰어 선정 -> 리뷰어들 및 열람자들의 리뷰 -> Github Actions 등 자동화 도구를 통해 정적분석 -> 머지 

 

구글의 코드리뷰 흐름

 

1. 변경 생성

사용자가 개인 작업공간의 코드 베이스에 변경을 생성 및 스냅샷을 Critique에 업로드합니다.

변경의 diff를 작성자에게 보여줌으로서, 작성자로 하여금 스스로 리뷰를 해볼 수 있도록 하고, 정적 분석기가 실행되어 코드에 문제가 없는지 검사됩니다.

 

2. 리뷰 요청

작성자가 변경의 상태가 마음에 든다면, 정해진 양식을 통해 리뷰를 요청합니다. 이 때, 도구에서 직접 코드 담당자, 혹은 소유자 등의 목록을 이용해서 리뷰어 목록을 제안해준다고 합니다. (github에서도 비슷한 기능을 지원하죠?)

 

3~4. 변경 이해 및 댓글 달기

누구든 변경을 확인하고 댓글을 달 수 있으며, 수정 방식을 제안하거나 수정 요청을 합니다.  누가 행동을 취해야 할지 등을 정해주고 보여주는 기능 또한 제공한다고 합니다. 이 책임자들을 '관심 집합' 이라고 하는데, 이 집합에 속해있다고 하면 제때 신속하게 응답해야 한다고 합니다. 이 기능은 도입 하고 굉장히 큰 순기능을 봤다고 하네요. 이는 Github 의 흐름과는 조금 차별점이죠?

 

5. 변경 승인

변경을 승인하고, 변경에 점수를 매깁니다. 이 때 고려하는 요소는 3가지 입니다.

•  LGTM(Looks Good To Me) : 변경을 허용한다. 승인의 의미인 것은 마찬가지이나, LGTM 이 하나라도 존재하지 않으면 변경을 커밋할 수 없다고 합니다. 변경을 머지하는데에 책임이 들어간 승인 인가봅니다.
• 승인(approval) : LGTM 보다는 약한 승인의 의미
• 미해결 댓글 개수 : 적을 수록 좋겠죠?

6. 번경 커밋

변경을 UI로 커밋가능합니다. 커밋 이후에도 댓글을 달 수 있습니다. 

 

 

정적 분석

어떻게 정적분석을 적용하였는가?

 

구글은 어마어마한 코드의 모노레포를 가지고 있죠. 이런 막대한 코드에 어떻게 정적분석을 적용시켰을까요?

코드 분할 과 점진적으로 분석 이 두가지 방법을 이용했다고 합니다. 거대한 프로젝트 모두를 분석하는 대신, 영향받는 파일들만 분석하고, 분석 도구가 분석기법을 통해 코드베이스를 직접적으로 다루게 했다고 합니다.

 

Key Point

 

1. 개발자 행복에 집중하자.

2. 정적 분석을 위해 개발자 워크플로에 반드시 끼워 넣자.

3. 사용자가 기여할 수 있도록 하자.

 

개발자 행복에 집중하자는 말은 , 거짓 음성보다 거짓 양성에 집중하자는 뜻입니다. 개발자 입장에서 문제가 없는데 문제를 찾았다는 경고를 계속해서 보게 된다면, 피로도와 스트레스는 무수히 쌓이고, 결국 테스트는 의미가 없어져버립니다. (대부분 비슷한 경험을 하신 적이 있을 거라 생각합니다..🥲)

 

그리고 개발자 누구나 직접 정적분석을 수정하고, 추가할 수 있도록 했다고 합니다. 

 

Tricoder

 

Tricoder 는 정적 분석을 개발자 워크플로우에 통합시키기 위해 나온 구글의 정적 분석기라고 합니다. 구글은 참 자체적인 어플리케이션이 많은 것 같죠? ㅎㅎ

 

코드리뷰 도구인 Critique 와 통합해서 돌아가게 되며, 여러 대의 분석 도구를 두고, 변경된 코드와 메타데이터를 함께 보내 분석을 요청하는 구조라고 합니다. 

 

분석 결과 각각에 Not useFul 등을 피드백할 수 있도록 해서, 분석이 유효하지 않았다고 분석기 작성자에게 알리는 기능이 있다고 합니다. 거짓 양성을 내뿜지 않고, 유효 거짓 양성 비율(사용자가 거짓 양성이라고 인식하는 비율)을 줄이는 기능을 하는 것이죠! (이 부분은 정말 좋은 기능인 것 같습니다. 저희 팀에도 도입하고 싶네요 !!! ⭐️)

 

기타 Tricoder의 기능들

• 수정 제안: 분석 결과에 따라 수정 내용을 제안하고, 반영됐을 때의 모습을 보여줌
• 프로젝트 별로 선택적 분석기를 추가, 설정 가능 (선택적 분석기는 많은 사랑을 받게 되면 때때로 기본 분석기로 승격함)

 

그 외

그 외에도 많은 내용을 담고 있습니다. 인상깊었던 내용들을 메모해보았습니다. 관리자의 일들, 조직 이끌기에 등 제 기준에서 메모해둘 필요가 없어 보이는 것들은 전부 생략했습니다.

 

이것저것 알아두면 좋을 용어들도 많이 나왔는데, 관련해서 정리된 좋은 사이트가 있어서 메모 📝

 

https://github.com/codeanddonuts/hacker-laws-kr

GitHub - codeanddonuts/hacker-laws-kr: 💻📖 개발자에게 유용한 법칙, 이론, 원칙, 그리고 패턴들 #hackerlaw

 

 

이 책에 대한 나의 생각 📖

 

주요 흐름 및 내용들

 

내용들이 서술하는 식으로 되어있어서 읽기는 편했는데, 기술적인 내용이 중심이 되었다기 보다는, '우리 구글은 이렇게 하고 있으며 이렇게 생각한다.' 정도의 내용들이었습니다. 사실 구글에서 쓰고 있다고 해서 그 내용들이 바이블인 것도 아니고, 아주 반듯하고 좋은 참고자료가 될 뿐이죠. 우리 팀의 입장, 시스템에 대입해보거나 비교해보면서 읽으려고 노력했습니다. 때로는 비판적으로 받아들일 필요도 있구요. (이렇게 생각하면서 읽는 것이 가장 어려운 법이죠🥲 생각하면서 읽어야 하는데 저 같은 경우 집중이 쉽지 않더군요..)

 

구글이 매우 큰 조직이다보니까, 대규모 프로젝트에서만 고려하게 되는 부분들, 구글 아니고서야 고민해보기 힘든 부분들에 대한 내용이 많았습니다. 어딘가에서 쉽게 레퍼런스를 구할수 있는 자료가 아니라는 좋은 점도 있고, 일반적인 개발자들은 실제 조직에서 겪을 일이 없을 수도 있는 부분이라는 단점도 있죠. 저희 팀의 코드베이스는 그렇게 크지는 않기에 (제가 전사팀에서 일하게 되지 않는 이상) 어떤 부분들은 조금 먼 산 이야기 같긴 했습니다 ㅎㅎ

 

아쉬웠던 부분?

 

개인적으로 아쉬운 부분도 있었는데요, 이 책이 담고있는 코어 내용에 비해서는 책의 양이 너무 길었습니다ㅎㅎ 사례를 제시하고, 하나하나 풀어서 설명하다보니 읽기 쉽다는 점도 있지만, 그만큼 내용들이 길어지더라구요. '도메인 주도 설계로 시작하는 마이크로서비스 개발', '개발자의 글쓰기' 와 같은 책들은 그냥 컴팩트하게 지식 자체에만 집중해서 설명하는 핵심요약집이라면, 이 책은 경험많은 시니어 개발자가 자기 경험을 쭉 풀어서 길게 강연해주는 것을 듣는 느낌? 하지만 저는 극강의 효율충이기 때문에, 전자가 조금 더 잘맞는 것 같기도 했습니다... 하하

 

마치며

 

책에서는 이런 내용들이 담겼지만, 지금도 구글의 시스템은 계속해서 변하고 있겠죠. 결국 계속 이렇게 좋은 시스템, 문화는 무엇인가에 대해 관심을 가지고 꾸준히 성장하려는 노력을 하는 것이 가장 중요할 것 같습니다. 이 책은 그런 데에 동기부여제가 될 수도 있고, 좋은 참고자료가 될 수도 있다고 생각합니다. 앞으로도 이런 책이 많아졌으면 좋겠습니다. 구글 사내 시스템, 기술 이야기를 어디서 듣겠어요~ 다음에는 아마존, 카카오, 넷플릭스 등 다양한 회사 이야기를 담은 책들이 나오길!! 😘