최근 들어 Gitlab Pages의 TTFB의 속도가 체감될 정도로 느려졌다. 첫 로딩속도에 가장 큰 영향을 주는 요소이기 때문에 이를 해결할 방법이 필요했다. 최근 등장한 Netlify는 이에 가장 적합한 도구로 여겨졌다. Gitlab Pages는 아직 지원하지 않는 HTTP/2 지원과 Force HTTPS 지원은 지금껏 해온 많은 작업을 덜 수 있을 것 같아 유용해보였다.

Netlify

Netlify는 Gitlab 서비스와 연동하여 쓸 수 있다. 따라서 꼭 필요한 서버나 기타 도메인 설정만 Netlify가 담당하게 둘 수 있다. 처음 Netlify를 접했을 때 설정이 다소 복잡할 것이라고 생각했다. 하지만 정작 Netlify에 설정한 것은 빌드를 어떤 커멘드로 하는지 설정하는 것 외엔 아무것도 없었다.

여기서 놀랐던 점은 추가로 RubyGems의 설치나 NPM의 설치를 정의하지 않았음에도 알아서 이를 인식하고 처리했다는 점이었다. Gitlab Pages에서는 gitlab-ci.yml에 Docker를 비롯해 이 환경을 위한 구체적인 커멘트를 제시해야 했기 때문에 놀라운 경험이었다.

그렇게 커멘트 설정을 끝내니 Netlify 서버에 벌써 빌드를 완료후 Deploy가 되었다는 안내를 볼 수 있었다. 정말 유저가 추가적인 작업을 하지 않아도 알아서 완벽하게 작동하는 점은 지금껏 써본 웹 서비스 중에서 가장 훌륭했다.

Build Speed

솔직히 내가 예상하지 못한 부분이었다. Gitlab CI에 익숙해져 있다보니 이 방식이 가장 빠를 것이라고 착각하고 있었다. Netlify는 Gitlab CI가 빌드를 시작하고 있을 때 이미 빌드를 끝내고 Deploy 과정을 밟고 있었다. 거의 모든 과정이 1분 이내로 완료되었다. 또한 Netlify도 트리거를 지원하고 있어 Github Webhook도 잘 작동했다.

Let’s Encrypt Automation

HTTPS 설정이 이렇게 쉬울지 몰랐다. Let’s Encrypt의 SSL 인증서를 이용하겠다는 버튼에 클릭만 하니 알아서 인증부터 자동 리뉴얼 설정까지 완료하였다. Gitlab Pages를 썼을 땐 Cloudflare와의 강한 보안¹을 위해 내가 수동으로 Let’s Encrypt 인증서를 발급해야 했다. Netlify는 이를 자동으로 해결해주고 Force HTTPS로 자동 리다이렉트까지 지원해주었다.

후기

Netlify에도 몇가지 문제는 있었다. 서버가 대소문자를 엄격히 구별하기 때문에 서비스 워커에서 손상된 프로토콜 오류가 발생하곤 했다. 이 문제를 수정하기 위해 모든 파일의 이름을 소문자로 할 필요가 있었다. 하지만 그를 넘어서는 Build의 장점이 더 많았다. 항상 수동으로 하던 작업도 자동화 해주니 Netlify로 넘어갈 이유가 분명해보였다.