저는 이 블로그를 직접 운영하면서, 매일 반복되는 글 발행·SEO 작업·이미지 처리·서버 배포를 손으로 하는 게 점점 부담스러웠습니다. 그래서 터미널에서 동작하는 AI 코딩 에이전트인 Claude Code로 발행 파이프라인을 직접 만들어 보기로 했습니다.
결론부터 말하면, 자동화 자체는 충분히 가능했습니다. 다만 그 과정에서 AI가 짜준 코드와 명령을 검토 없이 그대로 돌렸을 때 “겉보기엔 성공인데 실제로는 실패”하는 함정을 여러 번 만났습니다. 더 위험한 건 이 함정들이 에러를 내며 멈추는 게 아니라, 조용히 잘못된 상태를 만들고 넘어간다는 점이었습니다.
이 글에서는 Claude Code 워드프레스 자동화를 직접 구축하며 만난 3가지 함정을 증상 → 원인 → 해결 순서로 정리했고, 중간에 헤맨 과정도 함께 적었습니다. 같은 환경에서 자동화를 시도하는 분이라면 같은 곳에서 헤매는 시간을 아낄 수 있을 겁니다.
함정 1: cron에 올렸더니 WP-CLI가 “조용히” 실패했다
가장 먼저 자동화한 건 글 본문을 일괄 갱신하는 작업이었습니다. 워드프레스 명령줄 도구인 WP-CLI로 wp post update를 실행하는 스크립트를 짜고, 이걸 서버 cron에 등록했습니다.
증상
cron이 돌고 난 뒤 로그를 보면 분명 성공처럼 보였습니다. 스크립트는 끝까지 진행됐고, 종료 코드(exit code)도 정상인 0이었습니다. 그런데 정작 사이트의 글은 하나도 바뀌어 있지 않았습니다.
로그를 자세히 들여다보니 본문 갱신이 일어나야 할 자리에 이런 출력이 섞여 있었습니다.
Content-type: text/html; charset=UTF-8
Warning: WP-CLI only works correctly from the command line,
using the 'cli' PHP SAPIwp post update가 실행은 됐는데, 실제 DB 갱신은 무시하고 경고만 찍은 채 정상 종료한 것이었습니다.
삽질
처음엔 권한이나 경로 문제인 줄 알았습니다. 그런데 SSH로 접속해서 같은 스크립트를 손으로 실행하면 멀쩡하게 잘 동작했습니다. cron에서만 실패하는 전형적인 “내 컴퓨터에선 되는데” 패턴이었죠. 차이는 코드가 아니라 실행 환경에 있었습니다.
원인
cPanel 기반 서버에는 서로 다른 PHP 실행 파일이 두 개 깔려 있었습니다.
/usr/bin/php→ CGI용 래퍼(cgi-fcgiSAPI)/usr/local/bin/php→ 명령줄용 래퍼(cliSAPI)
WP-CLI(/usr/local/bin/wp)의 첫 줄은 #!/usr/bin/env php라서, 그때그때 PATH에 먼저 잡히는 php를 따라갑니다. 제가 인터랙티브 셸로 접속하면 /usr/local/bin이 우선이라 cli SAPI로 동작하지만, cron의 기본 PATH는 /usr/bin:/bin이라 /usr/bin/php(CGI SAPI)가 먼저 잡혔습니다.
WP-CLI는 CGI SAPI로 로드되면 실제 작업을 수행하지 않고 경고만 출력합니다. 문제는 이때도 종료 코드가 0이라, 스크립트 입장에서는 “성공”으로 판단하고 후속 단계(캐시 비우기 등)까지 그대로 진행한다는 점이었습니다.
해결
스크립트 맨 위에서 PATH를 명시해 cli SAPI를 강제했습니다.
export PATH=/usr/local/bin:/usr/bin:/bin또는 더 확실하게, 모든 호출을 풀 경로로 박아 SAPI를 고정했습니다.
/usr/local/bin/php /usr/local/bin/wp post update 1234 --post_content="..."교훈은 분명합니다. 종료 코드 0이 곧 성공은 아닙니다. 그리고 cron 자동화를 검증할 때는 인터랙티브 셸에서 테스트하면 안 됩니다. 다음처럼 cron과 동일한 환경을 흉내 내서 돌려야 진짜 함정이 드러납니다.
env -i HOME=/home/USER PATH=/usr/bin:/bin /bin/bash /path/to/script.sh함정 2: 한글이 grep에 안 잡혔다
본문 갱신이 잘 됐는지 자동으로 점검하려고, 발행 후 글에 의도한 한글 키워드가 들어갔는지 grep으로 세는 검증 단계를 붙였습니다. 그런데 여기서 두 번째 함정에 빠졌습니다.
증상
사람 눈으로 보면 본문에 한글이 분명히 있는데, 검증 스크립트는 매칭 건수를 빈 값으로 뱉거나 이런 에러를 냈습니다.
grep: Invalid collation character문제의 패턴은 흔히 쓰는 한글 범위였습니다.
grep -E '[가-힣]' post.html # cron 환경에서 실패원인
cron 기본 환경에는 LANG이나 LC_ALL 같은 locale 변수가 설정돼 있지 않습니다. 즉 C(POSIX) locale로 동작하는데, 이 환경에서는 [가-힣] 같은 범위 표현의 collation(정렬 순서)을 지원하지 않습니다. 그래서 한글 범위가 “유효하지 않은 정렬 문자”로 처리돼 매칭에 실패한 겁니다.
여기엔 한 겹 더 깊은 함정이 있었습니다. locale을 UTF-8로 지정해줘도 grep -E '[가-힣]'은 여전히 불안정했습니다. 결국 안정적으로 동작한 방법은 PCRE(펄 호환 정규식) 모드에 유니코드 코드포인트를 직접 쓰는 것이었습니다.
해결
locale을 명시하고, 한글 범위는 GNU grep의 -P(PCRE) 옵션 + 코드포인트로 바꿨습니다.
export LC_ALL=en_US.utf8
export LANG=en_US.utf8
# [가-힣] 대신 유니코드 코드포인트 범위 + PCRE
grep -cP '[\x{AC00}-\x{D7A3}]' post.html\x{AC00}-\x{D7A3}은 한글 음절(가~힣)의 유니코드 범위입니다. -E(기본 정규식)가 아니라 -P로 돌려야 locale에 휘둘리지 않고 안정적으로 한글을 잡았습니다.
교훈은, 한글이나 이모지 같은 멀티바이트 문자를 다루는 검증은 locale을 명시하고 PCRE를 쓰라는 것입니다. 그리고 자동화의 “검증 단계” 자체도 검증해야 합니다. 본문은 잘 갱신됐는데 검증 메트릭만 조용히 0을 뱉고 있으면, 문제가 생겨도 알아채지 못하니까요.
함정 3: AI가 “그럴듯한” 링크 슬러그를 지어냈다
세 번째는 앞의 두 개와 결이 다릅니다. 서버 설정이 아니라 AI 그 자체의 특성에서 비롯된 함정이었고, 개인적으로 가장 뼈아팠습니다.
증상
글마다 SEO를 위해 관련 글로 가는 내부 링크를 2~3개씩 넣습니다. “이 글에 관련된 기존 글 링크를 본문에 추가해줘”라고 지시하면 AI가 알아서 링크를 만들어 넣어줬습니다.
한참 뒤, 구글 서치 콘솔(GSC)에서 여러 글이 “크롤링됨 – 현재 색인이 생성되지 않음” 상태로 보류돼 있는 걸 발견했습니다. 본문을 뜯어보니, 내부 링크 중 일부가 404였습니다. 더 충격적인 건 여러 글에 똑같은 잘못된 슬러그가 박혀 있었다는 점입니다.
원인
AI에게 “관련 글 링크를 넣어줘”라고 하면, 실제 URL을 모르는 경우 패턴상 그럴듯한 슬러그를 추측해서 만들어냅니다. 이른바 환각(hallucination)입니다. 예를 들어 연도가 슬러그 앞에 오는지 뒤에 오는지 같은 사소한 차이를 AI가 임의로 채워 넣는 식이죠.
문제를 키운 건 복제였습니다. 한 번 잘못 만든 슬러그가 다음 글을 쓸 때 “앞 글 본문”을 참고 맥락으로 들어가면서, 같은 환각이 글마다 일관되게 퍼졌습니다. 그리고 구글은 본문에 박힌 404 링크를 콘텐츠 품질이 낮다는 신호로 받아들여 색인을 보류했습니다. 링크 하나가 사이트 전체 평가에 영향을 준 셈입니다.
해결
규칙은 단순합니다. AI가 만든 슬러그를 본문에 그대로 두지 않습니다. 발행 직전에 본문의 모든 내부 링크가 실제로 200 응답을 주는지 기계적으로 확인하는 단계를 넣었습니다.
# 초안에서 내부 링크를 뽑아 HTTP 상태 코드 확인
grep -oE 'https://rabby\.kr/[a-z0-9-]+/' draft.md | sort -u | while read url; do
code=$(curl -sS -o /dev/null -w "%{http_code}" -L "$url")
echo "$code $url"
done200이 아닌 게 하나라도 나오면 발행을 멈추고 슬러그를 고칩니다. 별것 아닌 curl 루프지만, 이 한 단계가 색인 사고를 막아줍니다.
여기서 얻은 가장 큰 교훈은 이겁니다. AI가 만들어낸 “사실처럼 보이는 값”은 무조건 1차 검증을 거쳐야 한다. 링크 슬러그뿐 아니라 통계 수치, 인용구, 날짜처럼 AI가 자신 있게 제시하지만 출처가 불분명한 모든 값이 여기에 해당합니다.
그래서 배운 것: AI 도구는 “검토 없이” 쓰는 순간 위험하다
세 함정의 공통점이 있습니다. 셋 다 요란하게 터지지 않았다는 점입니다. cron의 WP-CLI는 종료 코드 0으로 성공인 척했고, 한글 grep은 조용히 빈 값을 뱉었고, AI는 자신만만하게 가짜 링크를 만들었습니다. 전부 “겉보기엔 성공”이라 검토를 건너뛰게 만드는 함정이었습니다.
이 외에도 자잘한 함정은 더 있었습니다. 마크다운 표를 변환해 발행했더니 모바일에서 한글 셀이 음절 단위로 짓눌려 읽을 수 없게 깨지는 문제도 있었는데, 표를 figure 블록으로 감싸고 word-break: keep-all을 적용해서야 정상으로 보였습니다.
정리하면, Claude Code 워드프레스 자동화로 시간을 아끼는 건 분명한 사실입니다. 하지만 그 ROI는 사람이 최종적으로 검토하는 단계를 남겨둘 때만 유지됩니다. 검토를 없애는 순간, 자동화는 시간을 아껴주는 게 아니라 잘못된 결과를 빠르게 양산하는 도구가 됩니다. Claude Code 같은 AI 에이전트는 강력하지만, 어디서 조용히 틀리는지를 모르면 그 강력함이 그대로 리스크가 됩니다.
비슷한 결의 시도가 궁금하다면, 단일 AI를 넘어 여러 에이전트를 조합한 멀티에이전트 시스템 구축 경험도 같은 맥락에서 참고가 될 겁니다. 참고로 이 블로그는 이렇게 다듬은 워크플로우로 미국 기업 심층 분석 같은 글을 발행하지만, 모든 글은 발행 전에 사람이 직접 검토한 뒤 게시합니다. 결국 AI 도구를 잘 쓴다는 건, AI가 어디서 조용히 틀리는지를 알고 그 자리에 검증을 끼워 넣는 일이라고 생각합니다.
