본 내용은 구글 엔지니어는 이렇게 일한다(링크)를 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.

  • 조직은 자신의 문제 대부분에 스스로 답할 수 있어야 한다.
  • 조직에 배움의 문화가 자리 잡혀야 한다.
  • 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다.

구글은 규모가 커지면서 이런 문제들을 겪었다.

  • 불이익이 두려워서 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경

  • 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화된다.
  • 정보 파편화: 섬마다 서로 다른 그림을 그리고 그마저도 불완전하다.
  • 정보 중복: 섬마다 나름의 작업 방식을 재창조한다.
  • 정보 왜곡: 같은 일이라도 섬마다 작업 방식이 다르고, 심지어 충돌하기도 한다.

  • 중요한 정보를 한 사람이 독점하면 병목이 생긴다.

  • 조직 구성원이 '모든 것을 아는' 사람과 '아무것도 모르는' 초심자로 나뉜다.
  • 지식과 책임은 계속 이미 전문가가 된 사람들에게 집중된다.
  • 새로운 팀원이나 초심자들은 그들만의 울타리에 갇혀 느리게 성장하게 된다.

  • 이해하지 못한 상태로 흉내만 내는 것
  • 목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라한다.

  • 무언가 잘못될 게 두려워서 아무도 손대지 않는 영역
  • 두려움과 비합리적인 의심 때문에 사람들이 손대기를 기피하는 영역

  • 소프트웨어 엔지니어링에서 가장 중요한 요소는 사람

  • 그 어떤 전문가도 한때는 초심자였다.

  • 조직의 성패는 인력에 얼마나 투자해서 얼마나 잘 키워내느냐에 달려 있다.

  • 전문가의 일대일 조언

    • 개개인이 특정 분야에서 최고의 조언자가 될 수 있다.
    • 전문가 개인이 부재중일 경우 어려움이 있을 수 있다.

  • 문서화된 지식

    • 많은 사람들이 참여하여 자신들의 전문성을 더 큰 그룹과 공유할 수 있다.
    • 대부분 일반적인 상황을 다루므로 개별 학습자의 특수 상황에서는 부적합하다.

  • 현장 지식(contextual knowledge)

    • 위의 두 개념의 절충적 개념
    • 팀원 개개인의 지식과 문서화된 정보 중간 어딘가에 존재
    • 문서화된 지식과 상호 보완

  • 심리적 안전은 학습 환경을 조성하는 데 매우 중요.

  • 타인의 무지를 탓하지 말고 그 솔직함을 반겨야 한다.

  • 배움에는 '무언가를 시도하다가 실패해도 안전하다'는 인식이 엄청나게 중요

  • 건강한 환경에서라면 사람들은 질문을 던지고. 틀리고. 새로운 지식을 얻는 걸 편안하게 생각한다.

  • 구글에서 멘토의 공식 역할은 궁금한 점에 답해주고 신입의 성장을 돕는 것
  • 신입이 속한 팀의 팀원이나 관리자 혹은 테크 리드는 멘토에서 제외
  • 동료나 상사의 시간을 뺏는 건 아닐지 걱정하는 마음을 덜 수 있다.

  • 그룹의 모든 구성원이 안전한 환경을 만들고 유지하는 역할을 함께 해줘야 한다.
  • 신규 입사자는 부담 없이 질문할 수 있게 해준다.
  • 성장 중인 전문가는 기존 전문가들이 자신의 답변에서 허점을 찾아 공격할지 모른다는 두려움 없이 도움의 손길을 내밀 수 있다.
  • 안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화

"뭐라고?! 스택이 뭔지 모른다니 믿을 수가 없네!"

  • 거짓된 놀람은 심리적 안전을 방해
  • 모른다는 사실을 인정하기 두렵게 된다.

지나칠 정도로 세세하게 고쳐주는 행위는 정밀성보다는 자신을 뽐내려는 무의식에 기인하는 경향이 있다.

토론 중에 적절한 발언권 없이 끼어들어 의견을 제시하지 말라.

"이건 우리 할머니도 할 수 있겠네!"

인종주의, 연령주의, 동성애 혐오 발언 같이 편견이 깃든 표현은 다른 이에게 불편함과 무례함, 불안함을 느끼게 한다.

  • 지식 공유는 여러분으로부터 시작한다. 항상 무언가 배울 게 있음을 인식하는 게 중요하다.
  • 자신의 지식을 강화하는 데 도움되는 지침 두 가지를 알아보자.

"항상 배우고 항상 질문하라!"
  • 질문하라. 여러분의 동료가 가장 훌륭한 정보 소스일 경우가 많다. 낮은 수준의 질문이라며 지레 겁 먹거나, 혼자 해결하려 들지 마라.
  • 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들여라.

  • 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함
  • 체스터슨의 울타리 원칙: "무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자"
  • 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해야 한다.
  • 코드의 목적과 맥락을 이해하고, 그런 다음 변경하려는 방향이 여전히 더 나은지 고민해야 한다.

  • 무언가를 일 대일로 배울 때는 '기록하는 습관'을 길러라.
  • 더 큰 커뮤니티에 도움을 청하는 것도 좋다.
  • 커뮤니티의 전문가에게 도움을 받을 수 있고, 기록되어 미래 구성원들에게까지 폭넓게 공유된다.

  • 누구에게 물어봐야 할 지 모르겠을 때
  • 대화 내용을 자동으로 보관해주니 아카이빙도 가능
  • 간단한 질문에 적합
  • 체계화된 구조가 있지 않아서 적극적으로 참여하지 않은 대화에서는 의미 있는 정보를 얻기 어렵다.

  • 공개 메일링 리스트에 질문을 던지면 구독중인 모두가 질문이 전달되고 답변하고, 배울 수 있다.
  • 메일 내용은 검색 가능한 아카이브로 보관
  • 맥락 정보가 많이 필요한 복잡한 질문에 적합
  • 그룹 채팅처럼 빠르게 주고받는 대화에는 취약
  • 오래전 스레드에서 얻은 해답이 오늘날의 환경에서도 여전히 유효할지는 알기 어렵다.

  • 가르친다는 건 전문가의 전유물이 아니다.
  • 전문성이라는 게 '초심자 아니면 전문가'처럼 이분법적으로 나눠지지도 않는다.
  • 전문성은 다차원 벡터입니다. 누구나 영역별로 다양한 수준의 전문성을 갖추고 있다.

누군가가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트

  • 지식 공유를 목적으로 오피스 아워를 최우선으로 활용하는 경우는 거의 없다.
  • 분명한 것은 오피스 아워가 전문가와 직접 대면할 기회를 제공한다는 사실

  • 무언가를 막 배운 순간이 기존 문서자료에서 개선점을 찾기에 가장 좋은 때
  • 구글에서는 문서자료 소유자가 누구든 모든 엔지니어에게 갱신 권한이 있다고 여긴다.

  • 숙달되면 자신만의 문서자료를 작성하고 기존 문서자료들을 갱신하라.
  • 새로운 개발 흐름을 만들어냈다면 그 단계들을 설명하는 문서자료를 작성하라.
  • 다른 사람에게 공유하여 여러분이 걸어간 길을 쉽게 따라오도록 하라.
  • 내용이 낡거나 틀렸을 때 소유자에게 알릴 수 있게 하거나, 직접 고칠 수 있게 하라.

  • 문서화는 소수가 시간을 들여 다수에게 이득을 주므로 조직 전체에 도움을 준다.
  • 기본적으로 기여자와 수혜자가 달라서 적절한 보상 없이는 사람들을 움직이게 하기 어렵다.
  • 같은 문제로 팀원들이 계속 찾아올 때 문서를 공유하기만 한다면 해결될 수 있으니 도움이 되기도 한다.
  • 팀과 조직의 규모를 키우는 데도 보탬이 된다.
    • 문서자료에 담긴 정보는 기본으로 참고해야 할 표준이 된다.
    • 표준을 팀 외부로 확산시킬 수도 있다.

  • 코드 문서화는 또 다른 형태의 지식 공유 수단이다.
  • 깔끔한 문서자료는 라이브러리 이용자는 물론 향후 라이브러리를 유지보수하는 이들에게도 큰 혜택을 준다.
  • 코드 내의 주석은 지식을 미래로 전달한다.
  • 트레이드오프: 코드 주석도 적극적으로 관리하지 않으면 금세 낡은 지식이 되어 코드와 모순되는 정보 때문에 혼란을 겪을 수 있다.
  • 코드 리뷰는 코드 작성자와 리뷰어 모두에게 배움의 기회를 준다.

  • 조직이 커질수록 전문 지식을 조직 전반에 제대로 공유하기가 어려워진다.
  • 표준 정보 소스 같은 것들은 조직이 커질수록 혜택도 커진다.

구글은 코드 같은 산출물보다 문화와 환경을 첫 번째로 두고 생각해야 더 나은 결과를 얻는다고 믿는다.

  • 지식을 공유할 때는 상냥함과 존중을 담아야 하고, 또 그래야만 가능하다.
  • 기술 업계에서는 '뛰어난 괴짜'를 용인하는(심지어 숭배하는) 경향이 있지만, 해로운 현상이다.
  • 상냥한 전문 가도 얼마든지 가능하다.

  • 좋은 문화는 적극적으로 육성해야 하며 지식 공유 문화를 장려하려면 인정과 보상 제도가 뒷받침되어야 한다.
  • 사람들은 진부한 칭찬보다는 확실한 보상에서 동기를 얻는다.
  • 말로만 하지 말고 보상과 수상 제도를 통해 실질적인 혜택을 주어야 하는 이유

  • 표준 정보 소스는 회사 차워의 중앙집중적 정보 원천
  • 표준화하고 전파하는 수단
  • 개별 부서나 개인들이 각자의 정보를 생성해 활용하다 보면 서로 충돌하거나 파편화되기 마련인데, 표준 정보 소스로 이런 문제를 막을 수 있다.
  • 표준 정보는 조직 차원에서 합의한 내용을 제공하고 눈에 잘 띄기 때문에 해당 분야 전문가들이 적극적으로 관리하고 감독해야 한다.
  • 복잡한 주제일수록 소유자를 명확히 정해둬야 한다.

  • 구글은 엔지니어들을 위해 깊이 있는 공식 가이드를 만들어 활용
  • 전문가는 회사 차원의 방침을 개인적으로 설명해주지 않아도 되므로 시간이 절약
  • 배우는 사람은 필요하면 언제든 신뢰 가는 정보를 찾아볼 수 있는 정보 소스가 있음을 알게 된다.
  • 전문가들이 공통의, 확장하기 쉬운 자원을 활용하여 특정한 정보의 필요성을 인지하고 해결하고, 지식이 확장

  • 구글 사내 단축 링크 서비스
  • 키워드를 중심으로 검색과 공유에 용이

  • 동작하는 예시 코드, 설명, 코딩 연습문제 등을 활용
  • 엔지니어에게 새로운 개념이나 프로세스를 가르치는 실습형 튜토리얼
  • 관리 비용이 많이 들며 학습자 개 인의 특수한 요구에는 대응하지 않는다.

  • 검사 로직을 자동화할 수 있는 모범 사례들을 공유하는 강력한 수단
  • 목적: 개선할 수 있는 코드를 찾아서 코드 작성자나 리뷰어에게 알려주는 것
  • 정적 분석 도구를 설정하기가 조금 까다롭겠지만 한 번 설정하고 나면 확장하기는 쉽다.
  • 엔지니어 개개인의 지식을 강화해주며, 조직 차원에서는 더 많 은 모범 사례를 더 일관되게 적용

  • 전달하려는 지식의 중요도에 따라 정보 공유 매체가 '얼마나 공식적이어야 하는가' 에 대한 기대치가 다르다.
  • 공식 문서는 항상 최신 싱태로 유지되기를 기대하지만, 뉴스레터에는 그런 기대를 하지 않기 때문에 더 편하게 관리할 수 있다.

  • 업무에 꼭 필요하지는 않지만 엔지니어들이 관심을 가질만한 정보를 유통하는 괜찮은 수단
  • 제공 빈도를 높이기보다는 내용을 더 유용하고 흥미롭게 채워야 효과적
    • '화장실에서도 테스트(Testing on the Toilet; TotT)'(테스트 팁)와 '화장실에서도 학습(Learning on the Loo)'(생산성 팁)
    • 독특한 전달 형태 덕에 다른 뉴스레터와 차별화

  • 다양한 분야에서 주제를 중심으로 다른 부서의 구글러들과 커뮤니티를 형성해 지식을 공유
  • 열린 소통 채널 덕분에 소속 팀이나 가까운 동료 외의 수많은 전문가 로부터 무언가를 배우기가 더 수월
  • 정보 섬과 중복 문제도 피할 수 있다.

  • 프로그래밍 언어 모범 사례를 전파하기 위한 구글 전사 차원의 '표준 멘토링 프로세스'를 지칭
  • 신규 입사자에게 모범 사례를 가르치고, 어떤 공유 인프라를 활용할 수 있는지 알려줬으며, 구글에서의 코드 작성이란 어떤 것인지를 보여주며 시작

  • 구글에서 코드 리뷰는 필수
  • 모든 변경 목록(ChangeLog; CL)은 가독성 승인을 얻어야 한다.
  • 구글은 덩치가 너무 커져서 코드 리뷰만으로는 모든 엔지니어에게 모범 사례들을 충분히 엄격하게 가르치는 게 불가능. 그래서 가독성 승인이 추가
  • 가독성 제도는 표준화와 개인화가 융합된 방식의 지식 확장 수단

  • 지식은 비록 형태는 없을지라도 많은 측면에서 소프트웨어 엔지니어링 조직의 가장 중요한 자산
  • 지식 공유야말로 조직에 탄력을 불어넣어 변화에 직면해서도 생존할 수 있도록 하는 데 결정적인 역할
  • 대부분 지식을 쉽게 공유하는 데 투자한 노력은 회사의 생애 동안 그 몇 배로 돌려받는다.