64. Git Flow (깃 플로우) 브랜치 전략

⚠️ 이 문서는 수십 명의 개발자가 하나의 소스코드를 동시에 수정할 때 소스가 엉키고 운영 서버가 망가지는 대참사를 막기 위해, 빈센트 드리센(Vincent Driessen)이 2010년에 제안한 **가장 고전적이고 체계적이며, 명확한 5개의 역할별 브랜치(Branch)를 사용해 소프트웨어 릴리스(배포) 생명주기를 통제하는 소스코드 형상 관리 모델인 'Git Flow'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 코드를 마구잡이로 섞는 대신, 영원히 유지되는 두 개의 중심 뼈대(master, develop)와 필요할 때 생겼다 사라지는 세 개의 임시 가지(feature, release, hotfix)로 역할을 엄격하게 나누어 코드의 병합을 통제하는 규칙이다.
  2. 가치: 배포를 앞두고 코드를 얼려놓고 테스트하는 기간(Release)과, 당장 운영 서버의 치명적 버그를 고치는 비상 통로(Hotfix)가 명확히 분리되어 있어 1.0, 2.0 같은 '정기적인 버전(Version) 릴리스'를 가진 엔터프라이즈 프로젝트에 극한의 안정성을 제공한다.
  3. 한계 체계: 규칙이 너무 무겁고 복잡하여, 하루에도 수십 번씩 배포가 일어나는 현대의 클라우드 네이티브 CI/CD 환경(Agile)에서는 점차 버림받고 며칠 만에 합쳐지는 가벼운 GitHub Flow나 Trunk-Based Development로 대체되는 추세다.

Ⅰ. 혼돈의 코드 병합과 5개의 방어선 (Branch)

개발자들이 각자 짠 코드를 한곳에 합치는 것은 언제나 시한폭탄을 다루는 일이다.

  1. 영구적인 중심 브랜치 (Main Branches):
    • master (또는 main): 오직 "완벽하게 검증되어 언제든 당장 상용(운영) 서버에 배포할 수 있는 상태"의 코드만 존재하는 가장 신성한 브랜치다. 버그가 있어서는 안 된다.
    • develop: 다음 버전을 위해 개발자들이 열심히 코드를 합치는 '공사판' 브랜치다. 모든 개발 작업의 중심이 된다.
  2. 임시 브랜치 (Supporting Branches):
    • feature: develop에서 가지를 뻗어 나와 '로그인 기능', '장바구니 기능' 등 새로운 기능 하나를 혼자 만들 때 쓰는 브랜치다. 완성이 되면 다시 develop으로 합쳐지고(Merge) 사라진다.
    • release: develop에 기능이 충분히 모여 "이제 1.0 버전 출시하자!" 할 때 뽑아내는 브랜치다. 이곳에서는 새로운 기능 추가는 절대 금지되며 오직 버그 픽스(QA 테스트 수정)만 한 뒤 master와 develop 양쪽으로 합치고 사라진다.
    • hotfix: 운영 서버(master)에 결제 에러 같은 치명적 버그가 터졌을 때 쓰는 구급차다. master에서 즉시 뻗어 나와 급하게 버그만 고치고 다시 master(긴급 패치)와 develop(다음 버전 반영)에 합치고 사라진다.

📢 섹션 요약 비유: master가 백화점 진열대(완성품)라면, develop은 공장 조립 라인입니다. feature는 부품을 깎는 개별 작업대이고, release는 조립된 물건을 진열대에 올리기 전 마지막으로 닦고 검사하는 검수실이며, hotfix는 진열된 물건에 하자가 발견됐을 때 셔터를 내리고 급하게 고치는 매장 내 비상 수리팀입니다.

Ⅱ. Git Flow의 강력한 안정성과 활용처

이 무거운 규칙은 왜 10년이 넘도록 사랑받았을까?

  1. 버전 기반 릴리스 (Versioned Release)에 최적화:
    • iOS나 안드로이드 앱 스토어에 심사를 거쳐 'v1.2.0' 형태로 한 달에 한 번 배포하는 모바일 앱 프로젝트나, 패키지 형태로 고객사에 CD를 구워 납품하는 B2B 솔루션 개발에 완벽하게 들어맞는다.
    • release 브랜치가 독립되어 있기 때문에, QA팀이 1.0 버전을 한참 테스트하고 있는 와중에도 개발팀은 눈치 보지 않고 develop 브랜치에서 2.0 버전을 위한 새 기능을 계속 개발할 수 있는 '동시 진행'이 가장 큰 장점이다.
  2. 안전장치 (Safety Net):
    • 절대로 덜 익은 코드(feature)가 운영 서버(master)로 다이렉트로 침범할 수 없도록 물리적/논리적인 격벽이 여러 겹 쳐져 있어 보수적인 금융, 공공 프로젝트에서 선호된다.

📢 섹션 요약 비유: 1년에 두 번, 봄/가을 컬렉션을 정기적으로 크게 발표하는 대형 패션 브랜드(앱 배포)의 업무 방식과 같습니다. 봄옷(1.0 release)을 마네킹에 입혀보고 최종 핏을 수정하는 와중에도, 디자이너들은 방해받지 않고 작업실(develop)에서 가을옷(2.0) 스케치를 계속할 수 있게 해주는 철저한 파이프라인입니다.

Ⅲ. Git Flow의 쇠퇴와 현대 CI/CD의 충돌

규칙이 너무 무거우면 속도가 생명인 현대전에서 도태된다.

  1. 병합 지옥 (Merge Hell):
    • Git Flow는 feature 브랜치에서 코드를 혼자 너무 오래 들고 있는 것을 방치한다. 한 달 만에 개발을 끝내고 develop에 합치려고(Merge) 하면, 다른 사람이 고쳐놓은 코드 수백 줄과 쾅 부딪혀 충돌(Conflict)을 해결하느라 며칠을 허비한다.
  2. 지속적 배포(CI/CD)와의 불협화음:
    • 하루에도 10번씩 넷플릭스처럼 웹사이트를 업데이트하는 애자일(Agile) 스타트업 환경에서는, release 브랜치를 파고 QA를 하는 긴 호흡의 Git Flow는 속도에 거대한 족쇄가 된다.
  3. 대안 트렌드: Trunk-Based Development (TBD):
    • 구글이나 메타 같은 현대 빅테크들은 복잡한 브랜치를 다 없애고 오직 뼈대(Trunk/Main) 하나만 둔다.
    • 개발자들이 자기 컴퓨터에서 짠 코드를 하루에 무조건 최소 한 번 이상 뼈대에 강제로 합치게(Push) 만들어 병합 충돌을 원천 차단하고, 막강한 자동화 테스트(CI)로 버그를 잡아내는 초고속 경량화 전략(GitHub Flow, TBD)으로 빠르게 넘어가고 있다.

📢 섹션 요약 비유: 정해진 날짜에만 거대한 댐의 수문을 열어 물을 방류하는 방식(Git Flow)은 안전하긴 하지만 수압(병합 충돌)이 너무 강합니다. 현대의 방식(TBD)은 수문을 아예 없애고 매일매일 졸졸졸 시냇물처럼 끊임없이 코드를 흘려보내어 물이 고일 틈을 아예 주지 않는 초고속 자동화 폭포수 시스템입니다.