Instagram 캐러셀 발행 에러(code -1), 절반은 거짓이었다 — 실측 12건 (2026)

duckpipe는 블로그 글을 쓰면 카드뉴스로 만들어 Instagram에 캐러셀로 자동 발행한다. 이 파이프라인을 운영하면서 같은 에러를 12번 만났는데, 절반 이상은 거짓이었다.

에러의 정체

Instagram Graph API로 캐러셀을 발행하는 마지막 단계(media_publish)에서 이 에러가 뜬다.

{
  "error": {
    "message": "Fatal",
    "type": "OAuthException",
    "code": -1,
    "error_subcode": 2207085,
    "is_transient": false,
    "error_user_msg": "내부 서버 오류가 발생했습니다. 나중에 다시 시도해주세요."
  }
}

스크립트는 이 응답을 받으면 예외를 던지고 종료한다. 자연스럽게 “발행 실패”로 처리하게 된다.

8월 4일 — 진짜 실패였던 날

카드뉴스 캐러셀 6개를 짧은 시간에 연달아 발행하려다 3개가 이 에러로 실패했다. 컨테이너 상태를 FINISHED까지 확인한 뒤에도 발생했으니 컨테이너 자체의 문제는 아니었다. 각 실패 건을 한 번씩 더 재시도했는데, 두 번째 시도에서도 정확히 같은 에러가 났다. 이때는 짧은 시간에 캐러셀 6개를 몰아서 쏜 게 원인으로 보였다 — 레이트 리밋에 걸린 성격으로 추정하고 재시도를 멈췄다. 실제로 이 3건은 그날 게시되지 않았다.

8월 5일 — 9번 다 거짓이었던 날

다음 날은 다른 양상이었다. 하루 동안 12개 이상의 글을 하나씩 순서대로 발행하는 과정에서, 캐러셀을 만들고 마지막 발행 단계에서 9번 이 에러를 만났다. 매번 스크립트는 예외를 던지고 종료했다.

그런데 에러가 뜰 때마다 실제로 확인해봤다 — Instagram Graph API로 계정의 최근 미디어 목록을 곧바로 다시 조회한 것이다.

GET https://graph.instagram.com/v21.0/{IGID}/media?fields=id,caption,permalink,timestamp&limit=1

9번 다 방금 올린 캡션이 이미 게시돼 있었다. 에러 응답을 받은 시점에는 이미 Meta 서버 쪽에서 게시가 끝나 있었던 것이다.

같은 코드, 정반대의 결과

8월 4일과 8월 5일 모두 완전히 동일한 응답(code: -1, error_subcode: 2207085)이 왔다. 하지만 8월 4일의 3건은 재시도해도 계속 실패한 진짜 실패였고, 8월 5일의 9건은 전부 이미 성공해 있던 거짓 실패였다. 이 에러 응답 하나만 보고는 실제로 무슨 일이 있었는지 알 수 없다는 뜻이다.

정확한 원인은 밝혀내지 못했다. 추정할 수 있는 건 Meta 서버 내부에서 게시 처리 자체가 끝났는데도, 클라이언트에게 결과를 확인해주는 응답 단계에서 별도의 오류가 나 실패처럼 보이는 응답이 갔을 가능성이다. 8월 4일처럼 짧은 시간에 요청을 몰아 쏘면 진짜로 막힐 수 있고, 8월 5일처럼 순차적으로 보내도 이 응답 자체의 신뢰도와는 무관하게 뜰 수 있다는 정도만 확인했다.

그래서 바꾼 것 — 재시도 전에 먼저 재조회

이 경험 이후로 이 에러를 만나면 다음 순서를 따른다.

1. 곧바로 같은 명령을 재실행하지 않는다. 실제로 이미 게시됐다면 중복 게시가 된다.
2. 미디어 목록을 재조회해 방금 캡션이 올라갔는지 확인한다.
3. 올라가 있으면 성공으로 처리하고 상태 파일에 기록한다. 자동 발행 스크립트가 이 예외를 캐치해 그냥 false를 반환하는 구조라면, 성공했는데도 “미발행” 상태로 남아 다음 자동 실행 때 중복 게시될 위험이 있다.
4. 재조회해도 안 올라가 있으면 그때 재시도한다.

에러 메시지의 is_transient: false나 “나중에 다시 시도해달라”는 안내 문구를 곧이곧대로 믿지 않는 것이 핵심이다. 이 필드가 실제 성공/실패와 무관하게 찍히는 걸 12번 중 9번 확인했기 때문이다.