Git 충돌(Conflict) 시 JetBrains AI Assistant의 자동 병합 기능 사용 후기

git에서 컨플리크트가 발생했을 때 어려운 점은 '어느 쪽이 맞는가'가 아니라 '둘 다 맞는' 경우입니다.

예를 들어,

• main 브랜치: register()에 유효성 검사(이메일 형식, 비밀번호 길이 체크) 추가 -
  feature-logging 브랜치: 동일한 register()에 로그 출력 추가

둘 다 올바른 변경 사항이며, 본래는 두 가지 모두 통합하고 싶습니다. 수동으로 두 개의 변경 사항을 읽고 조합하여 수정해야 합니다. 변경할 부분이 많아지면 시간이 걸릴 뿐만 아니라, 놓칠 위험도 높아집니다.

이번에는 IntelliJ IDEA AI Assistant의 'AI를 사용하여 Git 충돌 해결하기' 기능이 있어 실제로 두 가지 시나리오로 테스트해 보았습니다.

제품: IntelliJ IDEA 2026.1.2 / AI Assistant 플러그인 활성화

3개의 페인 구성

페인	내용
왼쪽	HEAD (현재 브랜치)의 변경
...

먼저 '양립할 수 없는' 케이스로 동작을 확인했습니다.

동일한 fetchUser() 메서드를 두 개의 브랜치에서 각각 다르게 수정한 상태입니다.

// 공통 조상
public User fetchUser(String id) {
return users.get(id);
...

main은 캐시를 포함하여 nullable을 반환하는 설계, feature-logging은 찾지 못하면 예외를 던지는 non-null 설계입니다. 반환 타입이 바뀔 정도로 본질적으로 다른 변경이기 때문에 둘 다 통합할 수는 없습니다.

'AI를 사용하여 병합하기(Merge)'를 클릭하자 중앙 페인에 main 측 (캐시 포함) 구현이 채택되었습니다. 채택된 줄은 왼쪽, 중앙, 오른쪽 페인을 가로지르는 선으로 표시되어 어느 페인의 변경 사항이 중앙에 통합되었는지 시각적으로 알 수 있었습니다.

확인한 점

• AI는 main 측을 채택했습니다.
• 적용(Apply)하기 전에 수동으로 편집할 수 있습니다.
• 채택되지 않은 오른쪽 페인의 변경 사항은 그대로 남아 참조할 수 있습니다.

아쉬운 점

• 캐시 쪽을 선택했다는 설명이 없었습니다.

다음으로 '두 가지 모두 통합 가능한' 케이스입니다.

// 공통 조상
public User register(String email, String password) {
User user = new User(UUID.randomUUID().toString(), email, password);
...

변경 부분이 독립적이기 때문에 (함수 시작 부분에 유효성 검사 vs 함수 시작 및 끝에 로그), 이론적으로는 두 가지 모두 통합된 결과가 존재합니다.

페인	내용 개요
왼쪽 (main)	if 유효성 검사 2줄 → User 생성 → database.save → return
중앙 (AI 결과)	if 유효성 검사 2줄 → logger.info → User 생성 → database.save → logger.info → return → （공통 블록 중복）
오른쪽 (feature-logging)	logger.info → User 생성 → database.save → logger.info → return

AI는 main의 유효성 검사 2줄과 feature-logging의 감사 로그를 모두 통합했습니다. 다만, 충돌 범위 외의 공통 블록(User 생성 → save → return)이 끝부분에 중복으로 삽입되었습니다. 시나리오 1은 '둘 중 하나', 시나리오 2는 '모두 통합'입니다.

AI를 사용하지 않고 수동으로 해결하려고 하면,

<<<<<<< HEAD
public User register(String email, String password) {
if (!email.contains("@")) {
...

git은 '같은 함수가 변경되었다'는 것을 제시합니다.

개발자는:

• 마커를 읽고 두 변경 사항의 의도를 파악합니다.
• '유효성 검사는 로그보다 앞에 위치해야 한다'고 판단합니다.
• '시작 로그는 유효성 검사 후, 완료 로그는 save 후'라는 순서를 확인합니다.
• 수동으로 조합하여 다시 작성합니다.
• 마커 줄을 삭제하고 커밋합니다.

이번 사례는 변경된 행수가 적어 해석하기 어렵지 않지만, 실제 코드에서 유사한 상황이 발생하면 "유효성 검사 (Validation) 위치가 어긋나지 않았는지", "로그가 누락되지 않았는지"를 주의 깊게 확인해야 한다. 변경량이 늘어날수록 간과할 위험도 높아진다.

좋았던 점

• "양쪽의 변경 사항을 통합할 수 있는지"를 AI가 판단하여 자동으로 수행해 준다.
• 중앙 페인 (Central Pane)에서 AI의 판단을 수동으로 수정한 후 적용 (Apply)할 수 있다. 완전히 맡겨두기만 하는 방식이 아니다.

불편했던 점

• 채택 이유에 대한 설명이 없음. "왜 이것을 선택했는지", "어떤 순서로 배치했는지"가 보이지 않으면, 더 복잡한 충돌 (Conflict) 상황에서 불안함이 남는다.
• AI의 출력에 대한 수동 확인이 필요함. 검증 과정에서 통합의 방향성은 올바르지만, 충돌 범위 외의 공통 블록이 중복 삽입되어 컴파일 에러 (Compile Error)가 발생하는 케이스가 있었다. 적용 (Apply) 전에 중앙 페인을 확인해야 한다.

공식 문서에는 "AI Assistant는 충돌하지 않는 변경 사항과 충돌하는 변경 사항을 모두 병합 (Merge)합니다"라고 적혀 있다. 이번 테스트를 통해 실제로 확인할 수 있었다.

AI는 "양쪽의 변경 사항을 통합할 여지가 있는지"를 판단하고 있다. 여지가 있으면 통합하고, 없으면 한쪽을 선택하는 동작을 확인했다.

도움이 될 만한 상황은, 변경 위치는 독립적임에도 git이 동일한 함수 내의 변경으로 감지하는 충돌 상황이다. 유효성 검사 추가와 로그 추가, 예외 처리 (Exception Handling) 추가와 메트릭 (Metrics) 기록 등, 책임이 서로 다른 변경 사항이 동일한 메서드 (Method)에 들어간 경우에 시간을 절약할 수 있다.

저희 회사는 JetBrains 제품에 관한 질문이나 상담 등을 받고 있습니다. 저희의 X 또는 이메일로 연락해 주시기 바랍니다.