CASE STUDY
배포 파이프라인 개선 (SWING)
FE·BE·배치 3개 GitHub Actions 워크플로우가 서로를 모른 채 도는 구조에서 생기는 무중단 위협을 위험도별로 분석하고, 워크플로우 통합·자동 롤백·차등 캐시로 잡았습니다.
블로그에서 더 읽기 — 배포 파이프라인 개선 시리즈 ↗7개 분석
무중단 위협
ECS 자동 롤백
배포 실패
파일 특성별 차등
캐시 전략
문제정의
- packages/types를 건드리면 FE·BE 워크플로우가 동시에 떴고, 빨리 끝나는 FE(3~5분)가 구 BE(10~25분)를 호출해 404·undefined가 났습니다.
- 마이그레이션은 성공했는데 ECS 배포가 실패하면, 새 스키마를 구 코드가 만났습니다.
- CloudFront 전체 무효화는 글로벌 엣지로 최대 15분 전파돼, 그동안 신·구 번들이 혼재했습니다.
- 배포 실패 시 직전 Task Definition으로 자동 복구하는 로직이 없어 콘솔에서 손으로 되돌려야 했습니다.
문제해결
- 분리돼 있던 3개 워크플로우를 하나로 합치고 job 의존성으로 배포 순서(BE → FE)를 강제했습니다.
- 배포 실패 시 직전 ECS Task Definition으로 자동 롤백하도록 만들고, continue-on-error의 outcome/conclusion 차이를 이용해 실패를 정확히 감지했습니다.
- CloudFront 캐시를 파일 특성별로 나눠, 해시 에셋은 1년 immutable·index.html은 no-cache로 두고 선별 무효화했습니다.
- 마이그레이션에서 DROP을 금지하고 ADD-only로 두어 롤백 시 구 코드 크래시 위험을 줄였습니다(근본책 아닌 완충재로 한정).
결과
- packages 변경 시 FE가 구 BE를 호출하던 레이스 컨디션을 없앴습니다.
- 배포가 실패해도 직전 안정 버전으로 자동 복구되게 했습니다.
- 해시 에셋 영구 캐시·index.html no-cache로 캐시 전파 지연을 없애 배포 즉시 반영되게 했습니다.
기술스택
GitHub ActionsAWS ECSCloudFrontDocker