[책] 구글 엔지니어는 이렇게 일한다 - 2

책을 읽고 인상 깊었던 글귀 정리

Chapter2. 팀워크 이끌어내기

---

이번 장의 핵심 주제는 소프트웨어 개발은 '팀의 단합된 노력'의 결실이라는 점입니다. 그래서 엔지니어링팀이 (혹은 어떤 형태든 창의적 협업이) 성공하려면 겸손, 존중, 신뢰라는 핵심 원칙에 맞게 여러분 자신의 행동을 바로잡아야 합니다.

[2.2 천재 신화]

파이썬은 온전히 귀도 반 로섬의 작품일까요? 그가 첫 번째 버전을 작성한 건 사실입니다. 하지만 그 후 버전들은 수천 명의 사람이 아이디어를 모으고 기능을 개발하고 버그를 수정하며 만들었습니다. 스티브 잡스는 매킨토시 제작팀을 이끌었습니다. 빌 게이츠는 초기 가정용 컴퓨터를 위한 베이식 언어 인터프리터를 작성했지만, 더 큰 업적은 MS-DOS를 중심으로 마이크로소프트라는 회사를 일구어 성공시킨 일입니다. 이들은 모두 커뮤니티를 이끌어 집단적 성과물의 상징이 되었습니다. 이렇듯 천재 신화는 팀이 이룬 성공을 단 한 사람(리더)에게 몰아주어 만들어지는 경향이 있습니다. (== 모든 훌륭한 결과물은 다수의 사람에 의해 만들어진다.)

천재라고 해서 괴짜처럼 행동하는 게 용서받는 시대는 지났습니다. 천재든 아니든 사회성이 부족한 사람은 팀원으로 적합하지 않기 때문이죠. 구글에서의 업무 거의 대부분이 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구합니다.(다른 회사들도 대동소이합니다.) 그래서 우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐입니다.(구글 같은 기업에서는 특히 더 합니다.)

 

[2.3 숨기는 건 해롭다]

위대한 아이디어를 세상으로부터 숨기고 완벽히 다듬어질 때까지 아무도 들여다보지 못하게 하는 건 엄청난 도박입니다. 초기 설계에는 근본적인 실수가 스며 있기 쉽습니다. 자칫하다가는 바퀴를 다시 발명하게 될 수도 있고 협업이 주는 이점도 얻지 못합니다.

여러분의 프로젝트에서는 필요한 지식과 노하우가 얼마나 분산되어 있나요? 프로토타입 코드의 동작 원리를 이해하는 사람이 나뿐이라면 내가 해고될 가능성은 극히 낮습니다. 하지만 내가 버스에 치인다면 프로젝트는 아마 망할 것입니다. 누군가가 결혼하거나 팀을 옮기거나 퇴사하거나 병가를 낼 수 있습니다. 최소한 각 책임 영역마다 2차 소유자(담당자)를 두고, 제대로 된 문서를 갖춰 둔다면 프로젝트의 미래를 보장하는데 도움이 됩니다.

다른 이들과 함께 어울려 일하면 개인의 노력만으로는 깨우치기 어려운 공동의 지혜라는 이점을 얻을 수 있습니다.

 

[2.4 모든 건 팀에 달렸다]

말하고자 하는 핵심은 프로그래밍 세계에서는 고독한 장인은 매우 드물고, 존재하더라도 초월적인 업적을 홀로 이루어내지는 못한다는 것입니다. 그들이 만든, 세상을 뒤바꾸는 성취의 거의 대부분은 영감의 불씨를 영웅적인 '팀의 노력'으로 활활 불사른 결과입니다. 위대한 팀은 슈퍼스타를 잘 활용하며, 동시에 개개인이 낼 수 있는 성과를 합한 것보다 더 큰 성과를 만들어냅니다. (중략) 다른 사람과 함께 일해야 합니다. 비전을 공유하세요. 역할을 나누세요. 다른 이로부터 배우세요. 멋진 팀을 만드세요.

협업의 열반에 들어가려면 가장 먼저 사회적 스킬의 '세 기둥'을 배우고 익혀야 합니다.

1. 겸손: 당신은 모든 것을 알지도, 완벽하지도 않습니다. 겸손한 사람은 배움에 열려 있습니다.
2. 존중: 함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다.
3. 신뢰: 동료들이 유능하고 올바른 일을 하리라 믿습니다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.

겸손, 존중, 신뢰 실천하기

1. 자존심 버리기: 겸손은 중요하지만 그렇다고 바짝 엎드리라는 뜻은 아닙니다. 자신감을 갖는 건 나쁠 게 없죠. 그저 모든 걸 다 아는 듯 행동하지 말라는 뜻입니다. 자신이 잘 아는 분야에 대해 걱정하는 대신 팀의 성취와 단체의 자부심을 높이려 노력하세요.
2. 비평하고 비평받는 법 배우기: 건설적 비판은 프로젝트에 도움이 되며 개선을 위한 지침을 줄 수 있고, 또 주어야 합니다. 여기서 가장 중요한 점은 건설적으로 비판하는 사람은 상대방을 진심으로 생각하고 상대방의 업무가 개선되길 바라야 한다는 것입니다. 대화의 반대편으로 가서, 여러분 자신도 비평을 잘 수용할 줄 알아야 합니다. 자신의 기술에 겸손해야 함은 물론, 상대는 내 최우선 관심사를 진심으로 생각하며 절대 나를 어리석다고 생각하는 게 아님을 믿어야 합니다. 우리 자존감을 우리가 작성한 코드와 동일시해서는 안됩니다.(중략) 누군가에게 '잘못했다'라고 해서는 안됩니다. 무언가를 '고치라고 요구'해서도 안 됩니다. 마지막으로 '다른 사람들과 다르게 했다고 비난'하면 안 됩니다. 다음과 같이 이야기하면 한결 나을 것입니다. "저기, 이 부분의 제어 흐름이 좀 헷갈리네요. 혹시 xyz 코드 패턴을 적용하면 더 명확해질까요? 나중에 관리하기 쉬워질지도 모르겠네요." > 상대가 아닌 자신을 겸손하게 낮췄음에 주목하세요. 아무것도 요구하지 않고 동료가 제안을 거부해도 부담을 느끼지 않도록 배려했습니다. 또한 누군가의 가치나 코딩 기술이 아니라 코드 자체에 집중하고 있습니다.
3. 빠르게 실패하고 반복하기: 구글에서 제가 정말 좋아하는 좌우명은 '실패는 선택이다'입니다. 구글에서는 '가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않는 것이다'라는 믿음이 널리 통용됩니다. 실패를 '배우고 다음 단계로 넘어갈 수 있는 절호의 기회'라고 생각하는 것이죠. 실제로 발명왕 토머스 에디슨은 이런 말을 남겼습니다. '나는 만 가지의 잘못된 방식을 찾아낸 것일 뿐 실패한 게 아니다. 잘못하고 폐기한 시도 하나하나가 다음 단계로 이끌어주기 때문에 나는 낙담하지 않는다.'

비난 없는 포스트모템 문화

실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심입니다. 이를 구글은(그리고 많은 다른 회사에서도) 포스트모템이라고 합니다. (포스트모템: 프로젝트를 마친 후 전 과정을 되돌아보며 잘된 점과 잘못된 점을 되돌아보는 사후 검토 작업)

제대로 된 포스트모템에는 무엇을 배웠는지와 배운 것을 토대로 앞으로 무엇을 바꿀지가 담겨야 합니다.

훌륭한 포스트모템에는 다음 내용이 담겨야 합니다.

• 사건의 개요
• 사건을 인지하고 해결에 이르기까지의 타임라인
• 사건의 근본 원인
• 영향과 피해 평가
• 문제를 즉시 해결하기 위한 조치 항목
• 재발 방지를 위한 조치 항목
• 해당 경험에서 얻은 교훈

마음을 열고 받아들이자

다른 이로부터 배우는 데 열려 있을수록 여러분의 영향력도 커집니다.

엔지니어링은 본질적으로 트레이드오프에 관한 것이라 했습니다.

실수했거나 자기 역량을 넘어선 일임을 인정하면 장기적으로 지위를 확고히 해줄 것입니다. 사실 결점을 드러낸다는 것은 겸손을 겉으로 표현하는 일이며, 책임을 지고 의무를 다 하려는 의지의 표출입니다. 그리고 다른 이들의 의견을 신뢰한다는 신호이기도 합니다. 그 결과 사람들은 당신의 솔직함과 용기를 존중하게 될 것입니다.

소프트웨어를 작성할 때는 방어적인 태도를 고집할 이유가 없습니다. 팀원은 동반자이지 경쟁자가 아닙니다. 여러분 모두가 같은 목표를 향해 달려가는 중입니다.