WordPress 7.0은 2026년 5월 20일에 Armstrong이라는 릴리스 이름으로 출시되었습니다. 원래의 2026년 일정표에 적혀 있던 날짜보다 6주 늦었고, block editor 이후 대행사에게 가장 큰 영향을 주는 코어 릴리스입니다. 헤드라인은 이제 코어가 생성형 AI 모델과 대화할 수 있다는 것입니다. 하지만 더 중요한 세부 사항은, 코어가 플러그인이 그 모델들과 어떻게 대화해야 하는지까지 정의하게 되었다는 점입니다. 이는 사이트에 있는 모든 플러그인이 자기 영역에 대해 전제해도 되는 것을 조용히 바꿔 놓습니다.

편집자 입장에서 보이는 변화는 크지 않습니다. Command Palette가 생겼고, 대시보드가 정돈되었으며, 글꼴 관리 화면이 추가되었고, 리비전이 좋아졌습니다. 그러나 사이트를 업으로 관리하는 사람에게 중요한 변화는 관리자 화면 아래에 있습니다. options 테이블에 놓이는 자격 증명 저장소, 사이트가 할 수 있는 일들의 레지스트리, 그리고 그것을 나열해 주는 REST 표면입니다. 어느 것도 선택 사항이 아닙니다. 누군가 고른 플러그인이 아니라 코어와 함께 도착하기 때문입니다.

이 글은 실무자의 독법입니다. 실제로 무엇이 들어왔는지, 릴리스 12일 전에 무엇이 빠졌고 왜 그랬는지, 업데이트가 무엇을 깨뜨리고 무엇을 깨뜨리지 않는지, 그리고 AI가 WordPress에 들어간다는 기사 제목을 막 읽은 고객에게 무엇을 말해야 하는지를 다룹니다.

업데이트해야 할까요? 해야 합니다. 다만 7.0에서 멈추지 말고 7.1까지 가십시오. WordPress 7.1은 2026년 8월 19일에 출시되었고, 7.0 뒤에는 네 번의 유지보수 릴리스가 쌓여 있습니다. AI 기능은 관리자가 설정에서 Connectors로 들어가 제공업체 키를 저장하기 전까지는 작동하지 않으므로, 업데이트 자체가 여러분의 콘텐츠를 어디로도 보내지 않습니다. 이 업데이트의 진짜 위험은 AI가 아니라 평범한 플러그인과 테마 호환성입니다.

WordPress 7.0에서 실제로 출시된 것

릴리스 이름은 루이 암스트롱에서 따왔습니다. 주요 버전을 재즈 음악가의 이름으로 부르는 프로젝트의 관례를 따른 것입니다. 릴리스 공지는 875명이 넘는 기여자와 420건이 넘는 개선 및 수정을 언급합니다.

실제로 들어온 것의 목록은 유용할 만큼 짧습니다. 코어는 AI Client를 얻었습니다. 생성 모델에 프롬프트를 보내기 위한, 제공업체에 구애받지 않는 PHP 인터페이스입니다. 설정 아래에는 Connectors 화면이 생겼고, 관리자는 여기에 제공업체 자격 증명을 저장합니다. 그리고 Abilities API의 JavaScript 절반이 들어왔습니다. PHP 절반은 이미 6.9에서 출시된 바 있습니다.

편집 쪽에서는 Ctrl+K 또는 Cmd+K로 열리는 Command Palette, 현대화된 대시보드, 전용 글꼴 관리 페이지, 리비전을 시각적으로 훑어보는 기능, 그리고 새로운 Heading, Breadcrumbs, Icons 블록과 갤러리용 라이트박스 슬라이드쇼가 추가되었습니다.

들어오지 않은 것은, 이 릴리스 전체가 그 주위에 만들어져 있던 바로 그 기능이었습니다. 실시간 공동 편집은 출시 12일 전에 제거되었습니다. 그 부재와 그 이유가 기능 목록보다 코어의 현재 상태를 더 잘 말해 줍니다.

날짜가 움직인 이유

릴리스는 원래 2026년 4월 9일로 예정되어 있었습니다. 공동 편집이 준비되지 않았고 프로젝트가 그 상태로 내보내지 않겠다고 판단했기 때문에 5월 20일로 밀렸습니다. 향후 경로를 밝힌 글은 지연이 “실시간 협업 구현에 대한 테스트 피드백을 처리할 시간을 더 확보하기 위해” 있었다고 분명히 밝히며, 개발 주기는 기술적인 이유로 릴리스 후보 버전 번호를 유지한 채 베타로 되돌아갔습니다.

이것은 이례적입니다. RC까지 간 주요 릴리스가 베타로 돌아가는 것은 강한 신호이며, 그것은 옳은 결정이었습니다.

AI Client, 코어가 출시한 것은 추상화이지 모델이 아니다

WordPress 7.0에 대한 가장 중요한 아키텍처 사실은, 코어가 AI 모델도 API 키도, 어떤 벤더와의 관계도 포함하지 않는다는 것입니다. AI Client 개발 노트는 “WordPress 코어는 어떤 AI 제공업체도 직접 번들하지 않는다"고 분명하게 적고 있습니다.

코어가 출시하는 것은 일관된 PHP 인터페이스입니다. 플러그인은 wp_ai_client_prompt()를 호출해 WP_AI_Client_Prompt_Builder 객체를 받고, using_temperature()나 using_model_preference() 같은 설정을 체이닝한 다음, generate_text() 또는 generate_image()로 마무리합니다. 오류는 WP_Error로 돌아오고, 요청은 WordPress의 HTTP 전송 계층을 지나며, 전체가 훅 시스템에 연결되어 있습니다.

실무적인 효과는, 플러그인 작성자가 모델 벤더마다 HTTP 클라이언트, 재시도 루프, 키 저장 화면, 설정 페이지를 다시 쓰지 않아도 된다는 것입니다. 무엇을 원하는지 기술하면 코어가 경로를 잡아 줍니다.

이것은 중복 코드의 실질적인 감소입니다. 동시에 신뢰의 집중이기도 하며, 무언가를 켜기 전에 생각해 볼 가치가 있는 부분이 바로 그것입니다.

커넥터란 무엇인가

커넥터는 여러분의 사이트와 외부 서비스 사이에 등록된 관계입니다. 7.0에서 유일한 커넥터 유형은 AI 제공업체이며, Anthropic, Google, OpenAI를 각각 다루는 세 개의 대표 제공업체 플러그인이 있고 모두 따로 설치합니다.

Connectors API 개발 노트는 자격 증명이 어떻게 해석되는지 설명합니다. 키는 환경 변수, PHP 상수, 데이터베이스 설정에서 올 수 있고 그 순서대로 확인되며, 옵션 이름은 connectors_ai_{$id}_api_key 패턴을 따릅니다.

사이트를 책임지는 사람이라면 주목해야 할 세부 사항이 하나 있습니다. 개발 노트는 데이터베이스에 저장된 API 키가 “암호화되지 않지만 사용자 인터페이스에서는 마스킹된다"고 말하며, 암호화는 후속 작업으로 추적되고 있다고 밝힙니다. 관리자 화면에서 키를 설정하면 그것은 평문으로 wp_options에 놓이고, 그 데이터베이스의 모든 백업은 이제 요금이 청구되는 자격 증명을 담게 됩니다.

코드를 쓰지 않는다면 이것이 무슨 뜻인가

사이트 소유자에게 이 변화는 들리는 것만큼 복잡하지 않습니다. 두 가지가 참이 되기 전까지는 아무것도 생성되거나 요약되거나 다시 쓰이지 않습니다. 제공업체 플러그인이 설치되어 있어야 하고, 누군가 작동하는 키를 설정에서 Connectors에 붙여 넣었어야 합니다.

그전까지 AI Client는 휴면 상태의 라이브러리입니다. WordPress 7.0으로의 업데이트는 여러분의 글을 모델로 보내지 않고, 어디에도 계정을 만들지 않으며, 요금을 발생시키지도 않습니다.

대신 다음에 설치할 플러그인의 문턱을 낮춥니다. 예전에는 여러분에게 키를 요청해야 했던 플러그인이, 이제는 사이트에 이미 설정된 키를 찾아 쓸 수 있습니다. 편리한 일이며, 동시에 사고처럼 벌어지기 전에 정책을 써 두어야 할 바로 그런 종류의 일입니다.

Abilities API와 플러그인 설계가 바뀌는 이유

3년 뒤에도 여전히 중요할 조각은 Abilities API이며, 이것은 본질적으로 AI와 아무 상관이 없습니다. 레지스트리입니다. 플러그인은 wp_register_ability()로 namespace/ability-name 형태의 이름 붙은 기능 단위를, 사람이 읽을 수 있는 설명, 입력과 출력의 JSON Schema, 실행 콜백, 그리고 선택적인 권한 콜백과 함께 등록합니다.

공식 문서는 권한 콜백을 평범한 권한 검사로 보여 줍니다. 예를 들어 current_user_can( 'manage_options' )를 반환하는 식입니다. 그것이 보안 모델의 전부이며, 플러그인 작성자의 판단만큼만 좋습니다.

능력이 존재하면 다른 것들이 그것을 열거할 수 있습니다. 모델은 이 특정 사이트가 할 수 있는 일의 목록을 스키마 형태로 건네받아 그중 하나를 호출할 수 있습니다. 클라이언트 쪽 Command Palette도 마찬가지이며, API의 JavaScript 절반이 Command Palette와 같은 릴리스에 들어온 이유가 바로 그것입니다.

플러그인 작성자에게 설계상의 결과는 실질적입니다. 예전에는 자신의 관리자 화면에서, 자신의 nonce와 자신의 폼을 통해서만 도달할 수 있던 기능을, 이제는 기계가 읽을 수 있는 계약을 갖춘 능력으로 노출하도록 기대받을 수 있습니다. 그것은 다른 공격 표면이고 다른 문서화 부담입니다.

7.1에서 바뀐 것

WordPress 7.1은 레지스트리를 확장하기보다 조였습니다. 7.1 Abilities 개발 노트는 검증 필터 wp_ability_validate_input과 wp_ability_validate_output, 실행 시작 시점에 발생하는 액션 wp_ability_invoked, 그리고 능력이 /wp-json/wp-abilities/v1/abilities에서 REST로 발견될 수 있는지를 제어하는 public 메타데이터 플래그를 추가합니다.

그 개발 노트에는 로깅 플러그인 작성자라면 모두 읽어야 할 문장도 담겨 있습니다. 호출 훅은 정규화되지 않은 원본 입력을 받으며, 개발자는 “자격 증명, 개인 정보, 기타 민감한 데이터가 포함될 수 있으므로 입력을 무분별하게 로깅하는 것을 피해야 한다"고 되어 있습니다.

실시간 협업과 그것에 필요했던 테이블

공동 편집은 충돌 없는 복제 데이터 타입인 Yjs 위에, 동기화 제공자 추상화를 얹어 만들어졌습니다. 코어는 기본으로 HTTP 폴링 제공자를 출시합니다. 어떤 호스팅에서도 동작한다는 이유로 WebSocket보다 선택된 것이며, 플러그인은 필터로 전송 방식을 바꿀 수 있습니다.

문제는 병합 알고리즘이 아니었습니다. 동기화 데이터가 어디에 사는가였습니다. 최초 구현은 그것을 포스트 메타에 저장했는데, WordPress에서는 당연해 보이는 선택이지만 초당 여러 번 바뀌는 데이터에는 잘못된 선택입니다.

포스트 메타 쓰기는 캐시 무효화를 유발합니다. 에디터가 열려 있는 동안 동기화 데이터는 계속 쓰였으므로, 쓰기마다 그 글의 캐시된 쿼리가 지워졌습니다. 실제로는 한 사람이 페이지를 편집하는 것만으로 세션 내내 사이트의 영구 객체 캐시가 계속 비워질 수 있었습니다.

이것은 포스트 메타에 대한 좋은 일반 교훈입니다. 포스트 메타는 그것이 매달린 콘텐츠의 캐시 수명 주기에 묶인 키값 저장소이며, 글이 바뀔 때 함께 바뀌는 속성에는 적합합니다. 고빈도 상태를 두는 임시 공간은 아닙니다.

측정된 해법, 그리고 그 결정

기여자들은 여덟 개의 호스팅 환경에서 저장 전략을 시험했습니다. 성능 분석은 트랜지언트로 뒷받침되는 전용 테이블이 기존 구현보다 약 52% 빠르고, 순수한 전용 테이블은 약 37% 빠르다고 결론지었습니다. 영구 객체 캐시가 있는 경우, 트랜지언트를 쓰는 두 전략 모두 디스패치당 데이터베이스 쿼리 한 번까지 떨어졌습니다.

선택된 것은 트랜지언트를 곁들인 커스텀 테이블이었습니다. 그리고 같은 날, 그 기능은 빠졌습니다.

제거 공지는 “표면적, 경쟁 상태, 서버 부하, 메모리 효율, 그리고 퍼즈 테스트에서 발견된 반복되는 버그에 대한 우려"를 이유로 들며, 이 결정이 “사용자를 위해 안정적이고 신뢰할 수 있는 WordPress 7.0 릴리스를 내보내기 위해” 내려졌다고 밝힙니다.

지금의 상태

7.1에서도 출시되지 않았습니다. 7.1 필드 가이드는 실시간 공동 편집이 “WordPress 7.1 주기 동안 광범위한 테스트와 피드백을 받았지만 최종 릴리스에서는 활성화되지 않았다"고 밝힙니다.

블록 단위 코멘트를 남기기 위한, 관련은 있지만 별개인 기능인 Notes는 출시되었고 7.1에서 서식 있는 텍스트와 @ 멘션으로 개선되었습니다. 고객이 WordPress에서 Google 문서 방식의 공동 편집을 요청한다면, 오늘의 정직한 답은 Notes가 검토 워크플로를 담당하고 동시 입력은 여전히 코어에 없다는 것입니다.

관리자 화면의 변화와 그것이 만들어 낼 문의

문의를 만들어 낼 변화가 두 가지 있고, 둘 다 버그가 아닙니다.

Ctrl+K 또는 Cmd+K의 Command Palette는 익히고 나면 대단히 빠르지만, Ctrl+K는 많은 에디터에서 링크 삽입 단축키입니다. 그래서 링크 삽입이 고장 났다고 알리는 사용자가 나옵니다. 고장 나지 않았습니다. 어떤 핸들러가 이기는지는 포커스 맥락이 결정합니다.

더 큰 쪽은 현대화된 대시보드입니다. 직원들이 스크린샷으로 교육받은 고객은 이제 교육 자료가 낡았고, 특정 클래스나 DOM 구조를 가정해 관리자 화면에 마크업을 끼워 넣던 플러그인은 이상하게 렌더링될 수 있습니다. 기능이 아니라 외관의 문제지만, 업데이트 당일에 모든 사이트에서 모든 사용자에게 나타납니다. 그래서 개발자가 아닌 사람들에게는 이 릴리스에서 가장 눈에 띄는 부분이 됩니다.

무언가를 업데이트하기 전에, 새 스크린샷을 곁들인 짧은 서면 안내를 위해 고객사당 한 시간을 잡아 두십시오. 같은 설명을 이메일로 열다섯 번 하는 것보다 쌉니다.

실제로 중요한 호환성 문제

버전 번호는 파괴적인 릴리스를 암시합니다. PHP 요구 사항은 그렇지 않습니다. PHP 지원 명확화가 밝히듯, WordPress 7.0부터 지원되는 최소 PHP 버전은 7.4이고 권장 최소 버전은 여전히 8.3입니다. PHP 7.2와 7.3에 대한 지원은 이 릴리스에서 중단되었습니다.

이 명확화는 또한 최신 PHP 버전에 붙던 옛 “베타” 표시를 없앴고, WordPress 6.9와 7.0에서 PHP 8.5를 완전히 지원한다고 기록합니다.

핵심은 지원되는 것과 합리적인 것 사이의 간격입니다. PHP 7.4는 2022년 11월에 수명이 끝났으므로, 최소 요건을 겨우 넘긴 사이트는 4년 가까이 보안 수정을 받지 못한 인터프리터로 돌아가고 있는 셈입니다. 2026년에도 호스팅이 여전히 7.4라면, WordPress 버전은 여러분에게 가장 급한 문제가 아닙니다.

실제 고장은 예측 가능한 패턴을 따릅니다. 방치된 플러그인이 먼저 깨지며, 특히 관리자 DOM이나 에디터 iframe을 조작하는 것들이 그렇습니다. 관리자 스타일을 하드코딩한 커스텀 테마는 이상하게 보입니다. 자체 React 번들을 싣고 다니는 페이지 빌더는 에디터 흰 화면의 단골 원인이며, 동시에 대개 가장 빨리 패치를 내놓습니다.

구체적인 업데이트 절차

스테이징을 준비하십시오. 운영 환경을 데이터베이스까지 포함해, 색인되지 않고 메일도 보내지 않는 환경으로 복제합니다. 아래 어느 것도 운영 사이트에서 할 만한 일이 아닙니다.

기준선을 기록하십시오. PHP 버전, 플러그인과 테마 목록 및 각 버전, 그리고 현재 WordPress 버전을 적어 둡니다. 고객이 매일 쓰는 관리자 화면 두세 개를 스크린샷으로 남깁니다.

먼저 WordPress만 업데이트하십시오. 플러그인과 테마는 그대로 두고, 프런트엔드, 글 편집기, 사이트 편집기, WooCommerce가 있다면 결제, 그리고 모든 커스텀 관리자 화면을 차례로 훑습니다. 여기서의 실패는 코어나 호환되지 않는 확장의 몫이며, 그것을 플러그인 업데이트와 분리하는 것이 이 순서로 작업하는 이유 전부입니다.

그다음 플러그인을 작은 묶음으로 업데이트하고, 묶음 사이마다 다시 테스트하면 회귀가 생겼을 때 용의자 목록이 짧아집니다.

페이지를 눈으로 보지 말고 오류 로그를 확인하십시오. 더 이상 쓰이지 않는 호출에서 나오는 PHP 알림은 늘 화면에 보이지는 않으며, 몇 달 동안 조용히 로그를 채웁니다.

Connectors 화면은 비워 두십시오. AI 제공업체를 설정하지 않은 상태로 업데이트를 내보내고, 하나를 켜는 일은 별도의 승인을 갖춘 별개의 의도적인 변경으로 다루십시오. 주변 통제는 저희 WordPress 보안 강화 체크리스트가 다루고, 그 뒤에 무엇을 측정할지는 성능 감사 가이드가 다룹니다.

거버넌스, 커넥터에 무엇을 허용할 것인가

여기에 능력 계층이 만들어 내는, 그리고 어떤 플러그인 작성자도 여러분 대신 답해 줄 수 없는 질문이 있습니다. 서드파티 플러그인은 고객 기록을 읽거나, 사용자를 내보내거나, 발행된 콘텐츠를 편집하는 능력을 등록할 수 있고, 레지스트리에 접근할 수 있는 모델은 그것을 호출할 수 있습니다. 권한 콜백은 권한 검사이므로, 모델은 로그인한 사람의 권한으로 행동합니다.

그 사람이 관리자라면 모델은 관리자가 할 수 있는 일을 할 수 있습니다. 그것은 설계의 결함이 아니라 문서대로 작동하는 설계입니다. 다만 그것은 어떤 커넥터가 사이트에 존재하는지에 대한 판단이 IT 취향이 아니라 데이터 보호에 관한 판단임을 뜻합니다.

CMS 안의 콘텐츠가 단순한 마케팅 문구인 경우는 드뭅니다. 댓글, 폼 제출, 주문 기록, 사용자 프로필은 개인 정보이며, 그것을 외부 모델로 보내는 일은 정당화할 수 있어야 하는 처리 행위입니다. 영국 정보위원회(ICO)의 AI와 데이터 보호 지침은 설계 단계부터의 데이터 보호를 입증하는 것과 거버넌스를 용도에 비례하게 유지하는 것을 포함해, 책임성과 투명성에 대한 기대를 제시합니다.

고객 사이트에 필요한 현실적인 최소치는 짧은 서면 정책입니다. 어떤 커넥터를 허용하는지, 누가 추가할 수 있는지, 어떤 능력을 REST로 공개하는지, 제공업체와의 보관 기간은 어떻게 되는지. 누군가 키를 붙여 넣기 전에 쓰십시오. 그 뒤에 쓰면 그것은 정책이 아니라 사고 보고서입니다.

다음에 대기 중인 것

WordPress 7.1은 2026년 8월 19일에 도착해 글로벌 스타일의 반응형 설정, 편집기 전반에 유지되는 관리 바, 제대로 된 미디어 편집 모달, Playlist와 Tabs 블록, 그리고 앞서 언급한 Notes 개선을 가져왔습니다. 또한 레거시 메타 박스를 등록하는 사이트를 포함해 글 편집기의 iframe 전환을 마무리했는데, 이것이 오래된 플러그인을 드러낼 가능성이 가장 큰 변화입니다.

WordPress 7.2는 2026년의 마지막 주요 릴리스로 계획되어 있습니다. 7.2 릴리스 페이지는 최종 릴리스를 2026년 12월 8일에서 10일 사이로 잡고, 베타는 10월 말부터로 잡고 있습니다. 그 일정은 출시된 것이 아니라 계획이며, 이 프로젝트는 올해 이미 주요 릴리스 날짜를 한 번 옮겼습니다.

공동 편집은 앞으로의 릴리스에 들어갈 분명한 후보로 남아 있지만, 이미 두 번을 놓쳤고 누구도 고객에게 날짜를 약속해서는 안 됩니다.

이것이 상업적으로 바꾸는 것

세 가지 고객 대화가 바뀌며, 그중 AI에 관한 것은 하나뿐입니다.

첫째는 업데이트 대화입니다. WordPress 7.0과 7.1은 스테이징 검증을 포함한 관리형 업데이트로 비용을 청구할 가치가 있습니다. iframe으로 바뀐 편집기와 관리자 화면 재설계가 오래된 확장을 실제로 드러내기 때문입니다. 서면 테스트 계획을 갖춘 고정 가격 패키지로 파는 편이, 유지보수 계약에 흡수시켰다가 저녁 6시에 망가진 페이지 빌더를 발견하는 것보다 더 정직하고 더 남습니다.

둘째는 거버넌스입니다. 커넥터 정책, 능력 검토, 자격 증명 취급은 2026년 5월 이전에는 존재하지 않았던 청구 가능한 자문 업무이며, 사내 마케팅 팀보다 대행사에 훨씬 잘 맞습니다.

셋째는 구축 업무입니다. AI Client는 사이트에 AI 기능을 만들어 넣는 일의 지루한 절반을 없앱니다. 배관의 가격을 낮추고, 무엇을 만들 가치가 있는지 아는 일의 가치를 높입니다. 그것을 맞춤 구축과 견주고 있다면, WordPress와 맞춤 개발 비교가 선이 보통 어디에 그어지는지를 다루고, WordPress 개발자 요율에 관한 글이 그 작업의 적정 비용을 다룹니다.

Mecanik은 코어 버전 업그레이드, 커넥터 거버넌스, AI 기능 작업을 WordPress 개발 및 AI 통합 서비스의 일부로 수행합니다. 저희가 보는 패턴은 일관됩니다. 업데이트 자체는 정형화된 작업이고, 비싼 놀라움은 3년 동안 아무도 검토하지 않은 확장에서 나옵니다.

자주 묻는 질문

WordPress 7.0은 언제 출시되었고 왜 지연되었나요? WordPress 7.0(릴리스 이름 Armstrong)은 2026년 5월 20일에 출시되었으며, 원래 일정의 4월 9일보다 6주 늦었습니다. 지연은 실시간 공동 편집 구현에 대한 테스트 피드백을 처리하기 위한 것이었고, 개발 주기는 릴리스 후보에 도달한 뒤 베타로 돌아갔습니다. 공동 편집은 결국 2026년 5월 8일에 이 릴리스에서 제거되었습니다.

WordPress 7.0이 제 콘텐츠를 AI 제공업체로 보내나요? 아닙니다. 코어는 AI Client를 출시하지만 어떤 AI 제공업체도, 모델도, API 키도 번들하지 않습니다. 관리자가 제공업체 플러그인을 설치하고 설정에서 Connectors에 작동하는 자격 증명을 저장하기 전까지는 아무것도 어디로도 전송되지 않습니다. 그전까지 AI Client는 비용도 통신도 없는 휴면 라이브러리입니다.

Abilities API는 무엇을 위한 것인가요? 플러그인이 JSON Schema 입력과 출력, 권한 콜백, 실행 콜백을 갖춘 이름 붙은 기능 단위를 선언할 수 있게 해 주는 레지스트리입니다. AI 모델과 Command Palette를 포함한 다른 소프트웨어가 사이트가 할 수 있는 일을 열거하고 호출할 수 있습니다. PHP 절반은 WordPress 6.9에서, JavaScript 절반은 7.0에서 출시되었습니다.

WordPress 7.0은 어떤 PHP 버전을 요구하나요? WordPress 7.0부터 지원되는 최소 버전은 PHP 7.4이며, 이 릴리스에서 PHP 7.2와 7.3 지원이 중단되었습니다. 권장 최소 버전은 여전히 PHP 8.3입니다. PHP 7.4는 2022년 11월에 수명이 끝났으므로 최소 요건만 맞춘다는 것은 지원되지 않는 인터프리터를 돌린다는 뜻이며, 실질적인 요구 사항은 8.3 이상이라고 보십시오.

실시간 공동 편집은 이제 사용할 수 있나요? 코어에서는 아닙니다. 경쟁 상태, 서버 부하, 메모리 효율에 대한 우려로 출시 12일 전에 WordPress 7.0에서 제거되었고, WordPress 7.1에서도 활성화되지 않았습니다. 멘션이 가능한 블록 단위 코멘트를 제공하는 별개의 Notes 기능은 출시되었으며, 동시 입력이 아니라 검토 워크플로를 담당합니다.