안전한 배포: 변경
Slack은 고객 영향의 대부분(73%)이 배포를 비롯한 Slack 내부 변경에서 발생한다는 분석을 바탕으로 Deploy Safety Program을 시작했다. 이 프로그램은 자동 감지·복구, 영향 범위 제한, 안전장치와 문화 개선을 통해 고객 영향 시간을 줄이는 것을 목표로 했으며, 2025년 1월에는 정점 대비 고객 영향 시간이 90% 감소했다. 핵심은 특정 배포 시스템만 엄격하게 관리하는 대신, 모든 배포 방식에 반복 적용 가능한 안전 패턴을 구축하면서 개발 속도도 유지하는 것이다. ## 변화가 안정성에 미치는 영향 - Slack이 고객 업무에서 더욱 중요한 제품이 되면서 안정성에 대한 기대 수준이 높아졌다. - 고객 대상 장애의 73%가 Slack 내부 변경으로 발생했으며, 특히 코드 배포가 주요 원인이었다. - 장애 영향은 시스템마다 달랐고, 고객이 사용하는 기능에 따라 피해 정도도 달라졌다. - Slack에는 수백 개의 내부 서비스와 여러 배포 시스템이 있어, 단일한 배포 방식만 개선해서는 문제를 해결하기 어려웠다. - 기존에는 개별 서비스나 배포 시스템에 수동 절차를 추가하는 방식이 많았지만, 이는 개발 속도와 엔지니어링 사기를 떨어뜨렸다. - 고객은 약 10분을 넘는 중단을 단순한 “일시적 문제”가 아닌 심각한 장애로 인식하는 경향이 있었다. ## Deploy Safety의 목표 초기에는 중요도가 높은 서비스 전체를 대상으로 다음과 같은 North Star 목표를 세웠다. - 배포로 인한 영향 시간 단축 - 자동 감지 및 복구: 10분 이내 - 수동 감지 및 복구: 20분 이내 - 영향 심각도 감소 - 전체 플릿의 10%에 도달하기 전에 문제가 있는 배포 감지 - 개발 속도 유지 - 안정성을 높이되 변화와 혁신의 속도를 희생하지 않음 이 목표는 이후 모든 배포 시스템과 프로세스에 적용되는 Deploy Safety Manifesto로 확장됐다. 단순한 운영 절차가 아니라 자동화, 배포 안전장치, 조직 문화의 변화를 함께 추진한 것이 특징이다. ## 고객 영향 시간을 측정하는 지표 Slack은 프로그램의 성과를 측정하기 위해 다음 지표를 정의했다. - **고심각도 및 일부 중간 심각도 변경 유발 장애로 인한 고객 영향 시간** - 장애 심각도는 현재 또는 예상되는 고객 영향을 나타내지만, 실제 최종 영향과 항상 일치하지는 않는다. - 따라서 중간 심각도 장애는 실제 고객 영향 수준을 기준으로 별도 선별해야 했다. - 이 지표는 고객 감정을 직접 측정하는 값이 아니라, 고객 경험을 추정하는 실용적인 대리 지표다. Slack은 다음 세 요소 사이의 연결이 완벽하지 않다는 점도 인정한다. - 고객의 실제 만족도 - Deploy Safety 프로그램 지표 - 개별 프로젝트 지표 따라서 지표를 설계할 때 결과를 측정할 수 있는지, 무엇을 측정하는지 명확한지, 주관적 판단이 일관적인지, 실제 고객 피드백과 계속 비교되는지를 중요하게 봤다. ## 투자할 프로젝트를 고르는 방법 프로그램 초기에는 어떤 프로젝트가 가장 큰 효과를 낼지, 효과가 언제 나타날지 알기 어려웠다. 장애 데이터는 과거 결과를 보여주는 후행 데이터였지만 고객은 이미 현재 문제를 겪고 있었기 때문이다. 이에 따라 Slack은 다음과 같은 투자 전략을 사용했다. - 초기에는 여러 영역에 폭넓게 투자하고 빠르게 실행 - 이미 고객 피해가 확인된 영역을 우선 개선 - 성과가 확인된 프로젝트와 패턴에 추가 투자 - 효과가 낮은 영역의 투자는 축소 - 결과에 따라 바뀔 수 있는 짧고 유연한 로드맵 운영 프로젝트는 주로 다음 중 하나 이상의 목표에 기여하도록 설계했다. - 배포 과정에서 문제를 더 일찍 감지 - 자동 복구 시간 단축 - 수동 복구 시간 단축 - 격리 경계를 설계해 장애의 확산 범위와 심각도 축소 ## Webapp 배포 개선 사례 변경 유발 장애의 가장 큰 원인으로 Webapp backend가 지목되면서 단계적인 개선이 진행됐다. - 자동 메트릭 모니터링 구축 - 자동 알림과 수동 롤백으로 고객 영향 여부 검증 - 자동 배포 및 자동 롤백 도입 - 자동 롤백을 통해 고객 영향 시간을 10분 이하로 유지하는 성과 확인 - 추가 메트릭 모니터링과 수동 롤백 최적화 - Frontend 수동 롤백 기능 추가 - 중앙 집중식 배포 오케스트레이션 시스템으로 패턴 확대 - Slack Bedrock과 Kubernetes를 넘어 여러 배포 시스템에 메트릭 기반 배포와 자동 복구 적용 이 과정을 통해 Webapp backend와 frontend, 일부 인프라 배포가 훨씬 안전해졌으며 분기별로 계속 개선되는 결과를 보였다. ## 반복 가능한 안전 패턴 Slack의 접근 방식은 처음부터 완벽한 시스템을 설계하는 것이 아니었다. - 문제를 해결할 수 있는 작은 프로젝트를 먼저 시도 - 실제 고객 영향과 지표 변화를 통해 효과 검증 - 성공한 방식을 다른 서비스와 배포 시스템에 복제 - 결과가 낮은 영역은 투자를 줄이고 새로운 접근을 시도 즉, Deploy Safety는 하나의 도구나 배포 시스템을 도입하는 프로젝트가 아니라, 측정과 실험을 반복해 조직 전체에 안전한 변경 방식을 확산하는 프로그램이다. 실무적으로는 모든 배포를 수동 승인으로 막기보다, 고객 영향과 직접 연결된 메트릭을 기반으로 조기 감지·자동 롤백·영향 범위 제한을 구축하는 것이 효과적이다. 또한 안정성 지표를 정기적으로 실제 고객 피드백과 비교하고, 효과가 입증된 안전 패턴을 다른 시스템에 재사용해야 개발 속도와 안정성을 함께 확보할 수 있다.
원문 읽기(새 탭에서 열림)