2022. 6. 8. 23:51ㆍETC/Software Engineering
본 포스팅은 Software Engineering at Google의 내용을 정리한 내용입니다.
해당 내용은 O'reilly에서 출간하고, 저자에 의해 공개된 Software Engineering at Google을 바탕으로 참고하여 정리한 내용입니다.
내용이 재밌기도 하고 기록하고 싶은 내용이 많아서 몇 가지 정리해볼 예정입니다.
Knowledge Sharing
조직에게 배움의 문화를 잡고 심리적 안전Psychological Safety을 제공해야 한다.
이 장의 핵심 내용은 아래 글귀가 대표할 수 있다.
always be learning; always be asking questions.
Challenges to Learning
한 조직에서 지식을 공유하는 일은 쉽지만은 않다.
이는 다양한 장애물이 있는데, 저자는 이 장애물을 아래와 같이 6가지 내용을 제시한다.
✔ Lack of psychological safety
심리적 안정감의 부족
본인의 부족함에 대해 비난이 걱정되어서 다른 사람들 앞에서 리스크를 감수하거나 실수하는 것을 두려워한다.
이 이유로 두려움이나 감추려는 성향을 띄는 문화가 보이곤 한다.
✔ Information islands
정보 섬
소통/공유 부족으로 지식들이 파편화되며, 그로 인해 아래와 같은 문제가 발생한다.
- 정보 파편화: 하나의 그림을 서로 다른, 불완전한 그림들로 채운다.
- 정보 중복: 각기 다른 방식으로 생산된다.
- 정보 왜곡: 같은 일에 대해 각자의 방법을 가지며, 서로 충돌 가능성이 있다.
✔ SPOF
single point of failure, 단일 장애점
한 사람이 중요한 정보를 독점하면서 병목이 생긴다. 지난 내용의 ‘버스 지수’와도 관련되는데 한 사람이 모든 걸 처리할 경우, 단기 효율은 높여주는 대신(‘내가 하는 게 빠르지’) 장기 확장성을 희생한다. 이는 아래의 ‘전부 아니면 전무 전문성’으로 이어진다.
✔ All-or-nothing expertise
전부 아니면 전무 전문성
조직 구성원이 ‘모든 것을 아는’ 사람과 ‘아무것도 모르는’ 사람으로 나뉜다.
한번 이렇게 되면 항상 모든 일을 전문가들만 처리하게 되어서
지식과 책임은 계속 전문가에게 집중되고, 초보들은 더디게 성장하게 된다.
✔ Parroting
앵무새처럼 흉내내기
이해하지 못한 상태로 흉내만 내는 것을 의미한다.
업무의 목적을 이해하지 못하고(‘이게 맞겠거니’) 무의식적으로 기존 패턴이나 코드를 따라 한다.
✔ Haunted graveyard
유령의 묘지
주로 코드에서 잘못될까봐 아무도 손대지 않는 영역을 말한다.
Setting the Stage
판깔아주기
무지에 대한 두려움을 없애는 문화가 필요하다.
자신이 이해하지 못한 게 있음을 인정해야 무언가를 배울 수 있다.
그래서 타인의 무지를 탓하지 말고 그 솔직함을 반겨야 한다.
배움에는 ‘무언가를 시도하다가 실패해도 안전하다’는 인식이 엄청나게 중요하다.
질문을 던지고, 틀리고, 새로운 지식을 얻는 걸 편안하게 생각해야 건강한 환경이 조성된다.
멘토제도
구글에는 멘토를 지정해서 심리적인 안전을 심어주고 성장을 독려한다.
팀원이나 테크 리드를 제외하여 최대한 편한 안전망이 되도록 한다.
편안한 근무환경을 조성하기 위해서는 협조적인 업무 문화를 이끌어 내려하는데, 소통 권장 방법을 제시한다.
아래는 그에 관련한 프로그래밍 교육 기관 Recurse Center의 규칙이다.
✔ 거짓 놀람 금지
“뭐라고?! 스택이 뭔지 모른다니 믿을 수가 없네!”
거짓된 놀람은 심리적 안전을 방해하여 구성원들은 모른다는 사실을 인정하기를 두려워하게 된다.
✔ “음, 실제로는” 금지
지나치게 깊이 고쳐주려는 행위는 정확한 방향을 이끌어 내려하기 보다는 자신의 지식을 뽐내려는 경향을 갖곤 한다.
✔ 뒷좌석 운전 금지
대화에 집중하지는 않는데 의견을 내기위해 말 도중 끼어들면 안된다.
✔ 미묘한 차별 금지
“이건 우리 할머니도 할 수 있겠네!”
인종주의, 연령주의, 동성애 혐오 발언 같이 편견이 깃든 표현은 다른 이에게 불편함과 무례함, 불안함을 느끼게 한다.
Growing Your Knowledge
인간이라면 언제나 아는 것보다 배워야 할 것이 많기 마련이다.
경력이 많은 엔지니어도 모르는 영역이 있고 전혀 문제될 일이 아니다.
모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이자.
우리는 무언가 배울 게 있는 환경에서 살아야 한다.
그렇지 않으면더 이상 성장하지 못할 것이다.
구글러들도 가면 증후군을 겪는 사람이 적지 않다.
실패를 두려워하기 쉽고 새로운 도전에 회피하려는 성향이 있다
하지만, 이를 꾸준히 극복해내며 성장해 나아가야 한다.
Chesterton’s fence
맥락이해하기
기존 코드를 이해하는데 시간을 쓰기보다는 차라리 처음부터 다시 짜고 싶어진다.
하지만 이 때, 이해할 수 없다고 성급히 결정짓지 말고, 맥락을 이해하려고 해야한다.
이 때, 체스터튼의 울타리 Chesterton’s fence 원칙을 떠올려보자.
짧게 '왜 그 자리에 있는지부터 이해하자’를 의미한다.
Chesterton’s fence
무언가를 좋은 방향으로 변경하는 문제에는 한 가지 분명하고 단순한 원칙이 있다.
예를 들어 도로를 가로지르는 울타리가 있다고 해보자.
보통의 사람들은 "무슨 용도로 울타리를 이렇게 설치했는지 모르겠군요. 깔끔히 밀어 버립시다" 라고말할것이다.
반면 현명한 유형의 사람은 다음과 같이 라고 말할 것이다.
"용도를 모르겠다면 그냥 밀어버리게 둘 순 없죠. 가서 더 생각해봅시다.
용도를 알아내면 그때 철거할지 결정하자고요"
엔지니어들은 성급히 ‘이건 잘못됐어’라고 결론 짓는 경향이 있다. 생소한 코드, 언어, 패러다임을 접했을 때는 더욱 심하다.
이 때에는 먼저 맥락을 찾아 이해해야 하며, 특히 정상이 아니라고 보이는 내용에 대해서는 더욱 필요하다.
더 낫다고 판단되면 고치고, 그렇지 않다면 미래에 다시 그 코드를 살펴볼 후임들을 위해 여러분이 생각한 근거를 적어두면 된다.
질문 확장하기
저자는 질문에 대한 중요성을 크게 갖고 전달한다.
질문하는 것에 두려움을 없애고 어디서든, 무엇이든 질문하는 것을 강조한다.
이때, 질문에 대한 답변을 가르치는 입장에서도, 또 배우는 쪽에서도 상세 내용을 모두 다 기억하기란 쉽지 않다.
그러니 미래의 자신을 위해서라도 무언가를 일대일로 배울 때는 ‘기록하는 습관’을 기르자.
또, 분명 또 다시 질문하는 사람이 생길 수 있으니 기록해둔 지식을 공유해야 한다.
커뮤니티를 통하여 이 질문을 확장시키는 것을 중요하게 다루는 것이다.
지식을 공유하는 많은 방법에 대해 예시를 들고 있는데, 자세히 다루지는 않겠다.
따로 요약만 하자면, 구글은 지식 공유를 위한 커뮤니티를 구성해두었다.
그룹 채팅, 메일링 리스트, 질의응답 플랫폼(구글 내부의 스택오버플로우와 같은 플랫폼) 과 같은 시스템을 통해 지식을 공유하는 문화를 이끌고 있다는 내용을 담는다.
참고로, 구글은 메일을 통한 의사소통을 정말 많이 한다고 한다. 이메일 기반 워크플로를 선호하며, 이는 단순히 익숙하기 때문이라고 한다. 이처럼 조직 내에서 익숙하고 사용성 좋은 소통 방식을 구축해 놓는 것을 제시한다.
누구나 가르칠 것이 있다
누구나 영역별로 다양한 수준의 전문성을 갖추고 있다.
조직이 성공하려면 다양성을 반드시 갖춰야 하는 이유도 이 때문이다.
현재 구글에서 독려하고, 실제로 사용하는 지식 전달의 방식을 아래의 세 가지로 소개한다.
✔ Office Hours : 누군가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트이다.
✔ 기술 강연/수업 : 구글은 구글 엔지니어부터 전 세계 학생들을 포함한 다양한 청중들에게 컴퓨터 과학을 교육하는 팀을 구성하며 강의한다.
✔ 문서 자료: 문서자료는 무언가를 배우도록 돕는 것을 최우선으로 하는 지식이다. 문서자료는 해당 상황에 맞춰 갱신되어야 하고, 문서화를 촉진 시켜야 한다.
사실 가장 중요한 것은, 이러한 지식 공유 문화를 장려하기 위해서는 지식 전파자들을 존중하고 보상하는 체계적인 제도를 마련해야 한다는 것이다.
전파자들에게 이 지식 공유에 대한 확실한 보상이 보이지 않는다면, 지속되기 어렵기 때문이다.
이번 장에서는 '지식 공유'에 대한 내용을 다룬다.
본인은 항상 모르는 게 많고 배울 게 많다고 생각했다.
항상 무엇인가 배우기 급급했고, 스스로의 무지가 드러나는 것이 민망하게 느껴져 위축되곤 했다.
이런 본인에게 '모르는 분야가 나오면 두려워하지 말고 성장하는 기회로 받아들이자'는 내용이 오래 기억에 남았다.
동일한 생각을 품고 있었는데, 이 내용이 외부에서 전달되니 선명하게 다가왔다.
또 이 내용은 실현하는게 어려웠는데, 아마 스스로가 정의내린 것에 확신이 없었던 것 같다.
이 내용에 확신을 가질 수 있어 오래 기억에 남은 듯 싶다.
재밌었던 내용 중 하나는 '맥락 이해하기'였다.
맥락을 이해해야 하는 이유를 보고 있으면 수긍이 되었고, 그 필요성 또한 타당하다고 판단되어서 나에게 직접 적용해보고 싶어졌다.
지금까지의 내용들은 공감을 느낄 수 있었고, 적용해보고 싶다는 생각을 할 수 있어 흥미롭게 읽었다.
이후의 몇 장들을 읽어보니 나에게 직접적으로 와닿는 내용은 적은듯 했다.
더 읽어보다가 기록하고 싶은 내용이 생기면 포스팅을 올려야겠다.
'ETC > Software Engineering' 카테고리의 다른 글
Documentation - Software Engineering at Google (0) | 2022.06.29 |
---|---|
Code Review Flow - Software Engineering at Google (0) | 2022.06.26 |
A Good Leader - Software Engineering at Google (0) | 2022.06.13 |
Work Well on Teams - Software Engineering at Google (0) | 2022.06.07 |
Software Engineering? - Software Engineering at Google (0) | 2022.06.04 |
Backend Software Engineer
𝐒𝐮𝐧 · 𝙂𝙮𝙚𝙤𝙣𝙜𝙨𝙪𝙣 𝙋𝙖𝙧𝙠