ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 🧑🏻‍💻 구글 엔지니어는 이렇게 일한다 (2) - 팀워크 이끌어내기
    📕 book/🧑🏻‍💻 구글 엔지니어는 이렇게 일한다 2025. 9. 2. 09:47

    🚀 2. 팀워크 이끌어내기

    이 주제를 논하려면 여러분이 반드시 통제해야 하는 하나의 변수, 즉 ‘여러분 자신’ 을 조망하는 데서 시작해야 합니다.

    사람은 완벽하지 않습니다.

    그래서 인간을 ‘간헐적 버그들의 집합’에 가깝다고 이야기하곤 하죠.

    하지만 동료에 내재된 버그를 이해하려면 무엇보다 여러분 내면에 서식하는 버그를 먼저 이해해야 합니다.

     

    이번 장의 핵심 주제는 소프트웨어 개발은 ‘팀의 단합된 노력’의 결실이라는 점입니다.

    그래서 엔지니어링팀이 (혹은 어떤 형태든 창의적 협업이) 성공하려면 겸손, 존중, 신뢰라는 핵심 원칙에 맞게 여러분 자신의 행동을 바로잡아야 합니다.

     

    📖 2.1 내 코드를 숨기고 싶어요.

    사람들은 자신이 진행 중인 작업물을 다른 사람이 보고 판단하는걸 두려워합니다.

    • 이런 두려움은 인간의 본성에 속할 것입니다.

    우리는 소프트웨어 개발에서의 좀 더 보편적인 경향을 찾아낼 수 있었습니다.

    불안감은 사실 더 큰 문제의 징후임을 말이죠.

     

    📖 2.2 천재 신화

    구글에서의 업무는 거의 대부분이 천재 수준의 지능을 요구하지 않는 반면, 모든 업무가 최소한의 사회성을 요구합니다.

    그래서 우리의 경력을 미래로 이어주는 핵심은 다른 사람과 얼마나 잘 협력하느냐입니다.

     

    📖 2.3 숨기는 건 해롭다.

    🚨 2.3.1 조기 감지

    위대한 아이디어를 세상으로부터 숨기고 완벽히 다듬어질 때까지 아무도 들여다보지 못하게 하는 건 엄청난 도박입니다.

    초기 설계에는 근본적인 실수가 스며 있기 쉽습니다.

    그래서 피드백을 ‘조기에’ 받을수록 이러한 위험이 크게 줄어듭니다.

    검증된 주문인 ‘일찍 실패하고, 빨리 실패하고, 자주 실패하라’. 를 기억해두세요.

    조기 공유의 효과는 단지 개인적인 실수를 예방하고 아이디어를 검증하는 데 그치지 않습니다.

    프로젝트의 소위 버스 지수를 높여주기도 하죠.

     

    🚌 2.3.2 버스 지수

    🚌 버스 지수

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

     

    내 지식을 동료 한 명과 공유한다면 버스 지수는 두 배가 됩니다.

    최소한 각 책임 영역마다 2차 소유자(담당자)를 두고 제대로 된 문서를 갖춰 둔다면 프로젝트의 미래를 보장하고 버스 지수를 높이는 데 도움이 됩니다.

     

    ⏩ 2.3.3 진척 속도

    프로그래머는 긴밀하게 피드백받을 때 가장 효율적으로 일합니다.

    • 함수 하나를 짜고 컴파일하고, 테스트 하나 짜고 컴파일하고, 리팩터링 살짝 하고 컴파일합니다.
    • 이 방법이 우리가 코드를 작성하자마다 가장 빠르게 오타와 버그를 잡는 길입니다.

     

    현재 데브옵스 철학은 가능한 한 일찍 피드백하고, 가능한 한 일찍 테스트하고, 보안과 프로덕션 환경을 가능한 한 초기부터 고려한다라는 목표를 천명하고 있습니다.

     

    이 모두는 개발 워크플로를 원점 회귀(shift left)하라는 아이디어에 녹아 있습니다.

    • 즉, 문제를 빨리 찾을수록 고치는 비용이 낮아집니다.

     

    빠른 피드백 루프는 코드 수준뿐 아니라 전체 프로젝트 수준에서도 이뤄져야 합니다.

    • 야심 찬 프로젝트는 빠르게 진화하기 때문에 변화하는 환경에 잘 적응해야만 합니다.

     

    생각하지도 못한 설계 장애나 정치적인 장벽에 부딪히거나 단순히 무언가가 계확한 대로 동작하지 않을 수 있습니다. 요구사항이 기대와 다르게 바뀔 수도 있고요.

     

    여러분이라면 계획이나 설계 변경이 필요한 시점을 즉시 알려줄 피드백 루프를 어떻게 마련할 것인가요? → 정답은 팀플레이입니다

     

    📖 2.4 모든 건 팀에 달렸다.

    ‘소프트웨어 엔지니어링은 팀의 단합된 노력입니다.’

     

    다른 사람과 함께 일해야 합니다.

    • 비전을 공유하세요.
    • 역할을 나누세요.
    • 다른 이로부터 배우세요.
    • 멋진 팀을 만드세요

     

    ✅ 2.4.1. 사회적 상호작용의 세 기둥

    협업의 열반에 들어가려면 가장 먼저 사회적 스킬의 세 기둥을 배우고 익혀야 합니다.

    겸손(humility) 당신은 모든 것을 알지도, 완벽하지도 않습니다. 겸손한 사람은 배움에 열려있습니다.
    존중(respect) 함께 일하는 동료를 진심으로 생각합니다. 친절하게 대하고 그들의 능력과 성취에 감사해합니다.
    신뢰(trust) 동료들이 유능하고 올바른 일을 하리라 믿습니다. 필요하면 그들에게 스스로 방향을 정하게 해도 좋습니다.

     

    🔍 모든 사람이 만족할 만큼 겸손한가요?

     

    🔍 다른 이들을 진심으로 존중하나요?

     

    🔍 서로 신뢰하나요?

     

    💡 2.4.2 세 기둥이 중요한 이유

    얻을 수 있는 교훈은 ‘사회적 관계의 힘을 과소평가하지 말라’는 것입니다.

     

    관계는 언제나 프로젝트보다 오래 지속됩니다.

    • 동료들과 끈끈해지면 여러분이 필요할 때 기꺼이 자신들의 수고를 마다하지 않을 것입니다

     

    👍 2.4.3 겸손, 존중, 신뢰 실천하기

     

    📌 자존심 버리기

     

    겸손은 중요하지만 그렇다고 바짝 엎드리라는 뜻은 아닙니다.

    • 자신감을 갖는건 나쁠게 없다.
    • 그저 모든 걸 다 아는 듯 행동하지 말라는 뜻입니다.

    더 나은 방법이 있습니다. 바로 ‘집단적’ 자존심을 찾는 것이죠

    자신이 잘 아는 분야에 대해 걱정하는 대신 팀의 성취와 단체의 자부심을 높이려 노력하세요.

     

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

    전문적인 소프트웨어 엔지니어링 환경이라면 비평에 개인적인 감정이 실리는 경우는 거의 없습니다.

    이런 환경을 조성하려면 먼저 ‘누군가의 창조적 산출물에 대한 건설적인 비평’과 ‘다른 이의 성향에 대한 맹렬한 공격’의 차이를 모두가 바르게 이해해야 합니다.

     

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

    여기서 가장 중요한 점은 건설적으로 비판하는 사람은 상대방을 진심으로 생각하고 상대방의 업무가 개선되길 바라야 한다는 것입니다.

    그리고 동료를 존중하는 법을 배우고 건설적이고 공손하게 비평하는 법을 배워야 합니다.

     

    여러분 자신도 비평을 잘 수용할 줄 알아야 합니다.

    자신의 기술에 겸손해야 함은 물론 상대는 내 최우선 관심사를 진심으로 생각하며 절대 나를 어리석다고 생각하는 게 아님을 믿어야 합니다.

    우리 자존감을 우리가 작성한 코드(혹은 그 어떤 창작물이더라도)와 동일시해서는 안 됩니다.

    누군가에게 ‘잘못했다’라고 해서는 안 됩니다. 무언가를 ‘고치라고 요구’해서도 안 됩니다.

     

    ↩️ 빠르게 실패하고 반복하기

    구글에서 제가 정말 좋아하는 좌우명은 ‘실패는 선택이다’입니다.

    구글에서는 ‘가끔씩 실패하지 않는다면 충분히 혁신적이지 않거나 위험을 충분히 감수하지 않은 것이다’라는 믿음이 널리 통용됩니다.

    실패를 ‘배우고 다음 단계로 넘어갈 수 있는 절호의 기회’라고 생각하는 것이죠

     

    나는 만 가지의 잘못된 방식을 찾아낸 것일 뿐 실패한 게 아니다. 잘못하고 폐기한 시도 하나하나가 다음 단계로 이끌어주기 때문에 나는 낙담하지 않는다.

    -토머스 에디슨-

     

    💡 2.4.4 비난 없는 포스트모템 문화

    포스트모템

    • 프로젝트를 마친 후 전 과정을 되돌아보며 잘된 점과 잘못된 점을 되돌아보는 사후 검토 작업

     

    실패한 근본 원인을 분석하여 문서로 남기는 것이 실수로부터 배우는 핵심입니다. 이를 구글은 포스트 모템(postmortem)이라고 합니다.

     

    ⚠️ 포스트모템 문서가 쓸모없는 사죄, 변명, 지적으로 채워지지 않도록 각별히 주의하세요. 이건 포스트모템의 목적이 아닙니다.

     

    제대로 된 모스트포템에는 무엇을 배웠는지와 배운 것을 토대로 앞으로 무엇을 바꿀지가 담겨야 합니다.

    그런 다음 포스트모템을 쉽게 열람할 수 있고 포스트모템에서 제안한 변화를 팀이 실천하는지 확인해야 합니다.

    실패를 제대로 기록해두면 다른 이들도 무슨 일이 있었는지 알 수 있고 똑같은 실수를 반복하는 일을 피할 수 있습니다.

     

    훌륭한 포스트 모템에는 다음 내용이 담겨야 합니다.

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

     

    👐 마음을 열고 받아들이자

     

    다른 이로부터 배우는 데 열려 있을수록 여러분의 영향력도 커집니다. 결점이 많은 사람일수록 더 강해보입니다.

    경험상 고집불통 팀원의 의견이나 반대에는 더 이상 귀 기울이지 않게 되고, 대신 공인된 장애물 취급하며 피해 다닙니다.

     

    여러분도 이런 사람이 되길 원치는 않을 테니 ‘다른 사람이 내 생각을 바꿔도 괜찮아’라는 생각을 항상 머릿속에 담아두길 바랍니다.

    • 사실 결점을 드러낸다는 것은 겸손을 겉으로 표현하는 일이며, 책임을 지고 의무를 다 하려는 의지의 표출입니다.
    • 그리고 다른 이들의 의견을 신뢰한다는 신호이기도 합니다.

    그 결과 사람들은 당신의 솔직함과 용기를 존중하게 될 것입니다.

    때때로 여러분이 할 수 있는 최선의 말은 ‘저는 잘 모르겠습니다’일 수도 있습니다

     

    💡 2.4.5 구글답게 하기

     

    ‘구글 다움’이 갖춰야할 기준

    • 강력한 리더십을 보이고 ‘겸손, 존중, 신뢰’를 드러내는 태도와 행동들을 정의

    1️⃣ 모호함을 뚫고 번창한다.

    • 끊임없이 변화하는 환경 속에서도 상충하는 메시지와 방향에 잘 대처하고, 합의를 이끌어내고, 문제에 대한 진전을 이룰 수 있습니다.

     

    2️⃣ 피드백을 소중히 한다.

    • 피드백을 주고받을 때 품위와 겸손을 유지하고 개인과 팀의 발전에 피드백이 주는 가치를 이해합니다

     

    3️⃣ 저항(항상성)을 극복한다

    • 다른 이들이 저항하거나 관성 때문에 움직이지 않으려 하더라도 야심 찬 목표를 세우고 밀고 나아갑니다

     

    4️⃣ 사용자를 우선한다

    • 구글 제품의 사용자 입장에서 생각하고 존중하며 그들에가 가장 도움되는 행동을 추구합니다.

     

    5️⃣ 팀에 관심을 기울인다

    • 동료들의 입장에서 생각하고 존중하며 팀의 결집을 위해 누가 시키지 않더라도 적극적으로 돕습니다.

     

    6️⃣ 옳은 일을 한다

    • 모든 일에 강한 윤리 의식을 갖고 임합니다. 팀과 제품의 진정성을 지키기 위해서라면 어렵거나 불편한 결정을 내릴 수 있어야 합니다.

     

    🤔 2장을 읽고나서,,,

     

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

    내 코드를 동료에게 보여주거나 리뷰받을 때 불안함을 자주 느꼈다. 완벽하지 못한 결과물이 드러나는 것이 두려웠지만 이것이 대부분 개발자에게 자연스러운 감정임을 책을 통해 다시 깨달았습니다.

    단점과 실수에 집착하는 대신 불안의 뿌리가 결국 성장의 기회임을 받아들이는 연습이 필요함을 느꼈습니다.

     

    ✅ 버스 지수

    이전 인턴 생활을 할 때 작업에 대한 담당자 / 2차 담당자를 지정해 진행하고 일의 맥락을 꼼꼼히 기록하고 공유하는 문화였습니다. 이런 문화 덕분에 누군가 빠져도 프로젝트가 잘 이어질 수 있었는데 이런 경험을 통해서 버스 지수가 얼마나 실무에서 중요한지 이해할 수 있었습니다.

    • 기롬은 꼼꼼하게 공유는 투명하게!@

     

    ✅ 사회적 상호작용의 세 기둥

    실제 팀 프로젝트 협업 상황에서 ‘겸손, 존중, 신뢰’의 가치를 종종 실감했는데 특히 인턴십 과정에서 해당 회사에서는 ‘서로 신뢰하고 솔직하게 소통’ ‘나보다 뛰어난 동료와 함께 한다’ 라는 팀 문화가 있었습니다.

    이렇게 나보다 뛰어난 사람과 일하며 배움의 기회를 얻고 서로 격렬하게 의견을 교환해도 신뢰를 기반으로 솔직한 소통이 가능했었던 것 같고 실패와 충돌도 두려움 없이 받아들이며 자신이 하는 작업의 퀄리티과 자신감을 동시에 높일 수 있었던 것 같습니다.

     

    ✅ 피드백과 반복

    ‘빠르게 실패하고 반복하라’는 구글의 철학처럼 피드백을 빠르고 자주 받으며 개선해나가는 것이 내가 개발자로서 성장하는데 중요한 요소중 하나겠구나.. 계획이 틀어지거나 설계에 변경이 필요할 때도 혼자 고민하지 않고 즉각 팀과 공유하여 결정하는 과정을 통해서 내가 놓친 부분에 대해서 보완해나가자!

     

    ✅ 실패 후 기록과 학습

    회고나 포스트모템 문화를 통해 결과만이 아니라 그 과정에서 무엇을 배웠고 앞으로 어떻게 바꿀지 생각하는 습관이 중요함을 다시 깨닫게 되었습니다.

    이렇게 실패를 숨기지 않고 문서화해 공유하는 것이 다음 성공을 위한 중요한 요소구나!

     

    ⭐ 정리

    • 실수와 불안은 성장의 기회!
    • 기록과 공유가 개인과 팀, 프로젝트 모두에게 도움이 된다!
    • 겸손, 존중, 신뢰를 통해서 프로젝트를 진행하자.
    • 빠른 피드백–반복–학습이 개발자로 성장하는 것과 곧 나의 실력이다!

     

    댓글

Designed by Tistory.