구글 엔지니어는 이렇게 일한다 리뷰 :: 마이구미

이 글은 "구글 엔지니어는 이렇게 일한다" 라는 책을 리뷰한다.
본인은 평범한 프론트엔드 개발자이다. 개인적인 생각과 해석이 들어가 있을 수 있다.
책 링크 - https://product.kyobobook.co.kr/detail/S000061352347

 

 

개발자라면, 누구나 빅테크들이 어떻게 일하고 있는지 궁금할 것이다.

책은 굉장히 두껍고 700 페이지를 차지하고 있다...

 

많은 문제들을 구글이 어떻게 해결했고, 그 과정들을 다루고 있다.

한편으로는 구글정도의 회사가 아니라면 고민하지 않는 문제들도 많다고 느끼긴 했다.

그래도 충분히 그러한 과정들은 흥미롭고 많은 지식을 습득할 수 있다.

실제로 우리가 그냥 당연히 사용하고 있는 도구, 시스템 등을 과거로부터 구글은 어떻게 고민했고, 해결해 나가고 있는지를 엿볼 수 있다.

정말 많은 내용들이 있지만, 몇가지만 기록용으로 남겨두려고 한다.

 

---

 

단명하는 코드와 장수하는 코드의 수명은 10만 배는 될 것입니다. 동일한 모범 사례를 수명 축의 양 끝단에 위치하는 두 프로젝트에 똑같이 적용하려는 건 너무 안일한 생각입니다.

 

프로젝트 규모, 목적, 수명 등에 상관없이 모범 사례를 적용하려는 시도는 때때로 접할 수 있다.

흔히 우리는 오버스펙이라고 부른다.

개인적으로는 있으면 좋고 없어도 문제 없는 것이라면, 대부분의 경우에 결국 다른 이슈로 돌아왔고, 선호하지는 않는다.

 

 

이용하는 API 명세에 명시되지 않은, 즉 언제든 변할 수 있는 기능을 사용하는 코드는 임시방편적인 혹은 기발한 코드입니다. 반대로 모범 사례를 따르고 미래에 대비한 코드는 클린하고 유지보수 가능한 코드입니다.

 

개인적으로 원하는 기능이 제공되지 않아서, 라이브러리의 코드를 분석해서 사용할 수 있는 코드를 발견하여 사용한 경험이 있다.

문서에는 관련 기능이 명시되지 않았지만, 알고 있다면 사용할 수 있는 기능이었다.

history 모듈에서 index 라는 값을 내부적으로 사용하고 있었고, 이 기능은 본인이 찾던 기능이었다.

그러던 중 어느 날 예기치 못한 에러를 맞이하게 되었다.

마이너 버전이 업데이트된 모듈에서는 index 값을 더이상 사용하지 않는게 원인이 되었다.

결과적으로는 공식적인 API 명세에 따르는 것이 클린하고 유지보수 가능한 코드라는 것을 느끼게 되었다.

 

 

변경은 본질적으로 좋지 않으므로 변경을 위한 변경은 삼가야 하지만 변화에 대응할 수는 있어야합니다.
언젠가는 바뀌어야 한다면 변경 시 비용이 적게 들도록 하는 데 미리 투자할지도 고민해야 하겠죠.

 

대부분 변경에 대해서는 회의적이다.

하지만 변화가 필요한 시점이 다가올 영역이라면, 미리 투자를 해야하는 것은 맞는 말이다.

변경에 두려움이 구성원에게 설득할 수 있는 좋은 말이라고 느껴진다.

 

 

원점 회귀(shift left)
개발 과정에서 문제를 일찍 발견할수록 비용이 적게 든다는 사실

 

원점 회귀라는 용어는 보안성 점검을 개발 프로세스의 마지막으로 연기하면 안 된다고 호소하며 보안을 고려하는 시점을 왼쪽으로 이동시켜라(shift left on security) 라고 한 말에서 유래되었다고 한다.

새로운 프로젝트를 시작하는 경우에 보안성 점검 관련 작업은 가장 후작업으로 미루는 모습을 많이 볼 수 있다.

실제로 예상하는 것보다 많은 이슈를 맞이하여 배포 일정이 밀리는 상황을 초래했다.

 

 

버스 지수(bus factor)
몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수

 

같은 팀이라도, 다른 동료의 업무를 잘 알지 못하는 경우가 많다.특정 상황에 대응할 수 있는 인원이 적을수록 쉽게 흔들리고 다른 팀들은 우리를 신뢰하지 않을 것이다.

 

 

늘 자신이 이 회의실에서 가장 중요한 인물인 것처럼 행동하는 사람과 함께 일하기를 좋아하는 사람은 없습니다.
모든 논의 주제를 시작하고 마무리 짓는 사람이 자신이어야 한다고 생각하나요? 제안이나 안건마다 사사건건 첨언하고 싶은가요?

 

이 문장을 읽자마자, 움찔하였다.

연관된 일이라면, 항상 본인의 주장을 제시하고 설득하려고 한다.

근본적인 원인은 다른 동료를 믿지 못하기 때문이라고 생각한다.

이 부분은 고치려고 노력하지만 잘 안되는 부분이다.

하지만 이러한 모습이 계속되면 나와 일하고 싶은 사람은 점차 사라지게 된다는 것을 잘 인지해야겠다.

 

 

전통적인 관리자는 일을 “어떻게" 처리할지를 고민하는 반면, 훌륭한 관리자는 “무슨" 일을 처리할지를 고민합니다.

 

본인이 관리자라면, 주어진 일들을 "어떻게" 처리할지 고민할 것이라고 상상해보았다.

하지만 훌륭한 관리자는 "무슨" 일을 처리할지 고민한다. 라는 의미를 조금 이해할 수 있었다.

이것도 신뢰의 문제가 포함된다고 생각한다.

"어떻게" 를 동료들을 맡길 수 있고, 관리자는 "무슨" 을 고민하는 것이 더 좋은 방향이라고 생각한다.

 

 

저에겐 두 가지 종류의 문제가 있습니다.
급한 문제와 중요한 문제.
급한 문제들은 중요하지 않고, 중요한 문제들은 절대 급하지 않습니다.

 

많은 상황에서 좋은 방향을 제시해주는 문장인 것 같다.

급하다는 이유로 중요한 것으로 합리화하는 경우가 많다.

중요한 문제는 절대로 급하게 처리할 수 없다.

 

거의 모든 코드 파일에 파일 주석이 적혀있어야 합니다.

 

 

파일 주석은 학생 시절 흔히 접했지만, 실무에서는 생각해본 적이 없는 것 같다.하지만 실무에서의 코드는 도메인 지식을 기반으로 작성된다고 생각한다.

그렇기에, 해당 파일의 존재 이유를 알려주면 좋은 파일들이 간혹 존재했는데 여기서 활용하면 좋을 것 같다.

 

 

개념 설명 문서
어떤 코드는 코드 주석 같은 참조용 문서자료만으로는 부족하여 깊이 있는 설명을 곁들여야 합니다.

 

대부분 컨플이나 구글독이나 문서 관련 툴을 사용할 것이다.

주석으로 표현하기 어려운 내용이라면, 과해보일수 있지만 문서 링크까지 포함시키는 것에 습관을 들이는 것도 좋을 것 같다.

 

 

문서자료 리뷰
구글에서는 문서 대부분이 독자 리뷰를 받도록 합니다.
문서의 품질은 작성자가 아닌 독자에 의해 평가된다.

 

문서들은 작성자가 작성하고, 다른 사람의 코멘트가 없는 모습을 많이 볼 수 있다.

본인만을 위한 문서가 되어버리거나, 잘못된 내용을 전파하는 문서로 남을 수도 있다.코드 리뷰처럼 문서자료 리뷰도 굉장히 유용해보인다.실제로 현회사에서도 작성된 문서에 아무 코멘트가 없는 것은 문제가 있는 것이라고 강조하고 있다.

 

리포지터리들끼리 상호 연결해주는 가벼운 기법을 연구하고 있습니다.
이질적인 여러 리포지터리들을 묶어 하나의 더 큰 가상 모노리포로 다루는 일이 그리 어렵지 않을 것입니다.

 

예전부터 현재까지 모노레포 방식이 유행되고 있다.

모노레포 방식은 유용해보이지만, 현존하는 많은 문제들도 있다.

독립적인 레포를 묶는 더 큰 모노레포는 굉장히 흥미로운 것 같다.

 

 

Semver 는 호환성을 확실하게 보장하는가? 추정인가?

 

현재 Semver 를 기반으로 버전 관리를 많이 접하고 있다.

책에서는 Semver 에 대한 문제점을 자세히 설명하고 있고, 흥미로운 내용이 많다.

실제로 메이저, 마이너, 패치의 기준은 정해져있지만, 이것을 정하는 건 결국 작성자이다.

그로 인해, "마이너니까 올려도 문제가 없겠지" 라는 것은 사실 보장할 수 없는 이야기이다.

실제로 마이너, 패치를 올려도 문제가 되는 경우를 경험할 수 있다.

 

 

포스트모템(postmortem)
실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심.

 

흔히 장애보고서를 말할 수 있다.

간혹 장애의 규모를 최소화하기 위해 목적과는 다르게 작성되는 경우도 접할 수 있다.

재발 방지를 위한 조치, 해당 경험에서 얻은 교훈 등에 중점을 두면, 굉장히 좋은 회고 방법이라고 생각한다.

 

 

 

칭찬 샌드위치(compliment sandwich)

 

전달하려는 메시지 앞뒤에 칭찬을 붙이는 것을 의미한다.

실제로 이러한 대화법을 사용하는 사람도 볼 수 있고, 본질을 이해하지 못하는 듣는이도 볼 수 있다.

전달하고자하는 본질을 흐려 상대방에게 원하고자하는 메시지가 전달되지 않을 수 있으니 고민해볼만한 사항이다.

 

 

피터의 법칙
주어진 위치에서 뛰어난 성과를 내는 직원은 승진을 거듭하다가 더는 성과를 낼 수 없는 위치까지 올라선 후 멈추게 됩니다. 그래서 결국 조직 전체가 무능한 사람들로 채워지는 역설적인 상황에 처함.

 

하이럼의 법칙
사용자 수가 충분히 많아지면 시스템이 약속하지 않았더라도 관찰 가능한 모든 행위에 누군가는 의존하게 된다.