머지 충돌 근본 원인 분석 수행하기

머지 충돌은 Git 문제가 아니라 워크플로 신호다

머지 충돌을 우연한 마찰로 취급하는 팀은 중요한 신호를 놓칩니다. 반복 충돌은 워크플로 문제의 지도입니다. 너무 큰 PR, 불명확한 소유권, god file, 진행 중인 리팩터 같은 것들 말입니다. GitHub의 개발 생산성 연구와 The Pragmatic Engineer의 엔지니어링 효과성 글는 최근 30일 충돌 인벤토리를 만들면 대개 충돌 대부분을 만들어내는 특정 모듈 2~3개나 워크플로 패턴이 드러난다고 말합니다.

머지 충돌 근본 원인 분석 수행하기 프롬프트가 작동하는 방식

이 프롬프트는 최근 30일의 충돌을 인벤토리화하고, 가장 많이 충돌하는 파일 3개와 PR 쌍을 찾는 패턴 분석을 수행한 뒤, 다섯 가지 원인 분류와 거기에 맞는 개입안을 연결합니다. 마지막으로 이번 스프린트에 바로 실행할 조치 하나를 고릅니다. 핵심은 "소통이 부족하다" 같은 추상적 설명이 아니라, 특정 모듈과 PR 쌍을 지목한다는 점입니다.

사용 시점

• 머지 충돌이 엔지니어당 주 2시간 이상을 잡아먹고 있습니다.
• 특정 모듈이 자주 충돌의 중심에 있습니다.
• 두 팀이 같은 영역을 두고 서로를 탓하고 있습니다.
• 새 EM이 개발 생산성 기준선을 만들고 싶어 합니다.
• 큰 리팩터가 진행 중이며 충돌률이 급증하고 있습니다.

흔한 함정

• "소통" 탓하기. "소통을 더 잘해야 한다"는 회고의 가장 싱거운 결론입니다. 데이터는 구체적 모듈을 가리킵니다.
• 증상만 고치기. 머지 봇을 추가하면 해결 시간은 줄일 수 있어도, PR 크기나 소유권 문제는 그대로입니다.
• 사후 측정 없음. 개입 후 다시 재측정하지 않으면 아무것도 증명되지 않습니다. 30일 뒤 다시 측정하세요.

출처

• GitHub Developer Research — GitHub
• The Pragmatic Engineer — Gergely Orosz
• The Pragmatic Engineer Newsletter — Gergely Orosz
• The Linear Method — Linear