이번에는 Netlify가 말썽이다. 번들러 마이그레이션 이후에 평화롭게 지내고 있었는데… Netlify의 새로운 가격 정책 때문에 갑자기 고민이 생겼다.
문제의 정책은 ‘Netlify Team에 소속된 유저만 빌드를 돌릴 수 있다’는 점이다. 이렇게 되면 레포지터리에 커밋하는 사람의 숫자만큼 과금을 진행해야한다.
기존에는 Organization 별로 과금을 하는 느낌으로 쓰는 곳이 많았다. 우리 역시 그렇다. 새 가격 정책을 따라도 크게 상관은 없다. 다만 몇 배로 불어나는 비용을 Netlify에 지출해서 얻는 이득이 적다는 생각도 좀 많이 든다.
Netlify를 쓰며 느낀 장점은 ‘협업 과정에서의 용이함’, ‘커스터마이징 자유도가 잘 문서화되어 있음(높은게 아님)’이다. Concurrent build가 기본 3개인 것도 좋고, Netlify functions를 사용해서 슬랙봇 등 내부 도구도 쉽게 만들 수 있다.
하지만 단점이 좀 크다. 큼지막한 것이 두 가지 있다.
당장 동아시아 기준으로 네트워크 커버리지 및 속도가 떨어진다. Vercel과 같은 NS1을 사용해도 Edge가 부족해서 그런지, 어떤 때에는 30초 넘게 기다려야 페이지가 열린 적도 있었다.
다른 하나는, 빌드 속도가 많이 느리다. 캐싱 등이 잘 되지 않고 Docker 컨테이너가 뜨는 속도 역시 느리다. 물론 Vercel이 잘해서 그런 것일 수도 있지만, 빌드 캐파(Capacity)가 Vercel에 비해 부족한 것을 고려하면…
어쨌든 Netlify 대신 다른 도구를 사용해야할지 고민중이다.
가장 먼저 떠오르는 곳은 Vercel인데, Vercel은 은근히 불편한 부분이 있어서 고민이다.
Pro 계정인데 Concurrent build가 1개인 것도 불편하고, 내부적인 문서화도 잘 안되어있어서 구현 방법 등을 파악하려면 직접 돌려봐야한다. 비용 측면에서도 좀 비싸다.
또 하나는 Cloudflare Pages를 진지하게 검토했었는데… 이것 역시 은근히 안되는 것이 많다.
예를 들어 기본중의 기본인 ‘빌드 완료 / 실패에 대한 Webhook’이 없다. 구현을 하고 싶어도 빌드 컨테이너에서 환경 변수로 ‘빌드 완료 시 생성될 주소’ 등을 제공하지 않아서 못한다. 같은 레포지터리로 여러 개의 Pages를 연결하지 못하는 것도 조금은 아쉽다.
이 두 가지만 대충 해결이 되면 Cloudflare Pages를 안 쓸 이유가 없는데. 가격적으로도 너무 경쟁력이 있고, 네트워크 커버리지 역시 엄청나기 때문이다. (Vercel이든 Netlify든 결국 Cloudflare의 NS1에 의존하니까)
이 비용이면, 현재 프로덕션에서 쓰는 S3 Static Page까지 옮겨버리는 것이 좋을 것 같은데… 만약 그렇게 되면, 추가적으로 Worker 개발도 필요하다. 이건 왜 필요하냐?
빌드를 하게 되면 이전 빌드에 있었던 파일이 사라지거나 생길 수 있다. (파일명의 hash가 바뀌거나, 정말 해당 파일이 추가/삭제되거나)
만약 이전 빌드 결과물을 사용하고 있는 유저가 있는 상황에서 새로운 배포본이 반영되면, 이전 빌드본에서 필요한 파일을 불러오지 못해 크래시가 발생할 수 있다. 이를 막기 위해 알아서 뒷단에서 업데이트를 하거나, 사용자에게 새로고침을 유도하는 Worker를 작성해서 돌려야 한다.
어떤 것을 선택해도 외통수에 몰린 기분이다.
Netlify vs Vercel vs Cloudflare Pages... 그나마 나은 선택지는 무엇일까...