🧑🏻‍💻 구글 엔지니어는 이렇게 일한다 (3) - 지식공유

🚀 3. 지식공유

가장 중요한 사실은 조직에 배움의 문화가 자리 잡혀야 한다는 것이고 그러려면 사람들에게 모르는 걸 인정할 수 있도록 돕는 심리적 안전을 제공해야 합니다.

📖 3.1 배움을 가로막는 장애물

조직 전체에 전문성을 공유하기는 결코 쉬운 일이 아니라 배움의 문화가 견고하게 뒷받침하지 못하면 여러가지 문제에 부딪히게 됩니다.

 

1️⃣ 심리적 안전 부족

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

이 현상은 두려움이 팽배한 문화 혹은 꼭꼭 숨기려는 경향으로 나타나곤 함

 

2️⃣ 정보 섬

조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아서 지식이 파편화됩니다.

이런 환경에서는 일하는 방식을 각각의 부서가 제각기 만들어나가서 여러 현상이 나타남

• 정보 파편화
• 정보 중복
• 정보 왜곡

 

3️⃣ 단일 장애점 (SPOF)

중요한 정보를 한 사람이 독접하면 병목이 생깁니다.

단기 효율은 높여주는 대신 장기 확장성을 희생하는 꼴입니다.

• 그 팀은 팀으로서 필요한 일들을 어떻게 해내야 할지 전혀 배우지 못합니다.
• 4번으로 이어집니다.

 

4️⃣ 전부 아니면 전무 전문성

조직 구성원이 모든 것을 아는 사람과 아무것도 모르는 초심자로 나뉨

전문가들은 항상 모든 일을 자신들이 처리하게 되고 새로운 전문가를 키우기 위한 여력이 줄어들음

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

 

5️⃣ 앵무새처럼 흉내내기

이해하지 못한 상태로 흉내만 내는 것을 말함

목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라함

 

6️⃣ 유령의 묘지

무언가 잘못될 게 두려워서 아무도 손대지 않는 영역(주로 코드)

두려움과 비합리적인 의심 때문에 사람들이 손대기를 기피하는 영역임

📖 3.2 철학

기록된 지식은 확장성이 좋지만 사람이 해주는 맞춤형 도움도 장점이 큽니다.

전문가는 특정 개인에게 딱 맞는 정보가 무엇인지 가늠하여 문서에 적힌 내용이 적절한지 그리고 그 내용을 어디에서나 찾을 수 있는지 알 수 있습니다.

현장 지식과 문서화된 지식은 서로를 보완해줍니다.

모든 형태의 배움에 최고인 유일무이한 지식 공유법은 존재하지 않으며 어떻게 조합하는 게 최선일지는 조직에 따라 다릅니다.

 

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

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

먼저 자신이 이해하지 못한 게 있음을 인정해야 무언가를 배울 수 있습니다.

그러니 우리 모두는 타인의 무지를 탁하지 말고 그 솔직함을 반겨야 합니다.

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

• 건강한 환경에서라면 사람들은 질문을 던지고, 틀리고, 새로운 지식을 얻는 걸 편안하게 생각합니다.
• 심리적 안전이 효과적인 팀을 이루는 데 가장 중요한 요인이었습니다.

 

📖 3.4 내 지식 키우기

📌 3.4.1 질문하기

초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것입니다.

• 혼자서 극복해내고 싶다거나 너무 기초적인 질문이란 소리를 듣는게 두려워서일 수 있습니다.
• 혹은 도움을 청하기 전에 최대한 노력해봐야 해라고 생각할지 모릅니다.

 

여러분의 동료가 가장 휼륭한 정보 소스일 경우가 많습니다.

• 이 귀중한 자원을 충분히 활용하세요.

 

구글에서 몇 년을 일한 엔지니어라도 어떻게 해야 할지 모르는 영역이 존재하며 전혀 문제 될 일이 아닙니다.

• 이게 뭔지 모르겠는데, 설명 좀 해주시겠어요?라고 말하는 걸 두려워하지 마세요.

 

모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이세요 👍

• 항상 무언가 배울 게 있는 환경에서 살아야 합니다. 그렇지 않으면 더 이상 성장하지 못할 것입니다.

 

우리는 많이 알면 알수록 모르는 것이 더 많음을 깨닫게 됩니다.

• 공개적으로 묻고 모르면 모른다고 인정한다면 다른 사람들도 점점 그렇게 변해갈 것입니다.

초기의 망설임을 극복하면 분위기를 빠르게 조성할 수 있으니 질문을 하도록 권장하고 “사소한” 질문이라도 답을 얻을 수 있도록 힘써주세요

 

📌 3.4.2 맥락 이해하기

새로운 것을 이해하는 일뿐 아니라 기존 설계와 구현을 뒷받침하는 결정 사항들을 더 깊이 이해하는 일도 배움에 포함됩니다.

• 특히 정상이 아니라고 보이는 결정에 대해서는 먼저 맥락을 찾아 이해해야 합니다.
• 우선 코드의 목적과 맥락을 이해하고 그런 다음 변경하려는 방향이 여전히 더 나은지 고민해야 합니다.
• 더 낫다고 판단되면 고치고 그렇지 않다면 미래에 다시 그 코드를 살펴볼 후임들을 위해 여러분이 생각한 근거를 적어두세요.

 

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

📌 3.6.3 문서자료

문서자료 갱신하기

• 무언가를 배운 순간이 기존 문서자료에서 개선점을 찾기에 가장 좋은 때입니다.
• 문서자료의 실수나 빠진 부분을 발견한다면 곧바로 고치세요!

 

새로운 문서자료 작성하기

• 스스로 새로운 개발 흐름을 만들어냈다면 그 단계들을 설명하는 문서자료를 작성하세요.
• 다른 사람에게 공유하여 여러분이 걸어간 길을 쉽게 따라오도록 하세요.

 

문서화 촉진하기

• 엔지니어들에게 각자가 한 일을 문서화하도록 장려하기가 쉽지는 않을 것입니다.
• 문서자료를 작성하려면 시간과 노력이 드는데 코딩할 시간에서 뺏어와야 하기 때문
• 문서자료로 정리하려면 시간을 좀 투자해야 하지만 한 번만 해두면 다음부터는 시간을 절약할 수 있습니다.
• 문서화는 팀과 조직의 규모를 키우는 데도 보탬이 됩니다.

 

📖 3.7 조직의 지식 확장하기

📌 3.7.1 지식 공유 문화 일구기

존중

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

구글의 소프트웨어 엔지니어링 직무 사다리에서 리더십 항목을 찾아보면 다음 내용을 명확히 밝히고 있습니다.

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

 

보상과 인정

• 동료의 업적을 인정해주는 공식적이고 손쉬운 제도는 직원들에게 계속해서 이타적이고 멋진 일들을 하도록 강한 동기를 부여합니다.
• 상여금보다는 동료를 인정해준다는 점이 더 중요합니다.

 

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

구글에서 가독성제도는 단순한 코드 가독성 이상을 의미합니다.

• 프로그래밍 언어 모범 사례를 전파하기 위한 구글 전사 차원의 “표준 멘토링 프로세스”를 지칭하죠.
• 오늘날에는 구글 엔지니어의 약 20%가 리뷰어 혹은 코드 작성자가 되어 가독성 인증 프로세스에 참여하고 있습니다.

 

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

구글에서 코드 리뷰는 필수입니다.

모든 변경 목록은 가독성 승인을 얻어야 합니다.

• 가독성 승인이란 해당 언어의 가독성 자격증이 있는 누군가가 해당 CL을 승인했다는 표시입니다.

 

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

문제는 들이는 비용에 비해 얻어지는 이익이 더 많은가입니다.

가독성 제도는 코드 리뷰가 길어진다는 단기적인 비용 과 코드 품질 개선, 리포지터리 차원의 코드 일관성 향상, 엔지니어 전문성 향상에서 절약하는 장기적인 비용을 의식적으로 맞바꾸는 제도입니다.

• 혜택의 시간 척도를 길게 잡을수록 코드의 기대 수명이 길다는 뜻이 됩니다.

 

🤔 3장을 읽고나서,,,

✅ 질문하기

이번 장에서 인상깊었는 내용 중 하나는 아래 내용이였어요.

초심자가 저지르는 가장 큰 실수는 무언가 막혔을 때 질문하지 않는 것입니다.

혼자서 극복해내고 싶다거나 너무 기초적인 질문이란 소리를 듣는게 두려워서일 수 있습니다.

 

그러나 구글 엔지니어들조차 모르는 게 많아 서로 사소한 것도 질문한다는 점을 보고 내가 질문하지 않는 것은 오히려 더 비효율적이고 바람직하지 않다는 것을 알게 되었어요.

 

질문 자체가 학습의 출발점이며 질문하지 않으면 더 크게 성장의 기회를 놓칠 수도 있을 것이라 생각이 들었어요.

따라서 앞으로는 막혔을 때 충분히 고민한 뒤 주저하지 않고 공유하고 질문을 던져 그것을 더 큰 학습의 기회로 삼아야겠다!!

 

✅ 문서자료

요즘 학습을 한 것, 구현과정에서 발생한 작업들을 문서화를 하느라 구현 시간이 줄어드는 것 같아 고민이 있었지만 그것 또한 개발자로서의 중요한 과정이라는 것을 다시 느낄 수 있었던 것 같습니다.

 

다만, 문서화와 구현 사이에서 균형을 유지하면서 핵심 내용을 먼저 기록하는 방식으로 개선해야겠다고 생각했어요..!

📚 Ref.

https://product.kyobobook.co.kr/detail/S000061352347