운영 장애를 줄이기 위해 배포 전에 확인하는 체크리스트

실서비스에서 몇 번 배포를 해보고 나면, 장애는 대단한 기술 이슈보다 사소한 확인 누락에서 시작되는 경우가 더 많다는 걸 느끼게 됩니다.
코드 자체는 맞았는데 환경 변수가 빠져 있거나, 배치 시간대를 생각하지 않고 배포했거나, DB 마이그레이션 순서를 잘못 잡아서 장애가 나는 식입니다.

저도 한동안은 "이번 변경은 작으니까 괜찮겠지"라는 생각으로 배포했다가 몇 번 크게 데인 적이 있었습니다.
그 뒤로는 배포 전에 보는 항목을 체크리스트로 묶어두고, 규모가 작은 배포라도 같은 순서로 다시 확인하고 있습니다.

체크리스트를 두기 전에는 왜 자꾸 놓쳤을까

배포 전에 확인해야 할 항목은 머리로는 다 알고 있습니다.

스키마 변경이 있는지
롤백이 가능한지
로그로 바로 확인할 포인트가 있는지
프론트나 운영팀에 공유할 내용이 있는지

문제는 이걸 "알고 있는 것"과 "항상 빠뜨리지 않는 것"이 전혀 다르다는 점이었습니다.
회의가 길어지거나 일정이 밀리면 제일 먼저 사라지는 게 이런 확인 과정이었습니다.

그래서 지금은 체크리스트를 기술 문서라기보다, 실수 방지 장치로 보고 있습니다.

1. 이번 배포가 어떤 종류인지 먼저 나눈다

가장 먼저 보는 건 변경의 성격입니다.

단순 코드 수정인지
스키마 변경이 포함되는지
외부 연동 포인트가 있는지
트래픽 피크 시간에 민감한 기능인지

이걸 먼저 나누면 배포 난이도를 대충 감으로 때려 맞추지 않게 됩니다.
예를 들어 API 응답 필드 하나 추가하는 배포와, 주문 테이블 스키마를 바꾸는 배포는 같은 "배포"라도 준비 방식이 달라야 합니다.

2. DB 변경은 코드보다 먼저 본다

운영 장애를 만들기 쉬운 배포는 대부분 DB가 끼어 있었습니다.

특히 아래 항목은 꼭 따로 봅니다.

nullable -> not null 변경이 들어가는지
대용량 테이블에 인덱스를 추가하는지
애플리케이션 코드와 스키마가 동시에 바뀌어야 하는지
이전 버전 애플리케이션과 잠시 공존해도 괜찮은지

실무에서는 애플리케이션은 롤백해도, 이미 반영된 스키마는 쉽게 되돌리기 어려운 경우가 많았습니다.
그래서 지금은 스키마 변경이 있으면 코드 리뷰보다 먼저 배포 순서를 봅니다.

3. 기능 플래그나 토글로 나눌 수 있는지 본다

한 번에 크게 여는 기능일수록 배포 순간의 리스크가 커졌습니다.
그래서 가능하면 아래처럼 쪼갭니다.

코드 먼저 배포
기능은 닫아둠
모니터링 확인
이후 플래그 오픈

이렇게 하면 장애가 나더라도 원인을 좁히기 쉽습니다.
예전에는 "배포와 기능 오픈"을 한 번에 끝내려고 했는데, 그 방식은 문제가 났을 때 어디서 흔들린 건지 찾기가 어려웠습니다.

4. 배포 직후 볼 로그와 대시보드를 미리 정해둔다

배포 후에 무엇을 볼지 정하지 않고 배포하면, 막상 이상 징후가 생겨도 어디를 먼저 확인해야 할지 헷갈립니다.

그래서 저는 배포 전에 미리 세 가지를 정해둡니다.

이번 배포에서 가장 위험한 API
그 API의 에러율과 응답 시간
배포 후 10분 안에 확인할 로그 키워드

이걸 적어두면 배포가 끝난 직후 대시보드 앞에서 멍하니 그래프만 보는 일이 줄어듭니다.

5. 롤백 기준을 미리 말로 적어둔다

롤백은 "이상하면 하자" 수준으로 잡아두면 항상 늦어졌습니다.

그래서 지금은 최대한 기준을 숫자로 적습니다.

5xx 비율이 평소 대비 얼마나 오르면 롤백할지
핵심 API 응답 시간이 몇 배 이상 튀면 멈출지
특정 예외가 몇 건 이상 반복되면 배포를 되돌릴지

이 기준이 있으면 배포 중에 분위기에 휩쓸리지 않고 판단할 수 있습니다.
실무에서는 기술적 판단보다도 "조금만 더 보자"라는 심리 때문에 대응이 늦어지는 경우가 많았습니다.

실제로 쓰는 배포 전 체크리스트

지금은 아래 항목을 배포 전에 짧게라도 확인합니다.

이번 배포 변경 범위와 영향 API를 한 줄로 설명할 수 있는가
DB 변경이 있다면 반영 순서와 롤백 가능 여부를 확인했는가
환경 변수, 배치 시간, 외부 연동 설정이 바뀌는가
기능 플래그로 나눌 수 있는가
배포 직후 볼 대시보드와 로그 키워드를 정했는가
이상 징후가 생길 때 누가 어떤 기준으로 롤백할지 정했는가

항목 자체는 거창하지 않지만, 이걸 적어도 한 번 눈으로 보고 배포하는 것만으로 사고가 꽤 줄었습니다.

마무리

배포 체크리스트는 배포를 느리게 만드는 문서가 아니라, 배포를 덜 불안하게 만드는 장치에 가깝습니다.

실서비스에서는 기술력이 높은 사람보다, 배포 전에 무엇을 확인해야 하는지 습관적으로 알고 있는 사람이 사고를 더 적게 냅니다.
저도 결국 배포를 잘하는 방법은 특별한 도구보다, 반복 가능한 확인 순서를 만드는 데 있다는 쪽으로 생각이 바뀌었습니다.