작은 자동화가 일을 더 늘리는 순간

작은 자동화는 일을 줄여줄 것처럼 보입니다. 버튼 하나, 스크립트 하나, 규칙 하나를 만들면 반복 작업이 사라질 것 같습니다.

그런데 실제로는 자동화가 일을 더 늘릴 때도 있었습니다. Daejin Lab에서도 확인 스크립트를 만들고, 결과를 해석하고, 다시 예외를 처리하다 보니 원래 일보다 커지는 순간이 있었습니다.

자동화가 일을 늘리는 패턴

작은 자동화가 실패하는 가장 흔한 패턴은 확인할 대상보다 자동화 자체가 더 복잡해지는 경우입니다.

스크립트가 하는 일을 이해해야 한다.
실패했을 때 로그를 다시 해석해야 한다.
예외 상황을 계속 추가해야 한다.
자동화 결과가 맞는지 사람이 다시 확인해야 한다.

예를 들어 sitemap 상태가 Search Console에서 가져올 수 없음으로 보인다고 해서, sitemap 파일을 계속 다른 형식으로 생성하는 스크립트를 만들면 일이 커집니다. 실제로는 공개 URL이 200이고 XML 파싱이 되면 기다리는 것이 맞을 수 있습니다.

자동화하기 전에 보는 질문

그래서 자동화를 만들기 전에 아래 질문을 먼저 봅니다.

이 작업은 일주일에 몇 번 반복되는가?
실패했을 때 피해가 큰가?
결과를 명령어로 검증할 수 있는가?
수동으로 하면 5분 안에 끝나는가?
다른 블로그에도 그대로 재사용할 수 있는가?

수동으로 3분 걸리는 일을 자동화하느라 1시간을 쓰면 당장은 손해입니다. 다만 앞으로 5개 블로그에서 매주 반복될 일이라면 그때는 스크립트로 바꿀 가치가 있습니다.

Daejin Lab에서 자동화한 것과 남긴 것

이번 블로그 작업에서는 자동화할 일과 사람이 볼 일을 나눴습니다.

자동화하기 좋은 것:
- 글 개수 세기
- 카테고리별 분포 확인
- 짧은 글 후보 찾기
- npm run build 실행
- sitemap URL 수 확인

사람이 볼 것:
- 글이 실제 경험처럼 읽히는지
- Search Console 화면을 어떻게 해석할지
- AdSense 신청 시점을 언제로 잡을지
- git push와 배포를 지금 할지

이 구분을 해두니 자동화가 목적이 아니라 운영 보조가 됩니다. 특히 AdSense 준비 단계에서는 글의 신뢰감이 중요하기 때문에, 스크립트 결과만 보고 “준비 완료”라고 말하면 위험합니다.

자동화를 미뤄도 되는 경우

아래 조건이면 자동화를 바로 만들지 않아도 됩니다.

작업이 아직 한두 번밖에 반복되지 않았다.
절차가 계속 바뀌고 있다.
외부 서비스 처리 지연이 원인일 수 있다.
실패했을 때 사람이 판단해야 한다.

Search Console sitemap 문제도 여기에 가까웠습니다. 사이트 파일을 더 고치기보다, 공개 URL과 Googlebot 유사 요청이 정상인지 확인한 뒤 기다리는 쪽이 더 안전했습니다.

이번 보강에서 자동화를 줄인 부분

이번 글 보강에서도 일부러 자동화하지 않은 부분이 있습니다. 짧은 글 후보는 스크립트로 뽑았지만, 본문을 한꺼번에 만들어 바로 발행하지는 않았습니다. 대신 5개만 골라 실제 운영에서 확인한 숫자, 멈춘 경계, 내부 링크를 사람이 읽을 수 있는 문장으로 보강했습니다.

자동화한 것: 후보 추출, 글 수 집계, 빌드, 정적 검증
자동화하지 않은 것: 최종 발행 판단, 외부 콘솔 조작, AdSense 신청

이렇게 나누면 자동화가 일을 대신 벌이지 않습니다. 특히 검색 콘솔이나 애드센스처럼 외부 서비스가 끼면, 화면 상태 하나만 보고 파일을 계속 바꾸는 자동화는 위험합니다. 관련 기준은 Search Console 색인 요청 일일 할당량 초과 후 한 일과 발행 버튼을 자동화하지 않기로 한 이유에서도 같은 방향으로 잡았습니다.

자동화보다 먼저 둘 중단선

개인 프로젝트에서 자동화는 작게 시작하는 편이 낫습니다. 처음부터 완전 자동 운영을 목표로 잡으면, 도구를 돌보기 위해 또 다른 도구가 필요해집니다.

Daejin Lab에서는 앞으로도 아래 순서로 자동화를 붙일 생각입니다.

1. 사람이 반복해서 확인한다.
2. 반복 항목을 체크리스트로 만든다.
3. 명령어로 검증 가능한 것만 스크립트로 바꾼다.
4. 실패하면 사람이 해석한다.
5. 여러 블로그에 반복될 때만 공통 도구로 만든다.

자동화의 목적은 일을 없애는 것이 아니라, 사람이 판단해야 할 시간과 체력을 남기는 것입니다. 그래서 Daejin Lab의 기본 원칙은 “반복 확인은 자동화하되, 공개·계정·결제·신청 버튼은 사람이 누른다”입니다.

자동화 보류 기준표

이번 사이트 점검에서 가장 조심한 부분은 sitemap을 계속 바꾸지 않는 일이었습니다. 공개 URL이 정상인데 Search Console만 늦게 반응할 때는 자동 수정이 오히려 문제를 키울 수 있습니다.

상황	자동화해도 되는 것	보류한 것
sitemap 상태 확인	HTTP 200, XML 파싱, URL 수 확인	GSC 상태만 보고 파일 형식 계속 변경
글 품질 점검	내부 링크 수, description 길이 추출	글 내용을 한꺼번에 발행
배포 확인	대표 URL의 새 문구 확인	외부 콘솔 조작 자동화
폴더 정리	dry-run 리포트 생성	원본 파일 자동 삭제

그래서 Search Console 문제는 robots.txt와 canonical을 점검하며 확인한 색인 기본 조건과 사이트맵이 정상인데 Search Console은 실패할 때 다음에 한 일처럼 파일과 콘솔 상태를 분리해서 봤습니다.

자동화 전에 멈춰볼 질문

자동화는 반복이 충분히 쌓였을 때 가치가 있었습니다. 한두 번 할 일을 자동화하면, 스크립트 관리가 더 큰 일이 될 수 있습니다.

다음에는 자동화하기 전에 세 가지를 보려고 합니다. 자주 반복되는지, 실패했을 때 수습이 쉬운지, 사람이 판단해야 하는 부분이 섞여 있지 않은지입니다. 셋 중 하나라도 애매하면 손으로 하는 편이 나을 때도 있습니다.

작은 자동화일수록 더 쉽게 방심했습니다. 다음에 스크립트를 하나 더 붙이기 전에는 로그, 되돌리기, 사람이 확인할 지점을 먼저 적어둘 생각입니다.

2026-05-31에 다시 본 자동화의 비용

AdSense 재검토를 준비하면서 가장 크게 느낀 것은 자동화가 많다고 사이트 품질이 좋아지는 것은 아니라는 점이었습니다. 글을 고르는 스크립트는 도움이 됐지만, 글의 마지막 문장과 공개 판단까지 자동화하면 오히려 위험이 커집니다. 이 글은 자동화 예찬이 아니라 자동화 보류 기준을 설명하는 글이어야 했습니다.

반복 여부, 되돌림 가능성, 출력 검증, 보류 판단을 보는 작은 자동화 비용 체크 카드

이 카드는 자동화하기 전에 보는 네 가지 질문입니다. 반복 작업처럼 보여도 예외가 많으면 수동으로 남기는 편이 낫습니다.

이번 보강에서 자동화한 것은 숫자와 후보 추출입니다. 자동화하지 않은 것은 공개 판단, 계정 콘솔 조작, AdSense 재검토 요청입니다. 이 선이 없으면 작업은 빨라질 수 있어도 사고가 커집니다. 작은 자동화는 “내가 덜 생각해도 되는 장치”가 아니라 “반복 확인을 줄여서 더 중요한 판단을 하게 해주는 장치”여야 했습니다.

참고한 공식 문서

Python 문서는 반복 파일 점검의 기본, GitHub 문서는 비밀값 노출 위험, Google 문서는 콘텐츠 품질의 방향을 확인하는 데 봅니다. 자동화는 이 기준을 통과할 때만 남깁니다.

확인하지 않은 것

이 글은 모든 자동화를 줄이라는 뜻이 아닙니다. 반복 횟수, 실패 비용, 복구 방법, 로그 확인 방식이 준비된 자동화는 여전히 쓸 수 있습니다. 다만 공개와 계정 조작처럼 되돌리기 어려운 작업은 보수적으로 남깁니다.

FAQ

자동화가 일을 늘리는 가장 흔한 순간은 언제인가요?

예외 처리가 자동화 자체보다 커질 때입니다. 한두 번 수동으로 끝날 일을 스크립트 유지보수로 바꾸면 일이 늘어납니다.

그래도 자동화해야 하는 일은 무엇인가요?

글 수, 링크 수, 이미지 누락, 빌드 성공 여부처럼 반복 확인이 가능하고 실패해도 되돌릴 수 있는 일입니다.

애드센스 대응에서 자동화한 부분은 무엇인가요?

약한 글 후보 추출, secret scan, build, sitemap/RSS 확인입니다. 재검토 요청 같은 계정 조작은 자동화하지 않았습니다.