금요일 오후 4시, 배포 리스트를 받았다
- 08 Dec, 2025
금요일 오후 4시
슬랙이 울렸다. 개발팀 리드가 배포 리스트를 공유했다. 12개 항목. 금요일 오후 4시에.
“이번 주 금요일 밤 11시 배포 예정입니다. QA 확인 부탁드립니다.”
커피잔을 내려놨다. 손에 힘이 들어갔다.
금요일 배포. 13년 동안 제일 싫어하는 단어다.
배포 리스트 뜯어보기
일단 항목을 확인했다. 12개 중 8개는 이미 테스트 완료. 문제없다.
남은 4개가 문제다.
- 결제 모듈 성능 개선 (High)
- 회원가입 프로세스 변경 (Medium)
- 관리자 대시보드 UI 수정 (Low)
- API 타임아웃 설정 변경 (Critical)
API 타임아웃이 Critical이다. 이게 잘못되면 전체 서비스가 멈춘다.
개발팀 리드한테 슬랙을 보냈다.
“API 타임아웃 테스트 완료됐나요? 부하 테스트 결과 공유 부탁드립니다.”
답장이 왔다. “로컬에서는 확인했습니다. 스테이징 배포는 내일 오전 예정이었는데…”
내일 오전. 배포는 오늘 밤 11시.
숨을 깊게 들이쉬었다. 토요일에 장애 터지는 게 보였다.
긴급 회의 소집
팀원들한테 슬랙을 날렸다. “4시 30분 회의실. 금요일 배포 건.”
5명이 모였다. 나머지는 재택이라 화상으로.
화이트보드에 4개 항목을 적었다. 우선순위를 다시 매겼다.
“결제 모듈이랑 회원가입은 테스트 완료. 문제없어. 관리자 UI는 리스크 낮아. 패스.”
마커로 API 타임아웃에 동그라미를 그렸다.
“이게 문제야. Critical인데 스테이징 테스트도 안 했어.”
막내가 물었다. “그럼 이거 빼고 배포하면 안 돼요?”
고개를 저었다. “이미 프로덕션에 타임아웃 이슈 있어. 고객 컴플레인 들어왔고. 월요일까지 못 기다려.”
시니어가 말했다. “지금 스테이징에 올려서 테스트하죠. 6시간 있으면 충분해요.”
시계를 봤다. 4시 40분. 배포까지 6시간 20분.
“좋아. 개발팀한테 지금 바로 스테이징 배포 요청해. 우리는 시나리오 준비.”
리스크 평가표 작성
회의가 끝나고 자리로 돌아왔다. 엑셀을 켰다. 리스크 평가표를 만들기 시작했다.
항목별로 리스크 레벨을 매겼다. 영향도, 발생 가능성, 복구 시간.
API 타임아웃: 영향도 9/10, 발생 가능성 6/10, 복구 시간 2시간.
결제 모듈: 영향도 10/10, 발생 가능성 2/10, 복구 시간 4시간.
회원가입: 영향도 7/10, 발생 가능성 3/10, 복구 시간 1시간.
관리자 UI: 영향도 3/10, 발생 가능성 1/10, 복구 시간 30분.
표를 보니까 명확했다. API 타임아웃이 최대 리스크다.
CTO한테 메일을 썼다. 제목은 “금요일 배포 리스크 분석”.
본문에 표를 붙였다. 마지막에 한 문단 추가했다.
“API 타임아웃 항목의 경우, 스테이징 테스트 미완료 상태입니다. 금요일 밤 배포 시 주말 장애 리스크가 높습니다. 권장사항은 해당 항목만 월요일로 연기하는 것입니다.”
전송 버튼을 눌렀다. 5분 후에 답장이 왔다.
“고객 컴플레인이 심각합니다. 월요일까지 기다릴 수 없어요. 스테이징 테스트 완료 후 배포 진행하세요.”
노트북 화면을 내려다봤다. 결국 내 책임이다.
스테이징 배포 테스트
6시. 개발팀이 스테이징에 배포했다.
팀원들이랑 테스트 시나리오를 나눴다. 각자 30분씩 돌리기로 했다.
내가 맡은 건 API 타임아웃 시나리오. 부하를 걸어봐야 한다.
Postman으로 API를 반복 호출했다. 100회, 500회, 1000회.
응답 시간을 체크했다. 평균 200ms. 최대 350ms. 타임아웃은 500ms로 설정돼 있다.
여유가 있어 보였다. 근데 프로덕션은 트래픽이 다르다.
개발자한테 물었다. “프로덕션 평균 TPS가 얼마죠?”
“보통 1500 정도요. 피크 타임엔 3000까지 올라가요.”
- 스테이징에서 그만큼 부하를 못 준다.
“부하 테스트 툴 돌릴 수 있어요?”
“JMeter 세팅하면 30분 걸려요.”
시계를 봤다. 6시 40분. 배포까지 4시간 20분.
“지금 바로 시작하세요.”
7시 30분, 테스트 결과
JMeter 테스트가 끝났다. TPS 3000으로 5분간 돌렸다.
결과를 봤다. 에러율 0.3%. 타임아웃 에러 9건.
많지 않다. 근데 0은 아니다.
개발자가 로그를 확인했다. “DB 커넥션 풀 부족인 것 같은데요. 설정값 올리면 될 것 같습니다.”
“지금 고칠 수 있어요?”
“10분이면 됩니다.”
“바로 해주세요.”
10분 후에 다시 테스트를 돌렸다. 이번엔 에러 없이 통과했다.
팀원들한테 물었다. “다른 항목 테스트 어때?”
“결제 모듈 이상 없습니다.”
“회원가입도 문제없어요.”
“관리자 UI 확인했습니다. 괜찮습니다.”
고개를 끄덕였다. 체크리스트를 하나씩 체크했다.
8시. 배포까지 3시간. 저녁을 먹을 시간이다.
“다들 밥 먹고 와. 10시에 다시 모이자.”
배포 직전 체크
10시 30분. 회의실에 다시 모였다.
배포 체크리스트를 스크린에 띄웠다. 30개 항목.
하나씩 확인했다.
- 테스트 완료: ✓
- 리스크 평가 완료: ✓
- 롤백 플랜 준비: ✓
- 모니터링 대시보드 확인: ✓
- 장애 대응 가이드 공유: ✓
- 비상 연락망 업데이트: ✓
개발팀 리드가 물었다. “QA 승인 가능한가요?”
노트북을 내려다봤다. 손가락이 키보드 위에 있었다.
API 타임아웃이 걸렸다. 스테이징에서 한 번 에러가 났었다.
근데 수정 후에는 통과했다. 프로덕션 트래픽이 다르긴 하지만.
월요일까지 기다리면 고객 컴플레인이 쌓인다. 기다려도 리스크는 같다.
“승인합니다. 배포 진행하세요.”
개발자가 고개를 끄덕이고 배포 스크립트를 실행했다.
11시 5분. 배포가 완료됐다.
모니터링 대시보드를 켰다. API 응답 시간, 에러율, TPS를 지켜봤다.
5분. 10분. 15분. 이상 없다.
팀원들이 하나둘 자리를 떴다. “고생하셨습니다.”
나는 30분을 더 지켜봤다. 11시 50분까지.
여전히 이상 없었다. 노트북을 닫았다.
집에 가는 길에 남편한테 전화했다.
“배포 끝났어. 지금 가.”
“고생했어. 내일 주말인데 괜찮아?”
“모르겠어. 내일 봐야지.”
토요일 아침
알람 없이 일어났다. 8시 30분. 습관이다.
침대에 누워서 폰을 켰다. 슬랙을 확인했다.
메시지 0건. 이상 없다는 뜻이다.
모니터링 대시보드 앱을 켰다. 어젯밤부터 지금까지 그래프를 봤다.
API 응답 시간: 평균 180ms. 에러율: 0.001%. TPS: 새벽 3시에 피크 2800.
이상 없다.
숨을 내쉬었다. 긴장이 풀렸다.
남편이 커피를 들고 왔다. “괜찮아?”
“응. 이상 없어.”
“다행이네. 오늘 뭐 해?”
“일단 12시까지 지켜볼 거야.”
남편이 웃었다. “알았어. 점심은 내가 할게.”
12시까지 30분마다 대시보드를 확인했다. 계속 정상이었다.
12시 15분. 딸이랑 같이 점심을 먹었다. 남편이 만든 김치찌개.
딸이 물었다. “엄마 오늘 회사 안 가?”
“응. 토요일이잖아.”
“그런데 왜 계속 폰 봐?”
말문이 막혔다. 습관이라고 해야 하나.
“엄마 일이 그래. 주말에도 확인해야 돼.”
딸이 고개를 끄덕였다. “나도 엄마처럼 회사 다닐 거야.”
”…그래. 근데 주말엔 쉬는 회사 다녀.”
남편이 웃었다. 나도 쓴웃음이 나왔다.
일요일 오전
일요일 아침에도 폰을 먼저 확인했다. 슬랙 메시지 없다.
대시보드를 봤다. 토요일 저녁 피크 타임에도 이상 없었다.
API 타임아웃 에러: 0건.
안도감이 왔다. 이제 진짜 괜찮은 것 같다.
오전에 가족이랑 공원에 갔다. 딸이 자전거를 탔다.
벤치에 앉아서 지켜봤다. 30분마다 폰을 확인했다. 습관이다.
남편이 말했다. “이제 그만 봐도 될 것 같은데.”
“응. 근데 월요일 아침까지는 봐야 해.”
“금요일 배포가 제일 힘들지?”
고개를 끄덕였다. “응. 주말 내내 불안해.”
“그럼 왜 금요일에 배포해?”
”…고객이 기다리니까.”
대답하고 나서 씁쓸했다. 고객도 중요하지만 내 주말도 중요한데.
13년 동안 금요일 배포를 몇 번이나 했을까. 50번? 100번?
매번 이렇게 주말을 보냈다. 폰을 확인하면서.
월요일 아침
월요일 아침 9시. 출근해서 제일 먼저 한 일은 주말 리포트 확인.
모니터링 팀이 보낸 메일을 열었다. “금요일 배포 후 48시간 모니터링 결과”.
- API 평균 응답시간: 185ms
- 에러율: 0.001%
- 타임아웃 에러: 0건
- 사용자 컴플레인: 0건
완벽했다. 문제없이 끝났다.
CTO한테 메일을 썼다. 제목은 “금요일 배포 완료 리포트”.
본문에 주말 모니터링 결과를 붙였다. 마지막에 한 문단 추가했다.
“금요일 밤 배포가 성공적으로 완료되었습니다. 주말 동안 모니터링 결과 이상 없음을 확인했습니다. 다만 향후 Critical 항목의 경우 스테이징 테스트 기간을 충분히 확보할 것을 권장합니다.”
전송 버튼을 눌렀다. 10분 후에 답장이 왔다.
“고생하셨습니다. 팀 회식비 신청하세요.”
회식비. 고맙긴 한데 주말 반납한 보상치고는 부족하다.
팀 회고
오후 3시. 팀 회고 미팅을 잡았다.
화이트보드에 세 가지를 적었다. “잘한 점, 아쉬운 점, 개선할 점”.
팀원들이 포스트잇을 붙였다.
잘한 점:
- 긴급 회의 빠른 소집
- 리스크 평가 정확했음
- 스테이징 테스트로 에러 사전 발견
- 모니터링 체계 잘 작동
아쉬운 점:
- 금요일 오후 4시에 배포 리스트 받음
- API 타임아웃 스테이징 테스트 미완료 상태
- 부하 테스트 시간 부족
- 주말 내내 긴장 상태
개선할 점:
- 배포 리스트 목요일까지 확정
- Critical 항목은 수요일까지 스테이징 테스트 완료
- 자동화 부하 테스트 환경 구축
- 금요일 배포 최소화 정책
마지막 항목을 동그라미 쳤다. “금요일 배포 최소화 정책”.
“이거 개발팀이랑 협의해보자. 금요일은 Low 리스크만 배포하는 걸로.”
시니어가 말했다. “좋은데 경영진 설득이 어려울 거예요.”
“알아. 근데 계속 제안은 해야지.”
회고 내용을 컨플루언스에 정리했다. 다음 주 전사 회의에서 공유할 예정이다.
퇴근길 생각
7시에 퇴근했다. 엘리베이터에서 개발팀 리드를 만났다.
“금요일 배포 고생 많으셨어요.”
“네. 다행히 이상 없었네요.”
“다음부턴 Critical 항목은 금요일 배포 피하는 게 어떨까요?”
개발팀 리드가 난처한 표정을 지었다. “그러고 싶은데 고객 요청이 급하면…”
말을 잘랐다. “고객 요청이 급해도 장애 나면 더 큰 문제잖아요.”
”…맞는 말씀이에요. 위에 건의해볼게요.”
엘리베이터 문이 열렸다. 서로 인사하고 헤어졌다.
지하철을 타고 가면서 생각했다. 13년 동안 똑같은 말을 몇 번이나 했을까.
“금요일 배포 피하자.”
근데 여전히 금요일에 배포한다. 고객이 급하니까. 일정이 촉박하니까.
결국 QA 팀장이 주말에 폰을 붙들고 있는다.
창밖을 봤다. 월요일 저녁 7시. 사람들이 퇴근하고 있다.
나도 퇴근이다. 근데 금요일 오후 4시부터 지금까지 진짜 쉰 시간이 얼마나 될까.
핸드폰을 꺼냈다. 슬랙을 확인했다. 습관이다.
남편한테 메시지를 보냈다. “지금 퇴근. 저녁 뭐 먹지?”
답장이 왔다. “치킨 시켜놨어. 맥주도.”
웃음이 나왔다. 좋은 사람이다.
그래도 다음 금요일 오후 4시에 또 배포 리스트를 받으면.
또 똑같이 할 것이다. 리스크 평가하고, 테스트하고, 주말에 폰 확인하고.
금요일 배포는 끝나지 않는다. 주말도 같이.