구글 엔지니어는 이렇게 일한다: 팀워크
in BOOK on 구글 엔지니어는 이렇게 일한다, Teamwork, Postmortem
1. 천재 신화
뛰어난 머리보다 건강한 협업이 낫다.
괴짜 천재는 더 이상 용납되지 않는다.
아무리 똑똑해도 사회성이 부족하면 팀원으로 부적합하다.
대부분의 개발 업무는 천재 수준의 두뇌보다 기본적인 협업 능력을 더 많이 요구한다.
경력을 이어주는 건 협업이다.
“똑똑한데 사회성은 없어” 는 더 이상 면죄부가 아니다.
개발자로서 커리어를 장기적으로 이어가려면, 결국 팀과 얼마나 잘 협력했는가가 핵심이다.
2. 숨기는 건 해롭다.
혼자 일하면 실패 가능성이 커진다.
아이디어를 숨기고 완성된 결과만 보여주려는 태도는 실패 확률을 높인다.
초기 설계에는 근본적인 실수가 숨어있기 쉬운데, 이걸 검증받지 못하면 나중에 큰 손해로 돌아온다.
피드백은 빠를 수록 좋다.
올바른 방향으로 가고 있는가? 를 점검하는 가장 빠른 방법은 조기 피드백이다.
다만 확신이 서지 않은 상태에서 과도한 피드백은 오히려 방해가 될 수도 있으므로 밸런스가 중요하다.
버스 지수(Bus Factor)란?
버스 지수는 핵심 인력이 갑자기 사라질 경우 프로젝트가 망할 가능성을 수치화한 지표이다.
지수가 낮을수록 위험하며, 핵심 지식이 특정 인물에게 집중되어 있는 상태를 의미한다.
<버스 지수를 높이는 방법>
- 정기적인 기술 공유 세션
- 시스템 구조, API 명세, 운영 메뉴얼 등의 문서화
- 페어 프로그래밍으로 상호 이해도 향상
- 코드 리뷰로 주요 설계를 팀이 함께 이해
- 온보딩 문서 및 교육 체계 강화
성공 프로젝트의 일부였던 경험이 실패 프로젝트의 전부를 책임졌던 경험보다 더 의미 있다.
혼자 일하면 속도도 느려진다.
잘못된 방향으로 나아가다 뒤늦게 수정하는데 드는 비용은 크다.
두어 명의 동료만 있었어도 즉각 피드백을 통해 방향을 바로잡을 수 있다.
회사에서 팀이 같은 공간에서 일하는 이유가 여기 있다.
개발은 Shift Left, 빠른 피드백 루프가 핵심
대부분의 개발자는 코드를 작성하고 즉시 컴파일하고 리팩터링하는 식으로 일한다.
이는 Shift Left(원점 회귀) 와 일맥 상통한다.
즉, 문제를 빨리 찾을수록 수정 비용이 낮아지고, 생산성도 향상된다.
눈이 많을수록 프로젝트는 안전하다.
계획과 설계 변경이 필요한 시점을 놓치지 않기 위해선, 항상 여러 명이 프로젝트를 같이 바라보고 있어야 한다.
혼자 일하면 내가 그리는 그림에 빠져 시장과 요구가 바뀐 것조차 눈치채지 못할 수 있다.
결론은 숨기지 말자, 그게 팀워크의 시작이다.
아이디어가 도둑맞을까봐, 내가 무능하다는 평가를 받을까봐 두려운 건 이해된다.
하지만 그 두려움보다 더 큰 위험은, 잘못된 방향으로 수개월을 낭비하는 것이다.
3. 모든 건 팀에 달렸다
“신뢰와 피드백으로 성장하는 개발 문화”
<협업의 기본>
- 겸손(Humility)
- 내가 다 안다고 생각하지 않기
- 배우는 데 열려 있기
- 존중(Respect)
- 동료를 친절히 대하고, 능력과 기여에 감사하기
- 신뢰(Trust)
- 자율성을 부여하고 스스로 결정할 수 있도록 믿어주기
우주의 중심처럼 행동하는 사람은 팀워크를 해친다.
사회적 관계의 힘을 과소평가하면 안 된다.
사람을 속이고 조종하지 말고, 함께 일할 수 있는 신뢰 기반의 관계를 구축해야 한다.
동료들과 끈끈해지면 내가 필요할 때 기꺼이 자신들의 수고를 마다하지 않을 것이다.
3.1. 겸손, 존중, 신뢰 실천
3.1.1. 자존심 버리기
회의실에서 가장 중요한 인물인 것처럼 행동하는 사람과 함께 일하기를 좋아하는 사람은 없다.
혹시 여러분은 모든 논의 주제를 시작하고 마무리 짓는 사람이 자신이어야 한다고 생각하나요?
제안이나 안건마다 사사건건 첨언하고 싶은가요?
혹시 주변에 이런 사람이 있나요?
겸손하라는 말은 바짝 엎드리라는 뜻이 아니다.
“모든 걸 다 아는 척하지 않는 것”, 그것이 겸손의 본질이다.
나 자신의 자존심보다 팀의 성취와 자부심을 우선시하자.
아래는 자존심을 내세워서 입는 손해를 잘 말해주는 이야기이다.
존 터키는 거의 항상 편하게 입고 다녔기 때문에 다른 이들은 존이 중요한 직책을 맡고 있음을 깨닫고 그의 말에 귀를 기울이게 되기까지는 시간이 걸렸죠.
‘내 식대로 하겠어’라며 자신만의 방식으로 자존심을 지키기로 고집한다면 당신의 경력 내내 소소한 비용을 꾸준히 지불해야 합니다.
팀은 나 혼자 잘났다는 사람이 아니라, 함께 잘하려는 사람과 일하고 싶어한다.
3.1.2. 비평하고, 비평받는 법
A 씨는 입사 후 본격적으로 코드베이스를 분석한 후 설계에 깔린 가정을 정중히 물어보거나, 로직을 개선할 수 있을 법한 부분을 짚어주는 코드 리뷰 결과를 이메일로 보냈다.
얼마 후 임원이 그를 호출하여 ‘대체 왜 그러시는 거죠? 요즘 당신이 하는 일에 사람들이 불만이 많아요. 사람들을 시시콜콜 비판한다던데요? 모두 화가 나 있어요. 부드럽게 대해주세요.
A 씨는 팀원들이 자신의 코드 리뷰를 환영하고 분명히 감사해할 거라 생각했기 때문에 당황했다.
하지만 이 경우 A 씨는 팀에 퍼져있는 불만을 더 세심히 살펴보고 코드 리뷰 문화를 소개하는데 더 절제된 수단을 썼어야 한다.
예를 들어 코드 리뷰를 해도 될지 팀 차원에서 미리 논의해봤어야 한다.
건설적으로 비판하는 사람은 상대방을 진심으로 생각하고 상대방의 업무가 개선되길 바라야 한다.
동료를 존중하는 법을 배우고, 건설적이고 공손하게 비평하는 법을 배워야 한다.
누군가를 진심으로 존중한다면 자연스럽게 도움 되는 표현을 고르려 신경쓰게 될 것이다.
좋은 표현을 고르는 기술에 대해서는 추후 다룰 예정입니다. (p. 84)
나쁜 피드백 예시:
“이 메서드의 제어 흐름이 완전히 잘못됐어요. 다른 사람들은 다 xxx 패턴 썼는데요?”
이는 전형적인 공격적인 언어와 비교의 실수이다.
“잘못했다”, “고쳐라”, “남들은 안 그러더라” 는 팀 분위기를 해친다.
좋은 피드백 예시:
“이 메서드의 제어 흐름이 조금 헷갈립니다. 혹시 xxx 패턴을 적용하면 더 명확해질까요? 나중에 유지보수가 쉬워질 수도 있을 것 같아요.”
상대가 아닌 자신을 겸손하게 낮추었다.(상대가 아닌 내가 코드를 이해하는데 문제를 겪고 있는 것이다)
명령이 아닌 제안, 비판이 아닌 협력이 보인다.
아무것도 요구하지 않고 상대가 거부해도 부담을 느끼지 않도록 배려했다.
3.1.3. 빠르게 실패하기
실패는 나쁜 것이 아니다. 충분히 도전했기 때문에 일어나는 일이다.
‘가끔씩 실패하지 않는다면, 위험을 충분히 감수하지 않은 것이다.’
실패를 ‘배우고 다음 단계로 넘어갈 수 있는 절호의 기회’로 여기는 것이다.
단, 같은 방식으로 반복해서 실패한다면(= 다음 단계로 넘어가지 못함) 학습 부족, 즉 무능이다.
핵심은 작게, 자주 실패하고 빨리 교정하는 시스템을 만드는 것이다.
3.2. 비난없는 포스트모템(postmortem) 문화
포스트모템은 시스템 오류나 프로젝트 실패 후, 그 원인과 과정을 문서로 기록하고 조직 학습의 자산으로 남기는 과정이다.
<좋은 포스트모템의 구성 요소>
- 사건 개요
- 타임라인: 인지부터 해결까지
- 근본 원인 분석
- 영향 및 피해
- 즉각적인 해결 조치(책임자 포함)
- 재발 방지 대책
- 이번 사건에서 얻은 교훈
사과, 변명, 지적이 아닌 학습과 개선에 집중해야 한다.
3.2.1. 인내심
사람마다 문제 해결 방식은 다르다.
예) 상향식(바로 실행하며 탐색) vs 하향식(전체를 파악한 후 계획한 후 접근)
의견 충돌이 생기면 서로의 방식을 이해하고, 잠시 각자의 방식대로 시도해본 후 다시 공유하는 협업 루틴이 효과적이다.
협업에는 유연성과 인내심이 필요하다.
3.2.2. 마음을 열고 받아들이기
고집불통 팀원은 협업의 흐름을 끊는다.
경험상 고집불통 팀원의 의견이나 반대에는 더 이상 귀를 기울이지 않고, 대신 공인된 장애물 취급하여 피해 다니게 된다.
이런 사람이 되지 않기 위해서 ‘다른 사람이 내 생각을 바꿔도 괜찮아’ 라는 마음가짐을 가져야 한다.
결정을 공표하기 전에 주변의 이야기를 먼저 들어보자.
나중에 계속 입장을 바꾸면 우유부단하게 보일 수 있다.
다른 사람들이 선호하는 업무 방식도 이해하려 노력해야 한다.
팀에서 배우려는 자세가 곧 나의 영향력을 키우는 길이다.
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 구글 엔지니어는 이렇게 일한다 를 읽으며 정리한 내용들입니다.
