블로그 1967개 글 제목을 본문 기반으로 자동 정책화

기술 블로그가 성장하면서 과거 글들의 제목이 일관성 없이 흩어져 있었다. 새로운 제목 정책(30자 이내, 증상·효과 중심)을 수립했을 때, 1967개 글을 수동으로 수정할 수는 없었다. 그래서 본문을 읽고 자동으로 제목을 재생성하는 파이썬 스크립트를 작성해 한 번에 처리했다.

과거 제목과의 괴리

내가 블로그를 시작했을 때만 해도 "제목을 어떻게 지을까" 같은 메타 고민이 없었다. 각 글을 쓸 때마다 "내용을 설명하면 되겠지" 식으로 지었으니, 어떤 글은 너무 길고, 어떤 글은 모호했다.

• 원래 제목: "사내 인증 시스템에 JWT 적용 후 발견한 세션 만료 버그와 쿠키 처리 전략"
• 새로운 정책: "만료 세션 쿠키로 홈 화면 깨지던 버그 수정" (증상 중심, 30자)

더 극단적인 경우도 있었다:
- 원래: "마이크로서비스 아키텍처 도입 시 고려사항"
- 정책화: "서비스 간 통신 지연으로 헬스체크 타임아웃 발생"

제목 정책 자체는 명확해졌는데, 그걸 1967개 글에 일일이 적용할 순 없었다. 우선순위를 매기자면, 이건 하루빨리 끝내야 할 "한 번의 노동"이었다. 자동화가 유일한 옵션이었다.

스크립트 설계의 핵심 결정

retitle_from_body.py 는 다음 흐름으로 동작했다:

1. 블로그 글 데이터베이스에서 각 글의 본문을 읽음
2. 본문의 처음 100-200 글자(도입부)에서 핵심 증상/효과를 추출
3. 추출한 내용을 "증상 중심, 30자 이내" 포맷으로 제목 생성
4. 각 글의 메타데이터에 새 제목 업데이트

일회성 스크립트이기 때문에, 몇 가지를 전략적으로 결정했다:

스크립트 자체는 복잡하지 않았다. 오히려 어려운 부분은 정책 판단이었다. "LLM으로 생성한 제목을 그대로 적용할까, 아니면 일부는 수동으로 다시 검토할까" 같은 결정 말이다.

일회성 스크립트의 가치와 한계

이런 종류의 일회성 스크립트가 정말 중요하다는 걸 다시 느꼈다. 특히 데이터 규모가 크거나 정책 변경이 일어날 때:

일회성 스크립트의 가치:
- 휴먼 에러 제거: 1967개를 손으로 하면 100% 실수한다. 스크립트는 정책을 정확히 1967번 반복한다.
- 명확한 기록: 나중에 "왜 2026년 6월에 모든 제목이 바뀌었지?"라고 물을 때, 커밋 메시지와 스크립트가 답이 된다.
- 대안 실험이 쉬움: 제목 포맷이 마음에 안 들면, 스크립트를 수정해 다시 실행할 수 있다.

약간의 아쉬움:
- 한 번 실행 후엔 버려진다. 데이터가 변경된 후에는 스크립트를 다시 돌릴 일이 거의 없다.
- 스크립트가 "지저분해" 보인다. 프로덕션 코드처럼 정교할 필요는 없지만, 향후 참고용으로라도 주석과 로깅은 필수다.

그래서 나는 실행 로그를 남기고, 생성된 제목과 원본을 비교 리포트로 보관해뒀다. "다음에 또 이런 작업이 필요하면 이 패턴을 참고"할 수 있도록.

기술 리더 관점에서의 배운 점

단순한 일회성 스크립트처럼 보이지만, 조직 관점에서 몇 가지를 깨달았다:

• 정책 정의가 자동화를 가능하게 함: "제목은 30자 이내, 증상 중심"이 명확하면 스크립트를 짤 수 있다. 정책이 모호하면 자동화가 불가능하다.
• 백필(backfill) 작업을 가볍게 여기지 말 것: 1967행은 작은 숫자처럼 보이지만, 누군가 일일이 다 한다면 며칠이 걸린다. 스크립트로 5분에 끝낸다.
• 일회성이어도 기록할 가치가 있음: 미래의 자신과 팀원이 "왜 이 시점에 제목이 바뀌었나"를 이해하려면, 커밋과 스크립트에 흔적을 남겨야 한다.

비슷한 상황을 자주 본다. 블로그의 태그를 정책화하거나, 메타데이터 형식을 마이그레이션할 때도 일회성 스크립트가 필수였다. 개별적으로 보면 작지만, 축적되면 블로그의 "품질과 일관성"을 크게 좌우한다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.