개발자를 위한 Recraft v4.1 텍스트→이미지 프롬프트 레시피

일회성 프롬프트보다 프롬프트 레시피가 나은 이유

텍스트→이미지 API를 호출하는 모든 팀은 결국 같은 벽에 부딪힙니다. 훌륭한 결과를 낸 그 이미지의 프롬프트가 채팅 기록이나 일회용 스크립트, 혹은 누군가의 노트 앱에 묻혀 있는 것입니다. 제품 요구 사항이 바뀌면—"같은 일러스트인데 사진 느낌으로" 또는 "이미지에 제목을 넣어서"—어떤 단어가 효과가 있었는지 아무도 모르고, 프롬프트는 처음부터 다시 쓰이며 출력도 예측할 수 없이 달라집니다.

프롬프트 레시피는 프롬프트를 작고 매개변수화된 문서로 취급함으로써 이 문제를 해결합니다. 하나의 골격, 몇 개의 교체 가능한 블록, 그리고 짧은 제약 목록. 스타일 변경이 전면 재작성이 아닌 단일 필드 편집이 되므로, 프롬프트를 diff하고 pull request에서 리뷰하며 출력이 왜 달라졌는지 추론할 수 있습니다.

레시피는 또한 품질 회귀를 디버깅 가능하게 만듭니다. 이미지가 갑자기 이상해 보인다면 이분 탐색할 수 있습니다. 주제 블록 문제인가, 스타일 블록인가, 레이아웃 지시인가, 아니면 네거티브 목록인가? 일회성 프롬프트라면 답은 보통 "전부"입니다.

이 가이드는 Recraft v4.1 텍스트→이미지에 적용되는 구체적인 골격을 살펴보고, 개발자가 가장 많이 쓰는 두 가지 범주의 바로 복사해 붙여넣을 수 있는 레시피—일러스트와 사진—를 제시합니다. 같은 구조는 레이아웃 제어, 이미지 내 텍스트, 네거티브 목록으로 확장할 수 있습니다.

레시피에 실제로 들어가는 것

모든 레시피를 네 부분으로 보세요:

• 고정 골격—코드베이스의 모든 프롬프트가 공유하는 순서 있는 블록.
• 교체 가능한 스타일 어휘—출력을 일러스트와 사진 사이에서 전환시키는 단어.
• 제약 절—레이아웃, 가로세로 비율, 텍스트 렌더링, 제외 지시.
• 버전 태그—프로덕션 환경의 프롬프트를 해당 자산을 생성한 정확한 리비전까지 추적할 수 있게 함.

이 중 어느 것도 특별한 도구가 필요하지 않습니다. 레시피마다 JSON 파일 하나를 API를 호출하는 코드와 함께 저장소에 커밋하는 것으로 충분합니다.

프롬프트 골격: 유지되는 블록과 변하는 블록

아래 골격은 의도적으로 지루하게 만들었습니다. 바로 그게 핵심입니다—안정적인 부분은 절대 편집할 필요가 없어야 하므로, 주의력이 변하는 부분에 집중됩니다.

[SUBJECT]        图像里有什么，用平实的语言描述
[STYLE]          媒介与渲染词汇
[COMPOSITION]    取景、镜头或布局、宽高比
[CONSTRAINTS]    文字渲染、配色限制、禁止规则

어떤 블록이 유지되고 어떤 것이 교체되는가

• SUBJECT—유지. 보통 제품 로직이 유일하게 매개변수화해야 하는 블록입니다(제품 이름, 사용자 입력에서 온 장면 설명).
• STYLE—교체. 일러스트와 사진의 차이는 거의 전부 여기에 있습니다.
• COMPOSITION—대부분 교체되지만 지시의 형태는 그대로 유지됩니다(먼저 프레이밍, 그다음 가로세로 비율).
• CONSTRAINTS—부분적으로 공유. 네거티브 목록과 "지정하지 않는 한 텍스트 금지" 규칙은 보통 전역적이고, 텍스트 렌더링 지시는 요청별입니다.

데이터로서의 최소 템플릿

{
  "recipe_id": "product-hero",
  "version": "3",
  "subject": "a ceramic coffee mug on a plain surface",
  "style": "{{style_block}}",
  "composition": "centered, generous negative space above the subject, square aspect",
  "constraints": ["no text in image", "no watermark"],
  "negatives": "{{negative_list_v2}}"
}

{{style_block}} 자리 표시자가 바로 이음새입니다. 나머지는 레시피 간에 공유되거나 호출자가 제공합니다. 나중에 세 번째 스타일—예를 들어 아이소메트릭 3D—을 추가할 때, 새로운 프롬프트 파일이 아니라 스타일 블록 하나만 추가하면 됩니다.

실용적인 팁: 블록 순서를 모든 레시피에서 일관되게 유지하세요. 모델이 문서화된 방식으로 순서에 민감하다는 보장은 없지만, 당신의 팀은 그렇습니다. 일관된 순서는 프롬프트를 비교 가능하게 하고 나란히 리뷰를 의미 있게 만듭니다.

일러스트 레시피: 플랫, 벡터, 에디토리얼 스타일

일러스트 레시피는 대부분 팀의 출발점입니다. 일러스트는 단순화에 관대하기 때문에 사실감과 씨름하지 않고 골격을 테스트하기 좋은 선택입니다.

플랫 일러스트

[SUBJECT] a developer workspace with a laptop, notebook and coffee mug
[STYLE] flat vector illustration, solid fills, no gradients, bold simple shapes, limited four-color palette, clean geometric forms
[COMPOSITION] centered composition, even margins, square aspect
[CONSTRAINTS] no text in image, no shadows, no textures

이런 느낌을 만드는 단어들: 플랫, 단색 채우기, 그라데이션 없음, 굵고 단순한 도형. 모든 단어가 일을 합니다. "그라데이션 없음"을 빼면 부드러운 그림자가 슬며시 끼어드는 것을 자주 보게 됩니다.

벡터 스타일 아이콘

[SUBJECT] a single shield icon with a checkmark
[STYLE] minimal vector icon, uniform stroke weight, rounded line caps, two-tone, high contrast on plain background
[COMPOSITION] centered, icon fills most of the frame, square aspect
[CONSTRAINTS] no text, no background scenery, no gradients

아이콘 프롬프트는 명확한 한정어—단일, 균일한 선 두께—의 도움을 받습니다. 이것이 없으면 그래픽 기호가 아니라 작은 장면을 얻기 쉽습니다.

에디토리얼 일러스트

[SUBJECT] a person reviewing charts on a large screen
[STYLE] editorial illustration, muted palette, subtle grain, hand-drawn line quality, slightly abstracted human figures, magazine feature style
[COMPOSITION] subject offset to the right, breathing room on the left, landscape aspect
[CONSTRAINTS] no text in image, no photorealism, no logos

에디토리얼 스타일은 중간 지대에 있습니다: 플랫 벡터보다 질감과 개성이 더 많지만 여전히 분명히 사진은 아닙니다. 차분한 팔레트와 미세한 입자를 함께 쓰는 것이 어느 극단으로도 흘러가지 않게 하는 핵심입니다.

튜닝 팁: 스타일 형용사는 한 번에 하나씩만 바꾸세요. "차분한 팔레트"를 "선명한 팔레트"로 바꾸는 것은 진짜 실험이지만, 다섯 단어를 한꺼번에 바꾸는 것은 아닙니다.

사진 레시피: 사실적, 스튜디오, 라이프스타일 프레이밍

사진 레시피는 같은 골격을 사용하되 어휘만 다릅니다. 주제 블록이 거의 변하지 않는다는 점에 주목하세요—이것이 템플릿화의 보상입니다.

깔끔한 스튜디오 제품 사진

[SUBJECT] a ceramic coffee mug on a plain surface
[STYLE] professional studio product photography, soft diffused key light, gentle falloff, neutral background, sharp focus, realistic material detail
[COMPOSITION] centered, slight three-quarter angle, generous negative space above, square aspect
[CONSTRAINTS] no text in image, no props, no harsh reflections

사진 어휘는 조명(부드러운 확산광, 감쇠), 광학(선명한 초점, 심도), 재질 사실감(사실적인 재질 디테일)을 중심으로 모입니다. 일러스트 어휘는 형태와 채우기를 중심으로 모입니다. 이 대비가 두 레시피 계열 사이의 전부입니다.

환경 라이프스타일

[SUBJECT] a person working at a wooden desk near a window
[STYLE] candid lifestyle photography, natural window light, shallow depth of field, warm neutral tones, realistic skin and fabric texture
[COMPOSITION] over-the-shoulder framing, subject left of center, landscape aspect
[CONSTRAINTS] no text in image, no visible brand marks, no exaggerated saturation

캔디드와 자연 창문광이 출력을 스튜디오의 세련됨에서 끌어냅니다. 결과가 너무 연출된 느낌이라면, 이는 보통 스타일 문제이자 구도 문제입니다—형용사를 더 쌓기보다 "오버 더 숄더 프레이밍"을 추가하는 것이 더 효과적입니다.

일러스트 레시피를 사진으로 변환하기

작동하는 일러스트 레시피가 있다면 변환은 기계적입니다:

1. [STYLE] 블록 전체를 사진 어휘로 교체합니다.
2. 프레이밍이 다를 때만 [COMPOSITION]을 조정합니다(각도는 사진에서 더 중요합니다).
3. [SUBJECT]는 바이트 단위로 동일하게 유지합니다.
4. 전역 네거티브 항목은 유지하고, 더 이상 적용되지 않는 일러스트 전용 항목(예: "그라데이션 없음")은 제거합니다.

사진 결과가 주제의 요소를 갑자기 발명하거나 잃어버린다면, 주제 블록의 설명이 부족할 가능성이 큽니다—보상적인 스타일 단어를 추가하지 말고 그곳을 수정하세요.

레이아웃과 텍스트 렌더링 제어

레이아웃과 텍스트는 개발자가 모델이 알아서 추론해 주기를 가장 자주 기대하는 두 가지이자, 가장 명시적으로 써 둘 가치가 있는 두 가지입니다. 스타일과 분리된 독립 프롬프트 블록으로 취급하세요.

실제로 제약이 되는 위치 언어

모호함: "랜딩 페이지의 배너 이미지."

명확함:

[COMPOSITION] landscape 16:9 frame; subject occupies the right two-thirds;
left third is empty open space suitable for a headline; horizon line at
lower third; nothing enters the left third

위치 지시를 더 견고하게 만드는 세 가지 습관:

• 먼저 프레임을 명명하고 그다음 배치를 설명합니다("가로 16:9 프레임").
• 예약 영역을 명시하고 해당 영역에 아무것도 들어가지 않는다고 선언합니다. 빈 공간은 기본 상태가 아닙니다.
• "약간 중앙에서 벗어남" 같은 측정 불가능한 단어 대신 삼분할선에 고정합니다.

텍스트 렌더링

이미지에 텍스트가 나타나기를 원할 때는 이를 별도 블록으로 분리하고 정확한 문자열을 인용하세요:

[TEXT] render exactly the words "Ship faster" in a bold sans-serif,
placed in the reserved left third, vertically centered, single line,
high contrast against a plain background. No other text anywhere.

반복을 줄여 주는 요점:

• 문자열을 그대로 인용하세요—프롬프트 안에서 절대 바꿔 쓰지 마세요.
• "정확히"와 "다른 텍스트 없음"을 말하세요—그렇지 않으면 모서리나 소품에 불필요한 글자가 생깁니다.
• 줄 수를 지정하세요("한 줄"), 그렇지 않으면 줄바꿈은 추측이 됩니다.
• 대비되는 배경을 지정하세요("단색 배경 위에") 텍스트가 기댈 곳이 있게 하세요.
• 텍스트는 [STYLE] 블록에서 완전히 떼어 두세요; 섞으면 둘 다 튜닝하기 어려워집니다.

정교한 다중 요소 조판이 필요한 요청이라면 텍스트 생성을 출발점으로 삼고 다운스트림에서 실제 텍스트 레이어를 계획하세요. 프롬프트 수준의 텍스트 제어는 짧은 제목과 레이블에 적합하고 밀도 높은 본문에는 적합하지 않습니다.

네거티브 목록: 무엇을 제외하고 어떻게 버전화할 것인가

네거티브 목록은 가장 저렴한 품질 관리 수단입니다. 원하는 것을 설명하는 대신, 받아들이기를 거부하는 실패 모드를 지목합니다.

제외할 가치가 있는 범주

네거티브 항목을 범주로 조직하면 모순을 만들지 않고 확장할 수 있습니다:

• 텍스트 아티팩트—불필요한 글자, 깨진 글리프, 워터마크, 서명.
• 구도 아티팩트—잘린 주제, 잘린 팔다리, 중복 요소, 어수선한 가장자리.
• 렌더링 아티팩트—흐림, 색 밴딩, 과도한 채도, 거친 HDR 느낌, 플라스틱 같은 피부.
• 콘텐츠 위생—브랜드 로고, 식별 가능한 상표, 실존 인물의 초상.
• 스타일 표류—일러스트 레시피에 나타나는 사진 사실감, 사진 레시피에 나타나는 일러스트 느낌.

마지막 범주를 팀이 가장 자주 잊습니다. 일러스트 레시피가 계속 사실적으로 흘러간다면, 명시적인 네거티브 항목이 스타일 형용사를 쌓는 것보다 종종 더 신뢰할 수 있습니다.

짧게 유지하고 모순을 만들지 말 것

지나치게 긴 네거티브 목록은 역효과를 냅니다. 네거티브 항목이 긍정 지시와 충돌하면 결과가 불안정해지고 어느 절이 우세했는지 판단할 수 없습니다. 두 가지 규칙:

1. 요구한 것을 부정하지 마세요. 구도 블록이 깊이감을 위해 그림자를 요구했다면, 동시에 전역으로 "그림자 없음"을 나열하지 마세요.
2. 구체적인 것이 일반적인 것보다 우선합니다. "워터마크 없음"은 실행 가능하고, "나쁜 것 없음"은 노이즈입니다.

네거티브 목록을 프롬프트와 함께 버전화하기

네거티브 항목은 이를 참조하는 모든 레시피의 동작을 바꾸므로, 프롬프트와 동등한 추적성이 필요합니다:

{
  "negative_list_id": "global-v2",
  "entries": ["watermark", "signature", "stray text", "cropped subject", "duplicated elements", "oversaturated colors"]
}

각 레시피에서 ID로 목록을 참조하고, 편집할 때 ID를 증가시키세요. 배포 후 출력 품질이 흔들리면 "네거티브 목록이 바뀌었나?"가 조사가 아니라 diff에서 한 줄 확인이 됩니다.

출시 전 실제 출력과 비교하기

실제 출력을 보기 전까지 레시피는 가설일 뿐입니다. 아래 비교 절차는 의도적으로 가볍게 유지했습니다—몇 분이면 되어야 하고, 스프린트가 걸려서는 안 됩니다.

절차

1. 하나의 변수를 제외한 모든 것을 고정하세요. 같은 주제 블록, 같은 구도, 같은 네거티브 항목, API가 시드를 노출한다면 같은 시드. 스타일 블록만 바꾸세요.
2. 작은 행렬을 생성하세요. 두세 개의 스타일 변형과 두세 개의 대표 주제 조합이면 보통 나쁜 레시피를 드러내기에 충분합니다.
3. 나란히 리뷰하세요, 순차적으로 리뷰하지 마세요. 순차 리뷰는 최근성 편향을 부릅니다—마지막 이미지가 가장 최신이라서 가장 좋아 보입니다.
4. 취향이 아니라 요구 사항에 따라 평가하세요. 이 자산이 무엇을 위해 쓰이는지(히어로 배너, 아이콘 세트, 에디토리얼 헤더) 적고, 실제로 중요한 구체적 속성을 확인하세요: 예약 공간이 실제로 비어 있는가, 불필요한 텍스트가 없는가, 스타일 표류가 없는가.
5. 의식적으로 승격하세요. 리뷰를 통과한 레시피 리비전만 제품 코드에 들어가고, 해당 버전 태그가 붙습니다.

주의할 점

• 주제 간 일관성. 한 주제에서는 잘 되지만 다른 주제에서는 무너지는 스타일 블록은 아직 준비되지 않은 것입니다.
• 제약 준수. 예약된 왼쪽 3분의 1이 비어 있는가? 인용한 정확한 문자열이 한 번만 나타나는가?
• 실패 군집. 같은 아티팩트가 여러 변형에서 나타나면 스타일 미세 조정이 아니라 네거티브 목록에 들어가야 합니다.

모든 것을 저장소에 보관하세요

레시피 JSON, 네거티브 목록 버전, 리뷰 기록을 함께 두세요. 6개월 후 누군가 히어로 이미지가 왜 이렇게 생겼는지 묻는다면, 답은 한 번의 커밋이지 기억이 아닙니다.

레시피가 이 순환을 통과하면, 주어진 주제에 대해 일러스트와 사진 사이를 전환하는 것이 단일 필드 편집이 됩니다—이것이 바로 골격이 제공하도록 설계된 유지 보수 특성입니다. 통합 API를 통해 Recraft v4.1 텍스트→이미지에 이 레시피들을 적용하고, 모든 프롬프트 리비전이 이를 호출하는 코드와 함께 버전화되게 하세요.