기술블로그 SEO 검사를 통과한 글이 안 읽힌 이유, 검사에 독자가 없었다

기술블로그 SEO 검사를 전부 통과한 글이 왜 읽히지 않았나?

기술블로그 SEO 검사를 전부 통과한 글이라도, 검사에 독자를 묻는 칸이 없으면 제목만 봐서는 무슨 글인지 알 수 없습니다. 저희가 자동으로 쓰고 검사를 거쳐 실은 기술블로그 글 4편이 바로 그랬습니다. 2026년 9월 2일 밤, 회사 대표가 실린 글을 직접 읽고 이렇게 말했습니다.

아무리 기술블로그라지만 검색 키워드나 글 주제와 맥락은 너무 고려를 안 한 것 같다. 전문적이고 어려워서가 아니라 그냥 문맥적으로 이해가 어렵다. 제목만 보고 어떤 내용일지 감도 안 오고, 어떤 문제·어떤 기술 이야기인지 예상이 안 되고, 그래서 궁금하지가 않다.

4편의 제목 가운데 셋은 “묻는 쪽이 더 위험했다”“1,300개의 에러는 버그가 아니었다”“노출 2.6→0.9, 범인은 따로 있었다”였습니다. 긴장감은 있는데 주어가 없습니다. 누가 무엇을 물었는지, 어느 도구의 에러인지, 어디의 노출이 줄었는지 제목만으로는 알 수 없습니다. 검색창에서 이 제목을 만난 사람은 자기 문제와 관련이 있는지조차 판단하지 못합니다.

이 결함은 에러를 내지 않습니다. 글은 정상으로 발행되고 검사는 초록불이며, 그저 읽히지 않을 뿐입니다. 같은 지적을 제목과 글쓰기 규칙 쪽에서 좇은 글로 기술블로그 제목에 기술명이 없던 원인이 이미 있습니다. 이 글은 시선을 검사기로 옮깁니다. 검사기는 무엇을 보지 않았고, 반대 방향으로는 어떻게 틀렸는지를 적습니다.

처음 의심한 것은 무엇이었나?

증상만 보면 떠오르는 설명은 셋이었습니다.

• 글이 전문적이어서 어렵다. 기술블로그는 전문 용어를 피하기 어렵고, 개발자가 아닌 독자에게는 문장마다 낯선 단어가 걸립니다. 맞다면 처방은 용어를 풀어 쓰는 일입니다.
• 제목 규칙이 느슨하다. 제목의 길이와 형태를 정한 조항이 있었으니, 그 조항에 틈이 있어 서사형 제목이 들어왔다고 볼 수 있습니다.
• 첫 문단이 약하다. 첫 문단에 결론을 먼저 쓰는 방식(BLUF, 결론을 맨 앞에 두는 글쓰기)을 규칙으로 두고 있었으니, 그 검사를 더 엄하게 조이는 처방이 따라옵니다.

셋 다 고치기 쉬운 방향을 가리켰습니다. 그래서 오히려 먼저 확인이 필요했습니다. 하나를 믿고 고치면 나머지 둘이 원인이었을 때 같은 일이 다시 나오기 때문입니다.

그 의심을 확인하는 데 무엇을 썼나?

수단은 세 가지였습니다. 세 번째가 결과를 갈랐는데, 이유는 뒤에서 풉니다.

• 비교 표본의 제목 분류. 다른 곳의 기술블로그 1,157편 제목을 기술명이나 문제 명사가 들어 있는지로 나눠 셉니다. 우리 글 4편에도 같은 잣대를 댑니다.
• 본문의 내부 용어 세기. 우리 4편 본문에서 사내 결정 기록에서만 쓰는 말이 몇 번 나오는지 셉니다.
• 규칙과 검사의 항목 대조. 글쓰기 규칙 문서의 조항과 검사 8항목을 나란히 놓고, “제목에 무슨 기술인지 있는가”“독자가 누구인가”를 묻는 칸이 어디에 있는지 찾습니다.

첫 번째 수단의 결과는 아래와 같습니다. 비교 표본 1,157편 가운데 86%가 제목에 기술명 또는 문제 명사를 담았고, 영문 기술 토큰만 세도 71%였습니다. 우리 4편은 0편이었습니다.

알리바이: 난이도도 제목 규칙 위반도 첫 문단도 범인이 아니었다

난이도부터 봅니다. 표본의 글도 전부 전문적인 기술 글입니다. 난이도가 원인이라면 전문적인 글일수록 제목이 모호해야 하는데, 실제로는 86%가 제목에서 기술명을 먼저 말했습니다. 우리 4편만 0편이었으니 난이도와 제목의 모호함은 따로 움직였습니다. 지적 원문도 이미 “어려워서가 아니라”라고 못 박고 있었습니다.

제목 규칙의 틈도 아니었습니다. 4편은 제목의 길이와 형태 규칙을 어기지 않았습니다. 규칙을 어긴 글이 아니라 규칙이 묻지 않은 자리에서 쓴 글이었습니다. 문제는 조항이 느슨한 데 있지 않고 조항이 없는 자리에 있었습니다.

첫 문단도 아니었습니다. 결론을 맨 앞에 두는 규칙은 이미 있었고 4편은 그 검사를 통과했습니다. 그런데 독자는 첫 문단을 읽고도 상황을 모른다고 했습니다. 결론 문장이 우리끼리 쓰는 말로 적혀 있었기 때문입니다. 그 결론은 맥락을 아는 사람에게만 결론입니다. 검사를 더 엄하게 해도 같은 문장은 같은 점수로 통과합니다.

진짜 원인은 무엇이었나? 검사에 독자를 묻는 칸이 없었다

항목 대조 결과가 남은 설명이었습니다. 글쓰기 규칙은 제목의 길이와 형태, 첫 문단의 결론만 정해 두었고 독자가 누구인지는 한 번도 정의하지 않았습니다. 검사 8항목 어디에도 “제목에 무슨 기술인지 있는가”가 없었고, 타깃 검색어를 정하는 단계 자체가 파이프라인에 없었습니다.

본문의 내부 용어 세기도 같은 방향을 가리켰습니다. 우리 4편 본문에는 판매 상품을 가리키는 사내 용어가 21회, “게이트”라는 낱말이 30회 나왔습니다. 연도 없이 월과 일만 적은 날짜도 있었습니다. 글의 재료가 사내 결정 기록이어서, 기록 속 어휘가 그대로 글로 흘러나왔습니다. 그 어휘를 막는 검사도, 막아야 한다는 규칙도 없었습니다.

검사기가 이 빈칸을 스스로 알아채지 못한 이유도 있습니다. 9월 1일에 검사 8항목을 처음 만들었을 때, 이미 실려 있던 글 2편이 둘 다 SEO 제약을 어기고 있었습니다. 검사는 만든 쪽이 떠올린 결함만 봅니다. 자기가 자른 조각을 자기가 채점하면 잘라낸 부분은 채점표에 오르지 않습니다. “이 글을 누가 읽는가”는 우리 쪽에서는 떠올릴 일이 없는 질문이었고, 그래서 사람이 글을 읽기 전까지 어느 검사에도 걸리지 않았습니다.

어떻게 고쳤나: 독자 규칙을 쓰고 검사 8항목을 더했다

고친 순서는 규칙, 검사, 기존 글입니다. 먼저 글쓰기 규칙 맨 앞에 독자 항목을 새로 썼습니다. 독자는 우리 회사도 시스템도 용어도 모르는 사람입니다. 중소기업 대표, 마케팅 담당, 외주 검토자, 동종 개발자가 여기에 듭니다.

• 타깃 검색어 1개를 먼저 정하고, 제목과 description과 첫 문단에 그대로 넣는다.
• 제목에 기술명이나 문제 명사를 반드시 넣는다. 서사형 훅은 부제 자리로 보낸다.
• “이 글의 배경” 블록을 120자 이상 쓴다. 어떤 회사가 어떤 시스템으로 무슨 일을 하다가 무엇이 문제였는지를 적는다.
• 내부 코드명을 0건으로 한다.
• 연도 없는 날짜를 0건으로 한다.
• 세션·턴·훅·게이트·에이전트를 3회 이상 쓰면 배경에서 정의한다.

둘째로 이 규칙을 검사 8항목으로 옮겼습니다. 기존 SEO 검사 8항목은 그대로 두고 독자 검사 8항목을 더했습니다. 셋째로 이미 실린 4편을 같은 주소(slug)를 유지한 채 전부 다시 썼습니다. 제목은 아래처럼 바뀌었고, 각 글에 배경 블록을 붙이고 내부 코드명을 모두 풀어 썼습니다.

• “pytest ERROR 1,300건의 원인은 로그 캡처였다”
• “Claude Code 자율 실행은 왜 한 턴 만에 멈추나”
• “SEO 콘텐츠 노출이 안 붙은 원인: 중복이 아니라 검색광고 입찰가였다”
• “AI 에이전트 승인 게이트를 4개로 줄인 기록”

네 제목 모두 앞쪽에 기술명이나 문제 명사가 있고, 이야기의 긴장은 부제로 남았습니다. 변경은 PR #455로 묶어 머지했고 라이브 페이지에서 확인했습니다.

같은 실수를 막는 장치는 무엇인가?

규칙만 고치면 다음 글에서 같은 일이 다시 나올 수 있어, 장치를 네 겹으로 걸었습니다.

• 검사를 한 곳에 둔다. 독자 검사 8항목은 함수 하나(reader_gates())에 있고, 글을 쓰기 전 점검(check)과 발행 뒤 SEO 점검(9번째 항목)이 둘 다 거기서 불러 씁니다. 규칙 사본이 둘이 되지 않습니다.
• 검사기에 판별력 시험을 건다. 통과해야 할 글은 통과하고 떨어져야 할 글은 떨어지는지 스스로 시험하는 절차(selftest)가 있고, 이번 변경에서 통과했습니다.
• 작성 쪽에도 같은 규칙을 준다. 글을 쓰는 프롬프트와 작성 지시서에 같은 규칙을 넣어, 검사에서 떨어질 글을 처음부터 덜 쓰게 했습니다.
• 통과율이 떨어져도 의도라고 못 박는다. 하루 발행 상한은 한 번 실행에 5편으로 그대로 두었습니다. 검사 8항목이 늘었으니 통과율은 떨어질 텐데, 그건 의도한 결과입니다.

검색량은 검사가 아니라 참고로 둡니다. 기술 롱테일(검색어가 길고 구체적인 구간)은 검색량 0이 정상이어서, 검사 기준은 “검색어가 제목에 있는가”로 잡았습니다.

검사기가 멀쩡한 글을 버리고 있다면 어떻게 찾나?

지금까지는 검사기가 통과시키지 말아야 할 글을 통과시킨 이야기입니다. 반대쪽 오류도 있었습니다. 9월 5일에 기술블로그 초안 20건을 열어 보니, 2건이 검사에 걸려 닫힌 채 묻혀 있었습니다. 둘 다 지금 기준으로는 모든 축을 통과하는 글이었습니다.

하나는 첫 문장을 가르는 정규식이 원인이었습니다. 검사 스크립트(techblog-seo-check.py 162번째 줄)의 첫 문장 분리기는 `(?<=[.!?다요])\s` 였습니다. 마침표 같은 문장부호나 “다”“요” 뒤의 공백을 문장 끝으로 봅니다. 그런데 “정해진 시각마다 자동으로”의 조사 “마다” 끝 글자 “다” 뒤 공백까지 문장 끝으로 잘라 버렸습니다. 첫 문장이 11자로 세어져 미달로 떨어졌고, 실제 길이는 108자였습니다. 다른 하나는 “초안 생성 실패”로 닫혔지만 파일은 완결된 상태였습니다.

처방에서 먼저 버린 대안이 셋입니다. 첫째 임계 완화입니다. 품질이 상품인 자리라 기각했습니다. 둘째 드롭될 때 사람에게 알림을 보내는 안입니다. 알림은 많아질수록 읽히지 않아 기각했습니다. 셋째 드롭된 항목을 매일 전수 재검사하는 안입니다. 닫힌 소재 75건은 대부분 초안조차 없어 매일 헛돌기에 기각했습니다.

채택한 방식은 임계를 그대로 두고, 버려진 글을 다시 보는 경로를 만들었습니다. 일일 초안 스크립트에 orphans() 함수를 넣어 “닫힘 + 초안 파일 존재 + 미발행” 세 조건을 모두 만족하는 초안만 다음 실행이 먼저 다시 검사하게 했습니다. “파일 존재” 조건 덕에 실물이 있는 초안만 봅니다. 회귀 테스트 4건을 더해 테스트가 14건에서 18건 통과가 됐고, 첫 실행에서 2편을 회수해 발행했습니다. 라이브 목록은 19편에서 21편이 됐습니다.

대가도 있습니다. 회수한 글이 하루 발행 상한 5편을 먹습니다. 의도한 일입니다. 회수는 추가 발행이 아니라 늦은 발행이기 때문입니다.

같은 밤에 함께 찾은 사고 둘은 무엇이었나?

독자 검사를 만드는 동안 글 쓰는 파이프라인 아래쪽에서 사고 둘이 같이 드러났습니다. 글의 원인과는 무관하지만 같은 파이프라인에서 나왔고, 둘 다 조용히 실패했다는 점이 같았습니다.

첫째는 AI 호출 잔액 소진입니다. 크론(정해진 시각에 명령을 돌리는 예약 작업)이 AI를 부를 때 거치는 중계 스크립트(cron-gateway.sh)가 저렴한 외부 모델 DeepSeek의 계정을 쓰고 있었는데, 9월 1일 07:15부터 `API Error: 402 Insufficient Balance`로 전부 실패했습니다. 오류를 찍고 매달려 있다가 시간 초과로 끝났습니다. 이 문자열은 표준 출력으로 나왔고, 크론 로그는 표준 오류만 남기게 짜여 있어 어느 로그에도 없었습니다. 크론 건강 검사는 Traceback만 봤습니다. 영향받은 크론은 27개였습니다.

조치는 둘입니다. 로그가 아니라 직접 질의해 잔액을 재는 감시 항목을 새로 만들었고, 기술블로그를 쓰는 일은 Max 구독 경로로 옮겨 새벽 02:20에 돌리게 했습니다. 글은 상품이라 모델을 싸구려로 바꾸지 않았고, 밤에는 낮 작업과 쿼터를 두고 다투지 않기 때문입니다. 이 사고의 이후 이야기는 DeepSeek 402 오류 글에 있습니다.

둘째는 크론 설정 전체가 1분 동안 사라진 일입니다. `crontab -l | sed … | crontab -` 한 줄에서 sed가 구분자 `#`와 내용이 부딪혀 실패했는데, 파이프라인은 빈 입력을 그대로 `crontab -`에 넘겼고 166개 작업이 0개가 됐습니다. 직전에 떠 둔 백업으로 바로 복원했습니다. 규칙은 하나로 줄였습니다. crontab은 파일에 쓰고 검증한 뒤 `crontab <file>`로 등록하고, 파이프는 쓰지 않습니다.

남는 한계는 무엇인가?

첫째, 새 검사는 “그 말이 제목에 있는가”만 봅니다. 제목에 기술명이 들어 있어도, 그 제목이 독자가 실제로 궁금해할 문제를 말하는지는 재지 못합니다. 기계가 못 재는 부분은 여전히 사람이 읽어야 합니다.

둘째, 통과율이 얼마나 떨어졌는지는 이 글에 없습니다. 기록에는 “떨어질 것이고 그건 의도다”라는 예상만 남아 있고 측정값은 없습니다. 예상이 맞았는지는 따로 재야 합니다.

셋째, 이번 지적도 사람이 글을 읽은 뒤에야 나왔습니다. 검사는 만든 쪽이 떠올린 결함만 보기 때문에, 다음 빈칸도 검사기가 아니라 독자가 먼저 찾을 가능성이 큽니다. 그래서 완료를 보고하기 전에 원문 요구사항을 항목별로 다시 대조하는 절차를 같이 두었습니다.

정리하면, 검사 8항목은 독자 없는 글을 통과시키고 있었고, 반대로 멀쩡한 글을 조사 하나 때문에 버리기도 했습니다. 자동 글쓰기 파이프라인을 직접 운영하며 같은 빈칸을 의심하고 계시다면 상담에서 함께 살펴볼 수 있습니다.