워드프레스가 차기 대형 업데이트로 예고한 실시간 협업 기능을 둘러싸고, 코어 개발팀이 구현 난도를 공개적으로 드러내고 있다. 3월 19일 공개된 WordPress 7.0 RC1에는 구글 독스에 가까운 공동 편집 경험이 포함됐지만, 동기화 방식과 데이터 처리 설계에서 해결해야 할 과제가 남아 있다는 평가가 커뮤니티에서 이어진다. 특히 이 기능은 단순히 에디터에 ‘동시 편집’을 붙이는 수준이 아니라, 충돌 처리와 기록 추적, 권한 체계까지 포괄하는 소프트웨어 개발 이슈로 번졌다.
이번 릴리스는 4월 9일 정식 배포를 목표로 하고, Beta 3 이후 101건 이상의 수정이 반영됐다. 그만큼 막판 안정화가 빠르게 진행되고 있다는 신호이기도 하다. 다만 워드프레스가 강점으로 삼아온 폭넓은 호스팅 환경 호환성을 유지하면서도, 협업 도구 수준의 즉시성을 구현해야 한다는 점이 부담으로 작용한다. 웹 에이전시에서 다수 클라이언트 사이트를 운영하는 ‘민서’ 같은 퍼블리셔에게는, 편집 속도와 검수 체계가 바뀌는 문제이기도 하다. 결국 관전 포인트는 ‘기능이 들어갔느냐’가 아니라, 개발 과정에서 드러난 어려움을 어떻게 정리해 생태계 전체로 확산시키느냐다.
WordPress 7.0 RC1 실시간 협업 기능 개발의 핵심과 남은 과제
WordPress 7.0에서 가장 큰 변화로 꼽히는 건 블록 에디터의 실시간 협업이다. 여러 사용자가 같은 글을 동시에 편집할 수 있고, 각 사용자의 커서 위치가 추적되는 방식은 문서형 협업 도구의 문법을 워드프레스 안으로 끌어온다. 민서는 스테이징 환경에서 RC1을 적용해 편집자와 디자이너가 같은 페이지를 동시에 손보는 테스트를 진행했는데, 수정 요청이 댓글·메신저로 분산되지 않고 에디터 안에서 정리된다는 점이 가장 큰 변화로 꼽힌다.
기술적으로는 WebSocket이 아니라 HTTP 폴링 기반 동기화를 채택했다. 별도 서버 설정 없이 공유 호스팅에서도 작동하도록 설계한 선택인데, 워드프레스가 지닌 설치 기반을 고려하면 현실적인 접근이라는 평가가 나온다. 동시에 ‘진짜 실시간’에 대한 기대치가 높아진 상황에서, 폴링 방식이 부하·지연·충돌 해결에서 어떤 한계를 보일지가 안정화의 관건이 된다. 워드프레스가 범용 CMS를 넘어 협업형 편집 환경으로 이동하는 순간, 데이터 동기화는 곧 제품 신뢰로 직결되기 때문이다.
콘텐츠 전용 모드와 디바이스별 블록 표시가 바꾸는 웹 개발 워크플로우
실시간 편집만큼이나 현장 반응이 갈리는 변화는 ‘콘텐츠 전용(Content Only) 모드’의 기본 적용이다. 패턴을 사용할 때 텍스트·이미지 같은 콘텐츠 영역만 수정할 수 있고, 레이아웃은 잠겨 의도치 않은 붕괴를 줄인다. 이는 클라이언트가 빈번히 접근하는 사이트에서 반복되던 “왜 디자인이 깨졌지?” 같은 사고를 줄이려는 방향으로 읽힌다. 민서가 관리하는 기업 블로그에서도, 작성자는 글만 바꾸고 디자인은 유지하는 흐름이 정착되면 검수 시간이 짧아질 가능성이 크다.
반응형 처리도 에디터 레벨에서 한 단계 내려왔다. WordPress 7.0은 디바이스별 블록 가시성을 제공해 모바일·태블릿·데스크톱에서 특정 블록을 보여줄지 여부를 UI로 제어한다. 기존에는 커스텀 CSS나 테마 수정으로 해결하던 작업이 편집 화면 안으로 들어온 셈이다. 이런 변화는 웹 개발에서 ‘코드 작성’의 비중을 줄인다는 의미도 있지만, 반대로 디자인 규칙과 승인 절차를 어떻게 유지할지 프로젝트 관리 관점의 재정의가 필요해진다.
여기에 Command Palette(단축키 ⌘K 또는 Ctrl+K)와 DataViews 개선이 더해지며, 관리자 화면의 이동·검색·정렬이 빨라진다. 대규모 사이트에서 운영팀이 체감하는 변화는 ‘새 기능’보다 이런 미세한 속도 개선에서 더 크게 나타나는 경우가 많다. 결국 7.0은 편집기 기능 확장과 운영 효율화가 한 묶음으로 설계된 릴리스라는 인상을 남긴다.
AI 인프라와 개발자 도구 업데이트가 요구하는 버전 관리 전략
WordPress 7.0은 AI를 코어 차원에서 연결하기 위한 기반도 포함한다. WP AI Client는 WordPress와 외부 LLM 간 통신을 표준화하고, Abilities API는 AI 기능을 등록·관리하는 구조를 마련한다. 워드프레스 생태계에서 AI는 이미 플러그인 형태로 빠르게 확산돼 왔지만, 코어 레벨 표준이 생기면 플러그인 간 중복 구현을 줄이고 상호 운용성을 높일 여지가 생긴다. 다만 이는 곧 “어떤 기능이 코어의 공통 규칙을 따르는가”라는 새로운 호환성 이슈를 만들 수도 있다.
개발자 측면에서도 변화 폭이 크다. PHP만으로 블록을 등록하는 흐름, 블록 스타일링을 정교화하는 API, 서버 사이드 SVG 아이콘 등록(REST 엔드포인트 /wp/v2/icons), wp-env Playground의 phpMyAdmin 지원, Interactivity API 개선 등이 포함됐다. 여기에 PHP 7.4+가 필수 요건으로 올라오면서, 구버전 PHP에 묶여 있던 사이트는 업그레이드가 사실상 강제된다. 운영팀 입장에서는 기능 채택보다 서버·플러그인·테마 호환성 검증이 먼저라는 현실이 다시 확인된다.
이런 시기에는 릴리스 노트보다 “누가 어떤 기준으로 업데이트를 결정하느냐”가 더 중요해진다. 민서는 RC1을 설치한 뒤, 플러그인 의존도를 기준으로 테스트 우선순위를 나누고, 배포 승인 절차를 문서화했다. 실시간 편집이 들어오면 충돌 가능성이 높아지기 때문에, 코드뿐 아니라 콘텐츠 변경에 대한 버전 관리 원칙도 정리해야 한다는 판단에서다. 디지털 산업 전반에서 플랫폼이 기능을 넓힐수록 운영 리스크가 커지는 흐름은 다른 영역에서도 반복돼 왔다. 예컨대 규제와 시장 구조 변화가 플랫폼 전략에 영향을 주는 사례는 미국 시장에서의 코인베이스 관련 흐름처럼, 제품 로드맵이 외부 조건과 함께 움직이는 장면에서도 확인된다.
광고·마케팅 플랫폼에서도 ‘맥락 기반’ 설계가 운영의 핵심이 되는 추세다. 워드프레스가 에디터 안에 코멘팅과 협업 맥락을 심는 방향은, 데이터와 워크플로우를 한 화면에 묶으려는 산업적 흐름과도 닮아 있다. 이는 메타의 맥락 기반 광고 포맷처럼, ‘사용자가 있는 자리에서 바로 결정하게 만드는 인터페이스’가 경쟁력이 되는 흐름과 맞닿아 있다. 워드프레스가 7.0에서 보여준 방향성은 결국 협업 경험의 표준을 어디까지 끌어올릴 수 있느냐로 귀결된다.
