- 사람은 완벽하지 않다.
- 인간을 간헐적 버그들의 집합이라고도 함
- 하지만 동료에 내재된 버그를 이해하려면, 무엇보다 자신의 내면에 서식하는 버그를 먼저 이해해야 함.
- 이번 장의 주제는 소프트웨어 개발은 ‘팀의 단합된 노력’의 결실이라는 점이다.
- 그래서 엔지니어링팀이 성공하려면 겸손, 존중, 신뢰라는 핵심 원칙에 맞게 자신의 행동을 바로잡아야 함.
1. 내 코드를 숨기고 싶어요
- 사람들은 자신이 진행 중인 작업물을 다른 사람이 보고 판단하는 것을 두려워한다.
- 불안감은 사실 더 큰 문제의 징후가 된다.
2. 천재 신화
- 많은 사람이 본능적으로 우상을 찾고 흠모한다.
- 리누스, 데니스 리치만, 귀도 반 로섬 등 천재들이 혼자서 리눅스, 유닉스, 파이썬을 모두 완성한 것이 아니다. 팀의 작품임.
- 이들의 진짜 업적은 이 사람들을 협업하도록 이끈 것이다.
- 이들은 커뮤니티를 이끌어 집단적 성과물의 상징이 되었다.
- 천재 신화는 팀이 이룬 성공을 단 한 사람에게 몰아주어 만들어지는 경향이 있다.
- 인간은 본능적으로 리더와 롤모델을 찾고, 그들을 우상화하고 흉내내려 한다.
- 프로그래밍 세계에도 다르지 않고, 그래서 ‘기술 전문가 셀럽 현상’이 거의 신화화되어가고 있다.
- 내면 깊숙한 곳에서 많은 엔지니어가 자신이 천재로 비치기를 원한다.
- 여러분이 설령 천재더라도 코딩 기술만으로는 부족하다.
- 천재들도 실수를 하고 훌륭한 아이디어와 최고 수준의 프로그래밍 기술도 여러분이 만든 소프트웨어가 성공하리란 보장을 해주지 못한다.
- 우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐이다.
- 구글에서의 업무 대부분이 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구한다.
- 천재신화는 결국 우리 내면의 불안을 드러내는 또 다른 사례일 뿐이다.
- 많은 프로그래머가 동료들이 자신의 실수를 보면 자신이 천재가 아님을 눈치챌것이라는 두려움 때문에 방금 시작한 프로젝트를 공유하길 꺼린다.
3. 숨기는 건 해롭다.
- 여러분이 오롯이 홀로 일한다면 실패할 위험성을 불필요하게 키우고 자신의 성장 잠재력을 속이는 것이다.
3-1 조기 감지
- 초기 설계에는 근본적인 실수가 스며 있기 쉽다.
- 피드백을 조기에 받을수록 이러한 위험이 크게 줄어든다.
- 일찍 실패하고, 빨리 실패하고, 자주 실패하라
3-2 버스지수
- 버스지수 : 몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수
- 최소한 각 책임영역마다 2차 담당자를 두고, 제대로 된 문서를 갖춰준다면 프로젝트의 미래를 보장하고 버스 지수를 높이는데 도움이 된다.
- 실패한 프로젝트의 핵심을 책임진 경험보다 성공한 프로젝트의 한 부분에 참여한 경험이 낫다는데 대다수 엔지니어가 공감할 것이다.
- 혼자 일하게 되면 버스 지수 외에 전반적인 진행속도에도 해롭다.
3-3 진척 속도
- 프로그래머는 긴밀하게 피드백을 받을 때 가장 효율적으로 일한다.
- 현재 데브옵스 철학은 ‘가능한 일찍 피드백하고, 가능한 일찍 테스트하고, 보안과 프로덕션 환경을 가능한 초기부터 고려한다.’가 목표이다.
- 이 모두는 개발 워크플로를 ‘원점 회귀’하라는 아이디어에 녹아 있다.
- 즉, 문제를 빨리 찾을수록 고치는 비용이 낮아진다.
- 빠른 피드백 루프는 코드 수준뿐 아니라 전체 프로젝트 수준에서도 이뤄져야 한다.
- 팀 플레이로 계획이나 설계 변경이 필요한 시점을 즉시 알려줄 피드백 루프를 마련할 수 있다.
- ‘눈이 많아야 버그가 줄어든다.’
- ‘눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다.’
3-4 결론은, 숨기지 말자
- 홀로 일하기는 함께 일하기보다 본질적으로 더 위험하다.
- 다른 사람들이 아이디어를 훔친다거나 여러분이 똑똑하지 않다고 생각하는 게 두렵더라도, 잘못된 일에 여러분의 천금 같은 시간을 낭비할 가능성을 더 걱정해야 한다.
4. 모든 건 팀에 달렸다
- 위대한 팀은 슈퍼스타를 잘 활용하며, 동시에 개개인이 낼 수 있는 성과를 합한 것보다 더 큰 성과를 만들어 낸다.
- 소프트웨어 엔지니어링은 팀의 단합된 노력이다.
4-1 사회적 상호작용의 세 기둥
- 사회적 스킬의 세 기둥
- 겸손
- 당신과 당신의 코드는 우주의 중심이 아니다.
- 당신은 모든 것을 알지도, 완벽하지도 않다.
- 겸손한 사람은 배움에 열려있다.
- 존중
- 함께 일하는 동료를 진심으로 생각한다.
- 친절하게 대하고 그들의 능력과 성취에 감사해한다.
- 신뢰
- 동료들이 유능하고 올바른 일을 하리라 믿는다.
- 필요하면 그들에게 스스로 방향을 정하게 해도 좋다.
4-2 세 기둥이 중요한 이유
- 리처드 해밍의 강의 예시 - 동료들과 가까워지기 위해 노력한 결과 그들도 나를 더 성심껏 도와줌.
- 사회적 관계의 힘을 과소평가하지말라
- 관계는 언제나 프로젝트보다 오래 지속된다.
- 동료들과 끈끈해지면 여러분이 필요할 때 기꺼이 자신들의 수고를 마다하지 않을 것이다.
4-3 겸손, 존중, 신뢰 실천하기
- 자존심 버리기
- 늘 자신이 회의실에서 가장 중요한 인물인 것처럼 행동하는 사람과 일하기를 좋아하는 사람은 없다.
- 참석자 중 자기가 가장 현명하다고 확신하더라도 그런 속내를 겉으로 드러내서는 안된다.
- 겸손은 중요하지만 그렇다고 바짝 엎드리라는 뜻은 아니다. 그저 모든 걸 다 아는 듯 행동하지 말라.
- ‘집단적’ 자존심을 갖자.
- 자신이 잘 아는 분야에 대해 걱정하는 대신 팀의 성취와 단체의 자부심을 높이려 노력하라.
- 비평하고 비평받는 법 배우기
- 전문적인 소프트웨어 엔지니어링 환경이라면 비평에 개인적인 감정이 실리는 경우는 거의 없다. 더 나은 프로젝트를 만드는 과정일 뿐
- 이런 환경을 조성하려면 ‘누군가의 창조적 산출물에 대한 건설적인 비평’과 ‘다른 이의 성향에 대한 맹렬한 공격’의 차이를 모두가 바르게 이해해야 한다.
- 성향을 공격하는 건 쓸데없는 짓이다. 사소하며 대응할 방법도 거의 없다.
- 건설적 비판은 프로젝트에 도움이 되며 개선을 위한 지침을 줄 수 있다.
- 중요한 점은 상대방을 진심으로 생각하고 상대의 업무가 개선되길 바라야 한다는 점이다.
- 반대로 자신도 비평을 잘 수용할 줄 알아야 한다.
- 자신의 기술에 겸손해야 ㅎ마은 물론, 상대는 내 최우선 관심사를 진심으로 생각하며 절대 나를 어리석다고 생각하는 게 아님을 믿어야 한다.
- 우리 자존감을 우리가 작성한 코드와 동일시하지마라.
- 빠르게 실패하고 반복하기
- 구글에서는 ‘가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다’라는 믿음이 널리 통용된다.
- 실패를 배우고 다음단계로 넘어갈 수 있는 절호의 기회라고 생각하는 것이다.
4-4 비난 없는 포스트 모템 문화
- 실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심이다. ⇒ 포스트모템
- 포스트모템 문서가 쓸모없는 사죄, 변명, 지적으로 채워지지 않도록 각별히 주의하라.
- 훌륭한 포스트모템에는 다음 내용이 담겨야 한다.
- 사건의 개요
- 사건을 인지하고 해결에 이르기까지의 타임라인
- 사건의 근본 원인
- 영향과 피해 평가
- 문제를 즉시 해결하기 위한 조치 항목
- 재발 방지를 위한 조치 항목
- 해당 경험에서 얻은 교훈
- 마음을 열고 받아들이자
- 다른 이로부터 배우는데 열려있을수록 여러분의 영향력도 커진다.
- 엔지니어링은 본질적으로 트레이드오프에 관한 것이다.
- 새로운 증거가 나타나면 여러분의 생각을 바꿔야 한다.
4-5 구글답게 하기
- 모호함을 뚫고 번창한다.
- 끊임없이 변화하는 환경 속에서도 상충하는 메시지와 방향에 잘 대처하고, 합의를 이끌어내고, 문제에 대한 진전을 이룰 수 있다.
- 피드백을 소중히 한다.
- 피드백을 주고받을 때 품위와 겸손을 유지하고 개인과 팀의 발전에 피드백이 주는 가치를 이해한다.
- 저항을 극복한다.
- 다른 이들이 저항하거나 관성 때문에 움직이지 않으려 하더라도 야심 찬 목표를 세우고 밀고 나아간다.
- 사용자를 우선한다.
- 구글 제품의 사용자 입장에서 생각하고 존중하며 그들에게 가장 도움되는 행동을 추구한다.
- 팀에 관심을 기울인다.
- 동료들의 입장에서 생각하고 존중하며 팀의 결집을 위해 누가 시키지 않더라도 적극적으로 돕는다.
- 옳은 일을 한다
- 모든 일에 강한 윤리의식을 가지고 임한다.
- 팀과 제품의 진정성을 지키기 위해서라면 어렵거나 불편한 결정을 내릴 수 있어야 한다.
5. 마치며
- 거의 모든 규모의 소프트웨어를 떠받드는 토대는 ‘제대로 작동하는 팀’이다.
- 단 한명의 소프트웨어 개발자가 이룬 천재 신화가 만연하지만, 그 누구도 홀로 이뤄내지 않았다는 것이 진실이다.
- 소프트웨어 조직이 오래 지속되려면 겸손과 신뢰, 그리고 팀을 중심으로 한 존중에 뿌리를 둔 건강한 문화를 갖춰야 한다.
- 나아가 소프트웨어 개발은 근본적으로 창의적인 일이므로 위험을 감수할 주 ㄹ알아야 하고 때로는 실패할 줄도 알아야 한다.
- 실패를 인정하려면 건강한 팀 환경이 반드시 갖춰져 있어야 한다.