이번 장의 핵심 주제는 소프트웨어 개발은 팀의 단합된 노력의 결실이라는 점이다. 그래서 엔지니어링팀이 성공하려면 겸손, 존중, 신뢰라는 핵심 원칙에 맞게 자신의 행동을 바로잡아야 한다.
2.1 내 코드를 숨기고 싶어요
사람들은 자신이 진행 중인 작업물을 다른 사람이 보고 판단하는 걸 두려워 한다. 이러한 불안감은 소프트웨어 개발에서의 더 큰 문제의 징후임을 찾아냈다.
2.2 천재 신화
리눅스를 개발한 라누스, 파이썬을 개발한 귀도 반 로섬 등 처음 시작을 한 것은 맞지만 궁극적으로 수백, 수천명의 인재들이 함께 개발을 진행하며 지금의 자리에 올 수 있었다.
인간은 본능적으로 리더와 롤모델을 찾고, 그들을 우상화하고 흉내내려 한다. 프로그래밍 세계에서도 기술 전문가 셀럽 현상이 거의 신화화되어 가고 있다. 천재라고 해서 괴짜처럼 행동하는 게 용서 받는 시대는 지났다. 천재든 아니든 사회성이 부족한 사람은 팀원으로 적합하지 않기 때문이다. 구글에서의 업무의 대부분은 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구한다. 핵심은 다른 사람과 얼마나 잘 협력하느냐 이다.
2.3 숨기는 건 해롭다
오롯이 홀로 일한다면 실패할 위험성을 불필요하게 키우고 자신의 성장 잠재력을 속이는 것이다.
2.3.1 조기 감지
위대한 아이디어를 세상으로부터 숨기고 완벽히 다듬어질 때까지 아무도 들여다보지 못하게 하는 건 엄청난 도박이다. 초기 설계에는 근본적인 실수가 스며 있기 쉽다. 그래서 피드백을 조기에 받을수록 위험이 크게 줄어든다. 일찍 실패하고, 빨리 실패하고, 자주 실패하라
2.3.2 버스 지수
버스 지수 : 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수
프로젝트에서 필요한 지식과 동작 원리를 이해한 사람이 나뿐이라면 내가 해고될 가능성은 극히 낮다. 하지만 내가 버스에 치인다면 프로젝트는 망할 것이다. 내 지식을 동료 한 명과 공유한다면 버스 지수는 두 배가 된다. 최소한 각 책임 영역마다 2차 소유자를 두고, 제대로 된 문서를 갖춰 둔다면 프로젝트의 미래를 보장하고 버스 지수를 높이는 데 도움이 된다.
혼자 일하게 되면 버스 지수 외에 전반적인 진행 속도에도 해롭다. 혼자 일하는 것은 고된 싸움이며 사람들의 기대보다 훨씬 느리다는 점을 잊기 쉽다. 다른 이들과 함께 어울려 일하면 개인의 노력만으로는 깨우치기 어려운 공동의 지혜라는 이점을 얻을 수 있다.
2.3.3 진척 속도
현재의 데브옵스 철학은 가능한 한 일찍 피드백하고, 가능한 한 일찍 테스트하고, 보안과 프로덕션 환경을 가능한 한 초기부터 고려한다. 라는 목표를 천명하고 있다. 즉 문제를 빨리 찾을수록 고치는 비용이 낮아진다.
계획이나 설계 변경이 필요한 시점을 즉시 알려줄 피드백 루프를 어떻게 마련할 것인가? 정답은 팀 플레이이다. ‘눈이 많아야 버그가 줄어든다 -> 눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다.’
**오늘날의 소프트웨어는 개인이 아닌 팀이 만들어내므로 팀원들과의 즉각적이고 원활한 소통이 무엇보다 중요하다.
2.3.4 결론은 숨기지 말자
2.4 모든 건 팀에 달렸다.
프로그래밍 세계에서는 고독한 장인은 매우 드물고, 존재하더라도 초월적인 업적을 홀로 이루지는 않는다는 것이다.
소프트웨어 엔지니어링은 팀의 단합된 노력이다. ‘다른 사람과 함께 일해야 한다, 비전을 공유해라, 역할을 나누어라, 다른 이로부터 배우자, 멋진 팀을 만들자’
2.4.1 사회적 상호작용의 세 기둥
협업의 열반에 들어가려면 ‘사회적 스킬의 세기둥’을 배우고 익혀야 한다.
- 겸손
- 존중
- 신뢰
2.4.2 세 기둥이 중요한 이유
사회적 관계의 힘을 과소평가하지 말라 관계는 언제나 프로젝트보다 오래 지속된다. 동료들과 끈끈해지면 필요할 때 기꺼이 자신들의 수고를 마다하지 않을 것이다.
2.4.3 겸손, 존중, 신뢰 실천하기
- 자존심 버리기
- 비평하고 비평받는 법 배우기 : 전문적인 소프트웨어 엔지니어링 환경이라면 비평에 개인적인 감정이 실리는 경우는 거의 없다. 단순히 더 나은 프로젝트를 만드는 과정일 뿐이다. 스스로 비평을 잘 수용할 줄 알아야 한다. 자신의 기술에 겸손해야 함은 물론, 상대는 내 최우선 관심사를 진심으로 생각하며 절대 나를 어리석다고 생각하는 게 아님을 믿어야 한다. 우리 자존감을 우리가 작성한 코드와 동일시해서는 안 된다. 상대의 코드에 대해 피드백 할 때는 상대가 아닌 자신을 겸손하게 낮춰서 말하자, 상대가 틀린 것이 아니라 내가 코드를 이해하는 데 문제를 겪고 있는 것이다.
- 빠르게 실패하고 반복하기 : 구글에서는 ‘가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다’ 라는 믿음이 널리 통용된다.
2.4.4 비난 없는 포스트모템 문화
실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심이다. 이를 구글은 포스트모템이라고 한다.
제대로 된 포스트모템에는 무엇을 배웠는지와 배운 것을 토대로 앞으로 무엇을 바꿀지가 담겨야 한다. 그런 다음 포스트모템을 쉽게 열람할 수 있고, 포스트모템에서 제안한 변화를 팀이 실천하는지 확인해야 한다. 실패를 제대로 기록해두면 다른 이들도 무슨 일이 있었는지 알 수 있고, 똑같은 실수를 반복하는 일을 피할 수 있다.
다음의 내용을 담자
- 사건의 개요
- 사건을 인지하고 해결에 이르기까지의 타임라인
- 사건의 근본 원인
- 영향과 피해 평가
- 문제를 즉시 해결하기 위한 조치 항목(소유자 명시)
- 재발 방지를 위한 조치 항목
- 해당 경험에서 얻은 교훈
인내심을 기르자 : 서로 맞지 않더라도 인내심을 잃지 않고 새로운 협업 방식등을 찾아서 상황을 해결할 수 있다.
마음을 열고 받아들이자 : 결점이 많은 사람이 모른다고 바로 시인해버리면 주변의 누가 신뢰할까 싶다. 하지만 실수를 했거나 자기 역량을 넘어선 일임을 인정하면 장기적으로 지위를 확고히 해줄 것이다. 결점을 드러내는 것은 겸손을 겉으로 표현하는 일이며, 책임을 지고 의무를 다 하려는 의지의 표출이다.
2.4.5 구글답게 하기
구글만의 겸손, 존중, 신뢰 원칙이 있다. 구글은 구글 다움이 갖춰야할 기준을 명확히 정의했다.
- 모호함을 뚫고 번창한다.
- 피드백을 소중히 한다.
- 저항(항상성)을 극복한다.
- 사용자를 우선한다.
- 팀에 관심을 기울인다.
- 옳은 일을 한다.
2.5 마치며
소프트웨어를 떠받드는 토대는 제대로 작동하는 팀(고기능 팀)이다. 소프트웨어 조직이 오래 지속되려면 겸손과 신뢰, 그리고 팀을 중심으로 한 존중에 뿌리를 둔 건강한 문화를 갖춰야 한다.
2.6 핵심정리
- 고립되어 일할 때의 트레이드 오프에 유의하라
- 팀원들 사이의 소통, 대인 관계 충돌 때문에 낭비한 시간이 얼마나 많은지 생각하자 그리고 다른 사람들의 성향과 일하는 방식을 이해하는 데 조금만 투자하면 생산성을 크게 끌어올릴 수 있다.
- 팀 또는 더 큰 조직 안에서 효과적으로 일하고 싶다면 자신이 선호하는 업무 방식은 물론 다른 사람들이 선호하는 방식도 알아야 한다.