Git 충돌 표시가 떴을 때, 변경을 잃지 않고 해결하는 순서

AI가 고친 코드를 저장한 뒤 git pull이나 merge를 했는데 파일 안에 <<<<<<< HEAD가 보이면 초보자는 둘 중 하나를 통째로 지우고 싶어집니다. 하지만 이 표시는 Git이 망가졌다는 뜻이 아니라, 같은 줄 근처를 두 변경이 함께 고쳐서 사람이 결정해야 한다는 신호입니다. 이때 AI에게 바로 "충돌 해결해 줘"라고 던지면 의도와 다른 쪽 코드가 남을 수 있습니다.

Tap to zoom

git-scm.com의 Git 공식 git merge 문서는 충돌이 나면 작업 트리에 표시가 남고, 파일을 고친 뒤 git add로 인덱스에 올린 다음 git commit 또는 git merge --continue로 마무리한다고 설명합니다. docs.github.com의 GitHub Docs도 줄 단위 변경이 서로 충돌하면 어떤 변경을 포함할지 선택해야 한다고 안내합니다. 그래서 이 글의 목표는 Git 이론을 외우는 것이 아닙니다. 충돌 구간을 AI에게 넘기기 전에 판단 재료를 5칸으로 줄이는 것입니다.

먼저 git status로 충돌 파일만 따로 적습니다

처음 할 일은 충돌 표시가 있는 파일을 아무렇게나 고치는 것이 아니라 현재 상태를 확인하는 것입니다. 터미널에서 아래 명령을 실행합니다.

git status

Git의 git status 문서는 충돌이 아직 해결되지 않은 경로를 unmerged 상태로 보여 준다고 설명합니다. 여기서 봐야 할 것은 긴 설명 전체가 아니라 파일 이름입니다. 예를 들어 both modified: app/page.tsx가 보이면 지금 건드릴 파일은 app/page.tsx입니다.

AI에게 넘길 첫 칸은 이렇게 씁니다.

충돌 파일: app/page.tsx
현재 상황: git pull 중 both modified 상태

이 두 줄이 없으면 AI는 어느 파일에서 벌어진 충돌인지 추측해야 합니다. 충돌 해결의 첫 행동은 파일 수정이 아니라 상태와 파일명을 고정하는 것입니다.

Tap to zoom

<<<<<<<, =======, >>>>>>> 세 줄을 기준선으로 봅니다

충돌 파일을 열면 보통 이런 모양이 보입니다.

<<<<<<< HEAD
const title = "코딩사관학교";
=======
const title = "AI 코딩 훈련소";
>>>>>>> origin/main

<<<<<<< HEAD 위쪽은 현재 내 브랜치 쪽 변경이고, ======= 아래쪽은 가져온 쪽 변경입니다. 다만 이름만 보고 무조건 위를 남기거나 아래를 남기면 안 됩니다. 현재 브랜치가 작업 중인 기능인지, 원격에서 이미 반영된 이름 변경인지, 둘을 합쳐야 하는지 확인해야 합니다.

AI에게 붙일 때는 파일 전체보다 충돌 구간과 원하는 결과를 같이 줍니다.

충돌 구간:
[<<<<<<< HEAD부터 >>>>>>> origin/main까지 붙여넣기]

남기고 싶은 의도:
- 사이트 이름은 코딩사관학교로 유지
- 새 문구가 다른 파일과 연결되어 있으면 알려 달라
- 전체 파일 재작성 금지

여기서 중요한 문장은 전체 파일 재작성 금지입니다. 충돌은 보통 작은 구간의 의사결정 문제인데, AI가 주변 구조까지 바꾸면 새 오류가 생깁니다.

둘 중 하나를 고르기 전에 실행 결과를 정합니다

충돌을 해결한다는 말은 표시 세 줄을 지우는 일이 아닙니다. 표시를 지운 뒤 코드가 실행 가능한 한 가지 결과로 남아야 합니다. 그래서 선택 전에 아래 세 질문을 채웁니다.

이 표를 채우면 ours와 theirs라는 말에 덜 휘둘립니다. 남길 기준은 브랜치 이름이 아니라 실행 결과입니다. GitHub Docs가 말하는 핵심도 서로 다른 변경 중 포함할 변경을 선택해야 한다는 점입니다.

AI에게는 이렇게 묻습니다.

아래 Git 충돌 구간을 해결해 주세요.
목표 결과:
- 헤더 문구는 "코딩사관학교" 유지
- origin/main에서 들어온 nav 링크 구조는 유지
- 버튼 onClick 수정은 유지

금지:
- 충돌 구간 밖의 코드 재작성 금지
- import 정리나 스타일 변경 금지

출력:
- 최종 코드 조각
- 왜 그 조합을 골랐는지 3줄

표시를 지운 뒤에는 실행과 검색으로 확인합니다

AI가 답을 줬거나 직접 골랐다면 <<<<<<<, =======, >>>>>>> 표시가 파일에 남아 있지 않아야 합니다. 편집기 검색으로 세 문자열을 각각 찾습니다.

<<<<<<<
=======
>>>>>>>

그다음 프로젝트가 제공하는 가장 가까운 확인 명령을 실행합니다. 작은 React나 Next.js 작업이라면 보통 아래 중 하나입니다.

npm run lint
npm run typecheck
npm run build

모든 프로젝트에 세 명령이 다 있는 것은 아닙니다. package.json의 scripts를 보고 현재 프로젝트에 있는 명령만 고르면 됩니다. 여기서 실패하면 충돌 해결은 끝난 것이 아닙니다. 표시 제거와 실행 확인이 같이 끝나야 충돌 해결입니다.

마지막에 git add로 해결 완료를 표시합니다

파일을 고치고 확인까지 했으면 다시 상태를 봅니다.

git status

아직 unmerged로 보이면 Git 입장에서는 해결이 끝나지 않았습니다. Git 공식 문서의 흐름처럼 고친 파일을 인덱스에 올려야 합니다.

git add app/page.tsx

그 뒤 상황에 맞게 merge라면 commit 또는 git merge --continue, rebase라면 git rebase --continue를 진행합니다. GitHub Docs도 rebase 충돌을 해결한 뒤에는 git rebase --continue를 호출해야 한다고 안내합니다.

AI에게 마지막으로 확인받고 싶다면 파일 전체가 아니라 이 묶음만 줍니다.

Git 충돌 해결 최종 확인을 해 주세요.

git status 결과:
[붙여넣기]

수정한 충돌 구간:
[최종 코드 조각]

검증 결과:
- npm run build: 통과 또는 실패 로그

확인할 것:
1. 충돌 표시가 남아 있는지
2. 내가 남기려던 결과가 코드에 반영됐는지
3. git add 전에 더 볼 위험이 있는지

이 질문은 AI에게 새 코드를 만들게 하는 요청이 아닙니다. 충돌 해결이 끝났는지 검산하게 만드는 요청입니다.

오늘은 5칸만 채우고 AI에게 묻습니다

Git 충돌은 처음 보면 위험해 보이지만, 순서를 줄이면 다룰 수 있습니다. 아래 5칸을 채운 뒤 AI에게 넘기면 답변이 짧아지고, 잃으면 안 되는 변경을 덜 놓칩니다.

1. 충돌 파일:
2. git status에 나온 상태:
3. 남겨야 할 화면 또는 기능:
4. 가져온 변경에서 유지할 점:
5. 실행 확인 명령과 결과:

<<<<<<< HEAD가 보이면 파일 전체를 새로 만들라고 하지 마세요. 먼저 충돌 파일과 남길 의도를 적고, 표시를 제거한 뒤, 실행 확인과 git add까지 진행합니다. 코딩사관학교 초보자라면 오늘은 한 가지만 기억하면 됩니다. Git 충돌 해결은 코드 선택이 아니라 의도, 실행, 상태를 맞추는 과정입니다.

관련해서 원격에 밀어 올리는 단계에서 막혔다면 Git push 거절, force 전에 내 브랜치 차이를 확인하는 법을 먼저 보고, AI 수정 자체를 되돌려야 하는 상황이면 AI 수정이 더 망가질 때, 3분 만에 되돌리는 5줄 프롬프트를 이어서 확인하면 됩니다.

참고 출처

• Git Docs: git-merge: 충돌 뒤 파일 수정, git add, commit 또는 git merge --continue 흐름
• Git Docs: git-status: unmerged 경로와 상태 코드 확인
• Git Book: Basic Branching and Merging: 표준 충돌 marker와 수동 해결 예시
• GitHub Docs: Resolving a merge conflict using the command line: 양쪽 변경 선택·조합과 stage 절차
• GitHub Docs: Resolving merge conflicts after a Git rebase: rebase 충돌 뒤 continue 절차

이 글은 AI 코딩과 개발 학습의 일반 정보 제공 목적입니다. 도구, 모델, 커리큘럼, 요금은 버전과 시점에 따라 달라질 수 있으므로 실습이나 도입 전 공식 문서와 최신 릴리스 노트를 확인하세요.