구글 엔지니어는 이렇게 일한다: 지식 공유
in BOOK on 구글 엔지니어는 이렇게 일한다
조직은 자신의 문제 대부분에 스스로 답할 수 있어야 한다.
그러기 위해서 조직 내에는 질문의 답을 아는 전문가가 필요하고, 그들의 지식을 전파할 메커니즘이 필요하다.
또한 조직에 배움의 문화가 자리잡혀야 하고, 그러려면 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다.
1. 배움을 가로막는 장애물
- 심리적 안전 부족
- 불이익이 두려워서 스스로 위험을 감수하거나, 실수를 드러내기 꺼리는 환경
- 이 현상은 두려움이 팽배한 문화나 꼭꼭 숨기려는 경향으로 나타남
- 정보 섬(information islands)
- 조직의 각 부서가 서로 소통하지 않거나 자원을 공유하지 않아서 지식이 파편화됨
- 정보 파편화, 정보 중복, 정보 왜곡이 발생함
- 단일 장애점
- 중요한 정보를 한 사람이 독점하면 병목이 생김
- ‘다른 사람들을 위해 내가 다 처리하지,뭐’ 라는 좋은 의도로 시작했어도 결국 이것은 단기 효율은 높여주지만 장기 확장성을 희생하게 됨
- 그 팀은 팀으로서 필요한 일들을 어떻게 해야할지 전혀 배우지 못함
- 전부 아니면 전무 전문성(all-or-nothing expertise)
- 조직 구성원이 중간층없이 ‘모든 것은 아는’ 사람과 ‘아무것도 모르는’ 초심자로 나뉨
- 전문가들은 항상 모든 일을 자신들이 처리하게 되므로 전문가를 키우기 위한 멘토링이나 문서화에 신경 쓸 여력이 줄어듦
- 지식과 책임은 계속 전문가에게 집중되고, 초심자들은 느리게 성장하게 됨
- 앵무새처럼 흉내만 내기
- 이해하지 못한 상태로 흉내만 내는 것
- 목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라함
- 유령의 묘지
- 무언가 잘못될 것이 두려워서 아무도 손대지 않는 영역(주로 코드)
2. 철학
전문가가 일대일로 해주는 조언의 가치는 매우 크다.
하지만 전문가 한 명이 휴가를 가거나 이직을 하면 팀이 휘청거릴수도 있다. 이렇게 사람 사이에 일대일로 이루어지는 조언은 어떤 측면에서는 매우 효과적이지만, 확장성이 부족하여 팀이 커지면 그지 유용하지 못하다.
문서화된 지식은 팀을 넘어 조직 전체로 퍼뜨릴 수 있다.
정리된 문서가 일대일 조언보다 확장성이 좋지만 최신 정보를 반영해야 한다는 트레이드오프도 있다.
기록된 지식은 확장성이 좋지만 사람이 해주는 맞춤형 도움도 장점이 크다.
전문가에게는 다양한 지식을 종합할 수 있는 능력이 있기 때문이다.
팀원 개인의 지식과 문서화된 정보 중간에는 현장 지식이 존재한다.
현장 지식은 제대로 문서화되어 있지 않아서 관련 맥락을 알고 있는 핵심 멤버들만 알고 있는 지식을 말한다.
3. 심리적 안전
심리적 안전은 학습 환경을 조성하는데 매우 중요하다.
먼저 자신이 이해하지 못한 게 있음을 인정해야 무언가를 배울 수 있다.
타인의 무지를 탓하지 말고 그 솔직함을 반겨야 한다.
배움에는 ‘무언가를 시도하다가 실패해도 안전하다’는 인식이 매우 중요하다.
건강한 환경이라면 질문을 던지고, 틀리고, 새로운 지식을 얻는 걸 편안하게 생각한다.
효과적인 팀을 이루는 데 가장 중요한 요인은 심리적 안전이며, 그 외에는 신뢰성, 구조와 명확성, 일의 의미, 일의 영향력 등이 있다.
신규 입사자는 부담없이 질문할 수 있게 해주고, 성장 중인 전문가는 자신의 답변에서 허점을 찾아 공격당할지 모른다는 두려움 없이 도움의 손길을 내밀 수 있도록 해야 한다.
이처럼 안전하고 편안한 근무 환경 조성에 중요한 것은 적대적이지 않고 협조적으로 일하는 문화이다.
| 권장 패턴 | 안티 패턴 |
|---|---|
| 기초적인 질문과 실수를 올바른 방향으로 안내함 | 기초적인 질문이나 실수를 가려내서 질문한 사람을 꾸짖음 |
| 질문자가 배우게끔 도와줄 목적으로 설명함 | 자신의 지식을 뽐낼 목적으로 설명함 |
| 상냥하고 인내심을 갖고 도움이 되게끔 대응함 | 잘난 체하고 비난하며, 건설적이지 못한 방식으로 대응함 |
| 해법을 찾기 위한 공개 토론 형식으로 상호작용이 이루어짐 | 승자와 패자를 가리는 논쟁 형식으로 상호작용이 이루어짐 |
4. 나의 지식 키우기
4.1. 질문하기
초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것이다.
혼자서 극복해내고 싶거나 너무 기초적인 질문이라는 소리를 듣는 것이 두렵겨나, 도움을 청하기 전에 최대한 노력해봐야 한다. 라고 생각해서 일 수도 있다.
이 함정에 빠지지 말자.
옆의 동료가 가장 훌륭한 정보 소스일 경우가 많으니 이 귀중한 자원을 충분히 활용하자.
‘이것이 뭔지 모르겠는데 설명 좀 해주시겠어요?’ 라고 말하는 것은 두려워하지 말아야 한다.
모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들여야 한다.
가면 증후군을 겪는 사람들이 적지 않다.
가면 증후군은 자신의 능력보다 과대 평가받고 있다고 느껴서 자칫 실수하면 자신이 사기꾼임을 들킬지 모른다는 두려움을 말한다.
가면 증후군에 걸린 사람들은 실패를 두려워하기 쉽고, 새로운 도전을 피하려는 경향이 강하다.
모르는 건 바로바로 물어봐야 더 빨리 성장하고 팀에도 더 빨리 녹아들 수 있다.
많이 알면 알수록 모르는 것이 더 많아짐을 깨닫자.
또한, 끈기를 가지고 상냥하게 답변해줘야 사람들이 안심하고 도움을 청하는 환경이 조성된다.
4.2. 맥락 이해하기
기존 설계와 구현을 깊이 이해하는 것도 배움에 포함된다.
기존의 것을 이해하는데 시간을 쓰기보다 새로 만들고 싶을수도 있지만 무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해해야 한다.
특히 정상이 아니라고 보이는 것에 대해서는 먼저 맥락을 찾아야 한다.
코드의 목적과 맥락을 이해하고, 그런 다음에 변경하려는 방향이 여전히 더 나은지 고민해야 한다.
5. 질문 확장
일대일 도움은 밀도가 높지만 확장하는 데에는 필연적으로 한계가 있다.
배우는 쪽에서도 상세 내용을 모두 다 기억하기란 쉽지 않으므로 미래의 자신을 위해서라도 무언가를 일대일로 배울 때는 기록하는 습관을 기르는 것이 좋다.
6. 지식 확장
가르친다는 것은 전문가의 전유물이 아니며, 전문성이라는 것은 ‘초심자 아니면 전문가’처럼 이분법적으로 나뉘지도 않는다.
무언가를 막 배운 순간이 기존의 문서자료에서 개선점을 찾기 가장 좋은 때이다.
프로세스나 시스템에 익숙해지고 깊이 이해하게 되면 어떤 내용이 어려웠고 ‘시작하기’ 문서에서 누락된 사소한 단계가 무엇인지 알기 어렵다.
처음 배우는 단계에서 문서자료의 실수나 빠진 부분이 있다면 곧바로 문서자료를 갱신하자.
자신만의 문서자료를 작성하고 기존 문서자료를 갱신해보자.
그런 다음 다른 사람들에게 공유하여 내가 걸어간 길을 쉽게 따라오도록 하자.
문서화는 시간과 노력이 들기 때문에 엔지니어들에게 각자가 한 일을 문서화하도록 장려하기는 쉽지 않다.
문서화는 소수가 시간을 들여 다수에게 이득을 주므로 조직 전체에 도움을 주지만, 기본적으로 기여자와 수혜자가 달라서 적절한 보상없이는 사람들을 움직이기 어렵다.
하지만 문서자료 작성자 역시 문서화롤부터 직접적인 혜택을 받기도 한다.
해법을 문서자료로 정리하려면 시간을 좀 투자해야 하지만, 한 번만 해두면 이후부터는 시간을 절약할 수 있다.
같은 문제로 질문이 들어왔을 때 문서자료를 건네 스스로 해결하게 하고, 꼭 필요할 때만 나서면 된다.
7. 조직의 지식 확장
조직이 커질수록 전문 지식을 조직 전반에 제대로 공유하기는 어렵다.
7.1. 지식 공유 문화 만들기
7.1.1. 존중
몇몇 개인의 나쁜 행동으로 인해 팀 전체가 초심자에게 버티기 가혹한 환경으로 변하기도 한다.
이런 환경에서 초심자는 궁금한 게 생겨도 커뮤니티 외부에서 답을 찾거나, 새로운 전문가로 성장해야 할 사람들은 노력하기를 멈춰버린다.
지식을 공유할 때는 상냥함과 존중을 담아야 한다.
리더십 항목 높은 수준의 기술 리더십을 요구하지만, 모든 리더십이 기술 문제와 관련있는 것은 아니다.
리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 팀의 가치를 설정하며, 더 활기차고 신나는 일터로 바꾸어야 한다.
괴짜는 좋은 리더가 아니다.
7.1.2. 보상과 인정
지식 공유 문화를 장려하려면 인정과 보상 제도가 뒷받침되어야 한다.
사람들은 칭찬보다는 확실한 보상에서 동기를 얻기 때문에 말로만 하지 말고 보상과 수상 제도를 통해 실질적인 혜택을 주어야 한다.
쿠도스(공개 칭찬)은 동료의 기여를 공개적으로 인정하는 제대로, 동료 간에 이루어진 기여를 더 널리 알리는 효과가 있다.
동료의 업적을 인정해주는 공식적이고 손쉬운 제도는 직원들에게 계속해서 이타적일 수 있도록 강한 동기를 부여한다.
7.2. 표준 정보 소스 구축하기
깊이있는 공식 가이드를 만들어 활용하는 것도 좋다.
코딩 스타일 가이드, 공식 소프트웨어 엔지니어링 모범 사례, 코드 리뷰 가이드와 테스트 가이드, 금주의 팁 등 다양하다.
전문가는 회사 차원의 방침을 개인적으로 설명해주지 않아도 되므로 시간이 절약되고, 배우는 사람은 필요하면 언제든 신뢰가는 정보를 찾아볼 수 있는 정보 소스가 있음을 알게 된다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 구글 엔지니어는 이렇게 일한다 를 읽으며 정리한 내용들입니다.
