충돌 표시를 지우면 끝일까? Git 2.56으로 배우는 안전한 병합

1. 충돌 해결의 마지막 단계에서 생기는 실수

팀원 두 명이 같은 파일의 같은 부분을 고치면 Git은 어느 변경을 남길지 자동으로 결정하지 못할 수 있습니다. 이때 파일 안에 충돌 표시가 생기고 개발자가 최종 내용을 선택합니다. 문제는 파일을 고친 다음입니다. 평소처럼 git add .을 실행하면 충돌을 해결한 파일뿐 아니라 작업 폴더에 있던 unrelated 변경까지 함께 스테이징될 수 있습니다. 커밋에 들어갈 파일을 다시 확인하지 않으면 디버깅용 출력이나 아직 끝나지 않은 작업이 섞일 수 있습니다.

Git 2.56 릴리스 노트에는 git add의 새 --resolved 옵션이 소개됐습니다. 공식 설명에 따르면 이 옵션은 충돌 상태였던 경로 가운데 해결된 경로를 스테이징하고, 관계없는 로컬 변경은 스테이징하지 않습니다. 남아 있는 충돌 표시도 검사해 발견하면 중단합니다. 이 기능 하나가 모든 충돌을 올바르게 해결해 주는 것은 아닙니다. 개발자가 선택한 최종 코드의 의미와 테스트 결과는 여전히 사람이 확인해야 합니다.

이번 글에서는 새 명령을 외우는 데서 그치지 않고 충돌을 하나의 상태 전이로 이해합니다. 충돌 발생, 내용 편집, 표시 제거, 스테이징, 테스트, 커밋의 각 단계에 확인 조건을 둡니다. 실습은 별도 가상 저장소에서 수행하는 제안이며 실제 프로젝트의 브랜치나 사용자 파일을 변경했다는 뜻이 아닙니다.

근거 자료 · Git 2.56 공식 릴리스 노트

2. 작업 폴더·스테이징 영역·커밋을 구분하자

Git을 처음 배울 때 파일이 저장되면 곧바로 커밋에 포함된다고 생각하기 쉽습니다. 실제로는 작업 폴더의 현재 파일, 다음 커밋 후보를 모아 둔 스테이징 영역, 이미 기록된 커밋이 서로 다른 상태입니다. 충돌을 해결해 파일을 저장해도 Git에는 아직 해결 완료로 표시되지 않습니다. 선택한 결과를 스테이징해야 다음 단계로 진행할 수 있습니다.

git status는 이 세 상태의 차이를 확인하는 기본 도구입니다. 충돌 중인 경로, 스테이징된 변경, 아직 스테이징하지 않은 변경을 나누어 보여 줍니다. 사람이 읽는 기본 출력은 버전이 바뀌면서 표현이 달라질 수 있으므로 프로그램이 분석할 때는 공식 문서가 설명하는 porcelain 형식을 사용하는 편이 적절합니다. 화면 문장을 문자열로 잘라 자동화하면 안내 문구 변경에 취약해질 수 있습니다.

실습 보고서에서는 명령 실행 전후의 상태를 표로 남겨 보세요. 파일 내용만 캡처하면 어떤 변경이 다음 커밋에 들어가는지 알기 어렵습니다. 상태를 기록할 때는 실제 개인 저장소 대신 가상 파일명을 사용하고, 접근 토큰이나 비밀 설정 파일의 내용을 출력하지 않습니다.

근거 자료 · Git 공식 문서 · git status

3. 충돌 표시는 오류 메시지가 아니라 경계선이다

일반적인 텍스트 충돌에는 현재 쪽, 구분선, 상대 쪽을 나타내는 표시가 들어갑니다. 개발자는 두 쪽 중 하나를 단순 선택할 수도 있고 두 변경을 합쳐 새로운 결과를 만들 수도 있습니다. 표시를 삭제했다고 논리적 충돌까지 해결된 것은 아닙니다. 예를 들어 한쪽은 함수 이름을 바꾸고 다른 쪽은 옛 이름을 호출하도록 기능을 추가했다면 문법상 깨끗해도 실행 중 오류가 날 수 있습니다.

Git 2.56의 --resolved는 남아 있는 충돌 표시를 찾아 실수로 스테이징하는 상황을 줄이려는 기능입니다. 하지만 문자열 안에 의도적으로 같은 모양의 문자가 있거나, 표시를 없앤 뒤 잘못된 코드를 선택한 경우까지 의미적으로 판단하는 AI 검토기는 아닙니다. 명령이 성공했다는 사실과 프로그램이 올바르다는 결론을 분리해야 합니다.

아래 흐름은 교육용 절차 예시입니다. 새 옵션을 사용할 수 있는 Git 버전인지 먼저 확인하고, 지원되지 않는 환경에서는 해결한 경로를 명시적으로 git add한 뒤 상태를 확인합니다. 어느 방법이든 전체 파일을 무심코 추가하지 않고 대상 경로를 검토하는 습관이 핵심입니다.

교육용 충돌 해결 흐름
1. git status로 충돌 경로 확인
2. 파일을 열어 두 변경의 의도 비교
3. 최종 내용 편집 후 충돌 표시 검색
4. 지원 환경: git add --resolved
5. git diff --cached로 다음 커밋 내용 확인
6. 테스트 실행 후 커밋

4. 두 브랜치로 재현 가능한 실습 만들기

가상 저장소에 price.py 파일을 만들고 main 브랜치에서는 할인율 검증을 추가합니다. 별도 feature 브랜치에서는 같은 줄에 회원 등급별 할인을 추가합니다. 두 브랜치를 병합해 충돌을 재현한 다음, 두 요구사항을 모두 만족하는 함수로 고칩니다. 여기에 notes.txt를 별도로 수정해 두면 충돌 해결 경로와 관계없는 변경이 스테이징되지 않는지 관찰할 수 있습니다.

실습 데이터는 정상 가격, 음수 가격, 알려지지 않은 등급을 포함하도록 제안합니다. expected.json에 입력과 기대 결과를 적고 Python 테스트가 구현 결과와 비교하도록 만들 수 있습니다. 수치는 학습용 예시이며 실제 쇼핑몰 정책이나 측정 결과가 아닙니다. 요구사항이 모호하다면 코드를 합치기 전에 할인 적용 순서와 오류 처리 규칙을 팀이 먼저 합의해야 합니다.

각 팀은 명령을 실행하기 전에 예상 상태를 써 보고 실제 git status와 비교하세요. notes.txt가 스테이징되었다면 어떤 명령 때문에 포함됐는지 기록합니다. 결과 커밋만 제출하면 과정의 오류를 찾기 어렵기 때문에 상태 전환표와 테스트 실패 한 건 이상을 함께 남기는 것이 좋습니다.

5. 반복되는 충돌은 rerere로 학습시킬 수 있다

같은 장기 브랜치를 여러 번 재배치하면 비슷한 충돌을 반복해 해결할 수 있습니다. Git의 rerere는 이전에 사람이 해결한 충돌의 모양과 해결 결과를 기록해 비슷한 상황에서 재사용할 수 있게 합니다. 공식 문서는 recorded resolution을 다시 사용하는 기능으로 설명합니다. 이것은 원격 AI 서비스가 코드를 학습한다는 뜻이 아니라 로컬 저장소의 충돌 해결 기록을 활용하는 Git 기능입니다.

rerere가 제안한 결과도 현재 요구사항에 맞는지 검토해야 합니다. 과거에는 맞았던 해결이 새 정책에서는 틀릴 수 있기 때문입니다. 자동으로 적용된 파일을 곧바로 커밋하기보다 diff와 테스트를 통과시키는 절차를 유지하세요. 기록을 지우거나 상태를 변경하는 명령은 실습 저장소에서만 시험하고 각 명령의 영향을 공식 문서에서 확인합니다.

학습 과제로 같은 충돌을 두 번 재현하고 두 번째 해결에 어떤 차이가 생기는지 관찰할 수 있습니다. 시간 절감만 측정하지 말고 최종 파일의 해시, 테스트 결과, 스테이징된 경로가 첫 번째와 같은지도 확인하세요. 편리한 자동화일수록 결과 검증 조건을 명확히 두어야 합니다.

근거 자료 · Git 공식 문서 · git rerere

6. AI에게 충돌 해결을 맡길 때 필요한 경계

AI 도구는 두 변경의 차이를 설명하거나 테스트 후보를 제안하는 데 도움을 줄 수 있습니다. 입력에는 충돌 구간뿐 아니라 함수 계약, 호출하는 코드, 실패한 테스트가 필요합니다. 일부 줄만 보여 주고 양쪽 의도를 추측하게 하면 자연스러운 코드가 나와도 요구사항을 놓칠 수 있습니다. 비밀키와 운영 데이터가 포함된 설정 파일은 외부 모델 입력에서 제외해야 합니다.

AI가 만든 해결안을 평가할 때는 충돌 표시 제거 여부, 컴파일 또는 문법 검사, 기존 테스트, 새 요구사항 테스트를 차례로 확인합니다. 단순히 병합이 끝났다는 메시지만으로 성공 처리하지 않습니다. 테스트가 부족하면 양쪽 브랜치에서 추가된 행동을 각각 하나 이상 검증하는 사례를 먼저 작성하도록 제안합니다.

Java 프로젝트라면 컴파일과 단위 테스트, Python 프로젝트라면 정적 검사와 테스트를 실행할 수 있습니다. SQL 변경이 함께 있다면 스키마 마이그레이션 순서와 이전 데이터 호환성을 별도로 확인합니다. 클라우드 배포는 병합 검증이 끝난 커밋에서 실행하고, 자동화 계정이 작업 폴더의 임의 변경을 함께 커밋하지 않도록 깨끗한 체크아웃을 사용합니다.

7. 평가는 빠른 병합보다 설명 가능한 병합

팀 프로젝트 결과물은 충돌 전 두 브랜치의 요구사항, 충돌이 난 이유, 선택한 최종 동작, 상태 변화, 테스트 결과를 포함하도록 제안합니다. 해결 시간은 참고 지표일 뿐입니다. 빠르게 합쳤지만 다른 작업 파일이 섞였거나 한쪽 기능이 사라졌다면 좋은 결과가 아닙니다. 반대로 시간이 더 걸려도 실패 사례를 발견하고 재현했다면 중요한 학습이 됩니다.

평가 기준은 의도하지 않은 스테이징 경로 수, 남은 충돌 표시 수, 양쪽 요구사항을 검증하는 테스트 통과 수, 같은 절차를 다른 팀원이 재현했을 때의 결과 일치 여부로 구성할 수 있습니다. 작은 실습에서 모두 통과했다고 실제 대규모 저장소의 모든 병합이 안전하다고 일반화하지 않습니다. 바이너리 파일이나 대규모 이름 변경은 별도 전략이 필요할 수 있습니다.

Git 2.56의 새 옵션이 주는 핵심 교훈은 명령 하나보다 범위를 좁히는 습관입니다. 충돌을 해결한 파일, 다음 커밋에 들어갈 변경, 테스트할 행동을 각각 명시하면 사람이 하든 AI가 돕든 검토 가능한 작업이 됩니다. 협업에서 좋은 병합은 충돌 표시가 사라진 상태가 아니라, 왜 그 결과가 맞는지 다른 사람이 확인할 수 있는 상태입니다.