배포를 도박처럼 여기지 마세요

Source: Dev.to

Here’s what changed.

A while back, our team had a problem that looked like a success: we were shipping constantly. PRs merged daily, features going out every week, stakeholders happy. Then one Friday afternoon, a release took down a core flow for 20 % of our users. No rollback plan. No feature flags. No one sure which commit was the culprit.

We weren’t moving fast. We were just falling forward.

If you’re a tech lead or engineering manager, you’ve probably lived some version of this. So here’s what we actually changed — not the ideal textbook version, but the stuff that made a real difference.

몰래 스며드는 나쁜 습관들

• “merged”를 “shipped”로 간주하기 – 메인에 머지하고 프로덕션에 배포하는 것이 동일한 행동이 된다. 스테이징이 없고, 스모크 테스트도 없다. 사용자가 보게 되기 전에 회귀를 잡아낼 창도 없다.
• 수동 릴리스 체크리스트 – 30단계가 적힌 공유 문서를 배포 전마다 사람이 직접 실행한다. 인간이 단계을 건너뛰기 쉬워, 특히 금요일 오후 5시엔 그렇다.
• 전부 혹은 전무 배포 – 모든 릴리스를 즉시 100 % 사용자에게 제공한다. 점진적 롤아웃이 없으며, 문제가 발생했을 때 폭발 반경을 제한할 방법도 없다.
• 배포 시 가시성 부족 – 팀이 배포하고 나서… 기다린다. 오류율, 지연 시간, 주요 비즈니스 지표에 대한 자동 검사가 없으며, 버그는 시스템이 잡지 못하고 사용자에게 보고된다.

실제로 도움이 된 것

1. 파이프라인을 제품처럼 다루기

CI/CD 파이프라인은 팀이 매일 사용하는 인프라입니다. 속도가 느리거나, 불안정하거나, 이해하기 어렵다면 사람들은 우회하게 되고, 그때 단축키가 생깁니다.

우리는 파이프라인을 빠르고 신뢰할 수 있게 만드는 데 시간을 투자했습니다: 테스트 스위트를 병렬화하고, 캐시를 적극 활용하며, 실패 메시지를 실제로 유용하게 만들었습니다. 파이프라인이 신뢰받게 되자, 사람들은 이를 우회하지 않게 되었습니다.

2. 기능 브랜치보다 기능 플래그 먼저

오래 지속되는 기능 브랜치는 함정입니다. 병합 부채가 쌓이고 통합 시점이 고통스러워집니다. 우리는 기능 플래그 뒤에서 배포하는 방식으로 전환했습니다 — 코드는 프로덕션에 올라가지만 비활성화된 상태입니다. 이를 통해 배포와 릴리스를 분리할 수 있었고, 위험에 대한 사고 방식이 완전히 바뀌었습니다.

LaunchDarkly, Unleash 같은 도구나 간단한 자체 플래그 시스템도 충분히 잘 작동합니다. 중요한 것은 도구가 아니라 사고 방식의 전환입니다.

3. 릴리스 체크리스트 자동화

릴리스 과정 중 스크립트화할 수 있는 단계가 있다면 자동화해야 합니다. 우리는 수동 체크리스트를 파이프라인 자체에 옮겼습니다: 헬스 체크, 스모크 테스트, 마이그레이션 검증 등. 이전에 사람의 주의가 45분이나 필요했던 작업이 3분짜리 자동 게이트가 되었습니다.

체크리스트는 여전히 존재하지만, 이제는 문서가 아니라 코드입니다.

4. 기본값으로 진행형 배포

카나리 릴리스와 점진적 롤아웃은 대기업 전용이 아닙니다. 작은 규모에서도 먼저 5 % 사용자에게 배포하고, 15분 동안 오류율을 관찰한 뒤 점차 확대하는 방식은 충분히 실현 가능한 관행입니다. 또한 문제가 발생했을 때 여러분을 구해줄 가장 중요한 방법이기도 합니다.

Argo Rollouts, Spinnaker, 혹은 클라우드 제공자의 기본 기능(AWS CodeDeploy, GCP Traffic Splitting) 등을 활용하면 과거보다 훨씬 쉽게 구현할 수 있습니다.

5. 자동 롤백, 영웅주의는 금지

제가 참여한 최악의 포스트모템은 슬랙이 불타는 상황에서 누군가가 압박을 받으며 수동으로 커밋을 되돌리는 경우였습니다. “나쁨”을 나타내는 지표(오류율 급증, p95 지연 시간 상승)를 정의하고, 탐지를 자동화하며, 롤백도 자동화하세요. 롤백을 지루하게 만들어 버리세요.

알아두면 좋은 도구

• GitHub Actions / GitLab CI – 대부분의 팀에 적합한 기본 제공, 좋은 생태계
• LaunchDarkly / Unleash – 적절한 타깃팅 및 감사 로그가 포함된 기능 플래그 관리
• Datadog / Grafana + Prometheus – 배포 마커와 대시보드로 변화 시점을 바로 확인
• Argo Rollouts – 쿠버네티스 네이티브 프로그레시브 딜리버리, 견고한 롤백 지원
• Sentry – 사용자가 불평하기 전에 문제를 드러내는 오류 추적

실제 변화

기술적인 변화도 중요했지만, 더 큰 변화는 문화적인 것이었습니다: 우리는 배포를 마침표로 여기던 방식을 멈췄습니다. 배포는 단지 하나의 체크포인트일 뿐입니다. 진정한 마침표는 “사용자에게 가치가 전달되고, 문제가 발생하지 않는 것”입니다.

파이프라인이 자동화되고, 릴리즈가 점진적으로 이루어지며, 롤백이 지루할 정도로 쉬워지면 — 배포가 도박처럼 느껴지는 일이 사라집니다.

그때 비로소 실제로 빠르게 움직일 수 있습니다.

팀이 배포 방식을 크게 바꾸게 만든 가장 큰 변화는 무엇인가요? 댓글에 남겨 주세요.