주간 배포: 트렁크 기반 개발과 GitFlow 비교

잘못된 브랜칭 모델 때문에 주간 배포가 엉망이 되는 이유

주간 배포는 간단해 보이지만 어느 한 주를 놓치면 모든 것이 뒤엉킵니다. 목요일에 빌드가 "거의 준비됨" 상태였는데 금요일 늦게 QA가 문제를 찾고, 월요일은 깨끗한 시작이 아니라 정리 작업으로 바뀝니다.

주된 원인 중 하나는 브랜칭 모델입니다. 이 모델은 변경사항이 언제 만나는지, 통합이 어디서 일어나는지, 무언가 깨졌을 때 얼마나 빨리 회복할 수 있는지를 결정합니다. 통합을 주말의 끝으로 미루면 병합 충돌, 예기치 않은 버그, 불안정한 테스트 환경을 대가로 치르게 됩니다.

워크플로가 당신에게 불리하게 작동할 때 보통 이런 느낌이 듭니다:

• 병합에 드는 시간이 기능 작업 자체보다 더 오래 걸립니다.
• 브랜치가 달라지면서 QA가 잘못된 변경 조합을 테스트합니다.
• 릴리스가 일상적인 과정이 아니라 협상이 됩니다.
• 핫픽스가 발생하면 무엇이 함께 배포될지 아무도 확신하지 못해 패닉이 옵니다.
• 사람들은 QA를 신뢰하지 못하고 예외를 요청하기 시작합니다.

브랜칭은 QA 안정성도 좌우합니다. QA가 반쯤 통합된 코드 경로 사이를 계속 오가면 그것은 움직이는 목표가 됩니다. 시스템이 몇 시간마다 바뀌거나 늦은 병합이 어제 테스트한 것을 조용히 대체하면 강한 테스터도 명확한 답을 주기 어렵습니다.

그래서 팀들은 주간 릴리스 리듬으로 갈 때 트렁크 기반 개발과 GitFlow를 비교하게 됩니다. 유용한 질문은 어느 것이 더 인기있는가가 아니라, 어느 모델이 병합 고통을 줄이고 릴리스를 예측 가능하게 하며 핫픽스를 빠르고 안전하게 만들고 QA의 의미를 유지시키느냐입니다.

작은~중간 크기 팀, 하나의 공유 리포지토리, 푸시마다 CI가 돌고 있다고 가정해보세요. 웹 앱과 API를 배포하거나 일부 팀은 AppMaster 같은 플랫폼에서 시각적으로 빌드하면서도 생성된 코드와 배포를 다른 제품 팀처럼 관리할 수 있습니다.

현재 프로세스가 주말의 큰 병합을 만들어낸다면 주간 캔던스는 계속 미뤄질 것입니다. 반대로 작은 빈번한 통합을 장려하면 주간 릴리스는 지루할 정도로 안정적으로 느껴질 수 있습니다(좋은 의미로).

트렁크 기반 개발과 GitFlow를 쉬운 말로

두 접근법 모두 작업을 "진행 중"에서 "릴리스됨"으로 혼란 없이 옮기기 위한 브랜치 사용 규칙일 뿐입니다. 실제 차이는 얼마나 많은 장기 브랜치를 유지하는지, 그리고 작업이 다른 사람의 코드와 만나기 전에 얼마나 오래 분리되어 있는지입니다.

• 트렁크 기반은 거의 모든 것을 main에 가깝게 유지합니다.
• GitFlow는 진행 중인 작업과 릴리스 안정화를 위해 별도의 레인을 유지합니다.

트렁크 기반 개발(쉬운 설명)

트렁크 기반 개발은 main(트렁크)을 중심으로 다룹니다. 사람들은 단기간(몇 시간에서 하루 이틀)의 브랜치에서 작업하고 자주 병합하며 main을 릴리스 가능한 상태로 유지합니다.

무언가 준비되지 않았다면, 작업을 빠르게 끝낼 수 있을 만큼 작게 유지하거나 기능 플래그 뒤에 숨겨 사용자에게 보이지 않게 안전하게 배포할 수 있습니다.

GitFlow(쉬운 설명)

GitFlow는 보통 기능 작업이 먼저 쌓이는 장기 develop 브랜치와 develop에서 분기된 기능 브랜치를 사용합니다. 릴리스 시점에는 release/* 브랜치를 잘라 안정화하고 테스트합니다. 프로덕션이 깨지면 main에서 분기한 hotfix/* 브랜치를 잘라 수정하고 다시 병합합니다.

이 모델은 분리를 최적화합니다: 릴리스 브랜치가 테스트되고 패치되는 동안 develop에서는 진행 중인 작업을 계속할 수 있습니다.

많은 고통은 다음 같은 오해에서 옵니다:

• 트렁크 기반을 "브랜치 없음"으로 착각하는 것(사실 브랜치는 사용되지만 수명이 짧습니다).
• GitFlow를 사용하면서 실제 릴리스 브랜치를 만들지 않아 develop이 불안정한 스테이징 구역이 되는 것.
• 기능 브랜치를 몇 주 동안 방치해 어떤 모델이든 병합 문제가 되는 것.
• "릴리스 가능"을 "모든 것이 끝남"으로 착각하는 것 대신 "배포해도 안전함"으로 이해하지 못하는 것.

병합 마찰: 실제 원인

병합 충돌은 보통 두 가지에서 옵니다: 브랜치가 너무 오래 지속되는 경우, 그리고 여러 사람이 같은 영역을 조정 없이 변경하는 경우입니다.

트렁크 기반과 GitFlow의 가장 큰 실질적 차이는 작업이 다른 작업과 만나기 전에 얼마나 오래 떨어져 있는가입니다.

트렁크 기반에서는 변경이 자주 메인 라인을 통과합니다. 풀 리퀘스트가 작고, diff가 작고, 충돌은 맥락이 아직 생생할 때 나타납니다. 충돌은 발생하지만 보통 몇 줄을 조정하는 수준이라 해결이 쉽습니다. 단점은 규율입니다: 빌드를 녹색으로 유지하고, 변경을 점진적으로 적용하며 main을 제품처럼 대해야 합니다.

GitFlow에서는 기능 작업이 일상적으로 다른 개발자에게 영향을 주지 않고 더 오래 머무를 수 있습니다. 비용은 나중에 더 큰 병합 이벤트로 나타납니다: 기능→develop, develop→release/*, release/*→main. 각 병합은 더 많은 변경의 충돌 소집이 되어 충돌이 더 많고 풀기 어렵습니다. 주간 배포에서는 이런 큰 병합이 테스트를 하려는 바로 그 시점에 발생하기 쉽습니다.

코드 리뷰 부담도 바뀝니다. 트렁크 기반은 보통 리뷰가 더 자주 오지만 각각은 이해하기가 빠릅니다. GitFlow는 더 적고 무거운 리뷰가 오며, 릴리스 병합 시 피곤한 상태에서 추가 검토 시간이 필요합니다.

어느 모델에서든 병합 마찰을 줄이려면:

• PR을 작고 집중적으로 유지하세요(한 번에 하나의 목표).
• 마이그레이션, 공유 설정, 핵심 UI 같은 위험 영역의 소유권을 합의하세요.
• 상류 변경을 매일 당겨 드리프트를 줄이세요.
• 특정 파일이 계속 "핫"하다면 병렬로 경쟁하지 말고 페어로 작업하세요.

충돌이 지속되면 보통 통합을 너무 늦게 하고 있다는 신호입니다. Git 자체가 문제인 경우는 드뭅니다.

주간 캔던스를 위한 릴리스 예측 가능성

예측 가능성은 세 가지를 의미합니다: 릴리스가 언제 나가는지 알고, 무엇이 포함되는지 알고, 배포 전에 어떤 검사가 통과되어야 하는지 아는 것입니다. 팀은 보통 범위 결정을 막 섞거나 막판 수정을 하면서 주간 릴리스를 놓칩니다.

트렁크 기반에서는 main이 녹색으로 유지되면 주간 릴리스가 예측 가능해집니다. 작은 변경을 자주 병합하고 기능 플래그로 범위를 통제하면 기능이 완성되지 않아도 릴리스는 진행됩니다. 코드는 들어오지만 사용자에게 보이는 동작은 준비될 때까지 꺼져 있습니다.

품질 게이트는 한 곳에서 검증하기 쉬운 경우가 많습니다:

• main에서 자동화 테스트가 통과해야 합니다.
• QA는 매번 마지막에 올라온 것이 아니라 안정된 후보 빌드를 테스트합니다.
• 롤아웃과 롤백 절차가 문서화되어 있습니다.
• (커밋은 계속 들어와도) 명확한 릴리스 컷오프 시간이 있습니다.

GitFlow에서는 릴리스 브랜치가 일종의 고정 구역 역할을 하므로 예측 가능성을 제공합니다. 컷오프를 정하고 release/*를 만들어 배포에 필요한 변경만 허용합니다. 다만 수정은 보통 여러 곳에 적용해야 하므로 조정이 필요합니다(예: develop에도 병합).

미완성 작업 처리 방식:

• 트렁크 기반: 안전한 부분을 병합하고 나머지는 플래그 뒤에 둡니다.
• GitFlow: 미완성 작업은 develop에 남겨두고 릴리스 브랜치에는 포함하지 않습니다.

예: 체크아웃 개선이 수요일까지 절반만 완료되었다면 트렁크 기반은 안전한 리팩터는 병합하고 새 UI는 숨겨둘 수 있습니다. GitFlow는 보통 그것을 develop에 남겨두고 이번 주에는 배포하지 않으며 다음 주에 완성합니다.

핫픽스 흐름: 프로덕션으로 가는 가장 빠르고 안전한 경로

핫픽스는 일반 작업이 아닙니다. 속도와 낮은 위험, 그리고 팀이 같은 버그를 두 번 고치지 않도록 하는 경로가 필요합니다.

먼저 한 가지 질문을 하세요: 지금 프로덕션에서 정확히 어떤 코드가 실행되고 있나? 초단위로 답할 수 없다면 핫픽스는 추측성이 됩니다.

트렁크 기반에서의 핫픽스

트렁크 기반의 핫픽스는 main을 진실의 출처로 다루기 때문에 더 단순하게 느껴질 수 있습니다.

일반적인 흐름:

• 프로덕션 커밋(보통 main)에서 짧은 수명의 브랜치를 만듭니다.
• 가능한 한 작은 수정만 합니다(가능하면 테스트 추가).
• 빠르게 main에 병합합니다.
• main에서 배포하고 릴리스 태그를 찍습니다.

팀이 자주 main에 통합하기 때문에 핫픽스는 자연스럽게 다음 주간 릴리스에 포함됩니다. 주요 위험은 main을 릴리스 가능한 상태로 유지하지 못하고 반쯤 끝난 작업이 섞이는 것입니다. 기능 플래그가 도움이 되지만 기본적으로 꺼져 있는지 확인하고 핫픽스를 검증할 때 관련 없는 기능이 켜지지 않도록 하세요.

GitFlow에서의 핫픽스

GitFlow에서는 핫픽스가 보통 main(프로덕션)에서 시작해서 develop으로 다시 병합해야 합니다.

안전한 흐름:

• 프로덕션 태그에서 hotfix/*를 브랜치합니다.
• 수정하고 릴리스합니다(핫픽스 브랜치에서 또는 main에 병합한 후).
• 핫픽스를 main과 develop에 병합합니다.
• release/*가 존재하면 그 브랜치에도 병합합니다.

가장 흔한 실패는 이 병합 중 하나를 잊어버리는 것입니다. 일주일 후 develop에 패치가 없어서 버그가 "다시" 나타납니다.

간단한 규칙: 핫픽스는 향후 릴리스할 모든 장기 브랜치에 병합될 때까지 완료된 것이 아닙니다.

QA 환경을 안정적으로 유지하는 방법(팀을 막지 않으면서)

주간 배포는 "QA가 지금 배포된 것"이라는 의미가 되면 망가집니다. 환경에 이름을 붙이고 각 환경의 역할을 명확히 하세요: dev는 빠른 피드백, QA는 팀 테스트, staging은 릴리스 점검, prod는 고객용. 환경의 목적을 한 문장으로 설명할 수 없다면 사람들이 잘못 사용합니다.

이동하는 목표를 막는 규칙들

안정적인 QA는 브랜칭 모델보다 무엇을 배포하느냐에 더 달려 있습니다.

트렁크 기반이라면 QA에 무작위 커밋을 배포하지 마세요. 항상 동일한 검사를 통과한 고정된 후보(태그된 빌드, 빌드 번호, 또는 짧은 수명의 릴리스 후보 브랜치)를 배포하세요. 개발이 main에서 계속되더라도 QA는 고정된 대상물을 테스트합니다.

GitFlow에서는 QA가 보통 릴리스 브랜치를 따라갑니다. 함정은 QA가 시작된 후에도 릴리스 브랜치가 계속 변경되는 것입니다. QA가 시작되면 릴리스 브랜치를 계약처럼 다루세요: 승인된 수정만 받아들이고 명확한 절차로만 적용하세요.

예측 가능성을 유지하는 간단한 규칙:

• QA에는 통과한 빌드만 배포합니다.
• 배포된 버전을 고정(pin)하고(태그, 빌드 번호, 또는 릴리스 브랜치 헤드) 이를 공지합니다.
• QA 변경은 버그 수정으로 제한하고 새로운 기능은 포함하지 않습니다.
• 테스트 데이터를 정기적으로 초기화하고 무엇이 초기화되는지 문서화합니다.
• 설정을 코드로 유지해 환경 드리프트를 줄입니다.

팀이 AppMaster를 일부 빌드에 사용한다면 같은 원칙을 적용하세요: QA에는 재생성된 특정 빌드를 배포하고, 무작위로 변경되는 편집 집합을 배포하지 마세요.

여러 팀이 QA를 공유할 때

하나의 공유 QA 환경은 두 팀이 서로 다른 버전을 필요로 할 때 병목이 됩니다. 별도의 QA 환경을 둘 여력이 없다면 가벼운 예약 규칙을 추가하세요: 일정 시간 동안 한 팀이 QA를 소유하고 다른 팀은 dev나 staging을 사용합니다. 기능 플래그도 도움이 되어 미완성 작업을 배포해도 테스터에게는 보이지 않게 할 수 있습니다.

예: 팀 A가 주간 릴리스 후보 빌드 1842를 검증 중이면 QA는 서명 전까지 빌드 1842에 고정됩니다. 팀 B는 수정 작업을 계속 병합할 수 있지만 그 변경은 다음 후보까지 기다립니다.

단계별: 팀이 매주 따라할 수 있는 워크플로 선택하기

"주간 배포"가 당신에게 무엇을 의미하는지 적어보세요. 릴리스 요일과 시간, 허용 가능한 위험 수준(예: "P1 버그 없음"), 팀 규모와 시간대 등을 정하세요. 그러면 브랜치 논쟁이 우선순위 논쟁으로 비화하는 것을 막을 수 있습니다.

하나의 기본 모델을 선택하고 한 달 동안 고수하세요. 바로 섞어 쓰지 마세요. 초기에 모델을 섞으면 규칙만 늘어나고 놀라움은 줄지 않습니다.

적용 가능한 간단한 주간 워크플로:

• 브랜치 수명을 짧게 유지(몇 시간~1-2일)하고 적어도 매일 병합하세요.
• 안전 장치 추가: 빠른 CI, 짧은 필수 리뷰, 실제로 깨짐을 잡아내는 소수의 자동화 테스트.
• 범위 통제 방법 결정: 기능 플래그, 주말 끝에 짧은 수명의 릴리스 브랜치, 또는 정확한 릴리스 커밋을 위한 태그.
• 핫픽스 단계를 정의: 누가 트리거할 수 있는지, 어떤 체크가 필요한지, 수정이 메인 라인으로 되돌아가는 방법.
• QA를 안정화: QA가 무엇을 추적하는지(릴리스 브랜치 또는 고정 후보)를 결정하고 테스트 중간에 변경하지 마세요.

최소한의 워크플로를 한 페이지에 적으세요. 새 팀원이 회의 없이도 따라할 수 있을 만큼 짧아야 합니다. 이는 팀 일부가 시각적으로(AppMaster 등) 작업하고 일부는 코드로 작업할 때 더 중요합니다. 규칙이 누군가의 머릿속에만 있으면 인수인계가 실패합니다.

예: 두 모델에서의 현실적인 주간 릴리스

6인 제품 팀이 금요일마다 배포하고 두 명의 QA 테스터가 하나의 스테이징 환경을 공유한다고 가정해보세요. 스테이징이 불안정하면 모든 사람의 테스트가 중단됩니다.

GitFlow로 바쁜 주

월요일: 세 명의 개발자가 기능을 마치고 develop으로 PR을 엽니다. QA는 develop에서 빌드된 스테이징을 테스트하기 시작합니다.

수요일: 팀이 금요일 배포를 보호하기 위해 release/1.8을 만듭니다. 새로운 작업은 계속 develop에 쌓이지만 QA는 이제 릴리스 빌드에 집중합니다.

목요일 오후: 늦은 버그가 발견됩니다. 수정은 먼저 release/1.8에 적용되어 QA가 빠르게 재검증할 수 있게 합니다. 그런 다음 누군가가 그 수정을 develop으로 병합합니다(여기서 실수가 자주 발생합니다).

일반적 리듬:

• 월-화: 기능이 develop에 병합되고 스테이징이 자주 변경됩니다.
• 수: release/1.8 생성, 스테이징은 릴리스 빌드로 전환.
• 목: release/1.8에서 버그 수정 후 develop에 병합.
• 금: release/1.8을 main에 병합, 태그하고 배포.

트렁크 기반으로 본 같은 주

주간은 main으로의 작은 빈번한 병합으로 구성됩니다. 기능은 플래그 뒤에 숨겨 불완전한 작업도 병합할 수 있습니다.

월~목: 개발자들이 매일 작은 변경을 병합합니다. QA는 고정된 후보 빌드를 테스트합니다.

화요일: 프로덕션 이슈 발생. 핫픽스는 main에서 짧은 브랜치를 만들고 리뷰 후 즉시 병합되어 프로덕션으로 승격됩니다. main이 진실의 출처이므로 별도의 백머지 단계가 필요하지 않습니다.

어느 쪽이든 팀은 명확한 승격 규칙이 필요합니다:

• 스테이징은 최신 고정 후보 빌드를 실행해야지 모든 커밋을 자동 반영하면 안 됩니다.
• QA는 준비되었을 때 새 후보를 요청해야지 자동으로 바뀌지 않습니다.
• 금요일 릴리스용 후보는 버그 픽스만 허용합니다.
• 그 외는 플래그 뒤에 두거나 후보에서 제외합니다.

혼란과 불안정한 QA를 만드는 흔한 실수

대부분의 팀이 실패하는 이유는 "잘못된" 모델을 선택해서가 아닙니다. 일상 습관이 모델과 맞지 않아 QA가 시끄러워지고 릴리스가 무작위로 느껴지기 때문입니다.

흔한 문제는 브랜치를 며칠 동안 방치하는 것입니다("아직 준비가 안 됐어"). 코드가 main과 달라지고 충돌이 쌓이며 QA는 아무도 재현할 수 없는 혼합된 빌드를 테스트하게 됩니다.

또 다른 실수는 실제 동결(freeze) 없이 GitFlow를 사용하는 것입니다. 릴리스 브랜치는 안정화를 위한 것인데 팀이 계속 "한 가지만 더" 집어넣으면 그 브랜치는 두 번째 메인 라인이 되고 QA가 무엇을 승인하는지 모르게 됩니다.

QA가 반쯤 완성된 빌드를 덤핑하는 환경이 되면 테스터들은 움직이는 목표를 쫓느라 시간을 낭비합니다.

가장 많은 혼란을 만드는 실수들:

• 늦게 병합되어 관련 없는 작업을 깨뜨리는 장기 기능 브랜치.
• 여전히 새로운 기능을 받아들이는 릴리스 브랜치.
• QA가 테스트한 빌드와 실제로 배포되는 빌드 사이에 승격 경로가 없음.
• 급하게 처리된 핫픽스를 모든 브랜치에 병합하지 않음.
• 소유자도 목적도 초기화 계획도 없는 환경들.

모두가 반복할 수 있는 규칙 세트를 유지하세요:

• QA는 오직 고정된 후보만 테스트합니다.
• QA에서 프로덕션으로 같은 아티팩트를 승격하세요.
• 각 환경에 소유자와 초기화 주기를 정하세요.
• 핫픽스는 같은 날 메인 라인으로 돌아가도록 합니다.

놀라움 없는 주간 배포를 위한 빠른 체크리스트

주간 배포는 팀이 몇 가지 지루한 질문에 자신 있게 대답할 수 있을 때 작동합니다. 두 개 이상에 대해 "아니오"라고 답하면 늦은 수정과 QA 혼란을 예상하세요.

• 오늘 안전하게 배포할 수 있는 하나의 브랜치가 있나요? 빌드되고 스모크 테스트를 통과하며 반쯤 결합된 변경을 피해야 합니다.
• 풀 리퀘스트가 작고 하루 이틀 내에 머지되나요? 장기 PR은 오래된 피드백과 큰 충돌을 의미합니다.
• QA는 움직이는 목표가 아니라 고정된 빌드를 테스트하나요? QA는 특정 빌드 번호나 릴리스 후보를 검증해야 합니다.
• 미완성 작업을 드라마 없이 릴리스에서 제외할 수 있나요? 기능 플래그, 설정 토글 또는 명확한 스코프 컷 규칙.
• 핫픽스와 롤백을 추측 없이 실행할 수 있나요? 짧은 런북이 부족한 집단 지식보다 낫습니다.

측정 가능한 목표 하나를 원하면: QA를 릴리스 후보에 고정하고 그 후보를 의도적인 수정 외에는 변경하지 마세요.

다음 단계: 다음 주에 시도할 하나의 변화 고르기

팀이 트렁크 기반 vs GitFlow로 논쟁 중이라면 한 번에 모든 것을 재설계하지 마세요. 가장 많은 시간을 잡아먹는 문제 하나를 골라 다음 릴리스에서 작은 실험을 해보세요.

병합 충돌이 가장 큰 고통이라면 즉시 브랜치 수명을 줄이세요. 매일(또는 격일) 작업을 올리되 필요하면 기능 플래그를 사용하세요.

QA 불안정이 가장 큰 고통이라면 QA가 무엇을 테스트하는지 고정하고 간단한 승격 단계를 정의하는 것부터 시작하세요.

가벼운 파일럿:

• 하나의 리포지토리와 하나의 팀을 선택하세요.
• 브랜치 최대 수명(예: 2일 초과 금지)을 정하세요.
• QA를 하나의 빌드에 고정하고 명시적 승격을 통해서만 변경하세요.
• 세 가지 수치(병합 해결 시간, QA 재작업 시간, 핫픽스 프로덕션 도달 시간)를 추적하세요.
• 2-4주 후 검토하고 조정하세요.

내부 도구나 고객 포털의 릴리스 압박을 줄이고 싶다면 AppMaster 같은 노코드 플랫폼(appmaster.io)을 사용해 시각적 디자인으로부터 생산 준비된 백엔드, 웹, 네이티브 모바일 앱을 생성하는 것도 도움이 됩니다. 다만 위의 습관들—작은 변경, 고정된 QA 후보, 명확한 승격 경로—은 여전히 필요합니다.