6월 COMMIT에서는 책 한 권을 소개했습니다. ≪구글 엔지니어는 이렇게 일한다≫라는 책이에요. 이 책을 번역한 이복연(개앞맵시) 번역가는 삼성전자를 비롯한 여러 스타트업에서 개발자로, 한빛미디어 등에서 IT 전문서 편집자로 일했습니다. ≪리팩터링 2판≫, ≪이펙티브 자바 3판≫, ≪밑바닥부터 시작하는 딥러닝≫ 시리즈 등의 베스트셀러를 번역하기도 했죠.
≪구글 엔지니어는 이렇게 일한다≫는 프로그래밍 방법론을 제외한 문화, 도구, 프로세스 등을 담은 책이에요. 복연 님은 이 책을 우리보다 먼저 앞서간 사람들의 회고록이라고 이야기합니다.
복연 님은 책 내용을 기반으로 구글은 지식 공유 문화를 어떻게 만들었고, 팀워크를 이끌어내기 위해 어떤 문화를 만들었는지 등 다양한 주제를 이야기했습니다. 구글의 방식이 정답은 아니지만, 조직이 겪는 다양한 문제에 구글은 어떤 선택을 했는지 살펴보며 실마리를 얻으시길 바라요.
🎤 이 아티클은 이복연 님의 6월 COMMIT 세미나 내용을 바탕으로 재구성되었습니다.
반갑습니다
이복연입니다
10년 정도 개발자로 일했고요. 스타트업에서 3년 반, 삼성전자에서 7년 반 정도 있었습니다. 지금은 책을 만들고 있어요. 출판 기획/편집 업계로 커리어를 옮긴 지 9년이 좀 넘었네요. 40권 이상의 책을 출간했고, 오늘 소개해 드릴 ≪구글 엔지니어는 이렇게 일한다≫를 번역했습니다.
Software Engineering at Google
‘Software Engineering at Google’은 ≪구글 엔지니어는 이렇게 일한다≫의 원서 제목입니다. 소프트웨어 엔지니어링은 코드를 작성하는 행위뿐만 아니라 코드를 구축하고 유지보수하는 데 이용하는 모든 도구와 프로세스를 포괄하는 개념이에요. 기술 변화, 조직 성장 등을 모두 고려해 아키텍처를 설계하고 코딩하는 거죠.
이 책을 읽고 우아한테크코스를 총괄하는 박재성 님께서 이런 말씀을 해주셨어요. “저는 소프트웨어 엔지니어링이라는 용어에 막연한 거부감을 느끼며 살아왔는데, 소프트웨어 엔지니어링을 ‘시간 위를 걷는 프로그래밍’이라고 정의한 글귀를 읽은 순간 거부감이 사라졌습니다. 지금까지 중요하게 여기고 강조했던 많은 활동이 소프트웨어 엔지니어링에 해당했기 때문입니다.”
재성 님이 이야기한 중요하게 여기고 강조했던 많은 활동, 즉 소프트웨어 엔지니어링을 생략하는 건 프로그래밍에만 집중하는 거예요. 설계를 제대로 하지 않고 코드를 작성한다거나, 테스트를 안 하는 식이죠. 설계나 테스트를 생략해도 돌아가게는 만들 수 있으니까요.
소프트웨어 엔지니어라는 업은 개발자, 프로그래머, 코더 등 지칭하는 용어가 다양하죠. 대표적인 용어가 소프트웨어 엔지니어인 만큼 소프트웨어 엔지니어링을 제대로 이해하고 거부감을 느끼지 않으면 좋겠습니다.
구글은 무엇이 다른가?
1. 코드 리뷰
| 대다수 기업 | 구글 | |
|---|---|---|
| 리뷰 전 자동 검증 | △ | 정적 분석, (대다수의) 테스트 |
| 테스트 누락 시 리뷰 거부 | X | O |
| 리뷰어 역할 구분 | X | 다른 엔지니어, 코드 소유자, 가독성 인증자 |
가장 큰 차이는 리뷰하는 사람의 역할을 구분한다는 거예요. 다른 엔지니어, 코드 소유자, 가독성 인증자를 모두 통과해야 코드를 커밋할 수 있습니다. 한 사람이 여러 개의 역할을 동시에 맡을 수도 있겠죠.
다른 엔지니어는 주로 팀원들입니다. 작성자가 의도한 기능을 제대로 수행하고 있는지, 이해하기 쉬운 코드인지를 확인합니다. 코드 소유자 역할은 주로 테크 리드나 해당 기술 전문가가 맡습니다. 본인이 책임지고 있는 코드에 변경을 받아들여도 되는지 판단하는 거죠. 가독성 인증자는 해당 언어의 표준 스타일과 모범 사례를 잘 따르는지 확인합니다. 일관된 표준을 모든 엔지니어에게 전파하는 역할을 하죠.
2. 버전 관리와 브랜치 관리
| 대다수 기업 | 구글 | |
|---|---|---|
| 리포지터리(Repository) | (프로젝트별/팀별 리포지터리) 멀티리포 | 모노리포 |
| 의존성 관리 | 원격 저장소 활용 | 원-버전(모든 의존성을 리포지터리에, 안정된 버전은 단 하나만) |
| 개발 브랜치 | 적극 활용 | X(모든 개발을 트렁크에서) |
대다수의 개발 조직은 프로젝트나 서브 조직별로 리포지터리를 두는 멀티리포 방식을 활용하실 텐데요. 구글은 수만 명의 엔지니어가 하나의 리포지터리를 보고 개발하고 있습니다. 의존성 관리나 서드 파티 라이브러리도 해당 리포지터리에 넣어두고 있어요. 그리고 안정된 버전이 단 하나만 존재하도록 원-버전 규칙을 적용하고 있습니다.
3. 문서 자료도 코드처럼
문서 자료도 스타일 가이드와 소유자가 있습니다. 코드에 원-버전 규칙을 적용한 것처럼 문서 자료도 주제별로 하나씩 표준 문서가 지정되어 있어요. 덕분에 같은 주제의 문서가 중복해서 만들어질 일이 없죠.
4. 테스트 스위트 분류
| 일반적인 분류 | 구글의 주된 분류 |
|---|---|
| 단위 테스트, 통합 테스트, 시스템 테스트 | 작은 테스트, 중간 크기 테스트, 큰 테스트 |
구글도 단위, 통합, 시스템 테스트 분류 체계를 사용하고 있습니다. 다만 작은 테스트, 중간 크기 테스트, 큰 테스트 분류 체계가 더 중요한 역할을 하고 있어요.
5. 빌드 시스템
구글은 태스크를 디파인(Define)하는 게 아니라 산출물을 정의한 다음 그사이 의존 관계를 디파인해두면 툴에서 자동으로 태스크가 만들어집니다. 태스크를 직접 만들 필요가 없어요.
6. 내부 개발도 오픈 소스 스타일
일반적으로 오픈 소스는 인터넷에 리포지터리가 공개되어 있어 누구나 코드를 수정할 수 있는데요. 구글은 모노리포 안에 모든 프로젝트 코드가 들어 있어 구글 엔지니어라면 누구나 버그를 패치하거나 기능을 추가할 수 있습니다. 실제로 프로젝트 팀 외부에서 변경하는 양이 매우 많다고 해요.
7. 비욘세 규칙
A팀의 제품이 B팀 제품에 의존하면 B팀이 제품을 수정할 때 A팀 제품이 영향을 받는 상황을 겪어보셨을 텐데요. 자칫하면 조직 간 다툼이 생기기도 하고, 서로 책임을 전가하는 상황이 발생합니다. 이때 교통 정리를 해주는 게 비욘세 규칙이에요.
이름이 특이하죠. 가수 비욘세의 <싱글 레이디스>에는 “네가 진심으로 좋아했다면 반지를 줬어야지”라는 가사가 있는데요, 상대방의 잘못으로 나를 놓쳤다는 뜻입니다. 구글은 이 가사를 “너에게 중요한 기능이었다면 테스트를 준비했어야지”로 해석했어요.
A팀이 제품을 수정하며 B팀에 문제가 발생했는데 같은 문제가 CI(지속적 통합)에 등록해 둔 자동 테스트에서 발견되지 않았다면 전적으로 B팀 책임입니다. CI 시스템에 추가해 두지 않은 테스트는 A팀이 책임지지 않는다는 뜻이에요. A팀은 CI만 믿고 계속 개발을 이어가는 거죠.
구글은 왜 달라야 했나?
이유는 간단합니다. 소프트웨어 개발 생태계가 달라졌기 때문이에요. 생태계 규모가 커지고 복잡해지면서 참여 인력도 많아지고 있죠. 배포 방식도 패키지에서 라이브 서비스 형태로 바뀌고 있고요. 배포 대상과 종류도 어마어마하게 많습니다. 기존 틀에 갇혀 있다면 경쟁력을 유지할 수 없기 때문에 변화가 필요해진 거예요.
구글은 어떻게 달라질 수 있었나?
구글은 소프트웨어 엔지니어가 변화를 주도하고 있습니다. 스스로 어떻게 일해야 할지 고민해서 발전시키고 있는 거죠.
되도록 변화를 강제하지는 않습니다. 시간이 걸리더라도 좋은 변화의 장점을 느끼고 스스로 따르도록 유도하고 있어요. 오늘은 책에서 중요하게 다루는 주제 몇 가지를 살펴볼게요.
1장. 소프트웨어 엔지니어링이란?
프로그래밍은 눈앞에 놓인 개발에 집중하는 즉각적인 행위라면 소프트웨어 엔지니어링은 흐르는 시간 위에서 순간순간의 프로그래밍까지 모두 더한 개념이에요. 영어로는 ‘integrated’, 수학에서는 적분과 비슷합니다. 소프트웨어의 기대 수명 동안 요구되는 모든 변경에 대응할 수 있는 지속 가능한 소프트웨어를 만드는 거예요.
인력이나 컴퓨팅 파워 같은 눈에 보이는 비용도 신경 써야 하지만, 빌드 시간이나 통합 시간 같은 눈에 띄지 않는 요인도 관리해야 합니다. 단기적인 개발 능력뿐만 아니라 여러 비용 요인을 종합적으로 모니터링하고 개선해야 해요.
소프트웨어 엔지니어링처럼 창의력이 핵심인 분야에서는 인력이 가장 큰 자산입니다. 소프트웨어 엔지니어들이 행복을 느끼고 능동적으로 일하도록 만드는 게 중요해요.
2장. 팀워크 이끌어내기
1~2명이 개발하던 시대는 오래전에 끝났고 이제 우리는 팀 단위로 소프트웨어를 만드는 데 익숙하죠. 협업에는 많은 변수가 있습니다. 구성원들이 실수할 때도 있고, 팀원 간 갈등이 생기기도 하죠.
위대한 업적은 팀이 만듭니다. 이런 팀은 어떻게 만들 수 있을까요? 책에서는 겸손, 존중, 신뢰를 강조합니다. 스스로 완벽하지 않다는 걸 깨닫고 배움에 열려 있어야 한다는 겸손, 동료를 진심으로 생각하며 그들의 능력과 성취에 감사해야 한다는 존중, 그리고 동료들을 믿고 필요하면 그들이 스스로 방향을 정하게 한다는 신뢰인데요. 기술뿐 아니라 함께 일하는 동료, 상사, 그리고 나 자신까지 이해해야 훌륭한 팀워크를 발휘할 수 있어요.
3장. 지식 공유
지식을 공유하는 이유는 무엇일까요? 함께 성장하기 위해서죠. 지식이 제대로 공유되려면 전문가들이 골고루 포진해 있고, 그 사람들을 중심으로 지식이 전파될 수 있는 메커니즘이 갖춰져야 합니다. 메커니즘으로는 사내 위키, 기술 블로그, 스터디 그룹 등이 있는데요.
조직 생활을 하다 보면 배움을 가로막는 장애물이 많습니다. 먼저 정보 독점이에요. 특정 기술이나 컴포넌트 정보를 한 사람만 알고 있다면 그 사람이 빠졌을 때 팀이 돌아가지 않겠죠. 소통이 부족해 같은 목적으로 쌓은 지식이 호환이 안 되는 상황도 있습니다.
모르면 모른다고 인정하는 분위기가 중요해요. 주니어 입장에서는 ‘일단 무언가 시키니까 자신 있게 한다고 얘기했는데, 이제 와서 모른다고 하면 안 되겠지?’, ‘왠지 나만 모르는 분위기인데⋯ 어디까지 알아보고 질문해야 하지?’ 같은 걱정을 할 거예요. 심리적 안전이 부족한 건 시니어도 마찬가지입니다. 오히려 더 심할 수도 있어요. 경력이 꽤 쌓였는데 모른다고 말하면 주변에서 우습게 보거나, 경쟁에서 밀리는 건 아닌지 걱정하죠.
소프트웨어는 광활하고 변화가 많은 세계입니다. 모르는 게 많은 건 당연해요. 서로 걸어온 길이 다르니 배우고 경험한 것도 다르잖아요. 시니어라 해도 고작 몇 년 차이로 특정 영역에서 더 뛰어나긴 어렵습니다. 동료의 단점보다는 장점을 보려고 노력하면 좋겠습니다.
5장. 팀 이끌기
소프트웨어는 사람이 모여 만듭니다. 누군가는 그 사람들을 한 방향으로 이끌어야겠죠. 그래서 리더가 필요하고요.
리더가 되면 해야 할 일이 달라집니다. 팀원일 때는 우리가 ‘개발자’ 하면 떠오르는 일만 잘해도 괜찮지만, 리더는 팀을 챙겨야 해요.
구글은 리더를 2가지 트랙으로 구분합니다. 첫 번째는 ‘관리자’ 트랙의 엔지니어링 관리자, 두 번째는 ‘기술 전문가’ 트랙의 테크 리드예요. 엔지니어링 관리자는 기술이나 코드보다는 사람이나 제품, 리더십, 코칭, 멘토링에 주력합니다. 테크 리드는 실무와 기술적 전문성을 담당하고요.
구체적으로 어떤 차이가 있는지 설명해 볼게요. 엔지니어링 관리자는 프로젝트 계획, 목표 설정, 성과 산출, 팀 빌딩, 팀원 경력 성장 계획 및 코칭 그리고 팀원의 행복 증진 같은 일을 맡습니다. 테크 리드는 기술적인 결정, 기술 포트폴리오 관리, 기술 역량 확보 계획 등을 세우고요. 기술적인 지원을 많이 하는 포지션입니다.
대부분 테크 리드 쪽 진로를 생각하실 텐데 엔지니어링 관리자도 고민해 보세요. 결국 많은 사람을 이끌 수 있어야 큰 성과를 만들 수 있거든요. 사람과 기술을 동시에 잘 이끌 수 있는 사람은 희귀하기도 하고요.
9장. 코드 리뷰
구글의 개발 워크플로는 특별하지 않아요. 코드를 짜서 변경하고 코드 리뷰를 통과하면 리포지터리에 서브밋(Submit)해 바이너리(Binary)를 만들고 프로덕션 환경까지 단계별로 승격시킵니다.
변경을 생성하면 바로 테스트가 진행됩니다. 결과는 최대한 빠르게 알려주고요. 리뷰가 끝나면 리포지터리에 넣기 전에 추가 테스트도 진행합니다. 이 테스트에서도 문제가 없으면 인프라(코드 리뷰 도구)에서 리포지터리에 서브밋해요. 승격 때마다 광범위한 테스트들이 다시 진행되고요.
테스트 외에 정적 분석도 자동으로 실행됩니다. 이외에도 스타일 가이드, 규칙, 지침 같은 것들을 철저하게 관리하고 있고, 가독성 인증 제도라는 것도 시행하고 있어요.
코드 리뷰는 본질적으로 작성된 코드에서 부족한 부분을 들추는 것이다 보니 피드백이 비판적일 수밖에 없습니다. 코드 리뷰 문화가 제대로 정착되지 않으면 자칫 작성자를 향한 공격으로 여겨져 불편한 활동이 되기 쉽죠. 제대로 된 문화를 갖춰 코드 리뷰를 꾸준히 실천하면 모든 엔지니어의 역량이 상향 평준화될 수 있습니다.
코드 리뷰는 공손하고 전문가답게 하세요. 작성자뿐만 아니라 리뷰하는 사람도 코드를 보고 배울 수 있습니다. 모두에게 배움의 기회가 된다고 생각하세요.
결함이 있을 때만 대안을 제시하고, 그 외에는 작성자의 방식을 존중해 주세요. 취향에 대한 논쟁은 답이 없고, 감정이 상하기 쉽습니다.
아직 코드 리뷰가 정착되지 않았다면 팀 단위로 좋은 코드에 대한 스터디를 진행하면서 이해도를 높여보세요. 좋은 책이나 유명한 코딩 스타일 가이드를 보고 함께 공부하면 좋을 것 같습니다. 이 분야의 대표격 도서인 《클린 코드》부터 《좋은 코드, 나쁜 코드》, 《쏙쏙 들어오는 함수형 코딩》, 《디자인 패턴의 아름다움》, 《필독! 개발자 온보딩 가이드》 등 좋은 책들이 꾸준히 나오고 있습니다. 전사 단위로는 코드 리뷰를 처음 수행할 적절한 팀을 선정하고, 시행착오와 노하우를 정리해 차근차근 전파하면 좋겠습니다.
구글은 코드 리뷰에 ‘크리틱(Critique)’이라는 도구를 활용합니다. 변경을 생성하면 정적 분석과 테스트를 자동으로 돌려주고요. 리뷰를 요청하면 리뷰어에게 메일도 전송합니다. 리뷰를 받아야 하는 사람을 선택하는 걸 도와주는 기능도 있어요. 다른 코드 리뷰 도구도 비슷한 기능이 있을 거예요.
11장. 테스트 개요
구글은 테스트 분류를 크기 별로 진행합니다. 작은 테스트는 프로세스 혹은 스레드를 하나만 쓸 수 있어요. 그리고 네트워크나 디스크로부터 정보를 불러와 테스트할 수도 없습니다. CPU에서만 실행되니 굉장히 빠르고, 비결정적 요인이 제거됐기에 안정적입니다. 단위 테스트는 대부분 작은 테스트에 포함되고, 통합 테스트도 상당 부분 작은 테스트에 속할 거예요.
중간 크기 테스트는 스레드나 프로세스 개수 제한이 없습니다. 로컬 호스트 내에서는 네트워킹 등 블로킹(Blocking) 호출도 가능해요. 큰 테스트는 제약이 없습니다. 가장 불안정하기 때문에 제한적으로 진행하고 있어요.
작은 테스트가 가장 중요합니다. 구글은 매주 약 2,500만 라인의 코드가 변경된다고 해요. 돌아가는 테스트는 수십억 개에 달하죠. 가능한 한 빨리 테스트해 결과를 얻는 게 중요합니다. 비단 구글뿐만 아니라 소프트웨어 규모는 계속 커지고 복잡해지고 있어요. 구글보다 규모가 작은 회사들도 작은 테스트를 신경쓴다면 실질적인 체감 효과가 있을 거라고 생각합니다.
주니어와 개발 문화
저는 주니어 때도 어떻게 하면 문화를 개선하고, 제대로 개발할 수 있을지 관심이 많았어요. 어떻게 보면 끊임없이 이것도 해보고, 저것도 해보자며 잡음을 내는 사람이었습니다.
좋은 문화를 뿌리내리려면 다음과 같은 프레임워크를 거쳐야 한다고 생각해요. 시작은 같은 편이 되는 겁니다. 아무리 이로운 변화라도 싫어하는 사람이 추진하면 협조하기 싫어지죠. 반대로 상대방이 나를 같은 편으로 생각하지 않는다면 제가 원하는 변화를 이끌어내기도 힘들 거예요. 적을 만들지 말고 두루두루 잘 지내야겠죠.
공감을 끌어내는 것도 중요합니다. 가까운 사람이 추진한다고 해도 당장 필요 없는 변화라고 느낀다면 시간을 투자하지 않거든요. 어쩔 수 없이 하는 척만 할 수도 있고요. 추진력을 얻으려면 많은 사람의 공감을 끌어내야 해요.
이렇게까지 해도 실패할 확률이 높습니다. 문화를 바꾸려면 주변 사람을 변화시켜야 하기 때문이에요. 나 하나 변화시키기도 어려운데, 다른 사람 여럿을 한 방향으로 움직이는 건 당연히 어렵습니다. 실패도 거쳐야 할 과정이라고 생각하세요. 쉽게 포기하지 마시고, 부족했던 부분을 찾아 재정비하여 다시 도전하세요. 이 과정을 반복하다 보면 조금씩 변화하는 모습이 보일 것입니다.
변화를 받아들이는 입장에서는 적극적으로 동참해 주시기 바라요. 대부분의 변화는 좋은 의도에서 시작합니다. 긍정적인 방향으로 의도를 파악해 보시고, 부드러운 피드백을 주고받으세요. 본인이 변화에서 얻을 수 있는 이점이 무엇인지 생각하고 적극적으로 활용하시길 바랍니다.
주니어가 조직 차원의 변화를 주도하기는 어렵습니다. 그러니 현실적으로 가능성이 더 높고 장기적으로도 도움이 되는 변화에 우선순위를 두시길 추천합니다.
먼저 자신의 변화부터 주도해보세요. 본인의 개발 역량과 사회적 영향력을 꾸준히 키워보세요. 스터디나 커뮤니티, 블로그, 유튜브 등에서 활동하는 거죠. 그러다 보면 조직 내에서도 서서히 신뢰가 쌓이고 영향력이 커질 거예요. 나중에 변화를 주도할 기회가 생기거나, 누군가에게 힘을 실어줄 때 성공할 확률이 높아집니다.
영향력이 큰 분을 포섭하는 방법도 있습니다. 그분을 A라고 칭한다면 A의 공감을 이끌어내 A가 변화를 주도하게 만드는 거죠. 직접 주도할 때보다 성공 가능성이 훨씬 커집니다. 다만, A가 주도하는 순간 의도했던 방향과 100% 같아지기는 어렵습니다. 변화가 잘 정착된다면 공은 자연스럽게 변화를 주도한 A에게 돌아갈 테고요. 이런 점은 감안해야 합니다.
연차가 쌓일수록 인맥으로 이직하는 경우가 많아지는데요, 여기서 인맥은 신뢰를 뜻합니다. 친해서 데려오는 게 아니라 함께 일하고 싶어서 부르는 거죠. 실력, 마인드, 리더십 등 종합적인 이미지를 볼 것입니다. 신뢰가 있다면 스펙이 좋지 않아도 부르는 곳이 많을 거예요. 신뢰가 없다면 5년 혹은 10년 후 이직할 때 전공과목부터 복습해야 할지도 모릅니다. 코딩 인터뷰 준비도 다시 해야 하고요.
결론은 지금 진행하는 프로젝트를 소홀히 하지 말고, 함께 일하는 동료들을 진심으로 대하면 좋겠습니다.
Edit Sunny Design Lil
