<div id="readability-page-1" class="page"><div>
                  <p><a href="/m/category/%EA%B5%AC%EA%B8%80%20%EC%97%94%EC%A7%80%EB%8B%88%EC%96%B4%EB%8A%94%20%EC%9D%B4%EB%A0%87%EA%B2%8C%20%EC%9D%BC%ED%95%9C%EB%8B%A4"><span>구글 엔지니어는 이렇게 일한다</span></a></p><h3>구글 엔지니어는 이렇게 일한다 part2 문화 - 3장 지식 공유</h3>
                </div><p><cite>Berno</cite>
                  <span> 2022. 5. 31. 18:50</span>
                </p><div>
                                <blockquote data-ke-style="style3"><span>지식 공유에 대한 문화가 없는 팀에서 대략 2년 동안 문화를 만들기 위해 노력을 해보았지만 실패하였다. 이제 2~3년 차 주니어 개발자가 파악하지 못한 이슈가 있었을 수도 있고 더 노력을 했어야 했을 수 도 있지만 결론은 문화를 만드는데 실패하였다. 이직을 앞둔 상황에서 이 장을 읽으며 다시 한번 지난 노력을 생각해보았다.</span></blockquote>
<h3 data-ke-size="size23"><span>0. 들어가며</span></h3>
<div data-ke-size="size16"><p><span>조직에는 각 분야에 대한 전문가들이 필요하다. 전문가는 문제에 대한 답을 스스로 도출할 수 있어야하고 다른 사람의 질문에 대해 답을 줄 수 있어야 한다. 지식 공유를 하기 위해서는 전문가와 더불어 지식을 전파할 메커니즘도 필요하다. 배움의 문화가 자리 잡혀 있어야 하고 이 배움의 문화가 자리잡기 위해서는 사람들에게 모르는 부분을 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다.</span></p></div>
<h3 data-ke-size="size23"><span>1. 장애물</span></h3>
<div data-ke-size="size16"><p><span>조직에서 전문성을 공유하는 일은 쉽지 않다. 구글에서도 다음과 같은 일들을 겪었다.</span></p></div>
<h4 data-ke-size="size20"><span><b>심리적 안전 부족(lackof psychological safety)</b></span></h4>
<div data-ke-size="size16"><p><span>불이익이 두려워 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경(2장의 불안감과 유사하다)</span></p></div>
<h4 data-ke-size="size20"><span><b>정보 섬(information islands)</b></span></h4>
<div data-ke-size="size16"><p><span>조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아 지식이 파편화된다. 이로 인해 정보 중복, 정보 왜곡 등의 현상이 발생한다.</span></p></div>
<h4 data-ke-size="size20"><span><b>단일 장애점(single point of failure)</b></span></h4>
<div data-ke-size="size16"><p><span>정보의 병목 현상이 생긴다. 한 명의 영웅이 나타나서 모든 일을 처리하면 참 좋은 일일 수 있지만 그로 인해 다른 사람은 그 일에 대한 정보가 무지해질 수 있다.</span></p></div>
<h4 data-ke-size="size20"><span><b>전부 아니면 전무 전문성(all or nothing expertise</b>)</span></h4>
<div data-ke-size="size16"><p><span>단일 장애점과 비슷한 현상이다. 조직 구성원이 ‘모든 것을 아는 사람’과 ‘아무것도 모르는 사람’으로 나누어진다.</span></p></div>
<h4 data-ke-size="size20"><span><b>앵무새처럼 흉내내기(parroting)</b></span></h4>
<div data-ke-size="size16"><p><span>이해하지 못했지만 그저 앵무새가 소리를 따라 하는 것처럼 흉내만 내게 된다.</span></p></div>
<h4 data-ke-size="size20"><span><b>유령의 묘지(haunted graveyard)</b></span></h4>
<div data-ke-size="size16"><p><span>어떤 일이 발생할지는 잘 모르겠고 위험을 감수하고 싶지 않아 아무도 손대지 않는 영역(기술, 코드 등)을 말한다. </span></p></div>
<h3 data-ke-size="size23"><span>2. 철학</span></h3>
<div data-ke-size="size16"><p><span>소프트웨어 엔지니어링은 <b><span>‘여러 버전의 프로그램을 여러 사람이 참여해 개발하는 일’</span></b>이라고도 할 수 있다. 소프트웨어 엔지니어링에서 가장 중요한 요소는 사람이다.</span><br><span>팀원 개개인의 지식과 문서화된 정보 중간 어딘가에는 현장 지식이 존재한다. 기록은 되어있지 않고 개개인의 지식으로 인식은 되어있지 않지만 현장에 대한 지식을 말한다. 이 지식도 기록을 하게 된다면 모두에게 전파를 할 수 있다.</span><br><span>조직 스스로 교육하고, 배우고 성장하는데 집중하고, 충분한 수의 전문가를 양성해야 한다. <b>전문가가 많다고 손해 보는 일은 없기 때문이다.</b></span></p></div>
<h3 data-ke-size="size23"><span>3. 심리적 안전</span></h3>
<div data-ke-size="size16"><p><span>학습 환경을 조성하는데 가장 중요한 부분이다. 우선 내가 모르거나 이해하지 못한 부분이 있음을 인정해야 한다. 다른 사람을 탓하지 말고 모르는 부분이 있다면 뉴비에게 소매 넣기 하기 전 반기는 것처럼 이 행위를 반겨야 한다. 안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화이다. 이를 위해 가져야 할 자세를 어떻게 말해야 할지 잘 되어있는 것으로 프로그래밍 교육 기관 Recurse Center에서 사용되는 규칙 중 일부를 가져왔다.</span></p></div>
<h4 data-ke-size="size20"><span>거짓된 놀람 금지(“뭐??? 스택이 뭔지를 몰라? 이거 믿을 수가 없는데!”)</span></h4>
<p data-ke-size="size16"><span>거짓된 놀람은 심리적 안전을 방해하여 구성원들이 모른다는 사실을 인정하기 두려워하게 한다.</span></p>
<h4 data-ke-size="size20"><span>“음.. 실제로는…” 금지</span></h4>
<p data-ke-size="size16"><span>지나칠 정도로 세세하게 고쳐주는 행위는 정밀성보다 자신을 뽐내려는 무의식에 기인하는 경향이 있다.</span></p>
<h4 data-ke-size="size20"><span>뒷좌석 운전 금지</span></h4>
<p data-ke-size="size16"><span>적절한 발언권 없이 끼어들어 의견 제시하지 않기</span></p>
<h4 data-ke-size="size20"><span>미묘한 ‘-주의’ 금지</span></h4>
<div data-ke-size="size16"><p><span>인종, 연령주의, 동성애 혐오 발언과 같이 편견이 깃든 표현은 듣는 사람에게 불편함과 무례함, 불안함을 느끼게 한다.</span></p><p><span>또한 심리적 안전을 조성하기 위해서는 끈기를 가지고 상냥하게 답변을 해줘야 한다. 그래야 사람들이 안심하고 도움을 청하는 환경이 조성된다. 사소한 질문이라도 답을 얻게 할 수 있는 환경을 만들기 위해 노력하자.</span></p></div>
<h3 data-ke-size="size23"><span>4. 멘토</span></h3>
<div data-ke-size="size16"><p><span>구글에서는 누 글러가 합류하자마자 분위기를 만들어주려 노력한다. 멘토 정해주기는 누글러에게 심리적 안전을 심어주는 효과적인 방법이다. 멘토는 누글러가 속한 팀의 팀원이나 관리자, 테크 리드는 제외된다. 멘토는 지원자 중에 선별하고 1년 이상 근무를 했으며 인프라부터 문화에 이르기까지 무엇이든 조언을 해줄 수 있어야 한다.</span></p></div>
<h3 data-ke-size="size23"><span>5. 내 지식 키우기</span></h3>
<p data-ke-size="size16"><span>우리가 항상 잊지 말아야 할 문장이 있다.</span></p>
<blockquote data-ke-style="style1"><span>항상 배우고 항상 질문하라.<br>모르는 분야가 나온다면 두려워하지 말고 성장하는 기회로 받아들이자.</span></blockquote>
<p data-ke-size="size16"><br><span>우리가 새로운 팀에 합류한 후 새로운 기능을 만들기 위해 기존 레거시 코드를 볼 때 이 코드는 내가 봤을 때 왜 이렇게 했는지 이해가 안 되는 경우가 있다. 심한 경우 처음부터 다시 짜는 게 더 편하겠다 라는 부분이 있을 수 있다. 이해는 되지만 조금만 내려놓고 다음 문장을 기억하자.</span></p>
<blockquote data-ke-style="style1"><span>무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자.</span></blockquote>
<div data-ke-size="size16"><p><span>우리가 모르는 부분이 생긴다면 커뮤니티에 물어본다는 좋은 선택지도 있다. 요새는 카카오톡 오픈 채팅방도 잘 되어있고 페이스북 그룹이나 stackoverflow 같은 커뮤니티가 너무 잘 되어있다. </span><br><span>내 지식을 키운다는 건 단순히 공부를 하는 것만 포함되는 게 아니다. 다른 사람을 가르치는 행위에서 다시 한번 내 지식을 견고하게 만들 수 있다. 가르친다는 건 전문가의 전유물이 아니다.</span></p><p><span>때로는 사람과 직접 대화를 해야 쉽게 풀리는 문제들이 있다. 그런 경우는 오피스 아워(office hours)가 좋은 해결책이 될 수 있다. 오피스 아워는 누군가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트다. 하지만 지식 공유를 목적으로 오피스 아워를 최우선으로 활용하는 경우는 거의 없다. 왜냐하면 당장 급한데 다음 오피스 아워를 기다리는 건 고역이기 때문이다.</span></p><p><span>구글의 g2g(google2googler)프로그램은 구글러라면 누구나 가입하여 동료들을 위한 수업을 개설하거나 참석할 수 있다. 업무에 도움이 되지 않는 스윙 댄스나 서예부터 모던 cpu에서의 벡터화 이해 같은 기술적 주제까지 누구나 자유롭게 개설하고 참석할 수 있다. 수업을 극대화하는 조건은 다음과 같다.</span></p></div>
<ul data-ke-list-type="disc">
<li><span>자주 오해를 일으킬 정도로 복잡한 주제를 다뤄야 한다. 수업 개설은 비용이 크므로 해결해야 할 분명한 요구가 있을 때 만들어져야 한다.</span></li>
<li><span>주제가 비교적 안정적이어야 한다. 수업 교재를 고치는 것도 큰 일이므로 내용이 자주 바뀐다면 다른 공유 형태를 찾아보자.</span></li>
<li><span>질문에 답해주고 일대일로 도와줄 수 있는 교수가 있어야 효과가 큰 주제여야 한다.</span></li>
<li><span>수업을 정기적으로 개설해도 될 만큼 수요가 많아야 한다.</span></li>
</ul>
<div data-ke-size="size16"><p><span>무언가를 막 배운 상태라면 문서화가 지식을 견고하게 만드는데 도움이 될 수 있다. 기존에 있던 문서자료를 갱신하거나 새로 작성하는 작업을 해보자.</span><br><span>윗 문장에서 문서화를 하자고 했는데 바로 말을 바꾸자는 건 아니고 문서화를 정착하기 어려운 이유를 조금 적어보자. 우선 시간이 많이 들어간다. 가뜩이나 개발할 시간도 없는데 문서화까지 강제한다는 건 너무나 고역이다. 소수가 다수에게 도움을 주는 작업이지만 기여자와 수혜자가 달라 적절한 보상 없이는 문화를 정착시키기 어렵다. 이 보상에 대해 잘 돌아가도록 고민이 필요하다.</span></p></div>
<h3 data-ke-size="size23"><span>6. 조직의 지식 키우기</span></h3>
<div data-ke-size="size16"><p><span>조직이 커질수록 전문 지식을 전반에 제대로 공유하기 어렵다.</span><br><span>조직 내에서 지식 공유 문화를 만들기 위해 우리는 2가지 키워드를 주의해야 한다.</span></p></div>
<h4 data-ke-size="size20"><span>존중</span></h4>
<div data-ke-size="size16"><p><span>지식을 공유할 때는 상냥함과 존중을 담아야 하고 또 그래야만 가능하다. 기술 업계에서는 뛰어난 괴짜를 용인하는 경향이 있지만 이는 해로운 현상이다.</span></p></div>
<h4 data-ke-size="size20"><span>보상과 인정</span></h4>
<div data-ke-size="size16"><p><span>지식 공유 문화를 장려하려면 인정과 보상 제도가 뒷받침되어야 한다.</span></p><p><span>조직의 지식을 키우는 방식으로 표준 정보 소스를 구축이 있다.</span><br><span>표준 정보 소스라고 하니 뭔가 어려워 보이지만 우리가 겪어본 것들이 있다.</span></p></div>
<ul data-ke-list-type="disc">
<li><span>개발자 가이드(코딩 스타일 가이드 포함)</span></li>
<li><span>go/링크 (특정 정보로 바로 접근할 수 있는 링크)</span></li>
<li>코드랩</li>
<li><span>정적 분석</span></li>
</ul>
<p data-ke-size="size16"><br><span>단 이 과정에서 소외되는 사람이 있을 수 있다. 나에게 필요한 정보가 없었거나 기여할 기외가 없던 사람들도 있었을 수 있다. 이런 사람들이 소외되지 않기 위해 정보를 항상 공유해주어야 한다.</span></p>
<h4 data-ke-size="size20"><span>뉴스레터</span></h4>
<p data-ke-size="size16"><span>뉴스레터는 정보 공유의 좋은 수단 중 하나이다. 구글에서는 특이하게 화장실 벽에 붙이는 한 쪽짜리 뉴스레터가 있는데 볼일을 보며 가볍게 읽을 주제로 구성되어있고 이 내용 또한 온라인으로도 제공한다.</span></p>
<h4 data-ke-size="size20"><span>커뮤니티</span></h4>
<div data-ke-size="size16"><p><span>커뮤니티는 서로 소통하며 지식을 키우는 좋은 수단이다.</span></p></div>
<h3 data-ke-size="size23"><span>7. 결론</span></h3>
<div data-ke-size="size16"><p><span>문화를 정착하기 위해서는 현재 조직의 상태를 파악하고 사람 간의 겸손과 존중이 기본적으로 되어 있으며 보상이 이루어져야 한다.</span></p></div>
            
            
                </div></div>

흔한 컴공출신 개발자

bernoyoun

지식 공유에 대한 문화가 없는 팀에서 대략 2년 동안 문화를 만들기 위해 노력을 해보았지만 실패하였다. 이제 2~3년 차 주니어 개발자가 파악하지 못한 이슈가 있었을 수도 있고 더 노력을 했어야 했을 수 도 있지만 결론은 문화를 만드는데 실패하였다. 이직을 앞둔 상황에서 이 장을 읽으며 다시 한번 지난 노력을 생각해보았다.
0. 들어가며
조직에는 각 분야에 대한 전문가들이 필요하다. 전문가는 문제에 대한 답을 스스로 도출할 수 있어야하고 다른 사람의 질문에 대해 답을 줄 수 있어야 한다. 지식 공유를 하기 위해서는 전문가와 더불어 지식을 전파할 메커니즘도 필요하다. 배움의 문화가 자리 잡혀 있어야 하고 이 배움의 문화가 자리잡기 위해서는 사람들에게 모르는 부분을 인정할 수 있도록 돕는 심리적 안전을 제공해야 한다.
1. 장애물
조직에서 전문성을 공유하는 일은 쉽지 않다. 구글에서도 다음과 같은 일들을 겪었다.
심리적 안전 부족(lackof psychological safety)
불이익이 두려워 스스로 위험을 감수하거나 실수를 드러내기 꺼리는 환경(2장의 불안감과 유사하다)
정보 섬(information islands)
조직의 각 부서가 서로 소통하거나 자원을 공유하지 않아 지식이 파편화된다. 이로 인해 정보 중복, 정보 왜곡 등의 현상이 발생한다.
단일 장애점(single point of failure)
정보의 병목 현상이 생긴다. 한 명의 영웅이 나타나서 모든 일을 처리하면 참 좋은 일일 수 있지만 그로 인해 다른 사람은 그 일에 대한 정보가 무지해질 수 있다.
전부 아니면 전무 전문성(all or nothing expertise)
단일 장애점과 비슷한 현상이다. 조직 구성원이 ‘모든 것을 아는 사람’과 ‘아무것도 모르는 사람’으로 나누어진다.
앵무새처럼 흉내내기(parroting)
이해하지 못했지만 그저 앵무새가 소리를 따라 하는 것처럼 흉내만 내게 된다.
유령의 묘지(haunted graveyard)
어떤 일이 발생할지는 잘 모르겠고 위험을 감수하고 싶지 않아 아무도 손대지 않는 영역(기술, 코드 등)을 말한다. 
2. 철학
소프트웨어 엔지니어링은 ‘여러 버전의 프로그램을 여러 사람이 참여해 개발하는 일’이라고도 할 수 있다. 소프트웨어 엔지니어링에서 가장 중요한 요소는 사람이다.
팀원 개개인의 지식과 문서화된 정보 중간 어딘가에는 현장 지식이 존재한다. 기록은 되어있지 않고 개개인의 지식으로 인식은 되어있지 않지만 현장에 대한 지식을 말한다. 이 지식도 기록을 하게 된다면 모두에게 전파를 할 수 있다.
조직 스스로 교육하고, 배우고 성장하는데 집중하고, 충분한 수의 전문가를 양성해야 한다. 전문가가 많다고 손해 보는 일은 없기 때문이다.
3. 심리적 안전
학습 환경을 조성하는데 가장 중요한 부분이다. 우선 내가 모르거나 이해하지 못한 부분이 있음을 인정해야 한다. 다른 사람을 탓하지 말고 모르는 부분이 있다면 뉴비에게 소매 넣기 하기 전 반기는 것처럼 이 행위를 반겨야 한다. 안전하고 편안한 근무 환경을 조성하기 위해 가장 필요한 것은 적대적이지 않고 협조적으로 일하는 문화이다. 이를 위해 가져야 할 자세를 어떻게 말해야 할지 잘 되어있는 것으로 프로그래밍 교육 기관 Recurse Center에서 사용되는 규칙 중 일부를 가져왔다.
거짓된 놀람 금지(“뭐??? 스택이 뭔지를 몰라? 이거 믿을 수가 없는데!”)
거짓된 놀람은 심리적 안전을 방해하여 구성원들이 모른다는 사실을 인정하기 두려워하게 한다.
“음.. 실제로는…” 금지
지나칠 정도로 세세하게 고쳐주는 행위는 정밀성보다 자신을 뽐내려는 무의식에 기인하는 경향이 있다.
뒷좌석 운전 금지
적절한 발언권 없이 끼어들어 의견 제시하지 않기
미묘한 ‘-주의’ 금지
인종, 연령주의, 동성애 혐오 발언과 같이 편견이 깃든 표현은 듣는 사람에게 불편함과 무례함, 불안함을 느끼게 한다.
또한 심리적 안전을 조성하기 위해서는 끈기를 가지고 상냥하게 답변을 해줘야 한다. 그래야 사람들이 안심하고 도움을 청하는 환경이 조성된다. 사소한 질문이라도 답을 얻게 할 수 있는 환경을 만들기 위해 노력하자.
4. 멘토
구글에서는 누 글러가 합류하자마자 분위기를 만들어주려 노력한다. 멘토 정해주기는 누글러에게 심리적 안전을 심어주는 효과적인 방법이다. 멘토는 누글러가 속한 팀의 팀원이나 관리자, 테크 리드는 제외된다. 멘토는 지원자 중에 선별하고 1년 이상 근무를 했으며 인프라부터 문화에 이르기까지 무엇이든 조언을 해줄 수 있어야 한다.
5. 내 지식 키우기
우리가 항상 잊지 말아야 할 문장이 있다.
항상 배우고 항상 질문하라.
모르는 분야가 나온다면 두려워하지 말고 성장하는 기회로 받아들이자.
우리가 새로운 팀에 합류한 후 새로운 기능을 만들기 위해 기존 레거시 코드를 볼 때 이 코드는 내가 봤을 때 왜 이렇게 했는지 이해가 안 되는 경우가 있다. 심한 경우 처음부터 다시 짜는 게 더 편하겠다 라는 부분이 있을 수 있다. 이해는 되지만 조금만 내려놓고 다음 문장을 기억하자.
무언가를 옮기거나 바꾸려면 그게 왜 그 자리에 있는지부터 이해하자.
우리가 모르는 부분이 생긴다면 커뮤니티에 물어본다는 좋은 선택지도 있다. 요새는 카카오톡 오픈 채팅방도 잘 되어있고 페이스북 그룹이나 stackoverflow 같은 커뮤니티가 너무 잘 되어있다. 
내 지식을 키운다는 건 단순히 공부를 하는 것만 포함되는 게 아니다. 다른 사람을 가르치는 행위에서 다시 한번 내 지식을 견고하게 만들 수 있다. 가르친다는 건 전문가의 전유물이 아니다.
때로는 사람과 직접 대화를 해야 쉽게 풀리는 문제들이 있다. 그런 경우는 오피스 아워(office hours)가 좋은 해결책이 될 수 있다. 오피스 아워는 누군가 특정 주제에 관한 질문에 답해줄 목적으로 시간을 비워 둔 정기적인 이벤트다. 하지만 지식 공유를 목적으로 오피스 아워를 최우선으로 활용하는 경우는 거의 없다. 왜냐하면 당장 급한데 다음 오피스 아워를 기다리는 건 고역이기 때문이다.
구글의 g2g(google2googler)프로그램은 구글러라면 누구나 가입하여 동료들을 위한 수업을 개설하거나 참석할 수 있다. 업무에 도움이 되지 않는 스윙 댄스나 서예부터 모던 cpu에서의 벡터화 이해 같은 기술적 주제까지 누구나 자유롭게 개설하고 참석할 수 있다. 수업을 극대화하는 조건은 다음과 같다.
자주 오해를 일으킬 정도로 복잡한 주제를 다뤄야 한다. 수업 개설은 비용이 크므로 해결해야 할 분명한 요구가 있을 때 만들어져야 한다.
주제가 비교적 안정적이어야 한다. 수업 교재를 고치는 것도 큰 일이므로 내용이 자주 바뀐다면 다른 공유 형태를 찾아보자.
질문에 답해주고 일대일로 도와줄 수 있는 교수가 있어야 효과가 큰 주제여야 한다.
수업을 정기적으로 개설해도 될 만큼 수요가 많아야 한다.
무언가를 막 배운 상태라면 문서화가 지식을 견고하게 만드는데 도움이 될 수 있다. 기존에 있던 문서자료를 갱신하거나 새로 작성하는 작업을 해보자.
윗 문장에서 문서화를 하자고 했는데 바로 말을 바꾸자는 건 아니고 문서화를 정착하기 어려운 이유를 조금 적어보자. 우선 시간이 많이 들어간다. 가뜩이나 개발할 시간도 없는데 문서화까지 강제한다는 건 너무나 고역이다. 소수가 다수에게 도움을 주는 작업이지만 기여자와 수혜자가 달라 적절한 보상 없이는 문화를 정착시키기 어렵다. 이 보상에 대해 잘 돌아가도록 고민이 필요하다.
6. 조직의 지식 키우기
조직이 커질수록 전문 지식을 전반에 제대로 공유하기 어렵다.
조직 내에서 지식 공유 문화를 만들기 위해 우리는 2가지 키워드를 주의해야 한다.
존중
지식을 공유할 때는 상냥함과 존중을 담아야 하고 또 그래야만 가능하다. 기술 업계에서는 뛰어난 괴짜를 용인하는 경향이 있지만 이는 해로운 현상이다.
보상과 인정
지식 공유 문화를 장려하려면 인정과 보상 제도가 뒷받침되어야 한다.
조직의 지식을 키우는 방식으로 표준 정보 소스를 구축이 있다.
표준 정보 소스라고 하니 뭔가 어려워 보이지만 우리가 겪어본 것들이 있다.
개발자 가이드(코딩 스타일 가이드 포함)
go/링크 (특정 정보로 바로 접근할 수 있는 링크)
코드랩
정적 분석
단 이 과정에서 소외되는 사람이 있을 수 있다. 나에게 필요한 정보가 없었거나 기여할 기외가 없던 사람들도 있었을 수 있다. 이런 사람들이 소외되지 않기 위해 정보를 항상 공유해주어야 한다.
뉴스레터
뉴스레터는 정보 공유의 좋은 수단 중 하나이다. 구글에서는 특이하게 화장실 벽에 붙이는 한 쪽짜리 뉴스레터가 있는데 볼일을 보며 가볍게 읽을 주제로 구성되어있고 이 내용 또한 온라인으로도 제공한다.
커뮤니티
커뮤니티는 서로 소통하며 지식을 키우는 좋은 수단이다.
7. 결론
문화를 정착하기 위해서는 현재 조직의 상태를 파악하고 사람 간의 겸손과 존중이 기본적으로 되어 있으며 보상이 이루어져야 한다.

구글 엔지니어는 이렇게 일한다 part2 문화 - 3장 지식 공유

댓글