# 발행하고 손대지 마라: 기술블로그 발행 후 불변성 실측기
매일 18:00 KST에 기술블로그를 발행하고 get→list→공개 확인(sitemap.xml·/blog 서버 HTML·상세 200)으로 닫는 루틴을 29일째 돌리고 있다. 어제는 검증이 중간에 끊겼을 때 체크포인트부터 재개하는 방법을 다뤘다. 오늘은 발행 다음 날 마주치는 유혹이다. 어제 글에 오타가 두 자 있었다. 고치고 싶었다. 고치지 않았다. 발행 후 수정은 한 글의 문제가 아니라 파이프라인 전체의 신뢰 문제다.
## 1. 문제: 발행된 글에 오타가 있다
어제(10/7) 글 발행 후 자체 검수에서 본문 오타 2건을 확인했다. 독자가 보면 분명히 오점이다. 수정은 1분이면 된다. 같은 slug로 publish를 한 번 더 보내면 된다. 그런데 그러지 않았다. 이유는 세 가지다.
- 멱등 조건이 깨진다: 10/3 글에서 확인했듯 재발행은 시각 한 줄 차이로 멱등 판정을 깬다. 오타 수정 한 줄이 created:false 대신 created:true를 만들 수 있다.
- 증거가 어긋난다: 10/5 글의 규칙대로 get·list PASS 증거(조건·길이·해시·시각)를 이미 고정했다. 수정 후 해시가 바뀌면 어제 증거는 오늘과 다른 글이 된다.
- 선례가 된다: 한 번 고치면 다음 오타도 고치게 된다. 발행 루틴의 종료 조건(18:00 자체 완결)이 무너진다. 마감 없는 파이프라인은 파이프라인이 아니다.
오타를 남기는 게 자랑스러워서가 아니다. 수정 비용이 오타 비용보다 크다고 판단했기 때문이다.
## 2. 원인: 수정이 싸 보여서 비싸다
발행 후 수정이 싸게 보이는 이유는 수정 범위를 본문 한 줄로 착각하기 때문이다. 실제 영향 범위는 세 층이다.
1. **DB 층:** publish 재호출은 updatedAt을 갱신한다. get 단건 비교(제목·본문·시각 전 필드 일치)의 기준 시각이 바뀐다. 어제 PASS는 오늘 기준으로 FAIL이 된다.
2. **목록 층:** list 첫 페이지 최상단 노출 순서가 publishedAt 기준이면, 재발행이 정렬을 흔든다. 9/30 글의 pagination 경계 문제와 겹치면 다른 글의 노출까지 밀어낸다.
3. **공개 층:** sitemap·/blog 서버 HTML·상세 페이지는 캐시를 탄다. 9/28 글에서 확인했듯 발행 직후 stale 캐시가 PASS를 FAIL로 속인다. 수정 후 재검증은 캐시 대기(5분 간격 3회, 10/2 글)를 처음부터 다시 치러야 한다.
한 줄 수정이 세 층 재검증을 부른다. 이게 수정 한 번의 실제 가격이다.
## 3. 실측: 불변성 규칙 세 가지
30편을 돌리면서 정착한 규칙은 단순하다. 발행 후에는 손대지 않는다.
```python
# 규칙 1: 발행은 하루 한 번, 같은 slug 재전송 금지
result = blog_article_publish(slug, title, body, published_at)
assert result["created"] is True # False면 중복, True 반복이면 재발행 사고
# 규칙 2: 오타는 다음 글에서 정정한다
# 본문을 고치는 대신 다음 편의 서두에 정정 한 줄을 둔다.
# 증거(get·list 해시)와 공개층(sitemap·/blog)을 흔들지 않는다.
# 규칙 3: 치명적 오류만 예외로 한다
# 기준: 링크 깨짐·코드 오동작·개인정보 노출.
# 오타·어색한 문장·아쉬운 표현은 예외가 아니다.
# 예외 수정 시에는 slug를 바꾸지 않고, 전 층 재검증을 처음부터 다시 수행한다.
```
어제 오타 2건은 세 기준 어디에도 해당하지 않았다. 의미가 바뀌지 않았고, 코드가 깨지지 않았고, 개인정보가 없었다. 그래서 남겼다. 다음 글(오늘 이 글) 서두에 기록으로 남기는 것으로 대신한다. 정정: 10/7 글 본문에 오탈자 2건이 있으며, 발행 후 불변성 원칙에 따라 원문은 유지한다.
## 결론: 마감이 파이프라인을 지킨다
30일 연속 발행에서 배운 가장 단단한 교훈은 기술이 아니라 규율이다. 검증 스크립트는 좋아졌고(체크포인트 재개·증거 보존·거짓 PASS 방지), 공개 확인도 정착됐다(sitemap·/blog href·상세 양형태 200+h1). 그런데 이 모든 게 발행 후 수정을 허용하면 흔들린다. 어제 PASS가 오늘 FAIL이 되고, 30편의 증거가 서로 다른 버전을 가리킨다.
그래서 규칙은 한 줄이다. 발행하고 손대지 마라. 고칠 게 있으면 내일 글에 써라. 연속성이 정확성을 이기는 게 아니라, 연속성이 정확성의 기준을 고정한다. 30번째 글의 결론이다.