WordPress 7.0은 WordPress 코어에 직접 내장된 네이티브 AI 클라이언트(wp_ai_client_prompt())라는 거대한 기능을 조용히 출시했습니다.

단 한 번의 함수 호출로 Anthropic, OpenAI, Google 등 등록된 어떤 제공업체(provider)든 사용할 수 있습니다. 플러그인의 설정 페이지에서 API 키를 씨름하며 관리할 필요도 없고, 사용자들을 특정 업체에 종속(vendor lock-in)시킬 필요도 없습니다.

저는 이를 기반으로 실제 제품을 만든 사람이 있는지 찾아보았습니다.

코어 팀의 데모와 몇 개의 개념 증명(proof-of-concept) Gist가 전부였습니다. 그게 끝이었습니다.

그래서 제가 직접 하나를 만들었습니다. 이 포스트는 판매 목적이 아니라 아키텍처(architecture)에 관한 것입니다. 궁금한 분들을 위해 마지막에 링크를 남기겠지만, 여기서 핵심은 패턴입니다. 왜냐하면 WordPress 플러그인을 만든다면, AI를 다루든 아니든 곧 이 문제에 직면하게 될 것이기 때문입니다.

모든 AI 기반 플러그인이 조용히 무시해 온 문제

지난 2년 동안 "AI 콘텐츠" 플러그인을 출시했거나 사용해 보았다면, 거의 확실히 다음과 같은 방식으로 작동했을 것입니다:

• 플러그인에 "OpenAI API Key"를 입력하는 설정 필드가 포함되어 있음
• 키를 붙여넣으면 wp_options에 저장됨 (때로는 암호화되지만, 종종 그렇지 않음)
• 해당 플러그인 개발자가 통합하기로 선택한 특정 제공업체에 종속됨
• 만약 세 개의 AI 기반 플러그인을 사용한다면, 세 명의 서로 다른 개발자가 작성한 키 처리 코드를 신뢰하며 세 개의 서로 다른 설정 화면에 동일한 키(또는 세 개의 서로 다른 키)를 붙여넣어야 함

이것은 WordPress의 문제가 아닙니다. 모든 플러그인 제작자가 동일한 통합 문제를 각자 고립된 상태에서 나쁜 방식으로 영원히 해결하고 있는 문제입니다.

wp_ai_client_prompt()는 이를 플랫폼 수준에서 해결합니다. 사용자는 Settings → Connectors에서 코어 수준에서 제공업체를 단 한 번 연결합니다. AI 기능이 필요한 모든 플러그인은 클라이언트를 호출하기만 하면 됩니다. 클라이언트는 뒤에 어떤 제공업체가 있는지 알 필요도, 신경 쓸 필요도 없습니다:

$result = wp_ai_client_prompt()
    ->with_text( 'Write a 150-word product description for a ceramic espresso cup.' )
    ->using_max_tokens( 300 )
...

이는 유연한 빌더(fluent builder)입니다: with_text(), using_system_instruction(), using_max_tokens(), using_model_preference() — 필요한 것들을 체이닝(chain)하고, generate_text()를 호출하면 문자열(string) 또는 WP_Error를 반환받습니다. 구축해야 할 제공자(provider)별 요청 형태(request shape)도 없고, 잡아내야 할 제공자별 에러 형식(error format)도 없습니다.

제 플러그인의 데이터베이스에는 키(key)가 없습니다. 사용자를 위한 제공자 종속성(provider lock-in)도 없습니다. 만약 사용자가 다음 달에 커넥터를 Claude에서 GPT-4o로 교체한다면, AI Client를 사용하는 모든 플러그인은 그냥... 다음 달에 GPT-4o를 사용하게 됩니다. 제 쪽에서는 코드 변경이 전혀 필요 없습니다.

이것은 20년 전 이메일 전송을 위한 wp_mail()이 가져온 변화와 동일합니다 — 지루하고 구조적이며, 그 위에 구축된 그 어떤 개별 기능보다 훨씬 더 중요한 바로 그런 종류의 변화입니다.

제가 그 위에 구축한 것: Wordvane

Wordvane는 wp-admin 내부에 상주하는 SEO 콘텐츠 생성기입니다. 비즈니스 프로필(무엇을 하는지, 누구에게 판매하는지, 브랜드 보이스, 링크를 원하는 최대 3개의 제품 등)을 한 번만 작성하면, 키워드 조사, 보조 키워드, 메타 제목/설명, FAQ 스키마(schema) 등 발행 준비가 완료된 전체 패키지를 포함한 구조화된 전체 기사를 생성합니다. 이 모든 것은 네이티브 Gutenberg 블록으로 직접 변환됩니다 (붙여넣고 형식을 다시 맞춰야 하는 HTML 덩어리가 아닙니다).

이 포스트가 존재하는 이유는, 이 모든 과정에서 제가 단 하나의 제공자 SDK를 건드리거나, 단 하나의 API 키를 처리하거나, 혹은 저만의 "AI 모델 선택" 설정 화면을 구축할 필요가 없었기 때문입니다. AI Client가 그 일을 해주었습니다. 저는 배관 작업(plumbing)이 아닌, 실제 제품인 기사 구조, SEO 점수, 내부 링크 구축에 시간을 쏟을 수 있었습니다.

단순히 설명하는 것이 아니라, 실제로 보여줄 가치가 있다고 생각하는 부분들은 다음과 같습니다.

1. 제공자가 연결되어 있는지 여부 감지

Wordvane가 누군가에게 무언가를 생성하도록 허용하기 전에, Wordvane 설정이 아닌 AI Client 자체의 제공자 레지스트리(provider registry) — 즉, 코어(core) 레지스트리를 확인합니다:

function wordvane_has_configured_ai_provider(): bool {
    if ( ! class_exists( 'WordPress\AiClient\AiClient' ) ) {
        return false;
...

연결된 것이 없더라도 Wordvane는 생성 도중에 오류를 발생시키지 않습니다. 대신 사용자가 "생성(Generate)" 버튼을 누르기 전에 **설정(Settings) → 커넥터(Connectors)**를 확인하도록 안내하는 관리자 공지(admin notice)를 보여줍니다. 사소한 차이 같지만, "플러그인이 고장 났다"와 "아직 설정을 완료하지 않았다" 사이의 결정적인 차이를 만들어냅니다. 또한 레지스트리(registry)가 공개 API이므로 제가 직접 구축할 필요 없이 단 네 줄의 코드만으로 구현할 수 있었습니다.

2. 실제 생성 호출, 엔드 투 엔드 (end to end)

이것은 단순화된 대역이 아닌 실제 형태입니다. 시스템 지침 (system instruction), 사용자 메시지 (user message), 토큰 예산 (token budget), 선택적 모델 선호도 (optional model preference)가 모두 하나의 클라이언트 호출에 체이닝(chained)되어 있습니다.

$prompt = wp_ai_client_prompt()
    ->using_system_instruction( $system_prompt )
    ->with_text( $user_message )
...

using_model_preference()가 흥미로운 부분입니다. 이는 일반 문자열(예: 특정 Claude 또는 GPT 모델 이름)이며, 클라이언트(Client)는 이를 현재 실제로 연결된 상태에 맞춰 해결(resolves)합니다. 만약 선호하는 모델을 사용할 수 없는 경우, 시스템이 완전히 실패하는 대신 유연하게 폴백(fallback)됩니다. 저는 이 코드베이스 어디에서도 특정 제공자(provider)에 종속적인 분기 처리를 작성하지 않았습니다.

3. 제공자별 JSON 모드에 의존하지 않고 구조화된 데이터(structured data) 가져오기

AI 클라이언트 뒤에 있는 모든 제공자가 동일한 구조화된 출력 (structured-output) 또는 도구 호출 (tool-calling) 기능을 지원하는 것은 아닙니다. 따라서 Wordvane는 이에 의존하는 대신, _이미 생성된 기사_를 대상으로 두 번째의 더 작은 생성 호출을 수행하여 일반 텍스트로 JSON을 요청합니다.

$prompt_text = "Output ONLY a valid JSON object — no explanation, no code "
    . "fences, no markdown.\n\nRequired fields:\n"
    . "- meta_title, meta_description, slug, tags, faq_schema\n\n"
...
```

', 3 ) === 0 ) {
    $json_str = preg_replace( '/^\n
```[a-z]*\n?/', '', $json_str );
    $json_str = rtrim( $json_str, " \n`" );
}

...

화려하지는 않지만, 오늘날 모든 제공자에 대해 동일하게 작동하며, Anthropic, OpenAI, Google의 구현 방식 간에 구조화된 출력 지원이 동일한 수준(parity)에 도달할 때까지 기다리느라 작업이 막히는 일이 없음을 의미합니다.

4. AI 출력을 HTML 덩어리가 아닌 실제 Gutenberg 블록으로 변환하기

생성된 기사는 평면적인 HTML 형태로 반환됩니다. 이를 포스트에 붙여넣으면 블록 에디터(block editor) 내부에 클래식 에디터(classic-editor) 스타일의 콘텐츠 덩어리가 남게 됩니다. 기술적으로는 문제가 없지만, 나중에 편집하기에는 실질적으로 엉망인 상태가 됩니다. Wordvane은 DOM을 탐색하여 실제 블록 주석(block comments)을 생성합니다:

private function node_to_block( DOMDocument $dom, DOMNode $node ) {
    $tag   = strtolower( $node->nodeName );
    $inner = $this->inner_html( $dom, $node );
...

모든 문단(paragraph), 제목(heading), 리스트 항목(list item)이 편집 가능한 네이티브 블록으로 배치됩니다. 사용자가 직접 작성한 다른 포스트와 동일한 방식으로 문단을 재배치하거나 삭제할 수 있습니다.

5. 의도적으로 "눈에 띄는" 테스트 데이터를 사용한 프롬프트 동작 회귀 테스트 (Regression-testing)

이것은 제가 다른 WP+AI 플러그인 개발자들에게 꼭 훔쳐 가라고 권하고 싶은 부분입니다. 초기 단계에서 사용자가 무엇을 설정했든 관계없이, 중립적이어야 하는 기사에 브랜드 이름과 제품 세부 정보가 유출되는 버그를 발견했습니다. 해결책은 프롬프트 수정이 아니었습니다. 자유 형식 텍스트 필드(예: "Acme Co premium widgets"를 포함하는 what_they_sell)에 포함된 비즈니스 이름은 "business_name 필드를 생략하라"는 단순한 필터를 그대로 통과해 버린다는 사실을 깨달은 것이었습니다.

회귀 테스트(regression tests)는 의도적으로 아주 명확한 가짜 브랜드를 사용하여, 어떤 유출이 발생하더라도 차이점(diff) 확인이나 실패한 어설션(assertion)에서 놓칠 수 없도록 합니다:

$this->dna = [
    'business_name'  => 'GlacierBrew Co',
    'what_they_sell' => 'GlacierBrew Co cold-process ales, brewed in small batches',
...

사용자가 제공한 프로필 데이터로부터 프롬프트를 구성하는 무언가를 구축하고 있다면, 이 패턴을 그대로 복사할 가치가 있습니다. 아무도 실수로 입력하지 않을 가짜 브랜드 이름을 정하고, 이를 포함할 가능성이 있는 모든 필드에 심어둔 뒤, 해당 정보를 억제해야 하는 모드에서 그 정보가 사라졌는지 확인(assert)하십시오. 이를 통해 "유출을 고친 것 같다"라는 추측을 CI(지속적 통합)가 실제로 강제하는 사항으로 바꿀 수 있습니다.

스크린샷

스크린샷

직접 사용해 보기 / 이를 기반으로 구축하기

만약 AI가 필요하지만 아직 wp_ai_client_prompt()를 살펴본 적이 없는 WordPress 플러그인 개발자라면 — 그것이 이 게시물에서 얻어갈 만한 실제 핵심입니다. 이것은 작은 API 표면이며, 우리 대부분이 수년 동안 잘못 해결해 왔던 문제(키 저장소, 제공업체 종속성, 설정 화면의 비대화) 전체 범주를 제거합니다.

Wordvane 자체는 설치가 무료이며, 무료 등급에서 무제한 생성이 가능합니다 — 제가 이것으로 무엇을 만들었는지 보고 싶다면 wordvane.com을 방문하세요.

댓글에서 더 깊이 논의할 준비가 되어 있습니다 — AI 클라이언트 내부 구조, 블록 변환, 프롬프트 유출 회귀 테스트 등 유용한 것이라면 무엇이든 좋습니다. 다른 WP 개발자들이 이것을 기반으로 구축하면서 어떤 문제에 직면하는지 진심으로 궁금합니다.