긴급 사태

가끔은 전체 코드 리뷰 절차를 최대한 빨리 통과해야 하는 긴급한 CL이 있습니다.

긴급 사태가 뭔가요?

긴급한 CL은 다음 중 하나를 포함한 작은 수정입니다:

• 주요 출시를 롤백하지 않고 계속 진행하게 합니다.
• 제품 사용자에게 큰 영향을 주는 버그를 수정합니다.
• 긴급한 법적 이슈를 다룹니다.
• 주요 보안 취약점을 해결합니다.
• 등등.

긴급 사태에서 우리는 응답 속도뿐만 아니라 전체 코드 리뷰 절차의 속도에 대해서 아주 신경써야 합니다. 이 경우에만, 리뷰어는 다른 것보다 리뷰 속도와 (정말로 긴급 사태를 해결하는지) 코드의 정확함에 신경 써야 합니다. 또, 이런 리뷰는 다른 모든 코드 리뷰보다 우선순위를 높게 가져야 합니다.

하지만, 긴급 사태가 해결되고 나면, 긴급 CL들을 다시 살펴보고 더 철저한 리뷰를 해야 합니다.

긴급 사태가 아닌 것은 뭔가요?

분명히 말해 다음과 같은 경우는 긴급 사태가 아닙니다:

• (동업자 계약과 같은 정말 빡센 마감이 있지 않다면) 다음 주가 아니라 이번주에 출시하고 싶은 경우.
• 아주 긴 시간 동안 기능을 개발해 왔고 정말 그 CL을 반영하고 싶은 경우.
• 리뷰어가 전부 다른 시간대에 있어서 지금 밤이거나 퇴근한 경우.
• 금요일 퇴근 시간이 다 되어가서 주말에 개발자가 부재하기 전에 그냥 이 CL을 반영하는게 좋아 보이는 경우.
• 매니저가 유연한 (빡세지 않은) 마감때문에 이 리뷰는 반드시 완료되어야 하고 CL은 오늘 검토되어야 한다고 말하는 경우.
• 테스트가 실패하거나 빌드를 깨는 CL을 롤백하는 경우.
• 등등.

빡센 마감은 뭔가요?

못지키면 뭔가 엄청난 참사가 일어날 수 있는 것을 빡센 마감이라고 합니다. 예를 들면:

• 특정 날짜까지 CL을 제출하도록 계약상 의무에 명시된 경우.
• 특정 날짜까지 배포하지 않으면 제품이 시장에서 완전히 실패할 경우.
• 어떤 하드웨어 제조사가 1년에 한번만 새로운 하드웨어에 (코드를) 싣는 경우. 만약 여기에 코드를 제출하는 것을 놓치면, 어떤 코드를 실을려는지에 따라 대참사가 일어날 수 있습니다.

일주일 정도 배포를 연기하는 일은 끔찍한 일이 아닙니다. 중요한 미팅을 놓치는 것은 참사일 순 있는데, 보통은 아닙니다.

대부분의 마감은 빡세지 않고 유연합니다. 보통은 특정 시간까지 기능이 완료되길 원하는 바람을 나타냅니다. 물론 이것도 중요하지만, 건강한 코드를 희생할 만큼은 아닙니다.

만약 배포 일정이 여러 주에 걸칠 정도로 아주 길다면, 다음 일정이 되기 전에 코드 리뷰 품질을 희생하면서 기능을 넣고 싶은 유혹에 빠질 수 있습니다. 하지만, 이런 일이 반복된다면, 프로젝트가 대응하기 힘든 기술적 빚에 시달리게 되는 것은 흔한 일입니다. 개발자가 피상적인 리뷰만 받고 “반드시 포함되어야 한다”고 일정이 거의 끝나갈 때 CL을 올리는 일이 일상이 되었다면, 팀 전체의 절차를 수정해서 큰 기능은 일정 초반에 반영해서 좋은 리뷰를 충분히 할 수 있도록 해야 합니다.