[책 정리] 구글 엔지니어는 이렇게 일한다 #3 지식 공유를 읽고

#3 지식 공유를 읽고

| 일부 내용
지식을 전파할 메커니즘

 

나도 프로그래밍을 이제 막 시작하는 시기에는 질문을 잘하지 못했다. 그렇기 때문에 내가 원하는 답을 얻기도 쉽지 않았고, 이를 기반으로 문제를 해결할 실마리를 마주하는것도 어려웠던때가 있었다. 더불어, 안그래도 초보인데 질문을 잘못해서 질책을 받으면 어떻게 하지? 이걸 물어봐도 되나? 라는 의문을 항상 품고 있었다.

 

책에서도 질문는 하는 과정에서의 심리적 안정성에 대해서 말해주고 있다. 

 

물론, 지금은 실무를 겪으며, 이러한 생각들은 나은 방향으로 변화했다. 내가 부족해보일까 두려워 질문을 주저하지 않고 질문을 하려고 한다.

 

 

더불어, 문서화의 중요성 또한 이야기 하고자 하는것을 느꼈다.

정보의 중복과 파편화, 전달의 왜곡은 질문 / 답변 / 지식 / 경험을 문서로 만들지 않으면, 흔하게 발생하기 때문이다.

 

---

 

| 일부 내용
단일 장애점 (Single point of fauilre, SPOF)
좋은 의도에서 단일 장애점이 시작되기도 합니다. 
"여러분을 위해 내가 다 처리하지" 같은 마음에서 말이죠. 
하지만, 단기 효율은 높여주는 대신 장기 확장성을 희생하는 꼴 입니다.

 

현업을 하다보면, 이슈가 발생하고 이에 대해서 해결하는 사람이 나타나게 된다. 

그러면, 이에 대한 경험치는 누가 얻게 되는건가? 를 생각해보면, 팀이 아닌 문제를 해결한 개인에게 집중된다. 

다음에 비슷한 류의 이슈가 발생하게 되면, 이전의 동일한 문제의 경험치가 쌓여 있는 개발자가 문제를 순식간에 해결하고 해당 이슈는 closed 된다. 

 

여기까지는 해피엔딩이다.

하지만, 해당 개발자가 퇴사를 하거나 부서 이동, 긴 휴가를 쓰는 과정에서 비슷한 이슈가 또 발생한다고 가정하면, 해당 이슈에 대해 경험치가 없는 개발자가 해당 이슈를 다시 처음부터 디버깅하며 문제를 해결하거나 퇴사/휴가 상태의 개발자에게 연락을 해야한다.

 

그렇기에 포스트 모멘텀 문서, 이슈 문서등 문서화를 통한 지식의 전파가 중요하다.

나도 현업에서 개발을 진행할때 AWS RDS 의 CPU 스파이크 현상을 해결하며 이를 문서로 정리하였고, 내가 휴가중에 발생한 비슷한 문제를 팀 동료가 문서를 통해 실마리를 잡아 해결했다는 이야기를 휴가 복귀하고 들었었다.

 

https://helicopter55.tistory.com/82

[AWS 트러블 슈팅] RDS CPU 점유율 99% 스파이크 현상 트러블 슈팅

 

---

 

| 일부 내용
앵무새처럼 흉내내기
이해하지 못한 상태로 흉내만 내는것을 말합니다. 
이증상에 빠진 사람은 목적을 이해하지 못하고 무의식적으로 기존 패턴이나 코드를 따라 합니다.

 

대학교, 학원등 다양한 활로를 통해 개발을 접하고 학습하며 노력하고, 현업에 참여하게 되면 기존의 방식과는 전혀 다른 구조의 프로젝트, 커스터 마이징된 프레임워크등을 마주하게 된다.

실제로 연차가 쌓이고 여러 트러블 슈팅을 겪으며, 새로운 프로젝트 개발을 완료하면서 실력을 쌓는 과정이 없었다면, 나는 아직 까지도 책에서 말하는 "앵무새 처럼 흉내내기" 단계에 머물러 있었을것이다.

 

---

 

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

 

프로그래밍을 업으로 삼거나 프로그래머가 되기 위해 노력하고 있는 사람들 중 대부분은 이러한 고민을 해봤지 않았을까 생각된다.

하지만, 책에서는 이러한 내용을 "함정" 으로 정의하고 빠지지 말라고 당부하고 있다는것에 한편으로는 웃음이 났다.

( 나도 한때는 그랬었는데... )

 

많은 사람들이 질문의 필요성을 강조하지만, 현업에 참여하게 되면 회바회, 부바부, 사바사 란말을 괜히 있는게 아니란걸 알게 된다.

내가 어디 있느냐에 따라서 이런 고민을 할 필요조차 없을 수 있고, 혹은 이런 고민만을 하게 될 수 도 있다. 

그렇기에 개발 조직과 개발 문화에 대해서 다시금 생각해보게 된다. 

 

---

 

| 일부 내용
구글에서는 '누글러 (구글에 새로 입사한 직원)' 가 합류하자마자 분위기를 만들어주려 노력합니다.
멘토 정해주기는 누글러에게 심리적 안전을 심어주는 효과적인 방법 입니다.
멘토의 공식 역할은 궁금한 점에 답해주고 누글러의 성장을 돕는 것입니다. 

 

심리적 안정을 위한 사수의 중요성에 대해 다시금 되새긴다. 

더불어, 나는 심리적 안정을 위한 사수 였는지 반추하게 된다.

 

바쁜 시간의 업무속..

조금 더 친절하게

조금 더 자세하게

조금 더 많은 내용을
알려주지 못했음이 아쉬움으로 남는다.

 

과거는 바꿀 수 없음을 알기에 앞으로의 미래에 이를 인지하고 행동해야겠다.

 

---

| 일부 내용
'무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지 부터 이해하자' 라고 말하는 체스터슨의 울타리 원칙을 떠올려보세요.

 

외주를 맡긴 프로젝트를 인수 인계 받거나 기존의 레거시 프로젝트를 마이그레이션 하는 경우, 이런 생각을 가지게 된다. 

"이게 뭐지"

 

내가 사용하지 않는 방식이기에

내가 사용하지 않은 라이브러리이기에

내가 사용하지 않은 언어이기에 

등등 다양한 이유로 처음에는 거부감을 느끼게 된다.

 

나도 현업에서 갑자기 외주를 맡긴 프로젝트를 인수 인계 받아 서비스를 해야하는 상황에 동일하게 반응했다.

하지만, 시간을 들여 프로젝트 구조를 파악하고 커스터마이징된 부분을 파헤치다보면 어떤 의도로 이렇게 코드를 작성했는지 파악되는 순간이 오고 오히려 이러한 방식이 더 효율적이지 않을까 하고 생각이 변했던적도 있었다.