잼스택 소개: 안전한 고성능 사이트 만들기

Introduction to the Jamstack: Build Secure, High-Performance Sites - SitePoint

Lucero del Alba, 2020년 7월 20일

 

가끔, 웹개발은 보다 나은 쪽으로 극적인 선회를 한다. 이 글에서 우리는 잼스택을 소개하고 그것이 무엇인지, 그리고 왜 대단한지를 설명한다.

 

예전에 역동적인(dynamic) 사이트들은 램프(LAMP) 스택으로 폭발했다. 그리고 나서 민(MEAN) 스택이 차세대 웹 앱들의 기초를 제공해 주었다. 이제 API 와 재사용 가능한 컴포턴트들이 뜨면서, 고정적인 사이트들이 다시 유행을 타고 있다. "기본으로 돌아가자" 는 류인데 꼭 그렇지는 않다.

 

잼스택이란 무엇인가?

잼스택은 더 빠르고 더 안전한 웹사이트들을 위한 현대 웹의 재정의이다. 이런 사이트들은 규모 변경에 더 좋고 적절한 도구 모음이 있으면 개발과 유지 보수가 훨씬 더 쉽다. (그리고 더 재밌다)

 

그 용어를 쪼개 보자.

 

J는 자바스크립트를 가리킨다. 자바스크립트는 1995년 넷스케이프에 의해 도입된 이래로 많은 진전이 있었다. 반응성 있고 진보적인 라이브러리들과 함께 모바일 앱처럼 작동하는 웹 앱들을 디자인 할 수 있다.

A는 API들을 가리킨다. 모든 기능 하나 하나를 다 프로그래밍 할 필요가 없이 엄청난 수의 작업들을 제 3자에게 안심하고 처리시킬 수 있다.

M은 마크업을 가리킨다. 이미 개발된 컴포넌트들을 재사용하거나 유지 보수 하기 훨씬 쉬운 것들을 새로 만들 수 있다.

 

그냥 케케묵은 얘기가 아닌가?

한 편으로는 그렇다. 잼스택이란 용어는 원래 JAMstack 으로 쓰도록 되어 있었는데, 네틀리파이(Netlify)가 자신들의 "현대 웹 프로젝트들을 자동화하기 위한 일체형 플랫폼"을 선전하기 위한 방법으로 만들어낸 신조어였다. 웹 컴포넌트들과 API들이 꽤나 오랜시간 존재했었기 때문에 잼스택 뒤의 원리들은 그다지 새롭지는 않은 것이다.

 

그러나 바로 똑같은 방식으로 에이잭스(Ajax - 비동기 자바스크립트와 XML)라는 용어가 당시 또 다른 회사 - 어댑티브 패스(Adaptive Path) - 에 의해 만들어졌고, 에이잭스를 가능하게 하는 XMLHttpRequest (XHR) API 가 한동안 존재했음에도 불구하고 에이잭스와 잼스택은 공동체에 빠르게 채용된, 합법적으로 사용되는, 신선한 개정된 아이디어들이었다. 그 과대광고는 충분한 자격이 있다: 이런 방식의 작동은 전 세계의 많은 개발자들에게 놀라운 것이었다.

 

고정적인 사이트들?

"고정적인 사이트들"은 "역동적인 웹사이트들"의 반댓말이다. 그런가? 그럼 평범한 HTML 파일들에 어떻게 풍부하고 역동적인 상호작용을 제공할 수 있을까? 음, 자바스크립트로.

 

자바스크립트는 첫번째 브라우저 전쟁들 이래로 엄청나게 진화했다. 노드 제이에스의 등장과 리액트, 앵귤러, 뷰 제이에스와 같은 라이브러리들과 함께 다목적 프로그래밍 언어로 스스로를 통합했다. 고급 사용자 인터페이스를 고안할 가능성들에는 끝이 없다.

 

물론 자바스크립트가 특효약은 아니다. 이걸로 데이터 분석이나 인공지능을 하고 있진 않을 것이다. 그러나 웹개발에서는 누군가가 이미 마이크로서비스를 만들어 놓았을 가능성이 높기 때문에, 자바스크립트 메소드들로 사용할 수 있는 API로 할 수 없는 것이 거의 없다.

 

그리고 무엇 보다도 그 과정을 마크업과 함께 재사용 가능한 컴포넌트들로 "캡슐화" 할 수 있어서, 그 특정한 기능이 필요할 때마다 들러서 사용할 수 있고 잠재적으로 그 때 마다 몇 시간의 작업을 아낄 수 있다.

 

그렇게 잼 스택이 바로 있다: 자바스크립트, API들, 마크업

 

 

비결합된(Decoupled), 헤드리스(Headless), 마이크로서비스, 서버리스... 미안, 뭐라고?

이 모든 것들은 웹개발에서 인기 있는 주제들이고 모두 서로 가깝게 연결되어 있지만 별로 동일하지는 않다. 이러한 용어들을 많이 듣게 될 것이니 시작부터 몇 가지 용어들을 확실히 구분하자.

 

결합된(Coupled) 대 비결합된(Decoupled) 대 헤드리스(Headless)

결합은 웹사이트의 내용이 사이트의 백 엔드에 생성, 관리, 저장될 때 데이터베이스에 놓여 있는 것을 말한다. (워드프레스 어드민과 같은) 그 내용은 그 후 백 엔드에서 꺼내져서 프론트 엔드 인터페이스(워드프레스 템플릿과 같은)를 통해 브라우저에 구현된다. 한 편으로 "결합된" 애플리케이션은 동일한 앱의 서로 다른 면인 백 엔드와 프론트 엔드를 가리키는 전통적인 "풀스택"이다.

 

그에 반해 비결합은 백엔드와 프론트엔드가 따로 관리될 때 - 즉 데이터베이스와 관리 도구들이 한 서버에 있고 프론트 엔드는 다른 곳에 있을 때를 말한다. 당연하게, 둘을 연결시킬 매개체가 필요하다. 보통 API 가 한다. 이에 더해 이제 백 엔드가 프론트 엔드로부터 효율적으로 분리되어 있으므로 실제로 여러 개의 프론트 엔드들이 서로 다른 장소에 있을 수 있다! (쇼피파이(shopify)처럼 같은 엔진을 사용한 서로 다른 스토어프론트들을 생각해 보라)

 

간결하게, 헤드리스 소프트웨어는 단순히 프론트엔드나 프레젠테이션 층이 없다. 예를 들어 헤드리스 CMS는 고정적인 내용을 생성하여 아무 곳에나 내보낼 수 있다: 모바일 앱, 사물 인터넷 장치, 웹사이트 등. 인정하건대, 이것도 또한 "비결합" 상황이지만 여기서는 API 조차 필요하지가 않다. 워드프레스 엔진이 그 게시물을 내보내서 고정된 HTML 파일들로 보여주는 것을 생각해보라. 그게 헤드리스다. 사실, 당신은 지금 딱 그 방식으로 만들어진 페이지에 있다.

 

획일적 (꽉 결합된) 대 마이크로서비스 (느슨하게 결합된)

간단히 말해 획일적이란 것은 하나의 조각으로 만들어진 소프트웨어로 정의될 수 있다. 모바일 앱, 당신의 컴퓨터에 설치할 수 있는 대부분의 소프트웨어들, 그리고 워드프레스와 같은 웹 앱들이 그 예시에 포함될 수 있다. 이러한 앱들은 여전히 내부에 "모듈들" 이나 "컴포넌트들"을 가지고 있을 수 있지만 그런 것들 없이는 애플리케이션이 작동하지 않을, 그 애플리케이션에서 없어서는 안 될 부품이기때문에 우리는 이런 것들을 꽉 결합되었다고 말한다.

 

반면, 느슨히 결합된 소프트웨어 컴포넌트들은 제거되거나 교체될 수 있는 플러그인처럼 작동하고, 아마 그 기능이 바뀌어도 애플리케이션의 핵심은 여전히 작동할 것이다. 이러한 원리는 제 3의 API들 - "마이크로서비스"라고 주로 불리는 - 이 애플리케이션의 없어서는 안 될 부분이 아니며 내장되어 있지 않은 부차적인 기능들 (이미지 리사이징, 로그인, 저장 등)을 제공하므로 이것들을 통해 기능을 "위탁" 하는 것을 가능하게 한다.

 

서버리스 대 전통적인 전산

인정하건대, "서버리스"는 좀 부적절한 명칭이다. 어느 전산 벤쳐에 있든지, 서버는 관여하게 되어 있다. 하지만 당신이 서버에 접속하고 관리하는 방식은 급격히 다를 수 있다.

 

전통 모델에서는 아마도 실제 물리적인 서버(때로 나금속 -bare metal- 이라 칭해지는)가 있거나 물리적인 서버의 다른 사용자들 사이에서 당신에게 자원이 할당된 가상의 전용 서버가 있을 것이다. 자원은 한정되어 있고 그것의 100%를 쓰든지 말든지 간에 마치 다 쓰는 것처럼 지불을 한다.

 

서버리스 모델에서는 많은 서버들이 서로 연결되어 제공하는 거대한 공동 자원이 제공된다. 당신은 필요할 때 필요한 만큼 그냥 당길 수 있고 필요에 따라 규모를 키우거나 줄일 수 있다. 어떤 실제 서버를 당신의 것으로 지정할 수는 없지만 어디에서 오는지에 상관 없이 자원이 있다는 것은 알 수 있다.

 

전통 모델	서버리스 모델
실제 서버와 제한된 자원들	무제한 공동 자원
오작동 경향 (즉 하드 디스크 실패)	더 믿을 수 있는 구성*
제한된 확장성	무제한 확장성
대기 중 서비스 포함 전부 지불	사용한 것을 지불 (사용한 만큼 지불)
단순한 사용법	실행을 배워야 함

* 하드 디스크들, CPU들 그리고 메모리 칩 실패들은 여전히 발생한다는 것에 주의. 그러나 자원들이 투명하게 배정되기 때문에 하드웨어가 깨져서 교체되더라도 눈치채지 못 할 것이다.

 

잼스택의 실용적인 예시

이러한 개념이 처음이라면 공부해야 할 게 많을 것이다. 그러니 이론은 잠시 쉬고 몇 가지 실용적인 현실 잼스택 사용 사례를 보자.

 

사례 연구 1: 속도 10배 향상을 위해 워드프레스를 고정 사이트로 바꾸기

만약 고정으로 갈 거라면 역동적인 워드프레스 블로그를 가지고 고정으로 바꾸는 것 보다 더 나은 방법이 뭐가 있겠는가? 그렇게 함으로써 우리는 페이지 로딩 속도와 대기 시간을 적어도 한 지수는 줄일 수 있고 보안을 높이 향상시킬 수 있으며 SEO도 개선시킬 것이다.

 

과정 요약

1. 고정 사이트 생성기(SSG - Static Site Generator)를 사용하여 워드프레스에서 게시글과 페이지들을 고정된 양식(텍스트, 마크다운, HTML)으로 생성한다.
2. 고정된 내용을 깃헙, 깃랩 또는 비트버킷의 저장소(repository)와 동기화 한다.
3. 배포 관로(deployment pipeline)을 자동화 해서 저장소에 변화가 있을 때마다 그 변화들이 글로벌 컨텐츠 전송망(CDN)에 즉각 반영될 수 있게 한다.
4. 자동화된 배포로 안전하고 빠른 웹사이트들이 무료 호스팅 되는 것을 편히 즐긴다.

근데 이거는...

물론 이것은 많은 의문을 불러일으킬 것이다:

• 어드민은 어떻게 해?
• 범주들과 RSS피드는?
• 이제 내용은 어떻게 관리하지?
• 댓글 섹션이랑 뉴스레터는 어쩌지?

이쯤 되면 당신은 SSG로 내용을 생성시키고 있을 것이므로 워드프레스 어드민에는 이별 키스를 날릴 수 있다. 사실, 지킬(Jekyll)과 같은 SSG들은 블로그들을 만들기 위해 특별히 고안된 것이고 갯츠비 제이에스(Gatsby.js)와 같은 SSG들에는 이미 모든 배터리들도 포함되어 있다.

 

내용 관리(기존의 게시글 수정과 같은)는 헤드리스 CMS가 구원의 손길을 내민다. 댓글과 뉴스레터에 대해서는, 이미 디스커스(Disqus)나 메일침프(Mailchimp)와 같은 외부 API를 사용하고 있지 않은가?

 

실제로 어떻게 하는가?

여기서 SSG나 헤드리스 CMS의 구석구석을 다 보여줄 순 없지만 이 시리즈의 다음 회차를 계속 주목하라. 워드프레스 사이트를 옮기는 단계적인 가이드를 선사할 것이다.

 

사례 연구 2: 자동화된 관로로 고정 사이트를 무료 호스팅 하기

"무료"는 잼스택 커뮤니티에서 많이 듣게될 것인데 고맙게도 여전히 당신의 신용카드 번호를 말해줘야 한다는 점에서는 무료가 아니다.

 

과정 요약

이 경우, 고정된 사이트를 데리고 (예를 들면 사례 연구 1에서 옮겼던 블로그) 온라인에 놓는다:

 

1. 깃헙, 깃랩, 또는 비트버킷 저장소를 설정한다.
2. 네틀리파이, 깃랩 페이지, 또는 깃헙 페이지로 배포한다.

이 때 저장소의 모든 변화는 (웹훅들을 통해) 자동으로 새 배포를 촉발시킬 것이다. 혹시 문제가 발생하면 매우 우아하게 되돌릴 수 있다.

 

왜 회사들은 이것을 무료로 하는가?

HTML 파일들을 이미 배포된 CDN에 떨구는 간접 비용은 최소한이다. 실제 전산처리나 PHP 구현은 관여하지 않는다는 것을 상기하라. 많은 대역폭을 집어삼키는 어마어마하게 인기 있는 사이트를 호스팅 하지 않는 이상, 회사들은 약간의 호스팅을 해주는 것을 꺼리지 않는다. 그리고 그렇게 하는 것이 사회에 좋은 공헌이 된다.

 

많은 공짜 상품을 나눠줌으로써, 회사들은 또한 당신을 가둬두게 된다. 당신이 프리미엄 서비를 필요로 할 때 쯤엔 (당신의 사업이 잘 되면 그렇게 할 것이다) 당신은 이미 그들과 함께 있다. 그것은 그냥 공평할 뿐이다. 게다가 그쯤 되면 당신은 어차피 당신의 문제에 대한 임기 응변 해결책을 개발하거나 어떤 서비스에 지불하는 것이 필요해져 있을 것이다.

 

실제로 어떻게 하는가?

두 가지 경우에 네틀리파이나 깃헙/깃랩은 매우 간단하며 최소한의 노력을 필요로 한다. (그럼에도 불구하고 다음 글에서 그 과정을 자세히 다루겠다)

 

잼스택은 풀스택 개발과 어떻게 비교되는가

이 새로운 접근이 램프나 민 스택과 어떻게 다른지 보자:

 

램프/민 스택	잼스택
웹 서버들이 사이트들을 돌림	CDN에 글로벌 배포
FTP/SSH 업로드, 서버 재시작	자동화된 관로들
런타임에 페이지 구현	속도를 위해 페이지 미리 구현됨
획일적인 앱들 (예: 워드프레스)	API들과 마이크로서비스들(프론트/백 엔드 비결합)
풀스택(프론트/백 엔드 언어들)	단일 스택("전부 자바스크립트")

 

잼스택으로 할 수 있는 다른 것은?

이쯤 되면 당신의 사이트를 만드는 것의 혜택을 이해했길 바란다. 하지만 어쩌면 당신은 사용자 로그인 및 관계형 데이터베이스(RDBMS)없이 역동적인 내용들의 관리 또는 저장과 같은 백 엔드 처리 없이 어떻게 가장 기본적인 것들을 하는지에 대해 회의적일지도 모른다.

 

여기 잼스택으로 할 수 있는 몇 가지 예시들이 더 있다:

 

• 고정된 사이트를 서버리스 데이터베이스로 실행하기
• 서비스로서의 정체성(IDaaS): 상태 없는 인증
• 헤드리스 내용 관리 시스템들
• 서버리스 기능들을 고정 사이트에 사용하기
• 다목적 양식 관리
• 다플랫폼 공지 다루기
• 헤드리스 장바구니
• 반응성 있는 검색

 

결론

상황이 진화하는 것은 특히 IT에서는 필수불가결하다. 이 전에는 램프 스택이었고 그 다음엔 민 스택이었다. 이제는 잼스택이지만 5년에서 10년 사이에는 또 다른 것이 될 것이다. 이것들을 받아들이고 우리의 것으로 만드는 것이 최선이다!

 

뭔가를 하는 새로운 방식을 배우는 것은 귀찮은 일처럼 들리지만 개발에 대한 당신의 흥분을 재활성화시킬 수도 있다. 당신은 아마 서버 관리에 시간을 덜 쓰고 보안 문제를 더 걱정하는 자신을 발견하게 될 것이다. 개발에 노력이 덜 들고 고객들이 더 만족한다는 것을 알게될 수도 있다. 그리고 그 결과 심지어 더 경쟁력 있어질 수 있다.(그래서 임금 인상을 요구할 수 있을수도)

 

잼스택 기초

이 주제에 대한 글들이 더 나올지 지켜보라. 지난 몇 년간 잼스택을 다루는 동안 잼스택 스스로 한 분야이자 관행이 되었다. 우리는 당신이 잼스택 프로가 되기 위해 필요한 지침서들을 가져다주고 이 페이지에 있는 목차를 업데이트 할 것이다. 우리의 RSS 피드나 소셜 미디어에 관한 최신 유행을 따를 수도 있다.

 

 

다음에 올 것:

• 잼스택 관련 서비스들 나란히 비교
• 워드프레스를 고정 사이트로 어떻게 바꾸는지
• 자동화된 관로로 고정 사이트를 무료 호스팅 하기

 

그리고 더 많은 것들을 작업 중이다.