워드프레스 7.1 AI 기능의 public은 공개 실행이 아닙니다: Abilities API 노출표

핵심만 먼저

WordPress 7.1은 Abilities API의 메타데이터에 `public` 불리언 값을 통합했습니다. 공식 개발자 노트에 따르면 등록할 때 값을 주지 않으면 기본값은 `false`입니다. 하지만 `public: true`를 설정했다고 로그인하지 않은 누구나 기능을 실행할 수 있다는 뜻은 아닙니다. 외부 클라이언트가 이 기능을 사용할 의도가 있다는 메타데이터이며, 실제 REST 노출·인증·사용자 권한·입력 검증은 별도로 봐야 합니다.

AI 플러그인이나 외부 자동화가 워드프레스 기능을 호출한다면 “보이는가”와 “실행 가능한가”, “무엇을 바꾸는가”를 세 칸으로 나누세요. 한 칸으로 묶으면 읽기 기능과 글 삭제 같은 변경 기능을 같은 위험도로 취급하게 됩니다.

Abilities API와 public은 무엇인가요

Abilities API는 워드프레스 사이트가 할 수 있는 일을 구조화하고 조회할 수 있게 하는 기반입니다. 예를 들어 사이트 정보 조회, 현재 사용자 정보, 플러그인이 제공하는 특정 작업을 능력으로 등록할 수 있습니다. AI 도구나 외부 클라이언트는 이 목록을 보고 사용할 기능을 찾을 수 있습니다.

WordPress 7.1의 `meta.public`은 여러 외부 클라이언트에서 일반적으로 사용할 의도가 있는지 표시합니다. 기존 `show_in_rest`처럼 특정 채널에 대한 설정은 계속 유효하며 더 구체적인 설정이 우선할 수 있습니다. 따라서 `public` 하나만 보고 실제 REST 경로나 권한을 추측해서는 안 됩니다.

오늘 이슈와 공식 근거

WordPress Core 개발자 노트는 모든 ability의 해석된 메타데이터에 `public`이 항상 불리언으로 존재하고, 생략하면 false가 된다고 설명합니다. 기존에 `show_in_rest`나 `public`을 주지 않은 기능은 REST에서 사용할 수 없는 기존 동작을 유지합니다. 외부 여러 클라이언트에 노출하려는 경우 `public`을 고려하고, 특정 채널에만 공개하려면 채널별 설정을 쓰라고 안내합니다.

WordPress 7.1 Field Guide와 개발자 업데이트는 Abilities API가 AI 통합과 외부 도구의 기반이라고 설명하지만, 실시간 협업·일부 AI 기능처럼 로드맵에 있던 모든 항목이 최종 릴리스에 들어온 것은 아니라고 구분합니다. 로드맵 문구만 보고 운영 기능으로 전제하지 말고 실제 릴리스 노트를 기준으로 확인해야 합니다.

사장님 실무 적용 6단계

1. 등록된 ability 목록을 내보냅니다. 플러그인명, ability 이름, 설명, 입력·출력 스키마를 한 표에 모읍니다.
2. 노출 채널을 분리합니다. `public`, `show_in_rest`, 다른 채널별 설정을 각각 기록합니다. true 하나를 전체 공개로 번역하지 않습니다.
3. 읽기와 변경을 나눕니다. 사이트 정보 조회, 초안 생성, 게시, 사용자 변경, 파일 삭제처럼 부작용 수준을 적습니다.
4. 실제 권한 검사를 확인합니다. 익명·구독자·작성자·편집자·관리자 역할별로 실행 결과가 어떻게 다른지 테스트 환경에서 봅니다.
5. 입력 실패를 시험합니다. 비어 있는 값, 지나치게 긴 값, 다른 사용자의 ID, 외부 URL, 스크립트 문자열을 넣어 거절되는지 확인합니다.
6. 감사 로그와 중단 수단을 둡니다. 누가 어떤 ability를 언제 호출했고 무엇이 바뀌었는지 남기며, 문제 시 플러그인이나 채널 노출을 즉시 끌 수 있어야 합니다.

노출표의 최소 열은 `ability / 제공 플러그인 / public / REST / 인증 필요 / 최소 역할 / 읽기·변경 / 외부 전송 / 되돌리기 / 로그`입니다. 개발자가 아닌 운영자도 이 표만 보면 어떤 기능이 게시·삭제·전송을 일으키는지 알 수 있어야 합니다.

흔한 실수

• `public: true`를 익명 실행 허용과 같은 뜻으로 설명합니다.
• 메타데이터 노출과 실제 권한 검사를 한 단계로 봅니다.
• 로드맵에 있던 기능을 최종 릴리스 기능으로 단정합니다.
• 조회 기능과 게시·삭제 기능에 같은 승인 절차를 적용합니다.
• 관리자 계정으로만 시험하고 낮은 권한 역할의 차단을 확인하지 않습니다.
• AI가 호출한 작업을 일반 관리자 로그와 구분하지 않습니다.

제스토코스트의 판단

Abilities API의 가치는 AI가 무엇이든 하게 만드는 데 있지 않습니다. 사이트가 제공하는 기능을 이름·입력·권한·부작용으로 드러내 통제 가능한 계약으로 만드는 데 있습니다. 보이지 않는 자동화를 줄이는 방향으로 써야 합니다.

`public`은 출발점이지 보안 결론이 아닙니다. 외부에서 발견 가능한 기능은 더 강한 인증과 역할 검사가 필요할 수 있습니다. 특히 게시·삭제·사용자·파일·결제에 닿는 ability는 사람 확인과 되돌리기 경로가 없으면 운영에 연결하지 않는 편이 안전합니다.

자주 묻는 질문

`public`을 생략하면 어떻게 되나요?

WordPress 7.1 공식 개발자 노트는 해석된 메타데이터의 기본값이 `false`라고 설명합니다. 기존 채널별 설정이 있다면 그 설정의 권위와 실제 동작을 함께 확인해야 합니다.

`public: true`면 로그아웃 사용자도 실행할 수 있나요?

그렇게 단정할 수 없습니다. public은 일반 외부 사용 의도를 나타내는 메타데이터이고 실제 접근은 채널 설정, 인증, 사용자 권한, 콜백 검증에 달려 있습니다.

운영 사이트에서 바로 시험해도 되나요?

읽기 전용이 아닌 기능은 권장하지 않습니다. 스테이징에서 역할별 호출, 잘못된 입력, 중복 실행, 되돌리기를 먼저 검증하고 운영 연결 범위를 좁혀야 합니다.

출처

• WordPress Core: WordPress 7.1 Abilities의 통합 public 노출 플래그
• WordPress Developer Blog: 2026년 8월 개발자 업데이트와 7.1 Field Guide
• WordPress Core: WordPress 7.1 로드맵

CTA

AI나 외부 자동화 플러그인을 쓰고 있다면 등록된 ability부터 열 칸 노출표로 옮겨 보세요. `public`보다 먼저 읽기·변경 여부와 최소 사용자 역할이 비어 있지 않은지 확인하시기 바랍니다.

편집 고지: 이 글은 공식 자료 조사와 초안 정리에 자동화 도구를 활용했으며, 공개 전 출처·표현·실무 적합성을 검수합니다.