에이전트 셋에게 블로그 127편 감사를 나눠 맡겼다

블로그 글이 127편까지 쌓였다. 검색으로 사람이 들어오는지, 들어와서 읽을 만한지 한 번은 따져 봐야 했다. 그런데 127편을 혼자 다시 읽을 수는 없다. 개발 글만 해도 한 편에 3천 자 안팎이고, 그런 글이 82편이다. 그래서 묶음을 셋으로 나눠 에이전트에게 감사를 맡겼다. 사이트 전체의 기술 점검은 따로 하나를 더 돌렸다.

돌아온 보고서에서 제일 먼저 눈에 걸린 숫자는 둘이었다. 82편 끝에 똑같은 꼬리말이 붙어 있었다. 그리고 검색 로봇이 받는 글 페이지 HTML 에는 본문이 42자뿐이었다.

127편을 41, 41, 45로 나눴다

나누는 기준은 글이 어디서 왔는지였다. 감사 A 는 이름으로 된 개발 글 15편과 db-06부터 db-36 사이의 DB 글 26편을 묶어 41편을 맡았다. 감사 B 는 나머지 DB 7편과 백엔드 34편, 합쳐서 41편. 감사 C 는 철학, 음악, 패션, 명화, 성경으로 이어지는 묶음글에 손으로 쓴 낱글 셋을 더해 45편이었다.

개발 글 82편은 한 생성기가, 묶음글은 다른 생성기가 만들었다. 같은 생성기에서 나온 글끼리 한 사람이 보면 공통 결함이 한 보고서 안에서 드러난다. 반대로 섞어서 나누면 같은 결함을 세 보고서가 조금씩 다르게 적어 온다.

표의 칸은 셋 다 같게 맞췄다. slug, 지금 제목, 분야, 글자 수, 검색 의도, 독창성, 겹치는 글, 판정, 이유. 판정은 네 가지 중 하나만 고르게 했다. 유지, 제목과 설명만 손질, 합치기, 검색 제외(noindex). 칸이 같아야 세 장을 나중에 하나로 합칠 수 있다.

숫자는 잰 방법과 같이 받았다

글자 수 하나도 재는 방법이 갈린다. 공백을 셀까? 코드 블록은? 그래서 보고서마다 맨 위에 측정 방법을 먼저 적게 했다. 파이썬 len() 으로 유니코드 코드포인트를 세고, 「전체」는 공백과 마크다운 기호, 코드 블록, 꼬리말까지 포함한 파일 전체, 「공백제외」는 \s 를 지운 뒤의 수다.

기술 점검은 브라우저가 아니라 자바스크립트를 실행하지 않는 원본 HTML 을 봐야 했다. 재현할 수 있게 명령까지 남겼다.

curl -s -A "Mozilla/5.0 (compatible; Googlebot/2.1)" "https://bruni-world.pages.dev/blog/post?p=n-plus-1" > p.html
# <body> 에서 <script>·<style> 을 걷어내고 태그를 지운 뒤 공백을 한 칸으로 줄여 길이를 쟀다

이렇게 받아 두면 다음 사람이 같은 명령으로 같은 숫자를 다시 낼 수 있다. 숫자만 덩그러니 있으면 그 숫자를 믿을지 말지부터 다시 따져야 한다.

모르는 건 「미확인」으로 적게 했다

이번 감사에서 제일 신경 쓴 규칙이다. 검색량을 잴 도구는 쓰지 않았다. 키워드 플래너도 서치 콘솔도 없었다. 그러니 「검색 의도」 칸과 「유입이 기대되는 10편」은 전부 추정이다. 보고서는 그 사실을 첫머리에 밝히고, 근거도 같이 적었다. 사람들이 그 문자열을 그대로 검색창에 치는 꼴인지, 에러 문구나 프레임워크 용어인지를 봤다는 식이다.

사실 관계도 마찬가지였다. 감사 A 는 database is not accepting commands to avoid wraparound data loss 라는 에러 문구가 최신 PostgreSQL 에서도 글자 그대로인지 미확인이라고 적었다. 감사 B 는 실제 사고를 다룬 두 편에 출처 링크가 없고 사실 대조도 하지 않았다고 적었다. 기술 점검은 미확인 목록을 아예 따로 한 장으로 뺐다. 서치 콘솔의 실제 색인 수, 네이버 검색 로봇이 자바스크립트를 실행하는지, LCP 같은 속도 수치.

추정이 실측처럼 적혀 있으면 그게 제일 위험하다. 「미확인」이라고 박혀 있으면 적어도 다음에 무엇을 재야 하는지는 남는다.

세 묶음이 따로 찾아낸 같은 결함

보고서를 나란히 놓으니 같은 이야기가 겹쳐 나왔다.

날짜도 걸렸다. 감사 B 의 41편은 전부 2026-08-12 하루에 올라갔다. 같은 날 같은 틀로 수십 편이 올라온 모양은 검색 엔진이 대량 생성 콘텐츠로 볼 수 있다. 세 보고서 모두 이 위험을 짚었지만, 실제로 그렇게 보고 있는지는 미확인으로 남겼다. 서치 콘솔의 색인 제외 사유로 재야 하는 문제라서다.

검색 로봇이 받는 HTML 에는 본문이 없었다

기술 점검이 가져온 숫자가 제일 셌다. /blog/post?p=n-plus-1 의 원본 HTML 에서 스크립트와 스타일을 걷어낸 본문은 42자였다. 「← 기록 / 불러오는 중… / © 2026 bruni — 홈으로 · 개인정보처리방침」이 전부다. 같은 글의 마크다운 원문은 3,315자, 한글만 1,594자인데 그건 자바스크립트가 따로 받아 그렸다.

빠진 건 본문만이 아니었다. canonical 과 JSON-LD 도 자바스크립트로만 붙었다. 목록 페이지 /blog/ 의 원본에는 글 링크가 0개였다. 본문 안에서 다른 글로 가는 링크도 127편 합계 0개. 로봇이 글을 찾을 통로는 사이트맵뿐이었다.

Google 의 JavaScript SEO 문서에도 서버 렌더링이나 미리 렌더링이 여전히 좋은 생각이고, 모든 봇이 자바스크립트를 실행하지는 않는다고 적혀 있다. 그래서 이 보고서는 글마다 본문이 든 정적 HTML 을 만드는 생성기를 최우선으로 올렸다.

판정을 합치니 127편이 이렇게 갈렸다

글을 버리라는 판정은 거의 없었다. 개발 글은 공백을 빼도 2천 자가 넘고 코드 블록이 있어 얇은 글로 볼 근거가 없다고 했다. 대신 96편이 제목과 설명에 걸렸다. 「청소부가 멈추면 DB 가 쓰기를 거부한다」처럼 비유로 지은 제목에는 사람들이 실제로 치는 PostgreSQL 도 wraparound 도 없다.

검색 제외를 하나 골라 놓고도 바로 할 수는 없었다. 감사 B 와 C 가 각각 grep 으로 확인했는데, 글별로 noindex 를 거는 장치 자체가 아직 없었다.

나눠 맡기면 생기는 틈

셋으로 나누니 빨랐지만 이음매에서 틈이 보였다. 감사 C 는 첫머리에 「묶음글 43편」이라고 적었다. 그런데 같은 보고서가 나열한 범위는 철학, 음악, 패션, 명화 각 5편에 성경 22편, 합쳐서 42편이다. 기술 점검도 그 생성기가 쓰는 글을 42편으로 셌다. 한 보고서 안의 숫자끼리도 대조해야 한다는 걸 이걸 보고 알았다.

판정의 뜻도 조금씩 달랐다. 감사 B 는 「유지」에 요약 손질이 포함된다고 따로 밝혔다. 같은 단어를 쓴다고 같은 기준은 아니다. 다음에 나눠 맡길 땐 판정마다 무엇을 포함하는지부터 한 줄씩 정해 두려고 한다.

핵심 한 줄나눠 맡긴 감사는 표의 칸을 맞추고, 모르는 칸을 비워 둘 이름을 정해 줄 때 비로소 합쳐진다.