Blogger 글 발행 자동화에서 가장 위험한 실패는 글이 생성되지 않는 것이 아니라, 깨진 글이 정상 글처럼 공개되는 것이다. 이번 기록은 마크다운 잔재, 빈 본문, 깨진 HTML, 위험하게 보이는 예시 코드를 발행 직전에 차단하기 위해 만든 자동 QC 점검 구조를 정리한 것이다.
이 글은 기존에 발행되어 있던 자동 QC 글을 다시 정리한 버전이다. 기존 글에는 본문 안에 위험하게 보일 수 있는 스크립트 예시 문자열, 과장된 검증 수치, 현재 사이트 방향과 맞지 않는 오래된 문구가 섞여 있었다. 그래서 새 글은 실제 운영 관점에서 확인 가능한 문제와 재사용 가능한 점검 로직만 남기는 방식으로 다시 구성했다.
목차
문제 상황
ToolSignal Pro는 한국어 AI 코딩, 자동화, Blogger 트러블슈팅 기록을 계속 누적하는 사이트다. 글을 여러 편 발행하다 보면 문제는 글을 쓰는 속도보다 발행 전 검수 단계에서 생긴다. 특히 AI로 초안을 만들고 Blogger HTML 편집기에 붙여넣는 과정에서는 문서가 겉보기에는 정상처럼 보이지만, 실제 HTML 내부에는 깨진 구조가 남는 경우가 있다.
대표적인 문제는 세 가지였다. 첫째, 마크다운 문법이 HTML로 변환되지 않은 채 본문에 남는 문제다. 둘째, 코드 예시 안에 들어가야 할 문자열이 실제 태그처럼 해석될 수 있는 문제다. 셋째, 제목과 본문, 목차, 내부링크가 서로 맞지 않아 검색엔진과 독자 모두에게 불완전한 문서처럼 보이는 문제다.
이런 문제는 글 하나만 보면 작은 실수처럼 보인다. 그러나 블로그 운영에서는 반복성이 더 중요하다. 같은 실수가 여러 글에 반복되면 사이트 전체가 정리되지 않은 자동 생성물처럼 보일 수 있다. 그래서 발행 직전 단계에서 기계적으로 잡을 수 있는 오류는 자동 QC로 걸러내야 했다.
에러 증상
기존 QC 글에서 가장 먼저 보였던 문제는 안전하지 않은 예시 문자열이었다. 본문에는 코드 설명을 위한 예시가 있었지만, 일부 문자열이 실제 HTML 태그처럼 보일 수 있는 형태로 남아 있었다. 특히 스크립트 태그 예시는 보안 필터, 브라우저 확장 프로그램, 검색엔진의 안전성 판단에서 불필요한 오해를 만들 수 있다.
코드 예시는 설명을 위한 자료일 뿐 실제 실행 대상이 아니어야 한다. 따라서 아래처럼 원문 태그 모양을 그대로 노출하는 방식은 피하는 편이 안전하다.
나쁜 예:
<script>alert('test');</script>위 예시는 실제 실행되도록 삽입한 것이 아니더라도, 글 주소를 열었을 때 특정 환경에서 위험 문자열로 감지될 수 있다. 블로그 글에서는 보안 공격을 설명하는 글이 아니라면 이런 예시를 굳이 노출할 필요가 없다. 필요하다면 반드시 이스케이프된 코드 블록 안에서만 제한적으로 사용해야 한다.
또 다른 증상은 문서의 결이 현재 사이트 방향과 맞지 않는 것이었다. 예전 글에는 현재 한국어 AI 오류 해결 아카이브와 어울리지 않는 표현이 일부 남아 있었다. 글 하나의 문제라기보다 사이트 정체성이 바뀐 뒤 오래된 문구가 정리되지 않은 상태에 가까웠다.
환경
점검 대상 환경은 Blogger 기반 사이트다. 본문은 Blogger HTML 편집기에 직접 입력되며, 게시글은 한국어 기술 기록으로 발행된다. 사이트의 현재 방향은 AI 코딩, 자동화, Blogger 오류 해결, 실제 운영 중 발생한 오류 로그의 기록이다.
이 환경에서는 별도의 서버 렌더링이나 빌드 파이프라인이 없다. 따라서 발행 전 본문 HTML 자체가 최종 산출물에 가깝다. 일반적인 정적 사이트 생성기라면 빌드 단계에서 HTML lint, markdown transform, link checker를 적용할 수 있지만, Blogger에서는 사용자가 붙여넣은 HTML과 테마가 바로 라이브 페이지의 품질을 결정한다.
그래서 Blogger 운영자는 두 가지를 분리해서 봐야 한다. 하나는 테마 XML의 품질이고, 다른 하나는 개별 게시글 본문의 품질이다. 테마가 정상이어도 본문에 깨진 HTML이 들어가면 페이지 품질은 나빠진다. 반대로 본문이 좋아도 테마의 네비게이션이나 메타 구조가 깨지면 사용자 경험이 나빠진다.
시도했지만 실패한 방법
처음에는 글을 발행한 뒤 눈으로 확인하는 방식이면 충분하다고 생각하기 쉽다. 하지만 육안 검수는 반복 작업에 약하다. 제목, 목차, 본문, 내부링크, 코드 블록, 라벨, 검색 설명을 매번 확인하다 보면 어느 한 항목은 빠지기 쉽다.
또 하나의 실패한 방식은 AI에게 “SEO에 맞게 잘 써줘”라고만 요청하는 방식이다. 이 요청은 너무 넓다. 글의 문장은 매끄러워질 수 있지만, 실제 발행 품질을 결정하는 항목인 HTML 태그, 목차 앵커, 내부링크, 코드 이스케이프, 라벨 정합성까지 안정적으로 보장하지 못한다.
마지막으로 위험했던 방식은 정규식 하나로 모든 HTML 문제를 고치려는 접근이었다. 정규식은 간단한 문자열 정리에는 유용하지만, HTML 전체 구조를 이해하는 도구는 아니다. 특히 닫히지 않은 태그, 중첩된 코드 블록, 속성 내부의 특수문자까지 모두 정규식으로 처리하려고 하면 오히려 본문을 더 망가뜨릴 수 있다.
오류가 난 원인
핵심 원인은 발행 전 점검 항목이 명시적으로 정의되어 있지 않았다는 점이다. 좋은 글인지 아닌지를 감으로 판단하면, 어떤 날은 목차를 넣고 어떤 날은 내부링크를 빼먹는다. 어떤 글은 코드 블록을 안전하게 이스케이프하지만, 어떤 글은 예시 문자열이 그대로 남는다.
기술적으로는 세 가지 계층이 섞여 있었다. 첫째, 원고 생성 계층이다. 여기서는 마크다운 문법이나 초안용 문장이 남을 수 있다. 둘째, HTML 변환 계층이다. 여기서는 <h2>, <p>, <pre>, <code> 같은 태그 구조가 정리되어야 한다. 셋째, Blogger 발행 계층이다. 여기서는 제목, 검색 설명, 라벨, URL, 내부링크가 최종 확인되어야 한다.
이 세 계층을 한 번에 처리하지 않으면 오류는 어딘가에 남는다. 특히 코드 예시는 별도 규칙으로 다뤄야 한다. 코드 블록 안에서는 태그를 설명할 수 있지만, 그 태그가 실제 HTML로 해석되지 않도록 문자 이스케이프가 필요하다.
최종 해결
최종 해결은 발행 전 QC를 하나의 체크리스트이자 작은 검사 함수로 분리하는 방식이었다. 글을 쓰는 단계와 글을 검사하는 단계를 분리하면, 문장 품질과 구조 품질을 따로 볼 수 있다. 이 방식은 완전한 자동화보다 안정적이다. 자동 수정할 수 있는 것은 수정하고, 판단이 필요한 항목은 발행 전 보류로 남기기 때문이다.
점검 기준은 다음처럼 정리했다.
- 본문이 지나치게 짧지 않은지 확인한다.
**굵게**,## 제목같은 마크다운 잔재가 남아 있는지 확인한다.<script>처럼 위험하게 보일 수 있는 예시 문자열이 실제 태그로 해석되지 않는지 확인한다.- 목차와 본문 H2 앵커가 서로 맞는지 확인한다.
- 내부링크가 실제 존재하는 ToolSignal Pro 글로 연결되는지 확인한다.
- 현재 사이트 방향과 맞지 않는 오래된 문구가 남아 있는지 확인한다.
중요한 점은 자동 QC가 글을 대신 판단하지 않는다는 것이다. 자동 QC는 발행하면 안 되는 명백한 오류를 알려주는 장치다. 글의 최종 발행 여부는 운영자가 실제 맥락과 근거를 확인한 뒤 결정해야 한다.
사용한 코드
아래 코드는 Blogger 글 발행 전 HTML 조각을 검사하는 최소 예시다. 실제 운영에서는 이 코드를 그대로 붙여넣기보다, 자신의 글 구조와 라벨 기준에 맞게 항목을 조정하는 편이 안전하다.
import re
from html import escape
def inspect_blogger_html(html: str) -> list[str]:
issues = []
text_only = re.sub(r"<[^>]+>", "", html)
compact_text = re.sub(r"\s+", "", text_only)
if len(compact_text) < 1200:
issues.append("본문 길이가 짧습니다. 단순 공지인지 실무 기록인지 확인하세요.")
if re.search(r"(^|\n)#{1,6}\s+", html):
issues.append("마크다운 제목 문법이 HTML로 변환되지 않았습니다.")
if "**" in html:
issues.append("마크다운 굵게 표시 잔재가 남아 있습니다.")
if "<h2" not in html.lower():
issues.append("H2 구조가 없습니다. 목차형 글이라면 섹션 구조를 추가하세요.")
if "href=\"#toc\"" not in html and "목차" in html:
issues.append("목차 또는 앵커 링크 정합성을 확인하세요.")
risky_patterns = [
"<script>",
"</script>",
"javascript:",
"onerror=",
"onclick="
]
lowered = html.lower()
for pattern in risky_patterns:
if pattern in lowered:
issues.append(f"위험하게 보일 수 있는 문자열 확인 필요: {pattern}")
old_positioning = [
"old-english-review",
"old-builder-a",
"old-builder-b",
"old-builder-c",
"old-builder-topic"
]
for word in old_positioning:
if word in lowered:
issues.append(f"현재 사이트 방향과 맞지 않을 수 있는 잔재 확인: {word}")
return issues
def safe_code_example(raw: str) -> str:
return "<pre><code>" + escape(raw) + "</code></pre>"이 코드의 목적은 모든 문제를 자동으로 고치는 것이 아니다. 문제가 될 수 있는 항목을 빠르게 드러내는 것이다. 특히 위험 문자열은 실제 공격 코드가 아니어도 발행 전에 문맥을 확인해야 한다. 설명용 코드라면 반드시 escape를 거쳐 코드 블록 안에 넣는 편이 안전하다.
검증 결과
수정 후 점검 기준은 명확해졌다. 본문은 한국어 운영 기록 중심으로 정리하고, 오래된 포지셔닝 문구는 제거했다. 위험하게 보일 수 있는 예시 문자열은 실제 태그가 아니라 이스케이프된 코드로만 남겼다. 제목도 과장된 수치보다 문제 해결 의도가 드러나는 방식으로 바꿨다.
또한 목차와 본문 구조를 맞췄다. 단순히 H2를 나열하는 것이 아니라, 기존 ToolSignal Pro 글에서 쓰는 흐름인 문제 상황, 에러 증상, 환경, 실패한 방법, 원인, 최종 해결, 코드, 검증 결과, 조언, 관련 기록 구조를 따랐다. 이 구조는 독자가 같은 문제를 겪었을 때 바로 확인할 수 있는 순서를 제공한다.
다만 이 글은 자동 QC 시스템의 개념과 최소 구현을 설명하는 기록이다. 실제 운영에서 완전한 자동 발행 파이프라인을 보장한다는 의미는 아니다. 발행 전 최종 판단은 여전히 운영자의 확인이 필요하다.
같은 문제 겪는 분들에게
Blogger에서 글을 많이 발행한다면, 먼저 자동화보다 체크리스트를 만드는 것이 좋다. 자동화는 기준이 명확할 때만 도움이 된다. 기준이 없는 상태에서 자동화하면 깨진 글을 더 빠르게 많이 발행하게 된다.
특히 다음 항목은 발행 전 반드시 확인하는 편이 안전하다.
- 제목이 파일명처럼 보이지 않는가?
- 검색 설명이 본문과 정확히 맞는가?
- 목차 링크가 실제 H2 위치로 이동하는가?
- 코드 블록 안의 HTML 예시가 이스케이프되어 있는가?
- 현재 사이트 주제와 맞지 않는 오래된 문구가 남아 있지 않은가?
- 내부링크가 삭제된 글이나 빈 라벨 페이지로 가지 않는가?
이 기준을 통과하지 못한 글은 바로 발행하지 않는 편이 낫다. 글 하나를 늦게 발행하는 것보다, 깨진 글 하나가 사이트 전체의 신뢰도를 흐리는 것이 더 큰 문제다.
관련 ToolSignal 기록
같은 아카이브의 다른 운영 기록입니다. Blogger 자동화와 색인 복구 흐름을 함께 보면 발행 전 QC의 필요성을 더 쉽게 이해할 수 있습니다.
- 구글 색인 누락 200% 극복! 5종 자동화 소스코드 파일 및 파이썬 확장 활용 팁
- Blogger API 호출 시 자동 발행 GUARD로 인한 DRAFT 잔재 사고 해결
- Blogger XML Playwright 9222 CDP 자동 업로드 문제 해결 기록
현재 상태는 기존 글의 위험 표현과 오래된 문구를 제거하고, Blogger 발행 전 QC라는 실제 운영 문제로 다시 정리한 상태다. 이 글의 목적은 완벽한 자동 발행을 주장하는 것이 아니라, 발행 직전 단계에서 사람이 놓치기 쉬운 오류를 기계적으로 드러내는 기준을 남기는 것이다.