Git Flow? Trunk based?

Git Flow와 트렁크 기반 개발은 소프트웨어 개발 팀이 코드를 작성, 병합 및 배포할 때 채택하는 대표적인 브랜치 전략입니다. 두 전략은 각각의 핵심 원칙과 목표에 따라 브랜치 관리 방식과 개발 워크플로에서 명확한 차이를 보입니다.

📌 Git Flow의 핵심 원칙과 특징

Git Flow는 정교하고 안정적인 배포를 지향하는 브랜치 전략입니다. 2010년 Vincent Driessen이 제시했으며, 안정성과 체계적인 버전 관리에 중점을 둡니다.

⏱️ 다수의 장기 유지 브랜치: Git Flow는 master와 develop이라는 두 개의 주요 브랜치를 핵심으로 하며, 이 외에 feature, release, hotfix 세 가지 보조 브랜치를 사용합니다.
- master 브랜치: 제품의 안정된 버전이 유지되는 메인 브랜치로, 배포 가능한 상태의 코드만을 반영합니다. 실제로 배포되는 코드는 이 브랜치에서 가져옵니다.
- develop 브랜치: 개발 작업이 진행되는 메인 브랜치로, 아직 릴리즈되지 않은 최신 코드가 유지됩니다. 새로운 기능 개발, 버그 수정, 리팩토링 등이 이곳에서 이루어집니다.
- feature 브랜치: 새로운 기능을 개발하기 위해 develop 브랜치에서 분기하며, 개발이 완료되면 develop 브랜치로 병합됩니다.
- release 브랜치: 다음 버전 릴리즈를 준비하기 위해 develop 브랜치에서 분기합니다. 이 브랜치에서 문제가 해결되면 develop과 master 브랜치로 병합됩니다.
- hotfix 브랜치: 운영 중인 소프트웨어의 긴급 버그 수정 등을 위해 master 브랜치에서 분기합니다. 문제가 해결되면 develop과 master 브랜치로 병합됩니다.
🚦 명확한 역할 분담: 각 브랜치가 명확한 역할과 용도를 가지므로, 브랜치 관리가 체계적이고 배포 안정성이 높습니다. release 브랜치에서의 테스트 및 QA 과정을 통해 안정성이 검증된 기능이 master로 병합되어 배포됩니다.
🐢 느린 릴리즈 주기: 복잡한 브랜치 구조와 검증/테스트 과정이 추가되어 개발 속도가 느릴 수 있으며, 빠른 배포가 필요한 프로젝트에는 적합하지 않을 수 있습니다.
🧠 복잡성과 높은 진입 장벽: 다양한 브랜치 사용으로 인해 초기 설정이 복잡하고 팀원들이 이해하고 따르기 어려울 수 있습니다. 특히 작은 규모의 프로젝트에는 지나치게 복잡한 구조일 수 있습니다.

✏️ 트렁크 기반 개발의 핵심 원칙과 특징

트렁크 기반 개발은 간단하고 빠른 배포를 추구하는 브랜치 전략입니다. trunk 또는 main이라고 불리는 단일 브랜치 위에서 개발자들이 협력하는 방식입니다. GitHub Flow는 트렁크 기반 개발의 일종으로 간주될 수 있습니다.

📍 단일 주 브랜치(main/trunk): main (또는 trunk)이라는 주 브랜치 하나만 운영하며, 모든 신규 기능 개발이나 버그 수정은 이 브랜치에 직접 커밋하거나, 며칠 내로 main에 머지할 피처 브랜치에서 작업합니다.
🔗 지속적인 배포(CD) 촉진: main 브랜치에 코드가 머지되면 자동화된 CI 시스템이 테스트 및 통합 과정을 통과하는지 확인한 후, 즉시 운영 환경에 배포됩니다. 이는 작은 단위로 개발한 기능이나 수정 사항을 빠르게 배포하는 것을 가능하게 합니다.
🔍 간단하고 직관적인 구조: master와 develop 두 개의 브랜치만 사용하거나 (GitHub Flow의 관점에서는 크게 구분되지 않음), 단일 브랜치 중심이므로 전략 이해와 사용이 쉽고 프로젝트를 빠르게 시작할 수 있습니다. release나 hotfix 브랜치도 불필요한 경우가 많아 별도로 분기하지 않는 것이 일반적입니다.
⚒️ 잦은 병합과 충돌 최소화: 며칠 단위로 main 브랜치에 변경 사항을 머지하기 때문에, 머지 시 발생하는 변경이 작아집니다. 따라서 컨플릭트가 적거나 없고, 코드 리뷰가 용이합니다. 개발자들이 각자의 작업에 독립적으로 진행하기 때문에 충돌 발생 가능성이 줄어듭니다.
❗️ 배포 위험성 존재: develop 브랜치에서 master로 바로 머지할 수 있는 방식(GitHub Flow)은 테스트와 검증 절차를 충분히 거치지 않을 수 있어 잠재적인 위험성을 포함할 수 있습니다. 따라서 테스트와 검증 과정을 강화하는 방법을 도입하는 것이 권장됩니다. 이를 해결하기 위해 작은 단위 배포, 피쳐 토글, 테스트 코드 및 통합 단계 자동화 등의 실천법이 사용될 수 있습니다.

📄 주요 차이점 요약

특징	Git Flow	트렁크 기반 개발 (Trunk-based Development)
핵심 목표	정교하고 안정적인 배포, 체계적인 버전 관리	간단하고 빠른 배포, 지속적인 통합 및 배포
주요 브랜치	`master`, `develop` 두 개의 장기 유지 브랜치	`main` (또는 `trunk`) 단일 장기 유지 브랜치
보조 브랜치	`feature`, `release`, `hotfix` 브랜치 사용. 각 브랜치별 명확한 역할과 병합 규칙.	`feature` 브랜치 사용 시 짧게 유지하고 `main`에 빠르게 머지. `release`, `hotfix` 브랜치 별도 운영 안 함.
병합 주기	브랜치가 오래 유지되는 경향이 있어 변경 사항이 많고 병합 시 충돌 발생 가능성 높음.	며칠 단위로 `main` 브랜치에 작은 변경 사항을 자주 병합하여 충돌 최소화.
배포 방식	`release` 브랜치에서 테스트 및 QA 후 `master` 브랜치로 병합하여 배포. 계획적이고 구조적인 릴리즈.	`main` 브랜치에 머지되면 자동화된 CI/CD를 통해 즉시 배포.
복잡성	복잡한 브랜치 관리 규약과 높은 진입 장벽.	간단하고 직관적인 구조로 이해와 사용이 쉽고 프로젝트 시작 용이.
적합한 환경	대형 팀이나 복잡한 프로젝트, 안정성이 매우 중요한 시스템.	작은 규모의 프로젝트, 애자일 원칙을 따르는 웹 앱 개발, 클라우드 환경에서 빠른 피드백과 배포가 중요한 경우.

결론적으로, Git Flow는 안정적인 배포와 명확한 버전 관리를 위해 다단계의 브랜치 구조와 엄격한 규칙을 사용하는 반면, 트렁크 기반 개발은 빠른 배포와 효율적인 협업을 위해 단일 메인 브랜치와 짧은 주기의 병합을 강조합니다. 프로젝트의 규모, 배포 방식, 협업 방식, 유지보수 필요성 등 여러 요소를 복합적으로 고려하여 적절한 Git 브랜치 전략을 선택하는 것이 중요합니다.

🤔 트렁크 기반 개발의 한계 (어려움)

트렁크 기반 개발 또한 모든 문제를 마법처럼 해결하지는 못하며, 다음과 같은 어려움을 맞닥뜨릴 수 있습니다:

❗️큰 기능 문제: 몇 주나 몇 달의 개발 기간이 필요한 큰 기능의 경우, 며칠마다 메인 브랜치에 머지하기 어려울 수 있습니다.
🔗 의존적인 기능 문제: 특정 기능 A가 다른 기능 B의 릴리즈에 의존하는 경우, 기능 B가 완료되기 전까지 기능 A도 배포하기 어려울 수 있습니다.
🛠️ 불안정한 기능 문제: 별도의 스테이징 서버에서 검증 없이 바로 실서버로 배포하기 때문에, 잘못된 기능이 main 브랜치로 머지될 위험이 증가할 수 있습니다. 이는 테스트와 검증 절차를 충분히 거치지 않을 수 있기 때문입니다.
🔓 대규모 프로젝트에 제한적: 작은 규모의 프로젝트나 개인 프로젝트에 적합한 전략이며, 대규모 프로젝트에서는 복잡한 작업 흐름이나 추가적인 브랜치 전략이 필요할 수 있습니다.

💡 트렁크 기반 개발의 어려움을 해결하는 방법

위에서 언급된 트렁크 기반 개발의 어려움들을 해결하기 위한 여러 방법들이 존재하며, 이 방법들은 상호 보완적으로 작용합니다.

📌 더 작은 단위의 배포: 한 달 걸릴 작업을 일주일에 한 번 배포하는 방식으로 쪼개어 배포할 수 있습니다. 이는 큰 기능 문제와 의존적인 기능 문제를 해결하고, 배포 시 변경 사항의 개수가 작아 오류 발생 확률을 줄이고 디버깅을 용이하게 하여 불안정한 기능 문제의 영향을 최소화합니다.
🎛️ 피쳐 토글 (Feature Toggle): 코드를 운영 서버에 미리 배포해두고, 해당 코드를 실제로 운영 환경에서 실행할지 여부를 원격으로, 별도의 배포 없이 결정할 수 있게 합니다. 이는 코드의 배치(deploy)와 기능의 릴리즈(release)를 분리하여, 의존적인 기능 문제와 불안정한 기능 문제를 해결하는 데 도움이 됩니다.
🧪 테스트 코드와 통합 단계에서의 테스트 자동화: 새로운 기능을 위한 테스트 코드를 작성하면 기능이 의도와 다르게 동작할 확률을 최소화하고, 기존 기능에 대한 영향을 감지하여 불안정한 기능 문제를 해결할 수 있습니다.

📌 애자일 방법론과 트렁크 기반 개발의 관계

트렁크 기반 개발은 애자일 방법론과 깊은 연관성을 가집니다. 애자일 원칙은 지속적으로 작은 변경사항을 고객에게 제공하는 것을 추구하는데, 트렁크 기반 개발의 지속적인 배포(CD) 촉진 및 작은 단위의 잦은 배포 특성이 이를 뒷받침합니다.

트렁크 기반 개발은 다음과 같은 환경에서 도입을 적극적으로 고려해볼 만합니다:

애자일 원칙을 따라 지속적으로 작은 변경사항을 고객에게 제공하고 싶을 때.

클라우드에 배포되는 웹 앱과 같이, 배포 비용이 적고 롤백이 용이할 때.
페어 프로그래밍, 코드 리뷰, 테스트 코드와 같이 코드의 품질을 끌어올리는 개발 문화에 익숙할 때.