책 '구글에서의 소프트웨어엔지니어링'의 '문화' 요약

Oreilly의 Trending에 올라와 있는 "Software Engineering at Google"의 Culture 부분을 읽고, 앞 부분부터 참 좋은 내용이 많다는 생각이 들었습니다. 

 

저 개인적으로도 그 내용을 체화하기 위해 아래 요약으로 그 핵심을 전달하며 공부해보려 합니다. 이 부분은 읽으면서 전반적으로 느낀 점은, 아래의 사항들이 '추상적'인 언급이 아니라 프로세스화 되고, 가능하다면 기술로 구현되고, 장기적으로 경제적 이득이 되기에 행하고 있다는 점입니다. 여기서 '경제적 이득'이라는 부분은, 마틴 파울러가 Unittest가 실제로 코드 운영유지에 효율적이기에 해야한다고 하는 것과 유사한 맥락입니다.

 

• 팀으로 일하기
• 지식 공유하기
• 평등을 위한 엔지니어링
• 어떻게 팀을 리드하는가?
• 많은 사람을 이끌어가기
• 엔지니어링 생산성을 측정하기

---

팀으로 일하기

이 부분의 핵심이 되는 관점은 '소프트웨어 개발은 팀워크 활동'이라는 점입니다. 그렇기에 엔지니어링 팀으로 성공하기 위해서는, 겸손과 존중 그리고 신뢰에 중점을 두고 언행을 정돈하여야 합니다.

 

The Genius Myth

구글 오픈 소스 프로젝트 호스팅 서비스를 운영하던 Ben과 저자는 종종 코드를 숨기려하는 저의가 깔린 요청들을 받았습니다. 비판을 피하고 싶고, 있는 그대로를 보여주기 꺼리는 이러한 행동들은 더 큰 문제를 일으키는 증상이 되기 마련입니다.

 

그러한 insecurity의 저변에는 Linus Torvalds, Guido Van Rossum, Bill Gates와 같이 고독하게 혼자서 천재적으로 운영체제, 파이썬, MS를 완성시켰다는 '천재에 대한 환상'이 큰 부분을 차지합니다. 그리고 이러한 환상은 팀의 성공을 한 명의 사람이나 리더의 성공으로 잘 못 인식하게 합니다.

 

많은 사람들이 그들을 신격화(idolization)하였지만, 실제로 파이썬은 수백명의 뛰어난 인재들이 다양한 버젼, 아이디어, 기능, 버그 수정을 위해 헌신한 결과이고, Bill Gates의 가장 큰 업적은 MS-DOS와 관련해 성공적인 기업을 build한 것입니다. 

 

숨기는 것의 해로움

만약에 당신이 대부분의 시간을 혼자 일한다면, 당신은 실패의 확률을 높이는 동시에 성장가능성을 낮추고 있는 것입니다. 소프트웨어 개발이 깊은 집중과 혼자만의 시간이 필요한 것은 사실이나, 언제나 협업과 리뷰를 통해 가다듬을 필요가 있습니다.

 

혼자 일하다 보면, 적절한 방향성으로 진행되고 있는지 알기 어렵고 또한 같은 일을 반복하고 있을 위험에 빠지기 쉽습니다(risk reinventing wheels). 그렇기에 다른 시각을 가진 협업자들의 관점이 필요하고 협업자와 함께 일하며 주고 받는 상호 간의 피드백 루프는 마치 프로그래머가 개발을 진행하는 flow와 비슷합니다: 새로운 함수를 작성하고, 컴파일하고, 테스트를 추가하고, 코드를 조금 리팩토링하고, 컴파일하고 등등.

 

그렇기에 "숨기는 것(혼자 일하는 것)"은 다른 사람과 같이 일하는 것보다 근본적으로 위험합니다. 

 

Software Development is a team Endeavor

혼자서 개발한 널리 쓰이는 소프트웨어가 몇 개나 될까요? 거의 존재하지 않습니다. 모두 팀이 만들어낸 것입니다. 그렇기에 겸손, 존중, 신뢰를 기본으로 관계를 만들어 나가야 합니다. 관계는 언제나 프로젝트를 넘어서 지속됩니다. 

 

당신과 다른 사람의 성격과 일하는 방식을 이해하는 것에 대한 투자가 장기적인 생산성을 높일 수 있기에 다른 사람에게도, 자기 자신에 대한 실수에도 Open되어 있을 수 있어야 합니다.

 

 

지식 공유하기

인터넷 상에 있는 아무나보다는 당신이 속한 조직에서의 누군가가 그 문제가 존재하는 도메인과 컨택스트를 더 잘 이해하고 있습니다. 그렇기에 1) 잘 대답해줄 수 있는 전문가가 있어야 하고, 2) 그들의 지식을 잘 나누어줄 수 있는 메커니즘이 필요합니다. 그러한 메커니즘은 단순한 1:1 구두 질문부터 좀 더 구조화된 튜토리얼이나 사내 클래스까지 다양하게 존재합니다. 무엇보다도 중요한 것은 사내 전체에 '배움의 문화'가 깊이 스며들어야 합니다.

 

사내 지식 공유의 어려운 점

구글에서 발견한 어려운 이유는 다음과 같습니다:

 

• 심리적 안정감(Psychological safety)의 부재
• 정보고립 (Information islands)
• Single point of failure (SPOF)
• 과도한 전문성 격차
• 이해 없는 카피의 반복 (Parroting)
• 괜히 들쑤시는 것이 아닌가에 대한 두려움

'배움의 문화'에 대한 근본적인 철학

소프트웨어 엔지니어링은 기본적으로 여러 명이 여러 버젼의 프로그램을 개발하는 활동입니다. 그렇기에 사람이 소프트웨어 엔지니어링의 중심에 있으며 코드는 중요한 결과물이지만 그 일부분에 지나지 않습니다. 코드는 아무 곳에서나 발생하는 것이 아니라 전문가를 통해 탄생하며, 그 전문가도 처음에는 모두 초보자였습니다. 그렇기에 조직의 성공은 인재에 투자하는 것에 의존합니다.

 

전문가로부터 개인적인 1:1 조언,  문서화된 지식, 암묵지(tribal knowledge) 등 배움의 형태 모두 각각 장단점을 가집니다. 그렇기에 한 가지에 국한되지 않고 다방면으로 균형잡힌 지원과 각 방식에 맞는 활동이 필요합니다.

 

심리적 안정감을 주는 문화

심리적 안정감은 배움의 환경을 조성하는데 필수적입니다. 

 

배우기 위해서는 먼저 모르는 것이 있다는 사실을 인정해야 합니다. 사실 배움의 많은 부분은 어떤 것을 시도하고 실패해도 된다고 느끼는 것에 존재합니다. 구글의 리서치 역시, 심리적 안정감이 효율적인 팀의 중요한 부분임을 시사하고 있습니다.

 

그러한 부분을 위해서 다음과 같은 2가지 프로그램이 존재합니다:

 

• 멘토쉽: 구글에서는 "Noogler (New Googler)"이 조인하면 같은 팀이 아닌 타팀의 멘토를 1:1로 붙여줍니다. 어떤 것이든 비교적 자유롭게 질문할 수 있는 공식적인 멘토는 멘티가 편하게 조직 문화에 녹아드는 데 중요한 역할을 합니다.
• 다수 그룸에서의 심리적 안정감: Recurse Center's Social Rule과 같은 interaction patterns을 지향합니다.

배우고, 질문하고, 직접 나누고, 조직 전체로 나누기

주변 동료들에게 질문하고 해당 작업의 context를 이해(섣불리 갈아엎기보다는)하면서 스스로의 지식을 키워나갈 수 있습니다. 그러한 질문은 직접할 수도 있고, 구글 내의 그룹챗, 메일링리스트 또는 (스택오버플로우와 유사한) 사내 게시판(Yet Another Question System) 등을 통해 커뮤니티에 질문할 수도 있습니다. 

 

또한, 언제나 모두는 가르칠 수 있는 어떤 것을 가지기에 Office hours에나, tech talks나 class를 통해 사내 구성원들에게 지식을 나누고 문서화와 코드를 통해서도 지식을 나눌 수 있습니다. 

 

조직 전체의 지식 공유를 위해서 구글은 문화적인 측면의 '존중'을 강조하는 부분도 있으나, 인센티브와 같은 시스템을 사용하기도 합니다. 각 구성원들은 보상을 줄 수 있는 일정 포인트를 가지며, 이 포인트를 지식공유에 기여한 다른 구성원에게 주면 그것은 금전적 보상으로 제공됩니다. 

 

또한, 형식을 갖춘 공유를 위해서 개발 가이드, go/ links (특정 언어, 프레임워크에 대한 자료를 모아놓은 곳, 예로 go/python는 파이썬 가이드), codelabs, static analysis 등을 사용합니다. 

 

마지막으로, Readability를 위해 코드리뷰를 통해 정규적인 멘토쉽 프로세스를 운영합니다. 여기서 "readability"는 단순히 코드 가독성을 넘어서 language idioms, code structure, API design, 적절한 common 라이브러리 사용, 테스트 커버리지 등 다양한 부분을 포함합니다. 

 

현재 약 20%의 구글 엔지니어가 이러한 프로세스에 참여하고 있습니다.  

 

 

평등을 위한 엔지니어링

구글 엔지니어의 대다수는 남성이고, 백인이나 아시아인입니다. 그렇기에 편향(Bias)은 디폴트입니다. 사용하는 데이터일 수도 있고, 은연중의 가정이 그러할 수도 있습니다. 또한, 기술자로써 많은 사람들이 사용하는 제품을 만들기에 그 사용자는 전혀 기술을 모르는 사람일 수도 있습니다.

 

그렇기에 항상 "모두를 위해" 만들고, 모두의 관점으로 바라보기 위해 노력해야 합니다. 

 

이 부분은 구글의 이미지 분류 서비스가 한 구글러가 자신의 흑인 친구와 찍은 사진에서 친구를 "고릴라"로 분류한 것과 같은 일이 발생한다는 점을 보면 더욱 시스템적으로 관리되어야 할 사항입니다 (구글은 인풋 데이터를 통계적 편향 검증한다고 합니다). 

 

그러한 편향을 피하기 위해서, 채용(미약함)도 제품 개발에도 다양화라는 가치를 고려하여 업무가 진행됩니다. 그리고 상품의 개발 속도는 중요하지만, 그것이 사용자에게 해가 되는 부분이 고민된다면 상품 출시를 조금 늦추는 것이 더 적절합니다.

 

 

어떻게 팀을 리드하는가?

구글의 팀은 주로 성능, 생산성, 팀원의 행복을 책임지는 '엔지니어링' 매니저와 제품의 기술적 측면을 책임지는 Tech Lead가 이끌어 갑니다 (겸직하는 경우도 존재).

 

먼저, 엔지니어링 매니저의 Antipatterns을 소개해주고 있습니다: 아첨꾼만을 채용함, 저성과자를 신경쓰지않음(가능한 빨리 그들을 돕거나 괘도에 오를 수 있도록 처리해야 합니다), Human Issues를 신경쓰지않음, 모두의 친구가 되려함, 채용기준에 타협함(5명 뽑기 위해 50명을 면접보고 상대적 비교로 5명을 뽑는 것은 그저그런 팀을 만드는 가장 빠른 방법), 팀을 아이들처럼 대함 등.

 

반대로 긍정적인 행동양식으로는 Lose the Ego, Be a Zen Master, Be a Catalyst, Remove Roadblocks, Be a Teacher and a Mentor, Set Clear Goals, Be Honest, Track Happiness 같은 부분을 강조하고 있습니다.

 

팀 내에서 팀장의 역할이라는 글에서 다룬 부분과도 유사한 부분이 보이는 것 같습니다.

 

 

많은 사람을 이끌어가기

매니저에서 역할이 점점 진화하면서, 당신이 해결해야할 문제의 범위는 점점 넓어져가고 더 추상화되어 갑니다. 점점 "higher level"로 가게 되면서, 점점 더 technical하거나 engineering details에서 멀어집니다. "깊게"보다는 "넓게" 팽창합니다. 

 

그러한 지점에서 아래 3가지를 항상 떠올리게 됩니다:

 

• Always Be Deciding: 팀으로 이뤄진 팀을 관리하는 것은 더욱 higher level의 결정을 하는 것입니다. 특정 엔지니어링 task를 해결하는 것 보다는 high-level 전략을 짜는 것에 집중하게 되며, 대부분의 결정은 정확한 trade-offs를 찾는 것입니다.
• Always Be Leaving: 핵심은 "Self-Driving" 팀을 만드는 것입니다. 기술적인 마법을 부리는 것이 아니라, 사람들을 조직화하는 것입니다. 커다란 문제를 적절히 나누고, 각 부분을 해결할 사람(또는 팀에게) 할당하는 것입니다. 그렇게 그러한 부분에서 "손을 떼고" 더 고차원적이고 본질적인 부분에 당신의 시간을 할애할 수 있어야 합니다.
• Always Be Scaling: 리더로써, 가장 귀중한 자원은 제한된 당신의 시간과, 주의, 그리고 에너지입니다. 성공은 시간이 지날수록 더 많은 책임을 지웁니다. 그렇기에 당신은 그런 제한된 자원들을 보호할 수 있도록 proactive하게 이러한 관리를 scaling하여야 합니다. 

엔지니어링 생산성을 측정하기

구글은 데이터 드리븐 기업입니다. 그렇기에 대부분의 제품과 디자인 결정은 데이터에 기반하고 있습니다. 엔지니어링의 생산성도 예외는 아닙니다. 

 

구글은 조직이 점점 커지면서, 커뮤니케이션 비용은 기하급수적으로 높아져 갔고 인원을 더 채워넣으면 비지니스의 범위는 넓힐 수 있지만 그러한 커뮤니케이션 비용을 scale하지는 못하였습니다. 그러한 부분에서 구글은 커뮤니케이션 비용이 높아지는 것은 각 개인의 생산성을 높이는 것을 통해 막을 수 있다고 보았습니다.

 

그렇게 무엇이 생산성을 높이는지 찾고 해결하였지만, 그렇게 생산성을 찾기 위하는 프로세스에도 많은 비용이 소모되었고 비니지스의 확장 속도를 따라가지 못하고 있었습니다.

 

그렇게 소프트웨어 엔지니어링 생산성을 높이는 것이 목표가 아니라 그렇게 생산성을 높이는 활동을 더욱 효율적으로 할 수 있도록 하는 것이 목표가 되기 시작하였습니다. 엔지니어링 생산성에 대한 연구를 진행하는 팀이 그렇게 신설되었고 어떻게 엔지니어링 생산성을 효율적으로 높일 수 있는지 다음과 같은 프로세스를 만들기 시작하였습니다. 

 

측정할 필요가 있는지 되돌아보기

측정은 그 자체로 많은 비용이 듭니다. 아래와 같은 질문을 통해 어떤 부분을 체크해야 하는지 확인할 수 있습니다:

 

• 어떤 결과를 예상하고 왜 그런지
• 측정된 데이터가 그러한 예상된 결과를 뒷받침한다면 어떤 액션을 취할 것인지
• 누가 그 결과에 대한 액션을 취하고, 언제 취할 것인지 (측정 요청자가 결과를 실행할 수 있는 권한과 자원이 있는지 확인차)

또한, 아래와 같이 측정이 필요하지 않을 수 있는 많은 상황들이 존재합니다:

 

• 프로세스/도구를 변경할 여력이 지금 없을 때
• 다른 요인으로 인해 지금의 결과가 곧 의미없어질 때
• 어쨋든(결과에 상관없이) 하려는 일을 위해 측정 결과가 그냥 하나의 메트릭으로 사용하려할 때
• 얻을 수 있는 메트릭들이 문제를 측정하기에 정확하지 않고 다른 요인을 통해 대략적인 추산이 가능할 때

소프트웨어 프로세스를 측정하는 것의 성공은 가정을 올바르게 세우는지 아닌지에 존재하지 않습니다. 그것은 결정을 해야만하는 이해관계자들에게 데이터를 제공하는 것을 의미합니다. 

 

목적 및 시그널, 그리고 의미있는 메트릭 선택하기

구글에서는 Goals/Signals/Metrics(GSM) 프레임워크를 통해 메트릭 설정 가이드를 제공합니다. 

 

• Goal은 원하는 결과물입니다. High level에서 어떤 것을 이해하고자 하는지가 반영된 것이며 측정하는 특정 방식을 포함하지 않습니다.
• Signal은 원하는 결과물을 이루었는지 어떻게 알 수 있는가에 관한 것입니다. 시그널은 측정하고 싶은 것이나 그 자체로는 측정이 불가능한 것입니다.
• Metric은 시그널에 대한 proxy입니다. 이것은 우리가 실제로 측정할 수 있는 것입니다. 이상적인 측정치는 아니나, 충분히 시그널을 대변한다고 믿는 수치입니다.

메트릭을 선택할 때 고려해야할 사항은 어떠한 변화가 생산성의 한 측면은 증진시키나 다른 측면은 감소시킬 수 있기 때문에 소프트웨어 생산성의 모든 분야를 측정할 수 있도록 하는 것입니다. 또한, 정성적인 메트릭도 메트릭으로 사용될 수 있다는 점입니다. 

 

그리고 결과물에 기반한 액션은 개발자의 워크플로우나 인센티브 구조에 고려될 수 있는 변경사항을 만드는 것을 목적으로 하는 것이 좋습니다. 

 

 

 

 

 

 

Reference

[1] Software Engineering at Google

[2] https://hbr.org/2016/07/dont-let-your-company-culture-just-happen