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

Ch.1

프로그래밍 vs 소프트웨어 엔지니어링

• 소:
  • 프로그래밍이랑 다른점: 시간축 + 확장성 + 실전에서의트레이드오프
  • 언젠가 변경될 가능성에 신경쓰기
  • 프로그래밍 + 수정 + 유지보수
  • 조직 규모에 따라서도 코드의 모양이 바뀌여야 함
• 소프트웨어의 지속가능성
  • = 기대 생애 동안 필요한 변경사항에 대응할 수 있다

시간

• 줄곧 초기 스타텁에서만 일해왔다면 10년차 개발자라도 한 SW를 1~2년 이상 유지보수한 경험이 전무할수있음
• 장수 프로젝트(HTTP서버, 리눅스 커널 등)는 프로그래밍 과제나 스타텁 개발과는 다른 무언가가 되어감
• 하이럼의 법칙: 사용자가 충분히 많다면 명세에 적힌 내용은 중요하지 않음. 시스템에서 보이는 행위를 누군가는 이용하고 있기 때문
  • 스페이스바 여러번 누르면 과열되는 버그 → 어떤 사용자는 이걸 기능으로 쓰고 있음(과열되면 컨트롤키로 인식하도록 설정해둔다거나)
  • 엔트로피와 개념 유사.
  • S.E할거면 요런 사이드이펙트에 기대지 않고 모범사례를 따라야함 (프로그래밍이라면 기발함으로 칭찬할 수 있겠지만)
• 잘하는 시스템 관리자
  • 변경해도 백업 테이프를 마련해놓고
  • 어떻게 복구할 수 있는지, 그 비용은 어느정도인지
  • 이를 알아야 효율+안정성을 높일수있음.

확장

• 시간흐름보다 변경비용이 크면 확장하기 어렵다
• 코드베이스 자체도 확장가능해야함: 빌드나 git이 느려짐. 조직 차원에서 챙겨야함.
• 답해볼만한 질문들
  • Q. 조직이 10배로 커지면 이 작업도 10배로 많아지는가?
  • Q. 개발할 일이 조직이 커질수록 늘어나는가?
  • Q. 코드베이스가 커질수록 작업량도 늘어나는가?
  • 이렇게 냅두면 확장하기 어려워짐.
    • 조직이 커졌을 때 작업이 그보다 덜해지면 더 큰걸 만들수 있자너
• 마이그레이션 전문가 조직 따로 두는게 확장성 좋았음.
• 비욘세 규칙
  • 각 팀에서는 각자의 CI테스트를 미리 만들어놓고
  • 인프라팀은 그 CI만 통과한다면 어떤 변경이든 할 수 있도록 (그게 없다면 일일히 찾아가서 업글 잘 됐는지 확인해야함)
• 인프라는 자주 변경할수록 변경하기가 오히려 쉬워짐. 그리고 코드도 견고해짐!
  • 하이럼 법칙에 의해 하부 구현의 미묘한 차이에 의존하는 일들이 없어지고, 언어나 OS차원에서 보장하는 추상 개념을 활용하도록 바뀜

트레이드오프

• 비용
  • 금융 비용
  • 리소스 비용 (CPU시간)
  • 인적 비용 (엔지니어링 노력: 집중력을 흐리면 생산성도 나빠짐)
  • 거래 비용 (조치를 취하는 비용)
  • 기회 비용 (조치를 취하지 않는 비용)
  • 사회적 비용 (선택이 사회 전체에 미치는 영향)
• 위 구분의 비용들을 종합해서 의사결정에 참고해야 함
  • “데이터센터에 설치할 CPU n개를 줄이기 위해 엔지니어를 2주정도 투입할 비용은?” ⇒ 비교적 정량적으로 측정할 수 있음
  • “엉망으로 설계된 API의 엔지니어링 비용은?” ⇒ 쉽게 알 수 없음. 경험이나 리더십에 기대야 함.

Ch2. 팀워크 이끌어내기

전체가 개인의 합보다 크다는걸 뇌에 때려박어

• 프로그래머 특성상 내 코드가 부끄러워서 숨고 멋진 코드가 될 때 쨘 보여주고 싶은 욕망이 있는데 해로운 일임.
• 실패한 프로젝트의 핵심을 책임진 경험보다 성공한 프로젝트의 부분에 참여한 경험이 더 낫다
  • => 영웅 프로그래머가 되어야지 ㅎ 란 생각보다
  • => 최대한 고기능 팀을 경험하는걸 목표로!
• 같이 해야 더 성장함
  • 개인의 노력만으로는 깨우치기 어려운 공동의 지혜

사무실 구조: 오픈과 집중 그 사이

• 4~8명 정도 팀마다 하나의 방 배치
• 적당한 정도의 소음과 소통 유발

사회적 관계의 힘을 과소평가하지 말아라

• 일이 진행될 수 있도록 관계를 형성해라.
  • => 안되어보이는 일도 어떻게든 되게 만들고,
  • => 반대도 기능함. 되는 일도 안되게 만듦.
• 관계에 도움되는 일이라면 내가 개인적으로 불필요하다 생각하는 것도 하는게 좋을 때가 있음 e.g. 격식에 맞는 복장

겸손이 환대받음. 내가 짱이다 라고만 생각하면 안됨.

• 내가 젤 똑똑하다 생각해도 그게 티나면 망함
• 모든 걸 다 아는것처럼 행동하는게 오히려 독이 되기도.
  • 그 욕심을 버리고, 집단적 자존심 을 키워보자. (팀의 성취, 단체의 자부심)
• 다른 이들로부터 배우는데에 열려있을 수록 내 영향력이 커진다
  • 입장바꿔서 생각해봐라. 아무리 설득해도 고집불통인 사람. (e.g. 그래서 사람들이 정치인을 신뢰X)
  • “다른 사람이 내 생각을 바꿔도 괜찮아” 를 늘 염두
• 실수를 인정할 때 장기적으로 지위를 확고이 해줌.
  • 책임지고 의무 다하겠다는 표출.
  • 다른 사람 의견 신뢰한다는 표출
  • 어떻게든 일이 올바르게 돌아가도록 만들겠다는 표출.

실패는 선택이다

• 에디슨 “만 가지의 잘못된 방식을 찾아낸것일뿐 실패한게 아니다”
• 실패하지 않는다면 충분히 위험을 감수하지 않았거나 혁신적이지 못했던거다

Ch.3 지식 공유

성장의 분위기를 만들려면 심리적 안정감이 필요조건

• 타인의 무지를 탓하지 말고 오히려 솔직함을 반겨야 한다
  • 리더가 솔선수범해야함
    • 상급자라면 모든걸 알아야 한다는 인식 없애기
• 잘못하다간 조직 구성원이 ‘모든것을 다 아는 사람’과 ‘아무것도 모르는 사람’으로 나뉘어버림;;;
  • 일케 되면 전문가들은 모든 일을 다 처리해야됨 → 고러면 멘토링이나 문서화 시간낼수도 없음 (악순환)
• 끈기를 가지고 상냥하게 답변해줘야 사람들이 안심하고 물을 수 있는 환경 조성됨

뛰어난 개발자는 태어나는게 아니라 길러진다

• 그 어떤 전문가도 한때는 초심자였습니다
• 구글에서는 누글러에게 멘토를 붙여주는데 같은 팀의 일원으로는 안 한다 (편하게 질문 가능하도록)

문서 작성의 트레이드오프

• 일반적인 상황을 다루므로 개별 학습자의 특수상황엔 적합하지 않을수도
• 최신정보 반영해야 해서 유지보수 비용

가르치는건 전문가의 전유물이 아니다

• 전문성이 ‘초심자 아니면 전문가’로 이분법으로 나눠지는게 아님. 다차원 벡터임.
  • 누구든지 영역별로 다양한 수준의 전문성을 갖추고 있음.
• 문서자료 갱신하기
  • 무언가를 막 배운 순간: 문서자료에서 개선점 찾기 가장 좋은 때
  • 구글에선 모든 엔지니어에게 갱신 권한이 있다고 생각
    • 문서자료 버그 리포트도 문서 자체에서 가능하도록
  • 어느정도 숙달되어 스스로 새로운 개발 흐름을 만들었다면 직접 문서자료 만들어보고, 발견되기 쉽게 위치시키자

존중 + 지식공유

• 초심자에게 버티기 가혹한 환경이 되지 않으려면 상냥하게…
• 모든 리더십이 기술 문제와 관련된것은 아니다.
  • 리더는 주위 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크/협업문화 조성, 팀 내 긴장을 해소하고, 회사를 더 활기차고 신나는 일터로 가꿔야 한다. 소위 말하는 ‘괴짜 개발자’가 좋은 리더가 아니다.

표준 정보소스

• 개발자 공식 가이드: 깊이 있는 공식 가이드.
  • 코딩 스타일 가이드, 공식 SW엔지니어링 모범사례, 코드 리뷰 가이드, 테스트 가이드
• go/ 링크: 짧기 때문에 대화 중에도 공유하기 쉽다. (”go/표준동의모듈을 확인해봐!). 공유할 때 드는 노력이 적음. (우리 슬랙의 ?표준동의모듈이랑 비슷할듯). 사람들이 직접 자주 생성할 수 있도록 해야함.
• 정적 분석 도구: 코딩 가이드나 모범 사례를 적용해 개선가능한 코드를 자동으로 코드 작성자에게 제안
• 뉴스레터: 화장실에 한 쪽짜리로 붙여도 됨 ㅎㅎ. 이닦으면서 볼 수도 있겠네.

가독성 제도: 코드 리뷰를 통한 표준 멘토 제도

• 프로그래밍 언어 모범 사례를 전파하기 위함.
  • 코드 개선 방법부터 공백 규칙에 이르기까지..
• 가독성 인증 프로세스: 해당 언어의 가독성 자격증이 있는 누군가(1~2%의 구글 엔지니어)가 코드리뷰를 필수로 해줘야함.
  • 명확하고 관용적이고 유지보수하기 쉬운 코드를 일관적으로 작성.
  • 표준화와 개인화가 융합된 방식의 지식 확장 수단
  • 코드의 기대 수명을 늘려야 할 때 필요.
    • 가독성 인증을 받은 PR은 그렇지 않은 PR보다 파악하는 시간이 평균적으로 훨씬 짧음.
  • 구글은 정적 분석에 꾸준히 투자해서 가독성 리뷰어들이 더 고차원적인 문제게 집중할 수 있도록 지원.

Ch.4 공정 사회를 위한 엔지니어링

• 요즘 토스에서 하는 product ethics 원칙 생각나는구먼

의도치 않게 내가 불평등에 기여하고 있다고?

• 취약계층 사람들을 보호하지 못하는, 외려 해를 끼치는 SW를 만드는걸 경계해야함!
  • 세계 영향을 미치는 결정권자 / 결정 받아들일 수 밖에 없는 사람들 힘균형 계속 무너지고 있기 때문. 거기에 일조하지 말자.
• 우리 자체의 대표성을 이해해야 의도치 않은 피해를 피할 수 있음.
  • 자신을 솔직하게 바라보고 성찰하자.
  • 나는? 컴공/여성/아시안/정규직 등등..
• 정의는 노력 없이 오지 않는다
  • 무언가를 만들어야할 때와 아닐 때를 구분할 수 있는 안목
  • 부정적인 결과를 낳을 제품을 거부할 수 있는 용기 (어려운 목표임. 개인주의자가 높은 성과 내는 엔지니어 되기 쉽기 때문)
    • 기꺼이 출시일을 미룰 수 있는 결정

힘숨찐

• 엔지니어는 본인 상상 이상으로 사회를 변화시킬 힘이 있음;
  • 훌륭한 엔지니어가 되기 위해 힘을 발휘하되 해를 끼치지 않아야 하는 책임도 있음.
  • 포커스온임팩트 한답시고 많이쓰이는 기술을 먼저 만들어낸다면
    • 기술을 접하기에 유리한 사람에게 우선권을 줌으로써 불평등을 가중할 수 있음 → 어렵구먼

채용 다양성만 해결하면 되나? No.

• 채용만 다양성있게 하면 될까?
  • 노노. 이후도 중요. 승진과 고용유지도 봐야함(구글에선 흑인엔지니어들이 다른 모든 그룹의 이직율보다 높았음)
• 팀이동시 기존 평가를 오픈(+강조)하는게 맞을까? 챌린지 들어옴
  • 분석해보니, 낮은 평가 받았던 직원이 팀 이동 후 평가가 좋아졌음 (낮은 평가 한번도 안받았던 직원만큼 평가 좋아짐)
  • 이 분석은 오랜 시간이 걸렸지만 팀이동 프로세스의 공정성을 개선하는데 기여함.