AI한테 SEO를 맡기지 말고, SEO 엔지니어를 만들어라 — 3개월 168K 클릭의 구조
AI로 블로그 글이나 랜딩 페이지를 무한 양산해서 검색 트래픽 대박 났다는 썰, 솔직히 이제 지겹다 못해 사기처럼 느껴진다. (나도 블로그 운영하지만 그렇게 날로 먹을 수 있으면 누가 고생하겠는가…) 그런데 어제 r/ClaudeCode에 올라온 후기는 숫자의 디테일이 달라도 너무 달랐다. 최근 3개월간 구글 검색 콘솔(GSC) 기준 클릭 168K, 노출 1.41M, 클릭률(CTR) 11.9%, 평균 순위 7.5위.
이 성공담의 주인공이 강조한 핵심은 의외로 단순하면서도 묵직했다. “Claude Code로 페이지를 무지성으로 찍어내지 마라. 대신 닫힌 피드백 루프를 만들어라.”
AI로 SEO 하겠다는 사람들의 99%는 다 똑같은 실수를 저지른다. 프롬프트 대충 깎아서 키워드 때려 박고 수백 개 페이지를 공장처럼 찍어낸다. 그 결과가 뭘까? 자기 페이지들끼리 서로 키워드를 잡아먹는 ‘카니발라이제이션(자기잠식)’ 지옥이다(구글 알고리즘이 바보가 아니다). 글쓴이 역시 그 삽질을 뼈아프게 겪고 나서야 방식을 180도 바꿨단다. 글 쓰는 작가가 아니라, 검증하고 제어하는 ‘SEO 소프트웨어 엔지니어’를 만들기로.
루프는 다섯 단계로 닫힌다
이 사람이 공유한 파이프라인을 뜯어보면 무슨 마법 같은 프롬프트는 없다. 철저한 ‘공학적 순서’가 있을 뿐이다.
첫 단계는 코드를 한 줄이라도 치기 전에 구글 검색 콘솔(GSC) 데이터부터 까보는 거다. 새 페이지를 파기 전에, 이미 우리 사이트에 그 키워드로 순위 잡힌 URL이 있는지, 타깃 키워드의 검색 의도가 기존 글과 진짜 다른지 검증한다. 그리고 Claude에게 세 가지 중 딱 하나만 판정하게 강제한다. CREATE(신규 생성), IMPROVE EXISTING(기존 글 수정), REJECT(기각). 이 엄격한 분기 하나로 자기잠식의 90%를 원천 차단했다.
둘째, 배포 전 게이트(Pre-deploy Gate)다. 코드가 프로덕션으로 나가기 전에 통과해야 하는 하드코딩된 체크리스트다. 검색 의도가 명확한지, 기존 글과 겹치지 않는지, H1과 타이틀과 메타 태그가 칼같이 일치하는지, 캐노니컬 태그와 robots.txt 설정이 맞는지, 사이트맵에 잘 들어갔는지. 단 하나라도 어긋나면 빌드가 실패하며 배포를 막아버린다. 타협 따위는 없다.
셋째, 배포 후 라이브 검증이다. 소스 코드에서 잘 돌아가는 것과 실제 배포된 웹 브라우저에서 크롤러가 긁어가는 HTML은 완전히 다른 이야기다. 실서버 응답을 직접 찔러서 렌더링된 메타 태그와 캐노니컬 URL을 재확인한다. 실제로 로컬에선 멀쩡했는데 배포 환경에서 꼬였던 버그를 이 단계에서 여러 번 잡아냈단다(배포 직후 프로덕션 확인은 엔지니어의 국룰이다).
넷째, GSC 실측 데이터로 루프를 닫는다. 배포 후 데이터가 쌓이길 기다렸다가 트래픽이 꺾이면, 무작정 새 글을 싸지르는 게 아니라 원인부터 디버깅한다. 색인 누락인지, 캐노니컬 꼬임인지, 코드 배포 영향인지 조사한 뒤 KEEP, ITERATE, REVERT 중 하나를 택한다.
GSC → 의도/소유권 확인 → SEO audit → pre-deploy gate
→ 배포 → 프로덕션 검증 → GSC 측정 → keep/iterate/revert
댓글에서 나온 진짜 답
이 스레드의 진짜 알짜배기는 본문보다 댓글에 있었다. 테크 기업에서 대규모 SEO 인프라를 다뤄본 한 시니어의 지적이 폐부를 찌른다.
“데이터는 전략이 아니다. GSC에서 API로 데이터 뽑아오는 자동화는 누구나 짠다. 진짜 어려운 건 그 데이터를 읽고 카니발라이제이션을 감지하며 ‘어떤 페이지를 합치거나 죽일지’ 결정하는 판단 레이어다. 사람의 의사결정 전략이 썩어 있으면, AI는 단지 ‘틀린 판단’을 더 빠르고 거대한 규모로 자동화해 사이트를 골로 보낼 뿐이다.”
원글 작성자도 격하게 동의했다. GSC는 무슨 일이 벌어졌는지 보여줄 뿐이고, Claude는 원인 분석을 도울 뿐이다. 어떤 페이지를 살리고 어떤 페이지를 쳐낼지는 끝까지 엔지니어의 통찰에 달려 있다.
왜 주목할까
이 워크플로의 본질은 Claude라는 모델 자체가 아니라 견고한 ‘시스템 아키텍처’다. 실측 데이터(GSC), 도구(MCP), 배포 검증 규칙, 프로덕션 확인, 그리고 데이터 기반 피드백 사이클.
AI를 단순한 ‘블로그 글 대필 작가’로 쓰면 사람이 하던 멍청한 실수가 수백 배로 증폭된다. 하지만 AI를 ‘규칙을 검증하고 파이프라인을 지키는 엔지니어’로 쓰면 품질 게이트가 수백 배로 촘촘해진다. 똑같은 LLM을 쥐어줬는데 결과는 하늘과 땅 차이다.
기술 블로그를 운영하는 내 입장에서도 머리를 한 대 세게 얻어맞은 기분이다(GSC MCP 연동은 조만간 내 파이프라인에도 무조건 붙여봐야겠다).
SEO에 AI를 접목하는 법은 여전히 온갖 꼼수와 강의 팔이가 판치는 영역이다. 하지만 진짜 살아남는 답은 언제나 공학적 기본기에 있다. 페이지를 마구 찍어내는 손가락이 아니라, 잘못된 페이지를 가차 없이 걸러내는 검증 루프를 자동화하라. 168K 클릭이라는 숫자는 그 철저한 시스템 뒤에 자연스럽게 따라오는 부산물일 뿐이다.