저는 지금껏 제 직책 덕분에 다양한 유형의 소프트웨어를 배포할 수 있는 특권을 누렸습니다. CD를 발송했고, 웹을 통해 고객 소프트웨어를 배포했으며, 데이터베이스 인스턴스와 제어 평면을 업데이트했습니다. 그리고 실행 중인 대규모 미션 크리티컬 시스템을 실시간으로 업데이트했습니다.
제가 이것을 특권이라고 부르는 이유는 최종 사용자에게 소프트웨어를 제공하는 것이 소프트웨어 엔지니어가 가장 좋아하는 일이기 때문입니다. 그러나 배포가 게임처럼 재미있기만 한 것은 아닙니다. 그리고 배포를 할 때마다 고유한 문제가 발생하지만, 모든 배포 과정에서 한 가지 공통된 것이 있는데, 바로 두려움입니다.
중요한 소프트웨어의 배포를 담당하는 분이라면 제가 무슨 말을 하는지 잘 아실 것입니다. 배포 담당자는 소프트웨어를 개발하고, 준비하고, 테스트합니다. 그리고 마침내 소프트웨어가 출항하는 날이 오면 프로덕션 환경이라는 바다에서 순조롭게 항해할 수 있기를 바라고 또 기도합니다. 대부분의 회사에서 프로덕션 환경은 개발 및 스테이징 환경과 현저히 다르기 때문에 스테이징 환경에서 작동한 코드가 프로덕션 환경에서도 성공적으로 작동할 것인지는 알 길이 없습니다. 그러나 한 가지 분명한 점은 소프트웨어에 문제가 발생할 경우 모두가 이에 대해 알게 된다는 것입니다. 그래서 두려운 것입니다.
이러한 두려움이 개발자에게 미치는 영향을 가장 잘 이해할 수 있는 말이 있습니다. SF 소설 Dune의 저자인 Frank Herbert는 "두려움은 정신을 집어 삼킨다"고 했습니다. 두려움은 실험적이고 도전적인 정신을 약화시킵니다. 위험을 감수할 의지를 꺾고, 배포를 몇 달씩 미루는 등 나쁜 습관을 가져옵니다. 무엇보다 혁신의 속도를 느리게 만듭니다 (많은 기업들이 지불하고 있는 혁신세에 대한 게시물 참조).
프로덕션 환경에 배포하는 것는 분명 두려운 일입니다. 하지만 저는 지난 30년간 동료들과 협력하여 안전하고 자신 있는 배포 환경을 만들 수 있는 몇 가지 방법을 개발했습니다. 다음에 나오는 이 시리즈의 4개 블로그 게시물에서 각각에 대해 차례로 살펴보겠습니다.
· 180 규칙 - 쉽고 빠르게 롤백이 가능한 자동화된 배포 지원
· Z 배포 - 롤백 실패로 인한 다운타임 제한
· Goldilocks Gauge - 배포의 규모와 빈도를 적절하게 조정
. 거울을 통한 조율 - 개발 환경, 스테이징 환경 및 프로덕션 환경 간의 조율
이러한 방법들은 완벽하지 않으며 배포에 버그가 발생하지 않는다는 것을 보장하지 않습니다. 하지만 제 경험상 최고의 전략입니다. 그리고 의미 있는 혁신이 가능하도록 엔지니어링 팀 내에 자신감 있는 문화를 구축하는 데 도움이 됩니다.
시작을 위해 다음 블로그 게시물에서는 프로덕션 환경에서의 다운타임(분)을 줄이는 데 도움이 되는 "180가지 규칙"에 대해 소개하겠습니다. 그동안 @MarkLovesTech를 통해 안전한 배포를 위한 나만의 팁과 기법을 자유롭게 공유해보세요.