Nano Banana Pro API를 사용하여 주택 렌더링, 제품 이미지 합성 또는 이커머스용 장면을 생성할 때, 당혹스러운 상황을 마주할 때가 있습니다. 두 장의 참조 이미지를 업로드하고 프롬프트도 명확하게 작성했음에도 불구하고, 결과물은 마치 참조 이미지 중 하나를 그대로 복사한 것처럼 나와 지시사항이 전혀 반영되지 않는 경우죠. 이러한 현상은 2026년 2월 Gemini 3.1 Flash Image 출시 이후 눈에 띄게 늘었으며, Google AI Developers Forum의 관련 논의에서도 Pro 모델이 다중 참조 이미지 환경에서 "매우 불안정하다"는 점이 확인되었습니다.
본 글에서는 API 호출 메커니즘을 살펴보고, 실제 "건축 와이어프레임 + 완성 렌더링" 사례를 통해 Nano Banana Pro가 원본 이미지를 그대로 반환하는 5가지 트리거 조건을 분석하며, 즉시 적용 가능한 8가지 해결 방안을 제시합니다. 본문의 모든 호출 예시는 APIYI(apiyi.com) 플랫폼을 기준으로 작성되었습니다. 해당 플랫폼은 Gemini 3 Pro Image 시리즈 모델의 안정성을 강화했으므로, 본문에 소개된 수정 프롬프트를 바로 테스트해 보기에 적합합니다.
1. Nano Banana Pro가 원본 이미지를 반환하는 전형적인 현상
실제 사례를 먼저 살펴보겠습니다. 한 사용자가 주택 디자인 렌더링을 위해 두 장의 참조 이미지를 업로드했습니다. 이미지 1은 미완공 건축 와이어프레임(콘크리트 골조, 4.9MB), 이미지 2는 완공 후의 효과도(유리 커튼월, 조경, 석양 조명 등이 모두 포함됨, 13.8MB)였습니다. 프롬프트는 "이미지 2를 참조하여 이미지 1을 렌더링해줘. 색감: 차갑고 고급스러운 톤을 채택할 것. 표현 방식: 전형적인 상업적 실사 렌더링…"과 같이 작성했습니다. 의도는 이미지 2의 스타일과 재질을 빌려 이미지 1의 구조를 완성된 형태로 렌더링하는 것이었죠. 하지만 결과물은 이미지 2와 거의 똑같았고, 이미지 1의 구조 정보는 결과물에서 거의 찾아볼 수 없었습니다.
이는 단발적인 사례가 아닙니다. Google AI Developers Forum의 개발자들은 "모델이 참조 이미지를 너무 과도하게 다운샘플링하여 세부 정보를 인식하지 못한다"고 지적하며, Gemini 3.1 Flash Image 출시 이후 문제가 더욱 심화되었다고 언급했습니다. Replicate, Atlas Cloud, AI Free API 등 타사 플랫폼의 장애 해결 문서에서도 유사한 "참조 이미지 그대로 출력" 사례가 보고되고 있으며, 다만 플랫폼별로 트리거 조건에 약간의 차이가 있을 뿐입니다.
1.1 발생 빈도 및 영향 범위
아래 표는 다양한 사용 환경에서 Nano Banana Pro가 이미지를 수정하지 않는 현상의 상대적 발생 확률을 커뮤니티 피드백과 플랫폼 모니터링 샘플을 종합하여 정리한 것입니다.
| 사용 환경 | 발생 확률 | 영향 정도 |
|---|---|---|
| 단일 참조 이미지 편집 | 낮음 | 일부 세부 사항만 틀어짐 |
| 2개 이미지 합성(스타일 전이) | 중고 | 출력물이 특정 원본과 유사함 |
| 다중 이미지 합성(3장 이상) | 높음 | 마지막 이미지에 편향됨 |
| 미/유럽 피크 타임 호출 | 현저히 증가 | 전반적인 세부 품질 저하 |
| 민감한 장면 포함(인물/브랜드) | 간헐적 | 편집 거부 또는 원본 회귀 |
🎯 진단 제안: 이커머스, 주택, 제품 이미지 등 다중 참조 이미지를 활용하는 업무에서 "원본 반환" 현상이 10% 이상 발생한다면, 이는 단일 원인이 아니라 프롬프트, 파라미터, 인프라 세 가지 요소가 복합적으로 작용한 결과일 가능성이 큽니다. APIYI(apiyi.com) 플랫폼의 통합 인터페이스를 통해 동일한 프롬프트에서 Nano Banana Pro와 Nano Banana 2의 출력 차이를 비교해 보세요. 모델 계층의 문제인지 프롬프트 계층의 문제인지 빠르게 파악할 수 있습니다.
2. Nano Banana Pro가 원본 이미지를 반환하는 5가지 기술적 이유
2.1 원인 1: 프롬프트 내 참조 혼선으로 인한 "이미지 2" 복제 현상
Nano Banana Pro가 원본 이미지를 반환하는 가장 흔한 원인은 프롬프트 내의 "참조 이미지 2"와 같은 문구가 모델에 의해 "이미지 2의 복제본을 출력하라"는 명령으로 잘못 해석되기 때문입니다. Google DeepMind의 공식 프롬프트 가이드에서는 다중 이미지 입력 시 "the wireframe(와이어프레임)", "the rendered building(렌더링된 건물)"과 같이 의미론적인 이름을 사용할 것을 권장합니다. "이미지 2"와 같은 단순 위치 식별자는 피하는 것이 좋습니다.
2.2 원인 2: 편집 동사 누락으로 인한 "재현" 경로 선택
Gemini 2.5와 Gemini 3 Pro Image의 핵심 메커니즘은 자연어 이해를 기반으로 한 이미지 변환입니다. 프롬프트에 명확한 편집 동사(transform, render, apply, replace, composite 등)가 없으면, 모델은 다중 이미지 입력 상황에서 "재구성(reconstruction)" 경로를 선택하는 경향이 있습니다. 즉, 편집이 아닌 가장 강력한 신호를 가진 참조 이미지를 바탕으로 유사한 이미지를 다시 그려내는 것입니다.
2.3 원인 3: 다중 이미지 간 가로세로 비율 충돌 및 마지막 이미지의 주도권
Nano Banana 시리즈에는 잘 알려지지 않은 공식 규칙이 하나 있습니다. 다중 이미지 입력 시, 모델은 기본적으로 마지막 참조 이미지의 가로세로 비율을 따릅니다. 이 규칙은 DataCamp 튜토리얼과 Google Developers Blog에 명시되어 있지만, 실제 개발 과정에서는 자주 간과됩니다. 마지막 이미지의 비율이 우선시되면서 모델이 해당 이미지의 구도를 그대로 채택하게 되는 경우가 많습니다.
2.4 원인 4: 인프라 성능 저하 및 피크 시간대 자동 복구
2026년 2월 이후 Google은 Gemini 앱에서 Nano Banana 2를 기본 모델로 설정하고, Pro 모델은 "점 3개 메뉴 → Regenerate" 경로로 분리했습니다. 이와 동시에 API 측에서도 피크 시간대에 성능이 저하되는 현상이 보고되었습니다. Google AI Developers Forum의 게시글에 따르면, 주요 업데이트 전후로 이미지 생성 품질이 일시적으로 하락하는 경향이 있습니다. 이때 모델은 200 상태 코드를 반환하더라도 내부적으로는 더 작은 하위 모델을 사용하거나 후처리를 생략하여 품질이 떨어질 수 있습니다.
2.5 원인 5: 참조 이미지 과도한 다운샘플링
Google AI Developers Forum의 또 다른 분석에 따르면, "모델이 참조 이미지를 너무 과도하게 다운샘플링하여 세부 정보를 식별하거나 재현하지 못하는 경우"가 발생합니다. 참조 이미지 용량이 13MB에 근접하거나 초과하면 내부 전처리 단계에서 대폭 축소되어, 건축물의 기둥이나 제품 라벨과 같은 핵심 구조 정보가 뭉개질 수 있습니다. 디테일이 사라진 참조 이미지는 모델이 이를 무시하고 다른 선명한 이미지를 복제하게 만드는 원인이 됩니다.
3. 8가지 실전 복구 솔루션: Nano Banana Pro로 "이미지 기반 편집" 완벽하게 수행하기
Nano Banana Pro가 원본 이미지를 제대로 유지하게 하려면 모델이 알아서 의도를 추측하게 두지 마세요. '어떤 것이 베이스 이미지이고, 어떤 것이 참조 이미지인지, 그리고 어떤 변환을 수행할 것인지'를 명확히 지시하고, 호출 파라미터로 안전장치를 마련해야 합니다. 프롬프트와 파라미터 두 가지 측면에서 바로 적용 가능한 8가지 복구 포인트를 소개합니다.
3.1 프롬프트 계층의 5가지 복구 포인트
| 번호 | 복구 포인트 | 잘못된 방식 | 권장 방식 |
|---|---|---|---|
| 1 | 편집 동사 추가 | "이미지 2를 참조하여 이미지 1을 렌더링" | "Transform image 1 using image 2 as reference" |
| 2 | 번호 대신 의미 있는 이름 사용 | "이미지 1, 이미지 2" | "the wireframe / the finished rendering" |
| 3 | 역할 분담 명시 | (설명 없음) | "use the first as structure base, the second as style reference" |
| 4 | 목표를 긍정문으로 기술 | "이미지 2처럼 만들지 마" | "preserve the original building outline from the first image" |
| 5 | 구체적인 재질 요구사항 결합 | "차가운 톤으로 해줘" | "apply the cool-toned glass facade and warm interior glow from image 2 onto the structure from image 1" |
💡 프롬프트 템플릿: 건물 렌더링과 같은 '구조 + 스타일'의 2개 이미지 작업 시, 다음 템플릿 구조를 고정적으로 사용하는 것을 추천합니다:
[Action verb] + [structural reference from image A] + [style/material reference from image B] + [explicit constraints]. APIYI(apiyi.com) 플랫폼에서는 이 템플릿을 시스템 프롬프트로 저장하여 Nano Banana Pro와 Nano Banana 2를 A/B 테스트할 수 있으며, 반복 작업 비용을 획기적으로 줄일 수 있습니다.
3.2 호출 파라미터 계층의 3가지 복구 포인트
| 번호 | 복구 포인트 | 설명 |
|---|---|---|
| 6 | 업로드 순서 제어 | '편집 대상' 이미지를 마지막에 배치하여 모델이 해당 이미지의 가로세로 비율을 따르게 함 |
| 7 | 참조 이미지 크기 제한 | 단일 이미지를 2-5MB로 압축하여 과도한 다운샘플링 방지 |
| 8 | 명시적인 image_size 지정 | 1024×1024 또는 1536×1024 등으로 설정하여 가로세로 비율 충돌 방지 |
참고로, Gemini 3 Pro Image의 일부 버전에서는 "imageSize 파라미터가 무시된다"는 피드백(Google AI Developers Forum 사례 110458)이 있습니다. 따라서 복구 포인트 6과 8을 함께 사용하여 최종 비율이 의도와 일치하도록 보장해야 합니다. image_size만 설정하고 업로드 순서를 조정하지 않으면, 일부 버전에서는 마지막 이미지의 비율이 우선 적용될 수 있습니다.
4. Nano Banana Pro 이미지-이미지 변환 API 전체 호출 예시
4.1 오류 예시: Nano Banana Pro가 원본 이미지를 그대로 반환하게 만드는 잘못된 작성법
아래 호출 코드는 사용자 시나리오에서 실패했던 사례를 재현한 것입니다. 프롬프트 참조가 혼란스럽고, 편집 동사가 부족하며, 가로세로 비율(aspect ratio) 제어가 안 되고, 참조 이미지가 압축되지 않은 상태입니다.
import openai
client = openai.OpenAI(
api_key="your-apiyi-key",
base_url="https://api.apiyi.com/v1"
)
response = client.images.edit(
model="gemini-3-pro-image-preview",
image=[
open("wireframe.jpg", "rb"), # 4.9 MB
open("rendered.jpg", "rb"), # 13.8 MB, 마지막에 업로드
],
prompt="참조 이미지 2를 사용하여 이미지 1을 렌더링해줘. 색감: 차갑고 고급스러운 톤으로.",
size="auto",
n=1,
)
이런 방식은 다중 이미지 시나리오에서 모델이 rendered.jpg를 주도적인 신호로 인식하여 원본 이미지 2와 거의 흡사한 결과물을 내놓을 확률이 높습니다. 세 가지 핵심 위험 요소는 다음과 같습니다: 중국어 "참조 이미지 2(参照图2)"를 목표 출력물로 오해함, 편집 동사(transform 등) 결여, size를 auto로 설정하여 가장 큰 이미지의 비율이 전체를 주도함.
4.2 수정 예시: Nano Banana Pro가 의도대로 이미지를 편집하게 만드는 법
import openai
client = openai.OpenAI(
api_key="your-apiyi-key",
base_url="https://api.apiyi.com/v1"
)
prompt = (
"Transform the unfinished concrete wireframe structure in the first image "
"into a fully rendered architectural visualization. "
"Use the second image STRICTLY as a STYLE and MATERIAL reference: "
"apply its cool-toned glass facade, warm interior glow, surrounding greenery "
"and dusk lighting onto the structure from the first image. "
"Preserve the building outline, floor count and balcony arrangement "
"exactly as shown in the first image. "
"Do NOT replace the geometry with the second image."
)
response = client.images.edit(
model="gemini-3-pro-image-preview",
image=[
open("rendered_compressed.jpg", "rb"), # 스타일 참조, ~3 MB로 압축
open("wireframe_compressed.jpg", "rb"), # 편집 대상 이미지를 마지막에 배치
],
prompt=prompt,
size="1536x1024",
n=1,
)
여기에는 네 가지 핵심 변경 사항이 있습니다: 영어로 "A를 B를 참조하여 변환하라(transform A using B as reference)"는 역할 분담을 명확히 함; 업로드 순서를 조정하여 wireframe(편집 대상)이 '마지막 이미지'가 되도록 하여 비율을 주도하게 함; size를 명시적으로 지정하여 auto 모드에서 고해상도 참조 이미지의 비율을 상속받지 않도록 함; 두 참조 이미지를 모두 5MB 이하로 압축하여 과도한 다운샘플링을 방지함.
🚀 빠른 시작 팁: 수정 효과를 바로 확인하고 싶다면 APIYI(apiyi.com)에서 Nano Banana Pro와 Nano Banana 2를 동일한 프롬프트로 호출해 보세요. 플랫폼이 OpenAI 호환 인터페이스로 통합되어 있어 모델별로 코드를 수정할 필요가 없으며, 5분 안에 A/B 테스트 결과를 얻을 수 있습니다.
5. Nano Banana Pro 이미지-이미지 변환 FAQ
Q1: 수정된 프롬프트를 중국어로 쓰면 여전히 원본 이미지가 나오는데, 영어로 쓰면 정상인 이유는 무엇인가요?
Gemini 시리즈는 영어의 의미론적 해석이 더 안정적입니다. 중국어 동사와 순번 참조("참조 이미지 X")는 토큰화 과정에서 '목표 출력물 지시'로 오해받기 쉽습니다. 핵심 편집 지시어(transform, preserve, apply 등)는 영어로 작성하고, 상황 묘사는 중영문을 혼용하는 것을 권장합니다. 이렇게 하면 중국어의 섬세한 표현력을 유지하면서도 동사가 오해받는 상황을 피할 수 있습니다.
Q2: 참조 이미지를 모두 2MB 이하로 줄이면 해결되나요?
이미지 압축은 원인 5(다운샘플링 왜곡)를 완화할 뿐, 프롬프트와 가로세로 비율 충돌 문제를 해결하지는 못합니다. 압축 + 프롬프트 재작성 + 업로드 순서 제어라는 세 가지 단계를 모두 수행하는 것이 좋습니다. 업무량이 많다면 호출 전 전처리 과정을 통해 참조 이미지를 JPG로 변환하고 2~5MB로 압축한 뒤 모델을 호출하세요.
Q3: Nano Banana Pro와 Nano Banana 2 중 다중 이미지 편집에 더 적합한 것은 무엇인가요?
| 모델 | 다중 이미지 안정성 | 디테일 유지력 | 적합한 시나리오 |
|---|---|---|---|
| Nano Banana Pro (Gemini 3 Pro Image) | 보통(최근 변동성 있음) | 높음 | 고품질 단일 이미지 편집, 브랜드 이미지 |
| Nano Banana 2 (Gemini 3.1 Flash Image) | 높음 | 보통(약간의 플라스틱 질감) | 대량 이미지 생성, 이커머스 이미지 |
실무적으로 디테일 요구 사항이 매우 높다면(건축 렌더링, 고충실도 제품 이미지 등), Nano Banana 2로 안정적인 결과물을 먼저 뽑은 뒤 Nano Banana Pro로 정밀 보정하는 방식을 추천합니다. 이러한 '초안 + 정밀 보정' 계층화 방식은 안정성과 품질을 모두 챙길 수 있습니다.
Q4: "원본 이미지 그대로 출력"되는 현상이 발생할 때, 재시도하면 해결되나요?
피크 시간대의 인프라 성능 저하 문제라면 1~3회 재시도로 해결될 수 있습니다. 하지만 프롬프트나 파라미터 문제라면 100번을 재시도해도 결과는 같습니다. 판단 방법은 간단합니다. 동일한 파라미터로 시간대를 바꿔가며 계속 실패한다면 프롬프트 쪽을 점검해야 합니다. 반대로 시간대가 바뀌었을 때 정상 작동한다면 일시적인 성능 저하로 볼 수 있습니다.
Q5: 이 수정 방안은 다른 이미지 생성 모델(Flux Kontext, Seedream 등)에도 적용되나요?
프롬프트 개선 부분(의미론적 명명, 편집 동사, 역할 분담, 긍정적 묘사)은 모든 주요 이미지 생성 모델에 적용됩니다. 하지만 "마지막 이미지가 가로세로 비율을 주도한다"는 규칙은 Nano Banana 시리즈만의 고유 규칙입니다. Flux나 Seedream은 각자의 참조 이미지 가중치 메커니즘을 가지고 있습니다. 여러 모델을 사용 중이라면 APIYI(apiyi.com)의 통합 인터페이스를 통해 프롬프트 템플릿 하나만 관리하고, 파라미터 차이를 통해 각 모델에 최적화하는 방식을 권장합니다.
요약
Nano Banana Pro에서 원본 이미지가 반환되는 현상은 단순한 버그가 아니라, '다중 이미지 입력 + 모호한 프롬프트 + 인프라 변동성'이 모델의 기본 동작과 결합하여 발생하는 결과입니다. 모델이 '마지막 이미지'를 우선시하는 경향, 편집 동사에 대한 의존도, 그리고 참조 이미지의 해상도를 다운샘플링하는 전략을 이해한다면, 프롬프트의 80%만 수정해도 실패 사례의 90%를 해결할 수 있습니다.
주택 렌더링, 제품 이미지, 이메일 커머스용 이미지 합성 등 다중 이미지를 다루는 팀이라면, 앞서 언급한 8가지 해결 방안을 프롬프트 템플릿과 호출 규격으로 정립하여 프로덕션 환경에 고착화하는 것을 권장합니다. 장기적으로는 재실행 비용과 수작업 재작업률을 크게 낮출 수 있으며, Nano Banana Pro의 고품질 출력 성능을 비즈니스에 제대로 활용할 수 있게 될 것입니다.
본 글은 APIYI 팀이 정리하였으며, AI 대규모 언어 모델 API의 실전 활용에 집중하고 있습니다. Nano Banana Pro의 최신 호출 예제와 안정성 데이터가 궁금하시다면 APIYI 공식 홈페이지 apiyi.com을 방문해 주세요.
