구글의 소프트웨어 엔지니어링 (3/5)

3. 개발자 심리와 개발 프로세스

천재 설화

이 설화는 개발자들이 빠지게 되는 오류 중 하나라고 합니다. 이는 사람의 본성이기도 한데, 사람은 우상을 찾고 숭배하려는 본능을 가지고 있다고 합니다. 그런데 특히나 개발자들의 세계에선 이런 경우가 많다 합니다. 예를 들어 빌 게이츠, 스티브 잡스, 리누스 토발즈. 모두 한 명의 천재가 세상을 바꾸었습니다. 소프트웨어 개발을 하다보면 이런 이야기를 종종 접하다 보니 개발자들도 그렇게 되고 싶어 혼자 행동하는 경향이 강하다 합니다.

 

개발자 세상의 천재 설화는 대부분 같은 패턴입니다.

1. 멋진 새로운 개념에 빠집니다.
2. 몇 주 또는 몇 달 동안 동굴 속에 들어가 아이디어를 완벽하게 구현합니다.
3. 소프트웨어를 공개하고 전 세계를 여러분의 천재성으로 놀라게 합니다.
4. 동료들은 여러분의 천재성에 놀랍니다.
5. 소프트웨어를 사용하기 위해 사람들이 줄을 섭니다.
6. 명성과 행운은 자연스럽게 따라옵니다.

그런데 당연하게도, 이는 사실이 아닙니다. 빌 게이츠, 스티브 잡스, 리누스 토발즈 모두 혼자서 개발한 케이스는 없습니다. 모든 작업은 팀 단위 작업이었습니다! 리누스 토발즈도 리눅스를 개발하면서 맡은 부분은 '유닉스 계열 커널의 개념 증명 부분만을 만들고, 이메일 목록에 보여주는 것'이었다고 합니다.

 

이런 천재 설화에 매료된 개발자들은 오픈 소스를 개발하고 있음에도 레포지토리를 private으로 해두고 개발을 한다고 합니다. 그리고 모든게 만족스러울 만큼 완성이 되면 세상에 짜잔 하고 공개하고 싶어 한다고 합니다. 하지만 책에서는 무언가를 개발하고 있다면 지속적으로 주변 사람들에게 공유하고 피드백을 받으라 말합니다. 작업물은 자주 공유되는 것이 좋다고 하며, 코드를 숨기지 말고 주변인들에게 공유하라 합니다.

 

그리고 멍청하게도! 저 역시 같은 오류를 범했습니다. 주변 지인들에게 요즘 번역을 조금씩 해보고 있다고 말은 하긴 했지만, 진작에 원작자에게 물어봤다면 어땠을까요?

 

---

가면 증후군

단순히 개발자한테서만 일어나는 현상은 아닌데, 가면 증후군이라는 심리 현상이 있다고 합니다. 가면 증후군이란 쉽게 말해 "나는 자격이 없는데 운으로 이 자리에 올라온 것이며, 또 주변 사람들을 속여가며 이 자리에 온 것"이라고 생각하는 경우를 말합니다. 이는 성취도가 높은 사람들 사이에서 나타난다고 합니다. 그리고 구글에서 근무하고 있는 엔지니어들이나, 훌륭한 엔지니어가 확실함에도 이런 현상이 나타난다고 합니다.

 

그리고 이 증후군에 빠지게 되면 본인의 약점을 감추려든다 합니다. 모르는 게 있음에도 아는 척을 하거나, 물어보려하지 않는다고 합니다. 책에서는 모르는 것을 두려워할 게 아니라 기회라고 받아들여야 하며 도움이 필요하면 도움을 요청할 수 있어야 한다고 말합니다.

 

---

가독성 검사 프로세스

구글의 코드 리뷰는 크게 3가지 단계로 이루어진다고 합니다.

1. LGTM (Look great to me: "내가 보기에는 괜찮아 보이는데?") 리뷰.
2. 코드 소유자한테서 받는 리뷰.
3. 언어별 가독성 인증을 갖고 있는 사람한테서 받는 리뷰.

1번은 말 그대로 다른 팀원에게 코드가 괜찮은지 정도를 허가받는 리뷰라고 합니다. 2번은 구글에서 사용하는 코드 소유자 개념을 리뷰에 적용한 것입니다. 구글에서는 파일 별로 소유자를 할당하는데, 리뷰 프로세스에서 해당 코드의 소유주에게 코드가 괜찮은지 승인을 받아야 한다합니다.

 

여기서 3번이 좀 재미있습니다. 구글에선 언어별로 가독성 인증을 갖고 있는 사람들이 존재한다고 합니다. 여기서 가독성 인증이란 "이 사람은 코드를 가독성 있게 쓰는 사람입니다"하고 인증해 주는 것이랍니다. 이런 절차를 통해 전체적인 코드 베이스의 코드 품질과 일관성을 높인다고 합니다.

 

여기까지 읽는다면 문득 이런 생각이 듭니다. 'PR 한 번에 리뷰를 3번 받아야 하면 머지되는 게 너무 느릴 것 같은데?' 하지만 대부분의 리뷰는 한 사람이나 두 사람한테서 이루어진다고 합니다. 왜냐하면 LGTM 승인을 해준 있는 팀원이 코드의 소유주일 확률이 높으며, 가독성 인증도 받은 상태일 수 있기 때문입니다.

 

더불어 리뷰를 하면서 컨벤션과 같은 지적을 하지 않을 수 있도록 아예 스타일 가이드나 린트와 같은 정적 도구도 같이 사용하라 합니다. 이러는 것이 훨씬 일관성을 높이기 좋으며, 엔지니어의 시간은 소중하기 때문에 자동으로 할 수 있는 모든 업무는 자동화하라고 합니다.

 

---

Piper

한국에서는 Git 을 사용하는 게 너무나 당연하다 보니 구글에서도 깃을 쓰고 있을 것이라 생각했습니다. 하지만 자체적으로 개발한 버전 관리 도구인 Piper를 사용하고 있다고 합니다. 파이퍼는 구글의 상황에 맞는 커스터마이징한 기능들을 다양하게 제공하고 있는 것으로 보입니다.

 

애초에 구글은 대부분의 도구를 자체 개발해서 사용하고 있는 것으로 보입니다. 그리고 구글의 방대한 서비스와 조직 규모, 역사를 고려하면 기존의 상용 제품으로는 불충분한 상황이 발생할 수 있겠다는 생각이 들기도 합니다. 더불어 구글은 모노레포 방식으로 작업으로 일을 하는데, 모노 레포의 크기가 86TB(데이터 + 메타 데이터) 정도라 하니... 커스터마이징이 불확실한 상용 제품을 쓰지 않는게 납득이 갑니다.

 

---

TBD (Trunk based development)

일반적인 조직에서는 브랜치를 관리하기 위해 main/cbt/dev 브랜치를 나누고 feature/fix/refactor 같은 브랜치를 따서 작업합니다. 반면 구글에서 사용하는 브랜치 관리 전략은 TBD라는 전략을 사용합니다.

 

TBD란 브랜치 관리를 거의 하지 않고 main에서 작업을 하는 것을 의미합니다. 그리고 브랜치 관리를 해야한다면 브랜치의 수명을 반드시 짧게 가져간다 합니다. (사실 이 대목은 제가 이해도가 부족한데다 정보가 부족해서 정확히 일치하는지는 잘 모르겠습니다.) 단순 무식해보이지만 이 이면에는 많은 철학이 담겨있고, 이 방식을 이용하려면 선제 조건이 많이 붙습니다.

 

생각해 보면 브랜치를 나누고, 기능 개발이 완료된 feature 브랜치를 dev 브랜치로 머지하고, dev를 cbt 에 머지하고, cbt를 main에 머지 하는 프로세스는 시간이 지나치게 오래 걸리는 감이 없지 않아 있습니다. 경험적으로 dev 브랜치와 main 브랜치는 어쩔 때는 한두 달 가까이 싱크가 안 이루어지는 경우도 있었던 것 같습니다. 그리고 시간이 오래 지날수록 머지가 힘들어지는 것을 몸소 느꼈습니다. TBD 방식에서는 이런 긴 수명의 브랜치를 관리하지 않기 때문에 피드백이 빠르며 대규모 리팩토링이 쉬워진다고 합니다.

 

경험담인데 얼마전 이 책을 읽고 영향을 받아 회사에 스타일 가이드를 적용하려 했던 적이 있습니다. 그런데 스타일 가이드를 적용하기 조금 애매했던게,  스타일 가이드를 적용하려던 시기에는 dev 브랜치에서 작업이 길어지던 때여서, main 브랜치와 dev 브랜치 사이에 불일치가 있었습니다. (이렇게 된 배경도 있지만 생략합니다.) 아무튼 그러하다보니 스타일 가이드를 적용하려면 dev, cbt, main 각각에 따로 적용해야만 했습니다. 그리고 이 때문에 브랜치 간의 충돌이 더 심화돼서 머지를 더 힘들게 만들었습니다.  해당 문제는 여차여차 해결하긴 했지만 긴 수명의 브랜치를 가져가는 전략이 좋은 게 아니구나라는 것을 깨달았습니다. 긴 수명의 브랜치는 리팩토링을 힘들게 하며 피드백 루프도 길게 만듭니다.

 

물론 책에서 말하는 TBD 전략이 정답은 아니라고 봅니다. 다만 실현 가능한 전략이라면 분명 굉장한 메리트가 있어보였습니다. TBD 전략을 사용하기 위해선 선제조건들이 많이 필요합니다. 우선 테스트 케이스가 무수히 많아서 자동으로 호환성을 검증해 줄 수 있어야 합니다. CI/CD에 있어서도 완벽한 지원이 필요합니다. (여기서 CI/CD는 단순히 jenkins job을 구성하는 수준 이상의 의미입니다.) 구글에서는 대부분의 CI/CD 툴과 버전 관리 도구를 직접 만들어서 사용 중이기 때문에 TBD가 가능하지 않나라는 생각도 합니다.

 

좀 더 복잡한 내용들이 있지만, 자세한 내용은 이 또한 책을 읽어보라는 말과 함께 여기서 마무리합니다.