-
728x90
JAM Stack
JavaScript API MarkUp Stack
웹 서비스를 만드는 하나의 설계 방식, 프로그래밍 기법이라 할 수 있다.
일반적인 프로그래밍 기법이고 매우 익숙하게 느낄 수 있다. 실제로는 이러한 개념을 모르고 현재까지 이와 비슷한 방식으로 개발을 해오고 있었을 수도 있다. (LAMP, MEAN Stack과 같은 개념을 떠올리면 된다.)
더 나아가서 JAM Stack은 정적 사이트 생성기를 사용한 서비스의 설계를 의미하기도 한다.
여기서 정적 사이트 생성기란 (SSG) Next, Hugo, Gastby 등을 의미한다. 아래에서 SSG에 대해서도 다뤄보자.
JAM Stack 공식 문서에서는 아래와 같이 정의한다.
웹 애플리케이션에서 렌더링 할 화면을 Pre-render 하고 이를 CDN에서 제공(delivery)하여
빠르고 안전한 앱으로 웹 서버를 관리하거나 실행할 필요가 없다.
Jamstack is an architecture designed to make the web faster, more secure, and easier to scale.
JAM Stack 은 더 빠르고, 안전하며, 스케일링하기 쉬운 웹을 만들기 위해 디자인된 아키텍처입니다.
출처 : https://www.youtube.com/watch?v=CTtoHa1g8I4&t=329s 여기서 핵심으로 JAM Stack은 웹 애플리케이션의 마크업과 콘텐츠를 정적 페이지로 미리 생성해놓는다는 것이다.
이를 pre-rendering라 하며 로그인, 결제 등은 외부 API로 분리하는 decoupling 이라는 두 가지 개념이 중요하다.
Markup : SSG(Static Site Generator)나 Template Engine(Webpack 등)을 이용해서
Markup을 미리 생성합니다.JAM Stack에서 가장 핵심은 MarkUp이라고 할 수 있다.
MarkUp을 만들 수 있는 방법은 여러 가지가 있다.
1.HTML을 직접 작성한다
2.Template Engine 와 같은 툴을 사용한다.
3. 정적 사이트 생성기(Static Site Generator, SSG)를 이용해서 Static HTML을 생성한다.
e.g) Gatsby, Next.js, Gridsome, Nuxt.js, Hugo, Jekyll 등이렇게 만들어진 Static HTML은 웹 서버의 리소스를 사용할 필요 없이 사용자에게 HTML만 전달해주면 된다. Static HTML은 CDN을 통해서 Cache 하고 배포해서 빠른 속도를 유지하고, 따로 동적으로 HTML을 생성하지 않기 때문에 웹서버가 필요 없어서 서버 비용이 크지 않다.
하지만 모든 HTML을 Static HTML로 만들라는 뜻은 아니다.
모든 Markup을 정적으로 유지하게 되면, 최신 데이터를 유지하기 어렵기 때문이다.
중요한 것은 최대한 HTML Build를 하여 CDN Cache 서버를 통해 첫 의미 있는 페이지를 볼 수 있는 속도
(First meaningful paint)를 단축시킨다는 것에 주목할 필요가 있다.이렇게 JAM Stack은 페이지를 사전에 미리 생성한다는 것을 기억해야 한다.
이는 기존 웹들이 SSR이나, SPA 프레임워크, 라이브러리 등을 사용해서 페이지를 동적으로 생성한 것과 비교된다.
위 내용을 취합하여 JAM Stack을 다시 한번 표현해보자면
동적 요소 처리를 위한 JS, 재사용 가능한 API, 사전 생성된 페이지
이 3가지가 조합되어 서버 없이 배포 운영되는 모던 웹 개발 구조를 말한다.
출처 : https://www.youtube.com/watch?v=CTtoHa1g8I4&t=329s JavaScript, API 그리고 MarkUp
이름에서도 보았듯 이전 LAMP, MEAN과는 달리 DB, 서버에 관련한 스펙은 보이지 않는다.
DB, 서버는 철저하게 API로 분리하여 정적인 사이트를 만드는데 최적화된 방법이라 할 수 있다.
JavaScript와 MarkUp에 해당하는 HTML, CSS 정적 리소스들을 활용하여 웹 애플리케이션을 구성하는 스택이며, 이 정적 리소스들을 CDN에 배포하여 서버 관리를 최소화할 수 있다.
코드를 빌드하여 정적 페이지를 사전에 생성하고 이를 CDN에 배포함으로써
비용절감 + 사용자 경험까지 개선하는 것이 JAM Stack에서 권장하는 설계 구조이다.이러한 정적 페이지를 빌드해주고 CDN에 배포해주는 서비스가 Netlify, Vercel, AWS CloudFront이다.
JAMStack으로 개발한다는 것의 구조
일반적으로 JAM Stack은 SSG를 사용하여 빌드한다.
SSG 빌드의 결과물로 정적인 페이지들이 산출되고
CDN을 통해 전송을 하고 별도 추상화된 함수나 서비스들을 사용해 API 요청을 하게 된다.
출처 : https://www.youtube.com/watch?v=CTtoHa1g8I4&t=329s
JAM Stack을 사용하는 이유
1. 높은 안정성
- 정적 페이지를 미리 생성해놓기 때문에 동적으로 변경되는 부분이 적고, 서버나 DB 실행이 필요하지 않기 때문에 안정성이 높다.
2. 빠른 성능
- 콘텐츠들이 미리 정적 페이지로 생성이 돼있기 때문에 빠르게 랜더링이 가능하다.
- CDN에 정적 페이지를 배포하기 때문에 빠르게 전송하고 CDN의 캐싱 기능도 활용할 수 있다.
3. 확장성 및 낮은 비용
- 전 세계 어디든 CDN을 통해 손쉽게 확장하고 정적 HTML 호스팅 비용은 매우 저렴하거나 공짜인 서비스도 존재한다.
4. 쉬운 자동화
- 빌드 산출물이 정적 페이지이기 때문에 배포 과정이 편리하고 정적 자산을 호스팅 서비스에 제공만 하면 되기 때문에 자동화가 매우 쉽다.
JAM Stack의 한계
1. 빌드 속도
- 콘텐츠가 매우 많은 경우 생성해야 하는 페이지도 많아지고 결국 빌드 시간이 오래 걸리는 문제가 있다.
2. 실시간 변경 콘텐츠
- 실시간 단위로 콘텐츠를 변경해야만 하는 경우 반영에 시간이 걸린다.
- JAM Stack은 콘텐츠 변경사항을 반영하기 위해 빌드를 수행해야 하는데 빌드 속도가 느릴 경우 변경 사항을 즉각적으로 반영할 수 없다.
해결책 1
- 별도 CMS나 API 서비스를 활용해서 위 문제를 해결을 할 수는 있으나,
- 근본적으로 빌드 성능 개선에 관련한 문제를 해결하는 해결방법이 아니다.
해결책 2
- 위 문제를 해결하기 위해 Gastby, Next 같은 경우 점진적 Build라는 방법으로 이를 해결하기 위해 노력하고 있다.
- 매번 전체 콘텐츠를 대상으로 다시 빌드해서 페이지를 생성하는 방법이 아닌
- 변경된 부분만 빌드해서 해당 페이지만 다시 생성하는 방법이다.
- 이로 인해 빌드 속도를 20분에서 -> 1분 -> 10초 이하로 줄일 수 있었다고 한다.
이러한 점진적 Build라는 방법이 얼마만큼 발전하는지에 따라 웹의 미래를 선도할 가능성이 있다고 한다.
정적 사이트 생성기 (Static Site Generator, SSG)
빌드 산출물로써 정적 페이지를 만들어내는 것이 특징이다. SSG 별로 개발에 사용하는 언어가 다르다.
JAM Stack이 등장하게 된 배경 알아보기
뭐든지 그게 왜 등장했는지를 알면 이해가 훨씬 빠르다고 생각한다.
간단하게 웹 역사를 짚어보고 왜 등장하게 되었는지 따라가 보려고 한다.
Static Sites
초기 웹은 전부 Static Sites, 정적 사이트였다.
사용자가 URL을 입력하면 클라이언트는 서버 측에 어떤 HTML이 필요한지 요청을 보내면 서버에서는 이미 만들어져 있는 정적 HTML 파일을 내려주며 동작하였다.
다른 페이지를 보기 위해선 또 HTML 파일을 받아야 했고, 특정 일부분만 업데이트되는 것이 아닌 full page reqeuest로 전체 페이지를 다시 받아오는 방식이었다.
iframe
문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입이 되었고 이후 페이지 내에서 부분적으로 문서를 받아와서 업데이트할 수가 있게 된다.
XMLHttpRequest
Microsoft에서 만든 http 프로토콜을 사용하여 서버에 자원을 요청하기 위해 사용되는 자바스크립트 객체이다.
HTML 문서 전체가 아닌, JSON 형식으로 서버에서 필요한 데이터만 받아와는 요청을 보낼 수 있게 되었다.
AJAX (2005 ~)
Asynchronous JavaScript And XML 약자로 XML과 같은 방식이 공식적으로 AJAX라는 이름을 갖게 된다.
자바스크립트를 사용하여 클라이언트와 서버 간에 데이터를 주고받는 비동기 HTTP 통신 기술이다.
이후 이는 fetch, axios 등의 부모가 되는 개념이라 할 수 있다. (실제로 동일하지는 않다)
SPA (Single Page Application)
AJAX를 통해 필요한 데이터를 서버에서 비동기로 받아 올 수 있게 되었으며 페이지의 일부만 동적으로 업데이트할 수 있게 됨으로 써 SPA라는 개념이 등장하게 되고, 대세로 자리 잡게 된다.
SPA는 하나의 큰 애플리케이션의 모든 페이지를 하나의 페이지 내에서 동적으로 구성하는 방법이며,
CSR 방식을 채택하여 사용자에게 화면을 출력해주게 된다.CSR (Client Side Rendering)
CSR 이전에는 서버에서 동적으로 HTML을 생성할 수 있었다. 하지만 그 방법만으로는 HTML 조작에 한계가 있었고 JS와 브라우저 성능이 발전하면서 Vue, React, Angluar와 같이 DOM을 조작하기 쉽게 도와주는 프레임워크, 라이브러리의 등장으로 CSR이라는 개념이 등장하게 된다.
SSR (Server Side Rendering)
CSR의 페이지 초기 랜더링 속도, SEO 최적화 문제 등으로 등장하게 된 개념이며, 이전 Static Sites로 부터 영감을 받아 등장하게 되었다고 한다.
사실상 이전부터 있었던 방식으로 CSR의 문제점으로 인해 다시 돌고 돌아 등장하게 된 개념이다.
(CSR, SSR은 이 포스팅에서는 따로 설명하지 않는다.)
그래서 JAM Stack이 등장하게 된 배경이 무엇이냐?
사실 위 내용은 지금부터 정리하게 될 내용을 이해하기 위한 발판이다.
해당 영상을 한번 정독하고 본다면 더 이해하기 쉬울 것이라 확신한다. (NHN Cloud Youtube)
처음 전통적인 웹 구조는 아래와 같았다.
DB, CMS (Contents Management System, 워드프레스와 같은 툴) 사용하여 애플리케이션에 필요한 데이터를 조회하거나 저장하고,
App Server에서는 다양한 비즈니스 로직을 처리하게 된다.
Web Server에서는 처리한 데이터를 사용하여 HTML 페이지를 만들거나, 이미지, 폰트 등의 클라이언트에 필요한 정적 자원들을 브라우저에 전달하는 역할을 한다.
이러한 구조는 각 계층 간 의존성이 높기 때문에 별도의 서버 운용에 들어가는 비용이 크다는 단점이 있었다.
Serverless 웹
이 단점을 개선하기 위해 Serverless라는 개념이 등장하게 된다.
서버 시스템을 가상의 클라우드 환경에 두고 운용하는 구조이다.
이로 인해 서버 유지보수 비용 및 인프라 비용을 절감할 수 있었고
필요한 API, 비즈니스 로직 개발에만 집중할 수 있는 환경이 만들어졌다.
이에 대한 확장으로 AWS lambda, Netlify, Firebase 등 함수 단위의 서비스가 등장하게 된다.
Serverless 웹 구조
브라우저에서 데이터를 요청하면 DB에 접근하여 데이터를 가져와 화면을 출력해주는 것은 동일하다.
다른 부분은!
DB 서비스 API를 사용한다는 것이다.
즉, 웹 개발 시 DB, API 구조에 대해서는 전혀 신경 쓰지 않고 원하는 데이터를 DB 서버에 저장하고 필요에 따라 조회하면서 사용하면 된다.
Serverless란, 서버가 없다는 개념이 아닌, 서버 구성, 관리에 대해 신경 쓰지 않아도 된다는 개념이다.
JAM Stack은 Serverless에서 파생된 개념이다.
인터넷이 계속 발전하면서 만들어지는 웹 개발의 아키텍처, 프로그래밍 설계의 변화에서 있어 가장 최신 버전? 의 패러다임이 아닐까 생각한다. LAMP, MEAN 처럼 말이다.
LAMP (리눅스, 아파치, MySQL, PHP) -> MEAN Stack (MongoDB, Express.JS, Angular or React, NodeJS)-> JAM Stack
현재까지 CSR + SSR 서로의 단점을 보완하는 방법으로
이를 접목시킨 Next.JS, Nuxt.JS 등 프레임워크들이 인기를 끌고 있다.JAM Stack은 Next.JS와는 다르다, 결국 웹 사이트를 어떻게 구성할 것인지에 대한 관점이다.
돌고 돌아 그래서 JAM Stack 이 등장하게 된 배경
기존 웹 사이트들은 서버, DB 등에 매우 크게 의존했었기 때문이라고 정리할 수 있을 것 같다.
JAM Stack이라는 하나의 아키텍쳐?가 고안되면서 이러한
의존도가 크게 떨어졌고, 이는 비용 감소, 안정성, 확장성 측면에서 매우 큰 이점을 챙길 수 있었다.이러한 의존 관계를 벗어나 더 나은 성능, 안정성, 낮은 비용 그리고 높은 확장성을 갖는 웹 사이트를
개발할 수 있게 되었다고 이해할 수 있을 것 같다.
마무리
나에게 있어 생각보다 어려운 주제였다.
수많은 자료들을 토대로 어느 정도만 이해가 되었을 뿐 완벽하지는 않다고 생각한다.
아래 박성룡 님 Medium 아티클을 보면 JAM Stack을 가장 쉽게 따라 하는 방법에 대한 서술이 기록되어 있다.
이를 실제로 내가 개발해 보면서 포스팅을 수정하려고 한다.
CDN에서 배포가 왜 빠른지가 궁금하다면 이전 포스팅을 참고하면 이해하기 수월할 거라 생각한다!
저는 제가 보기 위해서 포스팅을 남깁니다.
어려운 주제를 스마트하게 다루지 못한 것 같아 글을 계속 다듬어야 할 것 같습니다.
언제나 잘못된 부분이 있다면 피드백 남겨주시면 더 견고한 지식이 될 것 같습니다!
출처 및 참고
728x90