브랜치 추상화에 대해 알아보자

브랜치 추상화란

어플리케이션의 큰 변화를 만들 때 주 흐름(Mainline)에 점진적으로 반영하는 패턴이다. 즉, 특정 라이브러리 혹은 오픈소스의 이름이 아니라, 작업 방식에 대한 방법론이다.

 

추상화된 브랜치 작업의 핵심은 예전에 하던 소스 추가 습관을 못하게 하는 훈련에 있다. 구체적인 방법은 다양한데, 가장 대표적인 방법은 특정 기술의 코드가 추가되면 빌드를 실패하게 하는 것이다.

 

일반적인 브렌치 추상화 작업 단계

1. 변경이 필요한 시스템 부분에 추상 레이어를 생성한다.
2. 시스템의 다른 부분을 이 추상 레이어를 쓰도록 리팩토링 한다.
3. 새로운 클래스를 생성하고, 새로운 구현을 한다. 그리고 그 추상 레이어가 이전에 혹은 새로 생긴 클래스를 필요에 따라 위임하도록 한다.
4. 이전 버전 구현 내용을 삭제한다.
5. 앞의 두 스텝을 반복하며 필요한 때 완성된 시스템을 전달한다.
6. 새로운 구현 내용이 온전히 이전 버전을 대체하면 추상 레이어를 삭제할 수도 있다.

 

 

추상화된 브랜치와 버젼컨트롤 상에서의 브랜치 비교

추상화된 브랜치는 어쩌면 잘못된 이름이다. 왜냐하면 추상화된 브랜치는 대규모 변경이 시스템에 일어날 때 버젼 컨트롤 시스템에 브랜치를 사용하는 것에 대안을 나타내기 때문이다.

 

깃 플로우의 경우, 기능추가 및 핫 픽스 혹은 릴리스 등 용도에 따라, 브렌치를 따로 만들고 해당 브렌치의 성격에 맞는 작업을 수행하고, 병합을 한다. 하지만 이 과정은 사실 너무 번거롭고, 만들어진 브렌치가 병합되지 않은 상태로 오랫동안 방치되면, 나중에는 지하철 노선도 처럼 복잡해진 깃 트리를 볼 수 있을 것이며... 이걸 정리해서 병합하려고 하는 것 도 매우 버거워 질것이다. 왜 기능 브렌치가 나쁜지에 대해선 마틴 플로우씨가 정말 잘 정리해주셨는데, 해당 링크를 공유하자면 다음과 같다.

http://martinfowler.com/bliki/FeatureBranch.html

bliki: FeatureBranch

기능 토글과의 관계

추상화된 브랜치의 의미와 용도를 보면, 기능 토글(혹은 feature flag)과 혼동될 수 있다. 왜냐면, 두가지 작업 패턴 모두 주요 흐름에 시스템의 변경을 점진적으로 수행할 수 있도록 하는 것이라는 같은 목표를 가지고 있기 때문이다. 차이점이라면...

기능 토글의 경우 새로운 기능 개발을 위한 방식으로 시스템이 동작하는 동안에 사용자가 이 새 기능을 확인할 수 없게 한다.이고,

추상화된 브랜치는 큰 변경에 대해 점진적으로 애플리케이션을 변경하는 개발 테크닉이라는 점이다.

추상화된 브랜치는 기능 토글과 같이 쓰는 것 역시 가능하다.

 

근데, 이건 그냥 잘 설계된 객체지향 코드랑 다를게 없지않나?

그렇다고 볼 수 있겠다. 특히 SOLID 원칙을 제대로 따르고 DI를 효과적으로 활용하고 ISP 원칙에 충실한 코드는 특히나 이 패턴을 적용하기가 더 쉬워진다.