Reddit Nano Banana 프롬프트: 문장보다 구조를 복사하고 테스트하기

Reddit에서 공유되는 Nano Banana 프롬프트는 실제 사용자가 제품 사진, 캐릭터, 광고, 정보 보드, 편집, 참조 이미지, 실패 상황을 어떻게 말로 옮기는지 보여준다. 하지만 다른 사람이 올린 결과가 좋아 보였다고 해서, 그 문장이 내 제품, 인물, 브랜드, 비율, 이미지 안의 텍스트, 참조 자료, API 작업에서도 그대로 통한다는 뜻은 아니다.

실무에서는 Reddit을 정답 창고가 아니라 원재료 창고로 보는 편이 맞다. 남길 것은 문장 전체가 아니라 이미지의 목적, 시각 구조, 사용할 경로, 보호해야 할 제약, 실패했을 때 바꿀 행동이다.

2026년 5월 18일 기준으로 경로와 모델 ID 같은 사실은 Google 공식 자료를 기준으로 확인해야 한다. 개발자 맥락에서 Nano Banana 2는 gemini-3.1-flash-image-preview, Nano Banana Pro는 gemini-3-pro-image-preview, 원래 Nano Banana는 gemini-2.5-flash-image와 연결된다. Reddit은 표현과 실패 사례를 배우는 곳이고, 모델 이름, 접근 경로, 가격, 무료 경계, 안전 동작을 확정하는 곳은 아니다.

같은 구조를 내 작업에 두 번 적용했는데 실패한다면, 형용사를 더 붙이기 전에 경로를 의심해야 한다. 글자가 틀어지는지, 인물 일관성이 무너지는지, 제품 형태가 바뀌는지, 편집 범위가 넓어지는지, API에서 재현되지 않는지, 안전 차단이 걸리는지 먼저 분류한다.

먼저 이미지의 일을 정한다

좋은 프롬프트는 스타일보다 작업 목표가 먼저 보인다. 제품 hero 이미지, 캐릭터 설정, 광고 시안, 실내 이미지, 음식 사진, 정보 보드, 부분 편집, 표지, 스토리보드, API 일괄 생성은 서로 다른 지시가 필요하다.

“고급스럽게 만들어줘”만으로는 약하다. 고급스러움을 만드는 것은 재질, 배치, 빛, 여백, 배경, 카메라 거리다. “무광 검정 데스크 램프를 월넛 책상 위에 두고, 왼쪽에서 부드러운 조명, 오른쪽에는 제목 여백”이라고 쓰면 모델은 무엇을 지켜야 하는지 더 잘 이해한다.

저장 전 세 가지 태그를 붙인다.

이 세 가지가 비어 있으면 그 문장은 영감에 가깝다. 작업 라이브러리에는 넣지 않는 편이 좋다.

경로를 고른 뒤 문장을 늘린다

Nano Banana라는 이름만으로는 충분하지 않다. 빠른 아이디어 생성, 참조 이미지 유지, 텍스트가 많은 레이아웃, 여러 이미지의 일관성, API 재현성은 각각 다른 문제다.

Gemini 앱은 시각 방향을 빠르게 볼 때 좋다. 분위기, 색, 구도, 카메라 느낌을 즉시 시험할 수 있다. 하지만 요청 기록, 모델 ID, 배치 처리, 재시도, 비용 관리까지 포함한 생산 환경의 증거로 쓰기에는 부족하다.

참조 이미지 편집은 제품, 얼굴, 옷, 방, 자세, 패키지, 기존 소재를 지켜야 할 때 필요하다. 이때는 무엇을 바꾸지 말아야 하는지를 먼저 쓴다. 스타일 단어를 잔뜩 쓴 뒤 마지막에 “같은 사람으로”를 붙이는 방식은 흔히 불안정하다.

Nano Banana Pro는 이미지 안에 정확한 문자, 표, 단계, 라벨, 설명 보드, 문서형 레이아웃이 있을 때 더 적합하다. 모든 이미지에 Pro가 정답은 아니다. 단순한 분위기 탐색이라면 짧고 깨끗한 자연어가 더 빠를 때도 많다.

AI Studio나 API는 모델 ID, 요청 형태, 로그, 실패 처리, 저장, 비용, 권한이 필요한 작업 경로다. 앱에서 잘 된 문장은 API에서 같은 동작을 보장하지 않는다.

프롬프트를 구조로 분해한다

재사용 가능한 프롬프트는 형용사 더미가 아니다. 무엇을 만들지, 무엇을 지킬지, 무엇을 바꿔도 되는지, 무엇을 보면 합격인지가 나뉘어 있어야 한다.

저장 형식은 다음처럼 잡는다.

hljs text复制
이미지 목표:
주제와 맥락:
구도와 카메라:
빛과 색감:
스타일 또는 형식:
반드시 지킬 요소:
피해야 할 실패:
경로 또는 파라미터:
검증 기준:

이 형식은 주제를 바꿔도 유지된다. 남의 “네온 비 오는 사이버펑크 전사”가 필요한 것이 아니라, 특정 주제, 환경, 빛, 시점, 제약, 합격 조건을 조합하는 방식이 필요한 것이다. 주제를 내 제품이나 캐릭터로 바꾸고, 장면과 검증 기준을 내 용도에 맞게 바꿀 때 비로소 내 프롬프트가 된다.

쓸 만한 패턴을 작업별로 저장한다

커뮤니티 예시는 마법 문장이 아니라 작업 카테고리로 읽어야 한다. 각 카테고리에서 남길 것은 구조이고, 그대로 남길 것은 장식어가 아니다.

제품 hero 이미지

hljs text复制
[제품]을 [표면/환경]에 둔 상업용 hero 이미지를 만든다.
[조명], [그림자], [배경 처리]를 사용한다.
카메라는 [각도]이고 제품이 주인공이어야 한다.
추가 로고, 손, 읽기 어려운 문자, 제품 형태 변화는 넣지 않는다.
검증: 세 번의 출력에서 형태, 재질, 핵심 특징이 유지된다.

제품 이미지는 재질, 각도, 빛, 배경, 여백이 중요하다. “프리미엄”보다 무엇이 프리미엄으로 보이게 하는지 구체적으로 써야 한다.

캐릭터와 정체성

hljs text复制
[캐릭터]를 [장면] 안에 그린다.
[얼굴형, 머리, 옷, 나이감, 상징 물건]을 유지한다.
스타일은 [스타일], 카메라 거리는 [거리]로 한다.
나이, 얼굴 구조, 옷 색, 시그니처 물건을 바꾸지 않는다.
검증: 세 번의 출력에서 정체성 앵커가 유지된다.

한 장짜리 콘셉트라면 텍스트만으로도 충분할 수 있다. 하지만 광고 시리즈, 마스코트, 연속 컷, 스토리보드라면 참조 이미지 경로를 먼저 고려한다. 텍스트만으로 같은 인물을 오래 유지하기는 어렵다.

정보 보드

hljs text复制
[독자]에게 [주제]를 설명하는 정보 보드를 만든다.
필수 블록: [1], [2], [3], [4].
짧은 라벨, 읽기 쉬운 여백, 문서형 계층을 사용한다.
정확히 표시할 텍스트: [지정어].
가짜 숫자, 추가 라벨, 장식 소음을 넣지 않는다.
검증: 필수 텍스트가 읽히고 새로운 사실이 생기지 않는다.

문자와 구조가 중요한 작업은 Pro 경로가 더 잘 맞을 수 있다. 정확한 숫자, 가격, 한도, 법무 문구, 브랜드 카피는 모델이 자유롭게 채우게 두면 안 된다.

입력 이미지 편집

hljs text复制
입력 이미지를 편집해 [구체적 변화]만 적용한다.
[인물, 제품, 자세, 배경, 원근, 텍스트]를 유지한다.
원본의 카메라 각도, 조명 방향, 원근을 맞춘다.
새 물체, 다른 사람, 배경 재구성, 문자 변경을 피한다.
검증: 변화는 보이지만 보호 요소는 원본과 일치한다.

편집에서는 무엇을 바꾸지 않는지가 성공을 좌우한다. 결과가 예뻐도 제품이나 인물이 달라졌다면 실패다.

같은 프롬프트를 작게 검증한다

저장하기 전에 하나의 구조를 세 가지 작은 실험으로 본다. 기준 버전, 시각 변수, 경로 변수를 나누면 실패 원인을 읽기 쉽다.

1. 기준: Reddit에서 얻은 구조를 내 조건으로 깨끗하게 쓴 버전.
2. 변수 A: 빛, 카메라, 배경처럼 시각 요소 하나만 바꾼 버전.
3. 변수 B: 텍스트, 참조 이미지, 레이아웃 복잡도처럼 경로에 영향을 주는 요소 하나만 바꾼 버전.

좋고 싫음이 아니라 기준으로 평가한다.

평균 4점 이상이고, 핵심 항목이 3점 아래로 떨어지지 않으며, 실패 이유를 설명할 수 있을 때만 저장한다. 우연히 한 장이 잘 나온 것은 작업 자산이 아니다. 다시 쓸 수 있는 구조만 남긴다.

실패 기록도 함께 남긴다

성공 이미지만 저장한 라이브러리는 금방 약해진다. 필요한 것은 어디서 깨졌는지, 왜 깨졌는지, 다음에는 무엇을 바꿀지다.

실패 기록은 팀을 보호한다. 누군가 같은 예시를 다시 가져왔을 때, 어느 경로에서 실패했는지, 어떤 조건에서 통과했는지, 어디부터 위험해지는지 바로 볼 수 있다.

인기 목록을 순위처럼 보지 않는다

100개, 500개, 1000개짜리 목록은 훑어보기에는 좋다. 하지만 좋아요 수나 수집 규모는 내 소재, 언어, 브랜드, 참조 이미지, API, 정책 안에서의 안정성을 증명하지 않는다.

목록에서 읽어야 할 것은 두 가지다. 첫째, 반복되는 작업 종류다. 제품, 인물, 3D 피규어, 인포그래픽, 음식, 실내, 광고, before/after가 자주 나온다. 둘째, 반복되는 실패다. 짧은 지시, 약한 참조, Pro와 2의 차이, 텍스트 실패, 정체성 흔들림, 생성과 편집 혼동이 계속 보인다.

같은 문제가 반복된다면 필요한 것은 더 긴 문장이 아니라 경로 규칙이다. 텍스트가 중요하면 짧은 라벨과 Pro, 인물이 이어져야 하면 참조 이미지, API로 옮길 때는 모델 ID와 요청 기록. 이렇게 남기면 목록은 단순한 수집물이 아니라 작업 규칙이 된다.

팀에서 쓰는 라이브러리로 만든다

혼자 쓰는 메모라면 자유롭게 적어도 된다. 여러 사람이 쓰는 라이브러리라면 기록 형식을 맞춰야 한다. 디자이너, 에디터, 마케터, 개발자는 같은 이미지를 보고 서로 다른 실패를 볼 수 있다. 공통 언어가 없으면 “더 자연스럽게”, “더 광고처럼”, “더 깨끗하게”가 매번 다른 뜻이 된다.

짧은 실행용 프롬프트와 긴 설명 메모는 분리해 저장한다. 짧은 버전은 실행을 위한 것이고, 긴 메모는 왜 그렇게 되었는지 넘겨주기 위한 것이다. 설명이 없으면 몇 주 뒤에는 아무도 고치는 법을 기억하지 못한다.

예시를 내 작업으로 바꾸는 순서

좋은 예시를 찾았을 때는 주제만 바꾸지 않는다. 먼저 골격을 뽑고, 다음에 업무 조건을 넣고, 마지막에 검증을 붙인다.

예를 들어 커뮤니티에서 “영화 같은 커피 컵 광고”를 봤다고 하자. 이를 바로 “헤드폰 광고”로 바꾸면 약해질 수 있다. 원래 예시의 힘은 컵이 아니라 단일 주제, 가까운 카메라, 테이블 질감, 부드러운 측광, 배경 흐림, 오른쪽 여백에 있었을 수 있다. 그 골격을 먼저 적고, 헤드폰의 재질, 이어컵 각도, 케이블 유무, 브랜드 색, 포장 노출, 광고 제목 영역을 넣어야 한다.

캐릭터도 마찬가지다. 예쁜 인물 프롬프트를 봤다면 “초고화질”, “시네마틱”, “감정적”을 남길 것이 아니라 얼굴형, 머리, 의상 색, 나이감, 표정, 상징 물건, 카메라 거리, 참조 이미지 여부를 남긴다. 두 번 연속 얼굴이 달라지면 문장을 늘리는 것이 아니라 참조 경로로 옮긴다.

정보 보드는 더 엄격해야 한다. 화면 안에 가격, 한도, 모델명, 날짜, 정책, 정확한 숫자가 들어간다면, 모델이 새 사실을 만들어내지 못하게 해야 한다. 반드시 보여야 할 단어, 줄여도 되는 단어, 절대 나오면 안 되는 단어를 나눠서 써야 한다.

저장 전 마지막 점검

저장 판단을 개인 취향에 맡기지 말고, 짧은 리뷰 기준을 둔다.

이 점검은 창작을 막기 위한 것이 아니다. 저장할 가치가 있는 구조만 남기기 위한 것이다. 애매한 프롬프트는 임시 테스트 영역에 두고, 경로와 합격 조건, 실패 기록이 채워진 뒤에 채택 영역으로 옮긴다.

저장 후에도 오래된 기록은 다시 본다. 모델 이름, 경로, 기능, 가격, 무료 경계는 바뀔 수 있다. 오래된 프롬프트를 삭제할 필요는 없지만, 현재 제작에 쓰기 전에는 짧게 다시 테스트하고 공식 정보를 확인한다. 라이브러리는 고정 문서가 아니라 검증된 작업대에 가깝다.

상황별로 고치는 순서를 정한다

프롬프트를 고칠 때도 순서가 필요하다. 모든 실패에 “더 자세히”라는 답을 쓰면 원인이 가려진다. 먼저 화면에서 보이는 실패를 이름 붙이고, 그 실패가 문장 부족인지 경로 문제인지 입력 자료 문제인지 구분한다.

제품이 자꾸 달라진다면 형용사보다 보호 규칙을 먼저 본다. 제품의 각도, 재질, 로고 노출 여부, 비율, 주요 부품을 앞쪽에 써야 한다. 그래도 달라지면 텍스트 생성이 아니라 참조 이미지 편집으로 가야 한다. 제품이 실제 판매 이미지라면 “비슷한 느낌”은 통과 기준이 될 수 없다.

인물이 달라진다면 정체성 앵커를 늘리는 것만으로는 부족할 수 있다. 얼굴형, 헤어스타일, 의상, 나이감, 표정, 상징 물건을 정리하고, 두세 장 이상 이어지는 작업이면 참조 이미지를 쓴다. 스타일이 예쁜 것과 같은 사람처럼 보이는 것은 다른 문제다.

텍스트가 틀린다면 단어를 더 많이 주기보다 줄인다. 이미지 안에 넣을 문구는 짧을수록 좋고, 계층은 적을수록 안정적이다. 숫자, 가격, 한도, 정책, 모델명처럼 틀리면 안 되는 정보는 별도 검증이 필요하다. 이미지 모델이 임의로 만든 글자가 자연스러워 보여도 사실이 아닐 수 있다.

구도가 계속 어긋난다면 카메라와 여백을 따로 지정한다. “멋진 광고 이미지”보다 “정면에서 약간 위, 피사체는 왼쪽 60%, 오른쪽은 제목 여백, 배경은 낮은 대비”가 낫다. 구도 문제는 스타일 단어로 고치기 어렵다.

오래된 프롬프트를 폐기하는 기준

좋은 라이브러리는 계속 늘어나는 목록이 아니다. 오래된 항목을 남기되, 더 이상 쓰지 않을 이유도 적어야 한다. 특히 모델 이름, 경로, 비용, 무료 경계, 텍스트 처리, 참조 이미지 기능은 시간이 지나며 달라질 수 있다.

폐기 기준은 간단하게 유지한다.

폐기는 삭제와 다르다. 나중에 비교할 수 있도록 실패 이유는 남긴다. 다만 채택 영역에서 빼고, 새 작업자가 바로 쓰지 않도록 표시한다. 이렇게 해야 라이브러리가 커져도 품질은 유지된다.

좋은 프롬프트는 짧은 실행문과 긴 판단을 함께 가진다

실행할 때 쓰는 문장은 짧고 분명해야 한다. 하지만 그 문장이 왜 그런 형태가 되었는지, 어떤 경로에서 검증됐는지, 어떤 실패를 피하려는지까지 한 줄에 다 넣을 필요는 없다. 그래서 실행문과 판단 메모를 분리한다.

실행문에는 모델이 바로 따라야 할 내용만 둔다. 주제, 장면, 구도, 빛, 보호 요소, 금지 요소, 필요한 텍스트, 출력 목적이다. 판단 메모에는 왜 이 경로를 골랐는지, 어떤 Reddit 예시에서 구조를 얻었는지, 어떤 변수를 테스트했는지, 무엇 때문에 저장했는지를 적는다.

이 방식은 프롬프트를 더 깔끔하게 만든다. 실행문이 길어질수록 모델에게 중요한 신호와 내부 설명이 섞인다. 판단 메모가 따로 있으면 팀은 이유를 이해하면서도, 실제 생성에는 정리된 문장만 넣을 수 있다.

또한 새 프롬프트를 만들 때마다 기존 라이브러리와 겹치는지 본다. 같은 제품 hero 구조가 이미 있는데 주제만 바뀐 항목을 계속 추가하면, 나중에는 어떤 것이 최신인지 알 수 없다. 겹치는 항목은 새로 저장하지 말고 기존 구조에 예시와 실패 기록을 더한다. 서로 다른 작업이어야 별도 항목으로 남긴다. 예를 들어 제품 hero와 정보 보드는 다른 항목이지만, “파란색 제품 hero”와 “검정 제품 hero”는 같은 구조 안에서 관리할 수 있다.

팀 안에서 프롬프트를 전달할 때도 이 기준이 중요하다. 누군가가 외부 예시를 가져왔을 때 바로 실행하지 말고, 어떤 기존 구조를 보완하는지 먼저 묻는다. 보완점이 없으면 보관하지 않는다. 보완점이 있다면 경로, 테스트, 실패 조건까지 채운 뒤에만 채택한다.

자주 묻는 질문

Reddit의 Nano Banana 프롬프트가 정말 더 좋은가?

발견에는 좋다. 실제 사용자가 어떤 작업을 요청하고 어디서 실패하는지 볼 수 있기 때문이다. 하지만 자동으로 더 좋은 프롬프트는 아니다. 가치는 문장보다 목적, 구도, 제약, 경로, 검증에 있다.

그대로 복사해도 되나?

한 번 시험해 보는 용도라면 가능하다. 작업에 쓰려면 주제, 브랜드, 장면, 비율, 참조 이미지, 텍스트, 합격 기준을 바꿔야 한다. 저장할 것은 원문이 아니라 구조다.

Nano Banana Pro에는 어떤 형식이 좋은가?

출력 유형, 텍스트, 계층, 금지 사항, 보호 요소, 검증 기준을 명확히 한 구조화 형식이 좋다. 정보 보드, 표, 자료형 레이아웃, 설명 이미지에서 특히 유용하다.

JSON 프롬프트가 필요한가?

팀이나 API에서 같은 필드를 반복해서 써야 한다면 유용하다. 하지만 JSON이 약한 목표를 강하게 만들지는 않는다. 일반 문장으로 구조가 명확하면 충분할 때도 많다.

먼저 Gemini 앱에서 시작해야 하나?

시각 방향을 빨리 보려면 Gemini 앱이 좋다. 대상을 지켜야 하면 참조 편집, 텍스트와 레이아웃이 중요하면 Pro, 모델 ID와 로그와 배치가 필요하면 AI Studio 또는 API로 간다.

프롬프트 생성기는 쓸 만한가?

빠진 필드를 채우는 도구로는 유용하다. 작업 목표를 대신 정하게 하면 위험하다. 불필요한 주장, 위험한 표현, 장식만 있는 단어는 삭제하고 검증해야 한다.

계속 실패하면 무엇을 해야 하나?

먼저 실패를 분류한다. 구조가 흐리면 다시 쓴다. 참조가 흔들리면 경로를 바꾼다. 텍스트가 약하면 줄이거나 Pro를 쓴다. 안전 차단이 걸리면 안전한 목표로 바꾸거나 멈춘다.