재심사 대기 중 파이프라인 코드를 처음부터 다시 읽었다 — 36편 발행 이력이 보여준 패턴

📚 이 글은 “개발자가 AI 자동화로 부업하는 실전 기록” 시리즈입니다.

36편: 애드센스 재심사 신청 완료

재심사 버튼을 누른 게 이틀 전이다.

솔직히 말하면, 눌러놓고 나서 할 게 없어졌다. 지금은 그냥 기다리는 상황이다. 구글 애드센스 재심사는 며칠이 걸릴 수도 있고 몇 주가 걸릴 수도 있다고 한다. 2주라는 사람도 있고, 운 좋으면 3일만에 나왔다는 사람도 있다. 어차피 내가 통제할 수 있는 게 아니다.

그래서 뭘 했냐면, 이 저장소의 코드를 처음부터 다시 읽었다. 개발자가 기다릴 때 코드를 읽는 건 뭔가 자연스러운 행동 같기도 하고, 사실은 그냥 불안해서 뭔가를 해야 할 것 같아서이기도 하다. 어쨌든 그 과정에서 몇 가지 흥미로운 걸 발견했다.


기다리는 동안 개발자답게 할 수 있는 것들

재심사를 신청하고 나면 선택지가 별로 없다. 새 글을 계속 쓰거나, 기존 글을 개선하거나, 아니면 그냥 기다리거나. 나는 셋 다 하기로 했다.

일단 새 글 발행은 계속한다. 그게 바로 지금 이 글이다. 애드센스 심사 중에도 글을 쓰는 게 오히려 좋다는 이야기를 들었다. 콘텐츠가 늘어나면 나쁠 게 없으니까. 물론 품질을 지키면서.

두 번째로 한 건 파이프라인 코드 정독이다. src/publish_draft.py를 열어서 처음부터 끝까지 다시 읽었다. 만든 지 얼마 안 됐지만, 만들 때는 “일단 돌아가게”에 집중했기 때문에 나중에 보면 눈에 띄는 것들이 생긴다.

세 번째는 published.json 데이터 분석이다. 36편이 쌓인 발행 이력을 보면 패턴이 보인다. 언제 많이 썼고 언제 띄어서 썼는지, 어떤 카테고리에 치우쳤는지.

재심사 대기는 통제 불가 영역이다. 그 시간을 어떻게 쓰느냐는 내가 정할 수 있다.


publish_draft.py 코드를 다시 읽으며 발견한 것들

이 파일은 Claude Code 자동화 파이프라인의 핵심이다. GitHub Actions가 매일 Claude Code를 실행하면, Claude Code가 글을 작성하고, 이 스크립트가 WordPress 발행 → published.json 갱신 → Notion 기록 → Threads 포스팅을 순서대로 처리한다.

코드를 다시 읽으면서 가장 눈에 들어온 건 중복 발행 방지 로직이다.

⚙️ 참고: 아래는 src/publish_draft.py의 실제 코드입니다. episode 번호를 기준으로 중복을 막습니다.

published = load_published()
if any(p["ep"] == episode for p in published):
    raise SystemExit(f"이미 발행된 에피소드입니다: {episode}편 (published.json 확인)")

단순하다. published.json을 불러와서 ep 번호가 겹치면 그냥 종료한다. 처음 짤 때는 당연한 거라 별로 신경 안 썼는데, 지금 보니 이 한 줄이 꽤 중요하다. GitHub Actions가 하루에 두 번 실행되는 상황이 오더라도 두 번째는 자동으로 막힌다.

두 번째로 눈에 들어온 건 에러 처리 패턴이다. Notion 기록이 실패하거나 Threads 포스팅이 실패해도 발행은 유지된다. 코드는 이렇게 처리하고 있다.

try:
    result["notion"] = log_to_dashboard(...)
    print("      완료")
except Exception as e:
    result["errors"].append(f"Notion 기록 실패: {e}")
    print(f"      실패 (발행은 성공): {e}")

이 패턴을 Threads 포스팅에도 똑같이 적용했다. 발행이라는 핵심 기능이 Notion이나 Threads 같은 부가 기능의 실패로 중단되면 안 된다는 판단이었다. 당시엔 그냥 짠 건데, 다시 보니 꽤 맞는 설계였다.

실제로 Threads 포스팅은 지금까지 몇 번 실패했다. 토큰이 만료됐을 때 그랬고, API 응답이 느릴 때도 그랬다. 그때마다 블로그 발행은 정상적으로 됐다. 에러 메시지만 출력됐을 뿐.

한 가지 개선 여지가 보인 건 plain_len 검사 방식이다. 현재는 HTML 전체 텍스트에서 공백 제거 후 길이를 재는데, 이 방식은 태그 안의 속성값이나 링크 URL까지 포함된다. 나중에 실제 텍스트만 추출해서 재는 방식으로 바꾸면 더 정확할 것 같다.

만들 때는 “일단 돌아가게” 짰지만, 돌아가고 나서 다시 읽으면 고칠 곳이 보인다.


36편 발행 이력 데이터가 보여준 패턴

published.json에는 36편의 발행 이력이 쌓여 있다. 초기 ep1~ep23은 날짜 필드가 없다. GitHub Actions 파이프라인으로 전환하기 전에 직접 발행했기 때문이다. 날짜 기록이 시작된 건 ep24부터다.

ep24(2026-07-09)부터 ep36(2026-07-29)까지 21일간 13편이 발행됐다. 날짜별로 보면 이렇다.

기간 발행 편수 발행 간격 해당 에피소드
07-09 ~ 07-13 (5일) 5편 매일 1편 ep24~ep28
07-15 ~ 07-29 (15일) 8편 평균 1.9일/편 ep29~ep36

초반 5일은 매일 1편씩 연속으로 나왔다. ep24~ep28이다. 그 이후로는 격일, 혹은 더 긴 간격이 됐다. ep34에서 ep35 사이는 사흘(07-24 → 07-27), ep35에서 ep36 사이도 이틀(07-27 → 07-29)이 걸렸다.

이게 나쁜 신호냐면 그건 아니다. 오히려 ep33 이후의 글들이 이전보다 훨씬 내용이 많고 실측 근거도 잘 들어가 있다. 발행 간격이 벌어진 건 글을 더 꼼꼼히 쓰고 있어서다. 애드센스 탈락 이후 품질 기준이 높아졌고, Claude Code도 그 기준에 맞게 더 길게 쓰고 있다.

카테고리 분포도 흥미롭다. topics.json 기준으로 전체 36편을 분류하면 개발 실전 기록이 20편으로 가장 많고, AI 자동화 부업이 8편, 수익화 전략이 7편이다. 나머지 1편은 PLM 마이그레이션 카테고리다. 개발 실전 기록이 압도적으로 많은 건 애드센스 탈락 이후 기술 구현 과정을 더 자세히 쓰게 됐기 때문이다.

💡 팁: published.json에 date 필드를 붙인 건 ep24부터다. 초기 글들에 날짜가 없는 건 파이프라인 전환 시점의 흔적이다. 나중에 소급해서 채우면 발행 패턴 분석이 더 쉬워질 것 같다.

36편을 쌓는 데 실제로 얼마나 걸렸는지도 계산해봤다. 정확한 시작일은 ep1 발행 시점인데 그건 기록이 없다. 하지만 ep24가 2026-07-09이고 ep1부터 ep23까지 23편을 먼저 썼다는 걸 감안하면, 전체 흐름은 꽤 빠른 편이다.

21일간 13편. 평균 발행 간격 1.6일. 자동화 파이프라인이 없었다면 불가능한 속도다.


재심사 결과 전에 더 해볼 것들

재심사가 어느 방향으로 나오든 일단 할 수 있는 건 계속한다. 지금 당장 할 수 있는 것들이 있기 때문이다.

첫 번째는 글 발행을 이어가는 것이다. 지금 하고 있는 것처럼. 재심사 대기 중에도 새 콘텐츠가 쌓이면 좋다. 어차피 애드센스 승인이 나더라도 글은 계속 써야 한다. 멈출 이유가 없다.

두 번째는 검색 유입 패턴을 보는 것이다. 구글 서치콘솔에서 어떤 키워드로 어떤 글에 사람들이 들어오는지 보면 다음 글 주제를 정하는 데 도움이 된다. 자동화로 쓴 글이지만 검색 결과에서는 제각각 반응이 다르다. 클릭률이 높은 글의 패턴을 파악하면 남은 발행 계획을 조정할 수 있다.

세 번째는 파이프라인 개선이다. 위에서 언급한 plain_len 계산 방식이나, 발행 후 검증 로직 같은 부분을 정리할 수 있다. 지금 당장 급한 건 아니지만, 재심사 결과가 나와서 다음 단계로 넘어가기 전에 파이프라인을 깔끔하게 다듬어 두면 좋다.

재심사 결과가 승인이면 당연히 광고를 붙이고 수익 추적을 시작한다. 탈락이면 피드백을 보고 다시 뜯어보는 과정을 반복할 것이다. 어느 쪽이든 멈추진 않는다. 이게 자동화 파이프라인을 만든 이유다. 결과와 상관없이 발행은 계속된다.

파이프라인이 돌아가는 동안 나는 다른 걸 할 수 있다. 기다리는 것도 그 중 하나다.


솔직히 말하면, 기다리는 게 제일 어렵다

코드를 짜거나 글을 쓰는 건 뭔가 하고 있다는 느낌이 있다. 근데 기다리는 건 그게 없다. 재심사 결과가 언제 나올지 알 수 없고, 좋게 나올지 나쁘게 나올지도 모른다. 그 불확실성이 은근히 신경 쓰인다.

그래서 오늘 한 일이 publish_draft.py 코드 정독이고, 36편 발행 데이터 분석이고, 이 글을 쓰는 것이다. 할 수 있는 걸 하면서 기다리는 것밖에 없다.

돌이켜보면 이 프로젝트에서 기다림은 계속 있었다. 처음에 WordPress 세팅하고 글을 올릴 때도 검색 노출이 언제 될지 기다렸다. 애드센스 첫 신청 후에도 기다렸다. 탈락 판정 받고 어떻게 고칠지 고민하면서도 기다렸다. 이번 재심사도 그 연장선이다.

결과가 언제 나올진 모르지만, 나오면 바로 여기 올릴 것이다. 그게 38편이 될 것 같다.

📌 다음 편: 애드센스 재심사 결과 공개

  • 재심사 결과 — 승인인지 탈락인지
  • 심사 기간이 얼마나 걸렸는지
  • 결과에 따른 다음 계획

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top