배포 파이프라인, 사람이 누르는 단계를 남겨 두기

단계를 나누는 기준은 실패 지점입니다

파이프라인을 설계할 때 단계를 기능으로 나누면 쓸모가 적습니다. 실패가 드러나는 지점으로 나눠야 합니다. 빌드 단계는 코드가 컴파일되고 묶이는지 확인합니다. 시험 단계는 동작이 깨지지 않았는지 확인합니다. 승인 단계는 사람이 판단할 내용을 확인합니다. 배포 단계는 실제 적용입니다. 이렇게 나누면 실패했을 때 어느 단계에서 멈췄는지만 보고 원인 범위를 알 수 있습니다. 반대로 빌드와 시험과 배포를 한 단계에 묶으면 실패 로그를 전부 읽어야 합니다. 그래서 단계 수는 적게 두되, 실패 성격이 다른 작업은 반드시 나눕니다.

사람이 누르는 단계를 남기는 이유

모든 단계를 자동화하면 빠르지만, 판단이 필요한 지점이 사라집니다. 승인 단계를 남겨야 하는 경우는 세 가지입니다. 첫째, 되돌리기 어려운 변경이 포함된 배포입니다. 둘째, 외부에 영향을 주는 변경입니다. 셋째, 트래픽이 많은 시간대를 피해야 하는 배포입니다. 반대로 작은 수정이 대부분인 서비스에서는 승인 단계가 병목이 됩니다. 그래서 승인을 모든 배포에 걸지 않고 조건으로 나눕니다. 변경 범위가 특정 영역을 건드릴 때만 승인을 요구하도록 두면, 대부분의 배포는 자동으로 흐르고 위험한 배포만 사람이 봅니다.

리드타임을 단계별로 나눠 봅니다

학습용 가정으로 계산합니다. 가정값은 빌드 6분, 시험 10분, 승인 대기 30분, 배포 8분이라고 두겠습니다. 전체 리드타임은 54분입니다. 승인 대기를 제외한 기계 작업은 24분입니다. 중간 계산값으로 승인 대기가 전체의 약 56퍼센트를 차지합니다. 최종 판단은 이 비중으로 합니다. 기계 작업을 아무리 줄여도 승인 대기가 절반을 넘으면 체감 속도는 거의 변하지 않습니다. 그래서 개선 순서는 승인 조건을 좁히는 것이 먼저이고, 그다음이 시험 시간 단축입니다. 단계별 시간을 기록해 두지 않으면 이 순서를 알 수 없습니다.

시험이 믿을 수 없으면 승인이 늘어납니다

결론을 뒤집는 조건은 시험의 신뢰도입니다. 시험이 통과해도 운영에서 문제가 자주 생기면 사람들은 승인 단계를 더 요구하게 되고, 결국 파이프라인이 느려집니다. 그래서 승인을 줄이려면 시험을 먼저 보강해야 합니다. 보강 방향은 두 가지입니다. 과거에 운영에서 터진 문제를 시험 항목으로 추가하는 것과, 간헐적으로 실패하는 불안정한 시험을 고치는 것입니다. 불안정한 시험이 많으면 실패를 무시하는 습관이 생겨 시험 자체가 무력화됩니다. 그래서 파이프라인 지표에는 시험 실패 중 재실행으로 통과한 비율을 함께 기록합니다.

서버 운영 실행 전 점검표

• 실패 성격이 다른 작업을 별도 단계로 나눴다
• 승인을 조건으로 한정해 위험한 배포에만 걸었다
• 단계별 소요 시간을 기록해 비중을 계산했다
• 불안정한 시험과 재실행 통과 비율을 추적한다