[책] 구글 엔지니어는 이렇게 일한다 - 3

책을 읽고 인상 깊었던 글귀 정리

Chapter3. 지식 공유

---

조직 내에는 질문의 답을 아는 전문가들이 필요하고 그들의 지식을 전파할 메커니즘도 필요합니다. 이것이 이번 장에서 다룰 주제입니다.

 

[3.1 배움을 가로막는 장애물]

조직 전체에 전문성을 공유하기란 결코 쉬운 일이 아닙니다. 구글은 특히 회사 규모가 커지면서 다음의 문제들을 겪었습니다.

1. 심리적 안전 부족 - 불이익이 두려워서 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경을 말합니다. 이 현상은 두려움이 팽배한 문화 혹은 꼭꼭 숨기려는 경향으로 나타나곤 합니다.
2. 정보 섬 - 조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화됩니다.
3. 단일 장애점 - 중요한 정보를 한 사람이 독점하면 병목이 생깁니다. 좋은 의도에서 단일 장애점이 시작되기도 합니다. '여러분을 위해 내가 다 처리하지'같은 마음에서 말이죠. 하지만 단기 효율은 높여주는 대신('내가 하는 게 빠르지') 장기 확장성을 희생하는 꼴입니다.(그 팀은 팀으로서 필요한 일들을 어떻게 해내야 할지 전혀 배우지 못합니다.)
4. 전부 아니면 전무 전문성 - 조직 구성원이 '모든 것을 아는'사람과 '아무것도 모르는' 초심자로 나뉩니다. 중간층은 거의 사라지죠. 한번 이렇게 되면 전문가들은 항상 모든 일을 자신들이 처리하게 됩니다. 지식과 책임은 계속 이미 전문가가 된 사람들에게 집중되고, 새로운 팀원이나 초심자들은 그들만의 울타리에 갇혀 느리게 성장하게 됩니다.
5. 앵무새처럼 흉내내기 - 이해하지 못한 상태로 흉내만 내는 것을 말합니다. 이 증상에 빠진 사람은 목적을 이해하지 못하고(주로 '잘은 모르겠지만 이게 맞겠거니' 하고) 무의식적으로 기존 패턴이나 코드를 따라 합니다.
6. 유령의 묘지 - 무언가 잘못될 게 두려워서 아무도 손대지 않는 영역(주로 코드)을 말합니다. 

 

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

심리적 안전은 학습 환경을 조성하는데 매우 중요합니다. 먼저 자신이 이해하지 못한 게 있음을 인정해야 무언가를 배울 수 있습니다. 그러니 우리 모두는 타인의 무지를 탓하지 말고 그 솔직함을 반겨야 합니다. 배움에는 '무언가를 시도하다가 실패해도 안전하다'는 인식이 엄청나게 중요합니다.

 

[3.4 내 지식 키우기]

이번 장에서 잊지 말아야 할 단 하나의 문장을 뽑는다면 '항상 배우고 항상 질문하라!'일 것입니다. 초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것입니다. 혼자서 극복해내고 싶다거나 '너무 기초적인' 질문이란 소리를 듣는 게 두려워서일 수 있습니다. 혹은 '도움을 청하기 전에 최대한 노력해봐야 해'라고 생각할지 모릅니다. 이 함정에 빠지지 마세요!

갑자기 모든 상황에 대한 완벽한 대처법을 깨닫게 되는 마법 같은 날은 결코 오지 않습니다. 인간이라면 언제나 아는 것보다 배워야 할 것이 많기 마련입니다. 구글에서 몇 년을 일한 엔지니어라도 어떻게 해야 할지 모르는 영역이 존재하며, 전혀 문제 될 일이 아닙니다. '이게 뭔지 모르겠는데, 설명 좀 해주시겠어요?'라고 말하는 걸 두려워하지 마세요. 모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이세요. (중략) 특히 조직(혹은 팀)의 리더들이 솔선수범해서 이런 문화를 만들어야 합니다. 그리고 '상급자라면 모든 걸 알아야 한다'라는 인식이 생겨나지 않도록 주의하세요. 사실 아래 그림처럼 우리는 많이 알면 알수록 모르는 것이 더 많음을 깨닫게 됩니다. 공개적으로 묻고 모르면 모른다고 인정한다면 다른 사람들도 점점 그렇게 변해갈 것입니다.

학사 > 석사 > 박사로 갈 수록 안다고 생각하는 것이 더 적어짐

 

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

일대일 도움은 밀도가 높지만 확장하는 데는 필연적으로 한계가 있습니다. 배우는 쪽에서도 상세 내용을 모두 다 기억하기란 쉽지 않습니다. 그러니 미래의 자신을 위해서라도 무언가를 일대일로 배울 때는 '기록하는 습관'을 기르세요. 여러분보다 나중에 들어오는 동료들도 여러분과 똑같은 질문을 할 가능성이 큽니다. 그들을 위해 '기록해 둔 지식을 공유'하세요.

질문 채널

• 그룹 채팅
• 메일리 리스트
• 스택오버플로
• ..

 

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

가르친다는 건 전문가의 전유물이 아니며, 전문성이라는 게 '초심자 아니면 전문가'처럼 이분법적으로 나뉘지도 않습니다. 전문성은 다차원 벡터입니다. 누구나 영역별로 다양한 수준의 전문성을 갖추고 있죠. 조직이 성공하려면 다양성을 반드시 갖춰야 하는 이유가 여기 있습니다. 우리는 서로 다른 관점과 전문성을 지니고 논의 테이블에 앉습니다. 구글 엔지니어들은 오피스 아워, 기술 강연과 수업, 문서 작성, 코드 리뷰 등 다양한 방식으로 다른 사람을 가르칩니다.

(중략)

<문서자료>

문서자료는 독자가 무언가를 배우도록 돕는 것을 최우선 목표로 하는 기록된 지식입니다.

• 문서자료 갱신하기 - 무언가를 막 배운 순간이 기존 문서자료에서 개선점을 찾기에 가장 좋은 때입니다. 새로운 프로세스나 시스템에 익숙해지고 깊이 이해하게 되면 어떤 내용이 어려웠는지, 혹은 '시작하기' 문서에서 누락된 사소한 단계가 무엇이었는지 이미 잊었을 가능성이 큽니다. 처음 배우는 단계에서 혹시라도 문서자료의 실수나 빠진 부분을 발견한다면 곧바로 고치세요!
• 문서자료 작성하기 - 숙달되면 자신만의 문서자료를 작성하고 기존 문서자료들을 갱신해보세요.
• 문서화 촉진하기 - 엔지니어들에게 각자가 한 일을 문서화하도록 장려하기가 쉽지는 않을 것입니다. 문서자료를 작성하려면 시간과 노력이 드는데, 코딩할 시간에서 뺏어와야 하기 때문이죠. 또한 문서화한 효과가 바로 나타나지도 않고 그마저도 대부분 (자신이 아닌) 다른 사람들에게 돌아갑니다. 이처럼 문서화는 소수가 시간을 들여 다수에게 이득을 주므로 조직 전체에는 도움을 주지만, 기본적으로 기여자와 수혜자가 달라서 적절한 보상 없이는 사람들을 움직이게 하기 어렵습니다. (중략) 그런데 문서자료 작성자 역시 문서화로부터 직접적인 혜택을 받기도 합니다. 특정한 유형의 문제가 발생하면 팀원들이 매번 여러분에게 달려와 도움을 청한다고 해보죠. 여러분의 해법을 문서자료로 정리하면 시간을 좀 투자해야 하지만, 한 번만 해두면 다음부터는 시간을 절약할 수 있습니다. 같은 문제로 팀원이 찾아오면 문서자료를 건네 스스로 해결하게 되고, 꼭 필요할 때만 직접 나서면 됩니다.

<코드>

코드 문서화는 또 다른 형태의 지식 공유 수단입니다. 코드 내의 주석은 지식을 미래로 전달합니다. 자기 자신을 포함한 미래의 독자를 위해 정확하게 기록하세요.

 

[3.7 조직의 지식 확장하기]

지식을 공유할 때는 상냥함과 존중을 담아야 하고, 또 그래야만 가능합니다. 기술 업계에서는 '뛰어난 괴짜'를 용인하는(심지어 숭배하는) 경향이 있지만, 해로운 현상입니다. 상냥한 전문가라도 얼마든지 가능하기 때문이죠. 구글 소프트웨어 엔지니어링 직무 사다리(job ladder)에서 리더십 항목을 찾아보면 다음 내용을 명확히 밝히고 있습니다.

리더는 주변 사람들을 성장시키고, 팀의 심리적 안전을 개선하고, 팀워크와 협업 문화를 조성하고, 팀 내 긴장을 해소하고, 구글 문화의 가치를 설정하며, 구글을 더 활기차고 신나는 일터로 가꿔야 합니다. 괴짜는 좋은 리더가 아닙니다.