Nano Banana 2.1 다중 라운드 편집 튜토리얼: 2회 연속 이미지 수정에서도 디테일을 잃지 않는 3가지 전달 요소

작성자 주: ‘왕관을 빨간 모자로 바꾸고, 분홍색 하트를 파란색으로 바꾸는’ 전체 사례를 통해 Nano Banana 2.1에서 여러 차례 편집할 때 매 라운드마다 대화 기록, 이전 라운드의 이미지, 사고 서명을 어떻게 다시 전달해야 하는지 설명해요. 이전 라운드의 결과를 유지하면서 특정 부분만 수정하는 방법을 알아봅니다.

gemini-nano-banana-2.1로 이미지를 처음 수정하는 개발자라면 비슷한 문제를 겪기 쉬워요. 첫 번째 수정은 잘됐는데, 두 번째 라운드에서 작은 부분만 더 다듬으려다가 앞선 수정이 ‘덮어써지거나’ 이미지 전체가 새로운 스타일로 다시 그려지는 경우죠. 이 글에서는 Nano Banana 2.1에서 여러 차례 이미지를 편집할 때 올바르게 데이터를 다시 전달하는 방법을 소개해요. 세부 사항을 유지하면서 이미지를 두 차례 연속으로 수정할 수 있도록 도와드릴게요.

개념만 설명하는 글이 아니에요. 누구나 재현할 수 있는 사례를 중심으로 살펴봅니다. 첫 번째 라운드에서는 캐릭터 머리 위의 왕관을 빨간 모자로 바꾸고, 두 번째 라운드에서는 빨간 모자를 그대로 둔 채 분홍색 하트만 파란색으로 바꿔요. 두 차례 요청에 필요한 전체 코드와 각 라운드에서 전달해야 하는 데이터도 함께 살펴봅니다.

핵심 가치: 이 글을 읽고 나면 Nano Banana 2.1의 다중 라운드 편집 방식과 매 요청마다 다시 전달해야 하는 세 가지 요소를 이해하고, 코드를 바로 활용해 특정 부분을 연속으로 수정할 수 있어요.

Nano Banana 2.1 다중 편집의 핵심

먼저 개념을 정확히 짚고 넘어갈게요. Nano Banana 2.1의 ‘네이티브 다중 편집’은 더 엄밀히 말하면 ‘연속 편집’이에요. 매 회차는 서로 독립된 API 요청이며, 모델이 이전 회차에서 무엇을 바꿨는지 ‘기억’하는 이유는 요청에 전체 대화 맥락을 다시 포함하기 때문이에요. 서버가 대신 세션을 저장해 주는 것은 아니에요.

Nano Banana 2.1 다중 편집에서 세부 요소가 ‘사라지는’ 이유

가장 흔한 실수는 두 번째 요청에 “분홍색 하트를 파란색으로 바꿔”라는 문장만 보내고 원본 이미지를 첨부하는 거예요. 그러면 모델은 여전히 왕관을 쓴 원본 이미지를 보게 되므로 왕관은 그대로 남고, 첫 번째 회차에서 씌운 빨간 모자는 사라져요. 또 다른 실수는 첫 번째 회차의 출력 이미지만 첨부하고 대화 기록은 보내지 않는 거예요. 이 경우 모델은 빨간 모자를 쓴 이미지를 받긴 하지만, 그 모자가 ‘방금 의도적으로 바꿔서 유지해야 하는 요소’라는 사실은 알지 못해요. 그래서 두 번째 회차에서 모자의 색이나 모양을 함께 바꿔 버릴 수 있어요.

안정적으로 편집하려면 첫 번째 회차의 전체 상호작용을 대화 기록으로 다시 전달해야 해요. 사용자가 무엇을 말했는지, 모델이 어떤 이미지를 반환했는지, 모델 응답에 어떤 서명이 포함됐는지를 모두 보내야 하죠. 이미지 편집의 다중 회차 시나리오에 관한 Google 공식 문서도 같은 방식으로 설명해요. 대화 기록에 포함된 서명을 통해 모델이 추론 맥락을 이어 가므로, 지정한 부분만 수정할 수 있어요.

Nano Banana 2.1 다중 편집의 요청 구조

두 번째 요청의 contents는 시간순으로 배열된 항목으로 구성되며, 최소 세 부분이 포함돼요. 첫 번째 회차의 user 메시지(원본 이미지와 지시), 첫 번째 회차의 model 응답(출력 이미지와 서명 포함), 그리고 두 번째 회차의 새로운 user 지시예요. 핵심은 model 응답 부분을 ‘원래 그대로 재생’하는 거예요. 이미지 base64만 추출해 다시 구성하면 변환 과정에서 서명 필드가 누락되기 쉬워요.

Nano Banana 2.1 멀티턴 편집 빠르게 시작하기

아래에서는 Python과 requests 라이브러리로 Gemini 네이티브 generateContent 형식을 직접 호출해요. OpenAI 호환 chat 형식을 사용하지 않는 이유는 멀티턴 편집에서 thought signature와 이미지 파트를 다시 전달해야 하기 때문이에요. 네이티브 형식을 사용하면 이러한 필드를 원래 구조 그대로 최대한 보존할 수 있어요.

준비물 체크리스트

간단한 예시: 1라운드에서 왕관을 빨간 모자로 바꾸기

첫 번째 라운드는 일반적인 이미지 편집 요청이에요. user 메시지 하나에 원본 이미지와 지시를 담으면 돼요. 중요한 점은 반환된 model 내용을 통째로 저장해 두는 거예요. 다음 라운드에서 다시 사용해야 하니까요.

import base64, requests

BASE_URL = "https://api.apiyi.com/v1"  # APIYI 统一接口，原生格式路径以文档中心说明为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}

img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

resp = requests.post(URL, headers=HEADERS, json={
    "contents": [user1],
    "generationConfig": {"responseModalities": ["TEXT", "IMAGE"]}}).json()
model1 = resp["candidates"][0]["content"]  # 原样保存，含图片和 thoughtSignature

여기서 가장 주의 깊게 볼 부분은 마지막 줄이에요. model1에는 이미지 데이터만 추출하는 대신 candidates[0].content 객체 전체를 그대로 담아요. 이 객체의 parts에는 텍스트, 이미지, thoughtSignature 필드가 함께 들어 있을 수 있어요. 원본 그대로 저장하면 어느 항목도 빠뜨리지 않을 수 있죠.

전체 예시: 2라운드에서 분홍색 하트만 파란색으로 바꾸고 빨간 모자는 유지하기

두 번째 라운드의 핵심은 contents를 [user1, model1, user2] 순서로 구성하는 거예요. 아래 전체 코드에는 두 차례의 호출, 서명 확인, 이미지 저장이 포함되어 있어 바로 실행할 수 있어요.

import base64
import requests

BASE_URL = "https://api.apiyi.com/v1"  # 通过 APIYI 调用，原生格式路径以 docs.apiyi.com 为准
API_KEY = "YOUR_API_KEY"
MODEL = "gemini-nano-banana-2.1"
URL = f"{BASE_URL}/models/{MODEL}:generateContent"
HEADERS = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
GEN_CONFIG = {"responseModalities": ["TEXT", "IMAGE"]}


def call(contents):
    """发送一次 generateContent 请求，返回 model 回复的完整 content 对象"""
    r = requests.post(URL, headers=HEADERS,
                      json={"contents": contents, "generationConfig": GEN_CONFIG},
                      timeout=180)
    r.raise_for_status()
    return r.json()["candidates"][0]["content"]


def save_image(content, path):
    """从 model 回复中取出图片并保存"""
    for part in content.get("parts", []):
        data = part.get("inlineData") or part.get("inline_data")
        if data:
            open(path, "wb").write(base64.b64decode(data["data"]))
            return True
    return False


def has_signature(content):
    """检查回复中是否带有思维签名"""
    return any("thoughtSignature" in p or "thought_signature" in p
               for p in content.get("parts", []))


# ---------- 第 1 轮：皇冠 → 红帽 ----------
img_b64 = base64.b64encode(open("origin.png", "rb").read()).decode()
user1 = {"role": "user", "parts": [
    {"inline_data": {"mime_type": "image/png", "data": img_b64}},
    {"text": "把角色头上的皇冠换成一顶红色的帽子，其他内容保持不变。"}]}

model1 = call([user1])
save_image(model1, "round1_red_hat.png")
print("第 1 轮签名存在:", has_signature(model1))

# ---------- 第 2 轮：粉心 → 蓝心，保留红帽 ----------
user2 = {"role": "user", "parts": [
    {"text": "在上一张图的基础上，只把胸前的粉色爱心改成蓝色。"
             "红色帽子和其他所有细节保持不变。"}]}

# 关键：完整历史 + 原样回传的 model1（含上一轮图片与签名）
history = [user1, model1, user2]
model2 = call(history)
save_image(model2, "round2_blue_heart.png")
print("第 2 轮签名存在:", has_signature(model2))

# 如需第 3 轮，继续追加：history += [model2, user3]

🚀 빠른 시작: 먼저 APIYI apiyi.com의 무료 테스트 크레딧으로 위의 2라운드 코드를 실행해 보세요. 2라운드 이미지에서 빨간 모자가 그대로 유지되고 하트 색만 바뀌는지 확인한 뒤, 실제 업무 흐름에 적용하면 돼요.

2차 지시문 작성 팁

연속 편집에서 ‘일부만 수정’할 수 있는지는 이전 대화 내용을 전달하는 구조뿐 아니라 지시문 작성 방식에도 영향을 받아요. 2차 지시문에는 다음 세 가지를 모두 명확하게 적는 것이 좋아요. 어떤 이미지를 바탕으로 수정할지, 어디를 수정할지, 무엇을 반드시 그대로 유지할지예요. 예를 들어 “이전 이미지에서 분홍색 하트만 파란색으로 바꾸고, 빨간 모자와 다른 세부 요소는 그대로 유지해 줘”라고 하면 단순히 “파란색으로 바꿔 줘”라고 하는 것보다 결과가 훨씬 안정적이에요.

또한 2차 요청에는 원본 이미지를 다시 첨부하지 마세요. 원본 이미지는 이미 user1에 포함되어 있어요. user2에 같은 이미지를 한 번 더 넣으면 모델이 이를 새로운 참조 대상으로 이해해 오히려 왕관이 있던 버전으로 돌아갈 수 있어요.

Nano Banana 2.1 멀티턴 편집에서 이전 대화를 전달하는 세 가지 방식 비교

왜 ‘세 가지 요소를 모두 갖춰야’ 하는지 설명하기 위해 흔히 사용하는 세 가지 방식을 함께 비교해 봤어요. 아래 표는 각 방식에서 나타나는 동작을 정성적으로 정리한 것으로, 어떤 방식으로 코드를 작성했는지 빠르게 확인하는 데 도움이 돼요.

비교 결과 해석

방식 A 비교 분석: 방식 A는 구현이 가장 간단하고, 매번 독립적인 요청을 보낸다는 장점이 있어요. 하지만 모델이 1차 결과를 전혀 볼 수 없기 때문에, 결국 단일 라운드 편집을 다시 하는 것과 같아요. 반면 전체 대화 기록을 전달하면 2차 편집을 1차 결과에 이어서 진행할 수 있어요.

방식 B 비교 분석: 방식 B는 이미지 한 장만 전송하므로 요청 크기를 줄일 수 있어요. 하지만 모델은 ‘빨간 모자가 의도적으로 수정된 것’이라는 맥락을 알 수 없고, 서명도 전달받지 못해 부분적인 일관성을 보장하기 어려워요. 디자인 시안이나 이커머스 대표 이미지처럼 여러 차례 세밀하게 수정해야 하는 작업에는 방식 C가 더 안정적인 선택이에요.

💡 선택 가이드: 두 차례 이상 연속으로 수정해야 하는 서비스라면 처음부터 방식 C를 사용하는 것을 권장해요. APIYI apiyi.com에서 같은 코드로 세 가지 방식을 각각 실행해 결과 이미지를 비교해 보면 차이를 쉽게 확인할 수 있어요.

Nano Banana 2.1과 같은 시리즈 모델 중 선택하기

APIYI에서 제공하는 Nano Banana 시리즈에는 여러 모델이 있어요. 연속 편집은 편집 기능을 한 단계 더 깊이 활용하는 방식이에요. 아래 표를 참고해 시리즈 안에서 적합한 모델을 찾아보세요.

Nano Banana 2.1 다중 턴 편집에서 자주 발생하는 문제

실제 연동 과정에서 “수정한 내용이 사라지는” 문제는 대부분 몇 가지 원인으로 좁혀져요. 자주 발생하는 순서대로 정리했으니, 문제를 확인할 때 하나씩 점검해 보세요.

1. 서명 누락: 모델 응답을 자체 데이터 구조로 변환한 뒤 다시 조합하면서 필드명의 대소문자나 중첩 구조가 바뀌어 thoughtSignature가 전달되지 않는 경우예요. 원본 content 객체를 그대로 저장하고 다시 전달하면 해결할 수 있어요.
2. 잘못된 역할 지정: 첫 번째 턴의 모델 응답을 user 역할로 지정하면 모델이 자신의 출력을 사용자가 새로 업로드한 이미지로 인식해요. 모델 응답의 역할은 반드시 role: model로 유지해야 해요.
3. 순서 뒤바뀜: contents는 시간순으로 정렬해야 해요. user1, model1, user2 순서로 배치하고, 새 지시를 맨 앞에 넣으면 안 돼요.
4. 형식 혼용: 이전 턴에서는 OpenAI 호환 형식을 사용하고 다음 턴에서는 네이티브 형식으로 바꾸면, 중간에 필드를 변환하는 과정에서 서명이 누락될 수 있어요. 다중 턴 전체 과정에서 Gemini 네이티브 형식을 일관되게 사용하는 것을 권장해요.
5. 대화 기록이 너무 긴 경우: 턴이 늘어날수록 요청에 포함되는 이미지가 많아져 데이터 용량과 처리 시간이 함께 증가해요. 두세 턴을 넘는 긴 작업이라면, 중요한 단계에서 현재 결과를 새로운 원본 이미지로 삼아 대화 기록을 새로 시작하는 방법을 고려해 보세요.

🎯 기술 제안: 문제를 점검할 때 먼저 model1의 parts 구조를 출력해 thoughtSignature 필드가 있는지 확인하고, 두 번째 턴 요청 본문에도 해당 필드가 원본 그대로 포함되어 있는지 살펴보세요. APIYI apiyi.com 문서 센터의 Gemini 네이티브 형식 및 다중 턴 대화 구성 예제를 참고해 비교해 볼 수 있어요.

자주 묻는 질문 FAQ

Nano Banana 2.1 멀티턴 편집 핵심 요점

• 본질은 연속 편집이에요: 각 라운드는 독립적인 요청이며, 클라이언트가 컨텍스트를 다시 전달해 대화 흐름을 이어가요.
• 세 가지 요소가 모두 필요해요: 전체 대화 기록, 이전 라운드의 출력 이미지, 사고 서명이 필요해요.
• model 콘텐츠를 그대로 다시 전달하세요: candidates[0].content를 그대로 저장하면 서명이 누락되는 일을 방지할 수 있어요.
• 네이티브 형식을 사용하세요: generateContent의 contents 구조가 이미지와 서명을 다시 전달하기에 가장 적합해요.
• 유지할 항목을 명확히 지시하세요: 두 번째 라운드에서 “어디만 바꿀지, 무엇은 그대로 둘지”를 분명히 지정하면 부분 수정이 더 안정적이에요.
• 원본 이미지를 반복해서 첨부하지 마세요: 두 번째 라운드에 원본 이미지를 첨부하면 모델이 수정 전 버전으로 돌아갈 수 있어요.
• 적은 비용으로 검증할 수 있어요: APIYI apiyi.com의 무료 사용량으로 두 라운드 편집을 먼저 테스트한 뒤 실제 서비스에 적용해 보세요.

요약

Nano Banana 2.1 멀티턴 편집의 핵심은 다음과 같아요.

1. 작동 방식: 멀티턴 편집은 클라이언트가 이전 내용을 다시 전달해 이어가는 연속 편집이에요. 서버가 자동으로 기억한다는 점은 아직 검증되지 않았으므로 이에 의존하면 안 돼요.
2. 다시 전달할 내용: 두 번째 라운드 요청에는 user1, 이미지와 사고 서명이 포함된 model1 원본, user2가 들어가야 해요.
3. 실전 팁: Gemini 네이티브 형식을 일관되게 사용하고, 지시문에 유지할 항목을 명시하세요. 새 라운드에서 원본 이미지를 반복해서 첨부하지 않는 것도 중요해요.

이 세 가지를 익히면 “왕관을 빨간 모자로 바꾸고, 이어서 분홍색 하트를 파란색으로 바꾸는” 식의 2단계 연속 이미지 편집을 안정적으로 재현할 수 있어요. 같은 구조를 여러 라운드로 확장하는 것도 가능해요.

APIYI apiyi.com을 통해 효과를 빠르게 검증해 보세요. 이 플랫폼은 OpenAI 호환 형식과 Gemini 네이티브 형식의 API를 제공해요. API 키 하나로 Nano Banana 시리즈를 비롯한 주요 모델을 호출할 수 있고, 사용량에 따라 요금이 부과돼 소규모 테스트 후 점진적으로 프로덕션에 도입하기에 적합해요.

📚 참고 자료

1. Google Gemini API 이미지 생성 및 편집 문서: 공식 멀티턴 이미지 편집 안내
2. 링크: ai.google.dev/gemini-api/docs/image-generation

3. 설명: 이미지 편집 요청 구조와 연속 편집을 위한 대화 방식을 소개해요.

4. Google Gemini API 사고 서명 문서: thought signature 메커니즘 안내

5. 링크: ai.google.dev/gemini-api/docs/thought-signatures

6. 설명: 서명의 역할과 멀티턴 요청에서 서명을 다시 전달하는 방법을 설명해요.

7. APIYI 문서 센터: Nano Banana 시리즈 개발 가이드, 멀티턴 대화 구현 가이드, Gemini 네이티브 형식 호출 가이드

8. 링크: docs.apiyi.com
9. 설명: 접속 엔드포인트, 네이티브 형식 경로, 대화 이력 구성 예제를 제공하며, 이 글의 코드 구현을 위한 참고 자료예요.

작성자: APIYI 기술팀
기술 문의: APIYI 웹사이트 첫 화면에서 문의해 주세요. Nano Banana 시리즈 연동 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있어요.

관련 글

• Nano Banana 2 vs 2.1 텍스트 렌더링: 포스터 5종 실측 비교 및 선택 체크리스트: Nano Banana 2.1이 텍스트 렌더링이 더 좋다고들 하는데, 왜 어떤 사람들은 2세대가 더 정확하다고 느낄까요? 재현 가능한 포스터 시나리오 5가지와 검수 기준, 건당 가격을 통해 언제 바꿔야 하고 언제 바꾸지 않아도 되는지 설명해 주세요.
• Nano Banana 2.1은 무엇이 개선되었을까? 6가지 주요 업그레이드 분석 및 Nano Banana Pro와의 성능 비교: Nano Banana 2.1은 Nano Banana 2의 업그레이드 버전으로 공식 벤치마크 점수에서 Nano Banana Pro를 넘어섰지만 실제 이미지 생성에서도 정말 더 뛰어난지 살펴보고, 이 글에서는 6가지 주요 개선 사항과 공식 및 제3자 평가 데이터를 분석해 Nano Banana 2.1과 Pro의 상황별 선택 가이드를 제공합니다.
• Nano Banana 2.1 가격 완벽 분석: Nano Banana 2와의 5가지 핵심 차이점 비교 및 비용 절감 계산: Google 공식 가격 페이지를 바탕으로 Nano Banana 2.1 가격을 분석해 이미지 출력 단가는 절반으로 낮아졌지만 입력 및 사고 토큰 가격은 인상되고 4K 사용량은 증가했으며 0.5K 등급은 폐지되었음을 살펴보고, 1K/2K/4K 단일 이미지 비용과 Batch 가격, 손익분기점 및 마이그레이션 권장 사항을 제공합니다.
• 이미지 한 장으로 300만 명을 속였다고? GPT Image 2.5로 AI 풍자 가짜 다큐멘터리 여행 이미지를 만드는 2단계 튜토리얼: Wytse Koetse의 파리 풍자 영상을 분석하고, 먼저 GPT로 구조화된 프롬프트를 작성한 다음 gpt-image-2.5-sunburst 또는 gemini-nano-banana-2.1을 사용해 ‘가짜 여행 광고 말투’의 의사 다큐멘터리 스틸 이미지를 일괄 생성하세요.