SEO 개선을 제안부터 효과 검증까지 하나의 흐름으로 관리하는 방법 ── AIO Helper

마쓰바라 마사요시(上原正吉) (EarthLink Network Co., Ltd.)입니다. Claude Code를 개발의 주체로 삼아 20개가 넘는 제품을 혼자 동시에 개발하고 운영하고 있습니다. 이것은 현장에서 직접 측정한 기록입니다.

AIO Helper는 저희가 만들고 있는 SEO 운영 SaaS입니다. 검색 데이터를 가져와 AI가 페이지별 개선안을 제시하고, 승인된 안을 페이지에 반영하며, 반영 후에 효과가 있었는지 확인합니다. 이 4단계 과정을 하나의 화면과 하나의 데이터베이스에서 처리합니다.

• 가져오기(取り込む): Google Search Console 등에서 페이지와 키워드별 수치를 매일 가져옵니다.
• 제안하기(提案する): AI가 페이지별로 제목, 설명문, 내부 링크, 콘텐츠 추가 등의 개선안을 제시합니다. 제안에는 예상 효과, 확신도, 리스크, 노력도가 포함됩니다.
• 반영하기(反映する): 사람이 승인한 안을 페이지에 반영합니다. 제목이나 설명문은 AIO Helper가 가진 페이지별 SEO 설정에 기록하고, 사이트 측에서는 이를 API로 읽습니다. 자체 CMS인 'Plovant'의 페이지에는 리스크가 낮은 안을 매일 자동으로 반영하는 설정도 있습니다.
• 확인하기(確かめる): 반영한 시책을 14일 간격으로 나누어 관찰하고, 순위, 클릭, 노출 수로 '개선', '변화 없음', '악화', '데이터 부족' 등으로 분류합니다.

반영된 변경 이력과 검증 결과를 보고 얻은 학습 기록은 다음 개선안을 만들 때 AI가 검색하는 자료가 됩니다. 본문에서는 이 4단계 과정을 실제 화면과 코드로 설명하겠습니다.

AIO Helper는 원래 저희 CMS인 'Plovant' 안에 있던 SEO 기능이었습니다. Plovant는 처음에는 SEO 플랫폼으로 만들기 시작했습니다. 이후 하나의 리포지토리(repository)에 CMS와 SEO라는 두 가지 제품이 함께 존재하게 되면서, SEO 기능을 별도의 제품으로 분리했습니다. 그것이 AIO Helper입니다.

분리할 때 생각했던 것은, SEO에서 가장 번거로운 부분이 무엇인가 하는 것이었습니다.

개선안을 제시하는 것 자체는 지금은 그리 어렵지 않습니다. Search Console의 수치를 보면 '노출 수는 많은데 클릭이 적은 페이지'를 알 수 있고, AI에게 물어보면 제목 수정 제안도 나옵니다.

어려운 것은 그 이후입니다.

• 제시된 안 중 어떤 것을 실제로 페이지에 넣었는지.
• 언제 넣었으며, 변경 전의 순위나 클릭은 어땠는지.
• 넣은 후 효과가 있었는지, 오히려 나빠졌는지를.
• 효과가 좋았던 시책을 다른 페이지에도 확장해도 되는지.

이것을 스프레드시트로 관리하기 시작하면 금방 따라잡기 어려워집니다. 제안하는 장소, 페이지를 수정하는 장소, 수치를 보는 장소가 여기저기 분산되어 있기 때문입니다.

그래서 AIO Helper에서는 개선안을 '제안'이라는 하나의 레코드로 만들고, 그 레코드가 승인/반영/검증과 상태가 변해가는 형태로 만들었습니다. 어떤 페이지에 무엇을 했고 지표가 어떻게 바뀌었는지를 제안별로 나중에 추적할 수 있도록 하기 위함입니다.

관리 화면은 왼쪽 메뉴에서 다음 4개의 그룹으로 나뉘어 있습니다.

CONTROL 컨트롤룸
STRATEGY 전략 파이프라인 / 확장 로드맵 / 성장 구조
INSIGHTS 키워드 / 페이지 관리 / 페이지 목표 / 콘텐츠 / 사이트 구조 /
...

화면 상단에서는 보는 사람의 입장을 '운영자(オペレーター)', '매니저(マネージャー)', '임원진(エグゼクティブ)'으로 전환할 수 있습니다. 매일 시책을 운영하는 사람, 우선순위를 결정하는 사람, 전체 수치만 보고 싶은 사람 등 같은 데이터라도 보여주는 방식을 다르게 합니다.

여기서 4단계 과정을 순서대로 살펴보겠습니다.

첫 번째 단계는 검색 데이터 가져오기입니다. 중심은 Google Search Console의 데이터이며, 그 외에 Google Analytics 4, PageSpeed Insights, 광고 데이터 등을 가져오는 처리도 있습니다.

매일의 처리는 정해진 순서로 작동합니다. 시각은 일본 시간입니다.

03:30 Search Console 가져오기
04:00 사이트 문서를 벡터화하고 다시 만들기 (나중에 설명할 검색 준비)
04:10 반영된 시책의 전후 수치 집계
...

가져온 수치가 그날의 제안과 검증 자료가 될 순서로 배치되어 있습니다.

가져오기 단계에서 신경 쓴 부분은, Search Console 데이터가 확정되는 데 시간이 걸린다는 점입니다. 어제 데이터를 어제 중에 가져가면 아직 '0건'인 경우가 있습니다. '0건' 상태를 '가져오기 완료'로 처리하면 그날의 데이터가 빠진 채로 남게 됩니다.

따라서 일일 데이터 가져오기는 매번 7일치를 모아서 다시 가져옵니다. 기본 설정은 3일 전을 마감일로 하는 7일치입니다.

// seo-ingest-gsc/src/dates.ts
export const DEFAULT_REFETCH_DAYS = 7;

이미 가져온 날짜라도 확정된 값으로 덮어씁니다. 같은 날을 몇 번 가져와도 결과가 바뀌지 않도록 처리되어 있어, 재가져오기를 매일 반복해도 중복되지 않습니다. 이 '0건 상태로 완료 처리되어 누락되는' 문제는 실제로 발생한 후에 수정했습니다. 자세한 경위는 이 시리즈의 다른 글에서 다루겠습니다.

가져온 수치는 페이지 단위, 키워드 단위, 일 단위로 데이터베이스에 저장됩니다. 키워드 화면에서는 추적 중인 키워드의 순위 외에도 '검색량은 있지만 아직 내 사이트가 순위를 차지하지 못한 키워드'를 격차(gap)로 보여줍니다.

두 번째 단계는 AI를 이용한 개선안입니다. '전략 파이프라인' 화면에 페이지별 제안들이 나열됩니다.

제안 1건은 다음과 같은 형태의 데이터입니다. 데모 데이터 1건을 API 응답에서 그대로 추출했습니다.

{
"type": "Meta",
"target": "/pricing",
...
}

제안의 주요 유형으로는 제목이나 설명문 변경(Meta), 본문 재작성(Content), 관련 페이지 그룹 추가(Cluster), 내부 링크(InternalLink), 사이트 구조(Architecture), 표시 속도(Performance), 브랜드 표기(Brand) 등이 있습니다.

각 제안에는 'impact(예상 효과)', 'confidence(확신도)', 'risk(위험도)', 'effort(노력/수고)'가 붙습니다. 화면에서는 예상 효과, 확신도, 위험도로 정렬하고 유형, 위험도, 노력으로 필터링할 수 있어, '효과가 크고 위험도가 낮은 것'부터 처리할 수 있습니다. 위험도에는 이유도 함께 기재합니다. 제목을 수정하는 것과 새로운 페이지 3개를 추가하는 것은 실패했을 때 미치는 영향이 완전히 다르기 때문입니다.

AI가 제안을 만들 때 아무것도 없는 상태에서 생각하는 것이 아닙니다. 사이트에 관한 문서를 벡터 검색(문장의 의미 근접도로 찾는 시스템)으로 가져온 후, 초안을 만듭니다. 그 검색 순서가 다음 코드입니다.

SELECT d.id AS doc_id, d.doc_type, d.title, d.content,
(e.embedding <=> $1::vector) AS distance
FROM seo_embeddings e
...

순서의 의미는 다음과 같습니다.

• 먼저, 해당 사이트 자체의 문서를 우선합니다.
• 그중에서는 브랜드 표기 규칙(brand_rules)을 최우선으로 합니다. 회사명이나 제품명 표기를 잘못한 제안은 아무리 효과가 커 보여도 사용할 수 없기 때문입니다.
• 다음이 learning입니다. 효과 검증 화면에서 결과를 본 사람이, 제안별로 남기는 학습 기록입니다. '어떤 유형의 제안을 어떤 페이지에 적용했고, 결과가 어땠는지'를 통해 알게 된 것을 1건씩 남깁니다.
• 그 뒤에는 효과 보고(outcome_report)와 변경 이력(change_log)이 이어집니다. change_log는 페이지의 SEO 설정을 바꿀 때마다 자동으로 남는 기록입니다.

즉, 이전에 효과가 있었던 조치와 그렇지 않았던 조치가 다음 개선안을 만들 때 근거로 가장 먼저 끌어옵니다. 제안을 내놓고 끝내는 것이 아니라, 효과 검증까지 추적하는 이유 중 하나가 여기에 있습니다. 검증 기록이 남아있지 않으면, AI는 매번 비슷한 일반론적인 제안만 하게 됩니다.

세 번째 단계는 페이지에 반영하는 것입니다.

반영 경로는 두 가지가 있습니다.

첫 번째는 AIO Helper가 가진 페이지별 SEO 설정에 쓰는 경로입니다. 제목이나 설명문을 바꾸면, 이 설정(PUT /v1/seo)이 업데이트됩니다. 사이트 측에서는 이 SEO 설정을 API(/v1/seo)에서 읽어 페이지 표시에 사용합니다. 이를 위한 부품도 준비되어 있습니다.

// packages/seo-kit/src/fetch-seo.ts (발췌)
const url = `${SEO_API_URL}/v1/seo?siteId=${encodeURIComponent(siteId)}&path=${encodeURIComponent(path)}&locale=${encodeURIComponent(locale)}`;
const res = await fetch(url, { cache: "no-store" });

작성과 동시에 다음 3가지를 수행합니다.

• 변경 전과 변경 후를 change_log로 저장하여, 다음 제안의 검색 자료로 활용합니다.
• 등록된 알림 수신처로 서명이 포함된 알림(webhook)인 seo.updated를 전송합니다.
• Search Console에 사이트맵을 재전송합니다.

두 번째는 자체 CMS인 'Plovant' 페이지에 직접 반영하는 경로입니다. 사이트별 설정에서 활성화하면, 위험도가 낮은 제안들을 매일 Plovant 페이지의 초안(draft)으로 자동 반영합니다. 초안을 공개할 때까지 자동으로 할지 여부는 별도의 설정에서 결정합니다.

자동으로 반영되는 범위를 '초안까지만'과 '공개까지' 두 단계로 나눈 이유는, AI가 제안한 내용을 그대로 공개하여 검색 순위가 떨어질 경우 되돌리기가 어렵기 때문입니다. 먼저 초안 상태에서 내용의 진위를 확인할 수 있는 환경을 만들고, 공개까지 맡길지 여부는 사이트별로 결정할 수 있도록 했습니다.

네 번째 단계는 효과 검증입니다. 효과를 검증하는 대상은 페이지와 목표 키워드의 조합으로 등록한 시책(施策)입니다. 반영된 모든 제안이 자동으로 대상이 되는 것은 아닙니다. '효과 검증' 화면에 대상이 된 시책별 결과가 나열됩니다.

검증에서는 공개일로부터 14일 간격으로 기간을 나누어, 반영 전 기간과 비교하여 대상 키워드의 순위나 페이지의 클릭 수가 어떻게 변했는지 살펴봅니다. 관찰은 보통 공개 후 56일까지 진행됩니다. 기준 값은 다음과 같습니다.

// rank-watch-judge.ts
export const DEFAULT_JUDGE_CONFIG: JudgeConfig = {
minImpressions: 50, // 기간 내 노출(表示回数)이 이보다 적으면 결론을 내리지 않음
...

여기서 중요하게 생각한 점은 '데이터 부족'을 검증 결과로 남기는 것입니다.

검색 수치는 원래 변동성이 큽니다. 노출 수가 몇 번밖에 없는 키워드에서 순위가 1계단 올랐더라도, 그것이 시책의 효과인지 우연인지는 알 수 없습니다. 그래서 대상 키워드의 노출 수가 기간 내에 50회에 도달하지 못하면, '개선'도 '악화'라고 말하지 않고 데이터가 부족하다고만 기록합니다.

또한, 목표 키워드의 순위가 올랐더라도 페이지 전체의 클릭이 크게 줄었다면 '악화'로 간주합니다. 이는 하나의 키워드만 보고 페이지 전체에서 손해를 보고 있다는 사실을 인지하지 못하는 상황을 피하기 위함입니다.

검증 결과를 본 사람은 해당 제안에 학습 기록(learning)을 추가할 수 있습니다. 이 기록은 이전 장에서 설명했듯이 다음 제안의 근거로 검색됩니다. 악화된 시책은 화면의 '다음 액션'에 되돌릴지 여부를 검토하는 항목으로 나타납니다.

AIO Helper를 만드는 데는 명확한 한계점도 있습니다.

• 노출 수가 적은 페이지는 결론을 내리기 어려운 경우가 많습니다. 검증에 필요한 수치가 갖춰지지 않기 때문에, 새로운 페이지나 검색량이 적은 페이지에서는 '데이터 부족' 상태가 지속됩니다. 데이터가 충분히 모이지 않은 상태에서 '데이터 부족'으로 관찰이 끝날 수도 있습니다. 해당 시책을 나중에 다시 확인하려면 재등록해야 합니다.
• 순위 변화를 오직 시책만의 탓으로 돌릴 수 없습니다. 검색 엔진 자체의 변경이나 경쟁 페이지의 변화로도 순위는 움직입니다. 반영 전과 반영 후를 비교하는 방식이므로, 같은 시기에 발생한 다른 변화는 구별할 수 없습니다.
• AI에 비용이 발생합니다. 제안을 만들 때마다 생성형 AI(生成AI)와 벡터 검색 API를 호출하기 때문에 사용할수록 비용이 증가합니다. 따라서 사이트별로 월간 상한선을 설정하고, 예상 비용이 잔액을 초과하는 요청은 AI 호출 전에 중단시키는 장치를 마련했습니다. 다만 이는 사전 예측에 의한 중단 시스템이므로, 예측보다 실제 비용이 높거나 동시에 들어오는 요청으로 인한 초과는 막을 수 없습니다. 이 시스템에 대해서는 다음 글에서 자세히 설명하겠습니다.

AIO Helper 관련 글은 이번 소개를 시작점으로 삼아 기능별 설명을 하고, 개발 과정에서 판단했던 내용들을 순서대로 작성해 나갈 예정입니다. 계획하고 있는 주제는 다음과 같습니다.

• 청구서가 오기 전에 앱 내에서 AI 사용액을 중단시키는 시스템
• Search Console 데이터 확정 지연 문제와 어제 날짜 데이터가 0건이 되는 문제
• 호출 빈도가 낮은 API를 상시 구동 서버에서 필요할 때만 작동하는 구성으로 변경한 판단
• 여러 언어 버전이 있는 사이트에서 동일 페이지의 언어별 차이를 하나로 모아 보는 방법
• AI가 개선안을 내지 않게 되는 문제와 프롬프트 및 데이터베이스 양쪽에서 방지한 방법
• 벡터 검색을 실제 Postgres 환경에서 테스트하는 이유

SEO 개선에 시간이 많이 걸리는 이유는, 개선안을 내는 것보다 어떤 페이지에 무엇을 넣고, 그 이후 어떻게 되었는지 계속 추적하는 데서 옵니다.

• AIO Helper는 개선안을 '제안'이라는 하나의 레코드로 만들고, 수집(取り込み)・제안・반영・검증의 4단계에서 상태를 변화시킵니다.
• 검증 단계에서는 '데이터 부족'도 결과로 가지며, 노출 횟수가 충분하지 않을 때는 개선이라고도 악화라고도 말하지 않습니다.
• 변경 이력과 검증 결과를 통해 얻은 학습 기록은 다음 제안을 만들 때 검색 자료가 되므로, 개선 기록 자체가 다음 개선의 근거가 됩니다.

이 AIO Helper에 대한 글은 어떤 기능이 있고 어떻게 구현했는지를 순차적인 시리즈로 공개할 예정입니다.

관심 있으신 분들은 '좋아요'와 아티클 구독을 부탁드립니다.

다른 자사 제품들은 https://www.eln.ne.jp/products 에 모아두었습니다.

우에하라 마사요시(上原正吉)입니다. EarthLink Network Co., Ltd에서 AI 개발을 하고 있습니다. 2025년부터 Claude Code를 개발의 주체로 삼아, 현재 20개가 넘는 제품을 혼자 동시에 개발하고 운영하고 있습니다. 이 연재에서는 현장에서 실제로 일어난 일(잘된 것도, 실패도)을 숫자를 함께 쓰겠습니다.

또한, AI로 업무나 개발 방식을 재편하고 싶은 회사/팀을 대상으로 AI 활용 컨설팅도 받고 있습니다. 상담은 www.eln.ne.jp에서 부탁드립니다.

EarthLink Network는 회사의 모든 업무를 AI로 돌리기 위해 필요한 것을 자체 제작하고 있습니다. 현재 만들고 있는 제품 목록과 개요는 이쪽에서 모아두었습니다.

회사와 각 제품의 상세 내용은 공식 웹사이트 www.eln.ne.jp를 참고해 주십시오.