3. 지식 공유

조직 내에는 질문의 답을 아는 전문가들이 필요하고 그들의 지식을 전파할 메커니즘 필요
1. 조직에 배움의 문화가 자리잡혀야 한다.
2. 모르는 걸 인정할 수 있도록 돕는 심리적 안전(psychological safety)을 제공해야 한다.

1. 배움을 가로막는 장애물

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

• 정보 섬
  : 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화

  • 정보 파편화: 섬마다 서로 다른 그림을 그리고 그마저도 불완전합니다.
  • 정보 중복: 섬마다 나름의 작업 방식을 재창조 합니다.
  • 정보 왜곡: 같은 일이라도 섬마다 작업 방식이 다르고, 심지어 충돌하기도 합니다.

• 단일 장애점
  : 중요한 정보를 한 사림이 독점하면 병목현상이 일어남 ('버스지수'와도 관련)
  

• 전부 아니면 전무 전문성
  : 지식과 책임은 계속 이미 전문가가된 사람들에게 집중되고, 새로운 팀원이나 초심자들은 그들만의 울타리에 갇혀 느리게 성장
  

• 앵무새처럼 흉내내기
  : 무의식적으로 기존 패턴이나 코드 따라하기
  

• 유령의 묘지
  : 무언가 잘못될 게 두려워서 아무도 손대지 않는 영역(주로 코드)을 말합니다.

2. 철학

• 소프웨어 엔지니어링 : 여러 버전의 프로그램을 여러 사람이 참여해 개발하는 일
• 조직의 성패는 인력에 얼마나 투자해서 잘 키워내느냐에 달려있다.
• 문서화된 지식과 현장 지식 (상호보완적)
  • 문서화된 지식
    • 팀을 넘어 조직 전체로 유통 가능 (확장성이 좋다)
    • 최신 정보를 반영해야 하므로 유지보수 비용 증가
  • 현장 지식
    • 맞춤형 도움
    • 문서화된 지식보다 효과가 좋음

3. 판 깔아주기: 심리적 안전

• 타인의 무지를 탓하지 말고 그 솔직함을 반겨야 합니다.
• '무언가를 시도하다가 실패해도 안전하다' 인식
• 심리적 안전이 효과적인 팀을 이루는 데 가장 중요한 요인

3-1. 멘토 제도

• 누글러(신규 입사자)가 속한 팀의 팀원이나 관리자 혹은 테크 리드는 멘토에서 제외 (애매한 상황에서도 편하게 질문할 수 있도록!)
• 공식 멘토 지정시 마음 편히 질문 가능

3-2. 큰 그룹에서의 심리적 인연

권장 패턴	안티패턴
기초적인 질문과 실수를 올바은 방향으로 안내합니다.	기초적인 질문이나 실수를 가려내서 질문한 사람을 꾸짖습니다.
질문자가 배우게끔 도와줄 목적으로 설명합니다.	자신의 지식을 뽐낼 목적으로 설명합니다.
상냥하게 인내심을 갖고 도움이 되게끔 대응합니다.	잘난 체하고 비난하며 건설적이지 못한 방식으로 대응합니다.
해법을 찾기 위한 공개 토론 형식으로 상호작용이 이루어집니다.	'승자'와 '패자'를 가리는 논쟁 형식으로 상호작용이 이루어집니다.

• 거짓된 놀람 금지 ("뭐라고?! 스택이 뭔지 모른다니 믿을 수가 없네!")
• "음, 실제로는..."금지
• 뒷자석 운전 금지 (토론 중에 적절한 발언권 없이 끼어들어 의견제시 노노)
• 미묘한 '--주의' 금지 ("이건 우리 할머니도 할 수 있겠네!")

4. 내 지식 키우기

항상 무언가 배울 게 있음을 인식하는 게 중요합니다.

4-1. 질문하기

항상 배우고 질문하라!

• 초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것
• 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아드리세요.
• '상급자라면 모든 걸 알아야 한다'라는 인식이 생겨나지 않도록 주의하세요.
• 끈기를 가지고 상냥하게 답변해줘야 사람들이 안심하고 도움을 청하는 환경이 조성됩니다.
• '사소한' 질문이라도 답을 얻을 수 있도록 힘써주세요.

4-2. 맥락 이해하기

체스터슨의 울타리 : 무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자

5. 질문 확장하기: 커뮤니티에 묻기

• 기록하는 습관, 지록해둔 지식을 공유

5-1. 그룹 채팅

동시에 여러 사람에게 질문을 던질 수 있고 시간이 허락되는 사람끼리 빠르게 대화를 주고받으며 답을 찾기 때문이죠.

• 간단한 질문에 적합
• 본인이 적극적으로 참여하지 않은 대화에서는 의미 있는 정보 추출 불리

5-2. 메일링 리스트

잠재적으로 답을 줄 수 있는 수많은 사람에게 질문이 전달되고, 해당 메일링 리스트를 구독하는 모두가 그 질문으로부터 배울 수 있습니다.

• 맥락 정보가 많이 필요한 복잡한 질문에 적합
• 빠르게 주고 받는 대화에는 취약
• 오래전 스레드에서 얻은 해답이 오늘날의 환경에서도 여전히 유효할지는 알기 어려움
• 정식 문서 같은 다른 매체보다 불필요한 정보가 많이 섞여 있을 수 있다.

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

가르친다는 건 전문가의 전유물이 아니며, 전문성이라는 게 '초심자 아니면 전문가'처럼 이분법적으로 나눠지지도 않습니다.

6-1. 오피스 아워

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

6-2. 기술 강연과 수업

• 일반적으로 연사가 청중에게 직접 강의하는 형태로 진행
• 자주 오해를 일으킬 정도로 복잡한 주제를 다뤄야합니다. 수업은 개설 비용이 크므로 해결해야 할 분명한 요구가 있을 때 만들어져야 합니다.
• 주제가 비교적 안정적이어야 합니다. 수업 교재를 고치는 것도 큰일이므로, 내용이 자주 바뀐다면 다른 공유 형태를 찾아보는 게 나을 것입니다.
• 질문에 답해주고 일대일로 도와줄 수 있는 교사가 있어애 효과가 큰 주제여야 합니다. 직접적인 도움 없이 학생 스스로 쉽게 익힐 수 있는 주제라면 문서나 동영상처럼 혼자서 학습 할 수 있는 매체가 더 효울적입니다. 실제로 구글이 활용하는 입문 수업 중 상당수가 자가 학습 버전도 제공합니다.
• 수업을 정기적으로 개설해도 될 만큼 수요가 많아야 합니다. 다음 수업이 언제 개설될지 불분명하다면 잠재 학생들은 다른 경로를 찾아 필요한 지식을 배워야 할 것입니다. 구글의 경우 작고 외딴 연구소에서 특히 문제가 된다.

6-3. 문서자료

독자가 무언가를 배우도록 돕는 것을 최우선 목표로 하는 기록된 지식

1. 문서자료 갱신하기

: 문서자료의 실수나 빠진 부분을 발견한다면 곧바로 고치세요! 캠핑장을 떠날 때는 처음 왔을 때보다 깨끗해야 하듯 스스로 문서자료를 고쳐보세요.

2. 새로운 문서자료 작성하기

: 숙달되면 자신만의 문서자료를 작성하고 기존 문서자료들을 갱신해보세요.

3. 문서화 촉진하기

• 문서자료에 담긴 정보는 기본으로 참고해야 할 표준
• 표준을 팀 외부로 확산시킬 수 있음

6-4. 코드

• 코드도 지식이라는 사실을 인지하느냐 여부가 코드 가독성과 명확성에 간접적으로 영향을 줄 때가 많습니다.
• 적극적으로 관리하지 않으면 금세 낡은 지식이 되어 주석을 읽은 사람은 실제 코드와 모순되는 정보 때문에 혼란!

7. 조직의 지식 확장하기

7-1. 지식 공유 문화 일구기

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

1. 존중

• No Jerk

2. 보상과 인정

• 사람들은 진부한 칭찬보다는 확실한 보상에서 동기를 얻습니다.
• 말로만 하지 말고 보상과 수상 제도를 통해 실질적인 혜택을 주어야 하는 이유
• 소프트 엔지니어링 사다리
• 쿠도스 (공개 칭찬)

7-2. 표준 정보 소스 구축하기

• 표준 정보 소스: 중앙집권적 정보 원천으로, 전문가의 지식을 표준화하고 전파하는 수단,
  조직 내 모든 엔지니어에거 공통적으로 필요한 정보를 담아두는 최선의 도구
• 표준 정보 : 조직 차원에서 합의한 내용을 제공하고 눈에 잘 띄기 때문에 해당 분야 전문가들이 적극적으로 관리하고 감독해야 합니다.

- 개발자 가이드

: 전문가는 회사 차원의 방침을 개인적으로 설명해주지 않아도 되므로 시간이 절약되고, 배우는 사람은 필요하면 언제든 신뢰 가는 정보를 찾아 볼 수 있는 정보 소스가 있음을 알게됨.

- go/링크

: 구글에서 사용하는 URL 단축 서비스, 실제 정보다 어디에 저장되어 있느냐는 신경 쓸 필요 없는 직관적이고 기억하기 쉬운 접근 수단

- 코드랩

: 동작하는 예시 코드, 설명, 코딩 연습문제 등을 활용해 엔지니어에게 새로운 개념이나 프로세스를 가르치는 실습형 튜토리얼

- 정적 분석

: 검사 로직을 자동화할 수 있는 모범 사례들을 공유하는 강력한 수단
정적 분석 도구는 엔지니어 개개인의 지식을 강화해주며, 조직 차원에서는 더 많은 모범 사례를 더 일관되게 적용해줍니다.

7-3. 소외되지 않기

업무를 수행하려면 반드시 필요한 정보들이 있습니다.

- 뉴스레터

: 업무에 꼭 필요하지 않지만 엔지니어들이 관심을 가질만한 정보를 유통하는 방법

- 커뮤니티

: 다양한 분야에서 주제를 중심으로 다른 부서의 구글러들과 커뮤니티를 형성해 지식을 공유

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

가독성 제도, 표준 멘토링 프로세스

구글 엔지니어의 약 20%가 리뷰어 혹은 코드 작성자가 되어 가독성 인증 프로세스에 참여

8-1. 가독성 인증 프로그램이란?

• 구글에서 코드 리뷰는 필수입니다.
• 모든 변경 목록은 가족성 승인을 얻어야 합니다.
• 가독성 승인이란 해당 언어의 가독성 자격증이 있는 누군가가 해당 CL을 승인했다는 표시
• 가독성 자격증은 받은 엔지니어 : 특정 프로그래밍 언어를 사용하여 구글의 모범 사례와 코딩 스타일에 맞는 명확하고 관용적이고 유지보수하기 쉬운 코드를 일관되게 작성하는 사람
• 배운 지식을 자신의 코드에 항상 반영할 것이며, 스스로 리뷰어가 되어 동료 엔지니어들의 코드를 살펴봐줄 것이라고 믿기 때문
• 리뷰어믐 가독성 제도를 게이트키핑이나 공격용 무기가 아닌, 가장 우선적이고 중요한 멘토링 수단이자 협업 수단으로 생각하고 행동해야 합니다.

8-2. 가독성 인증 프로세스를 두는 이유

• 엔지니어들에게 소속 팀에서 통용되는 현장 지식 이상을 전달한다는 매우 큰 장점을 선사
• 중앙 집중식 인증 프로세스
  - 장점: 일관성을 강화하고 정보 섬을 없애고 확립된 표준에서 (의도치 않게) 벗어나는 일을 막기 쉽다.
  • 단점: 조직 규모가 커졌을 때 인증 프로세스 규모도 선형으로 확장
• 코드베이스 전체가 일관될 때 얻는 가치는 아무리 강조해도 부족
• '코드 리뷰가 길어진다는 단기적인 비용'과 '코드 품질 개선, 리포지토리 차원의 코드 일관성 향상, 엔지니어 전문성 향상에서 절약하는 장기적인 비용'을 의식적으로 맞바꾸는 제도
• 구글은 매우 강력한 코드 리뷰 문화를 견지하고 있으며, 가독성 제도는 이 문화로 부터 자연스럽게 확장된 결과물입니다.

9. 마치며

대부분 지식을 쉽게 공유하는 데 투자한 노력은 회사의 생애 동안 그 몇 배로 돌려받습니다.

10. 핵심 정리

• 심리적 안전은 지식 공유 환경을 조성하기 위한 토대입니다.
• 작게 시작하세요. 질문하고 기록하세요.
• 직원들이 전문가와 문서화된 자료 모두로부터 필요한 도움을 쉽게 얻을 수 있도록 하세요.
• 자기 자신, 소속 팀, 소속 조직을 넘어, 자신의 전문 지식을 가르치고 전파하는 사람들을 격려하고 보상하는 체계적인 제도를 마련하세요.
• 만병통치약은 없습니다. 지식 공유 문화를 뿌리내리고 강화하려면 여러 가지 전략을 조합해야합니다. 또한 조직에 가장 적합한 조합은 시간이 지나면서 달라질 수 있습니다.