구글 엔지니어는 이렇게 일한다(타이터스 윈터스, 톰 맨쉬렉, 하이럼 라이트) - 04

공감되거나 인상 깊었던 문장들은 다음과 같다.

• 사람은 완벽하지 않습니다. 그래서 인간을 ‘간헐적 버그들의 집합’에 가깝다고 이야기하곤 한다. 하지만 동료에 내재된 버그를 이해하려면, 무엇보다 자신의 내면에 서식하는 버그를 먼저 이해해야 한다. (P.71)
• 소프트웨어 개발은 ‘팀의 단합된 노력’의 결실이라는 점이다. 그래서 엔지니어링 팀이 (혹은 어떤 형태든 창의적 협업이) 성공하려면 겸손, 존중, 신뢰라는 핵심 원칙에 맞게 여러분 자신의 행동을 바로 잡아야 한다. (P.71)
• 사람들은 자신이 진행 중인 작업물을 다른 사람이 보고 판단하는 걸 두려워한다. 어쩌면 이런 두려움은 인간의 본성에 속한다. 누구라도 비난받고 싶어 하지 않으며, 작업물이 완성되기 전이라면 더욱 그렇다. (P.72)
• 구글에서의 업무 거의 대부분이 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구한다. (다른 회사들도 대동소이하다). 그래서 우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐이다. (P.74)
• 위대한 아이디어를 세상으로부터 숨기고 완벽히 다듬어질 때까지 아무도 들여다보지 못하게 하는 건 엄청난 도박이다. 초기 설계에는 근본적인 실수가 스며 있기 쉽다. (P.76)
• 우리는 우리가 올바른 일을 하고 있는지, 제대로 하고 있는지, 그리고 다른 누군가가 이미 해놓은 일은 아닌지를 확인해봐야 한다. ‘초기’ 단계에서 이런 실수를 범할 확률은 상당히 높다. 그러서 피드백을 ‘조기에’ 받을수록 이러한 위험이 크게 줄어든다. 검증된 주문인 ‘일찍 실패하고, 빨리 실패하고, 자주 실패하라’를 기억하라. (P.76)
• 다른 이들과 함께 어울려 일하면 개인의 노력만으로는 깨우치기 어려운 공동의 지혜라는 이점을 얻을 수 있다. (P.77)
• 프로그래밍은 어렵다. 소프트웨어 엔지니어링은 한층 더 어렵다. 그래서 당신에게는 제3의 눈이 필요하다. (P.77)
• 프로그래머는 긴밀하게 피드백 받을 때 가장 효율적으로 일한다. (P.77)
• 현재의 데브옵스(devops) 철학은 ‘가능한 한 일찍 피드백하고, 가능한 한 일찍 테스트하고, 보안과 프로덕션 환경을 가능한 한 초기부터 고려한다’라는 목표를 천명하고 있다. 이 모두는 개발 워크플로를 ‘원점 회귀(shift left)’하라는 아이디어에 녹아 있다. 문제를 빨리 찾을수록 고치는 비용이 낮아진다. (P.77)
• 오늘날의 소프트웨어는 개인이 아닌 팀이 만들어내므로 팀원들과의 즉각적이고 원활한 소통이 무엇보다 중요하다. 아무리 오랫동안 깊이 몰입하더라도 잘못된 일을 하고 있다면 모두 시간 낭비일 뿐이다. (P.78)
• 우리도 방해받지 않고 코딩에 집중할 시간이 필요하다고 생각한다. 하지만 다른 팀원과의 활발한 소통도 그에 못지않게 중요하다고 믿는다. 아직 모르는 게 많은 팀원이 여러분에게 질문하기조차 어려운 문화라면 분명 문제다. (P.79)
• 소프트웨어 엔지니어링은 팀의 단합된 노력이다. (P.80)
• 다른 사람과 함께 일해야 한다. 비전을 공유하라. 역할을 나눠라. 다른 이로부터 배워라. 멋진 팀을 만들어라. (P.80)
• 협업의 열반에 들어가려면 가장 먼저 사회적 스킬(social skill)의 ‘세 기둥(pillars)’을 배우고 익혀야 한다.
  • 겸손(humility): 당신과 당신의 코드는 우주의 중심이 아니다. 당신은 모든 것을 알지도, 완벽하지도 않다. 겸손한 사람은 배움에 열려 있다.
  • 존중(respect): 함께 일하는 동료를 진심으로 생각한다. 친절하게 대하고 그들의 능력과 성취에 감사해한다.
  • 신뢰(trust): 동료들이 유능하고 올바른 일을 하리라 믿는다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋다.
• 성향을 공격하는 건 쓸데없는 짓이다. 사소하며 대응할 방법도 거의 없다. 건설적 비판은 프로젝트에 도움이 되며 개선을 위한 지침을 줄 수 있고, 또 주어야 한다. 여기서 가장 중요한 점은 건설적으로 비판하는 사람은 상대방을 진심으로 생각하고 상대방의 업무가 개선되길 바라야 한다는 것이다. 그리고 동료를 존중하는 법을 배우고 건설적이고 공손하게 비평하는 법을 배워야 한다. (P.84)
• 대화의 반대편으로 가서, 자기 자신도 비평을 잘 수용할 줄 알아야 한다. 자신의 기술에 겸손해야 함은 물론, 상대는 내 최우선 관심사(와 내 프로젝트)를 진심으로 생각하며 절대 나를 어리석다고 생각하는 게 아님을 믿어야 한다. (P.84)
• 구글에서 저자가 좋아하는 좌우명은 ‘실패는 선택이다’이다. 구글에서 ‘가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다’라는 믿음이 널리 통용된다. 실패를 ‘배우고 다음 단계로 넘어갈 수 있는 절호의 기회’라고 생각한다.

---

좋은 소프트웨어는 결국 팀에 의해 만들어진다. 현대 소프트웨어 개발에서 협업을 피할 수 없다. 원만하게 일하고 팀의 성공을 위해선 겸손, 존중, 신뢰가 필요하다. 스스로가 이 세 가지 덕목을 갖고 있는지 돌이켜 볼 필요가 있다는 생각이 든다. 책에서는 협업의 중요성을 강조한다. 우리 팀은 항상 페어 프로그래밍하는데, 페어와 대화하면서 더 나은 설계를 하는 경우가 많았다. 내가 몰랐던 비즈니스 컨텍스트나 충분히 이해하지 못한 코드에 대한 내용을 매번 팀원으로부터 배우고 있다.

처음 페어 프로그래밍을 시작했을 때는 나도 두려움이 있었다. 상대방이 내 코드를 보면서 잘못된 점들을 지적할까봐 무서웠다. 페어가 바뀔 때면 다른 팀원과 내 실력을 비교할까봐 두려움도 있었다. 이렇게 5년 정도 일하다보니 내 코드를 다른 사람에게 노출하는 것에 전혀 두려움이 없어졌다. 이것은 내 코드가 아니라 팀의 코드라는 생각이 더 커졌다. 내가 작성한 코드도 당시에는 잘 동작하지만, 점진적으로 빌드해나가면서 언제든지 바뀔 수 있다고 생각하게 됐다.

팀으로 일하려면 스스로 완벽하지 않음을 인정할 수 있어야 하고, 함께 일하는 팀원들의 작업 결과물을 인정하고 믿어야 한다.