이번 봄, PV 201인 LP를 매일 아침 AI가 점검하게 하여 '건드리지 않는' SEO 운영 체계를 만들었다

만든 뒤에 멈추는 문제

사이드 프로젝트는 만드는 동안보다, 만든 뒤에 멈추기 쉽다.

처음 며칠은 기세로 수정할 수 있다.

SNS에 게시한다.

LP를 조금 수정한다.

검색 유입을 확인하러 간다.

거슬리는 버그를 잡는다.

하지만, 점점 보지 않게 된다.

'나중에 보기'는 대개 보지 않는다.

GA4도 Search Console도, 열어보면 숫자는 있다.

다만, 그 숫자를 보고 가설을 세우고, 딱 하나를 수정하고, 나중에 결과를 확인하는 단계까지 지속하는 것이 어렵다.

이번 봄에 바꾼 것은 새로운 앱을 늘리는 것이 아니었다.

기존의 LP를 매일 아침 AI에게 점검하게 하는 운영 방식을 도입한 것이었다.

대상으로 삼은 것은 VoltKeep이라는 Tesla용 iOS 앱의 랜딩 페이지(LP)다.

LP는 Cloudflare Pages로 배포하고 있으며, 블로그와 FAQ도 정적 HTML로 보유하고 있다.

여기에 매일 아침 9시에 GA4와 Search Console을 확인하고, 필요하다면 작게 수정하는 AI 에이전트(AI Agent)를 배치했다.

무엇을 자동화하고 싶었는가

하고 싶었던 것은 'AI에게 SEO를 전부 맡기는 것'이 아니다.

오히려 반대로, AI가 기세에 눌려 너무 많이 수정하지 않도록 하고 싶었다.

검색 유입이 적은 LP는 숫자가 작다.

예를 들어 최근 28일 동안 GA4의 총 PV는 201, Search Console의 노출수는 213, 클릭은 1이었다.

이 정도 규모라면 매일 제목이나 본문을 건드리면 무엇이 효과가 있었는지 알 수 없게 된다.

그래서 자동화하고 싶었던 작업은 개선 그 자체보다 관찰과 기록이었다.

AI에게는 다음 규칙을 지키게 했다.

변경은 하루 1~3건까지로 제한한다
최근에 건드린 페이지는 원칙적으로 7일 이상 기다린다
메타 정보(Meta information), FAQ, 내부 링크 등 저리스크(Low-risk) 변경으로 한정한다
변경하면 반드시 가설, 검증 지표, 추적일을 PDCA 로그에 남긴다
배포 후에는 200 OK뿐만 아니라 페이지 고유의 문자열, canonical, JSON-LD까지 확인한다
숫자가 작을 때는 '변경하지 않음'도 성과로 취급한다

매일 아침의 처리는 대략 다음과 같았다.

GA4에서 페이지별 PV, 유입 경로, 디바이스, 일별 PV를 확인한다
Search Console에서 쿼리(Query), 페이지, 쿼리×페이지를 확인한다
최근의 PDCA 로그를 읽는다
이미 건드린 페이지를 다시 건드리려 하지 않는지 확인한다
저리스크 수정만 1~3건 선택한다
변경한다면 가설, 검증 방법, 추적일을 로그에 남긴다
배포 후에 실제 운영 페이지의 내용까지 확인한다

여기서 중요한 것은 5번보다 3번과 4번이었다.

AI에게 '무언가 개선해줘'라고 부탁하면 그럴싸한 수정안은 나오기 쉽다.

하지만 숫자가 작은 LP에서는 매일 건드릴수록 검증하기 어려워진다.

사용 중인 최소 구성

구성은 소박하다.

Hermes cron
└─ VoltKeep LP maintenance job
├─ GA4 report script
...

스케줄은 cron 식으로 매일 아침 9시로 설정했다.

0 9 * * *

리포트 취득은 일반적인 Python 스크립트로 작성했다.

/usr/bin/python3 scripts/ga4-report.py 28
/usr/bin/python3 scripts/gsc-report.py 28 --mode query --limit 30
/usr/bin/python3 scripts/gsc-report.py 28 --mode page --limit 20
...

Search Console 측은 쿼리뿐만 아니라 쿼리와 페이지의 조합을 보도록 했다.

같은 쿼리라도 어떤 페이지가 노출되느냐에 따라 대응책이 달라지기 때문이다.

예를 들어, 최근 Search Console에서는 Supercharger 요금 관련 검색에서 기사가 노출되고 있었다.

페이지 단위로는 충전 가이드 기사가 약 100 impressions, 0 clicks, 평균 순위는 한 자릿수였다.

이 숫자만 보면 제목을 강력하게 만들고 싶어진다.

하지만 그 페이지는 이미 6월 13일에 메타 정보를 수정했었다.

그래서 다음 날 이후에는 바로 재조정하지 않고, 로그에 '아직 측정 기간 중이므로 대기'라고 남겼다.

자동화해서 좋았던 점은 바로 여기였다.

AI에게 작업을 시켰다기보다, AI에게 '오늘은 건드리지 마'라고 말하게 하는 메커니즘을 만들 수 있었다.

PDCA 로그를 먼저 읽게 하기

가장 효과가 좋았던 것은 docs/seo-pdca-log.md를 만든 것이었다.

로그에는 변경 내용뿐만 아니라 다음 항목을 반드시 쓰게 한다.

Trigger: 무엇을 보고 움직이는가
Hypothesis: 왜 효과가 있을 것이라고 생각하는가
Action: 무엇을 바꾸었는가, 또는 바꾸지 않았는가
...

이 형식을 채택한 이유는 AI의 출력을 '작업 보고'가 아닌 '실험 기록'에 가깝게 만들고 싶었기 때문이다.

작업 보고만 하면 매일 다음과 같이 남는다.

확인했습니다.
개선했습니다.
배포했습니다.

이렇게 되면 나중에 다시 읽어도 왜 그 변경을 했는지 알 수 없다.

다음 AI도 같은 페이지에 같은 종류의 변경을 중복해서 수행하게 된다.

PDCA 로그로 만든 덕분에, AI가 다음번의 자신에게 브레이크를 걸 수 있게 되었다.

이는 사람에게도 효과가 있었다.

"이 페이지, 다시 손보는 게 좋지 않을까"라고 생각될 때, 로그를 읽어보면 "아직 7일밖에 지나지 않았다"는 것을 알 수 있다.

실제로 수행한 변경

이 메커니즘을 통해 몇 가지 작은 변경 사항들을 쌓아 올렸다.

예를 들어, 6월 13일에는 Supercharger 요금 관련 쿼리에 맞춰 충전 가이드 기사의 메타 정보와 구조화 데이터 (Structured Data) 주변을 정리했다.

6월 17일에는 메인 페이지의 FAQ에서 상세 FAQ로 연결되는 내부 링크 (Internal Link)를 추가했다.

GA4에서는 메인 페이지가 28일 동안 181 PV 전후를 기록하고 있었으나, 상세 FAQ는 거의 조회되지 않고 있었기에, 유입구에서 깊은 페이지로 연결하는 가설을 세웠다.

6월 21일 이후에는 FAQPage의 JSON-LD와 실제로 보이는 FAQ 내용이 어긋나는 페이지를 수정했다.

HTML로는 표시되고 있지만, 구조화 데이터가 예전 상태 그대로 남아 있는 경우가 있었다.

이는 수동으로 작성한 정적 HTML (Static HTML)에서 흔히 발생하는 문제였다.

6월 24일에는 TeslaMate alternative iOS와 phantom drain 계열의 검색 의도 (Search Intent)에 맞춰 비교 페이지와 유즈케이스 (Use Case) 페이지를 만들었다.

다만, 이 또한 단순히 "새로운 페이지를 늘렸다"에서 끝내지 않고, Search Console에서 새로운 URL에 노출수 (Impressions)가 발생하는지를 7일에서 28일 사이의 기간을 두고 관찰하기로 했다.

사소하지만, 이런 변경 사항은 사람 혼자 하면 뒤로 미뤄지기 쉽다.

AI가 매일 아침 확인하게 하면 "너무 작아서 잊어버리기 쉬운 작업"을 잡아낼 수 있다.

자동화를 통해 알게 된 실패 패턴

직접 해보니 몇 가지 실패하기 쉬운 패턴이 보였다.

1. 200 OK만 봐서는 의미가 없다

정적 사이트라도 라우팅 (Routing) 설정에 따라 존재하지 않는 경로에 LP의 index.html이 반환될 수 있다.

HTTP 상태 코드 (Status Code)만 보면 존재하는 것처럼 보일 수 있다.

따라서 실운영 확인 시에는 200 OK뿐만 아니라 페이지 고유의 문자열을 확인하도록 했다.

TS=$(date +%s)
curl -s "https://voltkeep.seeda.fun/blog/phantom-drain-guide/?bust=$TS" \
| grep -c "phantom"

실제 운영 시에는 변경한 페이지마다 제목, canonical, JSON-LD, sitemap의 loc 등도 확인한다.

2. JSON-LD는 깨지지 않았더라도 낡을 수 있다

json.loads로 파싱 (Parsing)할 수 있는 것과 페이지 본문과 일치하는 것은 별개의 문제였다.

FAQPage의 JSON-LD는 구문상으로는 올바르더라도, 눈에 보이는 FAQ와 질문 수나 답변 문구가 어긋나는 경우가 있었다.

이 경우 검색 엔진이나 AI가 어느 쪽을 신뢰해야 할지 모호해진다.

그래서 FAQ가 있는 페이지에서는 보이는 FAQ와 JSON-LD의 mainEntity를 대조하도록 했다.

이는 자동화와 궁합이 좋았다.

사람이 눈으로 전부 확인하기에는 지루하지만, AI에게 리뷰 (Review)를 시키기에는 딱 적당한 작업이다.

3. AI는 "기다림"을 어려워한다

가장 컸던 점은 이것이었다.

AI는 어떤 식으로든 개선안을 내놓는 것을 잘한다.

하지만 데이터가 적은 LP에서는 기다리는 것이 개선이 되는 경우도 있다.

6월 19일 로그에는 의도적으로 변경하지 않은 날을 남겨두었다.

이유는 6월 13일부터 18일 사이에 이미 메타 정보, FAQ 스키마 (Schema), 내부 링크, sitemap 조정을 마쳤기 때문이다.

여기서 더 손을 대면 나중에 무엇이 효과가 있었는지 알 수 없게 된다.

"오늘은 변경하지 않는다"를 하나의 성과로 취급할 수 있게 되면서, 비로소 운영다운 운영이 되었다.

인간의 역할은 사라지지 않았다

매일 아침 AI가 확인해 주게 되었음에도 인간의 역할은 남아 있었다.

오히려 인간이 확인해야 할 부분이 명확해졌다.

역할 분담은 대략 다음과 같이 되었다.

판단	AI에게 맡겼는가	이유
GA4와 Search Console의 정형 확인	맡겼음	매일 같은 절차이기 때문
...

AI는 손을 움직일 수 있다.

하지만 무엇을 성과로 간주할지는 여전히 인간이 결정해야 한다.

직접 한다면 처음에 결정해야 할 것

같은 일을 다른 사이드 프로젝트(Side Project)에서 한다면, 처음에 결정해야 할 것은 도구가 아니라 운영 규칙이라고 생각한다.

적어도 다음 5가지는 미리 적어둔다.

대상으로 할 페이지나 프로덕트(Product)를 좁힌다
1회 실행 시 변경해도 좋은 건수를 결정한다
최근에 수정한 페이지를 며칠 동안 기다릴지 결정한다
변경하지 않는 날도 PDCA 로그에 남긴다
운영 환경(Production) 확인 시 볼 고유 문자열이나 구조화 데이터(Structured Data)를 결정한다

프롬프트(Prompt)도 멋있게 만들 필요는 없었다.

실제로는 다음과 같은 제약이 효과적이었다.

매일 아침, GA4와 Search Console을 확인한다.
변경 전에 반드시 PDCA 로그를 읽는다.
이미 수정한 페이지를 단기간에 재조정하지 않는다.
...

이 정도라면 어떤 정적 사이트(Static Site)에서도 시작하기 쉽다.

오히려 처음부터 거대한 자율 에이전트(Autonomous Agent)로 만들지 않는 것이 좋다.

작은 정형 확인 작업에 가두어 두는 편이 결과적으로 인간이 추적하기 쉽다.

이번 봄의 한 걸음

이번 봄에 잘했다고 생각하는 것은 '매일 열심히 하겠다'고 결심한 것이 아니다.

매일 열심히 하지 않더라도, 매일 아침 확인하러 가는 메커니즘(Mechanism)을 구축한 것이었다.

사이드 프로젝트는 만든 순간보다, 가늘고 길게 이어가는 시간이 더 길다.

그 시간을 전부 정신력으로 버티는 것은 어렵다.

AI 에이전트에게 맡긴다면, 화려한 신기능보다는 우선 '계속 지켜보기', '기록하기', '같은 일을 반복하지 않기'부터 시작하는 것이 좋았다.

이번에 좋았던 점은 cron을 통해 GA4와 Search Console을 확인하고, PDCA 로그를 먼저 읽게 하며, '건드리지 않는다'는 판단까지 남긴 것이었다.

작은 LP라도 매일 아침 확인하고, 가설을 하나 남기고, 필요할 때만 수정한다.

그것만으로도 멈춰가던 사이드 프로젝트가 조금씩 운영 궤도로 돌아왔다.