반복 작업을 Python 스크립트로 줄인 사례

반복 작업을 몇 번 하다 보면 손으로 하는 게 더 빠른 것처럼 느껴질 때가 있습니다. 한두 번이면 그렇습니다. 그런데 같은 확인을 계속 반복하면 어느 순간 실수가 납니다.

Daejin Lab에서도 글 수, sitemap URL 수, 내부 링크 상태처럼 반복해서 봐야 하는 값들이 있었습니다. 이럴 때 Python 스크립트는 멋진 자동화라기보다, 제가 덜 빼먹게 해주는 체크 도구였습니다.

예시: 글 개수와 기본 정보 확인

Markdown 파일을 읽어서 대략적인 상태를 보는 간단한 스크립트는 이렇게 만들 수 있습니다.

from pathlib import Path

base = Path("src/content/blog")

for path in sorted(base.glob("*.md")):
    text = path.read_text(encoding="utf-8")
    body = text.split("---", 2)[-1]
    word_count = len(body.replace("
", " ").split())
    has_category = "category:" in text
    has_tags = "tags:" in text

    print(path.name, word_count, has_category, has_tags)

이 정도만 있어도 “어떤 글이 너무 짧은지”, “메타 정보가 빠진 글이 있는지”를 빠르게 볼 수 있습니다.

자동화하기 좋은 블로그 점검 항목

개인 블로그 운영에서 자동화하기 좋은 항목은 다음과 같습니다.

Markdown 글 개수 세기
draft: true 글 찾기
카테고리별 글 수 집계
본문 길이가 짧은 글 찾기
태그가 없는 글 찾기
이미지 경로 깨짐 확인
sitemap URL 개수 확인

이런 항목은 판단보다 반복 확인에 가깝습니다. 그래서 AI보다 스크립트가 더 안정적일 때도 많습니다.

자동화하면 안 좋은 부분

반대로 글의 품질 판단은 아직 사람이 봐야 합니다.

이 글이 실제 경험처럼 보이는가?
문장이 너무 AI처럼 반복되는가?
독자가 얻어갈 내용이 있는가?
AdSense 신청 전에 신뢰도가 충분한가?

스크립트는 “짧은 글”을 찾을 수는 있지만, “좋은 글”을 최종 판단하지는 못합니다.

Daejin Lab에서의 활용 방향

앞으로 글이 30개를 넘기면 간단한 점검 스크립트를 둘 계획입니다.

npm run build 전 콘텐츠 점검
카테고리별 글 수 확인
AdSense 신청 전 체크리스트 출력
Search Console 제출 URL 목록 정리

이런 자동화는 블로그 1개일 때보다 3~5개로 늘어났을 때 효과가 커집니다.

이번에 실제로 돌린 점검

이번에는 글 목록을 눈으로 세지 않고, 간단한 Python 점검으로 현재 상태를 먼저 봤습니다. 처음 30개 전후를 채울 때는 카테고리 분포를 보는 정도였고, 이후에는 AdSense 준비 관점에서 지표를 조금 더 나눴습니다.

초기 점검: 글 수, 카테고리, 태그, heroImage 유무
이번 점검: 짧은 글 수, 내부 링크 부족, 대표 이미지 누락, 공개 URL 상태
현재 보강 기준: 짧은 글 5개씩 수정한 뒤 다시 빌드

이전 점검에서는 짧은 글 후보가 23개였습니다. 반면 내부 링크 부족 글은 0개라서, 링크 구조를 새로 뜯기보다 본문 깊이를 늘리는 쪽이 우선이라고 봤습니다. 숫자를 보지 않았다면 “내부 링크도 더 넣어야 하나?”처럼 작업 범위가 쉽게 커졌을 겁니다.

스크립트가 좋은 이유는 여기 있습니다. 감으로 “글이 부족한 것 같다”고 말하는 대신, 어떤 항목이 약한지 바로 볼 수 있습니다. 자세한 연결 기준은 정적 블로그 글 20개 이후 내부 링크를 다시 설계한 방법과 공개 전 자체 점검 기준에 이어서 정리했습니다.

스크립트는 판단을 줄이는 도구가 아니다

Python 스크립트는 거창한 자동화보다 반복 확인을 줄이는 데 먼저 쓰는 편이 좋습니다.

처음 목표는 “블로그 운영을 완전 자동화하기”가 아니라, 사람이 매번 확인하던 작은 체크를 줄이는 것입니다. 이 정도만 해도 글 작성과 검수에 더 많은 시간을 쓸 수 있습니다. 다만 스크립트가 알려주는 것은 후보와 숫자일 뿐입니다. 어떤 글을 실제 경험형 문장으로 보강할지, push와 외부 콘솔 조작을 언제 할지는 여전히 사람이 정해야 합니다.

이번 점검에서 스크립트로 본 지표

반복 점검 스크립트는 “대충 괜찮아 보인다”를 숫자로 바꾸는 데 쓸모가 있었습니다. 이번 Daejin Lab 보강에서도 사람이 읽기 전에 먼저 아래 항목을 뽑아봤습니다.

점검 항목	스크립트로 볼 수 있는 것	사람이 다시 판단할 것
글 수	Markdown 파일 개수, draft 제외 여부	신청하기에 충분한 운영 기간인가
내부 링크	/blog/ 링크 개수	실제로 다음 글을 읽게 만드는 연결인가
이미지	heroImage 유무	꼭 이미지가 필요한 글인가, 표가 더 나은가
설명문	description 길이	검색 의도와 글 내용이 맞는가
빌드	npm run build 성공 여부	공개 사이트에서 반영됐는가

이 점검은 블로그 글 하단에 관련 글과 내부 링크를 넣은 이유와 Cloudflare Pages 배포 후 꼭 확인하는 체크리스트를 함께 봐야 의미가 있습니다. 숫자는 방향을 잡아주지만, 최종 판단은 실제 페이지를 열어보고 해야 했습니다.

스크립트로 넘길 일

Python 스크립트는 판단을 대신하는 도구가 아니었습니다. 반복해서 세고, 찾고, 비교하는 일을 맡기는 데 좋았습니다.

다음에도 글 품질 자체는 사람이 보되, 글 수와 URL 수, 누락 이미지, 짧은 글 후보 같은 건 스크립트로 먼저 뽑으려고 합니다. 사람이 봐야 할 시간을 남기는 게 목적입니다.

처음 한두 번은 직접 확인하는 게 빠릅니다. 문제는 같은 확인을 계속 반복할 때였습니다. 글 수, frontmatter, 링크 상태처럼 매번 보는 항목은 손보다 스크립트가 낫습니다. 대신 판단이 필요한 문장까지 스크립트에 맡기지는 않기로 했습니다.

2026-05-31에 다시 보강한 이유

AdSense 재검토를 준비하면서 이 글을 다시 보니, 가장 약한 부분은 코드 예시가 아니라 “실제로 어떤 판단을 줄였는지”였습니다. Python 스크립트 이야기는 흔합니다. 그래서 이 글은 자동화 튜토리얼보다 Daejin Lab에서 반복 점검을 어떻게 줄였는지 보여주는 글로 다시 잡았습니다.

이 카드는 실제 계정 정보나 private 경로를 쓰지 않은 공개용 흐름도입니다. 숫자는 스크립트가 뽑지만, 공개 판단은 사람이 합니다.

이번 애드센스 실패 뒤에는 같은 스크립트 기준이 더 중요해졌습니다. 감으로 “글이 얇아 보인다”고 말하면 작업 범위가 끝없이 커집니다. 반대로 글 길이, 외부 출처, 본문 이미지, FAQ 여부를 먼저 뽑으면 어디를 먼저 고칠지 보입니다. 이번 보강에서도 짧은 공개 글 5개를 먼저 고른 이유가 여기에 있습니다.

참고한 공식 문서

이 글의 코드 예시는 작은 운영 스크립트 수준이지만, 기본 동작은 공식 문서를 기준으로 확인합니다.

• Python docs — pathlib
• Python docs — argparse
• Python docs — json

공식 문서가 해결해주는 것은 문법과 표준 라이브러리 사용법입니다. Daejin Lab의 판단은 그다음입니다. 어떤 지표를 공개 글 보강에 쓸지, 어떤 값은 숫자로만 보고 멈출지는 블로그 운영 기준으로 따로 정해야 했습니다.

확인하지 않은 것

이 글은 자동 품질 평가기를 만들었다는 뜻이 아닙니다. 스크립트는 후보를 줄여줄 뿐입니다. 문장이 실제 경험처럼 읽히는지, 출처가 충분한지, 공개해도 되는 정보만 남았는지는 여전히 사람이 읽어야 합니다.

FAQ

Python 스크립트가 글 품질을 판단할 수 있나요?

아닙니다. 글 길이, 링크 수, 이미지 유무처럼 반복 확인이 가능한 값만 봅니다. “읽을 만한 글인가”는 별도 검토가 필요합니다.

왜 AI에게 전부 맡기지 않나요?

후보 추출은 AI보다 스크립트가 더 안정적인 경우가 있습니다. 반대로 문장 톤과 공개 위험은 사람이 봐야 합니다. 둘을 섞지 않는 편이 안전했습니다.

애드센스 재검토와 어떤 관련이 있나요?

“가치가 별로 없는 콘텐츠”를 줄이려면 약한 글을 감으로 고르기보다 지표로 먼저 좁혀야 합니다. 이번 글은 그 점검 방식 자체를 설명하는 대표 사례로 남겼습니다.

실제로 남길 스크립트의 기준

다음에 이 점검을 더 키운다면, 저는 먼저 CSV나 HTML 리포트처럼 사람이 바로 읽을 수 있는 출력부터 만들겠습니다. 터미널 숫자만 남기면 그 순간에는 편하지만, 며칠 뒤 다시 보면 왜 그 글을 골랐는지 흐려집니다.

그래서 반복 점검 스크립트에는 아래 기준을 붙이려고 합니다.

입력: src/content/blog의 공개 글
출력: 짧은 글, 외부 출처 없는 글, 본문 이미지 없는 글
보류: 품질 점수 자동 판정, 발행 여부 자동 변경
검증: npm run verify:publish 이후 dist에서 공개 표면 확인

이 정도면 자동화가 과해지지 않습니다. 스크립트는 “어디를 볼지”를 알려주고, 사람은 “어떻게 고칠지”를 정합니다. 이번 글도 그 경계가 보여야 한다고 봤습니다. 반복 작업을 줄인다는 말이 곧 발행 책임을 넘긴다는 뜻은 아니기 때문입니다.

이 글을 남기는 마지막 기준

이 글은 Python 문법 글이 아니라 운영 점검을 반복 가능하게 만든 기록이어야 합니다. 그래서 공개 표면에 남길 때도 “스크립트가 무엇을 대신했는가”보다 “스크립트가 어디까지 대신하지 않았는가”를 더 중요하게 봅니다. 글 수와 누락 후보는 자동으로 볼 수 있지만, 어떤 글을 고칠지와 언제 push할지는 사람이 결정합니다.

이번 보강의 목적은 자동화가 대단하다고 말하는 것이 아닙니다. 작은 점검기가 사람의 주의를 어디에 써야 하는지 알려줬다는 점을 남기는 것입니다. 이 기준이면 나중에 다른 블로그로 옮겨도 그대로 쓸 수 있습니다.

스크립트는 그래서 조용해야 합니다. 결과가 없으면 억지로 메시지를 만들지 않고, 이상한 후보가 있을 때만 사람이 볼 수 있게 보여주는 쪽이 맞습니다. 블로그 운영에서는 화려한 자동화보다 이런 작은 점검기가 더 오래 남았습니다. 이 정도 기준이면 나중에 다른 블로그로 옮겨도 그대로 쓸 수 있습니다.