"WordPress의 힘은 항상 코어(core), 플러그인(plugins), 테마(themes) 전반에 흩어져 있는 수천 개의 기능에 있었지만, 소스 코드를 읽을 의지가 있는 개발자가 아니라면 발견할 수 없었습니다." — 이것이 바로 WordPress AI 팀이 해결하고자 했던 문제이며, Abilities API가 그에 대한 그들의 해답입니다.

WordPress로 조금이라도 복잡한 것을 구축해 본 적이 있다면, 여러분은 이미 그 패턴을 알고 있을 것입니다. 특정 기능이 필요하면 함수를 작성하고, 어딘가에 훅(hook)을 걸고, 외부에서 접근해야 한다면 REST 경로(route)로 감싸고, 직접 유효성 검사(validation)를 작성하고, 권한 확인(permission check)을 수행한 뒤, 아무도 읽지 않는 문서(docs)를 작성합니다. 모든 플러그인, 모든 사이트, 그리고 여러분의 뒤를 잇는 모든 개발자에 대해 이 과정을 반복해야 합니다.

WordPress 6.9는 이 전체 패턴을 조용히 재설계하는 새로운 코어 API를 출시합니다. 이것을 Abilities API라고 부르며, WordPress AI 팀이 코어에 도입하고 있는 네 가지 "AI 빌딩 블록(AI Building Blocks)" 중 첫 번째입니다. 하지만 "AI"라는 프레임 때문에 이것이 단순히 덧붙여진 챗봇 기능이라고 생각하지 마세요. 이 API가 실제로 제공하는 것은 관리자 대시보드, REST 클라이언트, WP-CLI 명령, 또는 AI 에이전트(AI agent)가 소비하든 상관없이 어떠한 기능 단위라도 노출할 수 있는 표준화되고, 타입이 지정되었으며(typed), 권한이 부여되고, 발견 가능한(discoverable) 방식입니다.

이제 이를 제대로 파헤쳐 보고, 이것을 사용하여 무언가를 만들어 보겠습니다.

🤔 그래서 "Ability"란 정확히 무엇인가요?

잠시 AI 마케팅 용어를 걷어내 보겠습니다. Ability는 단순히 네 가지 부분으로 구성된 독립적이고 이름이 지정된 기능 단위입니다:

• 고유한 이름 (A unique name) — namespace/ability-name 형태이며, 여기서 네임스페이스(namespace)는 보통 플러그인 슬러그(plugin slug)입니다.
• 스키마 (A schema) — 어떤 입력을 기대하고 어떤 출력을 반환하는지를 나타내며, 둘 다 JSON Schema로 설명됩니다.
• 권한 확인 (A permission check) — 누가(또는 무엇이) 이를 실행할 수 있는지 결정합니다.
• 실행 콜백 (An execution callback) — 실제 PHP 로직입니다.

그게 전부입니다. 일단 등록되면, 이 단일 정의는 PHP에서 직접, WP-CLI에서, REST API를 통해, 그리고 — 그 형태가 Model Context Protocol (MCP)와 깔끔하게 매핑되기 때문에 — 도구 레지스트리 (tool registry)를 읽는 방법을 아는 모든 AI 에이전트로부터 동시에 사용 가능합니다.

우리가 항상 해왔던 방식과 비교해 보세요. 커스텀 함수, 자체 검증 로직이 포함된 별도의 register_rest_route() 호출, 콜백 어딘가에 숨겨진 수동 current_user_can() 체크, 그리고 누군가 코드를 읽거나 (아마도 오래된) 문서를 읽지 않는 한 발견할 방법이 전혀 없는 상태 말입니다. Abilities API는 이 모든 글루 코드 (glue code)를 하나의 선언적 등록 (declarative registration)으로 통합합니다.

🧩 이것이 지금 출시되는 이유

이것은 무작위로 추가된 기능이 아닙니다. 이는 WordPress가 AI 시스템이 이해할 수 있도록 만들려는 광범위한 추진력의 기초적인 조각입니다. 이는 개발 도구 세계 전반에서 MCP 채택을 이끌어온 것과 동일한 본능입니다. Abilities API 공식 GitHub 저장소는 이를 명확하게 설명합니다. 즉, 인간과 기계 모두 읽을 수 있는 통합 레지스트리를 구축하여, 개발자와 AI 에이전트를 포함한 다양한 플랫폼의 자동화 도구가 기능을 발견할 수 있도록 하는 것입니다.

show_in_rest가 활성화된 상태로 기능(ability)이 등록되면, /wp-json/wp-abilities/v1/{namespace}/{ability}를 통해 자동으로 접근할 수 있습니다. 여기에 WordPress MCP 어댑터 (MCP Adapter) 플러그인을 결합하면, AI 에이전트는 사이트에 "무엇을 할 수 있나요?"라고 물었을 때 추측 대신 구조화되고 타입이 지정된 (typed) 답변을 받을 수 있습니다. 이는 WordPress의 진정한 태도 변화입니다. 즉, "AI 도구가 당신의 REST 경로를 역공학(reverse-engineer)하는 방식"에서 "당신의 사이트가 자체적인 기능 메뉴를 게시하는 방식"으로 이동하는 것입니다.

그리고 실질적인 이점은 결코 AI에만 국한되지 않습니다. 등록하는 모든 기능은 다음과 같은 이점을 무료로 제공합니다: 자동 입출력 검증 (input/output validation), 함께 배치된 권한 체크 (permission check), 올바른 HTTP 동사 (HTTP verb)가 이미 선택된 REST 엔드포인트, 그리고 미래의 당신(또는 프로젝트의 다음 개발자)이 플러그인이 실제로 무엇을 하는지 이해하기 위해 찾아볼 수 있는 단일한 장소입니다.

🏗️ 핵심 구성 요소

코드를 작성하기 전에 어휘를 익혀두는 것이 도움이 됩니다. 이 API는 다섯 가지 기본 요소(primitives)를 기반으로 하기 때문입니다:

기본 요소 (Primitive)	설명
Ability	WP_Ability 인스턴스 — 기능 그 자체의 단위
...

가장 중요한 두 가지 훅(hook)은 다음과 같습니다: wp_abilities_api_categories_init (여기에 카테고리를 등록하세요. 가장 먼저 실행됩니다)와 wp_abilities_api_init (rest_api_init에 대응하는 Abilities API의 응답으로, 여기에 능력을 등록하세요). 실행 순서가 뒤바뀌면 능력이 등록되지 않고 조용히 실패합니다. 치명적인 오류(fatal error)가 발생하는 것은 아니지만, 단지 나타나지 않을 뿐입니다.

🛠️ 첫 번째 능력(Ability)을 올바르게 등록하기

장난감 예제 대신 실제 작동하는 무언가를 만들어 보겠습니다. 여기에는 사이트 상태 데이터의 정제된 스냅샷(sanitized snapshot)을 반환하는 능력을 등록하는, 객체 지향(OOP) 방식이며 PHPCS를 준수하는 작은 플러그인 구조가 있습니다. 이는 모니터링 대시보드나 AI 에이전트가 실제로 쿼리(query)하고 싶어 할 만한 유형의 기능입니다.

구조가 코드만큼 중요하므로 파일 구조부터 살펴보겠습니다:

site-pulse/
├── site-pulse.php
├── includes/
...

site-pulse.php — 이전 버전의 WordPress를 대비한 방어 코드가 포함된 진입점(entry point)입니다:

<?php
/**
 * Plugin Name: Site Pulse
...

includes/class-site-pulse-bootstrap.php — 등록 훅(registration hooks)을 관리하는 싱글톤(singleton)으로, 느슨한 함수 대신 순수한 객체 지향(OOP) 방식을 유지합니다:

<?php
/**
 * Plugin bootstrap.
...

includes/abilities/class-site-pulse-health-ability.php — 검증(validation), 정제(sanitization), 이스케이핑(escaping)을 타협할 수 없는 필수 사항으로 다루는 능력(ability) 정의 자체입니다:

<?php
/**
 * Site health Ability.
...

여기서 등록용 상용구(boilerplate) 이상의 어떤 일이 일어나고 있는지 주목하십시오. absint()와 sanitize_text_field()는 콜백(callback)을 떠나기 전 모든 값에 대해 실제 작업을 수행하고 있으며, 권한 콜백(permission callback)은 막연한 "로그인 여부" 확인 대신 특정 권한(capability)을 확인합니다. 또한 어노테이션(annotations)은 이 능력을 readonly로 정직하게 선언하여, REST 레이어가 이를 POST 대신 GET으로 라우팅하도록 합니다. 어노테이션을 속이는 것은 단순히 HTTP 메서드(HTTP verbs)를 잘못 라우팅하는 것에 그치지 않습니다. 이는 AI 플래너(AI planners)에게 안전하지 않은 작업을 안전하다고 말하거나, 완전히 무해한 작업을 안전하지 않다고 말하는 결과를 초래합니다.

이제 PHP 어디에서나 호출하는 방법은 매우 간단합니다:

$ability = wp_get_ability( 'site-pulse/get-health-snapshot' );

if ( $ability ) {
...

is_wp_error() 체크는 선택 사항이 아닙니다. PHP에서 WP_Error는 참(truthy)으로 취급되므로, 게으르게 if ( $result )라고 작성하면 실행 실패를 성공으로 기쁘게 처리해 버릴 것입니다. 이는 평생 기억하기 전 딱 한 번 당신을 괴롭힐 작은 함정(gotcha)입니다.

💡 구축할 가치가 있는 실무 플러그인 및 테마 아이디어

여기서부터 진정으로 재미있어집니다. Abilities API는 단순히 기존에 작성하던 방식을 더 깔끔하게 만드는 도구가 아닙니다. 이는 이전에는 구현하기 위해 너무 많은 접착 코드(glue code)가 필요하여 포기해야 했던 기능의 문을 열어줍니다. "이번 주말에 만들기" 수준부터 "하나의 제품이 될 수 있는" 수준까지, 탐구해 볼 만한 몇 가지 아이디어를 소개합니다.

접근성 감사(accessibility audit) 능력. theme-slug/audit-accessibility를 등록하여 현재 페이지의 렌더링된 블록을 스캔하고, 누락된 대체 텍스트(alt text), theme.json 팔레트의 낮은 대비 색상 조합, 그리고 제목 순서 위반 사항을 찾아 구조화된 보고서를 반환하도록 합니다. AI 에이전트나 관리자 대시보드 위젯이 저장할 때마다 이를 호출하여 게시 전 문제를 표시할 수 있습니다.

모든 것을 위한 폼-투-에니씽 (form-to-anything) 웹훅 브리지. 폼 플러그인에 Zapier 스타일의 통합 기능을 하드코딩하는 대신, forms/dispatch-submission을 destructive: false, idempotent: false 어노테이션(annotation)과 함께 하나의 능력(ability)으로 노출하세요. 이제 MCP를 인식하는 모든 자동화 도구가 이를 직접 트리거할 수 있으며, 여러분은 Slack, CRM, 이메일, 그리고 다음 분기에 고객이 요청할 그 어떤 서비스들을 위해 15개의 일회성 통합 포인트를 만드는 대신 단 하나의 통합 포인트만을 구축하게 됩니다.

편집 팀을 위한 콘텐츠 브리프 생성기. 주제와 타겟 키워드를 입력받아 WP_Query를 통해 관련 내부 포스트를 가져오고, 구조화된 개요 스캐폴딩(scaffold, 제목, 제안된 내부 링크, 예상 단어 수 포함)을 반환하는 능력을 등록하세요. 편집자는 커스텀 블록에서 이를 트리거할 수 있으며, AI 글쓰기 어시스턴트도 정확히 동일한 보장 조건 하에 동일한 능력을 호출할 수 있습니다.

지원 도구를 위한 WooCommerce 스타일의 주문 조회 능력. manage_woocommerce에 상응하는 권한(capability)으로 보호되는 shop/get-order-summary와 같은 기능을 통해, 정제된 주문 상태, 이행 단계 및 고객에게 안전한 세부 정보를 반환합니다. 이는 누군가 맞춤형 REST 경로를 수동으로 만들고 인증이 완벽하기를 기도할 필요 없이, "내 주문이 어디 있나요?"라는 질문에 답해야 하는 내부 지원 챗봇에 완벽합니다.

다국어 콘텐츠 동기화 확인 도구. WPML 또는 Polylang을 사용 중이라면, 포스트를 번역본과 비교하여 오래되었거나 누락된 언어 버전을 표시하는 능력을 통해 수동 QA 작업을 예약된 에이전트나 WP-CLI cron이 무인으로 실행할 수 있는 작업으로 전환할 수 있습니다.

고객 인계 시 활용하는 헤드리스(headless) "이 사이트가 무엇을 할 수 있는가" 탐색 엔드포인트. 나중에 자체 개발자를 고용할 고객을 위해 사이트를 구축하는 경우, 커스텀 포스트 타입(custom post types)과 메타 필드(meta fields)에 대해 깔끔한 능력 세트를 등록해 두면, 다음 개발자(사람 또는 AI 지원 개발자)가 코드베이스를 일일이 파헤치지 않고도 사이트의 커스텀 기능을 발견할 수 있습니다.

공통점은 다음과 같습니다: 평소에 커스텀 REST 라우트(REST route), AJAX 핸들러(AJAX handler), 또는 WP-CLI 명령어를 작성하면서 검증(validation)과 권한(permissions)을 별도로 걱정해야 했던 모든 곳에서, 어빌리티(ability)는 이 세 가지를 하나의 선언적 블록(declarative block)으로 제공합니다.

🔐 여기서 실제로 중요한 보안 체크리스트

Abilities API는 구조를 제공하지만, 기본적으로 보안을 보장해주지는 않습니다. 그 부분은 여전히 매번 사용자의 몫입니다:

• 먼저 검증하고, 아무것도 믿지 마세요. 입력 스키마(Input schemas)는 권한 콜백(permission callback) 이전에 실행되므로 이는 좋지만, 스키마는 형태(shape)만 확인할 뿐 비즈니스 로직(business logic)은 확인하지 못합니다. 콜백 내부에서 자체적인 경계 검사(bounds checking)를 추가하세요.
• 들어올 때는 정화(Sanitize)하고, 나갈 때는 이스케이프(escape)하세요. 입력값이 JSON 스키마(JSON Schema) 검증을 통과했다고 해서 데이터베이스 쿼리에 바로 넣거나 이스케이프 없이 렌더링해도 안전하다는 뜻은 아닙니다. 어빌리티 입력을 REST 입력과 똑같이 취급하세요. 기능적으로는 동일하기 때문입니다.
• 권한 콜백의 범위를 엄격하게 제한하세요. 모든 것을 포괄하는 is_user_logged_in() 대신, 상황에 맞는 가장 좁은 범위의 WordPress 권한(capability)을 사용하세요. 취약한 권한 검사 뒤에 숨겨진 destructive(파괴적) 어빌리티는 발견 가능한 REST 엔드포인트(endpoint)가 연결된 취약점이 됩니다.
• 어노테이션(annotations)을 정직하게 작성하세요. readonly(읽기 전용), destructive(파괴적), idempotent(멱등성)는 단순히 미적인 요소가 아닙니다. 이들은 엔드포인트가 허용하는 HTTP 메서드(verb)를 결정하며, 자동화된 도구가 무엇을 재시도해도 안전하다고 가정할지를 결정합니다.
• 출력 스키마(output schemas)를 통해 비밀 정보를 절대 유출하지 마세요. show_in_rest가 true로 설정되면 출력 스키마는 사실상 공개 계약(public contract)이 됩니다. 공개 API 응답을 다루는 것과 동일한 방식으로 취급하세요.

🌐 다음 단계

WordPress 6.9는 서버 측 기반인 등록(registration), 레지스트리(registry), REST 노출(REST exposure)을 탑재하여 출시됩니다. 브라우저 측 권한(abilities)을 위한 JavaScript 클라이언트는 이미 Gutenberg 패키지를 통해 병행 개발되고 있으며, 이는 AI 에이전트가 블록 에디터 자체를 제어하는 것(예: 블록 선택, 관리자 페이지 탐색, 서버 권한이 PHP를 실행하는 것과 동일한 방식으로 클라이언트 측 액션 실행)을 목표로 합니다. 이러한 기능은 이후 릴리스가 이 6.9 기반 위에서 구축됨에 따라 더욱 성숙해질 것으로 예상됩니다.

하지만 더 큰 변화는 기술적인 것이 아니라 아키텍처(architectural)적인 것입니다. WordPress는 지난 20년 동안 관례(conventions)와 암묵적 지식(tribal knowledge)으로 묶인, 훌륭하지만 파편화된 기능들의 생태계로 존재해 왔습니다. Abilities API는 이러한 기능들을 '읽을 수 있게(legible)' 만들기 위한 최초의 본격적인 코어 레벨(core-level) 시도입니다. 즉, 레지스트리를 훑어보는 사람, 워크플로우(workflows)를 구성하는 자동화 도구, 그리고 사이트에 접근하기 전 사이트가 실제로 무엇을 할 수 있는지 이해하려는 AI 에이전트 모두에게 말입니다.

만약 여러분이 현재 플러그인이나 테마를 제작하고 있다면, AI 활용 사례를 염두에 두지 않더라도 지금부터 권한(abilities) 관점의 사고를 시작하기에 좋은 시점입니다. 검증(validation), 권한 부여(permission), 그리고 발견 가능성(discoverability) 측면의 이점은 최종적으로 누가 — 혹은 무엇이 — 여러분의 코드를 호출하든 상관없이 그 가치를 충분히 증명할 것입니다.

여러분은 첫 번째 권한(Ability)을 등록해 보셨나요? 혹은 제가 여기서 다루지 않은 활용 사례를 발견하셨나요? 여러분이 무엇을 만들고 있는지 정말 궁금합니다 — 아래에 댓글을 남겨주세요. 👇