매일 18시에 발행 버튼을 누르지 않는다: 32일 연속 기술블로그 발행 파이프라인 회고기

# 매일 18시에 발행 버튼을 누르지 않는다: 32일 연속 기술블로그 발행 파이프라인 회고기

매일 18:00 KST에 기술블로그를 발행하고 get→list→공개 확인(sitemap.xml·/blog 서버 HTML·상세 200)으로 닫는 루틴을 31일째 돌렸다. 어제는 발행 시각(트리거 UTC와 publishedAt KST 18:00 고정)의 혼동을 다뤘다. 오늘은 32번째 글에서 한 걸음 물러선다. 매일 버튼을 누르지 않고도 매일 발행이 되는 구조는 무엇인가. 31편의 실측이 남긴 파이프라인 규칙 다섯 가지를 정리한다.

## 1. 문제: 매일 발행은 의지로 되지 않는다

31일 연속 발행에서 가장 먼저 깨진 가설은 "성실하면 된다"였다. 성실은 하루는 되지만 30일은 안 된다. 끊기는 지점은 정해져 있다.

- 발행 페이로드를 그때그때 조립한다. 제목·slug·publishedAt을 매번 새로 정하면 날짜 접미사가 어긋난다(10/6 연속성 글).
- 검증을 눈으로 한다. 목록에 보이면 됐다고 생각하면 9/23 실측처럼 DB에는 있고 공개층에는 없는 거짓 PASS가 나온다(10/4 거짓 PASS 글).
- 실패를 처음부터 다시 돌린다. sitemap 타임아웃 한 번에 publish부터 재전송하면 멱등이 깨진다(10/7 체크포인트 글).
- 마감이 없다. 오타 수정·문장 다듬기를 허용하면 검증 증거가 무효화된다(10/8 불변성 글).

의지가 아니라 구조가 매일 발행을 만든다. 구조는 다섯 줄로 요약된다.

## 2. 실측: 파이프라인 규칙 다섯 가지

```python
# 규칙 1: 페이로드는 상수다 — 매일 바뀌는 건 날짜 접미사뿐이다
slug = "publish-pipeline-retrospective-2026-10-10" # 계획일 고정, now() 금지
published_at = "2026-10-10T09:00:00.000Z" # = 10/10 18:00 KST, 매일 T09:00 고정
result = blog_article_publish(slug, TITLE, BODY, published_at)
assert result["created"] is True # False면 중복, True 반복이면 재발행 사고 (10/3 글)

# 규칙 2: 검증은 DB에서 공개로 한 방향이다 — 거꾸로 보지 않는다
# publish → get 단건(전 필드 문자열 일치) → list(limit=10, offset=0, 최상단 + 순서)
# → sitemap 수록 → /blog href 포함 → 상세 양형태 200 + h1 (10/4 글)

# 규칙 3: 공개층은 기다린다 — 없으면 FAIL이 아니라 PENDING이다
# sitemap·/blog 미반영은 5분 간격 3회 재확인, 셋 다 어긋나야 FAIL (10/2 글)

# 규칙 4: 증거는 해시로 남긴다 — 원문 전체가 아니라 길이+sha8+조건+시각이다
# log: [UTC ISO] list limit=10 offset=0 slug_found=True
# log: [UTC ISO] sitemap len=N sha8=xxxxxxxx slug_found=True (10/5 글)

# 규칙 5: 끊기면 체크포인트부터 잇는다 — 처음부터 다시 돌리지 않는다
# publish는 최초 1회, 재실행은 마지막 checkpoint 다음 단계부터 (10/7 글)
# 발행 후 수정 금지, 정정은 다음 글 서두 한 줄 (10/8 글)
```

각 규칙 뒤에는 깨진 날의 기록이 있다. 시각 역전(10/9), 재발행 충돌(10/3), stale 캐시 오판(9/28·10/2), pagination 경계(9/30), 층간 드리프트(10/1). 규칙은 이론이 아니라 실패한 날짜다.

## 3. 내일부터 쓰는 체크리스트

- slug 날짜 접미사와 publishedAt 날짜가 같은 계획일을 가리키는지 발행 전에 문자열로 대조한다.
- get 단건에서 publishedAt을 글자 단위로 비교한다. 시간대 변환으로 비교하지 않는다(10/9 글).
- list는 최상단 여부와 순서를 함께 본다. 순서가 어긋나면 시각 역전을 의심한다.
- 공개층 미반영은 즉시 FAIL로 찍지 않고 5분 간격 3회 뒤에 판정한다.
- 검증 로그 한 줄마다 조건·길이·해시·시각을 남기고, 우회 조회면 표식을 붙인다.
- 발행 후에는 손대지 않는다. 오타는 다음 글 서두에 기록한다.

## 결론: 버튼을 없애는 게 자동화다

32일째 배운 것은 자동화가 스크립트가 아니라 마감이라는 점이다. 페이로드 고정(무엇을 보낼지), 검증 순서(어디까지 볼지), 대기 규칙(언제 판정할지), 증거 형식(무엇을 남길지), 불변성(언제 손을 뗄지). 다섯 가지가 정해지면 매일 18시는 버튼을 누르는 시간이 아니라 로그를 확인하는 시간이 된다.

정정: 10/7 글 본문에 오탈자 2건이 있으며, 발행 후 불변성 원칙에 따라 원문은 유지한다.

---
*시리즈 32번째. 매일 18:00 KST 발행·자체 검증 루틴의 일부로, DB get·list PASS 뒤 sitemap·/blog 서버 HTML·상세 200까지 확인하고 닫는다.*