Nano Banana Pro에 RESTRICTED by System Instructions가 떴다면, 제일 먼저 할 일은 prompt를 다시 쓰는 것이 아닙니다. 이 문구는 대개 Google이 Pro를 전역적으로 몰래 낮췄다는 뜻이 아니라, 지금 서 있는 surface가 다르거나, 현재 entitlement가 맞지 않거나, 요청 자체가 아직 시스템이 막는 안전 경계 안에 있다는 뜻입니다.
먼저 확인할 것은 지금 Pro를 어디서 쓰고 있느냐입니다. Gemini Apps라면 그 이미지가 실제로 Redo with Pro 단계까지 갔는지, 그리고 현재 quota가 남아 있는지를 봐야 합니다. AI Mode라면 Thinking with 3 Pro에 있는지, 현재 제공 조건에 맞는지, 그리고 작업 성격이 infographic / diagram 쪽에 가까운지를 봐야 합니다. AI Studio나 Gemini API라면 gemini-3-pro-image-preview에서 안전한 최소 prompt를 하나 먼저 돌려 보고, route 문제인지 category 문제인지 나눠야 합니다.
한 번 수정한 뒤에는 surface를 바로 바꾸지 마세요. 같은 surface에서 다시 확인해야 합니다. safe prompt는 통과하는데 원래 요청만 계속 막힌다면, 그때는 hidden downgrade를 의심하기보다 category boundary를 의심하는 편이 맞습니다.
2026년 4월 14일 기준으로 Google의 Gemini Apps 도움말, AI Mode 도움말, Gemini API 문서는 Pro를 surface마다 다른 계약처럼 설명하고 있습니다. Gemini safety 문서도 일부 core harms는 계속 blocked 상태라고 말합니다. 여기서 정말 유용한 질문은 Google이 Pro를 몰래 바꿨나가 아니라 내가 먼저 어디서 막혔나입니다.
30초 분기 보드
| 어디서 막혔나 | 먼저 볼 것 | 같은 surface에서 어떻게 검증하나 | 판단을 바꿔야 할 순간 |
|---|---|---|---|
| Gemini Apps | Redo with Pro가 실제로 보였는지, 현재 quota가 남았는지 | 같은 이미지에서 Pro redo가 보이거나 완료된다 | prompt가 아니라 route / quota 문제다 |
| AI Mode | Thinking with 3 Pro인지, 현재 조건에 맞는지, 작업이 diagram 계열인지 | 같은 작업이 올바른 AI Mode branch에서 돌아간다 | 작업 자체가 AI Mode Pro와 맞지 않는다 |
| AI Studio / Gemini API | gemini-3-pro-image-preview를 쓰는지, 안전한 최소 prompt가 통과하는지 | 같은 모델에서 safe prompt가 성공한다 | 문제는 route가 아니라 원래 작업 쪽이다 |
| Safe prompt는 되는데 원래 작업은 안 된다 | route 자체는 살아 있다 | 원래 작업만 계속 막힌다 | policy boundary로 봐야 한다 |
이 문구가 오해를 부르는 이유는 Nano Banana Pro가 이제 어디서나 같은 한 줄기 통로가 아니기 때문입니다. Gemini Apps에서는 Nano Banana 2 뒤에 붙는 redo layer에 가깝고, AI Mode에서는 더 좁은 작업용 route이며, API에서는 model ID 자체입니다. 이 셋을 섞어 테스트하면 surface 차이가 그대로 Pro가 예전보다 나빠졌다는 느낌으로 보이기 쉽습니다.
그래서 여기서 가장 비효율적인 행동은 처음부터 prompt를 계속 손보는 것입니다. prompt를 바꿔도 내가 잘못된 surface에 있는지, entitlement가 없는지, 아니면 policy boundary인지는 드러나지 않습니다. 먼저 분기하고, 하나만 고치고, 같은 surface에서 다시 보는 편이 훨씬 빠릅니다.
Gemini Apps에서 이 문구를 봤다면
이 가지에서 가장 먼저 바로잡아야 할 인식은, Gemini Apps의 시작점이 항상 Nano Banana Pro는 아니라는 점입니다. 현재 Google 설명에 따르면 새 이미지는 먼저 Nano Banana 2로 생성되고, 그 다음에 유료 사용자가 Redo with Pro를 쓸 수 있습니다. 그래서 많은 사용자가 지금 Pro를 보고 있다고 생각하지만, 실제로는 default Nano Banana 2 flow나, 이미 redo path가 사라진 app 상태를 보고 있을 수 있습니다.
Gemini Apps 안에서 RESTRICTED by System Instructions가 떴다면 세 가지를 먼저 보세요. 첫째, 그 이미지가 실제로 Redo with Pro 단계까지 갔는가. 둘째, 오늘 quota가 아직 남아 있는가. 셋째, 지금 비교 기준이 현재 App contract인가, 아니면 예전 Pro 기억인가.
여기서는 route issue와 quality complaint가 특히 쉽게 섞입니다. Gemini Apps는 default model, redo path, quota boundary를 한 인터페이스 안에 넣기 때문입니다. Nano Banana 2 쪽 일일 한도에 닿으면 Pro redo 길도 같이 사라질 수 있습니다. 이때 맞는 다음 행동은 prompt를 더 다듬기가 아니라, 지금 App contract가 원하는 route를 열어 주지 않는다는 사실을 인정하고 quota reset을 기다리거나, 다른 surface로 옮기거나, Nano Banana 2를 의도적으로 쓰는 것입니다.
Gemini Apps, AI Mode, API 사이에서 왜 Pro 체감이 자꾸 달라지는지가 더 큰 질문이라면 Nano Banana Pro가 예전보다 나빠졌나?를 보는 편이 맞습니다.
AI Mode에서 Pro를 쓰려는 경우
AI Mode는 이름이 익숙해서 시간을 가장 많이 쓰게 되는 branch입니다. 현재 Google 설명에서 AI Mode의 Pro는 Thinking with 3 Pro를 통해 제공되고, infographics와 diagrams 쪽에 더 맞는 route로 소개됩니다. 즉 모든 이미지 작업의 상위 버전이라는 뜻이 아닙니다. 여기에 현재 plan, region, language 조건도 붙습니다.
따라서 AI Mode refusal은 Nano Banana Pro가 전부 막혔다는 뜻이 아닙니다. 단지 다른 mode에 있거나, 현재 조건이 맞지 않거나, 일반적인 이미지 생성 작업을 지금 Google이 더 구조화된 시각 작업용으로 설명하는 route에 억지로 넣고 있다는 의미일 수 있습니다. 작업이 빠르게 일반 이미지를 만들고 싶다에 더 가깝다면, AI Mode 안에서 prompt를 계속 다듬기보다 surface를 바꾸는 쪽이 더 빠를 수 있습니다.
이 가지에서 가장 쓸모 있는 same-surface 검증은 단순합니다. Thinking with 3 Pro, 현재 제공 조건, 작업 fit을 확인한 뒤 같은 작업을 다시 돌려 보세요. route와 entitlement가 맞는데도 작업 자체가 AI Mode Pro의 현재 역할과 맞지 않다면, 그때는 prompt surgery보다 surface choice를 바꾸는 편이 낫습니다.
또한 Gemini Apps와 AI Mode를 한 troubleshooting session에서 섞지 않는 것이 좋습니다. Apps의 default flow와 AI Mode의 좁은 route를 오가면 서로 다른 contract 차이를 숨은 다운그레이드처럼 읽게 됩니다. 더 안전한 습관은 하나의 surface, 하나의 수정, 하나의 재시도입니다.
AI Studio 또는 Gemini API를 쓰는 경우
developer 쪽에서는 판단이 조금 더 기계적입니다. Pro를 보려면 먼저 model ID를 확인해야 합니다. gemini-3-pro-image-preview가 맞는지 보세요. 그 다음 첫 테스트는 production prompt가 아니라, 명백히 안전한 최소 prompt여야 합니다. 사람, public figure, 민감한 edit를 피한 infographic나 단순 비교 카드, 중립적인 diagram이 좋습니다. 여기서 알고 싶은 것은 output의 예술성이 아니라 route가 살아 있는지입니다.
safe prompt가 gemini-3-pro-image-preview에서 통과한다면, 이미 큰 분기가 끝난 셈입니다. 모델은 reachable하고 route도 살아 있습니다. 그렇다면 원래 요청이 계속 막힐 때 살펴봐야 할 것은 route availability보다 request category 쪽입니다. API에서는 이 구분이 consumer surface보다 더 빨리 보입니다.
또 하나 중요한 점은, 다른 error family를 이 제목 안에 밀어 넣지 않는 것입니다. 실제로 보고 있는 것이 429, empty response, ignored parameters, wrong output size라면 그건 이미 RESTRICTED by System Instructions와는 다른 문제입니다. 그런 경우에는 Gemini image API 흔한 오류 수정 쪽이 맞습니다. 그때의 다음 분기는 billing, endpoint, parameter handling이기 때문입니다.
문제의 핵심이 요청 카테고리 자체라면
이 branch는 받아들이기 가장 어렵지만, 이 exact phrase에는 가장 도움이 되는 경우가 많습니다. 현재 Gemini safety 문서는 일부 core harms가 항상 blocked 상태라고 분명히 말합니다. 이것은 quota 문제도, hidden toggle 문제도, 표현을 조금 바꾼다고 반드시 열리는 문제도 아닙니다. route와 entitlement를 먼저 털어낸 뒤에 남는 것이 category boundary입니다.
테스트 방법은 단순합니다. surface를 바꾸지 말고, model도 바꾸지 말고, 원래 요청을 명백히 안전하고 평범한 요청으로 바꿔 보세요. 그 safe control prompt는 통과하는데 원래 요청만 계속 막힌다면, route issue와 category issue는 이미 분리된 것입니다. route는 살아 있고, 막히는 것은 작업 내용입니다.
그 다음 질문은 이 작업을 안전한 형태로 바꿀 수 있나가 됩니다. 실존 인물을 fictional character로 바꿀 수 있는가, 위험한 edit를 중립적인 diagram으로 바꿀 수 있는가, 경계를 건드리는 핵심 동작을 제거할 수 있는가를 봐야 합니다. 답이 아니라면, 시스템의 답도 지금은 아니라고 보는 편이 맞습니다. 여기서 prompt를 더 누르는 시간은 큰 의미가 없습니다.
문제가 사람, public figure, 얼굴 관련 제한에 더 가깝다면 왜 Gemini는 사람 이미지 생성을 제한하나를 보는 편이 낫습니다. 다만 이 페이지의 역할은 더 좁습니다. 정책의 전체 역사를 설명하는 것이 아니라, 경계를 빨리 알아보게 하는 것입니다.
수정 후 어떻게 검증하고 어떤 경로로 갈지
수정을 넣었다면, 변수 다섯 개를 한 번에 바꾸지 마세요. 가장 안전한 순서는 다음과 같습니다.
- 하나만 바꾼다
- 같은 surface에서 다시 본다
- route와 category를 더 가를 필요가 있으면 safe control prompt를 하나 추가한다
- 현재 surface가 명백히 다른 contract일 때만 route를 바꾼다
이 순서의 가치는 결과를 읽을 수 있게 만든다는 점입니다. surface, prompt, entry path를 한꺼번에 바꾸면 무엇이 먹혔는지 알 수 없습니다. 같은 surface에 남아 하나씩 보면, 내가 고친 것이 route인지 entitlement인지, 아니면 real boundary를 확인한 것뿐인지가 드러납니다.
Gemini Apps에서 Pro redo path가 없다는 것이 확인되면 surface를 바꾸거나 quota reset을 기다리면 됩니다. AI Mode가 task fit이 아니라는 것이 확인되면 일반 이미지 작업을 거기에 계속 밀지 않는 편이 좋습니다. API에서 safe control prompt는 통과하는데 원래 요청이 안 된다면 global Pro outage라고 보지 마세요. 반대로 safe prompt도 안 된다면 아직 policy diagnosis 단계가 아니니, route와 entitlement로 돌아가야 합니다.
gate를 확인한 뒤에 볼 sibling pages는 다음과 같습니다.
- Nano Banana Pro가 예전보다 나빠졌나?: cross-surface 설명이 더 필요할 때
- 왜 Gemini는 사람 이미지 생성을 제한하나: people / public-figure boundary가 핵심일 때
- Gemini image API 흔한 오류 수정: developer 쪽 failure family가 다를 때
자주 묻는 질문
Gemini Apps에 지금도 Pro가 있나요?
있습니다. 다만 항상 열려 있는 시작 경로는 아닙니다. 현재 Google 도움말은 이미지가 먼저 Nano Banana 2로 생성되고, 그 뒤에 유료 사용자가 Redo with Pro를 쓸 수 있다고 설명합니다.
AI Mode Pro는 모든 이미지 작업에 맞나요?
아닙니다. 현재 Google 설명은 Thinking with 3 Pro를 infographic / diagram 쪽 route로 두고 있습니다. 모든 이미지 작업의 상위 모드라는 뜻은 아닙니다.
API의 safety settings로 이걸 풀 수 있나요?
Google이 항상 blocked라고 설명하는 category에는 어렵습니다. safety settings가 영향을 주는 맥락은 있지만, current docs도 일부 core harms는 조정으로 풀리지 않는다고 적고 있습니다.
Safe prompt는 되는데 원래 요청만 막히면 무엇을 의미하나요?
route 자체는 살아 있고, 문제는 원래 요청의 category 쪽에 있다는 뜻입니다. 다음 행동은 job framing을 바꾸거나 경계를 받아들이는 것입니다.
언제 Nano Banana 2로 돌아가야 하나요?
일반 이미지 생성이 목적일 때, Gemini Apps가 이미 Nano Banana 2를 default path로 쓰고 있을 때, 또는 AI Mode Pro가 이 작업과 맞지 않다고 확인됐을 때입니다. 현재 공개 문서에서도 Nano Banana 2는 더 general 한 default route로 다뤄집니다.