WordPress Interactivity API 실전 적용의 공식 문서에는 기능 계약과 운영 경계를 분리해 읽어야 할 변화가 담겼다. 중요한 이유는 공식 문서의 기능 계약과 실제 운영 결과를 구분해야 장애 원인과 도입 판단이 달라지기 때문이다. WordPress 테마·플러그인 개발팀과 사이트 운영팀이 먼저 체감한다.
핵심 요약
무엇이 바뀌었나 Interactivity API는 WordPress 블록의 프런트엔드 상호작용을 선언적 지시자와 store로 구성하는 표준 경로다.
왜 중요한가 기능 계약과 실제 운영 결과를 구분해야 장애 원인과 도입 판단이 달라진다.
누가 먼저 체감하나 먼저 체감하는 쪽은 테마·플러그인 담당팀과 사이트 운영팀이다. 기능 계약과 실제 운영 결과의 차이를 함께 다뤄야 한다.
기능 계약과 운영 관측의 차이
WordPress 공식 개발자 문서를 기준으로 Interactivity API의 지시자와 store, 서버 렌더링, region 기반 클라이언트 탐색, 호환성 경계를 정리한다. 운영팀은 빠른 화면 전환만 볼 것이 아니라 스크립트 모듈 로딩, router region, DOM 변경 방식과 전체 페이지 전환 폴백을 함께 검증해야 한다.
쉽게 말하면 공식 문서는 기능이 따라야 할 계약을 제공하고, 운영팀의 테스트는 그 계약이 특정 환경에서 어떻게 작동했는지를 보여준다. 두 증거는 서로 대체되지 않는다.
공식 문서가 확인한 범위는 어디까지인가?
답은 공개 원문이 직접 뒷받침하는 기능 계약까지다.
Interactivity Router의 권장 탐색 방식은 같은 이름의 router region만 교체하는 region 기반 클라이언트 탐색이다.
직접 DOM을 변경하는 사용자 코드와 호환되지 않는 스크립트는 클라이언트 탐색 뒤 상태나 초기화가 깨질 수 있다.
서버 지시자 처리는 초기 HTML에 상태와 상호작용 정보를 반영해 클라이언트 기능과 서버 렌더링을 연결한다.
기능과 운영 책임은 어떻게 나뉘나?
핵심은 기능 계약과 운영 관측을 한 성공 판정으로 합치지 않는 데 있다.
| 확인된 내용 | 직접 근거 | 운영상 의미 |
|---|---|---|
| Interactivity API는 WordPress | 공식 근거 A · 3개 URL | router region을 좁게 정의하고 기존 전체 페이지 탐색을 |
| Interactivity Router의 권장 탐색 | 공식 근거 B · 3개 URL | vanilla DOM 변경과 전역 스크립트 의존성을 배포 전에 호환성 |
| 직접 DOM을 변경하는 사용자 코드와 호환되지 않는 | 공식 근거 C · 3개 URL | 서버 렌더 결과, 키보드 포커스, 스크린리더 알림과 브라우저 기록을 함께 |
| 서버 지시자 처리는 초기 HTML에 상태와 상호작용 | 공식 근거 D · 1개 URL | router region을 좁게 정의하고 기존 전체 페이지 탐색을 |
실제 적용에서는 무엇을 시험하나?
따라서 예를 들어 WordPress 구현팀은 핵심 기능 하나를 최소 환경에서 실행한 뒤 입력, 출력, 오류, 외부 부작용을 서로 다른 영수증으로 남길 수 있다. 네 결과를 한 성공 판정으로 합치지 않으면 실패 지점을 다시 찾기 쉽다.
가령 대상 환경의 버전이나 권한을 바꿔 같은 기능을 다시 실행하면 문서가 설명한 계약과 실제 관측의 차이가 드러난다. 공개 원문에 없는 성공률이나 호환성은 추정값이 아니라 미확정 항목으로 남는다.
도입 전 체크리스트
- 현재 테마와 플러그인의 상호작용 코드가 client-side navigation 호환 규칙을 지키는가?
- 탐색 중 새 페이지가 요구하는 script module과 스타일이 모두 로드되는가?
- 오류, 포커스 이동, 브라우저 기록과 전체 페이지 폴백을 어떤 환경에서 검증했는가?
- 각 핵심 주장과 직접 연결된 공식 URL
- 기능 계약과 실제 환경 관측값을 구분한 테스트 영수증
- 오류·호환성·폴백 조건의 재현 기록
공식 문서 밖에 남은 한계
- 현재 근거는 4개의 공개 원문에 한정된다.
- 공식 문서는 기능과 호환성 계약을 설명하지만 특정 앱이나 사이트의 성공률을 대신 증명하지 않는다.
- 문서가 갱신되거나 런타임·테마·플러그인 조건이 바뀌면 같은 테스트를 다시 실행해야 한다.
자주 묻는 질문
현재 테마와 플러그인의 상호작용 코드가 client-side navigation 호환 규칙을 지키는가?
답은 공식 문서만으로는 부족하다는 것이다. 공식 문서는 기능 계약의 기준이지만 대상 환경의 실제 동작까지 보장하지 않으므로 원문과 재현 가능한 테스트 영수증이 함께 필요하다.
탐색 중 새 페이지가 요구하는 script module과 스타일이 모두 로드되는가?
핵심은 기능 입력과 출력, 오류 경로, 호환성, 폴백 조건을 같은 버전과 환경에서 관측한 기록이다.
