Nano Banana 2 에서 image safety 는 하나의 스위치가 아니다. Gemini API 안에는 조정 가능한 prompt-side safety system 이 있고, 그 밖에 OTHER, PROHIBITED_CONTENT, IMAGE_SAFETY 같은 visible reason 을 돌려주는 더 강한 response layer 가 있다. 여기에 Gemini Apps 쪽의 product-level policy removal 까지 겹친다. 많은 디버깅이 빗나가는 이유는 모델이 완전히 이해 불가능해서가 아니라, 이 세 가지 결정을 하나의 필터로 취급하기 때문이다.
가장 먼저 기억해야 할 문장은 이것이다. BLOCK_NONE 은 좁은 control 이지 master switch 가 아니다. 이것은 Gemini API 의 네 가지 prompt-side categories 에만 영향을 준다. Google 의 built-in core protections 를 지우지 못하고, Gemini Apps 에서는 되던 작업이 API 에서는 왜 다른 hard block 으로 들어가는지도 설명해 주지 못한다.
가장 빠른 길은 어느 계약이 발동했는지부터 확인하는 것이다.
safetySettings를 바꿨을 때 결과도 함께 바뀐다면, 아직 조정 가능한 layer 에 있을 가능성이 높다.- API 가
SAFETY,OTHER,PROHIBITED_CONTENT,IMAGE_SAFETY같은 visible reason 을 보여 준다면, 그것을 막연한 오류가 아니라 route signal 로 읽어야 한다. - 같은 작업이 Gemini Apps 와 Gemini API 에서 다르게 보인다면, app shell 을 독립된 surface 로 보고 API 의 완전한 거울이라고 가정하지 않는 편이 낫다.
근거 메모: 이 글은 2026년 4월 3일 기준으로 확인한 Gemini API 공식 문서, Gemini Apps help page, Gemini 3.1 Flash Image model card, 그리고 current developer complaint threads 를 바탕으로 작성했다. 이 환경에서는 Google 직접 capture 가 막혀 있었기 때문에 search observation 은 fallback evidence 로 보강했다.
Nano Banana 2 에서 image safety 가 실제로 뜻하는 것
Nano Banana 2 는 Gemini API 에서 gemini-3.1-flash-image-preview 에 해당한다. Google 은 이를 더 빠르고 throughput 이 높은 image model 로 배치하고 있다. 이 점이 중요한 이유는 많은 페이지가 예전 Nano Banana 나 Nano Banana Pro 의 safety language 를 그대로 가져와 새 model 을 "같은 동작인데 더 엄격해진 버전"처럼 다루기 때문이다. 그런 shortcut 은 안전하지 않다.
더 정확한 mental model 은 이렇다. Nano Banana 2 에서 image safety 는 최소 세 가지 다른 계약을 가리킬 수 있다.
첫 번째 계약은 Gemini API 의 조정 가능한 prompt-side safety system 이다. Google 이 현재 공개한 adjustable categories 는 harassment, hate speech, sexually explicit content, dangerous content 네 가지뿐이다. 개발자가 safetySettings 라고 할 때 보통 말하는 층이 바로 이것이다.
두 번째 계약은 API 자체의 더 강한 block 및 response layer 다. 공개 schema 에는 SAFETY, OTHER, PROHIBITED_CONTENT, IMAGE_SAFETY 같은 이유가 보인다. 이것은 같은 거절을 다른 단어로 부르는 것이 아니다. settings 를 봐야 하는지, prompt 를 다시 써야 하는지, 작업 자체를 바꿔야 하는지, 아니면 그 surface 에 맞지 않는다고 받아들여야 하는지를 가르는 route signal 이다.
세 번째 계약은 Gemini Apps 라는 product shell 이다. Google 의 current help documentation 은 이미지 생성, 업로드 이미지 편집, 이미지 조합, 그리고 사람을 포함한 personalized-image scenarios 를 보여 준다. 동시에 policy reason 으로 이미지가 제거될 수 있다는 경고도 한다. 그래서 Gemini Apps 를 "UI 만 더 좋은 API" 로 보면 안 된다. 다른 user-facing contract 를 가진 별도의 surface 이다.
이 세 가지를 분리하면 Nano Banana 2 의 safety 문제는 훨씬 읽기 쉬워진다. 왜 이 filter 가 random 해 보이느냐고 묻는 대신, 이번 결정을 실제로 어느 layer 가 내렸는지를 먼저 볼 수 있기 때문이다.
safety settings 가 바꿀 수 있는 것과 없는 것
Nano Banana 2 주변의 가장 흔한 오해 중 하나는 BLOCK_NONE 을 모델의 꺼짐 스위치처럼 다루는 것이다. 현재 Gemini API safety docs 는 그런 해석을 지지하지 않는다.
문서가 지지하는 것은 더 좁지만 더 유용한 읽기다. Gemini API 에서 adjustable safety settings 가 다루는 것은 다음 네 가지 prompt-side categories 뿐이다.
HARASSMENTHATE_SPEECHSEXUALLY_EXPLICITDANGEROUS_CONTENT
즉 요청이 정말 이 configurable thresholds 안에 있다면 BLOCK_NONE 은 의미가 있다. 하지만 만능 답은 아니다.
Google 은 core harms 가 adjustable settings 밖에서도 계속 block 된다고 명시한다. 그래서 configurable thresholds 를 낮추거나 꺼도 결과가 전혀 움직이지 않는다면, 더 강한 결론은 "Google 이 숨겨진 extra filter 를 갖고 있다" 가 아니라 "애초에 adjustable layer 문제가 아니었다" 에 가깝다.
Nano Banana 2 관련 discussion 이 자꾸 원을 그리는 이유도 여기에 있다. 어떤 사람은 "이미 전부 BLOCK_NONE 으로 바꿨다"고 말하고, 다른 사람은 "그럼 hidden filter 가 있는 것"이라고 답한다. 더 방어 가능한 결론은, 요청이 configurable layer 밖으로 넘어가 BLOCK_NONE 이 원래 다루지 않던 계약으로 들어갔다는 쪽이다.
실무적 결론은 단순하다. 관측된 failure 가 adjustable prompt-side layer 와 맞을 때만 safetySettings 를 써라. response surface 가 다른 signal 을 주고 있다면, 그 signal 을 믿고 route 를 바꾸는 편이 맞다.
SAFETY, OTHER, PROHIBITED_CONTENT, IMAGE_SAFETY 를 어떻게 읽을까
visible reason 을 vague rejection 이 아니라 "다음 행동 지시" 로 읽기 시작하면 Nano Banana 2 는 훨씬 다루기 쉬워진다.
현재 Gemini API docs 에서 Google 은 SAFETY, OTHER, PROHIBITED_CONTENT, IMAGE_SAFETY 같은 block reasons 를 공개한다. image-generation integrations 에서는 이 값들이나 매우 가까운 response-layer reasons 가 body 에 나타날 수 있다. 더 안전한 운영 방식은 visible reason 을 routing instruction 으로 취급하는 것이다.
| Visible reason | 보통 무엇을 뜻하는가 | 다음 행동 |
|---|---|---|
SAFETY | configurable safety system 에 걸렸다. | safetyRatings 를 보고 현재 safetySettings 와 대조해서, 정말 네 가지 adjustable categories 문제인지 확인한다. |
OTHER | 더 넓은 policy boundary 나 unsupported content 에 닿았을 수 있다. Google troubleshooting docs 도 BlockedReason.OTHER 가 Terms of Service 나 unsupported content 를 뜻할 수 있다고 말한다. | 좁은 threshold problem 으로 다루지 말라. 작업을 재구성하거나 단순화하거나, 그 surface 에 맞지 않는다고 받아들여라. |
PROHIBITED_CONTENT | mild false-positive zone 이 아니라 더 강한 policy zone 으로 들어갔다. | 같은 아이디어를 미세하게 바꾸며 계속 밀어 넣지 말고, 작업 자체를 바꾸거나 멈춰라. |
IMAGE_SAFETY | image-generation safety layer 가 output 을 막았다. | prompt 를 다시 쓰고 framing 이나 style 을 바꾸거나 더 좁은 troubleshooting path 로 이동하라. settings toggle 하나로 해결된다고 가정하지 말라. |
핵심은 마지막 열이다. 이 labels 가 유용한 이유는 서로 다른 action 으로 route 해 주기 때문이다.
SAFETY 를 보면 docs 가 settings path 를 준다. OTHER 를 보면 문제가 adjustable categories 밖에 있을 수 있음을 Google 스스로 시사한다. PROHIBITED_CONTENT 라면 미세 수정 반복보다 작업 자체를 바꾸는 쪽이 더 자연스럽다. IMAGE_SAFETY 라면 그것은 image-layer block 이지 API settings misconfiguration 의 증거가 아니다.
다만 경계는 있다. Google 은 모든 IMAGE_SAFETY 나 OTHER case 에 대한 세부 trigger taxonomy 를 공개하지 않는다. 그래서 이 labels 를 hidden rulebook 처럼 다루면 안 된다. route marker 로 읽는 편이 맞다.
정상적인 prompt 도 왜 실패하는가
Nano Banana 2 의 safety 가 불투명하게 느껴지는 이유 중 하나는, 정상적이고 합법적인 use case 도 friction 을 겪을 수 있기 때문이다. Google developer forum 의 current complaint threads 에는 fashion, lifestyle 같은 non-NSFW prompts 에 대한 false positives 불만이 계속 보인다. Gemini 3.1 Flash Image model card 역시 false positives 와 false negatives 를 모두 줄이는 작업을 계속하고 있다고 말한다. 즉 균형은 아직 조정 중이다.
이 evidence 를 읽는 올바른 방식은 "모델이 망가졌다" 도 아니고 "모든 complaints 는 user error" 도 아니다. 더 강한 읽기는 public contract 가 아직 incomplete 하다는 것이다.
예를 들어 benign reference-image edit 도 실패할 수 있고, 의상 묘사가 작성자 기대보다 더 공격적으로 해석될 수 있다. 어떤 realistic portrait edit 는 한 surface 에서는 평범하게 보이지만 다른 surface 에서는 멈출 수 있다. 이것은 hidden official blacklist 의 증거가 아니다. 다만 실제 운영 friction 이 neat 한 public taxonomy 보다 더 복잡하다는 뜻이다.
이 차이는 중요하다. forum rumor 를 official policy 처럼 다루기 시작하면 debugging quality 가 급격히 떨어진다. folklore 에 과적합하고 evidence 에서 멀어지며, 사실은 route 를 바꿔야 할 자리에서 작은 prompt surgery 만 반복하게 되기 때문이다.
더 나은 workflow 는 실패를 정확히 기록하고, 모호함을 줄이고, 한 번에 하나의 큰 change 만 넣는 것이다. identity- or body-centric language 에서 task- or scene-centric language 로 옮긴다. 사람이 들어가는 작업이라면 정말 필요한 것이 photorealistic generation 인지, editorial-style illustration 인지, 더 안전한 reference transform 인지 먼저 정한다. 그래도 계속 실패한다면, 정직한 답은 "마법 같은 표현을 아직 못 찾았다" 가 아니라 "이 surface 에서는 지금 지원하지 않는다" 일 수도 있다.
Gemini Apps 와 Gemini API
나쁜 safety advice 의 상당수는 Gemini Apps 와 Gemini API 를 하나의 동작으로 눌러 버리는 데서 시작한다.
공식 Gemini Apps help docs 는 그런 단순화를 지지하지 않는다. Google 은 현재 Nano Banana 2 를 Gemini Apps 에서 이미지 생성, 업로드 이미지 편집, 이미지 조합, 사람을 포함한 personalized-image scenarios 에 사용할 수 있다고 설명한다. 이것만으로도 "Nano Banana 2 는 사람 이미지 자체를 허용하지 않는다" 는 blanket claim 은 무너진다.
동시에 그 same help surface 는 possible policy issue 가 감지될 때 이미지가 제거될 수 있다고 경고한다. 이 caveat 가 핵심이다. 어떤 capability 가 product-level 로 support 된다고 해서 모든 request 가 통과하는 것은 아니다. 또한 app-level removal 은 documented API response reason 과 동일하지 않다.
그래서 cross-surface anecdotes 는 특히 오해를 부르기 쉽다. 어떤 사람은 "Gemini 에서는 됐다"고 말하고, 다른 사람은 "같은 concept 가 API 에서는 막혔다"고 말할 수 있다. 둘 다 동시에 사실일 수 있다. shell, moderation path, user-facing messaging, enforcement timing 이 동일하지 않기 때문이다.
운영자에게 필요한 결론은 실무적이다. consumer-style editing 이나 personalized image manipulation 이 주목적이라면 Gemini Apps 가 현재 support range 를 파악하는 더 좋은 reference surface 일 수 있다. production API integration 이 주목적이라면, 판단의 출발점은 app screenshot 이나 forum anecdote 가 아니라 documented API contracts 여야 한다. 서로 관련은 있지만 서로를 대체할 수는 없다.
retry 보다 route 변경이 먼저여야 할 때
Nano Banana 2 image safety 에서 가장 유용한 습관 중 하나는, 한 번 더 retry 해도 아무 의미가 없는 순간을 알아보는 것이다.
200 OK 인데 usable image 가 없거나 response path 에 IMAGE_SAFETY 가 보인다면, 더 좁은 guide Nano Banana 2 가 200 OK 를 반환하지만 이미지가 없을 때 로 가는 편이 맞다. 이것은 아주 specific 한 operational failure mode 로, 별도의 debug logic 를 가진다.
failure mix 안에 quota exhaustion, malformed requests, broader reliability problems 가 섞여 있고 safety-specific block 만의 문제가 아니라면, 종합적인 Nano Banana 2 가 작동하지 않을 때의 가이드 로 route 하는 것이 더 자연스럽다. safety analysis 는 429, bad parameter, temporary service problem 을 고치지 못한다.
실제 질문이 Nano Banana 2 가 사람, portrait, personalized edits 를 얼마나 안정적으로 다룰 수 있느냐라면, 더 좁은 Gemini image generation 사람 제한 으로 가는 편이 낫다. 그 글은 human-image branch 자체에 초점을 맞춘다.
그리고 해야 할 일이 "Google 의 safety contracts 를 해석하는 것"보다 "하나의 stable 한 app/API layer 위에서 image generation 을 제공하는 것"에 가깝다면, Nano Banana AI image generator 같은 broader tooling surface 가 더 relevant 할 수 있다. Google model 내부의 policy decisions 를 없애지는 못하지만, provider switching 과 fallback routing 주변의 operational mess 는 줄여 줄 수 있다.
더 큰 요점은 다음과 같다. 올바른 다음 행동은 retry 가 아니라 routing 인 경우가 많다. Nano Banana 2 image safety 를 "먼저 contract 를 식별하고, 그 다음 action 을 고르는 문제" 로 보면 무의미한 재시도가 크게 줄어든다.
FAQ
BLOCK_NONE 은 Nano Banana 2 의 safety filters 를 모두 끄는가?
아니다. 현재 Gemini API docs 가 지지하는 해석은 훨씬 좁다. BLOCK_NONE 은 네 가지 prompt-side categories 의 thresholds 만 바꾼다. Google 의 built-in core protections 를 없애지 못하고, app-level policy behavior 까지 같은 rule set 으로 묶을 수도 없다.
image safety 는 Nano Banana 2 가 사람 이미지를 전혀 못 만든다는 뜻인가?
아니다. Gemini Apps current help page 는 사람을 포함한 personalized-image 와 image-editing scenarios 를 분명히 보여 준다. 더 정확한 말은, 사람 관련 request 는 더 민감한 zone 에 있고 Gemini Apps 와 Gemini API 의 동작이 다를 수 있다는 것이다.
IMAGE_SAFETY block 는 항상 과금되는가?
더 안전한 읽기는, processed image-generation blocks 는 official surface 가 명시적으로 아니라고 하지 않는 한 potentially billable 하다고 보는 것이다. Google 은 Nano Banana 2 의 current token-based pricing 을 공개하지만, 이번 research pass 에서는 모든 IMAGE_SAFETY case 를 한 문장으로 덮는 clean 한 공식 문장을 찾지 못했다. 그래서 이 글은 docs 가 지지하지 않는 universal billing claim 을 피한다.
Nano Banana 2 image safety 를 가장 쉽게 디버깅하는 방법은 무엇인가?
먼저 contract 를 식별하는 것이다. 이것이 Gemini API 의 adjustable safety settings 문제인지, 더 강한 API response reason 인지, 아니면 Gemini Apps 의 product-level policy behavior 인지부터 구분하라. layer 이름도 못 붙인 상태에서는 이후의 troubleshooting 이 거의 추측으로 흐를 수밖에 없다.
Nano Banana 2 에 하나의 image-safety filter 만 있는 것은 아니다. 시장이 한 문구로 뭉뚱그리는 여러 enforcement contracts 가 있을 뿐이다. 그것을 분리해서 보기 시작하면, 빈 retry 는 크게 줄어든다.