90개의 깨진 리치 결과(Rich Results) 페이지: 자율 에이전트가 이를 찾아내고 수정하며, 스스로 모니터링 시스템까지 재작성한 과정

자율 에이전트(autonomous agent)를 통해 1인 SaaS를 운영한 지 12일째 되는 날, 저는 에이전트가 90개 페이지에 걸친 구조화된 데이터(structured data) 버그를 조용히 수정하고, 동일한 패턴을 영원히 감지할 수 있도록 자신의 모니터링 서브 에이전트(monitoring sub-agent)를 패치하는 과정을 지켜보았습니다. 다음은 실제 로그입니다.

BailleurVérif 제품은 오픈 데이터(data.gouv.fr + ADIL 판례)를 기반으로 구축된 프랑스 임대 규정 준수 확인 도구입니다. 이 서비스는 "내 파리 아파트 임대료가 법적으로 제한되어 있는가?"와 같은 질문에 답하기 위해 프로그래밍 방식으로 HTML 페이지를 생성하며, 계정 생성이 필요하지 않습니다. 이를 실행하는 에이전트는 cron을 통해 매시간 실행되며, 서버 로그와 메모리 파일을 읽고, 의사 결정을 내리고, 코드를 배포하며, GitHub에 커밋(commit)합니다. 제가 명시적인 브리프(brief)를 보내지 않는 한, 인간의 개입(human in the loop)은 없습니다.

11회 이상의 사이클 동안 숨어 있었던 버그
11회 이상의 웨이크 사이클(wake cycles) — 대략 11시간 연속으로 — 90개의 HTML 파일이 유효하지 않은 BreadcrumbList JSON-LD를 제공하고 있었습니다. 누락된 필드는 ListItem의 2번 위치(position 2)에 있는 item 속성이었습니다. Google의 리치 결과(Rich Results) 파서(parser)는 모든 브레드크럼(breadcrumb) 위치에 name과 item이 모두 필요합니다. item이 없으면 브레드크럼 리치 결과는 SERP(검색 엔진 결과 페이지)에서 조용히 누락됩니다. 오류나 경고 없이 그냥 사라지는 것입니다.

// 깨진 상태 (실제 라이브 상태)
{ "@type" : "ListItem" , "position" : 2 , "name" : "Encadrement des loyers Paris" }

// 유효한 상태 (있어야 할 상태)
{ "@type" : "ListItem" , "position" : 2 , "name" : "Encadrement des loyers Paris" , "item" : "https://bailleurverif.fr/loyer-legal-paris.html" }

저는 GSC(Google Search Console) URL 검사 도구를 통해 이를 인지했습니다. 9시간 전에 배포한 파리 페이지에 대해 "BreadcrumbList is invalid"라는 메시지가 표시되었습니다. 저는 09:45Z에 에이전트에게 브리프를 보냈습니다: "BreadcrumbList 2번 위치의 누락된 item 필드를 수정할 것 — 81개 이상의 페이지."

한 번의 웨이크 사이클 동안의 에이전트 응답
Run-321은 10:00Z에 시작되었습니다. 11:00Z까지:

1. 90개 파일에 대한 수정 사항 커밋
   에이전트는 Python의 str.replace를 실행했습니다. 확인 결과, 단순히 81개가 아니라 90개의 파일에 버그가 있었습니다 (더 넓은 범위의 grep이 더 많은 템플릿을 찾아냈습니다).

커밋 1개: commit 3ee81da fix: BreadcrumbList의 2번째 위치에 누락된 item 필드 추가 (81+ 페이지) 90개 파일: 31개 encadrement-loyer + 50개 DPE F/G + 9개 관련 항목 (guide-bailleur, scanner-arnaque, irl-revision-loyer 등).

2. 영구적인 규율 문서(discipline document) 작성
   에이전트는 memory-agent/concepts/seo-discipline.md 파일을 생성했습니다 (+80줄). 여기에는 올바른 JSON-LD 패턴, 6개의 표준 허브 URL (canonical hub URLs), 4가지 안티 패턴 (anti-patterns), 그리고 향후 sub-seo-monitor가 이를 자동으로 감지해야 한다는 규칙이 포함되었습니다. 이는 일회성 메모가 아니라, 향후 모든 웨이크 (wake)가 컨텍스트 (context)로 로드하게 될 개념 파일 (concept file)로 작성되었습니다.

3. 자체 모니터링 서브 에이전트 (sub-agent) 패치 (PATCH)
   이 부분이 제가 진정으로 흥미롭다고 느끼는 지점입니다. 에이전트는 매일 밤 실행되는 Haiku 서브 에이전트인 sub-seo-monitor에 HTTP PATCH 요청을 보내, 기존 작업 2와 3 사이에 새로운 감사 (audit) 작업을 추가했습니다:

def audit_breadcrumbs ( html_content : str ) -> dict :
    import json , re
    results = []
    for script in re . findall ( r ' <script type= " application/ld\+json " >(.*?)</script> ' , html_content , re . DOTALL ):
        try :
            data = json . loads ( script )
            if data . get ( " @type " ) == " BreadcrumbList " :
                for item in data . get ( " itemListElement " , []):
                    if " item " not in item :
                        results . append ( item )
        except Exception :
            pass
    return { " pages_with_missing_item " : len ( results )}
# 경고 규칙: if pages_with_missing_item >= 1 → inbox.md 상단에 추가

sub-seo-monitor의 프롬프트 (prompt) 길이는 3,301자에서 5,766자로 늘어났습니다 (+2,465자). 백업 해시 (backup hash)는 81a0184d8f687290으로 기록되었습니다. 서브 에이전트 레지스트리 (sub-agents registry)는 last_update_run=run-321로 업데이트되었습니다. 이제부터는 item 필드 누락을 재발생시키는 어떠한 HTML 템플릿 회귀 (regression)도 24시간 이내에 포착됩니다.

수정 후 12시간 동안 일어난 일
같은 날, SEO 인프라에서 제가 몇 주 동안 기다려온 루프가 독립적으로 완성되었습니다. Googlebot WRS Mobile이 처음으로 JavaScript를 사용하여 홈페이지를 렌더링(render)했습니다. 그 증거는 server.log에 남아 있습니다.

IP 66.249.73.129 (검증된 Googlebot)로부터의 세 번의 연속된 요청: 2026-05-20T06:40:00Z GET / 200, 2026-05-20T06:40:01Z GET /api/changelog?limit=5 200 ← JS 전용 엔드포인트 (JS-only endpoint), 2026-05-20T06:40:02Z POST /api/visit 200. /api/changelog는 홈페이지의 클라이언트 사이드 JavaScript (client-side JavaScript)에 의해서만 호출됩니다. 일반적인 HTML 크롤러 (crawler)는 이 엔드포인트에 도달하지 못합니다. Googlebot이 여기에 도달했다는 것은 Googlebot이 실제로 우리의 JavaScript (JS)를 실행하고 있음을 의미합니다. 같은 날, Paris 페이지가 라이브된 후 12시간 이내에 4개의 독립적인 채널을 통해 9개의 뚜렷한 봇 크롤링 (bot crawls)이 발생했습니다: Googlebot Mobile WRS (JS 렌더링됨, 위 내용 참조), Google-InspectionTool/1.0 (드문 신호이며, 아마도 GSC 품질 확인용), GPTBot/1.3 (OpenAI LLM 수집 파이프라인), 일반적인 AWS/Bing 크롤러들. // dashboard-extras.json, 배포 12시간 후 { "bot_hits_24h" : 60 , "bot_hits_lifetime" : 118 , "gptbot_today" : 11 , "last_googlebot" : "2026-05-20T08:43:24Z" }. 같은 주에 에이전트는 사이트의 Organization JSON-LD sameAs 배열에 Wikidata 엔티티(entity) Q139857638을 추가하였고, 푸터(footer)의 GitHub 및 Wikidata 링크를 가시화했습니다. Moat 카테고리-4(category-4)의 개수가 2개에서 3개의 실질적인 구성 요소로 증가했습니다.

Stack Agent runtime: Claude claude-opus-4-6 (Builder Opus)가 메인 cron wake를 실행; Claude claude-haiku-4-5 (서브 에이전트: sub-seo-monitor, sub-observatoire-publisher, sub-critic, sub-linkedin-drafter) Memory: memory-agent/ 내의 평면(flat) .md 파일들 (개념(concepts), 결정(decisions), KPI, 스냅샷(snapshots)) — 벡터 DB나 임베딩(embeddings) 없이, 실행 시작 시 로드되는 구조화된 Markdown(마크다운) 사용 Orchestration: Linux VPS 상에서 cron 0 * * * * 실행, 매 실행 시 1회의 Claude API 호출, 15분 시간 제한(time-boxed) Sub-agent management: PATCH/GET API를 갖춘 로컬 Node.js agent-browser 서버, sub-agents-registry.json에 등록된 에이전트들 HTML generation: 템플릿에 Python str.replace 적용, 90개의 정적 파일, GitHub PAT를 통해 커밋 및 푸시 SEO signals: JSON-LD (Organization, BreadcrumbList, FAQPage, Dataset), IndexNow 핑(pings), sitemap.xml 자동 생성 Data: data.gouv.fr 6a0c30a 재사용, ADIL 판례 스크래핑(scraping), observatoire 121-wave 교차 분석 (전국적으로 57.6%의 위반율) Takeaways 소리 없는 구조화된 데이터(structured data) 버그는 매우 교활합니다. Google은 아무런 경고 없이 유효하지 않은 리치 결과(Rich Results)를 제외합니다. 유일한 탐지 경로는 서버 로그가 아니라, GSC(Google Search Console) URL 검사 또는 전용 야간 감사(nightly audit)뿐입니다. 자신의 모니터링 시스템을 패치(patching)하는 것이 실제적인 해결책입니다. 브레드크럼(breadcrumb) 코드 수정에는 3분이 걸렸습니다. 규정 문서(discipline doc)를 작성하고 서브 에이전트 프롬프트(prompt)를 패치하는 데 12분이 더 걸렸습니다. 하지만 이제 어떤 템플릿 회귀(regression)가 발생하더라도 24시간 이내에 자동으로

🔗 코드 소스: MIT github.com/Creariax5/bailleurverif · 사이트: bailleurverif.fr · 위키데이터 (Wikidata) Q139857638