WordPress AI 기능 끄는 법 (코어인가 플러그인인가, 솔직하게)

사람들이 없애고 싶어 하는 WordPress의 AI 기능은 거의 전부 플러그인, 호스팅, 또는 WordPress.com에서 옵니다. 직접 설치형 코어에서 오는 게 아닙니다. functions.php에 remove_action 스니펫을 붙여 넣기 전에 플러그인 목록부터 열어서 그 AI 패널을 실제로 그리고 있는 놈을 찾으세요. 코어에 있지도 않은 기능을 지우려는 시도는, 이미 이상하게 동작하는 사이트에서 시간만 크게 낭비하는 일입니다.

이 구분이 중요한 이유는 해결 방법이 완전히 다르기 때문입니다. 플러그인 기능에는 설정 토글이 있습니다. 호스팅이 심은 기능은 WordPress 관리자 화면이 아니라 호스팅 대시보드에 있습니다. 그리고 사람들이 “AI 끄기”라고 말할 때 보통 진짜로 뜻하는 것, 즉 AI 회사가 내 글로 학습하지 못하게 막는 문제는 애초에 WordPress 설정이 아닙니다. robots와 서버 설정의 영역입니다.

무엇이 코어이고 무엇이 아닌가

직접 설치형 WordPress 코어에는 설치 직후부터 동작하는 AI 글쓰기 도우미, AI 챗봇, AI 이미지 생성기가 들어 있지 않습니다. 블록 편집기에서 AI 반짝이 아이콘이 보인다면, 무언가가 그걸 설치한 겁니다.

AI 기능이 실제로 오는 곳은 다음과 같습니다.

출처	대표적인 기능	끄는 위치
Jetpack	AI Assistant 블록과 편집기 패널	Jetpack 설정의 모듈 토글
단독 AI 플러그인	콘텐츠 생성기, 챗봇, 대체 텍스트 작성기	해당 플러그인의 설정 화면
SEO 플러그인	AI 제목·설명 제안	플러그인 설정, 대개 기능별
페이지 빌더	빌더 UI 안의 AI 문구·이미지 생성	빌더 설정 또는 계정 패널
매니지드 호스팅	mu-plugin이나 대시보드로 주입된 AI 도우미	호스팅 관리 패널
WordPress.com	호스팅형 AI 글쓰기 도구	내 사이트가 아니라 WordPress.com 계정 설정

WordPress 프로젝트 자체도 AI 관련 개발을 계속하고 있습니다. 언젠가 코어에 들어갈 수도 있는 실험적 기능 플러그인들이죠. 최신 릴리스를 쓰고 있는데 플러그인 탓으로 돌릴 수 없는 AI스러운 무언가가 보인다면, 걸러 내야 할 코어 기본값이라고 넘겨짚지 말고 먼저 설치된 플러그인 목록을, 그다음으로 해당 릴리스의 변경 이력을 확인하세요. 이렇게 여지를 두는 건 의도적입니다. 이 분야의 버전별 서술은 금방 낡고, 틀린 정보 하나가 아무 이유 없이 파일을 뜯어고치게 만듭니다.

실제로 무엇이 추가하고 있는지 찾기

AI 패널이 사라질 때까지 플러그인을 몇 개씩 묶어서 비활성화해 보세요. 투박하지만 추측 대신 확실한 답을 줍니다.

WP-CLI가 있다면 활성화된 것부터 전부 나열하세요.

wp plugin list --status=active --field=name

그다음 일반 플러그인 화면에는 나타나지 않는, 호스팅이 심어 놓은 코드를 확인합니다.

ls -la wp-content/mu-plugins/

must-use 플러그인은 자동으로 로드되며 관리자 화면에서 비활성화할 수 없습니다. 호스팅이 여기에 AI 도우미를 넣어 놨다면 깔끔하게 없애는 방법은 그들의 관리 패널을 거치는 것뿐입니다. 파일을 지워도 다음 플랫폼 업데이트 때 다시 생기는 경우가 많습니다.

제대로 끄는 법

플러그인이 제공하는 설정을 쓰세요. 재미없는 답이지만 이게 맞는 답입니다. 특히 Jetpack은 모듈을 개별로 켜고 끌 수 있게 설계되어 있어서, 통계나 백업처럼 계속 쓰는 기능은 남겨 두고 AI Assistant만 끌 수 있습니다. 대부분의 단독 AI 플러그인도 기능별 켜기/끄기 체크박스를 제공합니다.

그 플러그인을 다른 용도로 전혀 쓰지 않는다면 플러그인 전체를 비활성화하세요. 설치된 채로 “비활성”인 AI 플러그인도 모든 요청마다 코드를 로드합니다. 비활성화가 어떤 필터보다 빠르고 안전하며 눈에 띄게 가볍습니다.

remove_action으로 훅을 해제하는 건 최후의 수단입니다. 실제로 동작하긴 하지만, 플러그인이 등록한 훅 이름·콜백·우선순위를 정확히 알 때만, 그리고 플러그인이 그중 하나를 바꾸기 전까지만입니다.

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

솔직한 대가는 이겁니다. 이 방식은 소리 없이 깨집니다. 플러그인 업데이트가 클래스 이름을 바꾸면 제거 코드가 더 이상 일치하지 않고, AI 패널이 다시 나타나며, 그걸 알려 주는 오류는 아무것도 나지 않습니다. 이 방법을 쓴다면 무엇을 제거했는지 적어 두고 그 플러그인이 업데이트될 때마다 다시 확인하세요.

JavaScript에서 편집기 패널의 등록을 해제하는 방법에도 같은 주의가 적용됩니다. 실제로 가능한 기능이지만, 문자열 식별자로 다른 플러그인의 등록 내용에 손을 대는 것이고 그 식별자는 공개된 약속이 아닙니다.

포럼 글에서 찾은 wp-config.php 상수로 AI 기능을 막으려 하지 마세요. 서드파티 플러그인의 AI를 꺼 주는 코어 상수는 없습니다. 그렇다고 주장하는 스니펫이 있는데 그 상수를 해당 플러그인 문서에서 확인할 수 없다면, 그건 아무 일도 하지 않습니다.

또 다른 질문: 내 콘텐츠로 AI가 학습하는 것 막기

이건 별개의 문제이고, 사람들이 정말로 불안해하는 지점이기도 합니다. 편집기 패널을 끈다고 누가 내 글을 크롤링하는지가 달라지지는 않습니다. 그 통제는 robots.txt에서, 그리고 강제력까지 원한다면 서버에서 이루어집니다.

웹 루트에 실제 파일이 없으면 WordPress는 가상 robots.txt를 제공합니다. 물리 파일이 있으면 WordPress는 완전히 물러나고 크롤러는 그 파일을 받게 됩니다. 가상 파일을 수정하려면 필터를 쓰세요.

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

규칙을 손으로 조립하는 지점에서 실수가 나옵니다. 토큰 하나만 틀려도 아무것도 막히지 않고, 엉뚱한 에이전트에 붙은 Disallow: / 한 줄이 일반 검색에서 사이트를 통째로 빼 버릴 수 있습니다. robots.txt 생성기는 AI 크롤러 차단 규칙을 일반 검색 지시문과 함께 조립해 주므로, 적용 전에 파일 전체를 눈으로 확인할 수 있습니다.

주요 사업자가 공개하고 준수한다고 밝힌 토큰은 다음과 같습니다.

토큰	사업자	적용 범위
GPTBot	OpenAI	모델 학습을 위한 크롤링
ChatGPT-User	OpenAI	사용자의 요청으로 발생하는 가져오기
ClaudeBot	Anthropic	크롤링
Google-Extended	Google	크롤링 자체가 아니라 Gemini 학습에 콘텐츠를 사용하는 것
Applebot-Extended	Apple	Apple의 생성형 모델 학습에 사용하는 것
PerplexityBot	Perplexity	크롤링
CCBot	Common Crawl	다수의 모델이 학습에 쓰는 대규모 아카이브

솔직한 주의사항 두 가지. 첫째, robots.txt는 자발적입니다. 예의 바른 사업자는 따르지만, 무시하려는 쪽은 그냥 무시합니다. 둘째, 차단은 공짜가 아닙니다. 이 토큰들 중 일부는 출처로 인용하고 링크해 주는 AI 답변에 노출될지 여부를 좌우합니다. 전부 막으면 학습 노출과 함께 그 유입 경로도 잃습니다. 자신이 실제로 신경 쓰는 쪽이 무엇인지 정하세요.

정중한 요청이 아니라 강제력을 원한다면 서버에서 막으세요. Apache의 .htaccess에서는 이렇게 합니다.

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

user-agent 문자열은 손쉽게 위조되므로, 이 방법은 정직하지만 원치 않는 트래픽을 막을 뿐 작정한 스크래퍼는 막지 못합니다. CDN이나 방화벽에서 검증된 IP 대역으로 차단하는 편이 더 강력하고, 요즘은 대부분의 CDN이 손으로 관리하는 목록보다 유지하기 쉬운 AI 봇 차단 규칙을 클릭 한 번으로 제공합니다.

효과가 없는 것들

llms.txt는 제안이지 표준이 아닙니다. 언어 모델에게 사이트를 설명하기 위해 제안된 마크다운 파일입니다. 주요 사업자 중 이것을 접근 제어로 취급하겠다고 밝힌 곳은 없습니다. 추가하는 데 드는 비용이 없고 모델이 사이트를 읽는 방식에 도움이 될 수도 있지만, 아무것도 차단하지 않습니다.

noai와 noimageai 메타 태그는 사실상 아무도 지키지 않습니다. 업계 전체의 합의가 아니라 한 플랫폼의 정책에서 나온 것입니다. 넣는다고 해로울 건 없지만, 동작하리라 기대하는 건 무리입니다.

“AI 차단”을 내세우는 플러그인은 대개 robots 규칙을 쓰는 게 전부입니다. 그 자체는 괜찮고, 여러분이 열 줄 정도로 직접 할 수 있는 일과 정확히 같습니다. 법적·기술적 장벽이 아니며, 어떤 플러그인도 그걸 장벽으로 만들지는 못합니다.

AI 크롤러 차단은 이미 학습된 모델 안의 콘텐츠를 지워 주지 않습니다. 오늘 무엇을 추가하든 작년에 출시된 모델에서 내 글을 소급해 빼내지는 못합니다. robots 규칙은 앞으로의 일에만 적용됩니다.

그래도 AI 패널이 보인다면

모든 플러그인을 껐는데도 패널이 남아 있다면 wp-content/mu-plugins/를 다시 확인하고, 그다음 호스팅 대시보드를 보고, 그다음 직접 설치형이 아니라 WordPress.com을 쓰고 있는 건 아닌지 확인하세요. WordPress.com이라면 토글은 사이트 관리자가 아니라 계정 설정에 있습니다. 그리고 플러그인 업데이트 후에 기능이 되살아났다면, 그건 코어 기본값이 고개를 든 게 아니라 훅 해제 스니펫이 더 이상 일치하지 않게 됐다는 신호입니다.