Gemini AI 사진 프롬프트 생성기: 모델 히스토리, 네이티브 멀티모달리티, 그리고 제대로 된 평가 계획

출시 이력: 이미지 생성 프리뷰에서 Nano Banana 패밀리까지

Google은 2025년 5월 7일 Gemini 2.0 Flash Preview Image Generation을 통해 Gemini API에 이미지 생성 기능을 공개했습니다. 같은 날 Gemini 2.5 Flash Image 프리뷰가 뒤이어 나왔고, 2025년 10월 2일 Nano Banana라는 이름으로 정식 출시(GA)되었습니다. 이제 안정 버전인 2.5 모델은 더 큰 패밀리 안에서 레거시 위치에 있으며, 처리량을 위한 Gemini 3.1 Flash Lite Image, 성능·비용·지연 시간의 전반적인 균형을 위한 Gemini 3.1 Flash Image, 복잡한 전문 작업을 위한 Gemini 3 Pro Image로 구성되어 있습니다.

이 이력은 실무적으로 중요합니다. 2.5 모델에 맞춰 튜닝된 프롬프트가 영원한 기준이 되는 것은 아닙니다. 모델 별칭, 출력 해상도, 레퍼런스 이미지 제한, 지원 종료 일정은 계속 바뀝니다. 결과를 비교할 때는 반드시 정확한 모델 식별자와 날짜를 기록하고, 마케팅용 이름을 재현성의 기준으로 삼지 마세요.

핵심 기술 개념: 네이티브 멀티모달 생성-편집 루프

Google은 Gemini 2.5 Flash Image를 네이티브 멀티모달 모델이라고 설명합니다. 텍스트와 이미지는 별도의 캡셔닝 단계와 그 뒤를 잇는 독립된 이미지 모델로 나뉘어 처리되는 것이 아니라, 하나의 통합된 워크플로 안에서 처리됩니다. 실무적으로 이는 하나의 대화 맥락 안에 지시문, 하나 이상의 레퍼런스, 그리고 일련의 편집 과정이 모두 담길 수 있다는 것을 의미합니다.

이는 모델이 모든 픽셀이나 정체성을 완벽하게 보존한다는 뜻은 아닙니다. 이미지 입력이 1급(first-class) 조건화 신호로 취급된다는 뜻입니다. 실무에서는 각 레퍼런스의 역할을 프롬프트에 명시해야 합니다. 어느 이미지가 피사체를 제공하는지, 어느 이미지가 재질이나 팔레트를 제공하는지, 그리고 어떤 속성이 변하지 않아야 하는지를 밝혀야 합니다. 모호한 멀티 이미지 프롬프트는 사용자가 명시하지 않은 디자인 충돌을 모델이 알아서 해결하도록 떠넘기는 것과 같습니다.

공식 문서가 실제로 말하는 것

현재 Gemini 이미지 가이드는 텍스트-투-이미지, 텍스트와 이미지를 함께 사용한 편집, 멀티 이미지 합성, 설정 가능한 종횡비, 그리고 상위 등급인 Gemini 3 모델에서 최대 4K까지의 출력 해상도를 문서화하고 있습니다. 또한 일부 Gemini 3 이미지 모델에 대해 검색 그라운딩(search grounding)과 사고 과정(thinking process)도 설명합니다. 이는 어디까지나 제품 기능에 대한 설명일 뿐, 모델 아키텍처, 학습 데이터, 파라미터 수, 디퓨전/디코더 설계에 대한 공개된 정보가 아닙니다. Google은 인용된 제품 문서에서 이러한 구현 세부 사항을 제공하지 않았습니다.

같은 문서는 실제 프롬프트 설계에 반영해야 할 명확한 제한도 제시합니다. Gemini 2.5 Flash Image는 입력 이미지가 최대 3장일 때 가장 잘 작동합니다. Gemini 3 Pro Image는 고충실도 레퍼런스 이미지 최대 5장, 전체 입력 최대 14장을 지원하며, Gemini 3.1 Flash Image는 캐릭터 유사성과 사물 충실도에 대해 각각 별도의 제한을 문서화하고 있습니다. 생성되는 모든 이미지에는 SynthID 워터마크가 포함됩니다.

평가: 지시 이행과 이미지 선호도를 분리하기

미적 선호도만으로는 프롬프트 생성기를 평가하기에 충분하지 않습니다. 서로 다른 능력을 개별적으로 검증할 수 있는 고정된 테스트용 브리프 세트를 구성하세요. 단일 피사체 충실도, 정확한 텍스트, 제한된 편집, 사물 개수의 정확성, 다중 레퍼런스 합성, 캐릭터 일관성, 종횡비 준수 등입니다. 각 브리프마다 모델, 사이즈, 가능하다면 시드(seed) 설정, 레퍼런스 입력을 고정하고, 테스트하려는 프롬프트 구성 방식만 변화시키세요.

각 결과물은 단순한 승패 판정이 아니라 루브릭(rubric)에 따라 채점하세요. 유용한 루브릭에는 요구 사항 충족도, 보호해야 할 요소의 보존, 텍스트 정확도, 공간적 정확성, 원치 않는 아티팩트, 최종 시각적 품질이 포함됩니다. 취향이 개입되는 판단에는 블라인드 처리된 인간 쌍대 비교(pairwise comparison)를 사용하고, 프롬프트 수, 프롬프트당 이미지 수, 평가자 수, 신뢰 구간을 함께 보고하세요. 이런 세부 정보가 없다면 리더보드 스크린샷은 단지 선호도 표본의 근거일 뿐, 일반적인 우월성을 입증하는 자료가 될 수 없습니다.

• 지시 이행 범위: 명시적으로 요구된 요소가 모두 나타났는가, 그리고 금지된 요소는 모두 제외되었는가?
• 편집의 국소성: 요청한 변경이 정체성, 레이아웃, 스타일의 불필요한 변화 없이 이루어졌는가?
• 레퍼런스 충실도: 결과물이 단순히 입력 이미지 중 하나를 닮은 것이 아니라, 각 입력 이미지에 지정된 역할을 실제로 보존했는가?
• 운영 비용: API 호출당 비용뿐 아니라 지연 시간, 실패율, 재시도 횟수, 승인된 결과물 기준 실질 비용까지 측정하라.

사진 워크플로에서 프롬프트를 작성하는 방법

장면 명세부터 시작하세요. 피사체, 환경, 카메라/프레이밍, 조명, 재질 단서, 의도한 출력 형식을 명시합니다. 그다음 명확한 제약 조건과 간결한 편집 계약(edit contract)을 추가합니다. 복잡한 작업의 경우, 처음 요청에 가능한 모든 변경 사항을 한꺼번에 쌓아 넣기보다는 짧은 첫 시도로 구도를 먼저 확립한 다음, 목표가 명확한 후속 편집을 한 번 진행하는 방식이 좋습니다.

사진 프롬프트 생성기에서 가장 가치 있는 결과물은 최대한 길게 쓴 문단이 아닙니다. 검증 가능한 결정들, 즉 피사체가 무엇인지, 어떤 시각적 속성이 타협 불가능한지, 편집 전반에 걸쳐 무엇이 그대로 유지되어야 하는지, 어떤 형식이 요구되는지를 담아낸 프롬프트입니다. Gemini의 멀티모달 워크플로는 이러한 구조가 레퍼런스의 역할을 명확하게 만들 때 가장 강력하게 작동합니다.