안녕하세요 오늘 소개할 책은 구글 엔지니어는 이렇게 일한다 ! 입니다
일단 제목부터 어그로가 상당하죠? 제목부터 안 살 수가 없어 ㅠ

((짤 2))

자 여러분들의 시간은 소중하니까 일단 시작합시다.

((짤 3))

Ch.1 소프트웨어 엔지니어링이란?

일단 이 책의 첫장은 SE 과 프로그래밍의 차이부터 짚고 넘어가는데요

((짤 4))

프로그래밍과 소프트웨어 엔지니어링의 가장 큰 차이

시간, (규모)확장, 실전에서의 트레이드 오프

구글에서는 이따금 "SE는 흐르는 시간 위에서 순간순간의 프로그래밍을 모두 합산한 것이다" 라는 말이 있는데요

((짤 5))

프로그래밍 작업: (개발 development)
SE 작업: (개발 development + 수정 modification + 유지보수 maintenance)
여기에 시간이라는 요소가 더해지면서 프로그래밍에는 중요한 차원때문에 더 입체적으로 진화 ! 하는거죠

((짤 6))

우리가 코드를 보고 이런 말을 할 수 있습니다. 이 코드의 예상 수명은?
몇분 후 사라질 코드부터 수십 년을 살아남을 코드까지 다양한 경우가 있다.

SE 와 프로그래밍을 가르는 핵심은 이 사실을 인식하는데서 시작합니다.

이 사실은 바로
우리가 말하는 소프트웨어의

((짤 7))

지속 가능성 sustainability

기술적인 이유든 사업적인 이유든,
SW 의 기대 생애 동안 요구되는
모든 가치 있는 변경에 대응할 수 있다면
"그 프로젝트는 지속 가능하다" 라고 말한다.

((짤 8))

의사결정의 복잡성과 이해관계 측면에서도 프로그래밍과 차이가 나요
SE에서는 주기적으로 여러 선택지 사이의 트레이드오프를 평가해야해요.
때로는 불완전한 지표에 기대어 결과에 커다란 영향을 주는 선택을 해야합니다.
SE 혹은 리더는 지속 가능성을 잃지 않으면서 조직, 제품, 개발 워크플로의 규모를 확장하는 비용을 관리해야 합니다

((짤 9))

이러한 사실을 주지하고 트레이드오프를 평가하여 합리적인 결정을 내려야하고
때로는 유지보수에 도움되는 변경을 연기하거나 심지어 확장성이 떨어지는 정책을 받아들여야 할 때도 있어요
이러한 결정은 훗날 다시 검토해야 할 수 도 있을을 잊지 말아야하며, 이 결정 때문에 생긴 지연 비용을 정확히 계산해두어야 해요. 엄청 할게 많죠?

((짤 10))

1.1.1 하이럼의 법칙

API 사용자가 충분히 많다면 API 명세에 적힌 내용은 중요하지 않습니다. 시스템에서 눈에 보이는 모든 행위(동작)를 누군가는 이용하게 될 것이기 때문이다.

하이럼의 법칙은 최선의 의도, 최고의 엔지니어, 꼼꼼한 코드 리뷰가 뒷받침되더라도 공표한 계약(명세)이나 모범 사례를 완벽하게 구현해냈다고 단정할 수 없다는 현실을 표현 한 말.
API 소유자가 인터페이스를 명확하게 설명해놓으면 어느 정도의 유연성과 자유를 얻을 수 있다. 하지만 현실에서는 API 사용자가 없는 기능을 찾아 활용하기도 한다.

그 기능이 유용해서 널리 쓰이면 추후 API 를 변경하기 어렵게 된다.

문맥에 따라 의역을 하자면 이렇습니다. API를 사용하는 사용자가 많아지면 API 문서에 뭐라고 적어두었는지는 더 이상 크게 중요하지 않다는 것을 의미합니다. 사용자가 API를 사용하면서, API 통해 기대하는 동작이 있을 것이고 이것들이 모여 API 문서와는 별개로 '암묵적인 인터페이스 규약'이라는 것이 생깁니다.

여기 예시가 있습니다.

((짤 11))

1.1.2 사례 : 해시 순서

해시 함수를 내가 만들었는데 버그가 있어요
해시 반복 순서가 무작위임을 눈치챈 누군가 사용자가 이를 난수 발생기로 사용할 수 도 있기 때문에, 이제 내가 무작위성(버그)를 제거하면 이 개발자(사용자)의 코드가 오작동할 것 !

결국 우리는 이 '암묵적인 인터페이스 규약'조차도 지킬 수 있어야 한다고 말합니다. 암묵적이어도 규약이기 때문입니다. 그리고 만약 API에 버그가 있었다면 이를 그냥 수정하고 문서만 바꾸기만 해서는 안 된다고 합니다. 더 나아가 구글에서는 버그를 위한 버그 하위 호환성도 지킬 수 있어야 한다고 말합니다.

하이럼 법칙은 사용자 수가 많고, API 가 노출되는 모든 곳에서 발생할 수 있다고 말합니다. 하이럼 법칙 때문에 확장이나 축소가 어려워지는 경우도 많이 셍깁니다. 그리고 확장 축소와 관련해서 하이럼 법칙이 문제가 되었던 실제 사례를 중간중간 많이 이야기하고 있습니다. 그렇기 때문에 하이럼 법칙을 API deprecation 이나 수정하기 어려운 이유 중 하나로 들고 있습니다.

((짤 12))

동작한다 : it works
옳다 : it is correct
는 다르다

"당장 돌아가야한다"
"언제까지고 작동해야 한다" 코드 차이

임시방편적인 혹은 "기발한" 코드
클린하고 유지보수 "가능한" 코드

우리는 "기발한" 이 칭찬으로 느껴진다면 프로그래밍이라고 하고
질책으로 느껴진다면 SE 라고한다.

((짤 13))

비욘세 규칙: "네가 좋아했다면 CI 테스트를 준비해뒀어야지" !

"인프라를 변경하여 서비스가 중단되는 등의 문제가 발생하더라고, 문제가 CI continuous integration 시스템의 자동 테스트에서 발견되지 않는다면 인프라팀의 책임이 아니다" 라는 정책

((짤 14))

규모확장과 효율성

• 전문성: 여러방법에 대한 충분한 지식이 있었습니다.
• 안정성: 더 규칙적으로 릴리스 하여 릴리스 사이의 변경량을 줄였습니다.
• 순응: 업그레이드를 겪지 않은 코드가 많지 않습니다. 규칙적인게 도움이 됨
• 익숙함: 업그레이드를 정기적으로 수행해서 중복되는 작업을 찾고 자동화 노력,
• 정책: 비욘세 규칙과 같은 유용한 정책과 절차를 갖춥니다.

((짤 15))

원점 회귀 (왼쪽으로 옮기기)

문제 발견 시점을 왼쪽으로 이동시킬수록 수정 비용이 줄어든다는 얘기

비용을 정확히 짚어줍니다
비용은 비단 돈 뿐만을 지칭하는것이 아니죠

• 금융 (예: 돈)
• 레소스 비용 (예: CPU 시간)
• 인적 비용 (예: 엔지니어링 노력)
• 거래 비용 (예: 조치를 취하는 비용)
• 기회 비용 (예: 조치를 취하지 않는 비용)
• 사회적 비용 (예: 선택이 사회 전체에 미치는 영향)

구글이 얼마나 비용효율적이게 일하는 가를 보여주는 가벼운 사례가 있어요

((짤 16))

사례 : 화이트보드 마커

많은 조직에서 화이트보드 마커는 귀중하게 대접받습니다. 엄격하게 관리되며 항상 공급이 부족하죠.
맨날 찾으면 없고 필요하면 없고, 찾으면 절반은 말라있어서 잘 안나오고, 잘 그리다 갑자기 안나와서 회의 흐름 끊기고, 이런 경험 없나요?

((짤 17))

없다면 당신은 진정한 디지털 MZ 세대?! 빠밤! ,, 장난이구요

그래서 구글 사무실 대부분 마커가 넘쳐나고 어디든 약간 서울의 편의점 마냥 어딜가든 찾을수 있게 많이 비치되어있다,
끊김 없는 브레인스토밍이 누군가 마커를 찾아 헤매는 일보다 훨씬 중요하기 때문이죠.

((짤 18))

드디어 파트 2 입니다. 바로 문화 입니다.

문화

그리고 첫 단원은 팀워크이죠

((짤 19))

사람들은 자신이 진행중인 작업물을 다른사람이 보고 판단하는 걸 두려워합니다.

아마 인간의 본성에 속할수도 있습니다.

((짤 20))

누구라도 비난받고 싶어 하지 않으며,
작업물이 완성도기 전이라면 더욱 그렇습니다.

이 책의 저자는 불안감을 멀리하라고 합니다.
불안감은 사실 더 큰 문제의 지후입니다.

천재신화

((짤 21))

리누스 토발스,
귀도 반 로셈
빌 게이츠
SE 계의 아이돌이죠,

((짤 22))

리눅스를 만들고 파이썬을 만들었다는 유명한 천재 신화이죠
하지만 첫 부분만 만들고 나머지는 수천명의 아이디어를 모으고 기능개발하고 수정하며 만들었습니다.
인간은 본능적으로 리더와 롤모델을 찾고 그들을 우상화하고 흉내내려합니다.

((짤 23))

내면 깊숙한 곳에서 많은 엔지니어가 자신이 천재로 비치기를 원합니다.
그 환상이 실현되는 시나리오는 대략 다음과 같습니다.

• 굉장히 새로운 개념이 떠오릅니다.
• 몇 주 혹은 몇 달 동안 동굴로 사라져서 이 아이디어를 완벽하게 구현해봅니다.
• 완성된 소프트웨어를 세상에 공개하여 여러분의 천재성에 모두가 충격을 받습니다.
• 동료들이 여러분의 영리함에 놀라움을 금치 못합니다.
• 여러분의 소프트웨어를 사용하려는 사람들이 물밀듯 몰려듭니다.
• 명성과 부는 자연스럽게 따라옵니다.

((짤 24))

현실은,,, 여러분은 분명히 매우 똑똑한 사람일거에요
까다로운 코딩도 잘하고 근데 천재들도 실수를 해요.
그리고 더 중요한건
"사람들에게 가치 있는 문제" 가 아닌
"분석 자체에만 의미를 두는 문제" 일 가능성이 높아요,

이것을 위한 빌드업이였습니다

((짤 25))

숨기는 건 해롭다

우리는 우리가 올바른 일을 하고 있는지, 제대로 하고 있는지, 그리고 다른 누군가가 이미 해놓은 일은 아닌지를 확인해봐야합니다.
"초기" 단계에서 이런 실수를 범할 확률은 상당히 높습니다.
그래서 피드백을 조기에 받을수록 이러한 위험이 크게 줄어듭니다.

검증된 주문입니다.

((짤 26))

일찍 실패하고, 빨리 실패하고, 자주 실패하라

너무 진지했나요?
이번에는 좀 재미있는 내용같아서 가져와봤습니다

((짤 27))

The bus factor

Bus factor 란

((짤 28))

"프로젝트 멤버 중 일부가 갑작스럽게
버스에 치여서 입원해야하느라
프로젝트를 하게 될 수 없는 경우,
몇 명까지 버스에 치여도
프로젝트가 중단되지 않을 수 있는가?"

입니다.

다시말해 프로젝트가 중단되지 않고 유지될 수 있게 하는 사람의 수가 몇이냐라는 의미입니다.

bus라고 하길래 롤에서 말하는 bus를 의미하는 줄 알았는데 실제 물리적인 버스를 의미하더라고요.

책에서 bus factor를 설명하면서 이야기하는 요점은 간단합니다. bus factor를 늘리라고 합니다. 프로젝트의 모든 짐을 혼자 감당하는 슈퍼 개발자가 되려한다면 프로젝트가 좌초될 확률이 높다 합니다. 그리고 bus factor 를 높이기 위해 본인이 가진 지식과 노하우를 팀원들에게 공유해서 분담하라고 말합니다.

결론은 ! 숨기지 말자

((짤 29))

홀로 일하기는 함께 일하기보다 본질적으로 더 위험합니다.

잘못된 일에 여러분의 천금 같은 시간을 낭비할 가능성을 더 걱정해야합니다. !

사회적 상호작용의 세 기둥

((짤 30))

위대한 소프트웨어를 만드는 최선의 길이 팀워크라면 위대한 팀은 어떻게 만들어야 할까요?
혹은 어떻게 하면 찾을 수 있을까요?

협업의 레베루에 올라가려면 가장 먼저 사회적 스킬의 세 기둥을 익혀야 합니다.

겸손: 당신과 당신 코드는 우주의 중심이 아닙니다. 당신은 모든 것을 알지도 완벽하지도 않습니다 겸손한 사람은 배움에 열려 있습니다.
존중: 함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다.
신뢰: 동료들이 유능하고 올바른 일을 하리라 믿습니다 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.

자존심 버리기

겸손은 중요하지만 바짝 엎드리라는 뜻은 아닙니다
자신감 좋습니다 그러나 모든걸 다 아는 듯 행동하지 말라.
'집단적'자존심을 찾으세요
자신보다 팀의 성취와 단체의 자부심을 높이려 노력하세요

비난 없는 포스트모템 문화

사후처리라는 뜻입니다.

((짤 31))

빠르게 실패하고 반복하기
구글의 좌우명 '실패는 선택이다'
실패의 근본 원인을 분석하여 문서로 남기는 것이 실수로 부터 배우는 핵심이다. (aka 포스트모템)
포스트모템에는 무엇을 배웠는지와 배운것을 토대로 무엇을 바꿀지를 담아야한다. 제대로된 실패의 기록 = 히스토리 + 똑같은 실수 방지

• 사건의 개요
• 사건을 인지하고 해결에 이르기까지 타임라인
• 사건의 근본 원인
• 영향과 피해 평가
• 문제를 즉시 해결하기 위한 조치 항목

드디어 챕터 3 입니다. 지식공유에 관한 건입니다.

챕터3 지식공유

((짤 32))

배움을 가로막는 장애물

• 심리적 안전 부족 ( 불이익때문에 질문하기를 주저하는것 등)
• 정보 섬 (지식이 파편화되는것) 팀마다 공유안하고 따로 작업
  • 정보 파편화, 정보 중복, 정보 왜곡
• 단일 장애점 (중요한 정보를 한명이 독점)
• 전부 아니면 전무 전문성 (조직원이 모든 것을 아는 사람과 아무것도 모르는 초심자로 나뉨)
• 앵무새처럼 흉내내기 (잘은 모르겠지만 이게 맞겠거니..)
• 유령의묘지 (우리 코드 결제쪽 같은.. 손대기를 기피하는 영역)

판 깔아주기 : 심리적 안전

((짤 33))

심리적 안전은 학습 환경을 조성하는데 매우 중요합니다.
모름을 인정하는 문화가 필요합니다.
무지를 탓하지 말고 그 솔직함을 반겨야합니다.

((짤 34))

배움에는 '무언가를 시도하다가 실패해도 안전하다'는 인식이 엄청나게 중요한 환경입니다.
심리적 안전이 효과적인 팀을 이루는데 가장 중요해요!

큰 그룹에서의 심리적 안전
안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화이다.

((짤 35))

전 이거 좀 웃겼던거 같아서 통째로 집어넣었어요.

내 지식 키우기

지식 공유는 여러분으로부터 시작됩니다.
항상 무언가 배울게 있음을 인식하는 게 중요합니다.

((짤 36))

1. 질문하기
   항상 배우고 항상 질문하세요.
   모르는 분야가 나오면 두려워하지말고 성장하는 기회로 받아들이세요
2. 맥락 이해하기
   새로운 것 뿐 아니라 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함됩니다.

((짤 37))

문서화 촉진하기

문서 작성에 드는 시간과 노력이 있으나 코딩할 시간을 뺏길때도 있죠
그러나 N명에게 질문에 답하는 시간보다 하나의 문서가 더 시간 절약하는 것입니다.
문서화는 팀과 조직의 규모를 키우는데도 보탬이 됩니다.

((짤 38))

코드

코드도 지식에 해당하므로 코딩은 지식을 옮겨 적는 행위로 간주할 수 있어요.
코드 문서화는 다른 형태의 지식 공유 수단입니다.
자기 자신을 포함한 미래의 독자를 위해 정확하게 기록하세요.

((짤 39))

지식을 공유할 때는 상냥함과 존중을 담아야 합니다.
뛰어난 괴짜를 용인하는 것은 해롭습니다.
상냥한 전문가도 얼마든지 가능합니다.

((짤 40))

지식은 형태는 없으나 많은 측면에서 소프트웨어 엔지니어링 조직의 가장 중요한 자산입니다.
지식 공유는 조직에 탄력을 불어넣어 변화에서 생존할 수 있는 역할을 합니다.
지식을 쉽게 공유하는데 투자한 노력은 회사의 생애 동안 몇 배로 돌려받는다.