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

(책을 읽으며 느낀 개인적인 사견이 회색 글씨로 작성되어 있습니다.)

 

3장 지식공유

조직 내에는 질문의 답을 아는 전문가들이 필요하고 그들의 지식을 전파할 메커니즘도 필요합니다. … 가장 중요한 사실은 조직에 배움의 문화가 자리 잡혀야 한다는 것이고, 그러려면 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야합니다.

3.1 배움을 가로막는 장애물

• 심리적 안전 부족
  • 불이익이 두려워 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경
  → 숨기는 것이 안전해지는 것이 아니라, 분명 드러나게 되어 더 큰 문제가 되어 돌아옴을 잊지 말 것 
  
• 정보 섬
  • 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아 지식이 파편화 됨
  • 이런 환경에서 일하는 방식을 각각의 부서가 제각기 만들어 나가다보면,
    • 정보 파편화
      • 섬마다 서로 다른 그림을 그리고 그마저도 불완전합니다.
    • 정보 중복
      • 섬마다 나름의 작업방식을 재창조합니다.
    • 정보 왜곡
      • 같은 일이라도 섬마다 작업 방식이 다르고, 심지어 충돌하기도 합니다.
• 단일 장애점
  • 중요한 정보를 한 사람이 독점하면 병목이 생깁니다.
  • 버스 지수와도 관련
  • ‘가르쳐주는 리소스가 드니까 내가 해야지’ → 장기 확장성 희생
  → 이전 회사에서 온갖 사소한 트러블 슈팅들을 직접 해결 해드리다보니 정작 나의 일을 할 시간이 없는 것을 깨닫고 자주 발생하는 이슈들에 대한 문서를 만들어 공유함
  → 많은 시간과 비용이 들었음은 분명하나, 장기적으로는 스스로의 시간을 save 하여 그 시간을 더 나은 업무에 사용할 수 있었음
  
  
• 전부 아니면 전무 전문성
  • 조직 구성원이 모든것을 아는 사람과 아무것도 모르는 초심자로 나뉘게 되는 문제
  • 지식과 책임은 계속 이미 전문가가 된 사람들에게 집중되고, 새로운 팀원이나 초심자들은 그들만의 울타리에 갇혀 느리게 성장하게 됨
• 앵무새처럼 흉내내기
  • 이해하지 못한 상태로 흉내만 내는 것
  • 목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라함
  → 가장 바보가 되기 쉬운 길, 항상 경계해야 한다고 생각
  
  
• 유령의 묘지
  • 무언가 잘못될 게 두려워서 아무도 손대지 않는 영역(코드)

3.2 철학

소프트웨어 엔지니어링에서 가장 중요한 요소는 사람입니다. 코드는 중요한 산출물이지만 제품 개발 전체를 보면 작은 부분에 지나지 않죠. 결정적으로 코드는 무에서부터 자연 발생하는 것이 아니며, 전문 지식 역시 마찬가지입니다. 그 어떤 전문가도 한때는 초심자였습니다.

• 일대일로 이루어지는 조언은 매우 효과적이지만 확장성이 부족 → 팀이 커지면 유용하지 못함
• 문서화된 지식
  • 팀을 넘어 조직 전체로 퍼뜨릴 수 있음(ex, 팀 위키)
  • 하지만 대체로 일반적인 상황을 다루게 되어 개별 학습자가 처한 특수상황에는 부적합할 수 있음
  • 최신 정보 업데이트의 유지보수 비용 소모
• 현장 지식
  • 제대로 문서화되어 있지 않아, 관련 맥락을 알고 있는 핵심 멤버들 혹은 관계자들만 알고 있는 지식
• 현장지식과 문서화된 지식은 서로를 보완해줌

3.3 판 깔아주기: 심리적 안전

자신이 이해하지 못한 게 있음을 인정해야 무언가를 배울 수 있습니다.
그러니 우리 모두는 타인의 무지를 탓하지 말고 그 솔직함을 반겨야합니다.
…
배움에는 ‘무언가를 시도하다가 실패해도 안전하다’는 인식이 엄청나게 중요합니다.
건강한 환경에서라면 사람들은 질문을 던지고, 틀리고, 새로운 지식을 얻는 걸 편안하게 생각합니다.

→ 안좋은 습관 중에 하나가 모르는 것을 숨기거나 이해한 척 넘어가는 태도였는데, 스스로뿐만 아니라 함께 일하는 동료에게도 피해가 가는 일이라는 것을 깨닫고 솔직하려 노력하고 있음
→ 상대방의 리소스를 너무 낭비하게 된다고 생각이 들 때에는 차라리 혼자 이해하는 시간을 가져보는 것도 도움이 되었습니다.

3.4 내 지식 키우기

3.4.1 질문하기

‘항상 배우고 항상 질문하라!’

우리는 많이 알면 알수록 모르는 것이 더 많음을 깨닫게 됩니다. 
공개적으로 묻고 모르면 모른다고 인정한다면 다른 사람들도 점점 그렇게 변해갈 것입니다.

끈기를 가지고 상냥하게 답변해줘야 사람들이 안심하고 도움을 청하는 환경이 조성됩니다.

→ 개인적인 목표: 따뜻한 개발자가 되는 것 😇

3.4.2 맥락 이해하기

• 체스터슨의 울타리 원칙
  • 도로를 가로지르는 울타리가 있다.
    • 무슨 용도인지 모르니 깔끔하게 밀어버리자 → X
    • 용도를 모르겠다면 그냥 밀어버릴 수 없다. 용도를 알아내면 그 때 철거하자 → O
• ‘무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자’
• 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해보자
• 코드의 목적과 맥락을 이해하고, 변경하려는 방향이 여전히 더 나은지 고민해본다.
• 더 낫다고 판단되면 고치고, 그렇지 않다면 미래에 다시 그 코드를 볼 사람들을 위해 그렇게 생각한 근거를 적어두기

→ PR에 작성 중

3.6 지식 확장하기: 누구나 가르칠 게 있다

3.6.4 코드

코드리뷰는 코드 작성자와 리뷰어 모두에게 배움의 기회를 줍니다.

• 리뷰어의 제안으로 작성자는 새로운 테스트 유형을 깨닫게 됨
• 작성자의 코드에서 리뷰어는 새로운 라이브러리의 사용법을 학습

3.7 조직의 지식 확장하기

3.7.1 지식 공유 문화 일구기

• 존중
• 지식을 공유할 떄는 상냥함과 존중을 담아야 하고, 또 그래야만 가능합니다. … 상냥한 전문가도 얼마든지 가능하기 때문이죠.

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

• 구글에서의 ‘가독성 제도’는 단순한 코드 가독성 이상을 의미
• 프로그래밍 언어 모범 사례를 전파하기 위한 구글 전사 차원의 ‘표준 멘토링 프로세스’를 지칭
• 언어이디엄, 코드 구조, API 설계, 공통 라이브러리의 올바른 사용법, 문서화, 테스트 커버리지 등 전문 지식을 광범위하게 다룸