JAMstack 아키텍처 이해

웹 서버가 요청마다 HTML을 만들고 데이터베이스를 조회하는 방식에서는 페이지를 전달할 때 애플리케이션 서버가 함께 일합니다. 반대로 미리 만든 HTML 파일을 전달하고 필요한 데이터만 API로 받는 방식도 있습니다.

요청마다 처리하는 방식은 사용자별 응답과 최신 데이터를 만들기 쉽지만, 요청량에 맞춰 서버·DB·캐시를 운영해야 합니다. 어떤 방식이 알맞은지는 페이지의 공개 범위와 데이터 갱신 요구에 따라 달라집니다.

JAMstack은 정적 생성, CDN 캐시, API 분리, 배포 단순성을 기준으로 웹 구조를 나누는 아키텍처입니다.

JAMstack이라는 이름은 JavaScript, APIs, Markup에서 출발했습니다. 핵심 기준은 공개 페이지를 미리 만드는 사전 렌더링과, 페이지 제공을 필요한 백엔드 기능에서 분리하는 것입니다. JavaScript와 API는 상호작용·동적 데이터가 필요할 때 조합합니다.

이번 장에서는 JAMstack의 기본 개념과 구성 요소, 그리고 실무에서 체감되는 핵심 이점을 중심으로 학습합니다.

이를 통해 정적 사이트 생성기(Static Site Generator), Headless CMS, Serverless Functions 등 관련 기술을 이해하고, 공개 콘텐츠와 사용자별 작업을 나누는 방법을 배울 수 있습니다.

먼저 HTML은 문서 구조, CSS는 표현, JavaScript는 동작을 담당한다는 점과 HTTP 요청·응답을 알고 있어야 합니다. 이 장의 빌드 시점은 배포할 파일을 만드는 때이고, 요청 시점은 사용자가 페이지나 데이터를 요구하는 때입니다. 정적 파일에도 JavaScript가 들어갈 수 있으므로, 정적 배포가 곧 상호작용 없는 화면을 뜻하지는 않습니다.

---

JAMstack이란?

도구의 이름보다 “페이지를 언제 만들고, 무엇을 요청마다 확인해야 하는가?”를 먼저 살펴봅니다.

JAMstack의 이름에서 J는 JavaScript, A는 APIs, M은 Markup을 가리킵니다. 특정 프레임워크나 세 기술을 반드시 모두 사용해야 하는 제품 규격은 아닙니다. 사전 생성한 공개 HTML만으로 충분한 문서 사이트도 있고, 같은 페이지에 API로 읽는 개인 데이터를 더하는 서비스도 있습니다. 공식 설명은 사전 렌더링과 기능 분리를 핵심 원칙으로 설명합니다.

• J (JavaScript)
  • 클라이언트 JavaScript는 UI 상호작용을 담당하고, 비밀·권한 검증과 데이터 변경은 서버 API에서 처리합니다.
  • React, Vue, Angular와 같은 프론트엔드 프레임워크나 바닐라 JavaScript를 사용하여 동적인 UI와 사용자 상호작용을 구현합니다.
• A (APIs)
  • 데이터베이스 접근, 사용자 인증, 결제 처리 등 서버 측 로직이나 동적인 데이터가 필요한 기능은 재사용 가능한 API를 통해 구현합니다.
  • 이러한 API는 기존 서버, 마이크로서비스, 서드파티 서비스(예: Stripe, Auth0), Headless CMS, 또는 Serverless Functions(AWS Lambda, Azure Functions, Google Cloud Run functions 등)로 제공할 수 있습니다. 별도 API가 있다는 것은 백엔드가 사라졌다는 뜻이 아닙니다.
• M (Markup)
  • HTML 마크업과 CSS·JavaScript 같은 자산을 웹사이트 배포 전에 사전 빌드합니다(Pre-built). CSS는 스타일시트이며 마크업 언어가 아닙니다.
  • 정적 사이트 생성기(Static Site Generator, SSG)를 사용하면 마크다운(Markdown) 파일이나 CMS 데이터를 기반으로 배포할 페이지의 HTML을 빌드 시점에 만들 수 있습니다. 어떤 경로를 생성할지는 도구와 설정에 따라 정합니다.
  • 생성된 정적 파일들은 CDN(Content Delivery Network)에 배포됩니다.

JAMstack의 핵심 철학

JAMstack은 웹을 구성하는 요소들을 분리하고, 가능한 한 많은 작업을 빌드 시점에 처리하여 서버 측 렌더링(SSR)이나 동적 서버 처리의 의존성을 줄이는 것을 목표로 합니다.

LAMP나 MERN은 사용하는 기술의 조합을 가리키므로, 그 이름만으로 페이지가 요청마다 생성되는지 판단할 수는 없습니다. 예를 들어 MERN의 React 화면을 정적 파일로 배포하고 Express API를 분리할 수도 있습니다. 기술 목록과 렌더링·배포 방식을 구분해야 합니다.

---

JAMstack의 주요 이점

JAMstack 아키텍처는 다음과 같은 핵심적인 장점을 제공합니다.

---

JAMstack의 핵심 기술 스택

JAMstack을 구현하기 위해 사용되는 주요 기술들은 다음과 같습니다.

정적 사이트 생성기

정적 사이트 생성기(Static Site Generator, SSG)는 마크다운·CMS 등에서 가져온 콘텐츠와 템플릿을 조합해 배포할 HTML 페이지를 만듭니다. CSS·JavaScript 자산은 함께 처리하는 빌드 도구의 역할에 포함될 수 있습니다. 빌드에 넣은 공개 데이터는 그 시점의 스냅샷이므로, 원본 DB가 나중에 바뀌어도 이미 배포한 HTML이 저절로 바뀌지는 않습니다.

• 대표적인 SSG
  • Next.js (Static Export): React 프레임워크인 Next.js 전체는 SSR·CSR 등도 지원하지만, static export는 빌드 시 생성할 수 있는 결과를 정적 파일로 배포하는 모드입니다. 빌드에서 평가 가능한 GET Route Handler는 포함할 수 있고, 요청 정보에 의존하는 서버 기능은 이 모드와 구분합니다.
  • Astro: 여러 UI 프레임워크를 선택적으로 사용하고 정적 HTML을 우선 전송하는 콘텐츠 중심 프레임워크입니다.
  • Nuxt.js (Static Site Generation): Vue 기반. Next.js와 유사하게 SSG, SSR, CSR을 지원합니다.
  • Jekyll: Ruby 기반. 주로 블로그나 문서 사이트에 많이 사용됩니다.
  • Hugo: Go 기반. 매우 빠른 빌드 속도가 특징입니다.

Headless CMS

Headless CMS(콘텐츠 관리 시스템)는 콘텐츠 관리와 사용자에게 보여 주는 사이트 화면을 분리합니다. 보통 API로 콘텐츠를 전달하고, 실제 페이지의 표현은 별도 프론트엔드가 정합니다. “Headless”는 편집자를 위한 관리 화면까지 없다는 뜻은 아닙니다.

CMS의 공개 콘텐츠를 빌드할 때 읽거나, 실행 중 API로 읽도록 설계할 수 있습니다. CMS에서 발행한 변경을 정적 HTML에 반영하려면 재빌드·배포를 연결해야 합니다.

• 대표적인 Headless CMS
  • Strapi
  • Contentful
  • Sanity
  • DatoCMS
  • Decap CMS(이전 Netlify CMS)는 Git에 콘텐츠를 저장하는 CMS입니다. API 중심 CMS와 저장 방식이 다르지만 SSG의 콘텐츠 편집·빌드 흐름에 조합할 수 있습니다. 공식 개요에서 Git 기반 동작을 확인할 수 있습니다.

Serverless Functions

Serverless Functions(서버리스 함수)는 요청이나 이벤트에 반응해 코드를 실행하며, 서버의 준비와 실행 환경 관리를 플랫폼에 맡기는 방식입니다. 실행할 서버는 존재하고, 개발자는 코드·권한·비밀·시간 제한·데이터 연결을 설계해야 합니다.

API 계층을 구축하는 데 사용됩니다.

• 대표적인 Serverless Platforms
  • AWS Lambda
  • Azure Functions
  • Google Cloud Run functions(이전 Cloud Functions)
  • Netlify Functions
  • Vercel Functions

CDN

CDN(Content Delivery Network)은 여러 지역의 엣지에서 콘텐츠를 캐시하고 전달합니다. 이 장에서는 사전 빌드된 파일을 제공하는 역할에 집중하지만 CDN이 정적 파일만 다루는 것은 아닙니다. 캐시 유효 기간·갱신·무효화 정책에 따라 사용자가 받는 버전이 달라질 수 있습니다.

• 대표적인 CDN Providers
  • Cloudflare
  • Amazon CloudFront
  • Fastly
  • Netlify, Vercel (자체 CDN 내장)

---

JAMstack이 적합한 경우와 고려 사항

JAMstack은 많은 장점을 가지고 있지만, 모든 프로젝트에 적합한 것은 아닙니다.

JAMstack이 적합한 경우

• 콘텐츠 중심의 웹사이트: 블로그, 포트폴리오, 마케팅 페이지, 문서 사이트 등 모든 사용자에게 같은 공개 내용을 제공하고, 변경 후 재빌드·배포까지의 지연을 허용할 수 있는 경우.
• 랜딩 페이지 및 정적 웹사이트: 공개 콘텐츠를 캐시해 제공하려는 웹사이트. 실제 속도와 보안은 자산 크기·API·운영 설정도 확인합니다.
• 전자상거래 (일부): 상품 목록 등은 SSG로, 결제 등 동적인 부분은 API로 처리하는 하이브리드 방식.
• 이벤트성 웹사이트: 트래픽 폭증이 예상되는 일시적인 캠페인 페이지.
• 소규모/중규모 애플리케이션: 복잡한 서버 로직이나 사용자별 맞춤형 콘텐츠가 매우 빈번하게 필요한 경우가 아닌 애플리케이션.

고려 사항 (한계점)

• 빌드 시간: 콘텐츠나 페이지 수가 매우 많아지면 빌드 시간이 길어질 수 있습니다. (증분 빌드, 빌드 최적화 필요)
• 실시간 동적 콘텐츠: 사용자별로 완전히 다른 실시간 동적 콘텐츠(예: 실시간 채팅, 주식 시세)를 제공하려면 다소 복잡한 구성이 필요할 수 있습니다 (이 경우 WebSocket, Server-Sent Events 등 실시간 통신 기술과 API 조합 필요).
• 복잡한 인증/세션 관리: API의 인증·권한 검사, 쿠키를 전달할 도메인과 요청 정책, 사용자별 응답 캐시를 함께 설계해야 합니다. JAMstack이 세션 쿠키 사용을 금지하거나 JWT 사용을 의무화하는 것은 아닙니다.
• 개발자 경험 변화: 서버 중심 개발에 익숙한 개발자에게는 새로운 워크플로우와 도구에 적응하는 시간이 필요합니다.

---

JAMstack 아키텍처 요약

JAMstack을 설계할 때는 빌드 시점에 끝나는 일과 요청 시점에 처리해야 하는 일을 분리해야 캐시와 배포 흐름을 안정적으로 운영할 수 있습니다.

상품 페이지로 빌드 시점과 요청 시점 나누기

공개 상품 소개와 로그인한 사용자의 주문 내역이 함께 있는 쇼핑몰을 생각해 봅시다. 첫 개념도의 위쪽은 Git·CMS → 빌드 → 정적 파일·CDN → 브라우저라는 공개 파일 전달 경로입니다. 아래쪽은 브라우저 → 서버 API → 서버 데이터의 요청과, 그 결과가 돌아오는 응답 경로입니다. 두 경로가 서로 다른 시점에 일한다는 점이 핵심입니다.

개인 주문 API는 요청마다 접근 권한을 확인해야 합니다. OWASP 권한 검증 지침이 이를 설명합니다. 개인 응답을 공통 정적 파일로 만들거나 공용 CDN 캐시에 공유하지 않도록 별도 캐시 정책도 정합니다. 예를 들어 저장을 허용하지 않을 민감한 응답에는 서버가 Cache-Control: no-store를 보낼 수 있습니다. private는 공용 캐시 저장을 제한하되 개인 브라우저 캐시 저장은 허용하므로 no-store와 뜻이 다릅니다. MDN 캐시 지시자 설명을 참고하세요.

CMS를 수정한 뒤에도 이전 상품 소개가 보인다면 콘텐츠 원본 변경 → 새 빌드 성공 → 배포 버전 변경 → CDN·브라우저 캐시 갱신을 차례로 확인합니다. DB 변경이나 Git Push 하나만 확인해서는 새 파일이 사용자에게 전달됐다고 결론 낼 수 없습니다. 두 번째 개념도의 재검증 방식도 지원하는 서버·플랫폼에서 설정해야 하며, 정적 파일 호스팅이 자동으로 요청별 재생성을 해 주는 것은 아닙니다. Next.js의 static export는 ISR 같은 서버 기능을 지원하지 않습니다. 지원 범위를 확인해야 합니다.

직접 연습: 공개 파일과 사용자별 작업의 경계

1. 강의 소개는 모든 사용자에게 같고 하루 뒤 반영돼도 됩니다. 수강생별 결제 내역은 본인만 읽을 수 있어야 하며, 환불에는 서버 비밀 키가 필요합니다. 세 기능을 어디서 처리할지, 각각의 이유와 함께 설명하세요.
2. 오전 10:00에 가격 10,000원을 넣은 HTML을 빌드·배포했습니다. 10:02에 서버의 실제 가격은 12,000원으로 바뀌었고, 다음 HTML 빌드·배포는 10:05입니다. 추가 가격 조회 API가 없는 상태에서 10:04에 이 파일을 읽는 사용자는 어떤 가격을 보나요? 브라우저가 10,000원을 보내 주문할 때 서버는 어떤 값을 근거로 판단해야 하나요? 캐시와 새 HTML 배포만으로 해결되지 않는 이유도 설명하세요.
3. CDN의 공개 상품 HTML은 정상 제공되지만 주문 API가 503을 반환합니다. 상품 소개와 주문 완료 중 무엇을 보여 줄 수 있나요? API 실패를 빈 주문 목록이나 주문 성공으로 표시해도 되는지 판단하세요.

풀이 1: 공개 정보·개인 정보·비밀 구분

강의 소개는 허용된 하루 지연 범위 안에서 다시 빌드·배포하는 공개 HTML로 제공할 수 있습니다. 결제 내역은 인증된 사용자의 권한 범위를 서버 API에서 확인해 조회하고, 사용자별 응답을 공용 캐시에 섞지 않습니다. 환불은 비밀 키를 가진 서버에서 권한과 환불 조건을 검증해 실행합니다. 화면에서 버튼을 숨기는 것은 권한 검증이 아닙니다.

풀이 2: 오래된 표시와 주문의 기준 값

10:04에는 아직 10:00의 HTML을 제공하므로 표시 가격은 10,000원입니다. 원본 가격이 바뀌어도 이전 파일의 내용은 변하지 않습니다. 주문 서버는 작업 시점의 실제 가격 12,000원과 재고·권한 등 조건을 확인해야 합니다. 가격이 바뀌었다면 새 가격을 사용자에게 알리고 다시 확인받거나 해당 주문 요청을 거절하는 등 명시한 주문 정책으로 처리합니다. 브라우저가 보낸 금액을 그대로 결제 가격으로 신뢰해서는 안 됩니다.

10:05에 새 HTML을 배포하더라도 이미 열린 탭에는 이전 표시가 남을 수 있고 캐시 정책도 영향을 줍니다. 따라서 재빌드·캐시 갱신은 공개 표시의 최신성을 개선하는 수단이며 주문 시점의 서버 검증을 대신하지 않습니다.

풀이 3: 정적 화면 성공과 API 성공 분리

CDN이 제공하는 상품 소개는 보여 줄 수 있지만 API가 실패한 주문을 완료됐다고 표시할 수는 없습니다. 실패는 “주문을 처리하지 못함”이라는 별도 상태로 다루고, 빈 목록이라는 성공 응답으로 바꾸지 않습니다. 재시도를 제공할 때도 주문 생성처럼 데이터가 바뀌는 작업은 중복 처리 방지 정책을 함께 설계해야 합니다. 공개 파일 전달의 가용성과 API 작업의 가용성은 별도로 확인합니다.

이번 장에서는 현대 웹 개발 아키텍처의 주요 트렌드 중 하나인 JAMstack에 대해 학습했습니다.

JAMstack은 JavaScript, APIs, Markup을 조합해 사전 빌드된 정적 콘텐츠, 클라이언트 측 동작, API 기반 백엔드를 연결하는 아키텍처입니다.

이 장에서는 성능, 보안, 확장성, 비용, 개발 경험 측면의 장단점을 함께 살펴보았습니다.

정적 사이트 생성기(Next.js의 static export, Astro 등), CMS, Serverless Functions, CDN의 역할과, JAMstack을 적용할 때 확인할 최신성·인증·API 용량·비용 기준을 살펴보았습니다.

JAMstack은 정적 마크업, API, 클라이언트 JavaScript를 조합해 성능과 운영 단순성을 높이는 아키텍처입니다.

모든 프로젝트에 적합한 방식은 아니므로 콘텐츠 변경 빈도, 인증 요구, API 의존도, 배포 구조를 기준으로 적용 여부를 판단해야 합니다.

이 장의 JAMstack 배포 아키텍처는 정적 생성, API 연동, CDN 배포, 빌드 갱신 기준을 정리합니다.