반복되던 배포 장애의 진짜 문제는 테스트가 부족한 것이 아니라, 어떤 변경이 나갔는지 추적하고 검증하고 되돌릴 기준이 없다는 점이었습니다. 조직이 커지고 제품팀이 나뉘며 끊긴 변경 맥락이 릴리즈 흐름에서 드러나도록, 상시 배포에 가깝던 흐름을 주 단위 릴리즈와 사전 검증이 있는 운영 체계로 다시 설계했습니다.

프로젝트 한눈에 보기

항목	내용
문제	배포 직후 장애가 반복되고 릴리즈별 변경 추적과 롤백 기준이 불명확한 상태
역할	릴리즈 운영 체계 재설계 및 배포 전 검증 흐름 구축
핵심 성과	배포 직후 장애가 사실상 매번 발생하던 상태에서 분기 1회 수준으로 감소
핵심 포인트	상시 배포에 가까운 흐름을 주 단위 릴리즈와 사전 검증이 있는 운영 체계로 전환

왜 이 문제를 먼저 풀어야 했는가

회사가 빠르게 성장하면서 하나의 제품팀이 3개로 나뉘었고, 신규 채용도 빠르게 늘어났습니다. 하나의 팀이던 시기에는 모두가 시스템 전체를 알고 있었지만, 팀이 쪼개지면서 제품 이해도가 떨어졌고 이를 이어주던 중간 관리자급 엔지니어들이 퇴사하면서 다른 팀의 사이드 이펙트가 제대로 챙겨지지 않기 시작했습니다.

이 상태에서는 기능을 더 빠르게 내는 것보다, 반복되는 장애를 멈추고 운영 안정성을 먼저 바로잡는 것이 우선이라고 판단했습니다.

당시 운영 문제는 명확했습니다.

• 배포 직후 장애가 사실상 매번 발생
• hash 기준으로만 되돌아가야 해 이전 상태를 정확히 재현하기 어려움
• 각 릴리즈마다 어떤 변경사항이 포함됐는지 추적 불가

배포 후 문제가 생기면 어떤 PR이 원인인지 Slack과 GitHub 기록을 다시 뒤져야 했습니다. 릴리즈 단위의 변경 이력이 없었기 때문에, 롤백도 기능 단위가 아니라 특정 hash로 되돌리는 방식에 가까웠습니다.

문제를 어떻게 정의했는가

당시 가장 큰 문제는 "배포가 불안하다"는 현상 자체보다도, 왜 문제가 생겼는지 추적하기 어렵고 문제가 생겨도 안전하게 되돌리기 어렵다는 점이라고 보았습니다. 즉, 테스트 몇 개를 더 추가하는 문제가 아니라 릴리즈 주기, 검증 단계, 변경 이력, 롤백 기준이 모두 약한 상태였습니다.

상시 릴리즈 자체는 변경을 빠르게 반영하고 배포 단위를 작게 유지할 수 있다는 장점이 있다고 생각합니다. 다만 당시처럼 팀이 분화되고 제품 이해도가 분산된 상태에서는, 그 장점을 살리면서도 내부 리뷰와 QA, 변경 추적을 함께 맞출 수 있는 보완 장치가 필요했습니다. 그래서 이 프로젝트의 방향은 상시 릴리즈를 부정하는 것이 아니라, 정기 릴리즈의 운영 안정성과 상시 릴리즈의 민첩성 사이의 트레이드오프를 고려해 릴리즈를 관리 가능한 단위로 다시 설계하는 데 두었습니다.

어떻게 안정화를 만들었는가

1. 릴리즈 단위와 변경 이력 재설계

• Squash & Merge 전략 전환
• standard-version 도입
• 자동 CHANGELOG 도입
• PR 템플릿과 커밋 컨벤션 문서화로 팀 간 공통 리뷰/릴리즈 프로세스 마련
• 상시 릴리즈의 장점은 유지하되, 주 단위 정기 릴리즈를 기준 흐름으로 두어 리뷰와 QA를 조율할 수 있게 설계

변경 이력이 릴리즈 단위로 남기 시작하면서, 문제가 생겼을 때 단순히 특정 hash로 되돌리는 것이 아니라 어떤 기능 묶음이 포함됐는지 확인하고 되돌릴지 판단할 수 있게 되었습니다. beta/QA 단계나 e2e 테스트에서 실패한 변경은 운영 배포 전에 중단했고, 운영 배포 후 문제가 생기면 changelog와 릴리즈 기준을 보고 영향 범위를 좁혀나갔습니다.

2. 사전 검증 단계와 릴리즈 게이트 도입

• 인프라팀과 협의해 배포 전 beta/QA 스테이지 구축
• 배포 전 기본 페이지와 핵심 기능을 확인하는 Playwright e2e 테스트를 릴리즈 게이트로 연결
• Playwright, GitHub Actions, Slack 알림을 연결해 통과한 변경만 배포하는 게이트 구성

릴리즈 플로우는 다음과 같이 바뀌었습니다.

Before
PR merge -> 배포 -> 장애 발생 시 Slack/GitHub 기록 추적 -> hash rollback

After
PR merge -> changelog 생성 -> beta/QA 배포 -> Playwright e2e 테스트 -> Slack 결과 공유 -> 주 단위 릴리즈 -> changelog 기준 rollback 판단

이 과정에서 인프라팀, 각 서비스 라인의 주요 개발자들과 함께 릴리즈 주기와 검증 프로세스를 조율했습니다. 핵심은 특정 배포 방식을 좋고 나쁜 것으로 나누는 것이 아니라, 당시 조직 상태에 맞게 릴리즈 주기-사전 QA-변경 이력-롤백 기준을 하나의 운영 체계로 묶는 것이었습니다.

결과는 무엇이 달라졌는가

• 배포 직후 장애가 사실상 매번 발생하던 상태에서 분기 1회 수준으로 감소
• 릴리즈마다 어떤 변경이 나갔는지 추적 가능한 상태 확보
• 릴리즈 기준과 사전 검증 단계를 바탕으로 롤백 판단과 대응이 가능한 운영 체계 마련

여기서 장애는 배포 직후 서비스 영향이 발생해 릴리즈 담당자가 원인 파악, 핫픽스, 롤백 판단을 해야 했던 릴리즈 대응 이슈를 기준으로 보았습니다. 일반 버그나 운영 문의가 아니라, 배포 직후 릴리즈 흐름 안에서 즉시 대응이 필요했던 이슈를 기준으로 정리했습니다.

정확한 장애 수치보다 중요한 변화는, 배포 때마다 문제가 날 수 있다는 전제가 사라지고 릴리즈 전 검증과 변경 추적을 기준으로 대응할 수 있게 되었다는 점이라고 생각합니다.

이 경험에서 배운 것

배포 안정성은 단지 테스트를 더 붙인다고 만들어지지 않았습니다. 어떤 변경이 릴리즈에 포함됐는지 추적할 수 있어야 하고, 그 변경이 안전한지 배포 전에 검증할 수 있어야 하며, 문제가 생겼을 때 같은 기준으로 되돌릴 수 있어야 했습니다. 이 프로젝트는 배포를 "잘 아는 사람이 조심해서 하는 일"에서 "여러 팀이 같은 기준으로 운영할 수 있는 시스템"으로 바꾼 경험이었다고 생각합니다.

주 단위 릴리즈는 변경 반영 속도를 일부 늦출 수 있는 선택이었습니다. 하지만 당시에는 팀 분화와 제품 이해도 분산으로 인해 변경 추적과 사전 검증을 확보하는 것이 더 큰 리스크를 줄이는 판단이라고 보았습니다.