개발 slecs

스태틱 사이트 배포 파이프라인 자동화로 장애 대응 속도 개선

목차

스태틱 사이트를 배포할 때 발생하는 수동 작업의 반복을 자동화했다. 빌드, 동기화, 헬스체크, 롤백까지 한 번에 처리하는 배포 파이프라인을 scripts/brainstorm_exec.py에 구현했는데, 이 작업을 통해 팀 운영 효율과 배포 안정성이 함께 개선되는 경험을 했다.

수동 배포에서 발생했던 문제들

예전엔 배포를 거의 수동으로 진행했다. 로컬에서 빌드한 후 rsync로 서버에 파일을 밀어 넣고, 사이트가 잘 떠올랐는지 눈으로 확인하고, 문제가 생기면 이전 버전으로 되돌리는 식이었다. 간단해 보이지만 문제가 많았다:

  • 인적 오류의 가능성: 빌드 단계를 빠뜨리거나, 동기화 후 헬스체크를 깜빡하는 경우
  • 장애 감지 지연: 배포 직후 문제가 있어도 누군가 수동으로 접속해야 알아챔
  • 빠른 복구 불가: 문제 감지 후 이전 버전으로 되돌리는 데 시간 소요
  • 팀 운영 비용: 배포할 때마다 담당자가 몇 분 이상 개입해야 함

배포 자동화는 단순히 편의성만의 문제가 아니라, 팀의 장애 대응 속도와 운영 신뢰도를 좌우하는 요소였다.

build→rsync→health→rollback의 4단계 설계

파이프라인을 4단계로 나누고 각 단계 사이에 실패 지점을 명확히 설정했다:

단계 목적 실패 시나리오 대응
build 최신 소스코드를 정적 자산으로 컴파일 컴파일 실패 → 배포 중단
rsync 빌드된 파일을 서버에 동기화 파일 동기화 실패 → 배포 중단
health 배포된 사이트가 정상 응답하는지 확인 헬스체크 실패 → 자동 롤백
rollback 이전 정상 버전으로 복구 롤백 실패 → 알람 발동

특히 health 체크가 실패했을 때만 자동 롤백하도록 설계한 것이 중요했다. 이렇게 하면 배포 직후 즉시 문제를 감지하고, 사용자 입장에서는 장애 시간을 최소화할 수 있다.

# 개념적 흐름 (실제 코드가 아닌 논리 구조)
def deploy():
    if not build():
        log("Build failed, aborting")
        return False

    if not sync_to_server():
        log("Sync failed, aborting")
        return False

    if not health_check():
        log("Health check failed, rolling back")
        rollback_to_previous()
        return False

    log("Deploy successful")
    return True

이런 설계가 중요한 이유들

헬스체크가 배포 안정성의 핵심이라고 생각했다. 빌드와 동기화까지 성공해도, 실제로 서버에서 뜬 애플리케이션이 제대로 응답하지 않으면 배포는 실패한 것이다. 따라서 health 단계에서는:

  • HTTP 상태 코드 (200 OK) 확인
  • 응답 시간이 정상 범위 내인지 체크
  • 필수 API 엔드포인트가 동작하는지 검증

이 몇 가지를 자동으로 확인하고, 하나라도 실패하면 즉시 롤백한다.

롤백 메커니즘이 배포의 심리적 안정감을 준다. 배포할 때 "만약 문제가 생기면?" 하는 불안감 없이 자신 있게 진행할 수 있다. 특히 팀 멤버들이 배포 자동화를 신뢰하고 자주 쓰게 되려면, "뭔가 잘못되면 자동으로 복구된다"는 보증이 있어야 한다.

팀 협업과 운영 관점에서의 변화

이 작업을 진행하면서 팀 내에서 몇 가지 규칙도 함께 정했다:

  • 배포 전 로컬에서 충분히 테스트하기 (build가 성공한다고 해서 모든 게 해결되는 건 아님)
  • health 체크 항목을 추가할 때는 코드 리뷰를 필수로 하기
  • 롤백이 실제로 발생한 경우, 원인 분석과 함께 개선안 논의하기

특히 마지막 부분에서 롤백 원인 분석을 팀이 함께 하는 것이 중요했다. 배포 자동화가 단순히 편하라는 이유만은 아니라, 팀이 장애 패턴을 배우고 개선할 수 있는 기회가 되기 때문이다.

마무리하며

처음 이 작업을 시작했을 때 "단순히 스크립트 하나 더 작성하는 것 아닌가" 싶었는데, 배포 파이프라인을 설계하고 구현하는 과정에서 "자동화가 정말 무엇인지", "어디까지 자동으로 하고 어디부터는 사람이 개입해야 하는지"를 고민하게 됐다. 팀 규모가 커질수록 이런 자동화의 가치는 더 커진다. 다음엔 배포 후 메트릭 수집과 모니터링 대시보드도 함께 구성해서, 배포 품질을 더 정량적으로 추적해볼 계획이다.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.