Storyblok는 콘텐츠 편집자가 실제로 편집 중인 내용을 볼 수 있는 몇 안 되는 헤드리스 CMS 중 하나입니다. 이 단 하나의 기능이 전체 개발자-편집자 관계를 바꾼다는 건 말할 것도 없습니다. 2026년 3월 Series C 펀딩에서 8천만 달러를 조성하고 워크플로우 자동화를 출시한 후, Storyblok이 실제로 무엇을 잘하는지, 어디가 부족한지, 그리고 다음 프로젝트에 적합한지 이해할 가치가 있습니다.
Storyblok이란?
Storyblok은 2017년 오스트리아 린츠에서 CEO 도미닉 앙거러(Dominik Angerer)와 CTO 알렉산더 파이글슈토퍼(Alexander Feiglstorfer)에 의해 설립된 내장 비주얼 에디터가 있는 헤드리스 CMS입니다. 블록(Bloks)이라고 불리는 컴포넌트 기반 아키텍처를 사용하며 REST 및 GraphQL API를 통해 콘텐츠를 제공합니다. Adidas, Tesla, Oatly이 사용하고 있으며, Storyblok은 Series C 라운드를 통해 총 1억 3,800만 달러의 펀딩을 조성했습니다.
헤드리스 CMS는 콘텐츠를 프론트엔드에서 분리합니다. API를 통해 콘텐츠를 관리하고 React, Vue, 또는 Astro 앱이 이를 소비합니다. 이 부분은 Contentful, Sanity, Strapi 및 다른 모든 헤드리스 옵션과 동일합니다. Storyblok을 다르게 만드는 것은 비주얼 에디터입니다.
우리는 Sanity를 포함한 여러 헤드리스 CMS에서 4개의 프로덕션 웹사이트를 운영하고 있습니다(Sanity는 이 블로그를 지원합니다). 실제 경험에서 Storyblok은 다음과 같이 비교됩니다: 비주얼 에디터는 개발자와 콘텐츠 팀 간의 왕복을 크게 줄입니다. 편집자가 양식을 채우고 "이게 어떻게 생겼을까?"라고 묻는 대신, 실제 페이지를 봅니다. 이는 마케팅 홍보 문구가 아니라 진정한 워크플로우 개선입니다.
핵심 아키텍처는 두 가지 개념으로 나뉩니다: Stories(페이지 또는 콘텐츠 항목)와 Bloks(히어로 섹션, 기능 그리드, CTA 같은 재사용 가능한 컴포넌트). 개발자는 Blok 스키마를 정의하고 편집자는 이를 Stories로 드래그 앤 드롭합니다. 콘텐츠는 Content Delivery API를 통해 프론트엔드에 도달합니다.
Adidas와 Tesla 외에 주목할 만한 고객으로는 Virgin Media O2, dm-drogerie markt, Oatly, Spendesk, Panini이 있습니다. Storyblok이 모든 주요 옵션과 어떻게 비교되는지 자세히 알아보려면 우리의 헤드리스 CMS 비교를 확인하세요.
Storyblok 비주얼 에디터는 어떻게 작동하나요?
Storyblok의 비주얼 에디터는 프론트엔드를 iframe에 로드하고 각 컴포넌트의 편집 가능한 영역에 오버레이를 그립니다. 콘텐츠 편집자는 모든 Blok에 대한 클릭 투 에디트 기능이 있는 방문자가 정확히 보게 될 내용의 라이브 미리보기를 봅니다. 이를 위해서는 프론트엔드 애플리케이션에 StoryblokBridge JavaScript 라이브러리가 설정되어야 합니다.
이것이 Storyblok을 Contentful의 양식 기반 접근, Sanity의 스키마-애즈-코드 접근, 또는 Strapi의 관리 패널과 구별하는 기능입니다. 이러한 CMS는 편집자에게 필드가 있는 양식을 제공합니다. Storyblok은 편집자에게 실제 페이지를 제공합니다.
Iframe 아키텍처
내부 작동 원리는 다음과 같습니다: 편집자가 Storyblok 대시보드에서 Story를 열면, 비주얼 에디터는 프론트엔드 애플리케이션을 iframe 내에 로드합니다. Storyblok은 각 Blok의 데이터에 _editable 속성을 주입하고(초안 콘텐츠에만 해당), StoryblokBridge JavaScript 라이브러리는 변경 사항을 감시합니다. 편집자가 컴포넌트를 클릭하면, 브리지는 부모 Storyblok 윈도우와 통신하여 올바른 필드 에디터를 엽니다.
결과는 어떨까요? 편집자는 히어로 섹션을 직접 클릭하여 헤드라인을 편집합니다. 가격 섹션 아래에 새로운 testimonial Blok을 드래그합니다. 미리보기에서 변경 사항이 즉시 반영됩니다. "저장하고 스테이징 사이트 확인" 루프가 없습니다.
주의할 점: 비주얼 에디터는 초안 콘텐츠에서만 작동하고 발행된 콘텐츠에서는 작동하지 않습니다. 미리보기 URL은 초안 데이터를 가져오는 앱 버전을 가리켜야 합니다. 이는 설정 중에 사람들을 놀라게 합니다.
StoryblokBridge 설정
다음은 Next.js App Router 프로젝트의 일반적인 설정입니다. @storyblok/react가 설치되어 있어야 합니다:
그런 다음 레이아웃을 공급자로 감싸고 StoryblokStory 컴포넌트를 사용하여 라이브 편집을 활성화합니다:
StoryblokStory 컴포넌트는 브리지 연결을 자동으로 처리합니다. iframe 리스너를 등록하고, _editable 속성을 Blok에 적용하며, 비주얼 에디터에서 클릭 투 에디트를 활성화합니다. 수동으로 연결할 필요가 없습니다.
Storyblok의 컴포넌트 아키텍처 (Blok과 Stories)
Storyblok은 두 가지 핵심 개념을 사용하여 콘텐츠를 구성합니다: Stories(페이지 또는 콘텐츠 항목)와 Bloks(히어로 섹션, 기능 그리드, CTA 같은 재사용 가능한 컴포넌트). 개발자는 Storyblok 대시보드에서 Blok 스키마를 정의하고 편집자는 Blok을 Stories로 드래그 앤 드롭하여 페이지를 구성합니다.
LEGO처럼 생각해 보세요. Stories는 기초판입니다. 당신이 만들고 있는 페이지입니다. Bloks는 개별 블록입니다. 히어로 섹션, testimonial 카드, 가격 책정 테이블입니다. 각 Blok 유형이 어떤 필드를 가져야 하는지(헤드라인, 이미지, CTA 텍스트) 정의하면 편집자는 이를 서로 연결합니다.
Stories: 당신의 콘텐츠 항목
Storyblok의 모든 페이지, 기사, 또는 콘텐츠 항목은 Story입니다. Stories는 폴더 구조 내에 있고(파일 시스템처럼), 각 Story는 URL에 매핑되는 슬러그를 가집니다. Story의 본문은 Blok으로 구성됩니다. 기본적으로 컨테이너입니다.
Stories는 또한 비페이지 콘텐츠를 보유할 수 있습니다. 당신은 네비게이션 링크, 푸터 텍스트, 소셜 미디어 URL을 저장하는 "site-settings"라는 Story를 가질 수 있습니다. 유연성은 Sanity에서 싱글톤 문서를 사용하는 방식과 유사합니다.
Bloks: 재사용 가능한 구성 요소
Blok은 두 가지 종류가 있습니다: 중첩 가능(nestable)과 콘텐츠 타입(root-level). 콘텐츠 타입 Blok은 Story의 최상위 스키마를 정의합니다("Page" 또는 "BlogPost" 같은). 중첩 가능 Blok은 편집자가 Story의 본문으로 드래그하는 컴포넌트입니다. 히어로 섹션, 이미지 갤러리, FAQ 아코디언입니다.
각 Blok은 필드를 정의하는 스키마를 가집니다. Storyblok 대시보드의 "Components" 아래에서 이를 만듭니다(코드가 아닙니다. 이는 Sanity의 스키마-애즈-코드 접근과의 핵심 차이입니다).
실무 콘텐츠 모델링
다음은 Management API를 통해 정의할 때 Hero Blok 스키마가 어떻게 보이는지입니다:
그리고 이 Blok을 렌더링하는 React 컴포넌트입니다:
storyblokEditable(blok) 호출은 비주얼 에디터에서 클릭 투 에디트를 가능하게 하는 것입니다. 이것이 없으면 컴포넌트는 잘 렌더링되지만 편집자는 필드를 편집하기 위해 클릭할 수 없습니다. 잊기 쉽고 디버그하기 어렵습니다.
Storyblok API: REST 대 GraphQL 대 Management
Storyblok은 세 가지 API를 제공합니다: Content Delivery API(REST, 대부분의 프로젝트에 권장), GraphQL API(읽기 전용, 선택적 필드 가져오기가 필요할 때 유용), Management API(마이그레이션 및 대량 업데이트 같은 프로그래밍 방식의 콘텐츠 작업). Storyblok은 새로운 프로젝트의 경우 REST를 권장합니다.
대부분의 헤드리스 CMS 가이드는 API 레이어를 완전히 건너뜁니다. 이는 실수입니다. 선택하는 API는 빌드 시간, 캐싱 전략, 속도 제한 여유에 영향을 미칩니다.
Content Delivery API (REST)
이것이 기본 API이며 시간의 90%를 사용할 API입니다. 필터링, 정렬, 페이지 매김, Stories 간 관계 해결을 지원합니다. 속도 제한은 관대합니다: 유료 요금제에서 초당 50개 요청입니다.
GraphQL API
GraphQL API는 읽기 전용이며 다른 속도 제한이 있습니다(초당 100개 복잡성 포인트). 강력한 타입을 원하고 전체 Story 페이로드가 필요하지 않을 때 유용합니다. 필요한 정확한 필드만 요청할 수 있습니다.
Management API
Management API는 Storyblok 공간의 CRUD 작업을 처리합니다: Stories 만들기, 컴포넌트 스키마 업데이트, 자산 관리, 마이그레이션 실행. CI/CD 파이프라인, 대량 콘텐츠 업데이트, 또는 Storyblok 주변의 사용자 지정 도구 구축에 이를 사용합니다.
어떤 API를 사용해야 하나요?
대부분의 Next.js, Nuxt, 또는 Astro 프로젝트의 경우, storyblok-js-client 또는 공식 SDK가 있는 REST Content Delivery API가 필요한 모든 것을 처리합니다. 콘텐츠 모델이 복잡하고 필요하지 않은 많은 필드가 있는 깊게 중첩된 구조를 가져올 때 GraphQL에 도달합니다.
2026년 Storyblok 가격 책정
...