imagen4-fast 프롬프트 레시피: 개발자가 복사해 붙여넣을 수 있는 프롬프트

프롬프트 레시피가 일회성 프롬프트를 이기는 이유

대부분의 이미지 생성 문제는 모델의 문제가 아니라 프롬프트의 문제이며, 고치기가 어렵습니다. 프롬프트가 누군가의 채팅 기록이나 낡은 문서 속에만 존재하는 경우가 많기 때문입니다. 화요일에는 훌륭한 결과를 냈던 일회성 프롬프트가 금요일에는 재현되지 않는데, 그 안에 정확히 무엇이 적혀 있었는지 말할 수 없기 때문입니다.

프롬프트 레시피는 이 문제를 함수가 복사-붙여넣기 로직을 해결하는 방식과 똑같이 해결합니다. 고정된 구조, 이름이 붙은 슬롯, 그리고 나중에 인용할 수 있는 안정적인 식별자를 갖습니다. 출력이 달라졌을 때 비교할 대상이 생깁니다.

실질적인 이점은 빠르게 드러납니다:

• 호출 간 일관성. 같은 레시피에 같은 입력을 넣으면 비교 가능한 구도와 스타일이 나옵니다. 한 페이지가 그리드에 카드 이미지 열두 장을 렌더링할 때 이 점은 결정적입니다.
• 저비용 반복. 자유분방한 산문을 다시 쓰다가 잘 작동하던 부분을 잃는 대신, 슬롯 하나만 바꿉니다.
• 추적 가능성. 레시피에는 버전이 있습니다. 브랜드 팀이 왜 썸네일이 지난달보다 밋밋해 보이는지 묻는다면, 이분 탐색으로 원인을 좁힐 수 있습니다.
• 리뷰 가능성. 레시피는 다른 자산처럼 풀 리퀘스트에서 리뷰할 수 있으며, 리뷰어가 프롬프트 작성으로 생계를 유지하는 사람일 필요가 없습니다.

이 글의 나머지 부분은 일종의 매뉴얼입니다. 모든 레시피는 같은 골격을 따르므로, 하나를 읽고 변형한 뒤 리팩터링 없이 코드베이스에 넣을 수 있습니다. 모델을 하나의 컴포넌트로, 레시피를 그 위에 구축하는 인터페이스로 여기십시오.

기억할 관념이 하나 있습니다: 레시피는 마법 주문이 아닙니다. 그것은 다운스트림 UI 슬롯과 생성 호출 사이의 계약입니다. UI 슬롯이 화면 비율을 결정하고, 레시피가 그 안을 무엇으로 채울지 결정합니다.

기본 프롬프트 골격

이 핸드북의 모든 레시피는 같은 4부분 골격으로 구성됩니다. 이 부분을 복사하고 슬롯을 채우십시오:

[subject] — [composition] — [style] — [constraints]

핵심 사상은 그게 전부입니다. 아래는 바로 붙여넣어 쓸 수 있는 채워진 버전입니다:

A lone ceramic coffee cup on a pale oak desk, three-quarter view, shallow depth of field,
soft morning light from the left, minimal editorial product photography, muted warm palette,
no text, no logos, no hands, centered subject with breathing room on all sides

각 슬롯의 역할

주체(Subject)는 이미지가 다루는 단 하나의 대상입니다. 구체적으로 명명하십시오: "커피 분위기"가 아니라 "세라믹 커피잔"입니다. 주체에 동작이나 상태가 있다면 함께 넣으십시오: "어두운 책상 앞에서 키보드를 두드리던 중인 개발자". 두 번째 주체를 추가하고 싶은 유혹을 물리치십시오. 이것이 결과가 어수선해지는 가장 흔한 원인입니다.

구도(Composition)는 화면 비율을 제어합니다. 시점(사분의 삼 시점, 탑뷰, 아이레벨), 주체 위치(중앙, 삼분할 왼쪽), 크롭(전체 화면, 타이트 크롭), 심도가 여기에 속합니다. 이 슬롯은 실제 비율이 별도 파라미터이더라도, 종횡비 의도를 텍스트로 인코딩하는 곳입니다.

스타일(Style)은 짧은 시각 어휘입니다: 매체(사진, 플랫 벡터, 수채화), 조명(부드러운 아침 빛, 강한 림 라이트), 색조(차분한 따뜻한 색, 고대비 단색), 질감(무광, 광택, 입자). 한두 개의 짧은 문장으로 제한하십시오. 더 긴 스타일 블록은 서로 충돌하는 경우가 많습니다.

제약(Constraints)은 부정 공간입니다. 나타나면 안 되는 것: 텍스트, 로고, 워터마크, 여분의 사지, 어수선한 배경, 거친 그림자. 제약은 값싼 보험이며, 레시피에 문제가 생겼을 때 가장 먼저 확장할 부분입니다.

상시 보관할 만한 두 가지 변형

미니멀 오브젝트 사진:

[object] on a seamless [color] backdrop, centered, straight-on view, soft even studio light,
clean commercial product photography, no shadows on background, no text, no props

에디토리얼 장면 사진:

[scene subject] in [environment], wide establishing view, natural light, subtle film grain,
documentary photography, muted palette, no text, no logos, no visible brand marks

둘 다 의도적으로 짧게 유지했습니다. 프롬프트가 형용사의 더미라면, 구도 슬롯을 그 안 어딘가에 이미 잃어버렸을 가능성이 큽니다.

프롬프트를 쓰기 전에 종횡비부터 정하십시오

채울 구멍의 모양을 안 뒤에 프롬프트를 쓰십시오. 종횡비는 프롬프트 결정이 아니라 제품 결정입니다. 늦게 정하면 이미 다듬어 둔 구도 문장을 다시 써야 합니다.

대부분의 인터페이스를 커버하는 간단한 매핑입니다:

• 히어로 배너와 페이지 헤더—와이드 화면. 구도 표현: "wide establishing view", "horizon placed in the lower third", "negative space on the left for headline overlay".
• 카드와 그리드 타일—정사각형 또는 거의 정사각형. 구도 표현: "centered subject", "even margins", "no important detail near the edges".
• 아바타와 프로필 소형 이미지—정사각형, 타이트 크롭, 단일 주체. 구도 표현: "head and shoulders", "centered face", "plain background".
• 썸네일과 리스트 행—작은 크기의 와이드 또는 정사각 크롭, 주체는 축소해도 분별 가능해야 함. 구도 표현: "single dominant subject", "high contrast against background", "no fine detail".
• 에디토리얼 콘텐츠 또는 장문 본문 삽화—세로 화면. 구도 표현: "vertical composition", "subject occupies the upper two thirds", "foreground anchor at the bottom".

왜 문구가 화면 비율과 일치해야 하는가

와이드 배너를 위해 쓴 구도 문장("negative space on the left")은 정사각형으로 잘리면 의미가 없어지고, 텍스트로 묘사한 타이트한 세로 크롭은 와이드 화면을 요구하면 눌립니다. 프롬프트와 비율은 일치해야 합니다. 같은 사각형을 언어로 한 번, 파라미터로 한 번, 두 번 묘사하고 있기 때문입니다.

실용 워크플로

1. 실제 UI 슬롯을 보고 그 종횡비와 작은 화면에서의 크롭 방식을 기록하십시오.
2. 모델이 여백으로 위장하도록 요구하는 대신, 가장 가까운 지원 종횡비를 선택하십시오.
3. 그 화면 비율에 맞춰 구도 슬롯을 작성하되, 부정 공간이 어디에 놓여야 하는지 포함하십시오.
4. 생성 후 이상적인 크롭이 아니라 최악의 크롭(모바일, 그리드 축소)을 확인하십시오.

하나의 레시피가 아주 다른 두 슬롯을 모두 지원해야 한다면, 두 개의 레시피로 만드십시오. 레시피를 복사하는 편이 어디서나 반쯤만 통하는 구도 문장을 쓰는 것보다 경제적입니다.

인터페이스별로 전환 가능한 스타일 단서 블록

스타일 슬롯은 가장 자주 바뀔 것으로 예상해야 하는 부분이므로 모듈화하십시오. 스타일 단서를 기본 골격에 붙이는 자족적 블록으로 작성하고, 인터페이스나 브랜드 톤에 따라 각각 하나씩 보관하십시오.

브랜드 안전 / 중립

minimal editorial photography, soft diffused light, muted neutral palette,
clean background, product-focused, no text, no logos

마케팅 페이지에서 이미지가 카피와 주의를 다투어서도, 브랜드 주장을 암시해서도 안 될 때 사용합니다.

사진 / 다큐멘터리

natural light, documentary photography, shallow depth of field, subtle grain,
unposed subject, realistic color, no heavy filters

에디토리얼 삽화와 내러티브 인터페이스에서 정교함보다 사실감이 더 효과적일 때 사용합니다.

플랫 일러스트레이션

flat vector illustration, limited two-color palette, bold simple shapes,
no gradients, generous whitespace, geometric composition, no text

온보딩, 빈 상태, 문서에서 이미지가 디자인 시스템과 일치해야 할 때 사용합니다.

스튜디오 제품 사진

seamless studio backdrop, soft even key light, crisp shadows, high detail on the subject,
commercial catalog photography, no props, no text

상품 카탈로그와 비교 그리드에서 개별 이미지보다 다중 이미지 간 일관성이 더 중요할 때 사용합니다.

퇴화 없이 전환하는 방법

• 스타일 블록을 하나의 변수로 취급하고, 주체나 구도 문장과 절대 섞지 마십시오. 스타일 단어가 프롬프트 전반에 흩어져 있으면 깔끔하게 교체할 수 없습니다.
• 한 번에 블록 하나만 바꾸고, 같은 주체와 구도로 다시 생성하십시오. 두 변수가 동시에 움직이면 무엇이 변화를 일으켰는지 판단할 수 없습니다.
• 스타일 블록이 몰래 구도를 끌어들이지 않는지 경계하십시오. "Centered"와 "close-up"은 스타일이 아니라 구도에 속합니다. 이것들이 스타일 블록에 살면 종횡비에 들인 노력이 조용히 무효화됩니다.
• 계속 부풀어 오르는 블록을 다듬으십시오. 스타일 문장 세 개면 보통 충분하고, 다섯 개부터는 서로 경쟁하기 시작합니다.

유용한 테스트 하나: 나머지가 완전히 같은 레시피에서 스타일 블록을 교체한 뒤 출력이 여전히 같은 UI 슬롯에 맞는지 보십시오. 맞는다면 그 블록은 적절히 격리된 것입니다.

코드에서 프롬프트를 파라미터화하기

레시피는 처리기 곳곳에 흩어진 문자열 리터럴이 아니라 템플릿으로 존재해야 합니다. 이름 붙은 변수를 가진 템플릿은 A/B 테스트, 롤백, 인터페이스별 오버라이드를 공짜로 제공합니다.

템플릿 형태

RECIPE = {
    "id": "product-hero-v3",
    "template": (
        "{subject} — {composition} — {style} — {constraints}"
    ),
    "defaults": {
        "composition": "centered subject, generous margins, eye-level view",
        "style": "minimal editorial photography, soft diffused light, muted neutral palette",
        "constraints": "no text, no logos, no watermark, clean background",
    },
    "aspect_ratio": "1:1",
}


def render(recipe, **overrides):
    slots = {**recipe["defaults"], **overrides}
    return recipe["template"].format(**slots)

레시피 객체는 식별자(id), 화면 비율(aspect_ratio), 기본값을 담습니다. 호출자는 다른 부분만 제공합니다. 이것이 호출 지점을 짧게 유지하고 두 인터페이스 간 차이를 한눈에 보이게 합니다.

A/B 테스트용 변형

변형을 분기된 문자열이 아니라 기본 레시피 위의 오버라이드로 모델링하십시오:

variants = {
    "control": {},
    "warm": {"style": "minimal editorial photography, warm afternoon light, muted warm palette"},
    "tight": {"composition": "tight crop, subject fills the frame, eye-level view"},
}

각 변형이 주체와 제약을 공유하므로, 결과 차이는 변경한 슬롯에 귀속시킬 수 있습니다. 이것이 이 연습의 가치 전부입니다.

롤백과 고정

• id에 레시피마다 버전을 부여하고, 모든 생성 요청에서 기록하십시오. 출력이 변하면 로그가 어느 레시피 버전이 무엇을 만들었는지 알려줍니다.
• 한동안 이전 버전을 주소 지정 가능하게 유지하십시오. 롤백은 압박 속에서의 코드 되돌리기가 아니라 구성 변경이어야 합니다.
• 자체 분석 시스템에 전달할 때 렌더링된 문자열이 아니라 레시피 id를 사용하십시오. 그러면 정확한 프롬프트 텍스트가 아니라 레시피별로 결과를 그룹화할 수 있습니다.
• API를 호출하기 전에 슬롯을 검증하십시오. 빈 subject는 모호한 이미지를 만드는 대신 애플리케이션에서 빠르게 실패해야 합니다.

종횡비는 템플릿과 나란한 일급 파라미터로 두십시오. UI 슬롯이 결정하고 프롬프트 텍스트가 결정하지 않기 때문입니다. API가 필요로 하는 모든 것은 하나의 레시피 객체에서 파생되어야 하며, 그래야 각 인터페이스에 단일 진실 공급원이 생깁니다.

흔한 실패 패턴과 디버깅 방법

대부분의 나쁜 출력은 하나의 슬롯으로 거슬러 올라갈 수 있습니다. 이 체크리스트로 전체 프롬프트를 다시 쓰기 전에 골격의 어느 부분을 조정해야 할지 결정하십시오.

주체가 잘리거나 화면 밖으로 나감

증상: 머리가 잘림, 물체가 가장자리를 넘침, 중요한 디테일이 안전 영역 밖에 놓임.

스타일이 아니라 구도 슬롯부터 고치십시오. 명확한 프레이밍 언어("full subject in frame", "generous margins on all sides")를 추가하고, 종횡비가 의도한 화면 비율과 일치하는지 확인하십시오. 주체 자체는 세로로 긴데 슬롯이 와이드라면, 프롬프트가 아니라 화면 비율이 잘못된 것입니다.

결과가 어수선함

증상: 서로 경쟁하는 여러 초점, 복잡한 배경, 요청하지 않은 소품.

주체 슬롯을 고치십시오. 하나의 주체, 하나의 상태로 줄이십시오. 소품으로 읽힐 만한 것은 제약에 제외 항목으로 옮기십시오. 어수선함은 대개 모델의 과잉 열의가 아니라 주체의 모호함에서 옵니다.

한 배치 안에서 스타일이 불일치함

증상: 그리드에서 어떤 이미지는 사진처럼, 어떤 이미지는 일러스트처럼 보임; 색조가 흔들림.

스타일 블록을 고치십시오. 하나의 매체, 하나의 조명 문장, 하나의 색조 문장으로 줄이십시오. 다른 슬롯으로 새어 나간 스타일 단어를 제거하고, 두 개의 다른 인터페이스를 동시에 지원하는 레시피를 분리하십시오. 한 배치 내 불일치는 종종 스타일 블록이 호출마다 달랐다는 증상입니다.

텍스트나 로고가 나타남

증상: 깨진 글자, 가짜 워터마크, 브랜드 유사 표식.

제약을 확장하십시오: "no text, no lettering, no logos, no watermarks, no signage". 구도가 보통 텍스트가 있는 매체(화면, 포장, 포스터)를 암시한다면, 명시적으로 배제하거나 구도를 바꾸십시오.

출력이 요구한 감정을 무시함

증상: 이미지는 맞지만 밋밋하거나 딱딱하거나 흔해 보임.

스타일 블록을 한 번에 한 문장씩 고치십시오. 조명이 보통 지렛대가 가장 큰 변경이고, 색조가 그다음입니다. 비교가 정직하도록 같은 주체와 구도로 다시 생성하십시오.

그 밖의 모든 경우

두 슬롯이 모두 의심스러워 보이면, 하나를 바꾸고 다시 생성하십시오. 그래도 결과가 틀리다면 한 걸음 물러나 레시피가 애초에 작성된 적 없는 UI 슬롯을 지원하도록 요구받고 있는지 확인하십시오. 그것은 프롬프트 결함이 아니라 제품 불일치입니다.

레시피 라이브러리 배포

레시피가 버전이 붙은 템플릿이 되면, 팀이 코드와 함께 유지 관리하는 자산이 됩니다. 목표는 누구나 어떤 인터페이스 뒤의 레시피를 찾고, 왜 그렇게 생겼는지 이해하고, 안전하게 바꿀 수 있게 하는 것입니다.

프롬프트 텍스트가 아니라 인터페이스별로 구성하십시오

레시피를 렌더링 위치별로 그룹화하십시오: hero, card, avatar, thumbnail, editorial-figure. 가격 페이지를 보는 개발자는 알파벳순 형용사 목록이 아니라 그 페이지가 사용하는 레시피에 도달해야 합니다. 각 레시피에 안정적인 id와 버전 접미사를 주고, 기본값은 레시피 객체 내부에 두십시오.

풀 리퀘스트에서 레시피 리뷰하기

레시피 변경을 컴포넌트 변경처럼 다루십시오. diff는 어느 슬롯이 왜 움직였는지 보여야 합니다. 리뷰어는 유용한 질문을 할 수 있습니다: 구도가 여전히 화면 비율과 맞는가, 스타일 단어가 구도로 새어 들어갔는가, 제약이 줄었는가? 작은 단일 슬롯 diff는 리뷰하기 쉽고, 전체 재작성은 그렇지 않습니다.

버전 관리, 기록, 정리

• 모든 생성 요청에서 레시피 id와 버전을 기록하십시오. 그래야 출력 변화를 특정 변경으로 추적할 수 있습니다.
• 어떤 인터페이스도 참조하지 않을 때까지 폐기 버전을 주소 지정 가능하게 유지하고, 그 뒤 한 차례 정리에서 제거하십시오. 죽은 레시피를 영원히 남겨 두지 마십시오.
• 변형을 추가할 때 승자를 새 버전으로 승격하십시오. A/B 분기를 영구 경로로 남겨 두지 마십시오.

계약 문서화

각 레시피에 대해 예상 UI 슬롯, 종횡비, 절대 버려서는 안 되는 제약을 기록하십시오. 두 문장이면 충분합니다. 이 레시피를 다음에 만지는 사람은 그것이 깨뜨려서는 안 되는 것이 무엇인지 알아야 합니다.

루프를 짧게 유지하십시오

레시피는 디자인 변경 후 아무도 다시 생성하지 않으면 썩습니다. 이미지 슬롯을 건드리는 모든 UI 작업에 작은 리뷰 단계를 연결하고, 그 변경의 일부로 영향을 받은 레시피를 다시 실행하십시오. 피드백 루프가 짧게 유지될 때만 전체 시스템이 저비용으로 유지됩니다.

기본 골격에서 시작해 인터페이스마다 스타일 블록을 하나씩 추가하고, 레시피 라이브러리가 가상의 슬롯이 아니라 실제 슬롯에서 자라게 하십시오. 생성을 애플리케이션에 연결하고 있다면 호출 지점을 얇게 유지하고, 결정은 레시피 객체가 지게 하십시오.