정적 리소스 캐시 무효화로 배포 후 구버전 문제 해결

정적 리소스 캐싱 관리 방식 개선

2026-04-02에 캐싱 관련 작업을 진행했음.

정적 리소스(CSS, JS, 이미지)는 변경 주기가 낮으니까 브라우저 캐시를 적극적으로 쓰는 게 성능에 유리함. 반면 배포 후 캐시가 안 털리면 구버전 리소스가 계속 쓰이는 문제가 생김.

캐시 무효화 전략

버전 쿼리스트링 방식을 사용함. 배포 시 리소스 URL에 버전 해시를 붙이면 URL이 바뀌어서 브라우저가 새로 요청함.

registry.addResourceHandler("/static/**")
    .addResourceLocations("classpath:/static/")
    .setCacheControl(CacheControl.maxAge(365, TimeUnit.DAYS));

JSP에서 <c:url> 또는 빌드 타임 변수를 활용해서 버전 파라미터를 자동으로 붙이도록 처리함. 배포 후 캐시 문제 신고가 줄어들었음.

다음

작업 규모는 크지 않았지만 운영 안정성을 위한 필요한 변경이었음. 이런 작은 수정들이 쌓여서 전체 시스템의 신뢰도를 높임.

CI/CD 파이프라인에서 자주 겪는 문제

• SSH 타임아웃: 빌드가 길어지면 연결이 끊김. command_timeout 명시 필요
• 키 인증 오류: 개행 문자 포함 여부 확인 필요
• 캐시 충돌: Gradle 캐시가 CI 환경에서 꼬이면 --no-daemon 또는 캐시 클리어
• 환경변수 누락: Secrets 설정 빠뜨리면 배포는 성공해도 앱이 뜨지 않음

무중단 배포 전략

서비스 중단 없이 배포하려면 트래픽 전환 타이밍이 중요함. 신규 버전 기동 완료 후 프록시 설정을 변경하는 방식으로 처리함.

헬스체크 엔드포인트가 반드시 있어야 함. 신규 버전이 떠있어도 정상 응답이 안 나오는 상태에서 트래픽을 받으면 에러가 남.

롤백도 고려해야 함. 이전 버전 JAR나 Docker 이미지를 유지해두고 문제 시 빠르게 복구할 수 있게 준비해두는 것도 배포 전략의 일부임.

다음