WordPress 7.0 RC2 기준
출시일: 2026.04.09
워드프레스 7.0, 기대했던 기능이 기본으로 꺼져 있습니다
4월 9일 출시 예정인 WordPress 7.0은 2018년 구텐베르크 도입 이후 가장 큰 업데이트입니다. 실시간 협업, AI 커넥터, DataViews 관리자 재설계까지 — 기능 목록만 보면 기대가 높아질 수밖에 없습니다. 그런데 RC1이 나온 뒤 공식 문서를 실제로 따라가 보니, 가장 많이 이야기된 기능 두 가지가 생각과 다르게 작동합니다.
실시간 협업, 기본값이 OFF인 이유가 있습니다
WordPress 7.0의 가장 큰 기능은 실시간 공동 편집(Real-Time Collaboration, RTC)입니다. 여러 명이 동시에 같은 글을 수정하는 구글 독스 방식의 편집 환경으로, 2019년부터 개발이 시작됐으니 7년 만에 코어에 탑재되는 셈입니다. 그런데 실제 RC1 릴리즈 노트를 열어보면 예상과 다른 문장이 있습니다.
“Beta 6 switched RTC to opt-in by default.”
(출처: The Repository, WordPress 7.0 RC1 발표 보도, 2026.03.25)
RTC는 기본으로 꺼져 있고, Settings → Writing 메뉴에서 직접 켜야 작동합니다. 왜 기본 OFF가 됐을까요. RC1 직전에 베타 기간 동안 심각한 문제가 발견됐기 때문입니다. RTC가 동기화할 때 WordPress 기본 post meta 함수를 씁니다. 그런데 이 함수는 post query 캐시를 지우는 부작용이 있습니다. RTC가 활성화된 상태에서 초당 최대 4번씩 동기화가 일어나면, 편집자가 글을 열어두기만 해도 사이트 전체 캐시가 계속 초기화됩니다. (출처: make.wordpress.org/core, WordPress 7.0 RC1 발표 글, 2026.03.24)
RC1에서는 WordPress VIP의 Chris Zarate가 post meta 함수 대신 직접 DB 쿼리를 쓰는 방식으로 임시 해결했습니다. 전용 데이터베이스 테이블을 만드는 근본적인 해법은 7.1에서 다시 검토하기로 했습니다. 당장 4월 9일 이후 RTC를 켜면 캐시 압박이 줄어든 건 맞지만, DB에 직접 쓰는 구조가 장기적으로 최선인지는 아직 공식 답변이 없습니다.
💡 공식 발표문과 RC1 릴리즈 노트를 같이 놓고 보니 이런 차이가 보였습니다 — RTC를 켜면 “빠른 실시간 협업”을 경험하는 게 아니라 “폴링 주기를 4배 늘린 상태의 실시간 협업”을 경험합니다. 폴링 간격이 늘어났다는 건 동기화 지연이 그만큼 생긴다는 뜻입니다.
실제 사용 조건도 따져봐야 합니다. 공식 문서와 달리 공유 호스팅에서는 RTC가 HTTP 폴링 방식으로만 작동합니다. 이는 WebSocket을 지원하지 않는 대부분의 저가 호스팅에서는 몇 초에 한 번씩 변경 사항을 “가져오는” 방식으로 협업이 이뤄진다는 뜻입니다. 두세 명이 같이 쓰는 팀에서는 체감상 충분할 수 있지만, 10명 이상이 같은 문서를 동시 편집하면 체감 지연이 생길 가능성이 높습니다.
클라이언트사이드 미디어, 사라진 곳을 찾았습니다
많은 WordPress 7.0 소개 글에서 “이미지를 업로드하기 전에 브라우저에서 먼저 압축·변환한다”는 클라이언트사이드 미디어 처리 기능을 큰 개선점으로 꼽았습니다. 서버 CPU 사용량을 80% 이상 줄일 수 있다는 수치까지 등장했습니다. (출처: GitHub Issue #74333, WordPress/gutenberg, 2026.01.02)
그런데 이 기능은 Beta 6에서 완전히 제거됐습니다. WordPress 7.0에는 들어가지 않습니다. 이유는 두 가지입니다. 첫째, 기능 구현에 vips라는 외부 라이브러리가 필요했는데, 이 라이브러리 하나 때문에 패키지 크기가 60MB까지 치솟았습니다. 참고로 WordPress 6.9.4 패키지는 약 27MB입니다. RC1에서는 클라이언트사이드 미디어를 제거한 뒤 29.8MB로 내려왔습니다. (출처: therepository.email, RC1 발표 보도, 2026.03.25)
둘째, WordPress Playground 환경에서 작동하지 않는 문제가 있었습니다. (출처: GitHub Issue #75941, WordPress/gutenberg, 2026.02.25) 공식 트래킹 티켓에는 7.1 릴리즈 사이클이 시작되는 시점에 다시 도입하겠다고 나와 있습니다. (출처: WordPress Core Trac #64919, 2026.03.20) 7.1 예정일은 2026년 8월 19일입니다.
📊 패키지 크기 비교 (WordPress 7.0 RC1 기준)
| 버전 | 패키지 크기 | 비고 |
|---|---|---|
| WordPress 6.9.4 | 약 27MB | 기준치 |
| WP 7.0 Beta 5 (미디어 포함) | 약 60MB | vips 라이브러리 포함 |
| WP 7.0 RC1 (미디어 제거 후) | 29.8MB | 클라이언트사이드 미디어 제거 |
출처: therepository.email, RC1 보도(2026.03.25) / 수치 단위: 공식 발표 기준
60MB에서 29.8MB로 줄었다는 건 절반 이하로 줄인 것입니다. 서버 업로드 속도나 배포 자동화 환경에서는 눈에 띄는 차이입니다.
AI 커넥터, 이번에 코어에 처음 들어갑니다
WordPress 7.0에서 처음으로 코어에 포함되는 AI 관련 기능이 있습니다. RC1에서 추가된 Settings → Connectors 화면입니다. OpenAI, Anthropic, Google AI 같은 외부 AI 서비스에 API 키를 연결하면 WordPress 자체가 해당 서비스를 사용할 수 있는 구조입니다. Matt Mullenweg이 지난달 제품 리뷰에서 직접 요청해서 RC1에 긴급 추가된 기능입니다.
여기서 짚어야 할 점이 있습니다. AI 커넥터는 서버가 AI 연산을 하는 게 아닙니다. WordPress 설치된 서버가 외부 AI 서비스에 요청을 보내고 응답을 받아오는 구조입니다. 즉 wp_remote_post()를 통한 아웃바운드 HTTPS 연결이 가능해야 작동합니다. 일부 저가 호스팅은 아웃바운드 HTTP 연결을 제한하거나 방화벽으로 차단합니다. (출처: 365i.co.uk, WordPress 7.0 호스팅 준비 가이드, 2026.03.15) 이런 환경에서는 커넥터 페이지가 오류를 표시할 수 있습니다.
개발자 관점에서는 WP AI Client API가 주목할 만합니다. 특정 AI 벤더에 종속되지 않는 공통 인터페이스를 코어가 제공하기 때문에, 플러그인이 OpenAI를 직접 호출하는 코드 대신 WordPress 표준 AI 레이어를 쓸 수 있게 됩니다. 이 구조가 완성되면 나중에 벤더를 바꿔도 플러그인 코드를 수정할 필요가 없어집니다. MCP 어댑터도 이번 7.0에서 함께 들어갑니다. 다만 MCP 어댑터는 PHP 8.2 이상에서만 작동합니다.
DataViews 전환으로 플러그인이 깨질 수 있습니다
관리자 화면의 글 목록, 페이지 목록, 사용자 목록이 WordPress 7.0에서 DataViews라는 React 기반 컴포넌트로 교체됩니다. 기존 WP List Table은 PHP가 HTML을 통째로 렌더링했지만, DataViews는 React가 DOM을 동적으로 구성합니다. 구조 자체가 다릅니다.
여기서 문제가 생깁니다. 글 목록에 커스텀 컬럼을 추가하거나, 벌크 액션을 수정하거나, 인라인 편집 버튼을 바꾸는 플러그인들은 기존 DOM 구조에 의존해 만들어졌습니다. DataViews로 바뀌면 그 DOM이 없어지기 때문에 해당 플러그인의 UI가 깨지거나 아예 작동하지 않을 수 있습니다. (출처: 365i.co.uk, WordPress 7.0 호스팅 준비 가이드, 2026.03.15)
글쓰기 화면이나 사이트 프론트엔드에 영향을 주는 플러그인은 대체로 문제가 없습니다. 관리자 목록 화면을 커스터마이징하는 플러그인이 위험합니다. 4월 9일 이전에 스테이징 환경에서 직접 테스트하는 게 필요한 이유가 여기 있습니다.
iframe 강제 적용, 7.0에서는 실제로 일어나지 않습니다
개발자 대상 자료에서 “WordPress 7.0부터 포스트 에디터가 항상 iframe으로 작동한다”는 내용이 많이 나옵니다. 공식 개발자 블로그도 “In WordPress 7.0, the post editor will always be iframed”라고 썼습니다. (출처: developer.wordpress.org, What’s New for Developers February 2026, 2026.02)
그런데 같은 공식 사이트의 다른 문서를 보면 이야기가 달라집니다.
“Please note that the iframe is NOT enforced in WordPress 7.0! The timeline to enforce it has been revised in favor of a more gradual rollout to allow more time and feedback.”
(출처: make.wordpress.org/core, Iframed Editor Changes in WordPress 7.0, 2026.02.24)
포스트 에디터가 iframe으로 “작동할 수 있는” 조건이 만들어진 것이지, 모든 환경에서 강제 적용되는 게 아닙니다. 실제 강제 적용은 Gutenberg 플러그인 22.6 버전부터 클래식 테마에 한해 먼저 시험하고, WordPress 코어에서는 이후 단계적으로 적용할 예정입니다. Block API version 2 이하를 쓰는 플러그인이 있으면 해당 플러그인이 삽입된 포스트에서는 여전히 non-iframed 모드로 돌아갑니다.
💡 공식 문서 두 곳을 같이 읽어보니 이런 차이가 보였습니다 — 개발자 블로그는 기능 방향을 설명하고, make.wordpress.org는 실제 적용 범위를 수정합니다. 두 문서 중 하나만 보면 전혀 다른 내용을 이해하게 됩니다.
PHP 최소 요건이 올라간 것보다 중요한 숫자가 있습니다
WordPress 7.0은 PHP 7.2와 7.3 지원을 공식 종료합니다. 최소 요건이 PHP 7.4로 올라갑니다. 지금 PHP 7.2나 7.3을 쓰고 있다면 WordPress 7.0 업데이트 알림 자체가 뜨지 않습니다. (출처: make.wordpress.org/core, Dropping Support for PHP 7.2 and 7.3, 2026.01.09)
여기서 중요한 숫자는 7.4가 아니라 8.2입니다. MCP 어댑터가 PHP 8.2 이상에서만 작동합니다. 그리고 실제 성능 차이도 있습니다. PHP 8.3 이상에서 운영하면 8.2 대비 약 12~14%의 처리 속도 향상이 측정됩니다. (출처: 365i.co.uk, PHP 8.5 WordPress Speed Wins, 2025.12.08) 12~14%는 단순한 수치가 아니라 동일한 서버에서 처리할 수 있는 요청 수가 그만큼 늘어난다는 뜻입니다.
PHP 버전별 WordPress 7.0 기능 가용 범위
| PHP 버전 | WP 7.0 업데이트 | MCP 어댑터 | 성능 |
|---|---|---|---|
| 7.2 / 7.3 | ❌ 불가 | ❌ | 기준치 |
| 7.4 / 8.0 / 8.1 | ✅ 가능 | ❌ | 제한적 |
| 8.2 | ✅ 가능 | ✅ | 권장 |
| 8.3+ | ✅ 가능 | ✅ | 최적 (약 +12~14%) |
출처: make.wordpress.org/core (PHP 지원 종료), 365i.co.uk (성능 수치) / 성능 수치는 실제 WordPress 사이트 기준 측정값
한 가지 더 — PHP 8.1은 2025년 12월 31일 공식 수명이 끝났습니다. 호스팅이 아직 PHP 8.1을 기본값으로 제공하고 있다면 보안 패치가 중단된 버전을 쓰고 있는 겁니다.
Q&A
마치며
WordPress 7.0은 좋은 릴리즈입니다. 실시간 협업의 기반이 코어에 들어오고, AI 인프라가 표준화되고, 관리자 인터페이스가 React 기반으로 전환되는 건 방향이 맞습니다. 하지만 기능 목록만 보고 기대를 높이면 실제 경험과 괴리가 생깁니다.
RTC는 켜야만 작동하고, 클라이언트사이드 미디어는 7.1로 미뤄졌고, iframe 강제 적용도 7.0에서는 일어나지 않습니다. 코어 커미터 일부가 RC 단계에서 “이 코드로 릴리즈하기 불안하다”고 말했을 만큼 복잡한 릴리즈였습니다. 매우 솔직하게 말하면, 7.0은 완성이 아니라 7.1을 향한 디딤돌에 가깝습니다.
4월 9일 이후 바로 업데이트할 계획이라면 스테이징에서 먼저 테스트하고, PHP 버전 확인하고, 관리자 화면 건드리는 플러그인이 있다면 업데이트 전에 따로 체크해두는 게 현실적인 준비입니다.
본 포스팅 참고 자료
- WordPress Developer Blog — What’s New for Developers (February 2026) developer.wordpress.org
- Make WordPress Core — Iframed Editor Changes in WordPress 7.0 (2026.02.24) make.wordpress.org/core
- The Repository — WordPress 7.0 RC1 Ships Despite Core Committer Concerns (2026.03.25) therepository.email
- 365i — WordPress 7.0 Hosting Readiness (2026.03.15) 365i.co.uk
- Make WordPress Core — Real-Time Collaboration Early User Feedback (2025.12.16) make.wordpress.org/core
- WordPress Core Trac — Re-introduce client-side media processing #64919 core.trac.wordpress.org
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. WordPress 7.0은 2026.03.31 기준 RC2 단계이며, 최종 릴리즈(2026.04.09 예정) 시점에 내용이 달라질 수 있습니다. 모든 수치·기능은 공식 발표 자료를 기준으로 하며, 실제 사용 환경에 따라 다를 수 있습니다.
댓글 남기기