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

기타

One-Version 규칙

One-Version 규칙이란 의존하는 라이브러리의 버전을 단일 버전 하나로 유지한다는 규칙입니다. 이 규칙은 예외를 허용하지 않습니다. 예를 들어 libA와 libB가 libBase를 사용하고 있고 시스템이 libA와 libB를 사용한다면 libBase의 버전이 다를 수 있습니다. 예를 들면 libA에서는 libBase 1.0을 사용하는데 libB에서는 libBase 2.0을 사용하고 있을 수 있습니다. 이런 경우 어떤 버전을 선택해야하는 것인지 상황이 많이 복잡해집니다. 이를 흔히들 다이아몬드 의존성 문제라고 부릅니다. 그리고 다이아몬드 의존성을 제대로 해결하는 일반적인 솔루션은 거의 존재하지 않는다고 합니다.

 

결국 이를 해결하기 위해선 버전을 하나로 관리하기 위한 엄격한 정책을 세우고 이를 따르도록 해야 합니다. 그게 One-Version 규칙입니다. 모노레포에서 관리하는 모든 라이브러리는 하나의 버전만을 갖게끔 유지하는 정책입니다. One-Version 규칙이 지켜지면 개발자 입장에서는 의존성의 버전을 고려할 필요가 없어집니다. 내 프로젝트에 libBase를 사용하고 싶을 때, 1.0을 사용해야 하는지 2.0을 사용해야 하는지 고민하지 않아도 되게 됩니다. 모노레포에서 관리 중인 libBase의 라이브러리를 가져오기만 하면 됩니다.

 

여기에 얽힌 경험담이 하나 있는데, Elasticsearch 7버전 라이브러리를 사용해서 개발을 마치고 서비스를 실행시켰을 때였습니다. 코드도 문제 없어보였고, 잘되겠지 생각하고 있었는데, 해당 코드를 실행시키면 NoSuchMethodException 을 내뱉고 있었습니다. 말 그대로 메소드를 찾을 수 없다는 에러인데, 상당히 의문스러웠습니다. IDE 상에서는 분명 메소드가 확인이 되고, 컴파일 타임에서도 문제가 없었습니다. 메소드는 분명 존재하고 잘 찾는듯 보였는데 이해가 되질 안 됐습니다. 구글링을 해도 마땅한 정보를 얻기 어려웠고요.

 

그러던 중 혹시 하는 마음에 빌드 로그를 살펴보기 시작했습니다. 그리고 이상한 로그를 하나 발견했습니다. 정의 내린 ES 라이브러리의 버전은 7버전이었는데, 메이븐에서는 6버전 라이브러리를 가져오고 있었습니다. 조사해보니 같이 사용하는 라이브러리인 Spring boot 2.1 은 ES 라이브러리 6.x 에 의존성이 걸려있었던 것을 확인했습니다. 그 결과 빌드를 마치는 과정 중에 7버전을 6버전으로 덮어쓰기 한 것이었습니다. 사용하고 있던 메소드는 6버전에서는 없었던 메소드였고, 그 결과 런타임에서는 NoSuchMethodException가 발생했던 겁니다.

 

이런 상황을 한번 겪고 나니 이 대목도 좀 크게 와닿았습니다.

 

---

unfunded mandate

재미있었던 게 이 책을 읽으면서 개발자에게 요구되는 책임 같은게 있을 때, 필요하다면 보상에 관한 내용이 항상 뒤따랐습니다. 이 점이 개인적으론 되게 좋았습니다. 보상이나 금전적인 내용을 하던 중 unfunded mandate라는 개념을 처음 접했는데, 이 또한 재미있어서 가져와봤습니다.

 

단어를 풀이하면 "보상 없이 기업이 부과하는 추가 요구 사항"을 의미합니다. 좀 더 한국스럽게 예를 들자면, 매달 첫째 주 금요일은 단합을 위해 "회사 등산"이라는 일정을 잡아뒀다 합시다. "등산화 필참"이라고 조건을 달아놓고선 등산화를 살 비용을 회사에서 주지 않는 경우를 상상해 보면 좋을 것 같습니다.

 

---

체스터슨 울타리

무언가를 제거하거나 바꾸기 전에, 먼저 그게 왜 있는지부터 이해하려 하는 것이 좋다는 이야기입니다. 주변의 팀원들에게 지식을 공유하고, 문맥을 이해할 수 있어야 한다 합니다.

리폼하는 것과는 별개로 해체 후 새로 만들 때, 분명하고 단순한 하나의 원칙이 있습니다. 아마도 역설이라고 할 수 있는 원리입니다. 간단한 예시를 들어보겠습니다. 도로를 가로질러 세워진 울타리가 있습니다. 어느 날 의욕적인 어떤 사람이 나타나 "이 울타리의 용도의 용도를 모르겠는데 치워버린죠."라고 말합니다. 하지만 좀 더 현명한 해결 방법을 원하는 사람이라면 이렇게 말할 겁니다. "이 울타리의 사용 용도를 모르신다면, 절대 반대합니다. 가서 이 울타리의 용도를 한 번 더 생각해 보시고 용도를 알아 오신다면 치우도록 하겠습니다."

https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence

 

---

마무리

 

이외에 더 이야기해 보면 좋을 만한 키워드들이 많지만 여기까지만 적으려 합니다. 더 읽어볼 만해서 찾아보시면 좋을 내용을 몇 개 더 나열해 보자면 아래와 같습니다.

 

• 비욘세 규칙
• 코드는 자산이 아니라 부채다
• actionable feedback
• 릴리스 주기는 짧은 게 더 안전하다.
• false-positive, false-negative, effective-false-positive, effective-false-negative
• 명령형 방식보다 선언적 방식을 택할 때 생기는 장점
• A/B 테스트
• 메서드 주도 테스트보다 BDD가 왜 좋은지?

 

포스팅에 작성된 개념들은 거의 파트 1, 2에 대해 나오는 내용을 다루고 있습니다. 사실 책의 후반부인 파트 3에서는 구글에서 본인들이 직접 개발한 시스템에 대한 소개를 주로 합니다. 홍보의 목적도 있겠지만, 시스템이 만들어진 배경과 원인을 잘 설명해 주고 있으니 충분히 읽어볼 만하다 생각합니다. 하지만 포스팅으로 담기에는 애매하고 내용 전달도 오히려 약해질 수 있으므로 적지 않으려 합니다.

 

전반적으로 책을 읽으면서, 업무를 통해 배운 드문드문한 지식들을 유기적으로 연결하게끔 도와준다는 느낌을 받아 좋았습니다. 내용들을 심도 있게 다루지는 않지만, 사실 소프트웨어 엔지니어링이란 무엇인가에 대한 구글의 생각을 들을 수 있었던 것만으로도 값진 책이었다 생각합니다. 포스팅은 여기서 마칩니다. 영어를 잘하시고 시간이 되신다면 읽어보실 것을 추천드립니다.