모닝 머지 리추얼: 브랜치를 차분하고 컨플릭트 없는 상태로 지켜주는 작은 데일리 습관

팀에서 기능 브랜치를 main에 머지하는 일을 모두가 두려워한다면, 혼자가 아닙니다. 오래 살아남은 브랜치가 main과 멀어지기 시작하면, 고통스러운 컨플릭트, 깨진 빌드, 뒤늦게 터지는 문제들이 거의 확정된 수순처럼 따라옵니다.

이걸 고치기 위해 거창한 프로세스 개편이 필요한 건 아닙니다. 필요한 건 아주 작은 습관 하나입니다.

그게 바로 모닝 머지 리추얼(Morning Merge Ritual) 입니다. 매일, 모든 개발자가 자신의 기능 브랜치를 main과 짧게 동기화하는 작은 루틴입니다. 몇 분이면 끝나지만, 디버깅과 컨플릭트 해결에 들일 수도 있었던 몇 시간(혹은 며칠)을 아껴줍니다.

이 글에서는 이 리추얼이 구체적으로 어떻게 생겼는지, 언제 rebase를 쓰고 언제 merge를 써야 하는지, 그리고 이것을 예측 가능한 팀 관행으로 만드는 방법까지 다룹니다.

브랜치가 난폭해지는 이유 (그리고 그것이 초래하는 비용)

활발하게 움직이는 팀에서는 main이 빠르게 변합니다.

크리티컬 버그 픽스가 머지되고
다른 기능들이 연달아 들어오고
리팩터링으로 API, 디렉터리 구조, 각종 계약(contracts)이 바뀝니다.

한편, 여러분의 기능 브랜치는 계속 따로 흘러갑니다. main과 동기화하지 않은 채 오래 갈수록, 다음과 같은 문제들이 점점 커집니다.

크고 지저분한 머지 컨플릭트가 브랜치를 통합하는 시점에 한꺼번에 터집니다.
다른 변경 사항 때문에 전제가 깨져서 생기는 예상 밖의 깨짐들이 등장합니다.
"fix merge", "resolve conflicts" 같은 커밋이 가득한 지저분한 커밋 히스토리가 만들어집니다.
여러분 코드뿐 아니라 통합 후 후폭풍까지 한꺼번에 리뷰해야 해서 PR 리뷰가 느려집니다.

하나하나만 봐도 아픈데, 이게 겹치면 생산성을 끌어내리는 거대한 마찰이 됩니다. 그리고 사람들은 대개 "원래 그런가 보다" 하고 넘깁니다. 그럴 필요가 없습니다.

작고 규칙적인 머지 습관을 들이면, 브랜치는 항상 main 근처에 머물게 되고, 컨플릭트는 일찍, 작고 이해하기 쉬운 단위로 나타납니다.

모닝 머지 리추얼 한눈에 보기

핵심 아이디어는 간단합니다. 하루에 한 번(가능하면 아침에), 자신이 작업 중인 기능 브랜치를 main과 동기화한다 는 것입니다.

큰 흐름은 다음과 같습니다.

로컬 main 업데이트:
```
git checkout main
git pull origin main
```
다시 기능 브랜치로 전환:
```
git checkout feature/my-task
```
main을 기능 브랜치에 가져오기 (상황에 따라 rebase 또는 merge 선택):
- 브랜치를 혼자 쓰고 있다면? rebase 권장:
```
git rebase main
```
- 여러 명이 함께 쓰는 브랜치라면? merge 권장:
```
git merge main
```
나오는 컨플릭트는 바로 해결합니다. (대개 작고 단순합니다.)
테스트 / 린트 실행으로 모든 것이 여전히 정상 동작하는지 확인합니다.

이게 전부입니다. 개발자 한 명당 하루 5~15분 정도면 브랜치를 차분하게 유지하고, 통합 작업을 “재미없는 루틴” 수준으로 만들 수 있습니다.

Rebase를 쓸 때와 Merge를 쓸 때

모닝 머지 리추얼의 핵심 결정은 이것입니다. rebase를 쓸까, merge를 쓸까? 정답은 그 브랜치를 어떻게 사용하고 있는지에 따라 달라집니다.

개인 기능 작업에는 Rebase 사용하기

기능 브랜치에서 본인만 혼자 작업하고 있다면, 보통은 main에 rebase하는 게 최선입니다.

개인 브랜치에 rebase가 잘 맞는 이유:

커밋 히스토리가 선형(linear) 이고 깔끔하게 유지됩니다.
브랜치의 커밋들이 지금의 main 바로 위에 쌓인 것처럼 보입니다.
리뷰어는 기능이 어떻게 진화했는지 직관적인 스토리로 볼 수 있습니다.

개인 브랜치에서의 전형적인 흐름:

git checkout main
git pull origin main

git checkout feature/faster-search
git rebase main

만약 컨플릭트가 생기면, 해결한 후 rebase를 이어갑니다.

# 파일에서 컨플릭트 해결 후
git add <files>
git rebase --continue

해당 브랜치를 쓰는 사람이 나 혼자라면, 히스토리를 다시 쓰는(rewrite) 행위가 문제되지 않습니다. 다른 누군가가 같은 브랜치의 변경 이력을 기준으로 작업하고 있을 일이 없기 때문입니다.

여러 명이 함께 쓰는 브랜치에는 Merge 사용하기

반대로, 한 브랜치에 여러 개발자가 함께 작업하는 상황에서 rebase로 히스토리를 바꾸면, 팀 전체가 혼란에 빠질 수 있습니다.

팀원들이 보던 “자기” 커밋이 사라졌다가, 해시가 바뀐 새 커밋으로 다시 나타납니다.
모두가 git pull --rebase, git reset 같은 복잡한 동작으로 로컬을 맞춰야 합니다.
이런 혼란이 반복되면 Git 자체에 대한 자신감이 떨어집니다.

이 경우에는 main을 해당 브랜치에 merge하는 편이 훨씬 낫습니다.

git checkout main
git pull origin main

git checkout release/2.0
git merge main

머지 커밋이 생기긴 하지만, 장점이 있습니다.

히스토리가 모두에게 정직하고 공유된 상태로 유지됩니다. 누군가가 남의 눈앞에서 히스토리를 다시 쓰지 않습니다.
팀원들은 별다른 두려움 없이 git pull을 해도 됩니다.
브랜치 타임라인이 main과 실제로 통합된 시점을 그대로 반영합니다.

팀에 이런 단순한 규칙을 두면 큰 도움이 됩니다.

팀 규칙: "한 브랜치를 두 명 이상이 같이 쓰면, main을 그 브랜치에 merge한다. 혼자 쓰는 브랜치는 main에 rebase해도 된다."

이 작은 리추얼이 놀라울 만큼 잘 작동하는 이유

매일 main과 동기화하는 일은 얼핏 보면 별것 아닌 것처럼 느껴지지만, 실제로는 여러 구조적인 문제를 한 번에 해결해 줍니다.

1. 더 작고, 더 안전한 컨플릭트

하루 정도만 main에서 떨어져 있었다면, 수십 개의 파일이 한 번에 컨플릭트 나는 경우는 드뭅니다. 컨플릭트가 생기더라도:

전부 최근에 건드렸던, 익숙한 변경 영역에 집중됩니다.
상황을 이해하기가 훨씬 쉽습니다.
설계가 아직 유연한 초기 단계에 문제를 조기에 드러내는 역할을 합니다.

결국 "커다란 머지 지옥의 날"을 "매일 5분짜리 예측 가능한 작은 정리"로 바꾸게 됩니다.

2. 통합 시점의 깜짝 이슈 감소

브랜치가 항상 main 근처에 머물면:

다른 사람이 만든 상충되는 변경을 빨리 발견합니다.
API나 스키마가 바뀌면, 몇 주 뒤가 아니라 바로 그날 알 수 있습니다.
마지막 단계에서야 기능이 더 이상 컴파일되지 않거나, 테스트가 깨져 있음이 드러나는 일을 줄일 수 있습니다.

통합은 더 이상 최종 보스전이 아니라, 일상적인 연속 과정이 됩니다.

3. 더 깔끔하고, 더 유용한 히스토리

브랜치 관리가 느슨하고, PR 워크플로가 제각각이면 대개 이렇게 흘러갑니다.

"merge from main" 같은 반복적인 머지 커밋이 쌓입니다.
코드 변경과 컨플릭트 해결이 뒤섞인 거대한 머지 커밋이 생깁니다.
"fix tests again", "oops, forgot file", "final fix" 같은 노이즈 커밋들로 로그가 부풀어 오릅니다.

분명한 전략을 두면:

개인 브랜치는 rebase로 선형적이고 깨끗한 히스토리를 유지합니다.
공유 브랜치는 예측 가능하고 추적 가능한 방식으로 merge가 이뤄집니다.
커밋 히스토리가 스릴러가 아니라, 읽을 수 있는 스토리가 됩니다.

4. 예측 가능한 팀 관행

이 리추얼이 개인 습관을 넘어 팀 관행이 될 때 진짜 힘을 발휘합니다.

모두가 main과 언제, 어떻게 동기화할지 알고 있습니다.
코드 리뷰는 항상 최신 상태의 브랜치를 기준으로 이뤄집니다.
CI 파이프라인은 실제 통합 상태를 반영하는 브랜치에서 돌게 됩니다.

"어제까지 내 로컬에서는 잘 됐는데…" 류의 문제를 크게 줄일 수 있습니다.

팀 전체의 표준으로 만드는 방법

모닝 머지 리추얼을 팀의 기본 관행으로 만들려면, 명문화하고 공유해야 합니다.

1. 명확한 정책 정의하기

팀 차원에서 다음과 같은 단순하고 명시적인 가이드에 합의하세요.

빈도: "업무일마다, 기능 개발을 시작하기 전에 자신의 브랜치를 main으로 한 번 업데이트한다."
Rebase vs Merge:
- 개인 브랜치: main에 rebase
- 공유 브랜치: main을 브랜치에 merge
PR을 열기 전에: 항상 먼저 main으로 업데이트한 뒤 PR을 연다.

이 내용을 기여 가이드(contribution guide), 팀 위키, 혹은 저장소의 CONTRIBUTING.md에 문서화하세요.

2. 워크플로에 자연스럽게 녹이기

실제 적용에 도움이 되는 몇 가지 팁입니다.

PR 템플릿에 짧은 체크리스트를 추가합니다.
- 브랜치가 최신 main 기준으로 rebase/merge 되어 있음
- 로컬 테스트 통과
main과 일정 수준 이상 뒤처진 PR은 CI에서 자동 거부하는 정책을 둘 수 있습니다.
간단한 헬퍼 스크립트나 alias를 만드는 것도 방법입니다. 예를 들어:
```
alias gsync='git checkout main && git pull && git checkout - && git rebase main'
```
(공유 브랜치에는 이걸 merge 버전으로 만든 변형을 쓸 수 있습니다.)

3. “어떻게”보다 “왜”를 먼저 설명하기

개발자들이 단지 "매일 rebase/merge해야 한다"는 말만 들으면, 그건 그저 또 하나의 관료제처럼 느껴집니다. 하지만 다음을 이해하게 되면:

뜻밖의 컨플릭트를 줄이고
리뷰를 더 부드럽게 만들며
막판 대형 통합 사고를 최소화한다는 점을 알게 되면,

훨씬 자발적으로 이 리추얼을 받아들이고 팀 차원에서 서로 챙겨 주게 됩니다.

큰 골칫거리를 막아 주는 작은 습관

머지 지옥을 줄이기 위해 새 브랜칭 전략을 도입하거나, 복잡한 Git 교육 프로그램을 돌릴 필요는 없습니다. 필요한 건 의도적인 일일 습관 하나입니다.

main을 업데이트하고
자신의 브랜치를 동기화하고 (혼자면 rebase, 여럿이면 merge)
큰 컨플릭트가 되기 전에 작은 컨플릭트를 지금 해결하는 것

이 모닝 머지 리추얼은 브랜치를 차분하게, 히스토리를 이해하기 쉽게 만들어 줍니다. 그리고 팀이 Git과 싸우는 대신, 진짜 기능을 만드는 데 집중할 수 있게 합니다.

내일 아침부터 시작해 보세요. 새 코드를 쓰기 전에, 먼저 자신의 브랜치를 main과 맞추는 것입니다. 일주일쯤 지나면 머지가 얼마나 덜 스트레스인지 스스로 느끼게 될 것입니다. 그때 이 단순한 리추얼을 팀의 공식적인 작업 방식으로 채택할지 함께 논의해 보세요.