Accept Current와 Incoming 차이, Git 충돌에서 누르기 전 볼 것

Git을 쓰다가 파일 안에 <<<<<<<, =======, >>>>>>> 표시가 갑자기 생기면 초보자는 코드가 망가졌다고 느낍니다. 하지만 이 표시는 Git이 자동으로 고르지 못한 두 버전을 보여 주는 신호입니다. 바로 AI에게 "고쳐줘"라고 파일 전체를 던지기보다, 먼저 어느 줄이 내 변경이고 어느 줄이 들어온 변경인지 나눠야 합니다.

오늘 목표는 충돌을 멋지게 설명하는 것이 아닙니다. 충돌 구간을 읽고, 남길 줄과 버릴 줄을 판단할 자료를 모은 뒤, AI에게 한 번에 하나의 안전한 결정을 요청하는 것입니다.

Tap to zoom

git-scm.com의 Git 공식 문서는 merge가 자동으로 합치지 못한 부분에 conflict marker를 남긴다고 설명합니다. docs.github.com의 GitHub 문서도 명령줄에서 충돌 파일을 열고, <<<<<<< HEAD, =======, >>>>>>> branch-name 사이의 차이를 고친 뒤 다시 add와 commit을 진행한다고 안내합니다. 그러므로 이 문제의 첫 행동은 전체 파일 재작성 요청이 아니라 충돌 표시의 세 구역을 보존한 채 읽는 것입니다.

먼저 HEAD와 들어온 변경을 같은 화면에서 분리합니다

충돌 파일은 보통 이런 모양입니다.

<<<<<<< HEAD
return <button onClick={saveDraft}>저장</button>;
=======
return <button onClick={submitForm}>제출</button>;
>>>>>>> feature/form-submit

<<<<<<< HEAD 아래는 현재 체크아웃한 브랜치 쪽 변경입니다. ======= 아래부터 >>>>>>> feature/form-submit 전까지는 병합하려는 다른 브랜치 쪽 변경입니다. 둘 중 하나만 항상 맞는 것은 아닙니다. 버튼 문구는 저장이 맞고 함수는 submitForm이 맞을 수도 있습니다.

그래서 처음 30초에는 아래 네 줄을 메모합니다.

1. 충돌 파일: app/components/FormButton.tsx
2. 현재 쪽 의도: 임시 저장 버튼을 유지하려고 함
3. 들어온 쪽 의도: 제출 핸들러로 폼 전송을 연결하려고 함
4. 최종 목적: 저장 버튼인지 제출 버튼인지 화면 역할에 맞춰 결정

이 네 줄 없이 AI에게 파일만 붙이면 AI는 문맥을 추측합니다. 초보자에게 위험한 지점은 여기입니다. 충돌 해결은 예쁜 코드 만들기가 아니라 두 변경의 의도를 잃지 않는 선택입니다.

충돌 전에 작업을 잠시 치워야 한다면 AI 수정 전 git stash로 변경을 보관하는 순서를 먼저 확인해도 좋습니다.

Accept Current와 Accept Incoming은 뜻을 알고 눌러야 합니다

에디터는 보통 Accept Current Change, Accept Incoming Change, Accept Both Changes 같은 버튼을 보여 줍니다. 버튼 이름은 편하지만, 뜻을 모르면 한쪽 작업을 조용히 버릴 수 있습니다.

여기서 바로 양쪽 모두를 남기는 것도 답이 아닐 수 있습니다. 같은 함수를 두 번 호출하거나 같은 UI를 중복 렌더링할 수 있기 때문입니다. 버튼을 누르기 전에는 화면 역할과 데이터 흐름을 먼저 말로 적습니다.

Tap to zoom

AI에게는 충돌 구간과 최종 의도를 같이 줍니다

AI에게 물을 때는 전체 저장소를 맡기지 말고 충돌 구간부터 줍니다. 비밀 키, 고객 정보, 개인 토큰이 들어간 파일은 그대로 붙이지 않습니다. 필요한 부분만 잘라서 이렇게 요청합니다.

Git merge conflict가 났습니다.

파일: app/components/FormButton.tsx
현재 화면 목적: 사용자가 글을 임시 저장하거나 제출할 수 있어야 합니다.
충돌 구간:

<<<<<<< HEAD
return <button onClick={saveDraft}>저장</button>;
=======
return <button onClick={submitForm}>제출</button>;
>>>>>>> feature/form-submit

요청:
1. Current와 Incoming이 각각 무엇을 보존하려는지 설명해 주세요.
2. 둘 중 하나를 통째로 고르지 말고, 최종 목적에 맞는 최소 코드를 제안해 주세요.
3. 수정 뒤 확인할 테스트나 수동 확인 명령을 하나만 제안해 주세요.

이 프롬프트의 핵심은 "최소 코드"와 "확인 명령 하나"입니다. help.openai.com의 OpenAI 프롬프트 작성 안내도 원하는 맥락, 결과 형식, 제약을 구체적으로 주라고 설명합니다. Git 충돌 질문도 같습니다. AI에게 결정을 맡기더라도 판단 기준은 사람이 먼저 좁혀야 합니다.

Tap to zoom

충돌 표시를 지운 뒤에는 Git 상태와 실행 확인을 같이 봅니다

충돌을 고치면 파일 안에 <<<<<<<, =======, >>>>>>>가 남아 있으면 안 됩니다. 먼저 검색합니다.

원격 반영 단계에서 push가 거절된다면 충돌 해결과 강제 덮어쓰기를 섞지 말고 Git push rejected에서 원격 변경부터 확인하는 순서로 이어가세요.

rg "<<<<<<<|=======|>>>>>>>" app src

그다음 Git 상태를 봅니다.

git status

충돌이 해결된 파일을 확인한 뒤 stage합니다.

git add app/components/FormButton.tsx

여기서 바로 commit하기 전에 프로젝트 확인 명령을 하나 돌립니다. React나 Next.js 프로젝트라면 보통 아래 중 하나입니다.

npm run lint
npm run typecheck
npm run build

수업용 작은 프로젝트라면 화면에서 버튼을 눌러 보는 수동 확인도 필요합니다. 충돌 해결은 Git 표시를 없애는 것으로 끝나지 않습니다. 원래 두 변경이 지키려던 동작이 살아 있는지 봐야 끝입니다.

다시 충돌이 나면 같은 질문을 반복하지 않습니다

충돌을 한 번 고친 뒤 또 막히면 "아직 안 돼요"라고 묻지 않습니다. 이번에는 새로 남은 충돌 파일명, 방금 선택한 이유, 실행한 확인 명령, 새 오류를 같이 줍니다.

방금 FormButton.tsx 충돌은 저장과 제출 버튼을 둘 다 보존하는 방향으로 고쳤습니다.
git status에서 아직 app/page.tsx가 unmerged로 남아 있습니다.
npm run typecheck는 아직 실행 전입니다.
다음 충돌 구간을 같은 기준으로 읽어 주세요.

이렇게 쓰면 AI가 앞선 결정을 기억한 상태로 다음 파일을 봅니다. 반대로 매번 "merge conflict 고쳐줘"만 반복하면 파일마다 기준이 흔들립니다.

오늘 충돌 표시를 만났다면 먼저 세 구역을 나누고, Current와 Incoming의 의도를 말로 적고, AI에게 최소 수정과 확인 명령 하나만 요청하세요. 그 다음 충돌 표시 검색, git status, 실행 확인까지 끝내면 코드와 Git 기록을 함께 지킬 수 있습니다.

참고 출처

• Git Documentation, Basic Merge Conflicts: https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts
• GitHub Docs, Resolving a merge conflict using the command line: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line
• GitHub Docs, About merge conflicts: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/about-merge-conflicts
• OpenAI Help Center, Best practices for prompt engineering with the OpenAI API: https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api

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