블로그를 여러 개 운영하면 가장 아까운 시간은 글을 쓰는 시간이 아니라 그 앞 단계다. 무엇을 쓸지 고르고, 공식 문서를 찾아 읽고, 뼈대를 세우고, 워드프레스에 옮겨 붙이는 일. 이 글은 그 반복 작업을 덜어낸 워드프레스 자동화 실전 기록이다. Claude Code의 예약 실행 기능인 루틴(Routine)이 매주 월요일 아침 소재를 조사하고 초안을 써서 워드프레스에 임시글로 올려두면, 나는 경험 몇 문단을 채우고 발행 버튼만 누르면 된다.
Claude를 처음 쓰신다면 클로드 Claude 사용법 완벽 가이드 2026을 먼저 보시면 요금제와 기능 차이를 이해하는 데 도움이 된다. 설정 자체는 30분이면 끝나는 구조인데, 실제로는 카페24 호스팅에서 세 번 연속으로 막혔다. 그 과정에서 알게 된 원인과 해결법이 오히려 이 글의 핵심이다. 같은 호스팅을 쓰는 분이라면 같은 자리에서 막힐 가능성이 높으니, 설정 순서와 함께 문제 해결 부분까지 끝까지 읽어보시길 권한다.
이 글에서 다루는 것
- 완전 자동 발행이 아니라 초안 자동화를 택한 이유
- 루틴 · GitHub · 워드프레스 REST API로 이어지는 전체 구조
- 애플리케이션 비밀번호 발급부터 루틴 등록까지 단계별 설정
- 카페24 워드프레스에서 REST API가 막힌 3겹과 각각의 해결법
- 첫 실행 결과와, 운영하면서 챙겨야 할 체크리스트
왜 “자동 발행”이 아니라 “초안 자동화”인가
AI로 글을 쓰고 곧바로 발행까지 자동으로 돌리는 방법은 기술적으로 어렵지 않다. 하지만 두 가지 이유로 발행 직전 단계에서 멈추도록 설계했다.
첫째, 검색엔진이 사람 손을 거치지 않은 대량 생산 콘텐츠를 점점 강하게 걸러낸다. 내 블로그의 서치콘솔을 보면 “크롤링됨 – 현재 색인이 생성되지 않음” 상태의 글이 적지 않은데, 대부분이 다른 사이트에도 비슷하게 있을 법한 개론형 글이었다. 반대로 클릭을 받은 글은 직접 해보고 쓴 사용 순서와 결과가 담긴 글이었다. 자동화가 대신해야 하는 건 조사와 뼈대이지, 경험이 아니다.
둘째, 발행은 되돌리기 어려운 행동이다. 루틴이 실수로 잘못된 내용을 발행하면 수습하는 비용이 자동화로 아낀 시간보다 크다. 그래서 스크립트 자체가 status=draft로 고정돼 있어, 루틴이 아무리 잘못 판단해도 발행은 구조적으로 불가능하게 만들었다.
자동화의 목표를 “글 수 늘리기”가 아니라 “내가 경험만 채우면 되는 상태로 만들어 두기”로 잡았다.
워드프레스 자동화 전체 구조 한눈에 보기
이번 워드프레스 자동화 구조의 구성 요소는 네 가지다. 각각이 맡는 역할만 이해하면 나머지 설정은 자연스럽게 따라온다.
| 구성 요소 | 역할 |
|---|---|
| Claude Code 루틴 | 정해진 시각에 클라우드에서 세션을 자동으로 시작하고, 저장해 둔 지침대로 작업한다. 노트북이 꺼져 있어도 돈다. |
| 클라우드 환경 | 루틴이 실행되는 가상 머신의 설정. 접속 허용 도메인, 환경 변수(사이트 주소·아이디·비밀번호), 설치할 패키지를 정한다. |
| GitHub 저장소 | 작업 지침(weekly-draft.md), 소재 목록(topics.md), 워드프레스 업로드 스크립트, 그리고 매주 쌓이는 원고가 들어 있다. |
| 워드프레스 REST API | 스크립트가 애플리케이션 비밀번호로 인증해 임시글을 등록하는 통로. 워드프레스 5.6부터 기본 내장돼 있다. |
준비물
워드프레스 자동화 루틴을 만들기 전에 아래 네 가지를 먼저 갖춰 두면 설정이 한 번에 끝난다.
- Claude 유료 요금제(Pro 이상): 클라우드 세션과 루틴은 유료 요금제에서 쓸 수 있고, 일반 대화와 같은 사용량 한도를 공유한다.
- GitHub 계정: 저장소는 비공개로 만든다. Claude GitHub 앱이 해당 저장소에 접근할 수 있어야 한다.
- 워드프레스 5.6 이상, HTTPS 적용: 애플리케이션 비밀번호는 HTTPS 연결에서만 동작한다.
- 워드프레스 관리자 계정: 임시글을 만들 권한이 있어야 한다.
1단계: 워드프레스 애플리케이션 비밀번호 발급
애플리케이션 비밀번호는 로그인 비밀번호와 별개로 발급하는 API 전용 비밀번호다. 이 비밀번호로는 로그인 화면에 들어갈 수 없고, 유출되더라도 그것 하나만 폐기하면 되기 때문에 자동화 스크립트에 로그인 비밀번호를 넣는 것보다 훨씬 안전하다.
- 워드프레스 관리자 → 사용자 → 프로필로 들어간다.
- 페이지 아래쪽 “응용프로그램 비밀번호” 항목에 알아보기 쉬운 이름(예:
claude-routine)을 입력한다. - “애플리케이션 비밀번호 추가”를 누르면 공백으로 구분된 24자리 비밀번호가 한 번만 표시된다.
- 반드시 화면의 복사 버튼으로 복사한다.
4번은 직접 겪고 나서 추가한 항목이다. 처음 발급한 비밀번호를 손으로 옮겨 적었다가 한 글자가 달라져 인증이 계속 실패했다. 대문자 I와 소문자 l, 대문자 O와 숫자 0처럼 헷갈리는 글자가 섞여 있고 다시 확인할 방법도 없으니, 복사 버튼을 쓰는 게 가장 확실하다. 실패했을 때는 기존 것을 폐기하고 새로 발급하면 된다.
참고로 이 메뉴가 아예 보이지 않는다면 보안 플러그인이 애플리케이션 비밀번호 기능을 꺼 두었을 가능성이 높다. 해당 플러그인 설정에서 이 기능을 허용하면 나타난다.
2단계: GitHub 저장소 구성
루틴은 매번 새 가상 머신에서 시작하기 때문에, 기억해야 할 모든 것은 저장소에 들어 있어야 한다. 구조는 단순하다.
easynjobs-pipeline/
├── prompts/weekly-draft.md # 루틴이 매주 따르는 작업 지침
├── content/topics.md # 다음에 쓸 소재 목록 (내가 자유롭게 편집)
├── content/drafts/ # 루틴이 쓴 초안 원고가 쌓이는 곳
├── scripts/wp_client.py # 워드프레스 REST API로 임시글을 올리는 스크립트
└── README.md # 설정 순서 기록핵심은 weekly-draft.md다. 여기에 “소재 목록 맨 위 항목을 고른다, 공식 문서를 우선해 조사한다, 필자의 경험은 지어내지 말고 빈칸으로 남긴다, 워드프레스에는 임시글로만 올린다” 같은 규칙을 적어 두었다. 루틴 설정 화면에는 “이 파일을 읽고 그대로 따르라”는 짧은 지시만 넣었기 때문에, 앞으로 작업 방식을 바꾸고 싶으면 이 파일만 고치면 된다.
업로드 스크립트는 마크다운 원고 맨 위의 제목·슬러그·카테고리·태그 정보를 읽어서 워드프레스 REST API의 /wp/v2/posts로 보낸다. 이때 상태 값을 항상 draft로 보내도록 코드에 박아 두었다.
3단계: 클라우드 환경 설정
claude.ai/code에서 입력창 위의 구름 아이콘을 누르면 클라우드 환경 목록이 나온다. 여기서 새 환경을 하나 만들고 세 가지를 설정한다.
| 항목 | 설정값 | 이유 |
|---|---|---|
| 네트워크 액세스 | 사용자 지정 + 블로그 도메인 추가 | 기본값(신뢰됨)은 패키지 저장소 같은 일부 도메인만 허용한다. 내 블로그 주소를 허용 목록에 넣어야 API 호출이 나간다. 기본 패키지 목록 포함 옵션도 켠다. |
| 환경 변수 | 사이트 주소, 워드프레스 아이디, 애플리케이션 비밀번호 | 스크립트가 여기서 값을 읽는다. 개인 환경이라 본인만 볼 수 있다. |
| 셋업 스크립트 | pip install markdown | 마크다운 원고를 HTML로 바꾸는 라이브러리를 미리 설치해 둔다. |
환경 변수를 저장한 뒤에는 새 세션을 열어야 반영된다. 이미 열려 있던 세션은 예전 값을 계속 쓰기 때문에, 값을 바꿨는데도 결과가 그대로라면 세션부터 새로 여는 게 먼저다.
4단계: 루틴 등록
claude.ai/code의 루틴 메뉴에서 새 루틴을 만든다. 설정한 값은 다음과 같다.
- 지침: “저장소의 prompts/weekly-draft.md를 읽고 그대로 따라 초안 1개를 만들어라. 임시글로만 올리고 발행하지 않는다.”
- 저장소: 앞에서 만든 비공개 저장소
- 클라우드 환경: 3단계에서 만든 환경
- 트리거: 스케줄 → 매주 → 월요일 오전 6시
- 커넥터: 전부 제거. 이 루틴은 웹 조사와 워드프레스 API만 쓰므로 메일이나 드라이브 같은 연결은 필요 없다. 루틴은 승인 없이 자율로 돌기 때문에 필요 없는 권한은 빼 두는 편이 안전하다.
카페24 워드프레스 자동화에서 막힌 3겹과 해결법
여기까지는 문서대로 하면 되는 부분이다. 이번 워드프레스 자동화 작업에서 실제 시간은 거의 다 이 구간에서 썼다. 첫 인증 테스트부터 실패했고, 원인을 하나 해결하면 다음 원인이 나타났다. 결과적으로 요청이 워드프레스 인증까지 닿으려면 세 겹을 모두 통과해야 했다.
첫 번째 벽: 스팸 SHIELD가 끼워 넣는 자바스크립트 검사
처음 증상은 이상했다. 브라우저로 /wp-json/ 주소를 열면 정상인데, 스크립트로 같은 주소를 부르면 JSON이 아니라 cupid.js라는 스크립트를 실행하라는 짧은 HTML 페이지가 돌아왔다. 카페24 웹호스팅의 스팸 SHIELD 기능이 봇을 걸러내려고 자바스크립트 실행 여부를 확인하는 페이지를 끼워 넣는 것이었다. 브라우저는 스크립트를 실행해 쿠키를 받고 통과하지만, 자바스크립트를 실행하지 않는 프로그램은 매번 이 페이지에서 멈춘다.
카페24 관리 화면의 스팸 SHIELD 차단 내역을 열어 보니 하루에만 19개국에서 차단이 일어나고 있었고, 그중 미국에서 접근한 IP 53개 가운데 47개가 막혀 있었다.
구글 검색 로봇과 애드센스 크롤러는 대부분 미국 IP에서 온다. 즉 이 기능이 스팸만이 아니라 검색엔진과 광고 크롤러까지 막고 있었을 가능성이 크다. 검색 유입으로 운영하는 블로그라면 오히려 손해인 설정이라 과감하게 껐다. 경로는 카페24 호스팅관리 → 보안관리 → 스팸 SHIELD이고, 해킹 공격을 막는 웹방화벽(ModSecurity)은 별개 기능이라 그대로 켜 두었다. 워드프레스 쪽에는 이미 방화벽 플러그인이 있어 로그인 공격 방어는 그쪽이 맡는다.
두 번째 벽: 사라지는 Authorization 헤더
스팸 SHIELD를 끄자 이번에는 JSON이 제대로 왔다. 그런데 내용이 401 rest_not_logged_in, 즉 “로그인 상태가 아니다”였다. 아이디나 비밀번호가 틀렸다면 워드프레스는 incorrect_password나 invalid_username을 돌려준다. 로그인 정보 자체가 워드프레스에 도착하지 않았다는 뜻이다.
애플리케이션 비밀번호는 Authorization라는 HTTP 헤더에 실려 간다. 공유 호스팅에서는 앞단 서버가 이 헤더를 PHP까지 넘겨주지 않는 경우가 흔하다. 보통은 .htaccess에 헤더를 넘기는 규칙을 넣으면 해결되는데, 이 사이트의 .htaccess에는 이미 그 규칙이 들어 있었고 추가 규칙을 넣어도 결과가 같았다. 응답 헤더를 보니 앞단이 nginx였고, nginx는 .htaccess를 읽지 않으니 여기서 고칠 수 있는 문제가 아니었다.
그래서 헤더 이름을 바꿔서 보내는 방법을 택했다. 업로드 스크립트가 같은 인증 정보를 X-WP-Authorization이라는 다른 이름의 헤더에도 함께 담아 보내고, 워드프레스에 설치한 40줄 남짓한 작은 플러그인이 이 헤더를 워드프레스가 원래 인증 정보를 읽는 자리로 옮겨 준다. 이름이 다른 헤더는 서버가 건드리지 않고 통과시키기 때문이다. 비밀번호 검증 자체는 워드프레스 본래 로직이 그대로 하므로 보안 수준은 표준 방식과 같다.
세 번째 벽: 틀린 비밀번호에도 “로그인 안 됨”
플러그인을 켰는데도 결과는 여전히 rest_not_logged_in이었다. 여기서 쓸모 있었던 방법이 일부러 틀린 비밀번호로 요청해 보기다. 인증 절차가 정상적으로 돈다면 틀린 비밀번호에는 반드시 incorrect_password가 와야 한다. 그런데 표준 헤더든 대체 헤더든 똑같이 “로그인 안 됨”이 왔다. 헤더 문제가 아니라, 비밀번호 검사 자체가 실행되지 않고 있다는 결정적 단서였다.
원인은 워드프레스의 동작 순서에 있었다. 워드프레스는 요청이 REST API 요청이라는 걸 판별한 뒤에야 애플리케이션 비밀번호를 검사한다. 그런데 설치된 다른 플러그인이 그보다 먼저 “지금 사용자가 누구인가”를 물어보면, 워드프레스는 그 시점에 사용자를 손님으로 확정해 버리고 이후 인증을 건너뛴다. 플러그인을 여러 개 쓰는 블로그에서 흔히 생기는 일이다.
해결은 워드프레스가 공식으로 제공하는 application_password_is_api_request 필터로 /wp-json/ 주소의 요청을 처음부터 API 요청으로 인정하게 하는 것이었다. 이 내용을 앞의 브리지 플러그인에 함께 넣었다.
// /wp-json/ 으로 들어온 요청은 처음부터 API 요청으로 취급
add_filter( 'application_password_is_api_request', function ( $is_api ) {
$uri = $_SERVER['REQUEST_URI'] ?? '';
return $is_api || false !== strpos( $uri, '/wp-json/' );
} );수정 후 틀린 비밀번호로 다시 시험하자 드디어 incorrect_password가 돌아왔다. 인증 경로가 열렸다는 뜻이다. 남은 문제는 앞에서 말한 비밀번호 복사 실수 하나였고, 새로 발급해 복사 버튼으로 붙여넣자 관리자 계정으로 인증이 통과했다.
정리: 증상별로 보는 진단표
| 응답 | 의미 | 확인할 것 |
|---|---|---|
| JSON이 아닌 HTML (cupid.js) | 호스팅의 봇 차단에 걸림 | 스팸 SHIELD 등 호스팅 보안 기능 |
| 401 rest_not_logged_in (틀린 비밀번호로도) | 인증 정보가 워드프레스에 닿지 않거나, 검사 자체가 건너뛰어짐 | Authorization 헤더 전달, 플러그인의 이른 사용자 확정 |
| 401 incorrect_password | 인증 경로는 정상, 비밀번호 값이 틀림 | 애플리케이션 비밀번호 재발급 후 복사 버튼으로 입력 |
| 200 + 사용자 정보 | 성공 | – |
첫 실행 결과
설정을 마치고 워드프레스 자동화 루틴 화면에서 지금 실행을 눌렀다. 루틴은 워드프레스 인증을 먼저 스스로 확인한 뒤, 워드프레스 공식 애플리케이션 비밀번호 문서와 Claude Code 루틴 문서를 조사해 소재 목록 1번 주제로 초안을 썼다. 임시글로 올린 다음에는 상태가 정말 draft인지 한 번 더 확인했고, 원고 파일을 GitHub에 커밋하고 끝냈다. 걸린 시간은 약 3분 30초였다.
루틴이 마지막에 남기는 요약에는 필자가 채워야 할 빈칸 목록이 들어 있다. 지금 읽고 계신 이 글이 바로 그 첫 초안에서 출발했다.
처음 열어본 초안은 약 670단어 분량이었고, 워드프레스 편집기에 “클래식” 블록 하나로 통째로 들어와 있었다. 공식 문서를 근거로 한 설명과 설정 순서는 꽤 정확했지만, 실제로 시간을 가장 많이 쓴 카페24 문제는 당연히 담겨 있지 않았고 빈칸 세 곳이 그 자리를 표시하고 있었다. 자료 조사와 목차가 이미 잡혀 있으니 무엇을 더해야 하는지가 분명하게 보였다. 이 글은 그 초안을 뼈대로 삼아, Claude와 함께 실제로 겪은 설정 과정과 문제 해결 기록, 작업 중 캡처한 화면과 인포그래픽을 더해 다시 정리한 것이다.
워드프레스 자동화 운영 체크리스트
- 소재 목록을 미리 채워 두기: 루틴은 목록 맨 위 항목부터 쓴다. 쓰고 싶은 주제를 미리 적어 두면 방향이 흐트러지지 않는다.
- 원고가 main 브랜치에 반영되는지 확인: 루틴은 기본적으로
claude/로 시작하는 새 브랜치에 작업을 올린다. 다음 주 루틴은 main을 읽고 시작하므로, 이번 주 원고가 main에 합쳐지지 않으면 같은 주제를 다시 고를 수 있다. 매주 풀 리퀘스트를 병합하거나, 지침을 고쳐 main에 직접 반영하도록 해 두자. - 사용량 한도: 루틴은 일반 대화와 같은 한도를 쓴다. 초안 한 편은 3~4분 정도라 부담이 크지 않지만, 한도가 거의 찬 날에는 실행이 밀릴 수 있다.
- 비밀번호 관리: 애플리케이션 비밀번호가 노출됐다고 생각되면 프로필 화면에서 바로 폐기하고 새로 발급하면 된다. 로그인 비밀번호는 영향을 받지 않는다.
- 발행 전 검수: 사실 관계와 링크를 한 번 확인하고, 빈칸에 내 경험을 채운 뒤 발행한다. AI를 활용했다면 그 사실을 글에 밝혀 두는 편이 독자에게도 검색엔진에게도 떳떳하다.
자주 묻는 질문
카페24가 아닌 호스팅에서도 브리지 플러그인이 필요한가요?
대부분은 필요 없다. 먼저 표준 방식으로 인증을 시험해 보고, 틀린 비밀번호로 요청했을 때 incorrect_password가 제대로 나온다면 그대로 쓰면 된다. 그 응답이 rest_not_logged_in으로 나올 때만 헤더 전달이나 플러그인 충돌을 의심하면 된다.
스팸 SHIELD를 끄면 보안에 문제가 생기지 않나요?
스팸 SHIELD는 해외 IP와 봇을 거르는 기능이고, 해킹 공격 방어는 웹방화벽이 따로 맡는다. 웹방화벽을 켜 둔 채 워드프레스 보안 플러그인과 강한 관리자 비밀번호, 가능하면 2단계 인증까지 갖추면 실질적인 위험은 크지 않다. 반대로 켜 두면 검색엔진 크롤러가 막혀 색인과 광고 수익에 손해를 볼 수 있다.
티스토리나 블로그스팟에도 같은 방식을 쓸 수 있나요?
블로그스팟은 구글의 공식 API가 있어 비슷한 방식이 가능하다. 티스토리는 오픈 API가 종료돼 루틴이 직접 글을 올릴 수 없으므로, 원고를 저장소에 쌓아 두고 사람이 옮겨 붙이는 반자동 방식이 현실적이다.
루틴이 쓴 글을 그대로 발행해도 되나요?
권하지 않는다. 워드프레스 자동화 루틴은 조사와 구조를 잘 만들지만, 검색에서 살아남는 글의 핵심은 직접 해본 사람만 쓸 수 있는 내용이다. 빈칸을 채우는 10~20분이 이 자동화의 가치를 결정한다.
마치며
여러 AI 도구 중 무엇을 어디에 쓸지 고민 중이라면 2026 AI 챗봇 비교: ChatGPT·Claude·Gemini·Perplexity도 함께 참고해 보시길 바란다.
자동화를 붙이는 데 걸린 시간의 대부분은 설정이 아니라 호스팅이 만든 세 겹의 벽을 넘는 데 들었다. 그래도 한 번 뚫어 두니 이제 매주 월요일 아침이면 조사와 뼈대가 갖춰진 초안이 임시글 목록에 올라와 있다. 워드프레스 자동화 방법을 고민하고 있다면, 발행까지 맡기기보다 “경험만 채우면 되는 초안”까지를 목표로 잡아 보시길 권한다.
참고 자료
- WordPress Developer Resources: Application Passwords
- WordPress REST API Handbook
- Claude Code Docs: Automate work with routines
- Claude Code Docs: Configure cloud environments
이 글은 Claude Code 루틴이 만든 초안을 바탕으로, 필자가 Claude와 함께 실제로 진행한 설정과 문제 해결 과정을 정리해 다시 쓴 것입니다. 인포그래픽은 이 글을 위해 제작했고, 화면 캡처는 실제 작업 화면입니다.