성장을 위한 열쇠를 간직하라
* <[무료 특별판] 구글 엔지니어는 이렇게 일한다>(교보, 리디)에 기고한 글입니다. 제목은 출판사에서 지어 주셨습니다.
* 내용은 [발표 영상]과 제법 겹칩니다만, 더 자세하고 더 정돈되어 있습니다.
안녕하세요? 역자 이복연입니다. 저는 학생 때부터, 그리고 스타트업과 대기업을 오가며 항상 ‘더 효과적으로 개발하는 방법’을 궁금해했습니다. 이 책에는 같은 고민에 대한 구글의 20년 치의 노력, 변화 과정, 결과가 담겨 있습니다.
이 책의 저자는 무려 26명입니다. 기여자의 수는 그 몇 배에 달합니다. 구글이 20년 이상 세계 톱 경쟁력을 유지해 온 비결은 소수의 천재들이 아니었습니다. 수많은 엔지니어가 각자의 영역에서 한 걸음씩 앞으로 내딛었고, 그 노력들이 융합되어 지금의 모습이 되었습니다. 우리도 그렇게 할 수 있습니다.
물론, 구글이 정답은 아닙니다. 하지만 구글이 왜, 어떤 과정을 거쳐 지금에 이르렀는지를 들여다보면 우리에게 필요한 다음 한 걸음을 결정하는 데 분명 커다란 도움이 될 것입니다.
저는 이 책 덕분에 수많은 기업 발표를 하게 되었습니다. 영광스러운 경험이었죠. 지금부터 그간의 발표와 피드백을 토대로, 조금은 색다르게 책의 매력을 소개해 드리겠습니다. 구성은 다음과 같습니다.
1. 시간 위를 걷는 프로그래밍
2. 개발자께서 "안 돼"라고 말씀하셨다.
3. 주인을 찾습니다!
4. 구글은 다르게 일한다.
5. 책의 구성과 키워드
6. (주니어를 위한) 소프트웨어 엔지니어링, 별거 없쥬!
1. 시간 위를 걷는 프로그래밍
‘우아한테크코스’를 총괄하시는 박재성 님은 이 책을 읽고 다음과 같이 말씀하셨습니다.
여러분도 혹시 소프트웨어 엔지니어링에 거부감을 느끼신다면, 혹은 나와는 상관없는 주제라 여기신다면, 아마도 오해에서 비롯된 생각일 것입니다. 많은 분이 소프트웨어 엔지니어링이라고 하면 프로세스 정립이나 생산성 측정 같은 ‘관리’ 측면에 치우친 주제라고 오해합니다.
하지만 소프트웨어 엔지니어링은 코드를 작성하는 행위에 더하여, 시간의 흐름에 발맞춰 한 조직이 코드를 구축하고 유지보수하는 데 관련된 모든 것을 포괄하는 현장 친화적인 개념입니다.
‘살아 있는 소프트웨어’라면 시간이 흐르면서 변화하며, 일반적으로 규모가 커지고, 이를 관리하는 조직도 성장합니다. 이 모든 것을 고려하여 아키텍처는 어떻게 설계하고, 어떻게 코딩하고, 어떻게 개발 프로세스를 가져갈지 등을 고민하고 실천하는 것… 한 마디로 ‘엔지니어답게 일하는 방법’이 바로 소프트웨어 엔지니어링인 것이죠.
2. 개발자께서 “안 돼”라고 말씀하셨다
소프트웨어 업계에는 공공연한 비밀이 하나 있습니다. 개발자에게 무언가를 요청하면 일단 “안 돼”라고 답하지만, 위에서 ‘쪼으면’ 결국 해낸다는 것입니다. 이유가 무엇일까요?
쪼을수록 개발자들은 ‘프로그래밍’에 집중하고 ‘소프트웨어 엔지니어링’에서 해야 할 일들을 소홀히 하기 때문입니다. 이때 생략되는 일들이 바로 앞서 박재성 님이 말씀하신 ‘지금까지 중요하게 여기고 강조했던 많은 활동’입니다. 대표적인 예로 설계, 테스트, 코드 리뷰, 프로세스 자동화 등을 소홀히 하고, 일단 돌아가게 만드는 데 온 힘을 쏟습니다.
3. 주인을 찾습니다!
현실에서 이런 대화는 상상하기 어렵습니다. 우리 직업을 개발자 혹은 프로그래머라고도 많이 부르지만, “소프트웨어 엔지니어시군요?”라고 물었을 때 아니라고 답하지는 않습니다.
우리는 소프트웨어 엔지니어입니다. 그렇다면 소프트웨어 엔지니어링이 무엇인지 올바르게 이해하고, 적어도 거부감은 갖지 않아야 하겠습니다. 우리가 선택한 직업이니까요. 나아가 소프트웨어 엔지니어임을 자각하고, 소프트웨어 엔지니어링을 주도해야 우리의 권익을 찾을 수 있습니다.
쳇바퀴 돌듯 어제와 똑같은 업무 방식, 쌓여만 가는 기술 부채, 데드라인에 쫓겨 단편적인 프로그래밍에서 헤어 나오지 못하는 하루하루... 프로그래밍 세계에 발을 딛으며 아무도 이런 삶을 꿈꾸지 않습니다. 우리가 소프트웨어 엔지니어링의 주인이 되어야 이런 삶에서 벗어나, ‘시간 위를 걸어’ 원하는 목적지까지 안전하게 여행할 수 있습니다.
4. 구글은 다르게 일한다
구글은 다르게 일합니다. 여느 회사와 같았다면 이 책을 읽을 필요도, 애초에 이 책이 출간될 이유도 없었겠죠. 그렇다면 과연 무엇이 다를까요? 왜 다르게 일해야 했고, 어떻게 달라질 수 있었을까요? 이 질문들이 바로 여러분이 이 책을 읽는 이유, 그리고 이 책에서 얻고자 하는 혜안일 것입니다.
4.1 무엇이 다른가?
먼저 무엇이 다른지, 대표적인 예 여섯 개를 뽑아봤습니다. 차이점 위주로 간단하게만 훑어볼 텐데, 얼핏 보기에는 상식에 맞지 않거나 실무에서 동작할 수 있을지 의문이 드는 예도 있을 것입니다.
예시 1. 코드 리뷰
코딩은 소프트웨어 엔지니어의 핵심 역량입니다. 그리고 수많은 사람이 팀을 이뤄 하나의 소프트웨어를 만들어 갑니다. 하지만 서로가 작성한 코드에 대해 이야기할 수 있는 수단은 코드 리뷰가 거의 유일합니다. 그래서 구글은 코드 리뷰를 매우 중요하게 여기며 제대로 수행하기 위해 심혈을 기울입니다. 구글식 코드 리뷰의 여러 특징 중 가장 두드러진 특징은 리뷰어 역할 구분으로 보입니다.
구글에서는 3가지 역할의 리뷰어가 승인하여야 변경된 코드를 커밋할 수 있습니다. 각 역할의 리뷰어들을 주로 다음 관점에서 코드를 검토합니다.
이렇게 하여 동료 엔지니어, 모듈 책임자, 전사 표준 지킴이의 관점에서 검토된 코드만이 리포지터리에 체크인되도록 합니다.
예시 2. 버전 관리와 브랜치 전략
버전 관리와 브랜치 전략 면에서도 구글은 일반적인 방식과는 큰 차이를 보입니다.
구글은 기본적으로 모든 프로젝트를 하나의 리포지터리에서 관리합니다. 그래서 구글의 리포지터리에는 20억 라인이 넘는 코드가 담겨 있습니다.
또한 각종 프로젝트에서 사용하는 의존성들(참조하는 다른 모듈, 서드파티 라이브러리 등) 역시 이 리포지터리에 두고, 모든 의존성의 버전을 단 하나씩만 존재하게 관리합니다. ‘A’라는 라이브러리를 사용해야 할 때 2.0.0을 써야 할지 2.0.1을 써야 할지 고민할 일 자체가 없게 만듭니다.
마지막으로 가장 독특한 특징으로, 개발 브랜치를 따지 않고 모두 헤드(메인, 트렁크)에서 개발을 진행합니다.
의존성을 포함하여 모든 프로젝트를 하나의 리포지터리에서 관리하면서 헤드에서만 개발하는 모습은 쉽게 상상이 되지 않을 것입니다. 이런 개발 방식이 어떻게 가능하고, 왜 이렇게 하고 있을까요?
예시 3. 문서자료도 코드처럼
많은 문서자료가 낡은 정보를 담고 있거나, 비슷한 정보가 여러 곳에 흩어져 있습니다. 처음 작성했을 때는 멋져 보이고 유용하지만, 시간이 지날수록 골칫거리가 되기 쉽습니다. 문서자료는 코드와 달리 동작하지 않아서 문제가 즉시 드러나지 않기 때문입니다. 그래서 구글은 문서자료도 마치 코드처럼 관리합니다.
다음은 구글이 코드를 관리하는 방식과 문서자료를 관리하는 방식입니다.
보다시피 문서자료도 마치 코드처럼 관리합니다. 심지어 스타일 가이드까지 마련되어 있습니다. 이렇게 하여 문서자료에는 항상 살아 있는 정보가 담기게 되며, 엔지니어들이 고품질의 문서자료 대부분을 작성하고 관리할 수 있습니다.
예시 4. 테스트 스위트 분류
이제는 소프트웨어 업계의 상식이 되어 버린 단위/통합/시스템 테스트 개념마저 구글에서는 주된 분류 기준이 아닙니다. 구글이 테스트 케이스를 분류하는 첫 번째 기준은 바로 테스트의 크기입니다.
10여 년 전, 동료 엔지니어분들께 효과적인 테스트 작성 노하우를 전파하고자 단위 테스트 책을 번역한 저로서는 이러한 변화가 참 감회가 새롭습니다.
예시 5. 빌드 시스템
현재 대다수의 프로젝트에서 그레이들Gradle이나 메이븐Maven을 이용하여 시스템을 빌드합니다. C/C++ 프로젝트에서는 메이크Make 계열 빌드 시스템도 여전히 많이 쓰죠. 이러한 빌드 시스템은 모두 태스크task를 정의하고 태스크 사이의 의존 관계를 설정하여 전체 빌드를 관리합니다. 그래서 이 방식의 빌드 시스템을 ‘태스크 기반 빌드 시스템’이라고 합니다.
그런데 또 다른 빌드 방식도 가능할까요? 다음 표를 보시죠.
태스크 기반 빌드 시스템에서는 결과물을 만들어내는 과정을 스크립트 언어로 명령 하나하나를 기술합니다. 그래서 프로젝트가 커지면 빌드 전담 인력을 두어야 할 만큼 스크립트를 관리하는 일이 복잡해집니다. 아티팩트 기반 빌드 시스템에서는 이런 문제가 말끔히 해결되며, 그 외에도 장점이 아주 많습니다.
예시 6. 오픈소스st + 비욘세 규칙
구글은 기본적으로 모든 프로젝트가 모든 사내 엔지니어에게 공개되어 있습니다. 코드를 오픈할 뿐 아니라 버그가 보이면 직접 패치할 수 있고, 심지어 내가 원하는 기능을 추가할 수도 있습니다. 변경 목록을 커밋하면 해당 모듈의 소유자가 리뷰하여 수용 여부를 결정합니다. 그리고 실제로도 상당 비중의 변경이 프로젝트 ‘외부’에서 촉발된다고 합니다.
오픈소스 생태계가 세상의 모든 엔지니어가 탐험할 수 있는 바라다면, 구글의 리포지터리는 수만 명의 구글 엔지니어 누구든 참여할 수 있는 거대한 호수입니다.
한편 그림 오른쪽에서 A 프로젝트의 코드를 변경하자 A에 의존하는 B 프로젝트가 오동작하기 시작했다고 해보죠. 우리 주변에서도 흔히 일어나는 상황인데, 누구의 책임인지를 놓고 팀 사이에 고성이 오가는 모습도 드물지 않게 볼 수 있습니다. 이 상황의 해법으로 구글은 ‘비욘세 규칙’을 적용합니다.
비욘세 규칙은 “너에게 중요한 기능이었다면 테스트를 준비했어야지”라고 풀어 이야기할 수 있는 규칙으로, 그 이름은 가수 비욘세의 히트곡 「싱글 레이디스」의 가사 “네가 진심으로 좋아했다면 반지를 줬어야지”에서 착안했습니다.
앞의 문제 상황에 비욘세 규칙을 적용하면 책임소지가 어떻게 결정될까요? 만약 B팀이 지속적 통합(CI) 시스템에 등록해둔 테스트들이 모두 통과된다면 문제를 해결할 책임은 전적으로 B팀이 집니다.
비욘세 규칙 덕에 모든 팀은 제대로 된 테스트를 충분히 갖춰놓게 되며, 각 팀은 CI를 믿고 자신들의 제품에 원하는 기능을 자유롭게 추가할 수 있습니다.
4.2 왜 달라야 했나?
구글이 이처럼 일반적인 상식과 다르게 일하는 이유는 간단합니다. 바로 소프트웨어 개발 생태계가 달라졌기 때문입니다.
먼저 소프트웨어의 규모와 수명이 꾸준히 증가하고 있습니다. 이에 따라서 하나의 프로젝트에 관여하는 소프트웨어 엔지니어의 수도 2차원적으로 늘고 있습니다.
배포 방식도 과거의 패키지 방식에서 라이브 서비스 형태로, 배포 대상도 PC, 스마트폰, 태블릿을 넘어 스마트워치, 자동차, 로봇 등으로 빠르게 늘어가고 있습니다. 배포 대상 중에서 PC를 제외하면 폼팩터 형태와 플랫폼 버전이 너무 다양하여 일일이 대응하기가 점점 어려워지고 있고요.
이렇게 급변하는 환경에서 기존 틀을 고집해서는 경쟁력을 유지할 수 없습니다.
4.3 어떻게 달라질 수 있었나?
구글은 흔히 엔지니어링 주도 회사로 알려져 있고, 실제로도 그렇다고 이야기할 수 있습니다. 구글은 지속 가능성을 항시 염두에 두고 소프트웨어 엔지니어들이 개발 문화를 주도했습니다.
조급하게 하향식top-down으로 바꾸려 시도하기보다는, 실무자들이 스스로 느끼고 따르도록 유도했습니다. 심리적 안전을 토대로 소통하고 함께 배우는 문화를 조성하는 데 힘을 쏟았습니다. 겸손, 존중, 신뢰 위에서 위대한 팀을 만들기 위해 노력했습니다.
5. 책의 구성과 키워드
이 책은 소프트웨어 엔지니어링을 프로그래밍, 문화, 프로세스, 도구라는 세부 영역으로 나눴습니다. 그중 프로그래밍 영역은 이미 훌륭한 책과 자료가 많기 때문에 이 책에서는 다루지 않습니다. 클린 코드, 리팩터링, 디자인 패턴 등의 주제가 프로그래밍 영역에 속합니다.
그래서 이 책의 구성은 다음과 같습니다.
1부. 전제
책의 나머지에서 이야기할 주제들에 공통된 기초를 닦기 위해 구글이 바라보는 소프트웨어 엔지니어링이 무엇인지를 자세히 설명합니다.
2부. 문화
개발 조직은 물론이고, 사실 사람들이 모여 만든 조직이라면 어디든 적용되는 이야기를 다룹니다. 그래서 저는 2부만 따로 묶어 작은 책으로 내놔도 멋질 거라 생각합니다. 여러분도 한번 읽어보시고 동의하신다면 협력 부서 분들께 권해보시기 바랍니다.
다음은 제가 생각하는 주요 키워드를 시각화한 그림입니다.
겸손, 존중, 신뢰를 바탕으로 위대한 팀을 만드는 방법, 공유하고 함께 성장하며 조직을 더 나은 방향으로 이끄는 이야기들이 펼쳐집니다.
3부. 프로세스
본격적으로 개발 조직 관련 이야기가 나옵니다. 키워드 자체는 익숙하겠지만 상당히 다르게 수행되는 모습이 흥미진진할 것입니다. 개발에 몸담고 있는 사람이라면 누구나 읽어보시길 권합니다.
다음은 구글의 개발 워크플로 중 주요 키워드를 시각화한 그림입니다.
작업 흐름을 구성하는 각 단계들은 특별할 게 없습니다. 하지만 이를 지원하는 제도가 많고 곧바로 이해되지 않는 용어도 보일 것입니다. 심지어 테스트 분류마저 단위/통합/시스템이 아니라고 합니다.
4부. 도구
구글이 사용하는 도구의 역할, 주요 기능, 이점뿐 아니라 만들어진 이유도 자세히 알려줍니다. 구글은 대부분의 도구를 직접 만들어 사용하기 때문에 아쉽게도 이 도구들을 만져볼 수는 없습니다. 그렇더라도 비슷한 기능을 제공하는 오픈소스 제품들을 함께 소개합니다. 소프트웨어 업계는 서로 활발하게 교류하며 비슷한 방향으로 발전하고 있으니, 대부분의 기능은 원한다면 어렵지 않게 손에 넣을 수 있습니다.
다음은 구글이 사용하는 도구들의 주요 키워드를 시각화한 그림입니다(붉은 글씨는 도구 이름).
역할 관점에서 보면 대부분의 개발 조직에서 사용하는 도구입니다. 하지만 모노리포, 트렁크 기반, 원-버전 규칙, 아티팩트 기반, 대규모 변경 같이 익숙하지 않은 용어도 등장합니다. 그 정체는 무엇이고 우리에게 어떤 의미가 있을까요? 지금 당장 혹은 가까운 미래에 우리에게도 필요한 개념들일까요?
6. (주니어를 위한) 소프트웨어 엔지니어링, 별거 없쥬!
주니어 입장에서는 책의 많은 내용이 아직은 피부에 와닿지 않는 거대담론처럼 느껴지실 수도 있습니다. 주니어 엔지니어가 조직의 문화, 프로세스, 도구의 변화를 이끌기란 쉽지 않은 것도 사실입니다. 그렇더라도 더 나은 엔지니어로 성장하기 위해 당장 할 수 있는 일은 아주 많습니다.
잠시 책 내용에서 조금 벗어나, 무엇부터 해야 할지 고민하시는 분들을 위해 제가 ‘더 나은 개발자를 꿈꾸며’ 걸어온 길에서 소프트웨어 엔지니어링 관점의 주요 마일스톤들을 뽑아서 따라가 보겠습니다. 학생 때부터 현업 6년 차 정도까지의 이야기입니다. 특출나지 않은 한 엔지니어의 이야기라서 더 많은 분께 공감과 용기를 드릴 수 있지 않을까 기대해 봅니다.
마일스톤 1. 첫 번째 프로그램
중1 여름방학, 제대로 된 저의 첫 프로그램이 탄생합니다. 간단한 그래픽 편집 도구였고, 아무런 고급 기술 없이 if/else를 열심히 써서 만들었습니다. 대략 다음 정도 느낌의 프로그램이었습니다(고전 게임 <울티마 6>의 화면을 참고용으로 잘라 붙였습니다).
마일스톤 2. 객체지향과 리팩터링
대학교 1학년 여름방학, C++와 자바 중 무엇을 공부할까 고민하며 관련 책들을 탐닉하는 과정에서 자연스럽게 객체지향을 접하게 되었습니다. 제가 ‘설계’라는 세계로 첫 발을 내디딘 시기이기도 합니다. 객체를 뽑아내고 역할을 부여하는 게 재미있어서 (비록 체계는 없었지만) 초보적인 리팩터링을 수없이 반복했습니다.
마일스톤 3. 디자인 패턴과 점진적 개발
저는 운 좋게 전산병으로 배정되어 군대에서도 프로그래밍을 계속할 수 있었습니다. 짬이 좀 차 여유가 생겼을 무렵, 『Applying UML and Patterns』라는 책을 아주 감명 깊게 읽었습니다. 하나의 프로젝트를 점진적으로 완성시켰는데, 이터레이션을 돌며 새로운 기능을 추가하가나 다양한 디자인 패턴을 적용하여 기존 설계를 개선했습니다. 이를 통해 GoF의 패턴과 GRASP 패턴을, 그리고 점진적 개발 프로세스를 체계적으로 익힐 수 있었습니다.
마일스톤 4. 버전 관리와 지속적 통합
제대 후 1년간 다닌 회사 덕에 버전 관리 도구를 처음 접하게 되었고, 그 후 몸담은 삼성 소프트웨어멤버십에서는 오픈소스 버전 관리 도구인 CVS를 설치해 멤버십 친구들과의 팀 프로젝트에 활용했습니다. 지금은 깃Git을 사용하는 게 너무 당연하지만, 2000년 즈음의 이야기라서 당시 대다수 대학생에게 버전 관리는 상당히 낯선 개념이었습니다.
나아가 (역시 고전 도구인) 아파치 앤트Apach Ant로 빌드 스크립트를 작성하고 리눅스 크론탭crontab으로 스케줄링하여 간단한 지속적 통합 시스템도 구축하여 개인 프로젝트들에 활용하기 시작했습니다.
마일스톤 5. 핵심은 사람이다
모듈화, 점진적 개발, 버전 관리, 자동화 등 ‘있어 보이는’ 개념들을 잔뜩 익혀 자신감이 올랐고 바로 써먹어보고 싶던 시기였습니다. 멋진 콜라보와 결과를 기대하며 프로젝트를 기획하여 친구들과 역할을 나눠 개발을 진행했습니다. 하지만 안타깝게도 기대한 만큼의 협업이 이루어진 프로젝트는 없었습니다.
물론 학생들끼리 반 취미로 시작한 프로젝트가 삐걱거리지 않으면 오히려 이상할 수도 있죠. 하지만 제가 깨달은 건 ‘내가 팀원들을 부품처럼 생각했구나’였습니다. 흥미로운 프로젝트, 멀끔한 설계, 체계적인 프로세스를 준비했으니 팀원들이 제 생각대로 움직여주리라 착각한 것이죠. ‘사람 이해하기’는 또 전혀 다른 영역입니다만, ‘핵심은 사람이다’라는 사실만이라도 본격적인 사회생활 전에 깨달아서 참으로 다행이라고 생각합니다.
마일스톤 6. IDE를 스토킹하다
IDE를 본격적으로 사용하기 시작하면서 IDE가 제공하는 기능들을 두루 살펴보고, 신버전이 릴리스되면 어떤 기능이 추가되거나 변경되었는지를 눈여겨봤습니다. 저는 특히 리팩터링 기능들에 관심이 많았습니다. 새로운 리팩터링 기능이 추가되면 어떤 경우에 적용하는지, 적용 전의 잠재적 설계 결함과 적용 후의 모습을 비교하며 공부하곤 했습니다.
IDE의 최우선 목표는 개발 생산성 개선이며 이름 그대로 ‘통합’ 개발 환경이므로, 정말 폭넓은 영역에서 개발에 도움 되는 기능들로 가득합니다. 시선을 플러그인까지 확장하면 전 세계 개발자들의 기발한 아이디어들을 엿볼 수 있습니다.
마일스톤 7. 정적 분석 도구
천하제일 IDE 플러그인 대회가 열린다면 정적 분석 도구는 단연 강력한 우승 후보입니다. 제가 정적 분석 도구를 처음 접한 계기는 정확히 기억나지 않지만, 아마도 IDE 플러그인들을 살펴보던 중 발견하지 않았을까 싶습니다. 어쨌든 언젠가부터 저는 개인 프로젝트에서 항상 Checkstyle과 Findbugs를 사용하고 있었습니다.
정적 분석 도구는 내가 어떤 프로젝트를 하든 훌륭한 짝 프로그래밍 파트너이자 코드 리뷰어가 되어 주었습니다. 마치 개인 교사를 고용한 느낌이었죠. 나의 모든 코드를 꼼꼼히 검토해주며 코딩 습관도 고쳐주고 안전하고 효율적인 코딩 스킬을 가르쳐주었습니다.
마일스톤 8. 애자일인듯, 애자일 아닌, 애자일 같은..
학부 때부터 관심이 많던 주제인 ‘더 나은 개발 프로세스’는 취업 후에도 변함이 없었습니다. 주니어 때부터 관련 논의에 적극 참여하고 따로 스터디도 종종 진행했지만, 직접 팀을 이끄는 기회는 역시 짬이 좀 찬 후에 찾아왔습니다.
몇 개월 후 열리는 국제 행사 때 전시할 데모 프로그램을 만드는 시한부 프로젝트였지만, 우리나라뿐 아니라 인도에서 근무하는 팀까지 함께 이끌며 미국 회사의 PC용 서비스를 모바일로 옮기는 작업을 하게 되었죠. 다음은 제가 이끈 팀의 대략적인 구성입니다.
시간대가 다른 세 지역에 분산된 팀을 통솔하며 코드를 매일 빌드하고, 엔진과 전체 앱의 안정 버전을 격주로 교차 릴리스했습니다. 일정 지연은 한 차례도 없었습니다. 저는 요구사항을 명확히 정의/공유하고, 엔진과 통합 앱을 릴리스 즉시 검증하고, 제기된 이슈는 모두 다음날 팀원들이 출근하면 결론이 나와 있도록 했습니다. 또한 팀원들이 자신의 전문 분야와 관련한 문제라면 직접 결정하게 했습니다. 엔지니어들이 외부 요인 때문에 블록되는 시간을 최소로 줄이려는 의도였습니다. 물론 저와 함께 일한 엔지니어들이 우수했고, 인도 팀에도 훌륭한 리더가 있었기에 가능했다고 생각합니다.
당시 저는 애자일이 무엇인지 몰랐습니다. 그저 ‘주어진 상황에 맞는 더 나은 개발 방식’을 고민하다 보니 많은 면에서 애자일과 맞닿게 된 것 같습니다. 제가 애자일을 제대로 공부한 건 이 경험 이후의 일입니다.
마일스톤 9. 분산 빌드와 대규모 지속적 통합
분산 빌드와 대규모 지속적 통합은 하나의 마일스톤으로 묶었지만, 적용 시기에는 몇 년의 차이가 있습니다.
먼저 분산 빌드는 제가 품질 보증 팀 소속으로 A 개발팀의 테스트를 지원해주던 시기의 일입니다. 약 40명 규모의 팀이었는데, 클린 빌드 한 번에 40분이 넘게 걸렸습니다. 이 상황이 너무 갑갑했던 저는 바로 적용할 수 있는 분산 빌드 도구를 찾아, 검증 후 개발팀에 소개했습니다. 이 도구 도입의 효과를 단순 계산해보면 다음과 같았습니다.
작은 도구 하나를 도입했을 뿐이지만, 보다시피 엔지니어 약 3명을 추가 고용한 효과를 얻어냈습니다.
지속적 통합 역시 같은 개발팀의 이야기입니다. 시간이 흘러 팀 덩치는 더욱 커졌고 저도 그 일원이 되었습니다. 규모가 커서 모듈별 개발 브랜치에서 작업 후 몇 달마다 통합하는 식으로 작업했는데, 이 통합이 보통 일이 아니었습니다. 며칠 지연은 당연하고, 일주일 이상 늘어지는 일도 허다했습니다. 저는 종종 지속적 통합 이야기를 꺼냈지만 받아들여지지 않았습니다.
그렇게 몇 년이 흐르고 마침 지속적 통합을 구축해본 사람이 합류하였고, 저는 다시 한번 도입을 제안했습니다. 다행히 이번에는 모든 게 잘 맞아떨어졌습니다. 전보다 문제가 심각해졌고, 그 사이 지속적 통합 도구도 많이 발전했습니다. 새로운 시스템은 매끄럽게 안착되었고, 숱한 야근과 지연을 낳던 통합이라는 개념은 우리 머릿속에서 사라졌습니다.
그래서 소프트웨어 엔지니어링이 뭐라고?
이 책에서는 소프트웨어 엔지니어링을 크게 프로그래밍, 문화, 프로세스, 도구로 분류하여 이야기합니다. 앞서의 제 마일스톤들에 이 분류를 대입하면 다음 그림과 같습니다.
저는 그저 ‘더 나은 개발자를 꿈꾸며’ 길을 걸었습니다. 특별할 것 없는 제 발자취도 보다시피 소프트웨어 엔지니어링의 모든 분야를 고루 거쳐왔습니다.
이처럼 소프트웨어 엔지니어링은 멀리 있지 않습니다. 우리가 개인 혹은 팀 역량을 높이기 위해 고민하고 실천하는 모든 것이 바로 소프트웨어 엔지니어링입니다. 주변 사람들은 어떻게 일하고 있는지 살펴보고, 당장 불편한 부분을 찾아 개선 방법을 고민해보고, 서점 베스트셀러 목록에서 흥미로운 주제의 책을 찾아 읽어보고, 출퇴근 길에 재미난 IT 유튜브나 팟캐스트를 시청하는 것도 훌륭한 엔지니어가 되는 멋진 출발입니다.
이런 식으로 개인의 역량을 키우고, 주변에 기여하고, 신뢰를 쌓으며 영향력을 키우다 보면, 어느 순간 변화를 이끌고 문화를 만들어 가는 중심에 서 있는 자신을 발견할 것입니다.
