본문으로 건너뛰기
피드

Cloudflare가 WordPress 대체 CMS 'EmDash'를 오픈소스로 공개함

frontend 약 8분
vote
0
댓글
북마크

Cloudflare가 WordPress의 정신적 후계자를 자처하는 오픈소스 CMS EmDash를 공개했다. TypeScript 기반 서버리스 아키텍처에 플러그인 샌드박스 격리로 WordPress의 고질적 보안 문제를 구조적으로 해결하고, x402 결제 표준 내장으로 AI 에이전트 시대의 콘텐츠 수익화까지 지원한다.

  • 1

    EmDash는 TypeScript 기반, 서버리스, MIT 라이선스 오픈소스 CMS

  • 2

    플러그인을 Dynamic Worker 샌드박스에서 격리 실행하여 WordPress 보안 문제의 근본 원인 해결

  • 3

    x402 결제 표준 내장으로 구독 없이 콘텐츠 유료화 가능

  • 4

    Astro 기반 테마 시스템과 빌트인 MCP 서버로 AI 에이전트 관리 지원

  • 5

    WordPress에서 마이그레이션 도구 제공, v0.1.0 프리뷰 단계

Cloudflare가 WordPress의 "정신적 후계자"를 자처하는 오픈소스 CMS EmDash를 공개함. TypeScript 기반, 서버리스, MIT 라이선스. WordPress 코드는 한 줄도 안 썼다는 게 포인트임.

중요

> WordPress 보안 이슈의 96%가 플러그인에서 발생함. 2025년에는 고위험 취약점이 직전 2년 합산보다 더 많이 발견됨.

플러그인 보안 — EmDash의 핵심 차별점

  • WordPress 플러그인의 근본적인 보안 문제를 구조적으로 해결함
    • WordPress 플러그인은 PHP 스크립트가 WordPress에 직접 hook되는 구조라서 DB와 파일시스템에 무제한 접근이 가능함
    • EmDash는 각 플러그인을 독립된 샌드박스(Dynamic Worker)에서 실행함
    • 플러그인이 manifest에 명시적으로 선언한 capability만 사용 가능 — OAuth 스코프 모델과 비슷한 구조임
  • 예를 들어 "콘텐츠 저장 후 이메일 발송" 플러그인이라면 read:contentemail:send 두 가지만 선언하고, 그 외 네트워크 접근 자체가 불가능함
    • 코드가 수만 줄이라도 선언된 capability 외엔 아무것도 못 함
    • 외부 네트워크 접근이 필요하면 특정 hostname만 명시적으로 지정해야 함

마켓플레이스 락인 탈출

  • WordPress.org는 플러그인을 수동 리뷰하는데, 현재 대기열이 800개 이상이고 최소 2주 걸림
    • 보안 위험이 크다 보니 마켓플레이스 신뢰에 의존할 수밖에 없는 구조
    • 거기다 GPL 라이선스 문제까지 얽혀서 플러그인 개발자들이 사실상 마켓플레이스에 종속됨
  • EmDash 플러그인은 두 가지로 이 문제를 깨뜨림
    • 라이선스 자유: EmDash와 코드를 공유하지 않으니 NPM이나 PyPI처럼 원하는 라이선스 선택 가능
    • 코드 비공개 실행: 샌드박스에서 독립 실행되니 사이트가 플러그인 코드를 볼 필요가 없음 — 중앙 마켓플레이스 의존도가 확 낮아짐

AI 시대의 콘텐츠 수익화 — x402 내장

  • EmDash에 x402 결제 표준이 기본 탑재됨
    • 에이전트가 HTTP 요청을 보내면 402 Payment Required 응답 → 에이전트가 온디맨드 결제 → 콘텐츠 접근 허용
    • 구독 모델 없이, 엔지니어링 작업 없이 콘텐츠 유료화가 가능함
    • 지갑 주소 설정하고 과금 대상 콘텐츠만 지정하면 끝
sequenceDiagram
    participant 클라이언트 as 클라이언트(에이전트)
    participant 서버 as EmDash 서버
    participant 지갑 as 결제 네트워크

    클라이언트->>서버: GET /premium-content
    서버-->>클라이언트: 402 Payment Required (가격 정보)
    클라이언트->>지갑: 결제 실행
    지갑-->>서버: 결제 확인
    클라이언트->>서버: GET /premium-content (결제 증명 포함)
    서버-->>클라이언트: 200 OK (콘텐츠 반환)

서버리스 아키텍처

  • WordPress는 전통적인 서버 프로비저닝이 필요하고 트래픽 스파이크 대응에 유휴 컴퓨트가 불가피함
  • EmDash는 Cloudflare의 workerd 런타임 위에서 v8 isolate 기반으로 동작함
    • 요청이 들어오면 즉시 isolate를 스핀업하고, 요청이 없으면 제로까지 스케일다운
    • CPU 시간만 과금 (실제 작업 시간 기준)
    • Node.js 서버 어디서든 실행 가능하지만, Cloudflare에서는 Cloudflare for Platforms로 수백만 인스턴스를 완전 제로 스케일링 가능

테마와 AI 에이전트 지원

  • 테마는 Astro 프로젝트로 만듦 — Pages, Layouts, Components, Styles, Seed 파일 구조
    • WordPress 테마처럼 functions.php에 의존하지 않아서 테마도 DB 조작 불가 (보안 격리)
    • 프론트엔드 개발자에게 익숙한 구조이고 LLM도 이미 Astro를 학습하고 있음
  • AI 에이전트로 사이트 관리가 가능하도록 설계됨
    • Agent Skills: 에이전트에게 EmDash의 capability와 hook 사용법을 설명하는 빌트인 컨텍스트
    • CLI: 로컬/원격 인스턴스와 프로그래매틱 상호작용
    • 빌트인 MCP 서버: Admin UI에서 할 수 있는 모든 것을 MCP로 노출

그 외 주요 특징

  • 인증은 패스키 기반 (비밀번호 유출·무차별 대입 벡터 없음), SSO 연동 가능
  • WordPress에서 WXR 파일 또는 EmDash Exporter 플러그인으로 마이그레이션 가능 — 미디어 라이브러리 자동 이관 포함
  • 커스텀 콘텐츠 타입을 Admin 패널에서 스키마 정의로 바로 생성 가능 (WordPress의 ACF 플러그인 없이)
  • 현재 v0.1.0 프리뷰 단계, npm create emdash@latest로 바로 시작 가능

기술 맥락

EmDash가 플러그인 보안을 isolate 기반으로 풀겠다는 건 Cloudflare Workers의 아키텍처를 그대로 활용한 거예요. Workers가 원래 V8 isolate 위에서 각 요청을 격리 실행하는 구조인데, 이걸 플러그인 단위로 확장한 거죠. 컨테이너보다 훨씬 가볍고 빠르게 스핀업되면서도 메모리 격리가 보장되는 게 핵심이에요.

x402는 아직 생소할 수 있는데, HTTP 표준의 402 상태 코드를 실제 결제 흐름에 활용하자는 아이디어예요. 원래 402는 "미래 사용을 위해 예약됨"이었는데, AI 에이전트가 웹을 자동 탐색하는 시대에 콘텐츠 과금 메커니즘으로 되살린 거거든요. 구독이나 API 키 없이 HTTP 레벨에서 결제가 이뤄지는 구조라 에이전트 친화적이에요.

WordPress가 GPL 라이선스를 쓰기 때문에 플러그인도 GPL을 따라야 한다는 논쟁이 오래됐는데, EmDash는 이걸 아키텍처로 해결한 거예요. 플러그인이 EmDash 코드를 import하거나 링크하지 않고 독립된 Worker에서 실행되니까 라이선스 전파가 발생하지 않아요. MIT 라이선스로 갈 수 있는 법적 근거가 여기서 나오는 거죠.

Astro를 테마 엔진으로 선택한 것도 의미가 있어요. Astro는 콘텐츠 중심 사이트에서 부분 하이드레이션(island architecture)으로 JavaScript 번들을 최소화하는 프레임워크거든요. CMS 특성상 대부분이 정적 콘텐츠인데, 여기에 Astro의 강점이 딱 맞아떨어져요.

WordPress 플러그인 보안 문제를 '더 조심하자'가 아니라 아키텍처 자체를 격리 모델로 바꿔서 해결한 접근이 인상적. Cloudflare Workers의 isolate 기술을 CMS 플러그인에 적용한 건 자사 인프라 위에서 돌아가는 킬러 앱을 만든 전형적인 플랫폼 전략이기도 함.

댓글

댓글

댓글을 불러오는 중...

frontend

요즘 픽셀 폰트가 그냥 복고 감성이 아닌 이유

1990년대 기기 화면 느낌을 현대 폰트 시스템으로 재해석한 픽셀 폰트 몇 가지를 소개한 글이다. 핵심은 예쁜 복고풍 글자 모양만이 아니라, 실제 제품에서 쓸 수 있게 기준선, 자간, 메타데이터, 세로 메트릭까지 챙기는지가 중요하다는 점이다.

frontend

HTML의 `<dl>`이 생각보다 쓸모 많은 이유

이 글은 HTML의 description list, 즉 `<dl>`, `<dt>`, `<dd>`가 단순 용어 사전용 태그가 아니라 이름-값 쌍 UI를 표현하는 꽤 강력한 시맨틱 도구라고 설명한다. 숙소 편의시설, 요금 내역, 기술 용어 설명, 게임 능력치표처럼 흔한 패턴을 중첩 `<div>` 대신 의미 있는 HTML로 만들 수 있다는 얘기다.

frontend

HTML을 캔버스 안에 넣는 데모 모음이 등장함

구글 크롬 랩스 저장소에 HTML-in-Canvas 관련 데모와 프레임워크 지원 목록이 정리됐다. Duck Hunt 스타일 폼, 흔들리는 버튼, 셰이더 기반 페이지 전환, 천처럼 매달린 폼 같은 실험적 예제가 포함돼 있고 Three.js와 PlayCanvas 쪽 샘플도 연결돼 있다.

frontend

싱글 페이지 앱이 웹을 너무 비싸게 만들었다는 불평

이 글은 싱글 페이지 앱(SPA)이 사용자 경험을 좋게 만든다는 명분 아래 웹의 초기 로딩 비용, 도구 복잡도, 개발 진입 장벽을 키웠다고 비판한다. 페이스북 로그인 페이지의 CSS 3.8MB, 레딧 몇 개 클릭 후 33MB 다운로드 같은 숫자를 들며, 지금의 프론트엔드 생태계가 사람보다 대기업의 요구에 맞춰져 있다고 주장한다.

frontend

네이티브로 끝까지 가려다 텍스트에서 막힌 macOS 개발자의 고백

20년 가까이 macOS와 iOS 네이티브 개발을 해온 작성자가 SwiftUI, AppKit, TextKit 2로 마크다운 채팅 UI를 만들다 결국 WebKit과 Electron 쪽이 훨씬 낫다는 결론에 도달한 글이다. 문제는 성능 하나가 아니라 선택, 스트리밍, 스크롤, 접근성, 텍스트 상호작용 같은 ‘사용자가 당연히 기대하는 기본기’가 네이티브 조합에서 계속 깨진다는 점이다.