학생들과 실제 겪은 merge 충돌 사례와 실무형 해결 전략

협업 중 merge conflict를 반복해서 겪는 학생에게 전한 이야기

요즘 개발 기본을 다질 겸, 과외를 진행하고 있어요

최근에 제가 진행하고 있는 개발 과외 수업에서, 학생들이 실제 협업을 해보는 팀 프로젝트를 시작했습니다.
그 과정에서 꽤 흥미로운 실전 이슈가 발생했는데요 — 바로 동일 파일에 대해 동시에 여러 명이 commit & push를 하며 발생하는 merge conflict 문제였습니다.

학생 A가 main 브랜치에서 작업을 하고, 동시에 학생 B와 C도 같은 파일을 수정해 push를 시도하면서 충돌이 끊임없이 발생하는 상황이었죠.

이 문제를 단순히 “주의하세요”로 넘기기보다는, 실제 실무에서는 어떻게 이런 충돌을 방지하고 해결하는지 알려주고 싶었습니다.

---

문제 상황 요약

 발생한 상황

• 여러 명이 동시에 App.tsx 같은 동일 파일을 수정
• 각자 본인의 브랜치가 아닌 main 또는 동일한 feature 브랜치에서 직접 작업
• Pull 없이 바로 commit & push 진행
• 결과적으로 merge conflict가 계속 발생

 주요 원인

• 브랜치 전략 부재 (feature 브랜치 없는 직접 수정)
• 작업 순서 불일치 (pull 없이 push)
• 소스트리/CLI 기본 사용법 미숙
• 팀 내 Git 규칙 부재

---

실무에서는 어떻게 해결할까?

1.  브랜치 전략을 확립하자 (Git Flow, GitHub Flow 등)

기본 원칙: main은 배포 가능한 안정 브랜치로 유지하고, 각 작업자는 feature 브랜치에서 작업해야 합니다.

# 기능 개발 전 feature 브랜치 생성
$ git checkout -b feature/login-ui

이후 작업을 마친 뒤에는 main에 직접 push하지 않고, **PR(Pull Request)**로 병합합니다.

2.  항상 push 전에 최신 내용을 pull 하도록 하자

Git은 분산 버전 관리 시스템이기 때문에, 서버와 나의 로컬이 불일치하면 충돌이 발생합니다.

# push 전에 꼭 최신 내용을 반영한다
$ git pull origin main --rebase

--rebase 옵션을 쓰면 병합 커밋 없이 내 커밋이 가장 최신 커밋 뒤로 재정렬되어 히스토리가 깔끔하게 유지됩니다.

3.  PR 리뷰를 통한 병합 절차 도입

GitHub에서 PR(Pull Request)을 활용하면 병합 전에 코드 리뷰를 거칠 수 있어,
동시에 동일한 파일을 수정한 경우도 어느 쪽이 먼저 적용되어야 하는지 판단할 수 있습니다.

• GitHub의 "Resolve conflict" UI를 활용해 병합 전 충돌을 직접 해결할 수 있음
• 리뷰를 통해 충돌 가능성 높은 코드를 사전에 조정할 수 있음

4.  커밋 책임을 나누자 (파일 단위, 영역 단위 등)

팀원이 동시에 동일한 파일을 만져야 한다면, 한 파일이라도 영역을 나눠서 책임지도록 정하는 것이 좋습니다.

예:

• App.tsx 파일의 상단 영역은 UI 담당자, 하단은 상태관리 담당자 등
• 더 나아가면 파일을 분리해서 컴포넌트 단위로 분할하는 것도 좋은 방법

5.  CI 테스트 도입 - 실무에서는 이런 내용까지

단순히 충돌을 해결하는 것에서 그치지 않고, 병합 전 코드가 문제 없이 작동하는지 자동으로 확인하는 체계를 구축합니다.
바로 CI (Continuous Integration) 도구를 활용한 자동 테스트 실행입니다.

어떻게 동작할까요?

• GitHub에 Pull Request가 생성되면
• CI 툴 (예: GitHub Actions, Jenkins, CircleCI)이 자동으로 테스트 스크립트를 실행
• 테스트가 통과하지 않으면 병합 불가

예시: GitHub Actions으로 테스트 자동 실행

# .github/workflows/test.yml
name: Run Tests

on:
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Install dependencies
        run: npm install
      - name: Run tests
        run: npm test

도입 효과

항목	효과
자동 검증	PR에서 충돌 해결뿐 아니라 기능 이상 여부도 검출 가능
코드 신뢰도 상승	팀원 누구든 병합된 코드는 최소한의 검증을 거침
피드백 속도 향상	“실행해봤어?”라는 질문 없이 PR에서 바로 확인

초기에 어렵게 느껴질 수 있지만, 팀 협업에서 CI는 반드시 익혀야 할 도구입니다.
개발만 잘하는 팀보다, 테스트와 협업을 잘하는 팀이 더 강한 팀입니다.

---

학생에게 이렇게 설명했어요

"실무에서도 같은 파일을 여러 명이 수정할 일은 많아요. 중요한 건, 충돌 자체를 피하는 게 아니라 예상하고 구조를 만드는 것이에요."

그래서 우리는:

• 각자 feature 브랜치를 만들고,
• 매 작업 전 pull --rebase를 하고,
• PR을 통해 병합하며,
• 겹치는 영역이 있다면 사전 조율하거나 영역을 나누자고 했습니다.

---

정리

문제	해결 전략
동일 파일 동시 수정	feature 브랜치 + PR 병합 방식 사용
pull 없이 push	항상 git pull --rebase 후 push
역할/파일 중복 수정	작업 영역 사전 분리 또는 리팩토링
병합 이후 오류 발생	CI로 자동 테스트 도입하여 예방

---

마무리

처음 겪는 충돌은 당황스럽고 귀찮을 수 있지만, 실은 이런 상황이 팀으로서 성장할 수 있는 기회입니다.
이번 경험을 통해 학생들이 단순히 코드를 잘 짜는 개발자가 아니라, 협업을 이해하는 개발자로 한 단계 올라설 수 있었으면 합니다.

그리고 Git은 익숙해질수록 '내가 뭘 잘못했는지'를 빨리 알게 해주는 좋은 도구입니다.
이제부터는 충돌이 날 때마다 겁먹기보다는, 왜 생겼는지 분석하고 구조적으로 해결하는 습관을 들이면 됩니다.