VS Code 사용자를 위한 Git Merge Conflict 해결 가이드: 내장 에디터 200% 활용법

VS Code 사용자를 위한 Git Merge Conflict 해결 가이드: 내장 에디터 200% 활용법

git pull을 눌렀는데 터미널에 CONFLICT가 뜨는 순간, 손이 멈추는 경험을 한 번쯤은 해봤을 거다. 특히 팀 프로젝트에서 브랜치를 오래 유지하다 머지하면 충돌 파일이 수십 개씩 쏟아지기도 한다. 그때마다 하나씩 파일을 열어 <<<<<<<, =======, >>>>>>> 마커를 눈으로 찾아 지우고 있다면, 꽤 비효율적인 방식을 쓰고 있는 거다.

VS Code에는 충돌 해결을 위한 도구가 기본으로 내장되어 있다. 인라인 에디터부터 3-Way Merge Editor까지, 제대로 쓰면 충돌 해결 시간을 절반 이상 줄일 수 있다. 이 글에서는 VS Code 내장 에디터를 실제 충돌 상황에서 어떻게 쓰는지, 설정은 어떻게 잡아두면 편한지를 흐름대로 정리한다.

---

충돌 마커, 구조부터 제대로 이해해야 실수가 없다

에디터 기능을 쓰기 전에 충돌 마커 자체를 이해해두는 게 먼저다. 직접 파일을 열었을 때 이런 구조를 본 적 있을 거다.

<<<<<<< HEAD
const limit = 100;
=======
const limit = 200;
>>>>>>> feature/increase-limit

<<<<<<< HEAD부터 =======까지가 현재 브랜치(Current)의 코드다. =======부터 >>>>>>> feature/increase-limit까지는 들어오는 브랜치(Incoming)의 코드다. 이 두 구간을 비교해서 어떤 내용을 살릴지, 또는 둘을 합칠지 결정하면 된다.

문제는 충돌이 한 파일에 여러 군데 뭉쳐 있거나, 같은 함수 내부에서 양쪽이 각각 다른 부분을 수정했을 때다. 이런 경우 텍스트만 보고 판단하면 실수가 나온다. 어떤 변경이 어떤 맥락에서 온 건지 한눈에 보이지 않기 때문이다. 이 상황에서 VS Code의 시각적 도구가 제 역할을 한다.

충돌 마커를 직접 지우는 방식은 간단한 충돌 하나짜리 파일에서는 빠를 수 있다. 하지만 한 파일에 5개 이상 충돌이 있거나, 어떤 변경이 더 최신인지 확인이 필요한 상황에서는 에디터를 통해 처리하는 게 훨씬 안전하다. 마커를 지우다가 실수로 한쪽 코드를 날려버리는 경우가 실제로 꽤 자주 생긴다.

---

인라인 에디터 — 빠른 단순 충돌 처리

VS Code에서 충돌이 있는 파일을 열면, 충돌 구간 위에 네 가지 액션 버튼이 나타난다.

• Accept Current Change — HEAD(내 브랜치) 코드를 선택
• Accept Incoming Change — 들어오는 브랜치 코드를 선택
• Accept Both Changes — 두 코드를 순서대로 모두 포함
• Compare Changes — 두 변경 사항을 나란히 비교

충돌 구간을 드래그하거나 직접 클릭할 필요 없이, 원하는 버튼을 누르면 마커가 사라지고 선택한 코드만 남는다. 단순히 한쪽 내용을 택해야 하는 충돌이라면 이 인라인 방식이 가장 빠르다.

왼쪽 Source Control 패널(사이드바의 브랜치 아이콘)을 보면 충돌 파일들이 C 표시와 함께 모여있다. 파일을 하나씩 열어서 인라인 버튼으로 처리하고, 모든 파일을 해결하면 된다.

Accept Both Changes는 주의해서 써야 한다. 두 변경이 순서에 무관한 경우(예: 서로 다른 함수를 각각 추가한 경우)라면 괜찮다. 하지만 같은 변수를 다른 값으로 설정하거나 같은 로직을 다르게 구현한 경우라면, 두 코드를 모두 포함하면 버그가 난다. 버튼을 누른 후 반드시 Result를 확인하는 습관이 필요하다.

충돌 파일이 많을 때는 Ctrl+Shift+G(맥은 Cmd+Shift+G)로 Source Control 패널을 열고, 충돌 파일 목록을 위에서부터 차례대로 열어가는 게 흐름을 잃지 않는 방법이다.

---

3-Way Merge Editor — 복잡한 충돌은 여기서 끝낸다

인라인 에디터는 단순한 충돌에 적합하지만, 변경 규모가 크거나 양쪽 의도를 모두 파악해야 하는 충돌에는 부족하다. 이럴 때 쓰는 게 3-Way Merge Editor다.

충돌 파일을 열었을 때 상단에 나타나는 "Resolve in Merge Editor" 버튼을 누르면 열린다. 또는 인라인 에디터 상태에서 ... 메뉴를 통해 접근할 수도 있다.

3-Way 에디터는 세 개의 패널로 구성된다.

[ Incoming (Left) ]  [ Current (Right) ]
         [ Result (Bottom) ]

• Incoming(좌측): 합쳐지는 브랜치의 변경 내용
• Current(우측): 현재 내 브랜치의 변경 내용
• Result(하단): 실제로 저장될 결과 코드

각 충돌 구간 옆에는 체크박스가 있다. Incoming 쪽을 체크하면 그 변경이 Result에 반영되고, Current 쪽을 체크하면 내 변경이 반영된다. 둘 다 체크하면 두 코드가 합쳐진다.

Accept Combination 버튼이 나타나는 충돌도 있다. 두 변경이 서로 다른 부분을 건드리는 경우 VS Code가 자동으로 합칠 수 있다고 판단할 때 표시된다. 실제로 써보면 코드 블록이 다른 위치에 추가된 경우나 서로 다른 프로퍼티를 추가한 경우에 잘 동작한다. 결과는 반드시 눈으로 확인하고 사용하는 게 안전하다.

Result 패널은 직접 편집도 가능하다. 체크박스로만 해결이 안 되는 복잡한 충돌 — 예를 들어 양쪽에서 같은 함수를 수정했는데 각각 필요한 부분만 가져와야 하는 경우 — 에는 Result 패널에 직접 코드를 작성하면 된다. 이게 단순 텍스트 에디터로 마커를 지우는 방식과의 가장 큰 차이다. 양쪽 원본을 보면서 최종 코드를 작성할 수 있다.

에디터 오른쪽에는 남은 충돌 수(conflict count)가 표시된다. 모든 충돌을 해결하면 하단의 Complete Merge 버튼이 활성화된다. 이 버튼을 누르면 해당 파일이 스테이징(stage)되고 머지 에디터가 닫힌다.

---

git.mergeEditor 설정과 워크플로 최적화

3-Way Merge Editor를 기본으로 사용하려면 설정을 확인해야 한다.

Settings (Ctrl+, 또는 Cmd+,) → 검색창에 merge editor 입력 → "Git: Merge Editor" 항목 체크

또는 settings.json에 직접 추가한다.

{
  "git.mergeEditor": true
}

이 설정이 켜져 있으면 충돌 파일을 더블클릭할 때 자동으로 3-Way Merge Editor로 열린다. 설정이 꺼져 있으면 인라인 에디터가 기본이다.

개인적으로는 이 설정을 켜두는 편이 관리하기 편했다. 단순한 충돌도 3-Way 에디터에서 처리하면 양쪽 컨텍스트가 보이기 때문에 실수가 줄었다. 물론 충돌 하나짜리 파일에서는 인라인이 더 빠르게 느껴지기도 하는데, 그건 취향 차이다.

실전 워크플로를 정리하면 이렇다:

1. git merge 또는 git pull 실행
2. VS Code Source Control 패널에서 충돌 파일 목록 확인
3. 파일별로 "Resolve in Merge Editor" 실행
4. 각 충돌 구간 체크박스 처리 → Result 확인 → Complete Merge
5. 모든 파일 처리 후 Source Control에서 커밋

Source Control 패널에서 충돌 파일들을 한눈에 볼 수 있고, 해결이 완료된 파일은 목록에서 빠지기 때문에 진행 상황을 트래킹하기 편하다. 터미널에서 git status를 계속 치는 것보다 훨씬 직관적이다.

터미널을 병행해서 쓰는 경우라면, 머지 도중 잘못됐다고 판단되는 시점에 git merge --abort를 치면 머지 전 상태로 되돌아간다. 이 명령은 머지를 완전히 취소하고 싶을 때 쓴다. 커밋은 되지 않은 상태이므로 데이터 손실 걱정 없이 쓸 수 있다.

---

GitHub Copilot을 활용한 AI 보조 충돌 해결 (2025~2026)

VS Code 1.105(2025년 9월 릴리즈)부터 GitHub Copilot 구독이 있는 경우 AI를 활용한 충돌 해결 기능이 추가됐다. 아직 실험적 기능(experimental)이라고 명시되어 있지만, 실제로 꽤 쓸 만한 수준이다.

충돌 마커가 있는 파일을 열었을 때 Copilot 관련 액션이 나타난다. 해당 액션을 선택하면 Chat 뷰가 열리면서, Copilot이 머지 베이스(두 브랜치의 공통 조상 커밋)와 양쪽 변경 내용을 컨텍스트로 받아서 충돌 해결 방향을 제안해준다.

Copilot이 분석하는 방식은 단순히 어느 쪽 코드가 더 최신인지 보는 게 아니다. 각 변경의 의도(intent)를 이해하고, 두 변경이 서로 독립적인지 의존적인지를 파악해서 제안한다. 코드 리뷰어처럼 "이 두 변경은 충돌하지 않으니 둘 다 포함해도 됩니다" 또는 "이 부분은 한쪽을 선택해야 합니다"라는 식으로 안내해준다.

2026년 4월 기준으로는 github.com PR 화면에서도 "Fix with Copilot" 버튼이 추가됐다. PR에 충돌이 있는 경우 버튼을 누르면 Copilot이 충돌을 해결하고 빌드·테스트까지 확인한 뒤 변경 사항을 푸시해준다. 로컬에서 직접 머지 작업을 할 필요 없이 PR 화면에서 처리가 가능해진 거다.

다만 이 기능은 GitHub Copilot 구독이 없으면 쓸 수 없다. 무료로 쓰는 개발자라면 위에서 설명한 3-Way Merge Editor만으로도 충분히 대부분의 충돌을 해결할 수 있다. AI 보조는 "충돌이 너무 복잡해서 어느 쪽을 선택해야 할지 모르겠다"는 상황에서 판단 보조 용도로 쓰는 게 가장 적합하다.

---

충돌 자체를 줄이는 협업 습관

좋은 도구를 갖춰도 충돌이 자주 터지면 피로도가 높아진다. 실무에서 충돌 빈도를 줄이는 데 가장 효과적이었던 습관 몇 가지를 정리한다.

1. 브랜치를 오래 살려두지 않는다

오래 유지한 브랜치일수록 메인 브랜치와의 차이가 커진다. 작업 단위를 작게 쪼개서 자주 머지하는 편이 한 번에 거대한 충돌을 해결하는 것보다 낫다. 이상적으로는 3~5일 이상 된 브랜치는 중간에 main을 한 번 rebase 또는 merge해서 최신 상태를 유지해두는 게 좋다.

2. 작업 전 항상 pull을 먼저

새 코드를 작성하기 전에 git pull로 원격 변경 사항을 먼저 받아오는 습관이 있으면, 충돌 가능성이 상당히 줄어든다. 특히 팀원이 많을수록 이 습관의 효과가 크다.

3. 같은 파일을 동시에 건드리는 구조를 피한다

설계 단계에서 역할 분리가 잘 돼있으면 충돌 자체가 덜 생긴다. 기능별로 파일을 분리하거나, 특정 공통 파일(예: 환경 설정 파일, 패키지 파일)은 한 사람이 책임지고 관리하는 방식이 도움이 된다.

4. rebase vs merge 전략을 팀에서 통일한다

merge는 충돌이 한 번에 몰리고, rebase는 커밋 하나하나마다 충돌이 생길 수 있다. 어떤 방식이 더 낫다기보다는, 팀 내에서 전략을 통일해두지 않으면 혼란이 생긴다. 히스토리를 선형으로 유지하고 싶으면 rebase, 머지 히스토리를 남기고 싶으면 merge를 선택하되 이유를 팀원과 공유해두는 게 낫다.

---

실전 FAQ — 자주 막히는 상황 모음

Q. "Complete Merge" 버튼이 비활성화되어 있어요.

Result 패널에 아직 해결되지 않은 충돌 구간이 남아있는 경우다. 오른쪽 충돌 카운터를 확인하고, 모든 충돌을 처리했는지 체크한다. 체크박스 없이 직접 Result를 편집한 경우에도 충돌 마커가 완전히 제거됐는지 확인해야 한다.

Q. 머지 에디터에서 수정하다가 망했어요. 처음으로 되돌리고 싶어요.

아직 "Complete Merge"를 누르지 않았다면, 에디터를 닫고 git merge --abort를 실행하면 머지 전 상태로 돌아간다. 이미 Complete Merge를 눌렀다면, git reset --merge HEAD를 사용하거나, git log로 이전 커밋 해시를 확인하고 git reset --hard <hash>로 되돌릴 수 있다. 단 hard reset은 커밋되지 않은 변경 사항도 날아가니 주의한다.

Q. 3-Way 에디터에서 Base(공통 조상 버전)를 보고 싶어요.

기본 레이아웃에서는 Base 뷰가 보이지 않는다. 3-Way 에디터 우측 상단의 레이아웃 버튼에서 "Show Base"를 활성화하면 세로 레이아웃으로 전환되면서 Base 파일도 함께 볼 수 있다. 충돌의 원인(두 브랜치 모두 무엇을 변경했는지)을 파악해야 할 때 유용하다.

Q. 충돌 파일이 너무 많아요. 일부는 한쪽을 그냥 전부 선택해도 되는 경우인데, 빠르게 처리하는 방법이 있나요?

터미널에서 git checkout --ours <파일경로> 또는 git checkout --theirs <파일경로>를 사용하면 특정 파일의 충돌을 한쪽으로 전부 선택할 수 있다. --ours는 현재 브랜치 버전, --theirs는 들어오는 브랜치 버전으로 덮어쓴다. 이후 git add <파일경로>로 스테이징한다.

Q. settings.json에 mergeEditor를 true로 했는데 여전히 인라인으로 열려요.

VS Code를 완전히 재시작하거나, Source Control 패널에서 파일을 마우스 오른쪽 클릭 → "Open in Merge Editor"를 선택해보자. 파일을 더블클릭하는 경우에만 설정이 적용되는지 확인한다.

---

마무리

VS Code의 3-Way Merge Editor를 처음에는 굳이 쓸 필요가 있나 싶었는데, 익숙해지고 나서는 충돌 파일이 많은 상황에서 확실히 실수가 줄었다. 인라인으로 마커 지우던 시절에는 결과를 확인하지 않고 넘어가다 버그를 만든 적도 있었다.

정리하면:

• 단순 충돌(1~2개) → 인라인 액션 버튼으로 빠르게 처리
• 복잡하거나 양쪽 맥락 파악이 필요한 충돌 → 3-Way Merge Editor
• git.mergeEditor: true 설정으로 기본 에디터 변경
• GitHub Copilot 구독자라면 AI 보조 해결 기능 시도 가능 (VS Code 1.105 이상)
• 충돌 자체를 줄이려면 브랜치를 짧게 유지하고, 작업 전 pull 습관화

직접 한 번 충돌 상황을 만들어보고 3-Way 에디터를 써보면 감이 바로 잡힌다. 임시 브랜치 두 개에서 같은 파일을 다르게 수정한 다음 머지하는 방식으로 연습 환경을 만들어보는 것도 방법이다.

---

Sources:
- Resolve merge conflicts in VS Code
- Source Control in VS Code
- Finally Released: 3-Column Merge Editor in VS Code!
- Visual Studio Code taps AI for merge conflict resolution | InfoWorld
- Fix merge conflicts in three clicks with Copilot cloud agent - GitHub Changelog
- Resolving Merge Conflicts with AI: Copilot, Cursor & Claude | DeployHQ
- Git에서 머지 충돌을 해결하는 방법과 실용 예시 - freeCodeCamp
- 7.8 Git 도구 - 고급 Merge
- Resolve Merge Conflicts in Git - 2026 Complete Guide - Picode
- How to Resolve Merge Conflicts Using the Merge Editor Feature on VS Code