병합 충돌(Merge conflicts)은 협업 소프트웨어 개발에서 반복적으로 발생하는 비용이며, 이를 처리하는 기존의 구조화 및 반구조화된 병합 도구들은 빈번하게 작업을 포기합니다. 즉, 도구의 휴리스틱(heuristics)이 적용되지 않을 때 충돌을 해결하지 않은 채 남겨둡니다. 반면 대규모 언어 모델(LLMs)은 거의 모든 충돌에 대해 후보 해결책을 생성할 수 있지만, 이러한 해결책이 실제로 대규모 환경에서 좋은지 측정하는 것은 어렵습니다. 왜냐하면 모든 모델 출력에 대해 인간의 선호도 판단을 얻는 것은 확장성이 떨어지기 때문입니다. 우리는 ConflictBench의 실제 Java 병합 충돌을 통해 이 두 가지 문제를 함께 연구합니다. 먼저, 우리는 추론 시 신호(충돌 마커, Java 파서, 중복 선언 확인)만을 사용하며 개발자의 정답을 전혀 보지 않는 '생성-검증-재시도(generate-validate-retry)' 에이전트로서의 LLM 솔버를 구축합니다. 그런 다음 두 가지 지표 세트로 해결책을 평가합니다: (1) G-Eval 지표로 구현되었으며, 결정적으로 사용 전 ConflictBench의 인간 레이블에 대해 보정(calibrated)된 개발자 일치형 LLM-as-judge, 그리고 (2) LLM을 사용하지 않는 결정론적 구조적 타당성(structural-validity) 검사입니다. 292개의 인간 레이블 사례에 대한 메타 평가 결과, 해당 judge는 64.6%의 재현율(recall)에서 100% 정밀도(precision, 오탐 수락 0건)에 도달하였으므로, 모든 수락 결과는 신뢰할 수 있으며 모든 후속 비율은 보수적인 하한선이 됩니다. 이 검증된 judge 하에서, LLM 솔버는 실제 충돌의 약 55%에서 개발자 자신의 해결책과 일치합니다(보수적인 하한선). 또한 커버리지 공정 비교(coverage-fair comparison) 하에서 LLM(55-59%)은 가장 강력한 전통적 도구인 AutoMerge(36.7%)를 약 18-22포인트 차이로 앞섭니다. 이러한 우위는 순수 정확도가 아닌 거의 전적으로 커버리지에서 비롯되는데, 이는 기존 도구들이 충돌의 20-90%에 대해 작업을 포기하는 반면, 강제 해결(forced resolution) 모드의 LLM은 하나도 포기하지 않기 때문입니다. 마지막으로, LLM judge는 결정론적 구조 검사를 통과하지 못한 5개의 해결책 중 4개를 수락하였으며, 이는 구조적 정확성(structural correctness)을 LLM에 위임해서는 안 된다는 증거입니다.