배포 후 처음 15분에 실제로 확인하는 것은 무엇인가요?
Source: Dev.to
Background
CI가 통과되었습니다.
배포가 완료되었습니다.
눈에 띄는 오류는 없습니다.
그럼에도 불구하고, 릴리즈 후 몇 분 동안은 프로덕션이 불안정하게 느껴집니다. 이것이 소프트웨어를 배포할 때 가장 어색한 부분 중 하나라고 생각합니다.
배포는 기술적으로 성공할 수 있습니다:
- 빌드 통과
- 테스트 통과
- 파이프라인 통과
- 컨테이너 시작
- 헬스 체크 정상
하지만 실제 트래픽이 시스템에 닿아야만 나타나는 런타임 문제도 존재합니다. 이 때문에 배포 성공과 런타임 신뢰 사이에 이상한 간극이 생깁니다.
많은 소규모 팀에서 배포 후 처음 몇 분은 다음과 같은 흐름을 가집니다:
- 로그 열기
- 최근 예외 확인
- 오류 급증 감시
- 현재 잡음과 “보통”이었을 때를 비교
- 무시할지, 조사할지, 롤백할지 결정
예외, 타임아웃, 재시도, 지연 급증, 외부 API 호출 실패, 성능 저하 엔드포인트 등 감지를 위한 도구는 충분하지만, 감지가 판단과 동일하지는 않습니다. 실제 배포 후 질문은 보통 다음과 같습니다:
이 배포가 실제로 상황을 악화시켰는가?
그리고 이어서:
지금 바로 주의를 기울여야 하는가?
두 번째 단계는 여전히 놀라울 정도로 수동적인 느낌을 줍니다.
성숙한 릴리즈 제어, 카나리 롤아웃, 피처 플래그, 강력한 관측성 설정이 있다면 불확실성 창은 훨씬 짧아질 것입니다. 하지만 많은 팀이 이를 갖추지 못했고, 갖추었다 하더라도 릴리즈 후 프로덕션이 실제로 무엇을 말하고 있는지 해석해야 합니다.
핵심은 “신호를 수집할 수 있느냐?”가 아니라:
- 배포 직후 가장 중요한 신호는 무엇인가?
- 이를 정상 동작과 어떻게 비교할 것인가?
- 잡음과 회귀를 어떻게 구분할 것인가?
- “이 배포는 괜찮다”라고 확신할 수 있는 기준은?
- 즉시 조사해야 할 상황은 무엇인가?
배포 후 처음 10~15분을 생각할 때, 저는 거대한 대시보드보다는 소수의 판단 신호에 더 집중합니다:
- 새로운 런타임 예외가 발생했는가?
- 기존 예외 패턴이 악화됐는가?
- 실패가 특정 서비스나 API 경로에 집중돼 있는가?
- 오류 패턴이 최근 베이스라인과 의미 있게 다른가?
- 이것이 일시적인 현상인가, 아니면 배포와 관련된가?
이는 일반적인 모니터링과는 다른 문제이며, 배포 후 런타임 진단에 가깝습니다.
My Approach
이러한 사고 흐름은 제가 Relivio를 만들게 했습니다. 아이디어는 좁습니다: 전체 관측성 플랫폼이 아니라 “이 배포가 안전한가, 아니면 주의가 필요한가?” 라는 질문에 답하기 위한 집중된 도구입니다.
- Minimal FastAPI demo:
- Main project site:
Discussion Questions
- 배포 후 처음 10~15분에 실제로 무엇을 확인하시나요?
- 로그, 알림, 대시보드, 릴리즈 뷰 중 주로 어떤 것을 활용하시나요, 아니면 다른 방법이 있나요?
- “이 배포는 아마도 나쁘다”라고 생각하게 하는 신호는 무엇인가요?
- 방치해도 된다고 확신하게 하는 신호는 무엇인가요?
- 이미 강력한 워크플로우가 있다면 그것은 어떤 모습인가요?
- 그렇지 않다면 아직도 수동적이거나 번거롭게 느껴지는 부분은 무엇인가요?
특히 작은 팀이나 사이드 프로젝트의 답변에 관심이 많습니다. 그곳이 아직 가장 인간적이고 자동화가 덜 된 부분이기 때문입니다. 현재 스택으로 이 문제가 충분히 해결됐다고 생각한다면 그 의견도 듣고 싶고, 전용 도구가 필요할 만큼 고통스럽지 않다고 생각한다면 그 이유도 진심으로 알고 싶습니다.