1. 코드 리뷰 시간 확보 및 규칙 정하기

이전에는 “코드 리뷰를 해야 한다”는 공감대는 있었지만, 언제, 어떤 기준으로, 어떻게 리뷰할지에 대한 합의는 다소 느슨했습니다.

이번 팀에서는 • 작은 PR 단위를 지향하고, • 커밋 메시지 컨벤션을 맞추고, • GitHub의 코드 리뷰를 필수 흐름으로 가져가면서

“PR → 리뷰 → 머지” 라는 기본 사이클을 팀의 리듬으로 정착시키려 했습니다.

완전히 이상적인 모습은 아니었지만,

• 리뷰를 염두에 두고 작업 단위를 나누게 된 점,
• 코드 스타일이 아니라 도메인 관점에서 질문이 오가는 리뷰가 늘어난 점에서

이전보다 확실히 목표에 가까워졌다고 느꼈습니다.

다만,

• 정해둔 PR 타임라인을 정확히 지키지 못한 순간들이 있었고,
• 리뷰가 밀리면서 뒤에 있는 작업이 연쇄적으로 밀리는 경우도 있었습니다.

그래서 다음 단계에서는

• “PR은 최대 어느 정도 크기까지 허용할지”
• “리뷰는 어느 정도 시간 안에 보는 걸 기본으로 할지”

와 같이 좀 더 구체적인 규칙에 대한 합의까지 가져가 보고 싶습니다.

체크

• ✅ 코드 리뷰 “문화”와 “기본 흐름”은 자리 잡았다.
• 🟡 리뷰 타이밍/규칙은 한 번 더 구체화할 여지가 있다.

2. 논의 주제에서의 본질을 벗어나지 않기

(실험: 논의 시간 타임박스 정해서 진행해보기)