최근 블로그 자동화 시스템을 보완하면서 가장 공을 들였던 부분은 퍼머링크 최적화였습니다. 테스트 환경인 Lab에서 멋지게 성공한 영문 퍼머링크 트릭을 드디어 실제 운영 중인 다른 채널들로 전파하기로 마음먹었습니다. 이 과정에서 가장 핵심이 된 작업은 바로 기존의 다양한 발행 환경에 맞춘 GAS 스크립트 이식 작업이었습니다.
하지만 단순히 코드를 복사해서 붙여넣는 것으로는 끝나지 않았습니다. 내가 운영하는 채널들은 각자 고유한 목적과 구조를 가지고 있었기 때문입니다. 동일한 트릭을 적용하더라도 채널의 성격에 따라 분기 처리를 정교하게 설계해야만 예상치 못한 에러를 막을 수 있었습니다. 오늘은 그 치열했던 삽질과 해결 과정을 기록으로 남겨봅니다.
동일한 구조를 가진 두 채널의 빠른 이식과 구조 단순화
먼저 손을 댄 곳은 IssueLog와 KidStory 채널이었습니다. 이 두 곳은 다행히도 기존의 Lab 환경과 완벽히 동일한 구조를 공유하고 있었습니다. 덕분에 기존에 검증해 둔 publishToBlogger 함수와 발행 후 타이틀을 변경하는 renamePostTitle 방식을 그대로 이식하는 것만으로도 충분했습니다.
여기에 더해 기존 워크플로우를 조금 더 직관적으로 다듬었습니다. 이전에는 발행 후 상태를 검수 대기로 두어 한 번 더 손이 가게 만들었지만, 이번에는 발행과 보완이 성공적으로 끝나면 상태를 바로 완료로 변경하여 종결되도록 프로세스를 단축했습니다. 자동화가 안정 궤도에 올랐다는 확신이 들었기에 내릴 수 있었던 과감한 결정이었습니다.
참고로 검색 엔진 최적화를 위한 제목 클릭형 최적화는 이번 이식 대상에서 제외하고 오직 Lab 채널에만 단독으로 유지하기로 했습니다. 분석해 보니 이미 IssueLog와 KidStory 같은 소비자 지향형 블로그들은 본문 작성을 시작할 때부터 충분히 짧고 검색 친화적인 제목을 사용하고 있었기 때문입니다. 굳이 불필요한 연산을 추가할 필요가 없다고 판단해 과감히 덜어냈습니다.
구조가 완전히 다른 IT Story 채널을 위한 별도 분기 설계
진짜 문제는 마이그레이션 전용으로 운영 중인 IT Story 채널이었습니다. 이 채널은 과거에 작성한 글들을 가져오는 용도라 일반 발행 함수가 아닌 publishToBloggerMig 함수를 사용하고 있었습니다. 특히 과거 시점으로 발행일을 고정해야 하는 Blogger 백데이팅 처리가 필수적인 구조였습니다.
기존의 일반적인 방식대로 일단 글을 발행한 뒤 제목을 변경하려고 하니, 백데이팅 기능과 꼬이면서 원치 않는 형태로 작동하곤 했습니다. 고민 끝에 구조적 차이를 인정하고 완전히 새로운 흐름의 분기 설계를 도입하기로 했습니다. 핵심은 영문 제목과 백데이팅용 published 날짜를 동시에 API insert 요청으로 보내 미리 완벽한 슬러그 예약을 받아두는 것이었습니다.
원하는 슬러그로 글이 무사히 생성되고 나면, 두 번째 단계로 PATCH published 요청을 보내 제목만 한국어 원제로 덮어씌웠습니다. 이 PATCH 방식은 오직 title 필드만 수정하기 때문에, 이미 고정된 published 날짜나 기확보된 영문 슬러그를 전혀 건드리지 않고 그대로 유지할 수 있었습니다. 덕분에 마이그레이션 중에도 아무런 충돌 없이 백데이팅과 영문 퍼머링크를 동시에 챙길 수 있게 되었습니다. 만약 이 백데이팅 과정에서 API 오류가 발생하면 published 값을 제거하고 재시도하는 안전한 폴백(Fallback) 구조 역시 단단히 유지했습니다.
테스트 과정에서 관찰한 독특한 슬러그 예약 현상
새로 설계한 분기 처리를 검증하기 위해 수없이 많은 테스트를 거듭하던 중 매우 흥미로운 현상을 관찰할 수 있었습니다. 테스트를 위해 방금 생성한 글을 삭제한 뒤, 동일한 영문 제목으로 다시 글을 발행하면 Blogger가 기존 주소를 기억하고 있다는 듯 URL 뒤에 _1, _2 같은 숫자 접미사를 붙여 발행하는 것이었습니다.
알고 보니 구글 블로거는 글을 삭제하더라도 중복 방지를 위해 기존 슬러그를 일정 기간 내부적으로 보관 혹은 예약 상태로 잡아두는 메커니즘을 가지고 있었습니다. 처음에는 코드에 버그가 있는 줄 알고 소스 코드를 한참 헤맸지만, 원인을 알고 나니 비로소 안도할 수 있었습니다.
실제 운영 환경에서는 매번 새로운 키워드로 완전히 다른 글이 생성되기 때문에 이러한 중복 이슈가 발생할 일이 전혀 없었습니다. 오직 개발 과정에서 동일한 제목으로 끊임없이 지우고 다시 쓰는 테스트를 반복할 때만 발생하는 특유의 현상이었던 셈입니다. 이 사소한 발견 덕분에 플랫폼의 내부 동작 방식을 한 층 더 깊이 이해하게 되었습니다.
이번 작업을 통해 아무리 좋은 기술적 트릭이라도 대상 플랫폼과 채널의 목적에 맞게 세밀한 분기 설계가 뒷받침되어야 진짜 내 무기가 된다는 것을 깨달았습니다. 깔끔하게 정리된 스크립트가 돌아가는 모습을 보니 그간의 삽질이 모두 값진 거름으로 돌아온 것 같아 무척 뿌듯합니다.