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

Description

팀이 매주 머지 충돌 해결에 몇 시간을 쓰고 있고, 모두가 다른 팀 탓을 하고 있습니다. 이 프롬프트는 최근 30일의 충돌을 구조적으로 분석해, 그 충돌을 만들어내는 코드 영역 2~3곳과 워크플로 패턴을 찾아내고 보통 더 작은 스토리와 더 명확한 소유권 경계 같은 해결책까지 도출합니다.

{{team_or_repo}}에서 발생하는 머지 충돌을 조사하는 개발 생산성 분석가라고 생각하세요. 최근 30일의 머지 충돌 데이터를 가져오세요.

## 1단계 — 충돌 인벤토리
최근 30일의 각 충돌마다:
| 충돌 | 변경된 파일 | 관련 PR | 해결 시간 | 해결 책임자 |

## 2단계 — 패턴 분석
- 전체 충돌의 50% 이상을 차지하는 파일/모듈 3개는 무엇인가요?
- 반복적으로 충돌하는 PR 쌍은 무엇인가요(같은 팀, 다른 팀 포함)?
- 충돌이 발생한 PR의 중간 나이는 얼마인가요?
- 충돌 해결 시간의 p90은 얼마인가요?

## 3단계 — 근본 원인 가설
반복 충돌을 다음으로 분류하세요:
- 너무 큰 PR(작은 스토리로 쪼개면 표면적 감소)
- 불명확한 소유권(두 팀이 같은 영역을 수정)
- 진행 중인 리팩터(반쯤 파일을 점유한 상태)
- 약한 모듈성("god file" 문제)
- 브랜치 전략(장수 브랜치)

## 4단계 — 개입안
각 원인 분류별로:
- 작은 스토리: WIP 제한, PR 크기 상한
- 불명확한 소유권: CODEOWNERS 파일, 모듈 경계
- 진행 중인 리팩터: 리팩터를 먼저 머지해 모두를 unblock
- God file: 별도 아키텍처 리팩터 일정 수립
- 장수 브랜치: trunk-based development

## 5단계 — 출력
1. 충돌 인벤토리 요약
2. 근거가 있는 근본 원인 2~3개
3. 예상 감소율과 함께 우선순위화한 개입안
4. 이번 스프린트에 바로 실행할 개입안 하나

Customize This Prompt