문제 상황
- 팀 프로젝트 시작 전, 팀장으로서 기본 개발 환경과 코드 컨벤션을 합의·적용했으나 일부 팀원이 규칙을 지키지 않거나 공용 코드를 사용하지 않은 채 PR을 반복적으로 올림.
- 리뷰를 통한 수정 요청만으로는 개선이 충분히 이뤄지지 않음.
환경
- 프로젝트: 팀 프로젝트(다인 협업)
- 역할: 팀장(리드)
- 도구: Git/GitHub, PR 리뷰, 컨벤션 문서(ESLint/Prettier 등)
증상
PR에서 컨벤션 미준수, 공용 컴포넌트 미사용, 리뷰 피드백 미반영 건 반복 발생
원인 분석
- 규칙 전달만으로는 실천이 이어지지 않았고, 모호한 부분에 대한 질문 장려가 부족했음.
- 공용 코드 사용 이점과 구체 예시가 충분히 공유되지 않아 선택지 중 하나로만 인식됨.
- 리뷰 프로세스에서 "반드시 반영" 기준과 협업 원칙이 명시적으로 합의되지 않음.
해결 방법
- 원칙 재합의 회의 소집
- "규칙을 모르면 반드시 질문", "PR 후 리뷰 피드백 반영"을 협업 핵심 원칙으로 명문화.
- 실행 기준 구체화
- 공용 컴포넌트/유틸 사용 기준, 네이밍/디렉터리 구조, 커밋/PR 메시지 규칙을 예시와 함께 재정리.
- PR 템플릿·체크리스트 도입
- 변경 요약, 테스트 범위, 컨벤션 체크 항목을 PR 본문에 체크하도록 요구.
- 예시 중심 교육
- 미준수 코드 → 준수 코드로의 변환 예시를 직접 설명하고, 공용 코드 사용 전/후 차이를 시연.
- 리뷰 정책 명확화
- 차단적 리뷰(Required) 기준을 정의하고, 피드백 미반영 시 재요청 규칙 확립.
검증
- 이후 PR에서 컨벤션 미준수 건수 감소, 공용 코드 사용률 증가 확인.
- 리뷰 재요청 횟수와 수정 라운드 수가 줄고, 머지 리드타임이 단축됨.
배운 점
- 규칙은 "전달"이 아니라 "합의·이해·납득"의 과정이 선행되어야 실천으로 이어짐.
- 예시와 구체적 기준이 있을 때 팀은 더 빠르게 동일한 방향으로 정렬됨.
- 리더십은 원칙을 정리하고, 질문을 장려하며, 실행을 위한 프로세스를 설계하는 일.
참고
- 팀 컨벤션 문서, PR 템플릿, 코드 스타일 가이드(내부 위키)