EmDash: WordPress의 전제를 다시 쓰는 CMS

AI 코딩 에이전트 시대에 더 무서운 변화는 “새 기능을 빨리 붙이는 것”이 아닙니다.
진짜 변화는 오래된 소프트웨어의 설계 한계를 더 이상 존중하지 않아도 된다는 데 있습니다.

Cloudflare의 EmDash가 흥미로운 이유가 바로 여기 있습니다. WordPress는 여전히 웹의 거대한 비중을 차지합니다. 2026년 4월 기준 W3Techs 통계에서 WordPress는 전체 웹사이트의 약 43%대, 알려진 CMS 중 약 60% 안팎을 차지합니다. 그런데 그 성공의 대가로, 플러그인과 테마가 코어와 너무 깊게 얽힌 구조도 함께 굳어졌습니다. EmDash는 이 문제를 “운영 잘하자” 수준으로 덮지 않고, 애초에 플러그인이 위험해질 수밖에 없는 실행 모델 자체를 폐기합니다. (W3Techs)

이 프로젝트가 왜 지금 나왔나

Cloudflare가 문제 삼는 지점은 분명합니다. WordPress 보안 이슈의 96%가 플러그인에서 나오며, WordPress 플러그인은 기본적으로 데이터베이스와 파일시스템에 직접 접근할 수 있는 PHP 코드입니다. 즉, 플러그인을 설치하는 순간 “이 코드가 모든 입력을 완벽하게 방어할 것”이라는 낙관에 전체 사이트를 맡기는 구조입니다. Patchstack의 2025 보고서도 취약점의 96%가 플러그인에서 발견됐다고 집계합니다. EmDash는 이걸 개발자 실수의 문제가 아니라 권한 경계가 없는 아키텍처의 문제로 보고 있습니다. (The Cloudflare Blog)

여기서 Cloudflare가 들고 온 해법이 Dynamic Workers입니다. Dynamic Workers는 런타임에 코드를 동적으로 로드해 별도 샌드박스에서 실행하는 방식으로, Cloudflare는 이를 신뢰할 수 없는 코드나 AI 생성 코드를 격리 실행하는 용도로 소개합니다. EmDash는 바로 이 메커니즘을 플러그인 시스템에 적용해, 플러그인을 “같은 프로세스 안의 PHP 코드”가 아니라 “명시된 권한만 가진 별도 워커”로 바꿉니다. (Cloudflare Docs)

EmDash가 실제로 바꾸는 것

첫 번째는 플러그인 보안 모델입니다.
EmDash 플러그인은 manifest에 필요한 capability를 선언해야 하고, 시스템은 그 선언에 맞는 binding만 제공합니다. 예를 들어 read:content, email:send만 선언한 플러그인은 그 두 가지 외에는 못 합니다. 외부 네트워크가 필요하면 그것도 특정 호스트 수준으로 명시해야 합니다. 이건 WordPress의 “설치하면 거의 모든 권한을 가진다”와 정반대입니다. Cloudflare 글이 OAuth 스코프 비유를 쓴 이유도 정확합니다. (The Cloudflare Blog)

두 번째는 호스팅 모델입니다.
EmDash는 Cloudflare Workers·D1·R2 조합에서 가장 잘 돌아가도록 설계됐지만, Node.js 서버와 SQLite 기반으로도 실행할 수 있습니다. 즉 “서버리스 우선”이지만 “Cloudflare 전용 SaaS”는 아닙니다. 이 점은 꽤 중요합니다. 개발자 입장에서는 현대적인 배포 모델을 쓰면서도, 완전한 플랫폼 종속에 대한 거부감을 줄일 수 있기 때문입니다. 다만 샌드박스 플러그인 기능은 Dynamic Workers에 의존하므로, 그 장점의 핵심은 Cloudflare에서 가장 잘 살아납니다. README도 Dynamic Workers가 현재는 유료 계정에서 제공된다고 명시합니다. (GitHub)

세 번째는 프론트엔드/테마 모델입니다.
EmDash는 Astro 위에 구축되어 있고, 테마도 Astro 프로젝트로 만듭니다. Pages, Layouts, Components, Styles, Seed file로 구성되는 방식이라 프론트엔드 개발자에게 훨씬 익숙합니다. WordPress에서 테마가 functions.php를 통해 사실상 실행 환경 전체에 손댈 수 있었다면, EmDash 테마는 DB 작업을 할 수 없도록 경계를 둡니다. 즉 “표현 계층은 표현 계층답게” 분리합니다. (The Cloudflare Blog)

네 번째는 콘텐츠 모델입니다.
README 기준 EmDash는 WordPress식 HTML 중심 저장 대신 Portable Text 기반의 구조화된 JSON 콘텐츠를 사용합니다. 이건 단순한 저장 포맷 변경이 아닙니다. 웹페이지, 이메일, 앱, API 응답 등으로 콘텐츠를 재활용하기 쉬워지고, 렌더링과 저장이 느슨하게 결합됩니다. WordPress가 “게시용 HTML 중심 CMS”였다면, EmDash는 좀 더 “구조화된 콘텐츠 플랫폼” 쪽에 가깝습니다. (GitHub)

다섯 번째는 AI 네이티브 운영 모델입니다.
Cloudflare는 EmDash를 단순히 “AI로 만들었다”가 아니라 “AI가 다루기 쉬운 CMS”로 설계했습니다. Agent Skills, CLI, 내장 MCP 서버를 제공해서 AI 도구가 콘텐츠 검색, 스키마 관리, 미디어 업로드, 플러그인/테마 작성까지 프로그램적으로 다룰 수 있게 합니다. 이건 꽤 전략적입니다. 앞으로 CMS 관리 작업 중 많은 부분이 사람이 UI에서 클릭하는 대신, 에이전트가 API/CLI/MCP를 통해 처리하게 될 가능성이 높기 때문입니다. (The Cloudflare Blog)

아키텍처를 개발자 관점에서 보면

EmDash의 핵심은 “CMS 코어, 콘텐츠 저장, 렌더링, 확장 코드”를 서로 다른 책임으로 분리한 데 있습니다.

이 구조의 의미는 단순합니다.

WordPress:

• 코어와 플러그인이 같은 집에 산다.
• 문 하나만 열리면 집 전체가 노출된다.

EmDash:

• 플러그인은 별도 방에 격리된다.
• 방마다 출입증이 다르다.
• 출입증에 적힌 문만 열 수 있다.

이 차이는 “보안이 조금 더 좋다”가 아니라, 플랫폼 운영자가 생태계를 믿을 수 있는 방식이 달라진다는 뜻입니다. Cloudflare가 marketplace lock-in까지 연결해서 설명한 이유도 여기에 있습니다. 플러그인의 행동 경계가 명확하면, 중앙 마켓플레이스가 모든 신뢰를 독점할 필요가 줄어듭니다. (The Cloudflare Blog)

코드로 보면 어떤 감각인가

Cloudflare가 보여준 예시는 게시 후 이메일 알림 플러그인입니다.

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: "editors@example.com",
          subject: `New post published: ${event.content.title}`,
          text: `"${event.content.title}" is now live.`,
        });

        ctx.log.info(`Notified editors about ${event.content.id}`);
      },
    },
  });

개발자 입장에서 중요한 건 문법보다 권한 모델이 코드에 드러난다는 점입니다.
예전 CMS 플러그인은 “할 수 있는 일이 너무 많아서 위험”했는데, EmDash 플러그인은 “하려는 일이 선언되어 있어서 검토 가능”합니다. 코드 리뷰, 보안 감사, 정책 enforcement가 훨씬 쉬워집니다. 이건 엔터프라이즈 호스팅이나 멀티테넌트 CMS 플랫폼에서 특히 큰 장점입니다. (The Cloudflare Blog)

이 프로젝트가 진짜 무서운 이유

저는 이걸 AI 코딩의 킬러 유즈케이스 후보로 보는 쪽입니다.
이유는 “2개월 만에 CMS를 만들었다”가 아닙니다. 중요한 건 레거시 시스템에서 가장 고치기 어려운 층을, AI를 활용해 처음부터 재설계했다는 데 있습니다.

보통 AI 코딩 담론은 생산성 향상에 머뭅니다.
하지만 EmDash는 다른 메시지를 던집니다.

• 오래된 아키텍처를 패치하는 대신
• 현재의 런타임 모델과 보안 모델에 맞는 새 설계를 만들고
• 그것을 오픈소스로 바로 공개하고
• AI가 계속 확장 가능한 형태로 운영 도구까지 붙였다

이건 “코드 작성 속도”보다 아키텍처 재작성의 경제성이 달라졌다는 신호에 가깝습니다. Cloudflare가 이전에 Next.js 재구축 사례와 Dynamic Workers를 연달아 내놓은 흐름까지 보면, 이건 단발성 데모라기보다 “AI + isolate 런타임 + 개발자 플랫폼” 전략의 일부로 읽힙니다. (The Cloudflare Blog)

그럼 WordPress 점유율을 진짜 뺏을 수 있나

제 판단은 이렇습니다.

단기적으로는 어렵고, 특정 세그먼트에서는 꽤 위협적일 수 있습니다.

왜 단기적으로 어렵냐면, WordPress의 해자는 기술보다 생태계이기 때문입니다. WordPress는 엄청난 설치 기반, 수많은 테마/플러그인, 에이전시 네트워크, 저렴한 운영 인력, 익숙한 편집 경험을 이미 갖고 있습니다. EmDash는 이제 막 v0.1.0 프리뷰가 나온 상태이고, 리포지토리도 공개 직후 초기 단계입니다. 즉 지금 당장 “대체재”라기보다 “아키텍처 선언문”에 더 가깝습니다. (The Cloudflare Blog)

하지만 위협적인 세그먼트는 분명합니다.

첫째, 새로 만드는 콘텐츠 사이트입니다.
특히 “굳이 PHP를 도입하고 싶지 않은 팀”, “Astro/TypeScript 친화적인 팀”, “멀티사이트를 서버리스로 운영하고 싶은 플랫폼 사업자”에게는 EmDash가 꽤 설득력 있습니다. (The Cloudflare Blog)

둘째, 보안 민감한 플러그인 생태계가 필요한 팀입니다.
예를 들면 내부 퍼블리싱 플랫폼, 미디어 그룹, 고객별 CMS 인스턴스를 대량 운영하는 호스팅 사업자처럼 “확장은 필요하지만 서드파티 코드에 전체 권한을 주기 싫은” 경우입니다. 이 시장에서는 EmDash의 capability 기반 샌드박스가 단순한 기능이 아니라 제품 핵심 가치가 됩니다. (The Cloudflare Blog)

셋째, AI 워크플로를 CMS 운영에 직접 붙이려는 팀입니다.
에이전트가 스키마를 바꾸고, 마이그레이션하고, 블록을 만들고, 플러그인을 작성하는 그림은 WordPress보다 EmDash 쪽이 훨씬 자연스럽습니다. (The Cloudflare Blog)

반대로 한계도 분명합니다.

• WooCommerce급 생태계를 단기간에 재현하기 어렵습니다.
• WordPress에서 통하는 수만 개의 플러그인 자산은 그대로 가져올 수 없습니다.
• Cloudflare 최적화가 장점이자 동시에 채택 장벽이 될 수 있습니다.
• 아직 프리뷰 단계라 실제 대규모 운영 사례가 쌓이지 않았습니다. (The Cloudflare Blog)

제 결론

EmDash가 곧바로 WordPress 40% 점유율을 가져갈 가능성은 낮습니다.
하지만 **“다음 세대 CMS는 어떤 구조여야 하는가”**라는 질문에는 꽤 강한 답을 내놨습니다.

이 프로젝트를 과소평가하면 안 되는 이유는 두 가지입니다.

첫째, 이건 CMS 경쟁이 아니라 플러그인 실행 모델 경쟁입니다.
둘째, 이건 기능 추가가 아니라 레거시 재작성의 비용 구조가 바뀌었다는 증거입니다.

그래서 제 평가는 이렇습니다.

• WordPress 킬러로 보기엔 아직 이릅니다.
• 하지만 현대적인 CMS 아키텍처의 기준점이 될 가능성은 충분합니다.
• 특히 “서버리스 + capability sandbox + Astro + AI-native tooling” 조합은 앞으로 다른 CMS들도 따라 하게 될 확률이 높습니다. (The Cloudflare Blog)