우리는 조직 내에서 의사소통 비용이 많은 비중을 차지 하는 지 이미 알고 있다.1 그래서 문서 작성 및 공유, 데일리 스크럼 등의 다양한 방법을 통해 소통과 합의 문제를 해결하려고 노력해 왔다. 소프트웨어 개발 및 운영도 사람이 하는 일이다보니 같은 문제를 겪고있다. 어떤 기능을 개발하고 있는 지, 어떤 방식으로 동작하는 지, 진행상황이 어떤 지 파악하기 위해서 수 많은 회의를 하고 보고서를 작성한다. 규모가 더 커지면, 이러한 소통의 복잡도는 더 높아진다. 이러한 문제를 해결하기 위한 아주 직관적인 방법이 있는데, 감독관이 검토하고 승인하는 절차를 만들고 지키도록 강제하는 것이다.2
소프트웨어 개발과 관리의 효율성과 품질을 높이기 위해서는 소통의 문제는 반드시 풀어야 한다. 그러나 모두가 힘들면서 속도도 느린 방법은 최후의 수단으로 남겨두고, 더 나은 방법을 찾아 볼 필요가 있다. 먼저 1/ 신뢰와 규약을 바탕으로 연합하여 시간을 절약하는 것3, 그리고 2/ 조직 구성원이 같은 맥락을 공유하고 있도록 도구와 문화를 갖추는 것이 필요하다고 생각한다. 1번은 인터페이스, 라이브러리와 같은 방식으로 해결하고 있으며 이미 이야기한 적이 있으므로 이번에는 2번 내용을 다루려고 한다.
이전에 버전 관리가 필요한 이유4와 분산 버전 관리 시스템(DVCS)에 대한 소개5, 그리고 전 세계의 수 많은 사람들이 효율적으로 소프트웨어 버전을 관리하는 방법6에 대해 이야기 했었고, 버전 관리는 소프트웨어 개발 수명 주기(SDLC: Software Development Lifecycle)에서 품질 관리를 위한 필수 요소7라고 설명했다. 버전 관리를 통해 의사 소통 비용을 줄이고, 구성원이 같은 맥락을 공유할 수 있는 것은 맞지만, 아쉽게도 버전 관리를 '잘'하는 것은 다른 문제 였다.
2012년 지속적 전달(CD: Continuous Delivery) 워크샵8에서 폭탄 병합(Bomb Merge)이라는 말을 들었다. 버전 관리를 위해 브랜치(Branch)를 관리하는 여러 방법을 소개하던 중, 시행 착오를 겪은 부분을 설명하면서 폭탄 병합이라는 용어를 사용했다. 브랜치를 바라보는 관점에 따라 버전 관리가 어렵게 된 상황을 설명한 농담같은 단어였다. 버전 관리를 위한 기준 브랜치9를 안전하게 지키려는 전략을 쓰다보면, 개발을 위한 임시/개인 브랜치에서 기준 브랜치로 변경 사항을 반영하는 간격이 길어진다. 이러한 현상은 스프린트(Sprint)와 같은 애자일(Agile) 방법을 사용하지 않을 때 더욱 더 잘 드러난다. 월간으로 베포를 진행하면서, 배포를 위한 기준 브랜치를 엄격하게 관리한다면 수 많은 개발자들을 자신들의 개발 내용을 개인 브랜치에만 담아두다가 갑작스럽게 병합 요청을 보내는 것이다. 마치 폭탄을 투하하듯 방대한 양의 변경 사항을 반영해 달라고 요청한다면, 다른 조직 구성원들은 당황할 수밖에 없으며, 현실적으로 모든 변경 사항을 꼼꼼하게 살펴 볼 수 없다.
버전 관리를 위한 브랜치 전략으로 크게 2가지가 있다. 하나는 피처 브랜치(Feature branch)가 있고, 다른 하나는 트렁크 기반 브랜치(Trunk-based branch)가 있다. 피처 브랜치는 기준 브랜치에서 개별 브랜치를 생성하고 개발이 완료될 때까지 분리/격리된 채로 개발하다가 기준 브랜치에 적용하는 방법이며, 트렁크 기반 브랜치는 개발자들이 작은 브랜치를 생성한 다음 최소 하루에 한 번 기준 브랜치에 반영하는 방식이다. 트렁크 기반 브랜치의 장점은 작은 컨테이너로 큰 시스템을 구성하는 클라우드 네이티브(Cloud-Native)10에서도 소개했다. 트렁크 기반 브랜치는 기준 브랜치에 항상 최신의 정보가 있다고 생각한다. 조직 구성원은 어떤 정보가 최신이고 어떤 내용을 운영 환경에 배포했는 지 물어볼 필요가 없다. 배포는 특정 브랜치 또는 태그 기반으로 진행하고, 해당 내용은 배포 후 폐기하기 때문에 명확한 기준으로 현황과 흐름을 파악할 수 있기 때문이다.
만약 배포에 문제가 생겨서 긴급하게 조치해야 할 경우(Hot Fix) 배포 브랜치와 기준 브랜치에 반영하면 된다. 물론 이러한 조치들은 최소화 해야 하며, 모든 변경 사항은 트렁크인 기준 브랜치 기준으로 논의해야 한다. 이런 정책을 활용하면 기준 브랜치에 불완전한 내용이 반영될 수 있다는 불안감이 있을 수 있다. 하지만 이 부분은 지속적 전달/지속적 통합의 자동화된 테스트를 통해서 해결하는 것이 생산적이다. 기본 브랜치에 변경 사항이 반영될 때마다 자동으로 테스트를 수행해서 항상 시스템이 잘 작동하도록 만들어야 한다.11 12
이와 달리 피처 브랜치는 개발자들이 변경사항을 오래 유지하도록 만든다. 동시에 여러 사람이 개발하면서 각자의 브랜치를 생성 하다보면 기본 브랜치와 변경사항 대한 차이가 발생하는데 이 부분을 지속적으로 맞춰줘야 하는 문제가 있다. 이러한 문제를 해결하기 위해 1/ develop과 같은 중간 단계의 브랜치를 만들어서 필요한 부분만 기본 브랜치로 옮기는 전략을 활용하기도 하고, 2/ 까다로운 절차를 도입하거나, 3/ 코드 잠금(Code lock 또는 Code freeze)와 방법을 활용하기도 한다. 이러한 전략에는 기본 브랜치를 보호하려는 보수적인 성향이 있기 때문에, 개발자 개인의 브랜치 유지 기간이 길어지게 되고, 더욱더 폭탄 병합이 발생할 가능성을 높이게 된다.
민첩하게 시장 변화에 대응하기 위하여 회의를 통해 다양한 의견을 수렴하지만, 우선순위에 따라 의사결정을 하고 빠르게 수행하는 것처럼, 1/ 코드 리뷰를 통해 의견을 수렴하고 2/ 자동화된 테스트를 통해 안정성을 보장하면서 3/ 브랜치 및 태그 전략을 통해 합의한 결정 사항을 효과적으로 실행하는 것은 소프트웨에 수명 주기에서 중요하게 봐야할 전략이다. 소프트웨어 제품을 시장에 출시하는 과정에서 시간과 비용을 최적화하면서도 실수를 줄여 품질과 운영 우수성을 높일 수 있는 가장 기본적인 트렁크 기반 브랜치 전략을 고려해 볼 필요가 있다.
- Amazon에서는 의사소통에 드는 비용을 줄이면서 자율적으로 혁신을 시도할 수 있는 문화를 만들기 위해 리더십 원칙(Leadership Principle)을 만들었다. 이와 비슷한 맥락으로 Core Value를 정의한 곳도 있다. [본문으로]
- 직관적인 방법이기 때문에 이런 접근법을 채택하는 곳이 많다. 그러다보니 코드리뷰를 숙제 검사로 인식하는 경우를 흔하게 볼 수 있었다. [본문으로]
- Encapsulation [본문으로]
- Version Control System [본문으로]
- Git [본문으로]
- GitHub Workflow [본문으로]
- 기본적이면서도 매우 중요한 요소이다. 운항에서 나침반도 중요하지만, 상황에 따라 적절한 판단을 하고 일사분란하게 이동하는 것이 중요한 이유와 같다. [본문으로]
- Serendipity [본문으로]
- Master로 부르는 경우가 많았지만, 노예제도를 연상하게 만드는 단어이기 때문에, 언어의 순화를 위해서 Mainstream, Main으로 부르고 있다. [본문으로]
- Cloud-Native [본문으로]
- Continuous Delivery [본문으로]
- Continuous Integration [본문으로]
'Sorry Architecture' 카테고리의 다른 글
| Unknown Artist (0) | 2024.10.08 |
|---|---|
| Cell-based Architecture (0) | 2024.09.29 |
| Static Stability (0) | 2024.02.23 |
| Serendipity (0) | 2024.01.02 |
| Innovation Costs (0) | 2023.12.15 |
