최근 개인 프로젝트의 일환으로 과거 기록들을 블로그로 옮기는 마이그레이션 작업을 진행하고 있었다. Gemini API를 활용한 메타데이터와 이미지 생성 단계까지는 아무런 문제 없이 물 흐르듯 성공했다. 하지만 기쁨도 잠시, 본격적으로 데이터를 블로그에 발행하는 publishToBloggerMig 단계에서 청천벽력 같은 400 에러를 마주했다.

호기롭게 준비해 둔 대기 큐의 169건의 데이터가 전부 대기 상태로 멈춰 서 있는 모습을 보니 눈앞이 아득해졌다. 로그에 찍힌 에러 메시지는 명확하게 INVALID_ARGUMENT를 가리키고 있었지만, 도대체 어떤 인자가 잘못되었는지 구체적으로 알려주지 않아 답답함이 밀려왔다. 무엇이 문제였는지 차근차근 디버깅하며 삽질했던 해결 과정을 공유해 보려고 한다.

원인 분석: 정상 작동 스크립트와의 처절한 페이로드 비교

이 문제를 해결하기 위해 가장 먼저 한 일은 기존에 정상적으로 잘 작동하고 있던 IssueLog 스크립트의 페이로드와 이번 마이그레이션용 페이로드를 하나하나 대조해 보는 것이었다. 두 API 호출은 거의 동일한 구조를 가지고 있었기에, 아주 미세한 차이가 Blogger API 400 오류를 유발하고 있을 것이라 확신했다.

꼼꼼히 비교해 본 결과, 눈에 띄는 단 하나의 차이점은 바로 글이 발행될 시간을 지정하는 published 필드였다. 기존 정상 작동 스크립트는 이 필드 없이 현재 시간으로 자동 발행되도록 하고 있었고, 이번 마이그레이션 스크립트는 과거 날짜로 백데이팅하기 위해 특정 날짜 데이터를 밀어 넣고 있었다. 바로 이 지점이 400 badRequest 에러의 출발지였다.

범인은 RFC3339 포맷의 밀리초(.000) 누락

구글 Blogger API의 공식 문서를 다시 뒤져보니 published 필드는 RFC3339 포맷의 시간 문자열을 요구하고 있었다. 내가 기존에 자바스크립트로 생성해서 보내던 ISO 문자열도 언뜻 보기에는 RFC3339 규격에 맞는 것처럼 보였기에 처음에는 무엇이 문제인지 이해하기 어려웠다.

하지만 결정적인 단서는 API가 정상적으로 응답할 때 보내주는 날짜 데이터 형태에 있었다. Blogger API가 반환하는 모든 시간 값에는 소수점 아래 세 자리의 밀리초가 항상 포함되어 있었다. 마이그레이션용으로 생성하던 날짜 문자열에 밀리초가 누락되어 검증기를 통과하지 못하고 계속 400 에러를 뱉어냈던 것이다.

헬퍼 함수와 안전한 자동 폴백 구현

원인을 파악했으니 해결책을 적용할 차례였다. 가장 먼저 날짜 오프셋을 정규화하고 반드시 밀리초 포맷을 포함하도록 보정해 주는 toBloggerRfc3339() 헬퍼 함수를 작성했다. 이 함수는 어떤 날짜가 들어오든 Blogger API가 안전하게 받아들일 수 있는 완벽한 RFC3339 문자열로 변환해 준다.

동시에 코드의 안정성을 높이기 위해 Blogger API 호출부를 공통 래퍼 함수인 postToBlogger()로 완전히 분리해 주었다. 여기에 만약 백데이팅을 시도하다가 날짜 포맷 문제나 기타 이유로 실패할 경우, published 필드를 아예 제거하고 현재 시간으로 우선 발행을 완료하게 만드는 자동 재발행 폴백 로직을 추가했다.

이 덕분에 오랜 시간 멈춰 서 있던 169건의 대기 큐 데이터가 단 하나의 누락도 없이 깔끔하게 백데이팅에 성공하며 발행을 마칠 수 있었다. 사소한 포맷 규격 하나가 전체 자동화 시스템을 마비시킬 수 있다는 뼈아픈 교훈을 얻은 값진 경험이었다.