Breeze 정기 배포의 검증 단계와 일정 조율

Breeze는 주문·결제와 외부 연동, 운영 도구가 연결된 커머스 플랫폼이었습니다. 각 서비스의 코드가 준비돼도 배포를 바로 끝낼 수는 없었습니다. 함께 바뀌는 서비스와 검증 상태를 확인하고, 트래픽이 몰리는 이벤트 일정도 고려해야 했습니다.

정기 배포에서는 Staging과 QA에서 확인한 변경을 Canary에 반영한 뒤 운영 적용 범위를 넓혔습니다. 이 글에서는 당시 배포 흐름과 그 과정에서 함께 확인했던 내용을 정리합니다.

단계별 검증

검증 환경에서는 변경한 기능과 기존 기능이 함께 동작하는지 확인했습니다. 다음 단계로 넘어갈 때도 어느 버전을 검증했는지, 어떤 확인이 끝났는지 이어서 공유해야 했습니다.

Canary는 일부 운영 트래픽에 새 버전을 먼저 적용해 보는 단계였습니다. 별도 환경에서 통과한 변경도 실제 운영 설정과 외부 연동에서는 다르게 동작할 수 있기 때문입니다.

일부 트래픽만 받는다고 확인이 저절로 끝나지는 않습니다. 어떤 요청이 새 버전으로 갔는지 알아야 하고, 오류와 응답 시간, 필요한 기능의 처리 결과를 함께 봐야 합니다. 문제가 보일 때 적용 범위를 넓히지 않고 멈출 수 있는 절차도 필요합니다.

서비스 의존성과 배포 순서

여러 서비스가 함께 바뀌면 각 서비스의 준비 상태 외에 버전 간 호환성도 확인해야 합니다. 새 응답을 기대하는 클라이언트가 먼저 배포되는데 서버는 이전 형식만 제공한다면 문제가 생길 수 있습니다.

무조건 서버부터 배포하는 식으로 순서를 고정하기보다, 변경 전후 버전이 함께 동작할 수 있는지 확인해야 합니다. 데이터를 바꾸는 작업이 포함되면 코드 버전만 되돌려도 되는지까지 살펴봐야 합니다.

배포 순서와 되돌릴 범위를 미리 정리해 두면, 적용 후 문제가 생겼을 때 확인할 대상도 좁힐 수 있습니다.

이벤트 일정과 배포 시점

The Draw처럼 트래픽이 몰리는 이벤트가 있는 주에는 배포 시점도 함께 조율했습니다. 변경 자체의 크기와 별개로, 적용 뒤 상태를 볼 시간과 문제가 생겼을 때 대응할 여유가 필요했습니다.

이벤트 직전에는 확인할 시간이 부족할 수 있고, 이벤트 중에는 원래 트래픽 변화와 배포 영향이 섞일 수 있습니다. 개발 완료일만으로 운영 반영일을 정하기 어려웠던 이유입니다.

반대로 Log4j 긴급 패치처럼 정기 일정까지 기다리기 어려운 변경도 있었습니다. 이런 경우에는 우선순위와 일정을 바꾸되 영향 범위, 검증 결과, 적용 상태를 공유하는 과정은 필요했습니다.

배포 상태 공유

배포 채널에서는 공지뿐 아니라 단계별 진행 상황을 공유했습니다. 어떤 환경에서 검증이 끝났는지, 누구의 확인이 남았는지, 적용을 진행할지 멈출지를 같은 곳에서 볼 수 있어야 했습니다.

여러 서비스가 움직이는 배포에서 “내 서비스는 완료”라는 정보만으로는 전체 상태를 알기 어렵습니다. 다른 서비스의 선행 작업이나 확인을 기다리는 상태도 구분해야 합니다.

정기 배포를 반복하며 익힌 이 흐름은 긴급 변경을 진행할 때도 사용할 수 있었습니다. 새 연락 경로를 만드는 대신, 평소 쓰던 경로에서 변경 범위와 일정, 남은 확인을 맞추는 방식이었습니다.

다음 글에서는 이런 배포 과정 속에서 동의 화면과 대량 이메일 발송을 함께 준비한 작업을 다룹니다.