Nano Banana Pro 가 HTTP 503 UNAVAILABLE 를 반환했을 때 가장 먼저 믿어야 하는 것은 message 가 아니라 code 와 status 다. 이유는 gemini-3-pro-image-preview 가 Deadline expired before operation could complete 라는 문구를 보여주면서도 실제로는 true 503 UNAVAILABLE 로 응답하는 경우가 있기 때문이다. wording 이 timeout 처럼 보여도, 그것만으로 504 분기로 넘어가면 안 된다.
이 지점에서 많은 troubleshooting 페이지가 시간을 낭비하게 만든다. 어떤 페이지는 503 이니 무조건 retry 라고만 말하고, 어떤 페이지는 deadline 을 보고 너무 빨리 timeout tuning 으로 간다. 하지만 이 exact symptom 에서 먼저 해야 할 일은 더 단순하다. 지금 필요한 첫 행동이 retry 인지, timeout 조정인지, 아니면 503 페이지를 떠나야 하는지를 먼저 정하는 것이다.
2026년 4월 15일 기준으로 Gemini API troubleshooting guide, Gemini image generation docs, 그리고 exact match 인 공식 forum thread를 다시 확인한 결론은 같다.
- 응답이 진짜
503 UNAVAILABLE라면 먼저 temporary capacity failure 로 보고 same path 에서 bounded backoff 를 시도한다. - 응답이 진짜
504 DEADLINE_EXCEEDED이거나 client 가 먼저 timeout 된 경우에만 timeout tuning 과 request load 조정으로 간다. - error 가
429,400,403이라면 이 503 페이지에 머물지 말고 다른 branch 로 이동한다.
진단을 망치지 않는 두 번째 rule 도 있다. branch 를 확인하는 동안에는 model, prompt, SDK surface, auth owner, payload shape 를 한 번에 바꾸지 말아야 한다. 그래야 service 가 회복된 것인지, 문제를 다른 것으로 바꿔버린 것인지 구분할 수 있다.
먼저 30초 안에 503 과 504 를 가른다
이 증상을 가장 안정적으로 읽는 방법은 세 갈래 분기뿐이다.
503 UNAVAILABLE: temporary capacity loss. 먼저 retry.504 DEADLINE_EXCEEDED: timeout budget mismatch. 먼저 timeout 또는 load 조정.429,400,403: 이 페이지의 범위가 아니다.
이건 편의를 위한 요약이 아니라 현재 공식 문서의 구분과도 맞는다. Google 의 troubleshooting 문서도 여전히 503 UNAVAILABLE 와 504 DEADLINE_EXCEEDED 를 분리한다. Nano Banana Pro 의 exact symptom 에서도 가장 안전한 출발점은 그 split 이다. message wording 은 비슷한 증상이라는 힌트는 줄 수 있지만, response class 보다 우선하지 않는다.
지금 당장 가장 작은 확인만 하고 싶다면 이렇게 하면 된다. HTTP code 를 읽고, status 를 확인한 뒤, same path 로 한 번만 다시 보내 본다. branch 가 계속 503 으로 남는지, 504 로 바뀌는지, 아니면 다른 class 로 바뀌는지. 그 한 번의 retest 가 긴 원리 설명보다 더 많은 정보를 준다.
왜 503 인데도 Deadline expired 라고 보일까
이 문제가 헷갈리는 가장 큰 이유는 message 가 완성된 timeout diagnosis 처럼 보이기 때문이다. 그래서 많은 사용자가 response class 보다 literal phrase 를 먼저 검색한다. 하지만 이 case 에서는 official forum 의 exact example 이 중요하다. Nano Banana Pro image endpoint 에서 503 UNAVAILABLE 와 Deadline expired before operation could complete 가 함께 나온 사례가 이미 있다. 즉 deadline wording 이 있다는 사실만으로 true 504 를 증명하지는 못한다.
여기서 가져가야 할 실전 rule 은 하나다. 이 문구는 orientation bridge 로만 쓰고, final diagnosis 로 쓰지 않는 것이다. 사용자가 "내가 찾는 증상이 맞다"는 것을 확인하는 데는 도움이 되지만, code/status split 을 건너뛸 권한을 주지는 않는다.
이 구분이 중요한 이유는 첫 행동이 달라지기 때문이다. true 503 branch 는 여전히 temporary capacity failure 의 문제다. true 504 branch 는 timeout budget 과 request load 의 문제다. wording 만 보고 timeout tuning 을 시작하면, service 가 스스로 회복될 503 event 에 대해 엉뚱한 변수를 만질 수 있다.
진짜 503 capacity failure 라면 무엇을 해야 하나
응답이 아직 503 UNAVAILABLE 라면, 첫 행동은 큰 수술이 아니라 recovery 를 확인할 수 있는 가장 작은 조치여야 한다.
가장 실용적인 방법은 same path 에서 bounded backoff 를 거는 것이다. 여기서 same path 라는 말은 가능하면 같은 model, 같은 route, 같은 auth owner, 같은 SDK surface, 그리고 크게 달라지지 않은 request shape 를 유지한다는 뜻이다. prompt 를 다시 쓰거나, SDK 를 바꾸거나, timeout 을 올리거나, fallback model 로 바로 넘어가는 것은 그 다음이다.
retry rhythm 도 복잡할 필요가 없다.
- 잠시 기다린 뒤 한 번 다시 보낸다.
- 여전히 503 이면 대기 시간을 조금 늘려 한 번 더 보낸다.
- bounded 한 횟수에 도달하면 더 기다릴지, queue 로 넘길지, temporary fallback 으로 갈지 결정한다.
여기서 bounded 가 중요한 이유는 무한 retry loop 가 분기 결정을 흐리기 때문이다. bounded retry 는 "짧은 capacity wobble 인가" 아니면 "이제 다른 운영 판단으로 넘어가야 하나"를 보이게 만든다.
또 한 가지 피해야 할 오해는 503 을 quota 문제로 읽는 것이다. branch 가 여전히 503 인 동안에는 billing upgrade 나 client-side throttling 이 첫 대응이 아니다. 응답이 429 RESOURCE_EXHAUSTED 로 바뀔 때 비로소 rate-limit diagnosis 로 넘어가야 한다. 그 branch 는 Gemini API rate limits guide 에서 다루고 있다.
진짜 504 또는 client timeout 이라면 무엇을 해야 하나
timeout branch 는 응답이 실제로 504 DEADLINE_EXCEEDED 가 되었을 때, 또는 client 가 서버보다 먼저 timeout 되었을 때 성립한다. 그때부터 timeout tuning 이 main move 가 된다.
이 branch 에서는 풀고 있는 문제가 이미 다르다. 더 이상 temporary capacity shortage 가 아니라, 현재 timeout budget 과 request load 가 맞지 않는 문제다. 그래서 대응도 달라져야 한다.
가장 안전한 첫 단계는 세 가지면 충분하다.
- client timeout 을 합리적으로 늘린다.
- request load 를 조금 가볍게 만든다.
- 그리고 same path 에서 다시 확인한다.
여기서 "load 를 가볍게 한다"는 말은 시스템 전체를 뜯어고친다는 뜻이 아니다. timeout branch 를 증명할 수 있을 만큼 request shape 를 조금 가볍게 보는 것이다. 목적은 영구적인 quality downgrade 가 아니라, 실제로 timeout budget 이 문제인지 확인하는 것이다.
중요한 점은 deadline 이라는 word 가 들어간 every message 에 timeout advice 를 그대로 씌우지 않는 것이다. 이 페이지의 가치 자체가 timeout-like wording 과 real timeout branch 를 분리하는 데 있기 때문이다.
same path 에서 branch 를 확인한 뒤 route-out 한다
이 verification step 이 있어야 이 페이지가 generic explanation 이 아니라 rapid-recovery guide 가 된다.
branch 확인용 retest 에서는 가능하면 같은 model, 같은 route, 같은 auth owner, 같은 SDK surface, 비슷한 payload shape 를 유지해야 한다. model, prompt, timeout 을 동시에 바꾸면 성공해도 무엇이 효과가 있었는지 알 수 없다.
retest 뒤에 중요한 outcome 은 세 가지뿐이다.
-
여전히
503 UNAVAILABLE이다.
503 capacity branch 에 남는다. bounded retry, queueing, deliberate fallback 판단으로 간다. -
504 DEADLINE_EXCEEDED가 되거나 client 가 다시 timeout 된다.
timeout branch 로 이동한다. -
429,400,403으로 바뀐다.
이 503 page 는 여기서 역할을 끝내고 다른 guide 로 clean route-out 해야 한다.
exact-error page 의 힘은 좁게 유지되는 데 있다. 무엇이든 다 다루는 대신, branch 가 바뀌는 순간 제대로 handoff 하는 것이다.
FAQ
Deadline expired 가 보이면 바로 timeout 을 올려야 하나
아니다. true 504 DEADLINE_EXCEEDED 또는 confirmed client timeout 일 때만 그렇다. response 가 여전히 503 UNAVAILABLE 라면 첫 대응은 503 branch 다.
왜 503 에도 Deadline expired before operation could complete 가 붙을 수 있나
message string 이 final diagnosis 가 아니기 때문이다. exact 조합은 official forum 에서도 확인됐다. 따라서 wording 은 symptom bridge 로는 유용하지만, code/status split 을 뒤집지는 못한다.
이건 quota 나 rate limit 과 같은 문제인가
보통은 아니다. quota / rate-limit branch 는 429 RESOURCE_EXHAUSTED 이다. 응답이 429 로 바뀌는 순간 이 페이지에서 나가야 한다.
model, prompt, timeout 을 한 번에 바꾸는 것이 좋나
좋지 않다. 먼저 same path 에서 branch 를 확정해야 한다. 변수를 한꺼번에 바꾸면 diagnostic signal 이 사라진다.
언제 이 페이지를 떠나야 하나
응답이 true 504, client timeout, 또는 429 / 400 / 403 으로 바뀌는 순간이다. exact-error page 는 좁기 때문에 유용하다.
마지막으로 남겨야 할 한 문장
Nano Banana Pro 가 503 UNAVAILABLE 를 반환하면, message string 보다 response code 와 status 를 먼저 본다. Deadline expired before operation could complete variant 라도, response 자체가 504 가 되지 않는 한 첫 분기는 still 503 이다.
이 한 rule 만 지켜도 가장 비싼 오진 경로를 많이 피할 수 있다.