Skip to content

Latest commit

 

History

History
259 lines (164 loc) · 14.6 KB

3. Knowledge Sharing.md

File metadata and controls

259 lines (164 loc) · 14.6 KB

3. 지식 공유

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

3.1 배움을 가로막는 장애물

회사 규모가 커지며 구글이 겪은 문제

심리적 안전 부족 (lack of psychological safety)

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

정보 섬 (information islands)

조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아 지식이 파편화 된다. 일하는 방식을 각각의 부서가 제각기 만들어 나간다.

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

단일 장애점 (single point of failure, SPOF)

중요한 정보를 한 사람이 독점하면 병목이 생긴다. '내가 다 처리하지'와 같은 좋은 의도로 시작하면 단기 효율은 높아도 장기 확장성은 희생된다.

전부 아니면 전무 전문성 (all-or-nothing expertise)

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

앵무새처럼 흉내내기 (parroting)

이해하지 못한 상태로 기존 패턴이나 코드를 따라한다.

유령의 묘지 (haunted graveyard)

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

3.2 철학

  • 일대일 조언은 효과적이나 전문가 한 명에 대한 의존성이 커 확장성이 부족하다 (팀이 커지면 유용하지 못하다).
  • 문서화된 지식은 일대일 조언보다 확장성이 좋지만 개별 학습자가 처한 특수한 상황에는 적합하지 않을 수 있다. 최신 정보를 반영해야하므로 유지보수 비용이 든다.
  • 현장 지식 (문서화 되지 않아 관련자들만 알고 있는 지식)과 문서화된 지식은 서로를 보완해준다.

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

  • 자신이 이해하지 못한 것이 있음을 인정해야 무언가를 배울 수 있다.
  • 배움에는 '무언가를 시도하다 실패하도 안전하다'라는 인식이 중요하다.

3.3.1 멘토 제도

  • 누글러의 멘토: 궁금한 점에 답해주고, 누글러의 성장을 돕는다. 누글러가 속한 팀원, 관리자, 테크 리드는 제외. 1 년 이상 근무하여 인프라와 문화를 알고 있어야 함.

3.3.2 큰 그룹에서의 심리적 안전

  • 심리적 안전을 위해 적대적이지 않고 협조적으로 일하는 문화가 필요하다.
권장 패턴 (협조적) 안티 패턴 (적대적)
기초적인 질문과 실수를 올바른 방향으로 안내 기초적인 질문이나 실수를 가려내 질문한 사람을 꾸짖음
질문자가 배우게끔 도와줄 목적으로 설명 자신의 지식을 뽐낼 목적으로 설명
상냥하게 인내심을 갖고 도움이 되게끔 대응 잘난 체하고 비난하며 건설적이지 못한 방식으로 대응
해법을 찾기 위한 공개 토론 형식으로 상호작용 승자와 패자를 가리는 논쟁 형식으로 상호작용

도움이 될만한 규칙

거짓된 놀람 금지 (뭐라고? 스택이 뭔지 모른다고?)

심리적 안전을 방해하여 구성원들이 모른다는 사실을 인정하기 두려워하게 된다.

"음.. 실제로는.." 금지

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

뒷자석 운전 금지

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

미묘한 '-주의' 금지

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

3.4 내 지식 키우기

3.4.1 질문하기

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

  • 초심자가 저지르는 가장 큰 실수는 막혔을 때 질문하지 않는 것
  • 동료는 가장 훌륭한 정보원이다.
  • 모르는 분야가 나오면 두려워하기보다 성장하는 기회로 받아들인다.
  • 상급자라면 모든 걸 알아야 한다는 인식이 생겨나지 않도록 한다.
  • 끈기를 가지고 상냥하게 답변해주어야 사람들이 안심하고 도움을 청하는 환경이 조성된다.
  • 사소한 질문이라도 답을 얻을 수 있게 도와준다.

3.4.2 맥락 이해하기

  • 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함된다.
  • 체스터슨의 울타리 원칙 (Chesterson's fence): 무언가 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자.
  • 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해야 한다.
  • 목적과 맥락을 이해하면 변경하려는 방향이 더 나은지 판단해보고 나으면 변경, 그렇지 않으면 판단 근거를 남긴다.

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

  • 무언가를 일대일로 배울 때는 기록하는 습관을 들이자. 나중에 합류한 동료에게 기록된 지식을 공유하자.

3.5.1 그룹 채팅

  • 질문은 있는데 누구에게 물어봐야할지 모르거나 물어보려는 사람이 바쁠 때 유용하다.
  • 주제 또는 팀별로 구성하는 경우가 많다. 규모와 신속성 vs 심리적 안전

3.5.2 메일링 리스트

  • 맥락 정보가 많이 필요한 복잡한 질문에 적합하다.
  • 빠르게 주고 받는 대화에는 취약하다.

3.5.3 YAQS: 질의응답 플랫폼

  • 사내 질의응답 플랫폼 활용

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

3.6.1 오피스 아워

  • 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트
  • 사람과 직접 대화해야 쉽게 풀리는 문제일 경우 유효하다.
  • 어떻게 질문해야할지 모를 때 또는 문서화되지 않은 특수한 문제에 맞닥뜨렸을 때 유용하다.

3.6.2 기술 강연과 수업

수업의 효과를 극대화하는 조건들

  • 자주 오해를 일으킬 정도로 복잡한 주제를 다루어야 한다. 수업은 개설 비용이 크므로 해결해야 할 분명한 문제가 있을 때 만들어져야 한다.
  • 주제가 비교적 안정적이어야 한다. 수업 교재를 고치는 것은 큰 일이다.
  • 질문에 답해주고 일대일로 도와줄 수 있는 교사가 있으면 효과가 큰 주제여야 한다. 직접적인 도움이 필요없는 주제는 문서나 동영상처럼 혼자 학습할 수 있는 방법을 생각해본다.
  • 수업을 정기적으로 개설해도 될 만큼 수요가 많아야 한다. 다음 수업이 언제 개설될지 불분명하다면 잠재 학생들은 다른 경로를 찾아 필요한 지식을 배울 것이다.

3.6.3 문서자료

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

문서자료 갱신하기

  • 처음 배우는 단계에서 문서자료의 실수나 빠진 부분을 발견한다면 곧바로 고친다.

새로운 문서자료 작성하기

  • 자신만의 문서자료를 작성하고 기존 문서자료를 갱신한다. 다른 사람들에게 공유하여 걸어간 길을 쉽게 따라올 수 있도록 한다. 다른 이들이 찾기 쉽게 한다.
  • 피드백할 방법을 제공한다.

문서화 촉진하기

  • 문제의 해법을 문서화하면 시간을 투자해야하지만 다음부터는 시간을 줄일 수 있다.
  • 문서화는 팀의 규모를 키우는데 도움이 된다.

3.6.4 코드

  • 라이브러리의 깔끔한 문서자료는 이용자와 유지보수하는 이들에게 혜택을 준다.
  • 코드의 주석은 지식을 미래로 전달한다. 낡은 지식은 혼란을 줄 수 있으므로 적시에 최신화한다.

3.7 조직의 지식 확장하기

3.7.1 지식 공유 문화 일구기

존중

  • 나쁜 행동은 초심자에게 버티기 가혹한 환경을 만들고, 전문가로 성장할 사람의 성장을 멈추게 만든다.
  • 지식을 공유할 때는 상냥함과 존중을 담아야 한다.
  • 리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 구글 문화의 가치를 설정하며, 구글을 더 활기차고 신나는 일터로 가꿔야 한다. 괴짜는 좋은 리더가 아니다.

보상과 인정

  • 지식 공유 문화를 장려하려면 인정과 보상 제도가 뒷받침되어야 한다.
  • 동료 상여 (peer bonus), 쿠도스 (kudos)

3.7.2 표준 정보 소스 구축하기

  • 회사 차원의 중앙집중적 정보 원천, 전문가의 지식을 표준화하고 전파하는 수단.
  • 해당 분야 전문가들이 적극적으로 관리하고 감독해야 한다.
  • 복잡한 주제일수록 담당자를 명확히 정해두어야 한다.

개발자 가이드

go/ 링크

  • 사내 리소스 URL 단축 서비스를 이용해 자원을 탐색하기 쉽게 한다.

코드랩 (codelab)

  • 동작하는 예시 코드, 설명, 코딩 연습문제 등을 활용해 새로운 개념이나 프로세스를 가르치는 실습형 튜토리얼.
  • 관리 비용이 많이 들고, 학습자 개인의 특수한 상황에는 맞지 않을 수 있다.

정적 분석 (static analysis)

  • 검사 로직을 자동화할 수 있는 모범 사례를 공유한다.
  • 설정하기는 까다로우나 설정 후 확장하기는 쉽다.
  • 엔지니어 교육에 드는 시간과 노력을 절약할 수 있다.
  • 개개인의 지식을 강화해주며, 조직 차원에서는 더 많은 모범 사례를 일관되게 적용되게 해준다.

3.7.3 소외되지 않기

뉴스레터

  • 업무에 꼭 필요하지는 않지만 엔지니어들이 관심을 가질만한 정보를 제공한다.
    • 엔지니어링 뉴스
    • 개인정보/보안 뉴스
    • 분기 중 가장 흥미로운 서비스 장애 소식
  • 제공 빈도를 높이기보다 내용을 더 유용하고 흥미롭게 채워야 효과적이다. 그렇지 않으면 스팸 처리된다.
  • 기발한 방법도 고민해볼 수 있다.
    • 화장실에서도 테스트
    • 화장실에서도 학습

커뮤니티

  • 다양한 분야에서 주제를 중심으로 다른 부서와 커뮤니티를 형성해 지식을 공유한다.
    • 문제 해결에 집중하는 그룹
    • 코드 건실성 그룹

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

  • 프로그래밍 언어 모범 사례를 전파하기 위한 전사 차원의 표준 멘토링 프로세스를 지칭한다.
  • 언어, 이디엄, 코드 구조, API 설계, 공통 라이브러리의 올바른 사용법, 문서화, 테스트 커버리지 등 전문 지식을 광범위하게 다룬다.

3.8.1 가독성 인증 프로세스란?

  • 구글에서 코드리뷰는 필수이며 모든 변경 목록 (changelist, CL)은 가독성 승인을 얻어야 한다.
  • 가독성 승인 (readability approval)이란 해당 언어의 가독성 자격증 (readability certification)이 있는 누군가가 해당 CL을 승인했다는 의미이다.
  • 가독성: 특정 프로그래밍 언어를 사용하여 구글의 모범 사례와 코딩 스타일에 맞는 명확하고 관용적이고 유지보수하기 쉬운 코드를 일관되게 작성하는 능력
  • 리뷰어는 가독성 제도를 게이트키핑이나 공격용 무기가 아닌, 가장 우선적이고 중요한 멘토링 수단이자 협업 수단으로 생각하고 행동해야 한다.
  • 리뷰어는 자신의 제안을 뒷받침하는 인용을 제공하여 CL 작성자가 해당 제안에 깔린 이론적인 근거를 배울 수 있도록 한다 (체스터슨의 울타리 등).
  • 가이드에 근거가 부족해보인다면 CL 작성자는 리뷰어에게 질문한다.

3.8.2 가독성 인증 프로세스를 두는 이유

  • 코드는 작성되는 횟수보다 훨씬 많이 읽힌다.
  • 문서로 정리된 모범 사례들은 모든 구글 코드에서 따라야 하는 일관된 표준을 제공하는데, 가독성 제도는 이 표준들을 시행하고 전파하는 메커니즘이다.
  • 일관성을 강화하고 정보 섬을 없애고 확립된 표준에서 의도치 않게 벗어나는 일을 막기 쉽다는 장점이 있다.
  • 조직 규모가 커졌을 때 인증 프로세스 규모도 선형으로밖에 확장할 수 없다는 단점이 있다.
  • 가독성 제도는 엔지니어링 속도 (engineering velocity)에 긍정적인 영향을 준다. 가독성 자격증을 받은 엔지니어들이 작성한 CL은 그렇지 않은 엔지니어들이 올린 CL보다 검토 시간이 평균적으로 훨씬 짧았다. 자신의 코드 품질에 관한 자가 만족도 조사에서도 자격증을 받은 엔지니어 쪽의 만족도가 높았다.

3.9 결론

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

3.10 핵심정리

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