최근 개인 프로젝트로 진행 중인 Blogger 자동 포스팅 도구에서 원인 모를 에러가 발생했다. API 요청 시 계속해서 400 에러가 반환되며 포스팅 발행이 멈추는 현상이었다. 처음에는 API 문서만 보고 단순한 일시적 오류이거나 필수 파라미터가 누락된 줄로만 알았다.
하지만 에러가 발생한 글 하나 때문에 뒤이어 대기 중이던 수많은 포스팅 큐가 통째로 정체되는 치명적인 상황이 벌어졌다. 이 문제를 해결하기 위해 최근 며칠간 밤을 새우며 겪은 눈물겨운 삽질과 마침내 찾아낸 해결책을 공유하고자 한다.
엉뚱한 곳에서 헤맸던 날짜 포맷의 늪
가장 처음 의심했던 용의자는 등록일(published) 날짜 포맷이었다. 로그를 확인했을 때 밀리초 단위가 누락되어 발생하는 오류인 줄 알고 날짜 변환 함수인 toBloggerRfc3339를 도입하고 실패 시 예외 처리를 하는 폴백(Fallback) 로직을 추가했다.
하지만 날짜 포맷을 정교하게 다듬고 예외 처리를 꼼꼼하게 넣었음에도 불구하고 400 에러는 여전히 발생했다. 큐가 여전히 꽉 막혀 꼼짝도 하지 않는 모습을 보며 뒤통수가 얼얼해지는 느낌을 받았다.
결정적인 단서는 예외 처리 폴백 로직이 제대로 작동하면서 포착되었다. 폴백 로직이 아예 published 필드를 완전히 제거하고 재시도하도록 설계했음에도 불구하고 동일하게 INVALID_ARGUMENT와 함께 400 에러가 떨어졌기 때문이다. 이는 날짜 포맷이 원인이 아니라, 두 요청에 공통으로 들어가는 다른 필드에 진짜 범인이 숨어있음을 의미했다.
범인은 날짜가 아니라 200자 제한의 라벨이었다
모든 공통 필드를 꼼꼼히 뜯어보던 중 Blogger 라벨에 눈길이 갔다. 검색을 거듭한 끝에 아주 놀라운 사실을 발견했다. Blogger는 개별 포스트에 달 수 있는 라벨 개수 제한인 20개보다, 모든 라벨의 합계 길이 제한인 200자 제한이 먼저 작동한다는 사실이었다.
이 200자 제한에는 콤마와 공백까지 모두 포함된다. 나는 콘텐츠 분류를 세분화하기 위해 띄어쓰기가 포함된 긴 멀티워드 라벨을 아낌없이 집어넣고 있었다. 여러 개의 긴 라벨이 콤마로 연결되다 보니 합계 길이가 손쉽게 200자를 초과해 버렸던 것이다.
그 결과 Blogger API 측에서는 이를 잘못된 인자(INVALID_ARGUMENT)로 판단하고 400 에러를 뱉어낸 것이었다. 원인을 알고 나니 허탈하면서도 문제를 해결할 수 있다는 실마리를 얻어 무척 기뻤다.
안전하게 컷오프하는 해결책과 동반 발견한 버그
해결을 위해 라벨의 총길이를 안전하게 가공해 주는 capBloggerLabels()라는 헬퍼 함수를 구현했다. 이 함수는 단순한 개수 제한뿐만 아니라, 콤마 구분자를 포함한 누적 문자열 길이가 190자를 넘지 않도록 안전선을 확실히 그어주도록 설계했다.
- 라벨을 순회하며 구분자를 포함한 총 문자열 길이를 실시간 계산
- 안전 마진을 두어 누적 190자까지만 라벨을 수용하고 이후는 과감히 컷
- 최종 라벨 개수도 최대 20개 상한선을 넘지 않도록 이중 안전장치 마련
이 작업을 진행하면서 또 다른 심각한 설계 결함도 발견했다. 작성해 둔 스크립트가 대기 상태인 행 중에서 항상 첫 번째 행만 가져와서 처리하도록 고정되어 있었던 것이다. 이 때문에 라벨 길이 초과로 에러가 난 특정 포스트 한 건이 큐의 맨 앞에서 버티고 서 있으니, 뒤에 있는 모든 정상 포스트들까지 전부 실행되지 못하고 큐 정체 현상이 발생했던 것이었다.
라벨 길이를 안전하게 잘라주는 보정 함수를 적용하고 나니 막혀있던 대기 행들이 거짓말처럼 한 번에 쭉 빠져나갔다. API 통신 시에는 사소한 문자열 제한조건 하나가 전체 시스템을 마비시킬 수 있음을 뼈저리게 배운 유익한 경험이었다.