발표 개요와 웹 개발 흐름
발표자가 JAMstack이 무엇이고 왜 쓰는지, 동적 콘텐츠 처리와 현재·미래까지 다룰 것임을 예고한다. 데이터베이스-앱서버-웹서버가 강하게 결합된 전통적 웹 개발 구조의 의존성·운영 비용 문제를 먼저 짚는다.
서버 유지보수 비용을 줄이는 서버리스 구조와 AWS 람다·파이어베이스 같은 펑션 단위 서비스의 등장을 설명한다. 각 계층이 독립 서비스로 분리되면서 JAMstack이 이 서버리스 구조에서 파생됐음을 정리한다.
JAMstack의 잼은 JavaScript·API·Markup의 약자로, 동적 요소는 JS가, 서버/DB 역할은 재사용 가능한 API가 맡는다. 핵심은 마크업과 콘텐츠를 정적 페이지로 미리 다 생성해 렌더링한다는 점이며, 이 사전 생성 개념을 강조한다.
정적 페이지 사전 생성으로 공격 노출면이 적어 안정성이 높고, CDN 캐시 덕에 성능이 빠르며, 호스팅 비용이 저렴하고, 정적 산출물이라 빌드·배포 자동화가 쉽다는 네 가지 장점을 차례로 제시한다.
워드프레스의 DB 연결·캐시 무효화 이슈를 JAMstack으로 해결하고 초기 로딩이 크게 빨라진 Smashing Magazine 사례를 든다. FE랩의 TOAST UI 브랜드 사이트는 기존 마크다운을 그대로 개츠비 콘텐츠로 써서 수월하게 개발·배포한 경험을 공유한다.
SSG는 빌드 산출물로 정적 페이지를 만드는 프레임워크로, 리액트 기반 개츠비·Next.js, 뷰 기반 넉스트 등이 있다. 개츠비가 JSON·YAML·마크다운을 GraphQL 노드로 변환해 리액트 컴포넌트에서 조회·조합하여 페이지를 생성하는 과정을 설명한다.
장바구니·검색처럼 경우의 수가 방대한 동적 콘텐츠는 모든 페이지를 미리 만들 수 없어 서드파티 API가 필요하다. 검색 API 서비스 알골리아를 개츠비 플러그인으로 빌드 시 레코드 등록해 TOAST UI 사이트에서 동적 검색을 구현한 예를 시연한다.
콘텐츠가 많거나 변경이 잦으면 빌드 시간이 길어지는 한계를 지적하고, 변경분만 다시 빌드하는 점진적 빌드를 해법으로 든다. 개츠비가 20분 빌드를 1분·10초로 줄인 사례와 Next.js 도입을 소개하며 JAMstack의 미래가 여기에 달렸다고 정리한다.