[웹] Jamstack에 대해서

Posted on Dec 16, 2021

많은 기술적 발전을 거쳐감에 따라서 사람들은 웹사이트를 방문할 때에 신속한 응답을 점점 당연하게 여기고 있다.

그래서 사람들은 사이트가 자신의 기대보다 늦게 보여진다면 뒤로가기 버튼을 눌러서 피드백하고, 영상들이 바로바로 재생되기를 바란다.

그에 대해 사람들은 많은 고민을 하고 있고, 그 중에서 Jamstack을 이용한 웹 사이트 배포가 떠오르고 있는 것 같다.

Jamstack이란??

Javascript API Markup의 약자로 빠르고 안전하고, 쉽게 확장가능한 웹을 만들기 위해 고안된 아키텍쳐를 뜻한다.

기존의 LAMP MEAN stack은 웹서버, 데이터베이스 등 특정 기술들의 집합을 의미했다면 잼스택에서는 약간 의미로 사용된다.

  1. 런타임 시 브라우저의 Javascript

  2. 특정 앱을 위한 데이터베이스가 아닌 재사용 가능한 HTTP API

  3. 미리 빌드된 Markup으로 배포

이 3가지를 활용한 Jamstack은 더 빠른 배포, 쉽게 확장가능한 사이트를 제공하며 서버 관리와 설정에 시간을 쏟지 않아도 되게끔 도와준다.

잼스택 특징

  1. 전세계에 분산되어 있고, 트래픽에 탄련적

CDN을 이용해 배포한다면 전세계에 안정적으로 배포할 수 있고, 미리 빌드된 HTML을 제공하기 때문에 캐쉬를 사용해서 아주 빠르게 전달할 수 있다.

  1. 개발자 친화적인 Git 워크플로우 중심적

Git을 사용했기 때문에 언제든지 특정 시점으로 돌아가기 쉽다.

  1. API를 통해 다른 서비스를 사용하는 모듈식 설계

모듈식 설계로 인해 기존의 monolithic 아키텍쳐 하의 사이트들에 비해 더 유연하고, 확장이 쉬워졌다.

또, 단순히 정적인 사이트를 배포한다면 이용자들의 흥미가 금방 떨어질 것이 자명하기 때문에 이 부분에 대해서는 API(Stripe의 결제, Disqus의 댓글 기능 등)를 이용해 동적인 컨텐트를 제공하게끔 하였다.

  1. 전달되기 전 최적화 및 미리 빌드

잼스택은 가장 큰 차이 점은 마지막 4번이다.

기존의 웹에서는 1. 데이터베이스에서 데이터를 가져옴 2. 템플릿에 따라서 렌더링 3. HTML로 변환 4. 방문자에게 제공이었다.

잼스택은 기존의 웹과는 다르게 항상 HTML을 새로 만들지 않고 미리 빌드한 사이트가 제공된다.

잼스택 워크플로우

  1. 사이트에 대한 소스를 레포지터리에 저장

  2. 변화가 생길 경우 사이트를 자동으로 빌드하게끔 만들어서 최종 HTML 등의 정적파일들로 변환

  3. 변환된 결과물을 CDN을 이용해서 배포하여 유저들이 가능한 한 가까울 수 있도록 만듦

이러한 방법을 통해 네트워크 지연이 상당히 줄어들었으며, 많았던 서버들에 대한 수요가 사라졌다.

또, 미리 렌더링된 컨텐트를 전달하는 단순함과 효율성으로 잼스택 사이트는 스피드 테스트에서 가능한 가장 높은 점수들을 얻게 되었다.

기존의 웹에 비해 좋은 점?

  1. 빠르다.

기존의 웹은 방문자가 사이트를 방문하면 그 때에 필요한 정보들을 데이터베이스에 불러와서 정보들과 함께 사이트를 구성하여 방문자에게 보여주었다면

잼스택에서는 미리 빌드된 사이트를 그대로 전달하기만 하기 때문에 훨씬 빠를 수 밖에 없다.

  1. 서버, 데이터베이스 등을 몰라도 쉽다.

서버 관리 혹은 설정, 데이터베이스 등에 대한 지식을 전혀 알지 못해도 쉽게 배포가 가능하다.

직접 HTML을 만들거나, 정적 사이트 생성기(Hugo 등)를 골라 작성한 후 Gitlab/Github에 push, 그리고 Netlify에서 배포하면 끝.

개인적으로 생각했을 때는 이 점이 제일 크다고 생각한다. 기존의 워드프레스같은 사이트들 배포할 때는 상당히 귀찮은 작업이 많았고, 서버 관리에 신경을 써야할 부분이 많았는데 작은 잼스택 사이트를 시험삼아 만들었을 때 이렇게 간단할 수가 있다고? 하며 놀랐었다.

물론 도커를 사용해서 워드프레스를 배포하면 그닥 어려울 것 같지는 않지만 그래도 여전히 잼스택 사이트보다는 배포하기가 힘들 것 같다.

안 좋은 점?

  1. 3rd 파티 의존적

동적인 컨텐츠들을 API에 의존해서 전달하다 보니 어느 정도 다른 서비스들에 의존할 수 밖에 없음.

ex) yalco.kr 의 글을 보면 댓글 기능을 맨 밑에 disqus의 서비스로 구현되어 있음.

  1. 컨텐트를 수정하는 게 쉽지 않다.

예를 들어 워드프레스에서 글을 쓸 때 에디터 창이 제공되는 거에 비해, SSG(Static Site Generator)는 따로 제공된다 거나 하지 않기 때문에 개발자 입장에서는 오히려 더 친숙할 수 있겠으나 대부분의 경우 컨텐트를 수정하는 데에 불편함을 느끼기 쉽다.

Strapi, NetlifyCMS 같은 headless CMS 등을 이용하면 편하게 컨텐트를 추가할 수 있다고 하지만 기본적으로 SSG에 있지는 않아서 단점으로 생각하였다.

사실 이것도 다른 서비스에 의존한다는 점에서 앞선 단점과 비슷한 것 같다.

SSG

잼스택은 미리 빌드된 정적파일들을 제공하는데, 그 때 SSG(Static Site Generator)를 사용해서 미리 빌드하는 것이다.

앞서 말했듯 기존 웹들과 다르게 데이터베이스 연결을 필요로 하지 않기 때문에 상당히 단순하게 작업 후 빌드할 수 있다.

또한 다양한 테마를 적용해서 사용할 수 있기 때문에 편리하게 글(Markdown)만 적으면 된다.

이 블로그는 Hugo로 작성됐는데 개인적으로 SSG 중에서 가장 프레임워크가 작성된 언어(Js, Go 등)에 대해 알지 못해도 사용자가 사용하기 쉬운 것 같다.

SSG목록은 여기에서 볼 수 있다. (C언어도 있다!)

느낀 점

각각 기능(댓글, 결제 등등)들을 제공하는 서비스들이 현재 시장에 나와있기 때문에 가능한 것 같다는 느낌이 들었는데, API들로 기능들을 사이트에 녹아내어 제공하는 점에서 이러한 느낌을 받았다.

또, 기존의 monolithic한 구조에서 탈피하여 잼스택은 백엔드와 분리된 구조를 택하고 그 결과로 다른 조그마한 API를 제공하는 서비스들이 합쳐진 사이트를 제공하는데, 이는 마이크로서비스들로 이루어져서 각각의 서비스들을 독립적으로 유지하는 MSA의 구조와 어느 정도 유사한 것 같다.

MSA에서는 한 서비스를 특정 기능을 가진 서비스들로 나누어 독립된 서비스들을 제공하고, 그 과정에서 잘 만들어진 API를 이용해 서로 소통한다.

이는 잼스택이 백엔드와의 연결을 포기하고 API로 각각의 서비스들을 사이트에 통합시킨다는 점에서 연상되었다.

잼스택이 정적인 요소가 많은 사이트들에서는 유용하게 사용될 수 있을 것 같긴 하지만, 기존의 웹을 전부 대체하기에는 무리가 있는 것 같다. 특히 동적인 요소가 많을수록!