2026년 4월 1일, Cloudflare가 조용히 폭탄 하나를 던졌습니다. 만우절에 발표된 이 소식은 처음엔 농담처럼 보였지만, 실제로는 진지한 프로젝트였습니다. 이름은 EmDash — TypeScript로 처음부터 새로 쓴 CMS로, 스스로를 “WordPress의 정신적 후계자(spiritual successor)”라고 부릅니다.
인터넷의 40% 이상을 구동하는 WordPress를 대체하겠다는 선언. 과연 EmDash는 무엇이고, WordPress와 무엇이 다르며, 실제로 써볼 만한 가치가 있을까요?
1. EmDash는 왜 등장했나? — WordPress의 어떤 한계가 계기가 됐을까?
WordPress의 나이
WordPress가 처음 만들어진 건 2003년입니다. 올해로 23살이 되는 이 플랫폼은 그 사이 세상이 얼마나 변했는지를 몸소 보여주는 살아있는 화석이기도 합니다. 탄생 당시에는 AWS EC2조차 없었고, 서버리스 컴퓨팅은 SF 소설에나 나올 법한 개념이었습니다.
지금은 다릅니다. 정적 파일 하나를 전 세계에 배포하는 데 사실상 비용이 들지 않고, 서버리스 함수는 밀리초 단위로 실행됩니다. 개발자들은 PHP보다 TypeScript를 먼저 배우고, LLM 에이전트가 코드를 짜는 시대가 됐습니다.
그런데 WordPress의 핵심 아키텍처는 여전히 2003년에 설계된 그 구조 위에서 돌아가고 있습니다.
플러그인 보안의 만성적 위기
Cloudflare가 EmDash를 만든 가장 직접적인 이유로 꼽은 것은 플러그인 보안입니다.
WordPress 보안 이슈의 96%가 플러그인에서 발생합니다. 2025년에는 역대 최다의 고위험 취약점이 WordPress 생태계에서 발견됐습니다. 이 숫자가 계속 나쁜 이유는 단순합니다. WordPress 플러그인은 PHP 스크립트이고, 이 스크립트는 WordPress와 동일한 실행 환경에서 돌아갑니다. 플러그인을 설치한다는 건 그 코드에게 데이터베이스 전체, 파일시스템 전체의 열쇠를 쥐여주는 것과 같습니다.
격리(isolation)가 없습니다. 검증되지 않은 입력 하나를 잘못 처리하면, 한 플러그인이 사이트 전체를 날릴 수 있습니다.
아키텍처 부채
여기서 더 근본적인 문제가 있습니다. Yoast SEO를 만든 Joost de Valk는 최근 글에서 WordPress의 진짜 병목을 이렇게 짚었습니다.
WordPress는 표면을 새로 칠하는 작업(redecorate)은 열심히 해왔지만, 실제로 뜯어고치는 작업(refactor)은 회피해왔다.
실제로 WordPress는 모든 콘텐츠 — 글, 페이지, 상품, 이벤트, 강좌 등 모든 것 — 를 wp_posts라는 단일 테이블에 몰아넣고, 메타데이터는 wp_postmeta에 단순한 키-값 쌍으로 저장합니다. 관계형 데이터베이스 위에서 사실상 스키마 없이 운영되는 구조입니다. 2003년 블로그 플랫폼으로서는 합리적인 선택이었겠지만, WooCommerce 같은 복잡한 플러그인이 올라오고 AI 에이전트가 콘텐츠를 다뤄야 하는 지금은 분명한 한계입니다.
Gutenberg가 블록 에디터에서 유지하는 구조화된 데이터는 저장할 때 HTML 주석으로 직렬화되어 post_content에 통째로 들어갑니다. API나 AI 에이전트가 이 구조를 다시 쓰려면 매번 파싱해야 합니다. WordPress VIP가 이를 위해 별도의 Block Data API를 만들어야 했을 정도입니다.
이런 구조적 문제들 — 단일 테이블 콘텐츠 모델, 격리 없는 플러그인, PHP 오토로더 부재 — 이 EmDash 탄생의 진짜 배경입니다.
Astro 인수, 그리고 EmDash — 우연이 아니다
EmDash를 이해하려면 먼저 Astro가 무엇인지 알아야 합니다.
Astro는 2021년 등장한 JavaScript 웹 프레임워크입니다. 당시 웹 개발의 주류는 React 기반 SPA(Single Page Application)였습니다. 모든 페이지를 JavaScript로 구동하다 보니 초기 로딩이 느리고, 간단한 블로그 하나에도 수백 KB의 JS 번들이 따라붙는 게 당연한 시대였습니다. Astro는 “대부분의 웹사이트에 JavaScript가 너무 많다” 는 단순한 문제의식에서 출발했습니다.
해법은 Islands Architecture입니다. 페이지의 대부분은 빌드 시점에 순수 HTML로 렌더링하고, 실제 상호작용이 필요한 부분(댓글 폼, 검색창 등)만 “Island”로 지정해 그 부분에만 JavaScript를 로드합니다. 결과적으로 콘텐츠 중심 웹사이트에서 다른 프레임워크보다 압도적으로 빠른 초기 로딩 속도를 냅니다. Unilever, Visa, NBC News가 채택하고, Webflow와 Wix도 자사 플랫폼의 기반으로 쓸 만큼 성장했습니다.
그리고 2026년 1월 16일, Cloudflare가 Astro를 인수했습니다. 같은 주에 AI 데이터 마켓플레이스 Human Native도 함께 인수했는데, 이 두 건의 동시 인수는 단순한 기술 투자가 아닙니다. 콘텐츠 생성(Astro) → 유통(Workers/CDN) → AI 시대 수익화(Human Native)로 이어지는 콘텐츠 생명주기 전체를 장악하려는 전략적 포석입니다. Vercel이 Next.js를 소유하고 생태계를 구축한 것과 같은 그림입니다.
타임라인을 보면 EmDash의 맥락이 더 선명해집니다.
- 1월 16일: Cloudflare, Astro 인수 발표
- 1월 중순: EmDash 개발 시작
- 4월 1일: EmDash v0.1.0 공개
인수 직후 개발이 시작된 것입니다. 기술적으로도 EmDash는 독립적인 CMS가 아니라 Astro integration, 즉 Astro 위에 CMS 레이어를 올린 것입니다. Cloudflare의 셈법은 간단합니다. Astro로 프레임워크를 확보하고, EmDash로 WordPress가 점유한 CMS 시장에 진입하고, 두 제품 모두 Cloudflare Workers에서 가장 잘 돌아가도록 설계해 플랫폼 사용을 자연스럽게 유도합니다. Matt Mullenweg가 “Cloudflare 서비스를 팔기 위해 만든 것”이라고 비판한 것도 이 맥락에서입니다.
물론 Cloudflare와 Astro 모두 “특정 플랫폼에 종속되지 않는다”고 공식적으로는 강조합니다. EmDash도 Node.js 서버 어디서든 배포 가능합니다. 하지만 핵심 기능인 플러그인 샌드박싱은 Cloudflare Workers 없이는 동작하지 않는다는 사실이, 그 주장의 한계를 드러냅니다.
2. WordPress vs EmDash: 무엇이 어떻게 다른가?
한눈에 보는 비교
| 항목 | WordPress | EmDash |
|---|---|---|
| 언어 | PHP | TypeScript |
| 기반 프레임워크 | 자체 | Astro |
| 라이선스 | GPL | MIT |
| 플러그인 보안 | 전체 접근 (Full trust) | 샌드박스 + 권한 선언 |
| 호스팅 방식 | 서버 기반 | 서버리스 (Cloudflare Workers 최적화) |
| 콘텐츠 저장 | wp_posts 단일 테이블 | 콘텐츠 타입별 독립 테이블 |
| 인증 | 아이디/비밀번호 | 패스키(Passkey) 기본 |
| AI 지원 | Abilities API (6.9 코어), MCP Adapter (별도 플러그인), WP AI Client (7.0 코어 예정) | MCP 서버 + Agent Skills 기본 내장 |
| 비주얼 에디터 | Gutenberg (블록 에디터) | 기본 텍스트 편집 수준 |
| 플러그인 생태계 | 6만+ 플러그인 | 이제 시작 |
| 커뮤니티 | 24년, 전 세계 규모 | 없음 |
플러그인 아키텍처의 근본적 차이
EmDash에서 플러그인은 각자 독립된 Dynamic Worker라는 샌드박스 안에서 실행됩니다. 플러그인이 무엇을 할 수 있는지는 manifest에 명시적으로 선언해야 합니다. 아래는 글이 발행될 때 이메일을 보내는 플러그인 예시입니다.
import { definePlugin } from "emdash";
export default () =>
definePlugin({
id: "notify-on-publish",
version: "1.0.0",
capabilities: ["read:content", "email:send"],
hooks: {
"content:afterSave": async (event, ctx) => {
if (event.collection !== "posts" || event.content.status !== "published") return;
await ctx.email!.send({
to: "[email protected]",
subject: `New post published: ${event.content.title}`,
text: `"${event.content.title}" is now live.`,
});
},
},
});
이 플러그인은 read:content와 email:send, 딱 두 가지 권한만 가집니다. 코드가 아무리 길어도 데이터베이스에 직접 접근하거나, 외부 임의 서버에 요청을 보내거나, 파일시스템을 건드리는 것은 구조적으로 불가능합니다. iOS 앱이 카메라 접근 권한을 요청하는 것과 같은 방식입니다.
서버리스와 스케일
WordPress는 서버를 프로비저닝해야 합니다. 트래픽이 없어도 서버는 돌아갑니다. EmDash는 요청이 없으면 비용이 0에 수렴하고, 트래픽이 몰리면 자동으로 수백만 인스턴스로 확장됩니다. Cloudflare Workers의 V8 isolate 아키텍처 덕분입니다.
콘텐츠 모델링
EmDash는 UI에서 직접 커스텀 콘텐츠 타입과 커스텀 필드를 정의할 수 있고, 각 타입은 독립된 테이블에 타입화된 컬럼으로 저장됩니다. WordPress에서 ACF나 CPT UI 같은 서드파티 플러그인 없이는 하기 어려운 일을 코어 기능으로 제공합니다.
AI 네이티브 설계
EmDash의 모든 인스턴스에는 다음이 기본 포함됩니다.
- 내장 MCP 서버: AI 에이전트가 관리자 UI와 동일한 작업을 직접 수행 가능
- Agent Skills: 플러그인 작성법, WordPress 테마 변환법 등을 에이전트에게 알려주는 구조화된 문서
- EmDash CLI: 미디어 업로드, 콘텐츠 검색, 스키마 관리를 CLI로 처리
x402 결제 표준도 내장되어 있어, AI 에이전트가 콘텐츠에 접근할 때 즉석 결제를 요구하는 것도 설정 몇 줄로 가능합니다.
3. 어떻게 시작하는가? — 설치, 배포, Playground
가장 빠른 시작: Playground
코드 한 줄 없이 EmDash 관리자 화면을 체험하고 싶다면 EmDash Playground에 바로 접속하면 됩니다. 로그인이나 설치 없이 관리자 UI를 탐색해볼 수 있어 감을 잡기에 좋습니다.
로컬 설치
터미널에서 아래 명령어 하나로 시작합니다.
npm create emdash@latest
Node.js 환경이라면 어디서든 실행할 수 있습니다. 로컬 개발 서버가 바로 뜨고, 관리자 화면, 콘텐츠 작성, 스키마 정의, 플러그인 설치까지 모두 로컬에서 테스트할 수 있습니다.
인증은 패스키가 기본이며, 패스키를 지원하지 않는 환경이라면 이메일 매직 링크로 폴백됩니다.
Cloudflare에 배포
Cloudflare 계정이 있다면 아래 버튼 클릭 한 번으로 Workers에 바로 배포됩니다.
https://deploy.workers.cloudflare.com/?url=https://github.com/emdash-cms/templates/tree/main/blog-cloudflare
Cloudflare for Platforms를 통해 수백만 개의 인스턴스를 독립적으로 운영하는 것도 가능합니다. 각 인스턴스는 트래픽이 없으면 자동으로 비용이 0이 됩니다.
Node.js 서버에 직접 배포
Cloudflare가 아닌 환경에서도 일반 Node.js 서버라면 배포할 수 있습니다. 다만 현재 자체 호스팅 환경에서는 샌드박스 플러그인이 동작하지 않는다는 점은 알아두어야 합니다. 플러그인 격리는 Cloudflare Workers 아키텍처에 의존하기 때문입니다.
WordPress에서 마이그레이션
기존 WordPress 사이트가 있다면 두 가지 방법으로 콘텐츠를 가져올 수 있습니다.
- WordPress 관리자 → 도구 → 내보내기에서 WXR 파일을 받아 EmDash에 임포트
- EmDash Exporter 플러그인을 WordPress에 설치해 직접 연동
글, 페이지, 미디어, 커스텀 포스트 타입까지 몇 분 안에 가져올 수 있습니다. 단, 콘텐츠만 마이그레이션됩니다. PHP로 작성된 테마와 플러그인은 별도로 재구현해야 합니다.
테마 개발
EmDash 테마는 Astro 프로젝트로 만들며 구성 요소는 다음과 같습니다.
- Pages: 홈, 블로그, 아카이브 등 라우팅 처리
- Layouts: 공통 HTML 구조
- Components: 내비게이션, 카드, 푸터 같은 재사용 요소
- Styles: CSS 또는 Tailwind 설정
- Seed file: CMS에게 어떤 콘텐츠 타입과 필드를 만들지 알려주는 JSON
테마 코드는 데이터베이스 작업을 할 수 없습니다. WordPress 테마의 functions.php처럼 모든 것이 가능한 환경이 아닙니다.
4. 커뮤니티와 전문가 반응 — 그리고 현실적인 한계
긍정적인 평가
Joost de Valk (Yoast SEO 창업자, Post Status 의장)는 EmDash를 “최근 몇 년간 콘텐츠 관리 분야에서 가장 흥미로운 사건”이라고 평가했습니다. 특히 AI 에이전트 친화적 설계, 구조화된 콘텐츠 저장 방식, 에지 배포 아키텍처가 “지금 우리가 실제로 일하는 방식에 맞게 설계됐다”고 봤습니다.
Brian Coords (WordPress 개발자)는 제로에서 기본 사이트까지 가는 속도가 놀라울 정도로 빠르다는 점, 코어에 데이터 모델링 UI가 내장된 점을 강점으로 꼽으면서도, 현재 수준은 베타가 아니라 알파에 가깝다고 했습니다.
The Register의 Tim Anderson은 보안 모델과 AI 통합이 주목할 만하며, 이 프로젝트가 “AI가 소프트웨어 설계를 어떻게 바꾸고 있는가”에 대한 핵심 질문을 던진다고 평가했습니다.
Matt Mullenweg의 반박
WordPress 창업자 Matt Mullenweg는 직접 블로그에 반박 글을 올렸습니다. 요점은 세 가지였습니다.
첫째, WordPress의 정신은 “퍼블리싱의 민주화”이며, 라즈베리파이부터 AWS까지 어디서나 같은 코드로 실행 가능한 것이 핵심이다. EmDash는 그 정신을 이어받지 않았다.
둘째, EmDash는 사실상 Cloudflare 서비스를 팔기 위해 만든 것이다. 자체 호스팅 시 샌드박스 플러그인이 불가하다는 점이 이를 뒷받침한다.
셋째, 플러그인이 WordPress 전체에 접근할 수 있다는 것은 버그가 아니라 기능이다. EmDash의 샌드박싱은 대부분의 플러그인이 실제로 하는 작업 앞에서 한계를 드러낼 것이다.
그러면서도 Agent Skills 구현은 “훌륭한 전략”이라고 인정하며 WordPress도 비슷한 방향을 준비 중이라고 밝혔습니다.
지적된 한계들
직접 써본 이들이 공통으로 지적한 현실적인 한계들이 있습니다.
생태계 부재. 6만 개 이상의 WordPress 플러그인과 수천 개의 테마를 대체할 생태계가 없습니다. 이벤트 캘린더 하나, 전자상거래 기능 하나를 만들려면 처음부터 직접 구현해야 합니다.
커뮤니티 없음. WordPress의 24년 역사에는 WordCamp, 전 세계 밋업, 수십만 개의 해결된 StackExchange 답변이 담겨 있습니다. 이건 코드로 복제할 수 없습니다.
비기술 사용자 진입장벽. 비주얼 에디터는 아직 기본 텍스트 수준입니다. 비기술 사용자가 혼자 사이트를 운영하기에는 아직 멀었습니다.
Cloudflare 종속. 가장 강력한 기능인 샌드박스 플러그인은 현재 Cloudflare Workers 환경에서만 동작합니다.
v0.1.0의 거친 느낌. 실제로 써본 이들은 “베타가 아니라 알파 수준”이라는 의견이 많습니다. 엣지 케이스에서 오류가 잦고, 리눅스 환경에서 패스키가 작동하지 않는 문제도 보고됐습니다.
5. AI 시대, CMS는 어디로 가는가
솔직히 EmDash를 보면서 가장 먼저 든 생각은 “이건 단순한 신규 CMS 발표가 아니다”였습니다. 제게 이것은 AI 에이전트 시대의 CMS가 무엇이어야 하는가에 대한 하나의 선언이자 모범답안이었습니다.
WordPress도 이미 AI 대응 중
물론 WordPress 진영도 손놓고 있지는 않습니다. 오히려 2025년 말부터 2026년 초까지 믿기 어려울 만큼 빠른 속도로 AI 인프라를 쌓아올리고 있습니다.
이 움직임의 시작은 사실 2025년 7월로 거슬러 올라갑니다. WordPress AI 팀은 “AI Building Blocks for WordPress”라는 이름으로 네 가지 공식 프로젝트를 발표했습니다. PHP AI Client SDK (어떤 AI 공급자에든 연결되는 공급자 불가지론적 PHP 라이브러리), Abilities API (WordPress의 기능을 AI가 발견하고 실행할 수 있도록 표준화된 중앙 레지스트리), MCP Adapter (Abilities를 Model Context Protocol로 변환하는 어댑터), AI Experiments Plugin (위 세 가지를 통합한 실험용 플러그인)이 그것입니다. 전략은 명확했습니다. “canonical first, Core when ready” — 먼저 Composer 패키지와 플러그인으로 배포하고, 검증이 되면 코어에 병합한다는 철학입니다.
WordPress 6.9 (2025년 12월 출시) 에서는 이 중 Abilities API가 코어에 정식 포함됐습니다. WordPress 코어, 플러그인, 테마가 자신이 할 수 있는 일들을 표준화된 형식으로 등록하면, AI 에이전트가 이를 자동으로 발견하고 실행할 수 있게 됩니다. 6.9에는 core/get-site-info, core/get-user-info, core/get-environment-info 세 가지 기본 Ability가 포함됩니다.
MCP Adapter는 현재 코어 바깥의 공식 플러그인/패키지로 제공됩니다. GitHub 릴리스 페이지에서 플러그인을 설치하면 WordPress 사이트가 즉시 MCP 서버가 되어 Claude Desktop, Claude Code, Cursor, VS Code 같은 AI 클라이언트와 연결됩니다. 코어 병합 여부는 아직 열린 질문으로, 커뮤니티 논의가 진행 중입니다. (아, 물론 현재도 워드프레스는 REST API를 통해 얼마든지 MCP 연동이 가능하고 기존에 나와있는 MCP 서버 솔루션들도 여럿 있습니다)
Agent Skills도 빼놓을 수 없습니다. 2026년 1월, WordPress는 AI 에이전트가 WordPress 코드베이스를 다루는 방법을 가르쳐주는 공식 Agent Skills를 github.com/WordPress/agent-skills에 공개했습니다. npx openskills install WordPress/agent-skills 한 줄로 설치하면 에이전트가 WordPress 코딩 패턴, Playground를 이용한 테스트 방법 등을 즉시 이해합니다. EmDash가 Agent Skills를 강점으로 내세웠지만, WordPress도 이미 같은 방향을 걷고 있었던 셈입니다.
WordPress 7.0 (2026년 4월 출시 예정) 은 WordPress 역사상 처음으로 AI가 코어에 내장되는 버전입니다. 핵심은 WP AI Client입니다. 플러그인 없이 WordPress 자체가 OpenAI, Anthropic Claude, Google Gemini 등 어떤 AI 공급자에게든 프롬프트를 보내고 결과를 받을 수 있는 PHP API가 코어에 들어갑니다. Settings → Connectors 화면에서 API 키를 한 번만 설정하면, 그 위에 만들어진 모든 플러그인의 AI 기능이 동일한 인증 정보를 공유합니다. 7.0에는 이 외에도 Client Side Abilities API, 실시간 공동 편집, 비주얼 리비전 비교, 관리자 대시보드 리디자인 등이 포함됩니다.
WordPress가 가진 가장 강력한 무기인 커뮤니티와 생태계가 이 AI 인프라 위에서 전환된다면, EmDash 같은 신규 플랫폼이 따라오기 어려운 경쟁 우위가 생깁니다. (워드프레스의 AI 전환 행보는 저도 관심있게 지켜보는 영역이기도 합니다)
그러나 Joost의 경고는 새겨들을 만하다
Joost de Valk가 한 말이 계속 머릿속에 걸립니다. WordPress는 표면을 새로 칠하는 데는 부지런했지만, 아키텍처 부채는 계속 쌓아왔다는 것. Gutenberg를 8년째 완성해가면서 그 아래 데이터 모델은 그대로 두고 있다는 것.
최근 WordPress가 프론트엔드(블록 에디터, 사이트 에디터, 전체 편집 경험)에 집중하는 동안 타입화된 데이터 모델, 구조화된 콘텐츠 저장, 플러그인 권한 범위 지정 같은 아키텍처 과제들은 우선순위에서 밀려났습니다. 어쩌면 EmDash가 들어온 빈틈은 기술력의 차이가 아니라, WordPress가 오랫동안 미뤄온 결정들이 만들어낸 공간일지도 모릅니다.
WordPress가 AI 시대에도 40%의 웹을 계속 지탱하려면, 프론트엔드 인터페이스의 완성만큼이나 이 아키텍처 문제들을 진지하게 다뤄야 합니다. 7.0을 향한 행보가 어떤 방향으로 가는지 지켜봐야 할 이유가 여기에 있습니다.
EmDash를 어떻게 볼 것인가
EmDash가 WordPress를 대체할 가능성은 현재로선 낮습니다. 생태계도, 커뮤니티도, 비기술 사용자를 위한 경험도 아직 갖추지 못했습니다. 하지만 미래의 CMS가 어떤 문제를 해결해야 하는지를 매우 명확하게 보여주는 실험입니다. AI 에이전트가 사이트를 만들고 관리하는 세상, 에지에서 서버리스로 콘텐츠가 서빙되는 세상, 플러그인 하나 잘못 설치했다가 사이트 전체가 털리는 일이 없어야 하는 세상.
그 세상이 오고 있다면, EmDash는 적어도 올바른 방향을 가리키고 있습니다.
직접 해보세요
이 글을 여기까지 읽었다면, 직접 한번 설치해보는 것을 권합니다.
npm create emdash@latest
또는 먼저 Playground에서 관리자 화면을 체험해보세요. WordPress를 오래 써온 분이라면 익숙한 UI에 살짝 놀라실 겁니다. 그리고 WordPress와 직접 비교해보면서 무엇이 더 좋고 무엇이 아쉬운지 스스로 판단해보시기를 바랍니다.
결국 좋은 도구인지는 직접 써봐야 알 수 있으니까요. 🤔
참고 자료
Astro & Cloudflare 인수
- Cloudflare Blog: Astro joins Cloudflare
- Astro Blog: The Astro Technology Company joins Cloudflare
- Cloudflare Press Release: Cloudflare Acquires Astro
EmDash 관련
- Cloudflare Blog: Introducing EmDash
- EmDash GitHub Repository
- EmDash Playground
- The Register: Cloudflare previews EmDash
- Brian Coords: EmDash First Thoughts
커뮤니티 반응
- Matt Mullenweg: EmDash Feedback
- Joost de Valk: WordPress needs to refactor, not redecorate
- The CMS is dead. Long live the CMS.
WordPress AI 대응
- Make WordPress AI: AI Building Blocks for WordPress (2025년 7월, 공식 로드맵 발표)
- WordPress Developer Blog: From Abilities to AI Agents — Introducing the WordPress MCP Adapter
- WordPress News: New AI Agent Skill for WordPress
- Make WordPress Core: Introducing the AI Client in WordPress 7.0
- WordPress 7.0 Beta 1
- Make WordPress AI Team Updates
- WordPress/mcp-adapter GitHub
- WordPress/agent-skills GitHub
※ 이 글은 Usefulparadigm blog에도 게재되었습니다.
