Vercel 정적 자산 최적화 공부 정리 | 배포마다 파일을 다시 올려야 할까

Vercel 체인지로그를 훑다가 “immutable static assets 최적화” 발표를 봤다. 제목만 보고는 캐시 헤더 설정 이야기인가 싶었는데, 읽어보니 배포 방식 자체에 관한 내용이었다.

배포할 때마다 정적 자산을 CDN에 다시 올리는 걸 당연하게 생각해왔다. 새 배포 = 새 업로드. 근데 이번 발표는 그 전제를 조금 다르게 다루고 있었다.

1️⃣ 이게 뭐냐?

핵심 개념은 “콘텐츠 주소 기반 자산(content-addressed assets)”이다. 파일 내용이 바뀌지 않으면 해시가 같고, 해시가 같으면 이미 CDN에 올려진 파일을 그대로 재사용한다. 새 배포가 나가더라도 변경되지 않은 JS 번들이나 이미지는 다시 전송하지 않는다.

설정은 따로 없다. 지원되는 프레임워크 버전으로 업그레이드하면 자동 적용된다. Vercel이 그 안에서 해시 충돌, 파일 생명주기, 라우팅을 직접 처리하기 때문에 사용자 입장에서는 코드 변경 없이 이 방식으로 전환된다.

발표에서 나온 수치를 보면, CDN 요청이 17% 줄고 전송 바이트가 24% 감소했다고 한다. 배포 시간은 평균 30% 빨라지고, TTFB는 60% 이상 개선될 수 있다는 내용이었다. 배포 빈도가 높은 프로젝트일수록 효과가 더 클 것 같다.

현재 지원 프레임워크는 Next.js 16.3 preview 이상이다. Nitro 등 다른 프레임워크 지원도 예정돼 있고, 프레임워크 개발자가 직접 구현하고 싶다면 Build Output API 문서의 immutable static files 섹션을 참고하면 된다고 한다.

2️⃣ 내가 든 생각

“배포마다 파일을 다시 올리는 게 당연하다”고 생각해왔는데, 공부하면서 이 전제 자체가 흔들렸다. 파일 내용이 같다면 굳이 다시 올릴 이유가 없다는 논리는 단순한데, 그게 CDN 레벨에서 실제로 구현된다는 게 생각보다 흥미로웠다.

👉🏻 불변성(immutability)이라는 개념이 코드 수준을 넘어 배포 인프라 수준에서도 쓰인다는 점이 인상적이었다. 함수형 프로그래밍에서 값을 불변으로 다루는 논리가 CDN 자산 관리에도 비슷하게 적용된다는 느낌이 들었다. 같은 해시 = 같은 내용 = 재업로드 불필요. 단순한 논리인데, 그게 인프라 수준에서 돌아간다는 게 묘하게 와닿았다.

💡 여기서 드는 질문? 불변 자산이 배포를 넘어 캐시를 유지한다면, 롤백 시에는 어떻게 처리될까. TTFB 개선이 크다면, 기존에 배포 직후 첫 요청이 얼마나 느렸던 걸까.

디자이너 입장에서는 배포를 자주 하게 된다. 수정 한 줄이라도 배포는 배포니까. 그때마다 변경 없는 이미지나 폰트도 통째로 다시 올라가고 있었을 텐데, 그 낭비를 딱히 의식하지 못하고 있었다는 게 묘했다. 매번 올라가는 파일이 전부 “필요한 것들”인 줄만 알았다.

⭐️ 마지막으로

결국 핵심은 배포 속도 개선이라기보다, 배포와 캐시가 어떤 관계를 맺어야 하는지를 다시 설계한 이야기에 가까운 것 같다. “배포하면 캐시가 날아간다”는 걸 당연하게 여겼는데, 그게 꼭 그래야 하는 건 아닐 수 있다는 걸 이번에 처음 생각해봤다.

---

참고 원문: Optimized CDN caching and deploying of immutable static assets