Work Well on Teams - Software Engineering at Google

본 포스팅은 Software Engineering at Google의 내용을 정리한 내용입니다.

2-3 min read 

 

 

해당 내용은 O'reilly에서 출간하고, 저자에 의해 공개된 Software Engineering at Google을 바탕으로 참고하여 정리한 내용입니다.

내용이 재밌기도 하고 기록하고 싶은 내용이 많아서 몇 가지 정리해볼 예정입니다.

 

 

---

 

팀워크 이끌어내기

 

Many eyes make sure your project stays relevant and on track

 

많은 개발자들이 본인이 개발한 코드를 누군가에게 공개하는 걸 두려워한다.

아직 완성되지 않은 코드를 들키는 걸 굉장히 두려워한다.

 

"천재 신화"라는 소주제를 달았는데, 이는 코드를 한 번에 잘 짜려고 해서 붙인 것 같다.

 

저자는 코드를 숨기는 건 해롭다고 하며 하나의 예시를 든다.

만약, 본인이 정말 멋있는 아이디어가 떠올라서 멋진 프로그램을 만든다고 가정해보자.

이 아이디어를 멋지게 구현해서 다른 사람들에게 보여주며 '천재' 처럼 인정받는 기대를 가득 품는다.

그래서 말하고 싶은 욕구도 참아내며 몇 개월을 꼭꼭 숨어 개발을 한다.

 

근데 어느날, 누군가가 내가 생각해낸 이 멋진 프로그램을 사용하고 있는 걸 발견한다. 

만약, 진작 이 내용을 공유하고 보여줬다면 시간을 버리지 않았을 뿐만 아니라, 

미리 다른 강점을 가진 내용을 구상해볼 수도 있었을 텐데 말이다.

 

본인의 코드를 숨기지 않는다면 얻을 수 있는 이익들을 생각해보자.

 

 

 

Early Detection

사람들은 목욕탕에 몸을 던지기 전에 발가락부터 담가본다.

몸 전체를 아주 뜨겁거나 아주 차가운 물에 닿지 않게하기 위해 시작부터 인지하기 위함이다.

 

초기에는 근본적인 설계 실수를 하기 쉽기 때문에

일을 올바르게 하고 있는지, 제대로 하고 있는지, 그리고 다른 누군가가 이미 해놓은 일은 아닌지를 확인해봐야 한다.

이를 위해서 피드백은 초기에 받을수록 이 위험이 크게 줄어든다.

 

Fail early, fail fast, fail often.

 

항상 이 말을 새겨두자.

 

이처럼 조기 공유는 혼자일 때보다 실수를 줄여주고, 아이디어를 검증하는데 도움을 준다.

뿐만아니라, 조기 공유는 프로젝트의 ‘버스 지수’를 높여주기도 한다.

 

 

bus factor

버스 지수

 

the number of people that need to get hit by a bus before your project is completely doomed.

 

버스 지수란 프로젝트를 완전히 망하게 하려면 몇명의 팀원이 버스에 치어야 하는지를 측정한 지수를 의미한다.

 

프로젝트를 수행할 때 그 프로젝트를 진행할 때의 지식이나 기술력을 아는 사람의 비율은 어느 정도인가를 생각해봐야한다는 의미이다.

만약, 해당 프로젝트의 주도적인 리더가 나 하나일 때, 내가 버스에 치이면 그 프로젝트는 망한 것이다.

5명의 사람에게 이 프로젝트를 공유를 했을 때를 생각해보자.

내가 버스에 치여도 나머지 네 사람이 이 프로젝트를 관리할 수 있다.

 

 

 

혼자 일하는 것보다 진행 속도를 가속화할 수 있다.

혼자서 잘못된 점을 끌고가는 것보다 바로 오점을 짚어주고 같이 해결 방안을 고려하는 동료가 있다면, 

그 진행 속도는 크게 가속될 것이다. 소프트웨어 엔지니어링에서 팀끼리 묶거나 pair programming하는 이유가 여기에 있는 것이다.

 

프로그래밍은 어렵고, 소프트웨어 엔지니어링은 한층 더 어렵다.

그렇기 때문에 우리에게는 제3의 눈이 필요하다.

 

 

협업을 위한 세가지 요소

협업을 위해서는 팀원들간의 건정한 의사소통이 필요하며, 이를 위해 아래의 세 가지 요소를 제안하고 있다.

 

Humility

겸손

: 모든 것을 아는 사람도, 완벽한 사람도 없다. 지속적인 자기 개발을 해라.

 

 

Respect

존중

: 함께 일하는 동료를 존중해야 한다. 친절하게 대하고, 능력과 성취를 인정(appreciate)할 줄 알아야 한다.

 

 

Trust

신뢰 

: 동료들의 유능함과 그들의 선택을 믿을 줄 알아야 한다. 그들의 선택을 받아들일 줄 알아야 한다.

You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate.

‘다른 사람이 내 생각을 바꿔도 괜찮아’가 되어야 한다는 의미이다.

 

 

자존심 버리기

"모든 주제를 시작하고 끝내는 것이 본인이다" 라고 생각하는 사람이 있거나 본인인가?

모든 내용에 사사건건 첨언을 하는 사람은 아닌가?

 

자신감을 갖는 건 나쁜 게 아니다. 

모든 걸 다 안다는 듯이 행동하지는 말라는 듯이다.

 

더 좋은 방법은 ‘집단적 collective ’ 자존심을 찾는 것이다.

자신이 잘 아는 분야에 대해 뽐내는 대신, 팀의 성취와 자부심을 높이려 노력해야한다.

 

 

비평하고 비평받기

본인이 하는 조언이 건설적인 비평인지, 상대방에 대한 비판인지를 바르게 이해하고 구별해야 한다.

건설적으로 비판은 프로젝트에 도움이 되며 개선을 줄 수 있고, 또 주어야한다. 

 

이때, 상대방을 진심으로 생각하고 상대방의 업무가 개선되길 바라야 한다.

누군가를 진심으로 존중한다면 자연스럽게 재치 있고 도움되는 표현을 고르려 신경 쓰게 될 것이다. 

 

조언을 받아들이는 사람 또한 겸손함을 가지고 받아들이며,

또 본인이 어리석다고 혹은 무시하는 것이 아니라는 것을 알아야 한다.

 

 

조언할 때의 주의점

 

"이 메서드의 제어 흐름을 완전히 잘못 짰네요. 다른 사람들처럼 xyz 코드 패턴을 적용했어야 해요."

 

위의 말에는 큰 문제가 있다.

위 대사를 통해 조언을 할 때의 주의사항을 알아보자.

 

- 누군가에게 ‘잘못했다’라고 해서는 안된다.

- 무언가를 ‘고치라고 요구’해서도 안된다. 

- ‘다른 사람들과 다르게 했다고 비난’하면 안된다.

 

이는 바보가 된 기분이 들게한다

 

그럼 어떻게 말을 할 수 있을까?

 

 “저기, 이 부분의 제어 흐름이 좀 헷갈리네요. 혹시 xyz 코드 패턴을 적용하면 더 명확해질까요? 나중에 관리하기 쉬워질지도 모르겠네요.”

 

상대가 아닌 자신을 겸손하게 낮췄음에 주목해라. 

상대가 틀린 게 아니라 여러분이 코드를 이해하는 데 문제를 겪고 있는 것이다.

 

 

바로 다음 챕터에서 저자는 심리적 안전을 제시한다. 

지식 고유 환경을 조성하기 위한 토대로 이 '지적' 은 악영향을 줄 수 있다.

참고로, 저자는 심리적 안전을 위한 '무언가를 실패해도 안전하다' 를 제시한다.

다만 이 포스팅을 쓰는 필자는 위와 같은 지적을 막는 것도 이 심리적 안전에 보탬이 될 것 같아 언급했다.

 

 

Fail fast and iterate

 

"Failure is an option"

 

 

아래 이 책에서 영감이 되며, 실패를 두렵지 않은 존재로 만들어준 글귀가 있다.

 

if you’re not failing now and then, you’re not being innovative enough or taking enough risks.
Failure is viewed as a golden opportunity to learn and improve for the next go-around.

 

해석해보면 아래와 같다.

 

때때로 실패를 겪지 않는다면, 당신은 이후의 혁신적이거나 충분한 위험을 감수하지 못할 것이다.

실패는 다음 단계로 성장하고 배울 수 있는 기회이다.

 

하지만 같이 알아둬야 하는 것은, 같은 이유로 동일한 일을 반복해서 실패한다면 실패한 게 아니라 무능함에 가깝다는 것이다.

 

 

 

Post-Mortem

실수로부터 얻을 수 있는 방법의 핵심은 postmortem처럼 실패한 원인과 그 근본을 분석하여 문서로 남기는 것이다.

 

 

Post-Mortem

Post는 이후, Mortem은 죽음이라는 뜻이다.

원래는 시체를 해부하여 그 사망 원인을 살펴보는 것을 의미한다.

 

기업에서는 포스트모템이란 단어는 기업에서 특정 과제가 끝나면 그 프로젝트 전 과정을 되돌아보며

잘된 점이 무엇인지 잘못된 점이 무엇인지를 살펴보는 작업을 의미한다.

 

 

포스트모템에는 변명, 사죄와 지적을 담아선 안되며, 무엇을 배웠는지와 배운 것을 토대로 앞으로 무엇을 바꿀지가 담겨야 한다.

기본적으로 아래와 같은 내용이 포함되어야 한다.

 

✔️ 사건 개요 

✔️ 사건의 타임라인 (인지 시점부터 해결까지)

✔️ 사건의 근본적 원인 

✔️ 영향과 피해에 대한 평가

✔️ 즉각적인 재발 방지를 위한 액션들(소유자 명시)

✔️ 추후의 재발 방지를 위한 액션들

✔️ 해당 경험에서 얻은 교훈

 

 

Humility, Respect, and Trust

겸손, 존중, 신뢰를 실현하고자 이에 해당하는 모범사례를 정의하면 아래와 같다.

 

✔️ Thrives in ambiguity

모호함을 없애고 성장한다

충돌하는 의견을 받아들이고 건설적인 논의를 거친다

 

✔️ Values feedback

피드백의 가치를 이해한다.

 

✔️ Challenges status quo

관성을 버리고 목표를 세워 도전한다

 

✔️ Puts the user first

사용자를 우선한다

 

✔️ Cares about the team

팀에 관심을 기울인다

 

✔️ Does the right thing

윤리 의식을 갖고 옳은 일을 한다 

 

 

 

 

 

전반적인 내용으로 팀워크를 이끌어내기 위해서는 '실패해도 되는 환경'과 '상대방을 존중하는 말하기'를 언급한다.

팀플레이에서 이 둘을 이끌어낸다는 것은 정말 중요하는 것을 공감하고 인정하지만, 사실 지켜지는 것은 어려운 것 같다.

많은 사람들이나 팀원이 이 글에 공감하고 같이 협력해준다면, 혹은 더 나아가 회사에서 이런 분위기를 만들어 준다면 좀 더 도전정신을 갖는 업무 환경이 될 수 있지 않을까.

 

모든 내용을 옳다, 혹은 그르다 할 수 없겠지만 구글에서 통용되는 문화를 배우고 현실적으로 쓸만한 내용들을 적용하는게 이 책을 얻는 방법이 아닐까 싶다.