사용 가이드
개발자를 위한 Muse-Image-1.0 이미지 간 변환 프롬프트 레시피
바로 복사해 붙여넣을 수 있는 편집 프롬프트, 주체를 보존하는 표현, 그리고 흔한 실패를 겨냥한 네거티브 프롬프트
이미지 간 변환 프롬프트와 텍스트-이미지 프롬프트의 차이
텍스트-이미지 프롬프트는 전체 장면을 묘사합니다: 주체, 조명, 스타일, 구도, 배경. 모델은 노이즈에서 시작해 모든 것을 구축합니다. 이미지 간 변환은 다릅니다: 이미 소스 이미지가 있고, 프롬프트는 그 이미지에 대한 증분입니다. 이미지에 무엇이 포함되어야 하는지를 처음부터 묘사하는 대신, 무엇이 바뀌어야 하고 무엇이 유지되어야 하는지를 묘사합니다.
이 구분이 중요한 이유는 편집 프롬프트에 전체 장면 묘사를 넣으면 모델이 화면 전체를 다시 렌더링하도록 유도되기 때문입니다. 주체를 자세히 묘사하면 모델이 주체를 유지하는 대신 다시 그릴 수 있습니다. 배경을 묘사하면 배경을 재구성할 수 있습니다. 결과는 종종 그럴듯하지만 다른 이미지처럼 보입니다 — 같은 개념이지만 다른 인스턴스입니다.
지켜야 할 멘탈 모델은 이렇습니다: 텍스트-이미지 프롬프트는 명세서이고, 이미지 간 변환 프롬프트는 차이 패치입니다. 소스 이미지는 기반 문서이고, 여러분의 프롬프트는 패치입니다. 패치는 작고 명확하며 범위가 제한되어야 합니다. 패치가 너무 광범위하면 모델이 모든 곳에 적용하고, 여러분이 유지하려던 소스 이미지 부분을 잃게 됩니다.
실제로 이는 편집 프롬프트가 기존 이미지에 대한 참조(예: "주체", "기존 배경", "현재 구도")에 의존해야 하며, 이를 다시 묘사하지 않아야 함을 의미합니다. 무엇이 존재하는지가 아니라 무엇이 움직이는지를 말하세요. 다음 섹션에서는 이를 재사용 가능한 뼈대와 구체적인 레시피로 전환합니다.
또 다른 결과가 있습니다: 소스 이미지가 너무 많은 정보를 담고 있기 때문에 같은 프롬프트가 서로 다른 입력에서 다르게 작동할 수 있습니다. 제품 이미지에서 효과적인 레시피가 인물 사진에서는 실패할 수 있습니다. 그래서 여기의 레시피는 마법 같은 문자열이 아니라 적응 가능한 패턴으로 작성됩니다.

레시피 형식: 하나의 변경, 하나의 보존, 하나의 제약
이 가이드의 모든 편집 프롬프트는 동일한 세 부분 뼈대를 따릅니다. 의도적으로 지루하게 보이는데, 바로 그것이 핵심입니다 — 고정 구조는 프롬프트를 비교 가능하고, 검토 가능하며, 템플릿화 가능하게 만듭니다.
뼈대
- 변경 — 수정을 설명하는 명확한 지시. 동사로 시작하세요: change, replace, add, remove, shift, recolor.
- 보존 — 고정되어야 할 항목을 명시적으로 나열한 목록: 주체 정체성, 자세, 구도, 배경, 조명, 질감.
- 제약 — 경계 조건: 스타일 일관성, 화면 비율, 새 객체 추가 금지, 요청하지 않는 한 텍스트 금지.
최소 프롬프트는 다음과 같습니다:
변경: 배경을 단색 연회색 스튜디오 배경으로 교체.
보존: 주체의 얼굴, 머리카락, 의상, 자세, 구도.
제약: 원래 조명 방향과 그림자 부드러움 유지; 소품 추가 금지; 텍스트 금지.
왜 한 문장이 아니라 세 부분인가
세 부분 분리는 두 가지를 합니다. 첫째, 변경과 보존 줄은 분리된 신호입니다. 모델이 받는 명시적 "유지" 지시가 편집 문장과 얽히지 않을 때 더 잘 따르는 경향이 있습니다. 둘째, 분리는 디버깅을 가능하게 합니다. 출력이 잘못되면 변경이 잘못 적용되었는지(변경 줄이 너무 모호함) 또는 소스가 과도하게 편집되었는지(보존 줄이 없거나 너무 짧음) 판단할 수 있습니다.
프롬프트당 하나의 변경만 유지
복합 편집에 저항하세요. "배경 교체하고 모자 추가하고 저녁 조명으로 만들기"는 세 가지 레시피를 한 겉포장으로 감싼 것입니다. 대신 순차적으로 수행하세요: 각 단계는 깨끗한 증분을 가지며 중간 결과를 검사할 수 있습니다. 순차 편집은 각 단계에서 간결한 보존 줄을 유지하게 해줍니다.
제약 줄은 품질 관문입니다. 출력을 거부하게 만들 요소 — 잘못된 화면 비율, 추가된 텍스트, 어긋난 색온도 — 를 제약에 넣으세요. 과도하게 제약된 프롬프트를 제거하는 것이 과소 명세된 프롬프트를 쫓는 것보다 쉽습니다.
바로 복사해 붙여넣을 수 있는 편집 레시피
아래 각 레시피는 변경 / 보존 / 제약 뼈대를 따릅니다. 괄호 부분을 주체에 맞게 조정하세요. 전후 비교 프레임을 체크리스트로 삼으세요: 무엇이 뚜렷하게 달라져야 하고, 무엇이 완전히 동일해야 하는지.
1. 배경 교체
전: 번화한 거리의 주체. 후: 같은 주체, 깔끔한 배경.
변경: 배경을 매끄러운 [색상] 스튜디오 배경으로 교체.
보존: 주체의 얼굴, 머리카락, 의상, 자세, 신체 구도; 현재 크롭 유지.
제약: 주체의 원래 조명 방향 일치; 배경에 새 그림자 추가 금지; 텍스트나 로고 금지.
2. 제품 색상 변경
전: 한 가지 색상 구성의 제품. 후: 같은 제품, 다른 색상.
변경: [제품 부품]을 [대상 색상]으로 다시 채색하고 재질 표면 처리 유지.
보존: 제품 형태, 이음새, 라벨, 반사, 기존 구도.
제약: 배경이나 주변 표면의 반사는 다시 채색하지 말 것; 텍스트 변경 금지.
3. 조명 및 시간대 전환
전: 정오의 평평한 빛. 후: 따뜻한 저녁 빛.
변경: 조명을 따뜻한 낮은 각도의 저녁 빛으로 전환.
보존: 주체의 정체성, 자세, 의상, 장면 배치.
제약: 그림자를 단일 저각 광원과 일치하게 유지; 객체 추가 또는 제거 금지; 텍스트 금지.
4. 객체 제거
전: 방해 요소가 있는 장면. 후: 같은 장면, 요소 사라짐.
변경: [위치]에서 [객체]를 제거하고 주변 표면으로 해당 영역을 채움.
보존: 화면의 다른 모든 것은 원래대로, 구도와 조명 포함.
제약: 객체 원래 위치에 흐림이나 번짐 아티팩트 없음; 대체 객체 추가 금지; 텍스트 금지.
5. 주체 스타일 전환
전: 주체의 사진. 후: 같은 주체의 일러스트화.
변경: 이미지를 [스타일] 일러스트 스타일로 렌더링.
보존: 주체의 얼굴 특징, 자세, 의상 디테일, 구도.
제약: 주체를 식별 가능하게 유지; 요소 추가 금지; 텍스트나 서명 표시 금지.
6. 크롭 및 재구도
전: 광각 샷. 후: 더 타이트한 구도, 같은 주체.
변경: 주체를 중앙에 둔 더 가까운 [인물/정사각형] 크롭으로 재구도.
보존: 주체 외형, 표정, 조명, 새 크롭 내 배경 맥락.
제약: 원래 프레임 밖의 디테일을 만들어내지 말 것; 텍스트 금지.
한 번에 하나의 레시피를 실행하고, 검사한 후 다음 단계를 연결하세요. 레시피가 잘못되면 수정은 보통 변경 줄에 형용사를 더 쌓는 것이 아니라 보존 줄이나 제약 줄에 있습니다.

주체 디테일을 온전히 유지하는 표현
정체성 드리프트는 이미지 간 변환에서 가장 흔한 불만입니다. 모델이 요청한 편집을 완료했지만 얼굴을 조용히 다시 그리거나, 직물을 바꾸거나, 자세를 어긋나게 했습니다. 여기서 표현이 주요 지렛대이며, 반복보다 효과적입니다.
고정되어야 할 내용을 명시하세요
추상적인 보존 지시("그대로 유지")는 약합니다. 구체적인 것은 강합니다. 비교해 보세요:
- 약함: "주체를 그대로 유지."
- 강함: "주체의 얼굴, 헤어라인, 눈 색, 옷 주름, 손 위치를 유지."
강한 버전이 효과적인 이유는 검사 가능한 속성을 나열하기 때문입니다. 모델은 모호한 "아무것도 바꾸지 말 것" 대신 구체적인 앵커를 가집니다.
이미지를 참조하고, 다시 묘사하지 마세요
주체를 다시 묘사하는 것은 가장 흔한 자기 발등 찍기 실수입니다. "갈색 머리에 파란 셔츠를 입은 여자"라고 쓰면, 모델은 소스 이미지의 그 여자가 아닌 갈색 머리에 파란 셔츠를 입은 어떤 여자를 생성할 수 있습니다. 지시적 참조를 우선하세요: "주체", "기존 배경", "현재 구도". 다시 묘사는 해당 속성을 바꾸고 싶을 때만 유용합니다.
편집을 공간적으로 제한하세요
가능하면 텍스트로 편집 영역을 경계 짓습니다: "배경만", "화면 아래 3분의 1", "제품 라벨". 공간 제한은 부수적 편집을 줄입니다. 파이프라인이 마스크를 지원하면 공간 언어를 마스크와 결합하세요 — 텍스트와 마스크가 서로를 강화합니다.
절대급이 아닌 비교급을 사용하세요
"더 따뜻하게", "약간 더 타이트하게", "덜 포화되게"는 "따뜻한 오렌지색", "극단적 클로즈업", "고포화"보다 원본을 더 많이 보존합니다. 절대급은 모델을 묘사의 전형적 버전 쪽으로 끌어당깁니다. 비교급은 소스 이미지에 고정시킵니다.
보존 목록은 짧지만 지지력 있게
세에서 여섯 개 속성이 보통 충분합니다. 스무 개 항목의 보존 목록은 주의를 희석합니다. 항목이 없는 목록은 드리프트를 초래합니다. 출력을 거부하게 만들 속성을 고르고 나머지는 비워 두세요.
실용적인 습관: 보존 줄을 먼저 쓰고, 변경 줄을 나중에 쓰세요. 무엇이 움직이는지 결정하기 전에 무엇이 가장 중요한지 결정하는 것이 종종 더 타이트한 프롬프트를 만들어냅니다.

흔한 실패 사례를 위한 네거티브 프롬프트
대부분의 나쁜 생성은 몇 가지 반복 가능한 실패 범주에 모입니다. 작고 재사용 가능한 네거티브 프롬프트 세트가 편집을 과도하게 제약하지 않고 이를 커버할 수 있습니다. 파이프라인의 전달 방식에 따라 제약 줄에 네거티브를 추가하거나 별도의 네거티브 필드로 전달하세요.
실패: 얼굴 정체성 드리프트
증상: 얼굴형, 눈, 나이가 어긋남; 표정이 예기치 않게 변함.
Negative: altered facial features, changed eye color, different person, age change, expression change
실패: 배경 과도 편집
증상: 주체만 편집했는데 배경 객체가 움직이고, 벽 색이 변하고, 그림자가 어긋남.
Negative: changed background, moved objects, altered wall color, new shadows, shifted horizon
실패: 질감과 재질 손실
증상: 직물이 플라스틱처럼 보이고, 피부가 에어브러시처럼 보이고, 금속이 반사를 잃음.
Negative: plastic texture, airbrushed skin, lost fabric weave, flattened reflections, oversmoothing
실패: 원치 않는 추가
증상: 소품이 나타나고, 텍스트나 워터마크가 나타나고, 여분의 사지나 객체가 생김.
Negative: added props, extra objects, text, watermark, logo, signature, extra limbs
실패: 스타일 침투
증상: 국소 편집이 새로운 스타일로 전체 이미지를 다시 그리거나, 스타일 편집이 주체 정체성으로 스며듦.
Negative: global restyle, changed lighting on subject, painterly bleed, uniform filter
실패: 아티팩트 이음새
증상: 객체가 제거된 곳에 흐림이나 번짐; 편집 경계에 딱딱한 모서리.
Negative: blur artifacts, smudge, visible seam, halo, patch mismatch
편집을 망치지 않고 사용하는 방법
실제로 관찰한 실패와 일치하는 네거티브 줄부터 시작하세요. 여섯 개를 한꺼번에 추가하면 종종 출력을 평평하게 만들고 요청한 변경과 충돌할 수 있습니다. 네거티브는 짧고 구체적으로 유지하세요. 긴 "bad quality" 용어 목록은 지향적 편집에 거의 도움이 되지 않습니다. 하나의 네거티브 줄이 한 상황을 고치지만 다른 상황을 망치면 전역 템플릿이 아니라 해당 레시피에 한정하세요.
레시피를 매개변수화된 템플릿으로 전환
복사해 붙여넣는 프롬프트는 시작점일 뿐입니다. 제품에서 확장 가능한 것은 명명된 슬롯, 버전 태그, 담당자가 있는 템플릿입니다. 목표는 모든 엔지니어가 같은 레시피를 호출하고 비교 가능한 동작을 얻는 것입니다.
슬롯 추출
레시피를 보고 요청마다 달라지는 부분을 자리 표시자로 바꾸세요:
변경: 배경을 매끄러운 {backdrop_color} 스튜디오 배경으로 교체.
보존: 주체의 {identity_attributes}; 현재 크롭 유지.
제약: 주체의 원래 조명 방향 일치; 배경에 새 그림자 추가 금지; 텍스트나 로고 금지.
Negative: {failure_negatives}
일반적인 슬롯: 주체 범주, 편집 대상, 대상 값, 보존 속성 목록, 제약 플래그, 네거티브 세트. 같은 호출자 코드가 레시피를 전환할 수 있도록 레시피 간에 슬롯 이름을 안정적으로 유지하세요.
버전 관리 및 레시피 등록
프롬프트를 스키마처럼 다루세요. 각 템플릿에 ID와 버전(background_replace@2)을 부여하고 무엇이 변경되었고 왜 변경되었는지 기록하세요. 모델이나 레시피가 변경된 후 출력 품질이 달라지면 어떤 버전이 주어진 자산을 생성했는지 알아야 합니다. 템플릿 참조뿐 아니라 렌더링된 프롬프트를 출력과 함께 저장하세요.
연결이 아닌 조합
자유 텍스트를 문자열 연결하는 대신 블록으로 프롬프트를 구축하세요 — 변경 블록, 보존 블록, 제약 블록, 네거티브 블록. 블록은 누락된 보존 줄을 린트하고 실패 범주별로 네거티브 세트를 교체할 수 있게 합니다. 작은 보존 블록 라이브러리(인물, 제품, 장면)와 네거티브 블록 라이브러리(정체성, 질감, 추가)를 유지하세요.
템플릿 계층의 가드레일
전송 전에 슬롯을 검증하세요: 알 수 없는 색상, 빈 보존 목록, 여러 변경을 조합한 편집을 거부하세요. API 경계에서 호출당 하나의 변경을 강제하세요. 이러한 검사는 비용이 저렴하며 대부분의 나쁜 프롬프트가 모델에 도달하기 전에 잡아냅니다.
예시와 함께 공유
각 템플릿에는 두세 개의 예시 소스 이미지와 예상 결과가 함께 제공되어야 하여 새 팀원이 여기저기 물어보지 않고도 변경 사항을 기본적으로 점검할 수 있게 하세요. 템플릿과 예시가 재사용의 단위입니다.
자신의 이미지에서 레시피 평가
한 샘플에서 좋아 보이는 레시피는 거의 아무것도 증명하지 못합니다. 프롬프트가 제품에 들어가기 전에 실제 입력을 반영하는 고정 평가 세트에서 자리를 확보해야 합니다.
작은 고정 테스트 세트 구축
열에서 서른 장의 소스 이미지로 시작하는 것이 보통 충분합니다. 실제로 보는 변형을 커버하세요: 주체 유형, 조명 조건, 배경, 화면 비율, 엣지 케이스. 세트를 동결하고 프롬프트 버전 간에 재사용하여 비교가 의미 있게 하세요. 세트가 놓친 실패 범주를 발견하면 새 이미지를 추가하되, 세트도 버전 관리하세요.
레시피별 통과 기준 정의
각 레시피에 대해 통과가 어떤 모습인지 적으세요. 배경 교체의 경우: 주체 정체성 보존, 광晕 없음, 조명 방향 일치, 배경 아티팩트 없음. 색상 변경의 경우: 대상 색상 정확, 라벨 온전, 반사 합리적. 기준은 "느낌" 묘사가 아니라 인간 검토자가 몇 초 안에 확인할 수 있어야 합니다.
절대가 아닌 변형 비교
같은 세트에서 프롬프트 변형을 나란히 실행하고 통과율을 비교하세요. 변경 줄 조정, 단축된 보존 목록, 추가된 네거티브 — 각각이 후보 변형입니다. 간단한 기록을 유지하세요: 변형 ID, 통과 횟수, 두드러진 실패. 이것이 프롬프트 튜닝을 일화에서 작은 실험 일지로 바꿉니다.
레시피 실패와 입력 실패 구분
일부 실패는 소스 이미지와 관련이 있습니다: 낮은 해상도, 심한 가림, 흐릿한 주체. 이를 별도로 기록하세요. 나쁜 입력을 고칠 수 없다고 해서 레시피가 손상되는 것은 아니지만, 파이프라인에는 입력 품질 게이트가 필요할 수 있습니다.
레시피 간 회귀 주의
공유 블록 — 보존 목록, 네거티브 세트 — 이 한 레시피를 개선하면서 다른 레시피를 조용히 해칠 수 있습니다. 공유 블록을 변경할 때는 조정 중인 레시피만이 아니라 전체 세트를 다시 실행하세요. 이것이 템플릿을 모듈식으로 유지하는 주된 이유입니다.
모니터링과 함께 출시
레시피가 출시된 후 프로덕션에서 출력을 샘플링하고 명백한 실패를 평가 세트로 라우팅하세요. 이 루프 — 관찰, 세트에 추가, 변형 테스트, 승격 — 가 입력과 모델 변화에 따라 프롬프트 품질이 저하되는 것을 방지하는 핵심입니다.
세 부분 뼈대에서 시작하고, 작은 평가 세트를 구축하며, 여기의 레시피를 최종 답이 아니라 버전 관리하고 적응할 출발점으로 삼으세요.
관련 글
모든 아티클 보기 →-
사용 가이드
seedream-5.0-pro/image-to-image 시작 가이드: 기능, 가격 및 연동 핵심 포인트
ByteDance 이미지 편집 모델의 기능 경계, 과금 방식 및 엔지니어링 연동 실무
-
사용 가이드
seedream-5.0-pro 텍스트-이미지 생성 입문 가이드: 능력 경계, API 연동 및 비용 관리
개발자를 위한 실무 관점: 파라미터 핵심부터 장당 $0.05 비용 추정까지
-
사용 가이드
Hailuo 2.3 Fast 이미지-투-비디오 입문 가이드: 성능 범위, 가격 및 연동 실무
개발자를 위한 MiniMax 이미지-투-비디오 모델 선택과 연동 핵심 포인트