<div id="readability-page-1" class="page"><div id="entry-view">
        
        <main>
          <div>
              <article id="mainContent">
                <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 문화 - 2장 팀워크 이끌어내기</h3>
                </div>
                <p><cite>Berno</cite>
                  <span> 2022. 5. 30. 18:55</span>
                </p>
                
            
                <div>
                                <blockquote data-ke-style="style3"><span>더 뒤에 어떤 내용이 나올지 모르겠지만 2장에서 내가 원하던 내용이 나왔다는 느낌을 받았다. 나도 코드 리뷰를 무서워하며 숨기려 했던 적이 있고 조금 안다고 해서 겸손보다 자만에 가까웠다. 2장의 내용은 이런 개발자들을 위한 내용이다.</span></blockquote>


<h3 data-ke-size="size23">1. 불안감</h3>
<p data-ke-size="size16"><span>우리 주변 소프트웨어 엔지니어들에 대한 행동 관찰하면 이런 행동이 나타나는 경우가 있다.&nbsp;</span></p>
<p data-ke-size="size16"><span>코드를 숨긴다. 내가 만든 코드를 숨긴다. SCM히스토리를 제거하거나 숨길 수 있는지 찾아본다.</span><br><span>이 행동들은 불안감에서 비롯되었다. 내 작업물을 다른 사람들이 보고 판단하는 것을 두려워하는 인간의 본성에서 나왔을 것이라 예상한다. 사람은 누구나 비난보다는 칭찬을 받고 싶어 하는데 완성되기 이전의 작업물이라면 더욱 보여주기 불안해 할 수 있다. 문제는 이 불안감은 더 큰 문제의 징후임을 말해주고 있다.</span></p>
<h3 data-ke-size="size23"><span>2. 천재</span></h3>
<p data-ke-size="size16"><span>우리는 리누스 토발즈, 반 로섬, 빌 게이츠 같은 천재들이 아니다.(천재일 수 도 있지만 극소수에 불과하기에 이렇게 표현해보겠다.)</span><br><span>근데 과연 저 천재들이 혼자 모든 것을 해냈을까?</span><br><span>아니다. 다 주위에 있는 동료들과 함께 아이디어를 모으고 서로 작품을 공유하며 마스터피스에 가깝게 만들어나가 최종적으로 우리가 알고 있는 작품과 함께 이름을 날렸다.</span><br><span>그러면 왜 우리는 저 사람들에 대해 우상화를 했을까? 사람은 본능적으로 리더와 롤모델을 찾고 영감을 받으며 그들을 우상화하며 흉내 내려한다.</span><br><span>내면 깊숙한 곳에서 많은 엔지니어들은 외부에서 스스로가&nbsp;&nbsp;천재로, 영웅으로 비치기를 원한다. 그 환상이 실현되는 시나리오는 다음과 같다.</span></p>
<ul data-ke-list-type="disc">
<li><span>굉장히 새로운 아이디어가 생각난다.</span></li>
<li><span>동굴에 들어가 면벽 수련을 하며 이 좋은 아이디어를 버그 없이 완벽하게 구현한다.</span></li>
<li><span>구현된 소프트웨어가 세상에 공개되며 내 천재성에 모두가 충격을 받는다.</span></li>
<li><span>주위 사람들이 놀라워하고 경의를 표한다.</span></li>
<li><span>내 소프트웨어 사용자가 늘어난다.</span></li>
<li><span>돈과 명예가 따라온다.</span></li>
</ul>
<p data-ke-size="size16"><span>하지만 앞서 언급한 대로 우리는 천재가 아니다. 모든 회사에서 당신이 천재가 아님을 알고 당신을 채용한다. 그렇다면 우리는 무엇이 필요할까? 바로 사회성이다. 다른 엔지니어들과 화합을 하고 서로 같이 일하며 시너지를 발휘해야 더욱 좋은 작품을 만들 수 있다.</span><br><span>앞서 언급했지만 우리는 불안감으로 인해 우리의 미완성 작품을 숨기기에 바쁘다. 근데 그것과 마찬가지로 숨기려는 게 하나 더 있다. 바로 아이디어다. 누군가 내 아이디어를 듣고 그것을 나보다 빠르게 구현하여 세상에 내놓을지 모르는 것. 이 또한 불안감에서 나오는 현상이다.</span></p>
<h3 data-ke-size="size23"><span>3. 숨기는 건 나빠</span></h3>
<p data-ke-size="size16"><span>내가 앞서 언급한 천재들처럼 혼자 모든 개발을 완벽하게 할 수 있다면 우리에게는 동료가 필요 없을지도 모른다. 문제는 그 천재에 조금 못 미치는 사람들은 내가 가고 있는 방향이 맞는지 체크해줄 동료가 없다면 작품은 산으로 가게 될 수 있다.</span><br><span>위대한 아이디어를 세상으로부터 숨기고 완벽히 다듬어질 때까지 아무도 들여보지 못하게 하는 건 엄청난 도박이다. 피드백을 ‘조기에’ 받을수록 이 도박의 위험성은 현저히 줄어든다. </span><br><span>다음 마법의 문장을 기억해두자.</span></p>
<blockquote data-ke-style="style1"><span>일찍 실패하고, 빨리 실패하고, 자주 실패하라</span></blockquote>
<h3 data-ke-size="size23"><span>4. 버스 지수</span></h3>
<blockquote data-ke-style="style2"><span>버스 지수(Bus factor) : 몇 명의 팀원이 버스에 치여서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수</span></blockquote>
<p data-ke-size="size16"><span>프로젝트를 성공적으로 완수하기 위해서 우리는 우리의 코드가 팀원들에게 잘 공유가 되어야 한다. 혹시나 내가 예기치 못한 일이 발생하여 당분간, 혹은 영영 이 프로젝트에 참여하지 못하게 되었을 때 다른 사람이 내 부분을 이해하고 이어서 작업을 해나갈 수 있어야 한다.</span></p>
<blockquote data-ke-style="style1"><span>눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다.</span></blockquote>
<h3 data-ke-size="size23"><span>5. 숨기지 말자</span></h3>
<p data-ke-size="size16"><span>다른 사람에게 코드와 아이디어를 숨기느라 잘못된 방향, 일에 시간을 낭비하는 일이 없도록 하자.</span><br><span></span></p>
<h3 data-ke-size="size23"><span>6. 고기능 팀으로 가자.</span></h3>
<blockquote data-ke-style="style3"><br>고기능 팀 : 팀원 개개인이 팀과 조직의 공통 목표를 잘 인지하여 최선의 결과를 얻기 위해 주도적이고 적극적으로 노력하는 팀을 말한다.</blockquote>

<div data-ke-size="size16"><p><span>이 팀에 속한다면 우리는 성공(뛰어난 엔지니어, 부, 명예 등)으로 갈 확률이 높아진다.</span></p></div>
<h3 data-ke-size="size23"><span>7. 사회적 상호작용의 3요소</span><br><span></span></h3>
<p data-ke-size="size16"><span>딱 3가지만 기억하자.</span><br><b><span>겸손(humility), 존중(respect), 신뢰(trust)</span></b><br><span>이 3요소를 우리가 일상에서 실천하기 위해서 어떻게 해야 할까?</span><br><span>우선 자존심을 버려야 한다. 그래야 겸손해질 수 있다. </span><br><span>이어서 인내심을 기르고 다른 사람의 의견에 대해 마음을 열고 받아들이자.</span><br><span>그리고 비평하고 비평받는 법을 배우자. 단적인 예로 코드 리뷰 때 “이건 왜 이렇게 했어요? 바꿔요.” 가 아닌 “이 부분은 어떤 의도로 작성되었는지 알 수 있을까요? 아 그렇군요. 좋은데요? 근데 이렇게 하면 어떨까 한번 의견을 내볼게요”라고 말하는 연습을 해보자.</span><br><span>그리고 딱 하나 명심하자.</span></p>
<blockquote data-ke-style="style1"><span>나는 내 코드가 아니다.</span></blockquote>
<h3 data-ke-size="size23"><span>8. 포스트모템 문화</span><br><span></span></h3>
<p data-ke-size="size16"><span>실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심이다. 구글은 이 것을 포스트모템이라고 한다. </span><br><span>내가 걸어간 발자취는 함정을 밟거나 실패했던 흔적도 남아있다. 다른 사람이 이 길을 걸을 때 같은 실수를 범하지 않고 바른 길을 빠르게 올 수 있도록 도와주자.</span><br><span>훌륭한 포스트모템에는 다음 내용이 담겨야 한다.</span></p>
<ul data-ke-list-type="disc">
<li><span>사건의 개요</span></li>
<li><span>사건을 인지하고 해결에 이르기까지의 타임라인</span></li>
<li><span>사건의 근본 원인</span></li>
<li><span>영향과 피해 평가</span></li>
<li><span>문제를 즉시 해결하기 위한 조치 항목(소유자 명시)</span></li>
<li><span>재발 방지를 위한 조치 항목</span></li>
<li><span>해당 경험에서 얻은 교훈</span></li>
</ul>
<h3 data-ke-size="size23"><span>9. 구글다움</span><br><span></span></h3>
<ul data-ke-list-type="disc">
<li>모호함을 뚫고 번창한다.</li>
<li>피드백을 소중히 한다.</li>
<li>저항(향상성)을 극복한다.</li>
<li>사용자를 우선한다.</li>
<li>팀에 관심을 기울인다.</li>
<li>옳은 일을 한다.</li>
</ul>
<h3 data-ke-size="size23">10. 결론</h3>
<p data-ke-size="size16">우리는 창의적인 일을 하는 사람들이다. 항상 똑같은 기능을 만든다고 하지만 그 코드가 항상 같을 수는 없다. 새로운 코드를 작성할 때는 그 위험을 감수할 줄 알아야 하고 실패를 두려워하지 않아야 한다. 이 실패를 두려워하지 않고 인정을 하기 위해서는 건강한 팀 환경이 반드시 갖춰져야 한다.</p>
            
            
                </div>
            

                
              </article>
              
              
              
                
              
              
              
                
              
            </div>
        </main>
        
      </div></div>

흔한 컴공출신 개발자

bernoyoun

더 뒤에 어떤 내용이 나올지 모르겠지만 2장에서 내가 원하던 내용이 나왔다는 느낌을 받았다. 나도 코드 리뷰를 무서워하며 숨기려 했던 적이 있고 조금 안다고 해서 겸손보다 자만에 가까웠다. 2장의 내용은 이런 개발자들을 위한 내용이다.
 
 
1. 불안감
우리 주변 소프트웨어 엔지니어들에 대한 행동 관찰하면 이런 행동이 나타나는 경우가 있다. 
코드를 숨긴다. 내가 만든 코드를 숨긴다. SCM히스토리를 제거하거나 숨길 수 있는지 찾아본다.
이 행동들은 불안감에서 비롯되었다. 내 작업물을 다른 사람들이 보고 판단하는 것을 두려워하는 인간의 본성에서 나왔을 것이라 예상한다. 사람은 누구나 비난보다는 칭찬을 받고 싶어 하는데 완성되기 이전의 작업물이라면 더욱 보여주기 불안해 할 수 있다. 문제는 이 불안감은 더 큰 문제의 징후임을 말해주고 있다.
2. 천재
우리는 리누스 토발즈, 반 로섬, 빌 게이츠 같은 천재들이 아니다.(천재일 수 도 있지만 극소수에 불과하기에 이렇게 표현해보겠다.)
근데 과연 저 천재들이 혼자 모든 것을 해냈을까?
아니다. 다 주위에 있는 동료들과 함께 아이디어를 모으고 서로 작품을 공유하며 마스터피스에 가깝게 만들어나가 최종적으로 우리가 알고 있는 작품과 함께 이름을 날렸다.
그러면 왜 우리는 저 사람들에 대해 우상화를 했을까? 사람은 본능적으로 리더와 롤모델을 찾고 영감을 받으며 그들을 우상화하며 흉내 내려한다.
내면 깊숙한 곳에서 많은 엔지니어들은 외부에서 스스로가  천재로, 영웅으로 비치기를 원한다. 그 환상이 실현되는 시나리오는 다음과 같다.
굉장히 새로운 아이디어가 생각난다.
동굴에 들어가 면벽 수련을 하며 이 좋은 아이디어를 버그 없이 완벽하게 구현한다.
구현된 소프트웨어가 세상에 공개되며 내 천재성에 모두가 충격을 받는다.
주위 사람들이 놀라워하고 경의를 표한다.
내 소프트웨어 사용자가 늘어난다.
돈과 명예가 따라온다.
하지만 앞서 언급한 대로 우리는 천재가 아니다. 모든 회사에서 당신이 천재가 아님을 알고 당신을 채용한다. 그렇다면 우리는 무엇이 필요할까? 바로 사회성이다. 다른 엔지니어들과 화합을 하고 서로 같이 일하며 시너지를 발휘해야 더욱 좋은 작품을 만들 수 있다.
앞서 언급했지만 우리는 불안감으로 인해 우리의 미완성 작품을 숨기기에 바쁘다. 근데 그것과 마찬가지로 숨기려는 게 하나 더 있다. 바로 아이디어다. 누군가 내 아이디어를 듣고 그것을 나보다 빠르게 구현하여 세상에 내놓을지 모르는 것. 이 또한 불안감에서 나오는 현상이다.
3. 숨기는 건 나빠
내가 앞서 언급한 천재들처럼 혼자 모든 개발을 완벽하게 할 수 있다면 우리에게는 동료가 필요 없을지도 모른다. 문제는 그 천재에 조금 못 미치는 사람들은 내가 가고 있는 방향이 맞는지 체크해줄 동료가 없다면 작품은 산으로 가게 될 수 있다.
위대한 아이디어를 세상으로부터 숨기고 완벽히 다듬어질 때까지 아무도 들여보지 못하게 하는 건 엄청난 도박이다. 피드백을 ‘조기에’ 받을수록 이 도박의 위험성은 현저히 줄어든다. 
다음 마법의 문장을 기억해두자.
일찍 실패하고, 빨리 실패하고, 자주 실패하라
4. 버스 지수
버스 지수(Bus factor) : 몇 명의 팀원이 버스에 치여서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수
프로젝트를 성공적으로 완수하기 위해서 우리는 우리의 코드가 팀원들에게 잘 공유가 되어야 한다. 혹시나 내가 예기치 못한 일이 발생하여 당분간, 혹은 영영 이 프로젝트에 참여하지 못하게 되었을 때 다른 사람이 내 부분을 이해하고 이어서 작업을 해나갈 수 있어야 한다.
눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다.
5. 숨기지 말자
다른 사람에게 코드와 아이디어를 숨기느라 잘못된 방향, 일에 시간을 낭비하는 일이 없도록 하자.
6. 고기능 팀으로 가자.
고기능 팀 : 팀원 개개인이 팀과 조직의 공통 목표를 잘 인지하여 최선의 결과를 얻기 위해 주도적이고 적극적으로 노력하는 팀을 말한다.
 
이 팀에 속한다면 우리는 성공(뛰어난 엔지니어, 부, 명예 등)으로 갈 확률이 높아진다.
7. 사회적 상호작용의 3요소
딱 3가지만 기억하자.
겸손(humility), 존중(respect), 신뢰(trust)
이 3요소를 우리가 일상에서 실천하기 위해서 어떻게 해야 할까?
우선 자존심을 버려야 한다. 그래야 겸손해질 수 있다. 
이어서 인내심을 기르고 다른 사람의 의견에 대해 마음을 열고 받아들이자.
그리고 비평하고 비평받는 법을 배우자. 단적인 예로 코드 리뷰 때 “이건 왜 이렇게 했어요? 바꿔요.” 가 아닌 “이 부분은 어떤 의도로 작성되었는지 알 수 있을까요? 아 그렇군요. 좋은데요? 근데 이렇게 하면 어떨까 한번 의견을 내볼게요”라고 말하는 연습을 해보자.
그리고 딱 하나 명심하자.
나는 내 코드가 아니다.
8. 포스트모템 문화
실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심이다. 구글은 이 것을 포스트모템이라고 한다. 
내가 걸어간 발자취는 함정을 밟거나 실패했던 흔적도 남아있다. 다른 사람이 이 길을 걸을 때 같은 실수를 범하지 않고 바른 길을 빠르게 올 수 있도록 도와주자.
훌륭한 포스트모템에는 다음 내용이 담겨야 한다.
사건의 개요
사건을 인지하고 해결에 이르기까지의 타임라인
사건의 근본 원인
영향과 피해 평가
문제를 즉시 해결하기 위한 조치 항목(소유자 명시)
재발 방지를 위한 조치 항목
해당 경험에서 얻은 교훈
9. 구글다움
모호함을 뚫고 번창한다.
피드백을 소중히 한다.
저항(향상성)을 극복한다.
사용자를 우선한다.
팀에 관심을 기울인다.
옳은 일을 한다.
10. 결론
우리는 창의적인 일을 하는 사람들이다. 항상 똑같은 기능을 만든다고 하지만 그 코드가 항상 같을 수는 없다. 새로운 코드를 작성할 때는 그 위험을 감수할 줄 알아야 하고 실패를 두려워하지 않아야 한다. 이 실패를 두려워하지 않고 인정을 하기 위해서는 건강한 팀 환경이 반드시 갖춰져야 한다.

구글 엔지니어는 이렇게 일한다 part2 문화 - 2장 팀워크 이끌어내기

댓글