Ch02 팀워크 이끌어내기

한 줄 정의

소프트웨어 개발은 ‘팀의 단합된 노력’의 결실이며, 그 토대는 겸손(humility), 존중(respect), 신뢰(trust)입니다.

쉽게 말하면

혼자 동굴에 틀어박혀 비밀 무기를 완성한 뒤 짠 하고 세상에 공개해 모두를 놀라게 하는 천재 개발자상은 환상입니다. 현실의 위대한 소프트웨어는 거의 전부 여러 사람이 오래 부대끼며 만들어낸 결과물입니다.

자전거 기어 변속기 비유가 이를 잘 보여줍니다. 새로운 변속기 설계가 떠올라 몇 주 동안 창고에서 혼자 프로토타입을 만들지만, 완성될 때까지 비밀로 했기에 잘 아는 친구에게 조언조차 구하지 못합니다. 그러다 어느 날 이웃이 자전거 매장 직원들의 도움을 받아 거의 똑같은 설계를 먼저 완성해 끌고 나옵니다. 더 분한 건, 이웃이 내 프로토타입을 잠깐 보더니 한 주면 고쳤을 설계 결함 몇 가지를 즉시 짚어준다는 점입니다.

혼자 숨어서 일한다는 것은 이렇게 검증·조언·협업의 이점을 통째로 포기 하는 일입니다.

왜 중요한가?

엔지니어가 사람과 관련된 일에 쏟는 에너지를 줄이고 코드 작성에 더 많은 시간을 쓰려면, 역설적으로 팀워크를 먼저 이해해야 합니다. 사람을 다루는 비용을 줄이는 가장 확실한 길이 협업 문화를 갖추는 것이기 때문입니다.

핵심 근거는 두 가지입니다.

• 업무 거의 전부가 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구합니다. 그래서 경력을 미래로 이어주는 핵심은 코딩 실력이 아니라 다른 사람과 얼마나 잘 협력하느냐입니다.
• 혼자 일하면 잘못된 길로 접어들었다가 뒤늦게 깨닫고 빠져나오는 데 막대한 시간을 낭비 합니다. 어깨 너머로 살펴보다가 즉시 잘못을 짚어줄 동료가 두어 명만 있어도 결과가 크게 달라집니다.

백엔드 관점에서 이는 곧 코드 리뷰, 페어 프로그래밍, 설계 문서 사전 공유, 포스트모템 같은 협업 장치가 “있으면 좋은 문화”가 아니라 실패 비용을 왼쪽으로 당기는 엔지니어링 수단 이라는 뜻입니다.

핵심 내용

천재 신화는 불안감의 다른 이름

리누스 토르발스, 귀도 반 로섬, 빌 게이츠 같은 이들을 흔히 혈혈단신으로 세상을 바꾼 영웅으로 떠올립니다. 하지만 실제로는 다릅니다.

• 리누스가 한 일은 유닉스와 유사한 커널의 시제품을 만들어 메일링 리스트에 뿌린 것입니다. 놀라운 성과지만 빙산의 일각이고, 그의 진짜 업적은 수천 명의 커뮤니티가 협업하도록 이끈 것입니다.
• 파이썬도 첫 버전만 귀도의 작품일 뿐, 이후 버전은 수천 명이 아이디어를 모으고 기능을 개발하며 만들었습니다.
• 마이클 조던조차 혼자 경기를 이기지 못합니다. 그의 천재성은 팀과 협동하는 방식에 있었습니다.

천재 신화(The Genius Myth) 는 팀이 이룬 성공을 단 한 사람(리더)에게 몰아주는 경향입니다. 인간은 본능적으로 영웅과 롤모델을 찾고 우상화하기에, 프로그래밍 세계에서도 ‘기술 전문가 셀럽 현상’이 신화화됩니다.

문제는 이 신화가 불안감(insecurity) 을 먹고 자란다는 점입니다. “내 작업물을 남이 보고 판단하는 게 두렵다”, “동료가 내 실수를 보면 내가 천재가 아님을 눈치챌 것이다”라는 두려움이 코드와 프로젝트를 숨기게 만듭니다. 진행 중인 작업물을 숨기려는 이유는 두 가지로 압축됩니다.

• 비난받고 싶지 않은 두려움 (완성 전이라면 더욱)
• 누군가 아이디어를 훔쳐 먼저 세상에 내놓을 거라는 두려움

핵심 통찰은 이것입니다. 불안감은 그 자체가 문제가 아니라 더 큰 문제(고립된 작업 방식)의 징후 라는 점입니다.

숨기는 건 해롭다

혼자 일하며 숨기는 것이 왜 위험한지는 세 갈래로 정리됩니다.

조기 감지 — 일찍 실패하고, 빨리 실패하고, 자주 실패하라

위대한 아이디어를 완벽히 다듬을 때까지 아무도 못 보게 하는 것은 엄청난 도박입니다. 초기 설계에는 근본적인 실수가 스며 있기 쉽고, 자칫하면 바퀴를 다시 발명하게 됩니다.

피드백을 ‘초기’ 단계에서 받을수록 이 위험이 크게 줄어듭니다. 그래서 “일찍 실패하고, 빨리 실패하고, 자주 실패하라(fail early, fail fast, fail often)” 가 검증된 주문이 됩니다. 사람들이 목욕탕에 몸을 던지기 전에 발가락부터 담가보는 것과 같습니다.

다만 단서가 있습니다. 방향이나 목표에 대한 확신이 서지 않은 상태에서 너무 일찍부터 너무 많은 피드백을 받으면 오히려 위험 할 수 있습니다. 조기 공유의 가치는 “방향이 정해진 뒤 검증을 앞당기는 것”이지 “방향 없이 휘둘리는 것”이 아닙니다.

버스 지수 — 지식이 한 사람에게 몰리면 프로젝트가 죽는다

버스 지수(bus factor): 몇 명의 팀원이 버스에 치여 일을 할 수 없게 될 때 프로젝트가 망하게 되는지를 나타내는 지수.

프로토타입의 동작 원리를 이해하는 사람이 나뿐이라면 버스 지수는 1입니다. 내가 사라지면 프로젝트도 사라집니다. 지식을 동료 한 명과 공유하면 버스 지수는 2가 됩니다.

여기서 ‘버스에 치인다’는 문자 그대로의 사고만 뜻하지 않습니다. 결혼, 이직, 퇴사, 병가처럼 살다 보면 마주치는 예기치 못한 사정 전부를 말합니다. 그래서 현실적인 대비책은 다음과 같습니다.

• 각 책임 영역마다 2차 소유자(담당자) 를 둔다
• 제대로 된 문서를 갖춰 둔다
• 작은 팀을 꾸려 함께 설계하고 구현한다

진척 속도 — 빡빡한 피드백 루프가 곧 속도다

컴파일러 비유가 핵심을 찌릅니다. 1만 줄을 다 작성한 뒤 마지막에 단 한 번 ‘컴파일’을 누르는 사람은 없습니다. 함수 하나 짜고 컴파일하고, 테스트 하나 짜고 컴파일하고, 리팩터링 살짝 하고 컴파일합니다. 작은 단계마다 컴파일러가 즉시 오타와 버그를 잡아주기 때문입니다.

협업도 똑같습니다. 사람으로 구성된 빡빡한 피드백 루프가 잘못된 방향으로 가는 것을 조기에 잡아줍니다. 현재의 데브옵스 철학이 “가능한 한 일찍 피드백하고, 일찍 테스트하고, 보안과 프로덕션 환경을 초기부터 고려한다” 를 천명하는 것도 같은 맥락이며, 이 모두가 원점 회귀(shift left) 라는 아이디어로 수렴합니다. 문제를 빨리 찾을수록 고치는 비용이 낮아집니다.

빠른 피드백 루프는 코드 수준뿐 아니라 프로젝트 수준에서도 이뤄져야 합니다. 요구사항과 환경은 계속 바뀌므로, 계획이나 설계 변경이 필요한 시점을 즉시 알려줄 피드백 루프가 곧 팀 플레이입니다. “눈이 많아야 버그가 줄어든다” 를 넘어 “눈이 많아야 프로젝트가 탈선하지 않고 옳은 방향으로 나아간다” 가 더 정확한 표현입니다.

사회적 상호작용의 세 기둥 (HRT)

협업의 열반에 들어가려면 사회적 스킬의 세 기둥 을 익혀야 합니다. 이 세 원칙은 관계라는 톱니바퀴에 기름을 치는 정도가 아니라 모든 건강한 상호작용의 초석입니다.

기둥	의미	핵심 태도
겸손(humility)	당신과 당신의 코드는 우주의 중심이 아니다	모든 걸 알지도 완벽하지도 않음을 인정하고 배움에 열려 있기
존중(respect)	함께 일하는 동료를 진심으로 생각한다	친절히 대하고 능력과 성취에 감사하기
신뢰(trust)	동료가 유능하고 올바른 일을 하리라 믿는다	필요하면 스스로 방향을 정하게 맡기기

거의 모든 사회적 갈등의 근본 원인을 분석해보면 결국 겸손·존중·신뢰 중 하나가 부족해서 일어났음을 알게 됩니다. 주변에서 벌어지는 불편한 상황을 떠올려보면 대부분 “모두가 만족할 만큼 겸손한가? 서로를 진심으로 존중하는가? 서로 신뢰하는가?”라는 질문으로 환원됩니다.

HRT를 실천하는 법

추상적인 세 기둥이 현실에서 어떻게 작동하는지가 이 장의 알맹이입니다.

자존심 버리기

늘 자신이 회의실에서 가장 중요한 인물인 것처럼 행동하는 사람과 함께 일하고 싶은 사람은 없습니다. 겸손은 자신감을 버리라는 뜻이 아니라, 모든 걸 다 아는 듯 행동하지 말라 는 뜻입니다.

더 나은 방법은 개인의 자존심을 집단적(collective) 자존심 으로 옮기는 것입니다. 자신이 잘 아는 분야를 혼자 걱정하는 대신 팀의 성취와 단체의 자부심을 높이려 노력합니다. 아파치 소프트웨어 재단이 강한 정체성을 지니면서도 커뮤니티보다 자기 홍보에 더 관심을 두는 사람을 거부하는 것이 대표적입니다.

리처드 해밍의 일화도 같은 결을 전합니다. 비서들에게 농담을 건네며 가까워지려 노력한 결과, 정작 머리 힐 지역의 모든 복사 서비스가 멈춘 날에도 그의 비서만은 한 시간 거리의 다른 지점까지 가서 복사를 해다 주었습니다. 교훈은 “사회적 관계의 힘을 과소평가하지 말라” 는 것입니다. 사람을 조종하라는 게 아니라, 일이 진행되도록 관계를 형성하라는 뜻이며, 관계는 언제나 프로젝트보다 오래 지속됩니다.

비평하고 비평받는 법 배우기

신입 프로그래머 희철의 일화가 핵심입니다. 출근 첫 주가 지나자 희철은 팀원들의 코드를 리뷰하며 설계 가정을 정중히 묻고 로직 개선점을 짚어주었습니다. 본인은 환영받으리라 생각했지만, 몇 주 후 임원이 그를 불러 “팀원들이 가혹하게 비판받는다며 화가 나 있다”고 전합니다.

전문적인 환경에서 비평에 개인적인 감정이 실릴 이유는 없습니다. 비평은 단순히 더 나은 프로젝트를 만드는 과정일 뿐입니다. 여기서 반드시 구분해야 할 것이 ‘창조적 산출물에 대한 건설적 비평’과 ‘상대의 성향에 대한 맹렬한 공격’ 의 차이입니다.

비판하는 쪽이 지켜야 할 핵심은 누군가를 진심으로 존중하고 그의 업무가 개선되길 바라는 마음 입니다. 같은 지적도 표현에 따라 정반대로 받아들여집니다.

방어를 부르는 표현	협업을 부르는 표현
”이봐요, 이 메서드의 제어 흐름을 완전히 잘못 짰잖아요. 다른 사람처럼 xyz 패턴을 적용했어야 해요."	"저기, 이 부분의 제어 흐름이 좀 헷갈리네요. 혹시 xyz 패턴을 적용하면 더 명확해질까요?”
상대가 틀렸다고 단정 (‘잘못했다’, ‘고치라고 요구’)	자신이 이해하는 데 문제를 겪고 있다고 낮춤
다른 사람과 다르게 했다고 비난	아무것도 요구하지 않고 거부해도 부담 없게

비평받는 쪽도 마찬가지입니다. “나는 내 코드가 아니다” 를 반복해 되뇌며 자신과 자신이 만든 것을 분리해야 합니다. 프로그래밍은 하나의 기술이라서 연습하면 실력이 좋아집니다. 동료가 기술 개선법을 알려주는 것을 인간으로서의 가치 공격으로 받아들여서는 안 됩니다.

빠르게 실패하고 반복하기

천만 달러를 잃은 임원과 CEO의 도시 전설이 이 원칙을 압축합니다. 사고를 친 임원이 사직서를 내밀자 CEO가 답합니다. “자르다니요? 제가 왜 해고합니까? 천만 달러는 그냥 당신 훈련비라고 치죠.” 같은 실수를 하지 않을 유능한 임원을 잃는 게 더 손해라는 것을 CEO가 이해하고 있기 때문입니다.

구글의 좌우명 ‘실패는 선택이다’, 그리고 ‘가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다’ 라는 믿음이 여기서 나옵니다. 토머스 에디슨의 “나는 만 가지의 잘못된 방식을 찾아낸 것일 뿐 실패한 게 아니다”도 같은 맥락입니다.

단, 중요한 단서가 있습니다. 동일한 일을 반복해서 실패한다면(즉, 다음 단계로 넘어가지 못한다면) 그것은 실패한 게 아니라 무능한 것 입니다. 실패의 가치는 ‘배우고 다음 단계로 넘어가는 것’에 있습니다.

비난 없는 포스트모템 문화

실패에서 배우는 핵심은 근본 원인을 분석해 문서로 남기는 것입니다. 이를 포스트모템(postmortem) 이라 합니다.

가장 중요한 원칙은 비난(blame)을 배제 하는 것입니다. 포스트모템이 사죄·변명·지적으로 채워지면 목적을 잃습니다. 제대로 된 포스트모템에는 무엇을 배웠고 그 배움을 토대로 무엇을 바꿀지가 담겨야 합니다. 그리고 쉽게 열람할 수 있고, 제안한 변화를 팀이 실제로 실천하는지 확인해야 합니다.

훌륭한 포스트모템에 담겨야 할 내용은 다음과 같습니다.

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

인내심을 기르자

CVS 리포지터리를 서브버전으로 옮기는 도구를 만들던 일화입니다. 짝 프로그래밍을 하는데 한 명은 일단 뛰어들어 빠르게 시도하고 세부사항을 넘기며 길을 찾는 상향식(bottom-up) 엔지니어였고, 동료 칼은 전체 지형을 먼저 파악하고 거의 모든 메서드를 구현한 뒤에야 버그 사냥에 나서는 하향식(top-down) 엔지니어였습니다.

이 성향 차이로 격렬한 논쟁이 벌어져 더는 짝 프로그래밍을 할 수 없는 지경에 이릅니다. 하지만 오랜 세월 서로를 신뢰하고 존중해온 사이였기에, 인내심을 잃지 않고 새로운 협업 방식을 찾아냅니다. 함께 버그를 확인한 뒤 각자 자리로 돌아가 각자의 방식으로 풀고, 알아낸 사실을 가지고 다시 모이는 식이었습니다. 인내심 덕분에 프로젝트도 구하고 우정도 돈독해졌습니다.

마음을 열고 받아들이자

다른 이로부터 배우는 데 열려 있을수록 자신의 영향력도 커집니다. 모순처럼 들리지만, 주변이 아무리 설득해도 고집을 굽히지 않는 사람이 낀 팀을 상상해보면 분명해집니다. 그런 사람의 의견과 반대에는 더 이상 귀 기울이지 않게 되고, 대신 ‘공인된 장애물’로 취급하며 피해 다니게 됩니다.

“다른 사람이 내 생각을 바꿔도 괜찮아” 를 늘 머릿속에 담아두는 것이 핵심입니다. 새 증거가 나오면 생각을 바꿔야 하며, 때때로 할 수 있는 최선의 말은 “저는 잘 모르겠습니다” 입니다. 결점을 드러내는 것은 약점이 아니라 겸손을 표현하고 책임을 지려는 의지의 표출이며, 다른 이들의 의견을 신뢰한다는 신호입니다. 그 결과 사람들은 당신의 솔직함과 용기를 존중하게 됩니다.

구글답게 — 모호한 가치를 구체적 행동으로

초창기 구글에는 ‘구글답게(Googley)’ 라는 표현이 있었습니다. 명확히 정의된 적이 없어 ‘사악해지지 말자’, ‘옳은 일을 하자’ 정도로 두루뭉술하게 쓰였습니다.

문제는 채용 면접과 인사 평가에 이 말이 쓰이기 시작하면서 터졌습니다. 정의가 없으니 모두가 각자의 의미로 활용했고, 결국 ‘구글답게’가 ‘나와 같게’로 변질되어 무의식적 편견(bias)을 낳을 위험 에 처했습니다. 면접관 개인이 같이 맥주를 마시고 싶은지가 후보의 역량 평가에 끼어드는 것입니다.

구글은 ‘구글다움(Googleyness)‘의 기준을 명확히 정의해 이 문제를 해결했습니다. 겸손·존중·신뢰를 드러내는 구체적 행동을 못 박은 것입니다.

행동 기준	의미
모호함을 뚫고 번창한다	상충하는 메시지·방향 속에서도 합의를 이끌어내고 진전을 이룬다
피드백을 소중히 한다	품위와 겸손을 유지하며 피드백이 주는 가치를 이해한다
저항(항상성)을 극복한다	다른 이들이 관성 때문에 움직이지 않아도 야심 찬 목표를 밀고 나간다
사용자를 우선한다	제품 사용자 입장에서 생각하고 가장 도움 되는 행동을 추구한다
팀에 관심을 기울인다	동료 입장에서 생각하고 누가 시키지 않아도 적극적으로 돕는다
옳은 일을 한다	진정성을 지키기 위해서라면 어렵거나 불편한 결정을 내릴 수 있다

이렇게 모범 행동을 정의한 뒤로 ‘구글답게’라는 모호한 용어는 폐기됐습니다. 기대하는 바를 구체적으로 밝히는 편이 항상 더 낫기 때문 입니다. 이는 어느 조직이든 가치(value)를 평가 기준으로 쓸 때 새겨야 할 교훈입니다. 추상적 슬로건은 결국 평가자의 편견을 정당화하는 도구로 변질되기 쉽습니다.

비교 / 트레이드오프

사무실 형태: 개인 사무실 vs 오픈 플로어 vs 중간

생산성을 둘러싼 공간 논쟁도 결국 “방해 없는 몰입”과 “팀원 간 즉각적 소통” 사이의 트레이드오프입니다. 어느 한쪽 극단도 정답이 아닙니다.

형태	장점	단점
개인 사무실 (25년 전 정설)	방해 없이 코드에 몰두할 시간 보장	팀과의 즉각적 소통 단절, 잘못된 일에 오래 몰입할 위험
오픈 플로어 플랜 (현재 다수)	물리적 근접성	모두에게 들려 오히려 입을 다물게 됨, 적개심 유발
중간 (4~8명 작은 방)	부담 없는 자발적 대화, 적절한 소음 차단	—

방해 차단 장치(헤드폰, 토큰 인형 등)도 양날의 칼입니다. 단기적으로는 몰입에 도움 되지만, 늘 끼고 있으면 사무실에서 고립되어 협업에 방해가 됩니다. 정확한 균형점 찾기는 정답 없는 예술의 영역입니다.

상향식(bottom-up) vs 하향식(top-down) 엔지니어

graph LR
    A["상향식 엔지니어"] -->|"먼저 뛰어들어<br/>빠르게 시도, 세부는 넘김"| C["같은 버그를<br/>다르게 접근"]
    B["하향식 엔지니어"] -->|"전체 지형 파악 후<br/>메서드 구현 뒤 버그 사냥"| C
    C -->|"신뢰·인내로<br/>역할 분리"| D["각자 방식으로 풀고<br/>다시 모여 종합"]

성향 자체에는 우열이 없습니다. 충돌의 해법은 한쪽을 굴복시키는 것이 아니라, 신뢰를 바탕으로 각자의 강점을 살리는 협업 구조를 새로 설계하는 것입니다.

내 생각

• 천재 신화는 시니어가 가장 빠지기 쉬운 함정 입니다. 경력이 쌓일수록 “내가 짠 게 맞다”는 확신이 코드 리뷰를 형식적으로 만들고 버스 지수를 1로 떨어뜨립니다. 핵심 도메인 지식이 한 사람 머릿속에만 있으면, 그 사람의 휴가가 곧 장애 대응 공백입니다.

• 버스 지수는 측정 가능한 운영 리스크 입니다. 2차 소유자 지정과 문서화는 “착한 문화”가 아니라 SPOF(단일 장애점) 제거 작업입니다. 온콜 로테이션, 런북, 페어 온보딩이 모두 버스 지수를 올리는 장치입니다.

• 비난 없는 포스트모템은 인시던트 학습의 전제 조건 입니다. 책임자를 찾는 순간 사람들은 정보를 숨기고, 다음 장애의 근본 원인은 영영 묻힙니다. ‘blameless’가 ‘accountability 없음’을 뜻하지 않는다는 점만 팀에 명확히 해두면 됩니다.

• ‘구글답게 → 나와 같게’ 변질은 모든 컬처핏 평가의 위험 입니다. 채용·평가 기준을 슬로건으로 두면 평가자 편견을 정당화하는 알리바이가 됩니다. 기대 행동을 관찰 가능한 항목으로 못 박아야 공정성이 생깁니다.

• “나는 내 코드가 아니다”는 코드 리뷰 문화의 기초 체력 입니다. 리뷰 코멘트를 인신공격으로 받는 팀은 리뷰가 빈약해지고, 빈약한 리뷰는 곧 품질 저하로 돌아옵니다. 표현을 질문형으로 낮추는 작은 습관이 리뷰 수용성을 좌우합니다.