구글 엔지니어는 이렇게 일한다

02. 팀워크 이끌어내기

주요내용

• 사람은 완벽하지 않음
• 고립되어 일하면 초반에 문제를 인지할 수 없음
• 자신뿐만 아니라 다른 사람의 성향과 일하는 방식도 이해하고 존중해야 함

이번 챕터에서는 구글에서 이루어지는 소프트웨어 엔지니어링의 문화적/사회적 측면에 대해 다룹니다. 소프트웨어 개발은 '팀의 단합된 노력'의 결실입니다. 인간은 완벽하지 않기 때문에 겸손, 존중, 신뢰라는 핵심 원칙에 맞게 행동해야 엔지니어링 팀이 성공할 수 있습니다.

1. 내 코드를 숨기고 싶어요

다른 사람들이 아직 완성되지 않은 내 코드를 보는 건 진짜 진짜 겁이 나. 
그걸 진지하게 보고 내가 바보라고 생각할 것만 같아.

많은 개발자들은 미완성인 자신의 코드를 누군가 보고 판단하는 것을 두려워합니다. 이는 프로그래머들이 느끼는 매우 일반적인 감정입니다. 다들 자신의 코드를 숨기고 완벽해질 때 까지 다듬은 후 세상에 알리고 싶어합니다.

리눅스 개발자 리누스, 파이썬 개발자 귀도 반 로섬, 빌 게이츠 등 개발자로서 우상으로 섬기는 사람을 떠올려 보세요. 이들은 모두 커뮤니티를 이끌어 엄청난 집단적 성과물을 이끌어 냈습니다. 마이클 조던 역시 혼자서 경기를 승리로 이끈 것은 아닙니다. 조던의 진정한 천재성은 그 팀과 협동하는 방식에 있습니다. 단지 천재 신화(The Genius Myth)는 팀이 이룬 성공을 단 한 사람(리더)에게 몰아주어 만들어지는 경향이 있습니다.
우리는 천재가 아닙니다. 혼자서 위대한 무언가를 해내는 것보다는 협업을 통해 해내는 것이 훨씬 쉽습니다.

2. 숨기는 건 해롭다

오롯이 홀로 일한다면 실패할 위험성을 불필요하게 키우고 자신의 성장 잠재력을 속이는 것입니다. 구글은 다음의 근거들을 바탕으로 코드를 숨겨가며 혼자 일하는 것을 심각한 문제라고 생각합니다.

조기감지

일찍 실패하고, 빨리 실패하고, 자주 실패하라

초기 설계에는 근본적인 실수가 스며 있기 쉽습니다. 피드백을 조기에 받을수록 위험이 크게 줄어듭니다. 혼자 일한다면 협업이 주는 이점도 얻지 못합니다.

버스 지수

버스 지수 (Bus Factor)
몇 명의 팀원이 버스에 치어서 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수

최소한 각 책임 영역 마다 2차 소유자(담당자)를 두고, 제대로 된 문서를 갖춰 둔다면 프로젝트의 미래를 보장하고 버스지수를 높이는 데 도움이 됩니다. 혼자 일한다면 버스 지수 외에 전반적인 진행 속도에도 해롭습니다.

진척 속도
현재 Devops 철학은 '가능한 일찍 피드백 하고, 가능한 일찍 테스트하고, 보안과 프로덕션 환경을 가능한 초기부터 고려한다'라는 목표를 천명하고 있습니다. 팀 플레이를 할 경우 계획이나 설계 변경이 필요한 시점을 즉시 알려줄 피드백 루프를 마련할 수 있습니다.

[사례 연구: 엔지니어와 사무실]
- 엔지니어들이 방해받지 않고 코드 작성에 몰두 할 수 있는 1인실이 좋을까? (X)
- 수십명의 사람이 함께 쓰는 오픈 오피스가 좋을까? (X)
둘 다 활발한 대화를 하기에 적합하지 않다. 
팀마다 4~8명 정도의 방을 사용하는 것이 자발적이고 활발한 대화를 이끌어 낼 수 있다.

3. 결론: 숨기지 말자

'홀로 일하기'는 '함께 일하기'보다 본질적으로 더 위험합니다. 다른 사람이 아이디어를 훔친다거나 여러분이 똑똑하지 않다고 생각하는 게 두렵더라도, 잘못된 일에 여러분의 천금 같은 시간을 낭비할 가능성을 더 걱정해야 합니다.

4. 모든 것은 팀에 달렸다

소프트웨어 엔지니어링은 팀의 단합된 노력입니다. 그러므로 가능한 고기능 팀을 경험하는 것을 목표로 삼아야 합니다. 또한 사회적 관계의 힘을 과소평가하지 마세요. 일이 진행되도록 관계를 형성해야 합니다.

겸손(Humility)
당신과 당신의 코드는 우주의 중심이 아닙니다. 당신은 모든 것을 알지도, 완벽하지도 않습니다. 겸손한 사람은 배움에 열려 있습니다.

존중(Respect)
함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해야 합니다.

신뢰(Trust)
동료들이 유능하고 올바른 일을 하리라 믿습니다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.

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

자존심 버리기
자기가 가장 현명하다고 확신하더라도 그런 속내를 겉으로 드러내서는 안됩니다. 모든 것을 다 아는 듯 행동하면 안됩니다. 집단적 자존심을 찾아야합니다. 자신일 잘 아는 분야에 대해 걱정하는 대신 팀의 성취와 단체의 자부심을 높이려 노력해야 합니다.

비평하고 비평받는 법 배우기
건설적으로 비판하는 사람은 상대방을 진심으로 생각하고 상대방의 업무가 개선되길 바라야 합니다. 그리고 동료를 존중하는 법을 배우고 건설적이고 공손하게 비평하는 법을 배워야 합니다. 또한 스스로도 비평을 잘 수용할 줄 알아야 합니다. 우리 자존감을 우리가 작성한 코드(혹은 이외의 창작물)와 동일시해서는 안됩니다.

Bad :-(
- '~ 했어야 해요' 라고 말해서는 안됨
- '~가 잘못했어요' 라고 말해서는 안됨
- '~를 고치세요' 라고 요구해서는 안됨
- 다른 사람과 다르게 했다고 비난하면 안됨
Good :-)
- 상대가 틀린게 아니라 자신이 코드를 이해하는 데 문제를 겪고 있는 것이라고 말하기
- 개선 방안 제안하기
- 요구하지 않고 제안을 거부해도 부담을 느끼지 않도록 배려하기
- 누군가의 가치나 코딩 기술이 아니라 코드 자체에 집중하기

빠르게 실패하고 반복하기
실패를 '배우고 다음 단계로 넘어갈 수 있는 절호의 기회'라고 생각합시다.

[사례 연구: Google X]
자율 주행 자동차 등 급진적인 신기술을 연구하는 구글X 사업부에서는 실패를 보상 제도에 녹였다.
사람들은 엉뚱한 아이디어를 내놓고 동료들에게 가능한 빠르게 그 아이디어를 파쇄하라고 장려한다.
연구원들은 정해진 기간 동안 얼마나 많은 아이디어를 반증하고 무력화하는지에 따라 보상을 받고 서로 경쟁한다.
그리고 잘못된 아이디어임을 증명할 수 있는 동료가 하나도 없는 경우에만 초기 프로토타이핑 단계로 넘어갈 수 있다.

6. Postmortem 문화

실패한 근본 원인을 분석해 문서로 남기는 것이 실수로부터 배우는 핵심입니다. 이것을 포스트모템이라고 합니다. 제대로 된 포스트모템에는 무엇을 배웠는지와 배운 것을 토대로 앞으로 무엇을 바꿀지가 담겨야 합니다.

포스트모템의 내용

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

Googleyness (구글다움)

• 모호함을 뚫고 번창한다
  끊임 없이 변화하는 환경 속에서도 상충하는 메시지와 방향에 잘 대처하고, 합의를 이끌어내고, 문제에 대한 진전을 이룰 수 있다.
• 피드백을 소중히 한다
  피드백을 주고 받을 때 품위와 겸손을 유지하고 개인과 팀의 발전에 피드백이 주는 가치를 이해한다.
• 저항(항상성)을 극복한다
  다른 이들이 저항하거나 관성 때문에 움직이지 않으려 하더라도 야심찬 목표를 세우고 밀고 나간다.
• 사용자를 우선한다
  구글 제품의 사용자 입장에서 생각하고 존중하며 그들에게 가장 도움되는 행동을 추구한다.
• 팀에 관심을 기울인다
  동료들의 입장에서 생각하고 존중하며 팀의 결집을 위해 누가 시키지 않더라도 적극적으로 돕는다.
• 옳은 일을 한다
  모든 일에 강한 윤리 의식을 갖고 임한다. 팀과 제품의 진정성을 지키기 위해서라면 어렵거나 불편한 결정을 내릴 수 있어야 한다.