HiAPI
블로그

사용 가이드

Flux-1 Kontext Max 프롬프트 레시피: 바로 복사해 붙여넣어 효과를 볼 수 있는 편집 프롬프트

오늘 바로 Kontext Max에 붙여넣을 수 있는 지시 문구 패턴과 첫 편집이 빗나갔을 때 반복 개선하는 방법

Nov 3, 2026
Article cover: flat marbled liquid forms in celadon and slate folding over a dark ink field.

Kontext Max 프롬프트 레시피의 본질

프롬프트 레시피는 설명 문장이 아니라, 무엇을 바꾸고 무엇을 유지할지 모델에게 정확히 알려주는 압축된 지시 형식입니다. Flux-1 Kontext Max에서 우리가 사용하는 모든 신뢰할 만한 레시피는 동일한 4단 구조를 따릅니다:

  • 동사——작업 유형: 교체, 제거, 재채색, 추가, 확장, 재스타일링.
  • 대상——동사가 작용하는 영역이나 객체로, 명확히 이름을 붙여야 합니다("왼쪽 인물이 입은 빨간 재킷").
  • 기대 변화——과정이 아니라 최종 상태("색을 바꿔라"가 아니라 "네이비로 만들어라").
  • 보존 조항——완전히 동일하게 유지해야 하는 내용("동일한 직물 주름, 조명, 배경을 유지하라").

따라서 하나의 레시피는 이렇게 읽힙니다: replace the jacket on the person at left with a navy wool coat; keep pose, lighting, and background unchanged.

핵심 멘탈 모델: Kontext Max는 생성기가 아니라 편집기입니다. 입력 이미지에서 출발해 하나의 차이(diff)를 적용합니다. 이 차이가 작고 경계가 정밀할수록 결과는 더 예측 가능합니다. 이미지 생성 설명처럼 읽히는 프롬프트("밤 도시 속 여성의 분위기 있는 초상")는 모델에게 모든 것을 다시 생성할 자유를 주며, 모델은 실제로 그렇게 합니다.

보존 조항은 대부분이 건너뛰는 부분이자 가장 큰 효과를 내는 부분입니다. 이것이 없으면 모델은 이미지의 나머지를 마음대로 바꿀 수 있는 것으로 간주합니다. 이것이 있으면 사실상 자연어로 마스크를 그리는 셈입니다——수동으로 마스크를 만들 필요가 없으니 매우 유용합니다.

레시피는 프롬프트를 여러 입력 흐름으로 분해해 단일 편집 단계로 모읍니다.

결과의 방향을 바꾸는 지시 문구 규칙

이것들은 프롬프트 수준에서 제어할 수 있는 지렛대입니다. 각각은 출력을 예측 가능한 방향으로 안정적으로 밀어줍니다.

설명문이 아니라 명령문을 써라

"오른쪽 아래에 있으면 안 되는 쓰레기통이 있다"가 아니라 "오른쪽 아래의 쓰레기통을 제거하라"라고 씁니다. 명령형 어조는 편집 작업에 직접 대응합니다. 설명형 어조는 장면 설명처럼 읽혀 재생성을 유도합니다.

이미지 전체가 아니라 대상을 지목하라

"이미지 속 텍스트"보다 "문 위의 표지판"이 낫습니다. 이미지에 표지판이 세 개 있다면 어느 것인지 밝히세요("왼쪽 출입구 위에 걸린 나무 표지판"). 공간적 앵커——왼쪽, 오른쪽, 위, 전경, 주체 뒤——는 비용이 거의 들지 않으면서 대부분의 모호함을 없앱니다.

지시당 한 번의 편집만

변경이 두 곳 필요하다면, 같은 영역에 작용할 때만 세미콜론으로 연결하세요: remove the chair; keep the floorboards and shadows beneath it. 관련 없는 편집은 별도 호출로 분리해야 합니다. 관련 없는 변경을 한 프롬프트에 쌓는 것이 부수적 손상을 일으키는 가장 흔한 원인입니다.

순서: 제약이 스타일보다 먼저

보존 및 범위 제약을 어떤 선택적 형용사보다도 앞에 두세요. Keep the background, wardrobe, and expression unchanged; restyle the lighting to soft window light는 효과가 있습니다. 반면 Restyle to soft cinematic lighting, keep background unchanged는 시네마틱 처리가 화면 전체로 새어 나가게 합니다. 모델은 마지막으로 읽은 내용을 주된 참조 프레임으로 삼으므로, 움직일 수 없는 내용으로 마무리하세요.

단계가 아니라 최종 상태를 서술하라

"하늘을 평평한 회색 구름으로 덮어 흐리게 만들어라"는 목표입니다. "채도를 낮추고, 구름을 추가하고, 대비를 줄여라"는 워크플로이며, 모델은 이를 문자 그대로 실행하지 않고 과도하게 적용할 수 있습니다. 보고 싶은 결과를 서술하세요.

긍정 목표가 있을 때는 부정을 피하라

"워터마크를 제거하라"는 괜찮습니다. 제거가 곧 작업이기 때문입니다. 그러나 "흐리게 만들지 마라"는 "주체를 선명하고 초점이 맞게 유지하라"보다 약합니다. 가능하면 제약을 긍정적 불변식으로 표현하세요.

짧게 유지하라

두 문장을 넘는 레시피는 지시를 희석합니다. 프롬프트에 문단 하나가 필요하다면, 아마 편집이 두 개이거나 대상 지정이 부족한 것입니다.

흔한 편집용 복사해 붙여넣을 레시피

아래 레시피는 각각 그대로 붙여넣을 수 있습니다. 대괄호 부분을 상황에 맞게 바꾸세요. 추론 설명은 왜 문구를 이렇게 구성했는지 설명합니다——텍스트만이 아니라 패턴을 배우세요.

객체 교체

replace the [object] at [spatial anchor] with [new object]; keep the surrounding [key surface, e.g. table/floor] and lighting unchanged 추론: 앵커와 보존 조항이 합성을 그럴듯하게 만듭니다. 주변 표면을 명명하면 모델이 문맥을 다시 렌더링하는 것을 막습니다.

객체 제거

remove the [object] at [spatial anchor]; reconstruct the background behind it to match the surrounding [surface] and fill the shadow naturally 추론: 제거에는 무엇이 그 자리를 채우는지 밝혀야 합니다. "배경 재구성"이 없으면 흔히 얼룩이나 어긋난 패치가 나옵니다.

배경 교체

replace the background with [new setting]; keep the subject's silhouette, edge detail, and lighting direction identical 추론: 가장자리 디테일과 조명 방향은 배경 교체가 실패하는 지점입니다. 이를 명시해야 보존됩니다.

표지판 텍스트 편집

change the text on the [sign/label] to read "[new text]"; keep the font weight, perspective, and material of the sign unchanged 추론: 짧고 모호함 없는 대상에 글꼴 원근 고정을 더합니다. 새 텍스트는 짧게 유지하세요——긴 문자열이 바로 아티팩트가 나타나는 곳입니다.

색상 및 재질 변경

recolor the [object] to [color]; preserve the original texture, folds, and highlight placement 추론: "change the color to" 대신 "recolor"를 쓰면 지시가 더 압축되고, 텍스처 조항은 평면 채우기를 막습니다.

아웃페인팅 / 확장

extend the image to the [left/right/top] by roughly [fraction, e.g. one third]; continue the existing [surface, e.g. wall/ground] seamlessly and match the current lighting 추론: 이어갈 표면과 맞출 조명을 명명하는 것이 깔끔한 확장과 보이는 이음새를 가르는 핵심입니다.

자세 또는 표정 미세 조정

adjust the subject's expression to a slight smile; keep head angle, hair, and the rest of the face unchanged 추론: "얼굴의 나머지 부분은 그대로"가 가드레일입니다. 인접 특징을 둘러싸지 않으면 얼굴 편집이 흘러내립니다.

범위 제한이 있는 재스타일링

apply a [style, e.g. watercolor] treatment to the foreground subject only; leave the background photographic and unchanged 추론: 재스타일링 프롬프트는 과도 적용의 최대 원인입니다. 스타일에 범위를 제한하는 것은 선택이 아니라 필수입니다.

각 레시피는 문구를 편집 범위에 매핑합니다: 국소 미세 조정부터 동일한 액체 형태의 전체 재배치까지.

레시피를 코드에 연결하기

레시피는 문자열입니다——코드베이스에서 매개변수와 버전을 붙여 문자열로 다루세요.

연결이 아니라 매개변수화

레시피를 명명된 슬롯이 있는 형태로 저장하고 호출 시 채웁니다:

RECIPES = {
    "object_replace": "replace the {object} at {anchor} with {replacement}; "
                      "keep the surrounding {surface} and lighting unchanged",
    "object_remove": "remove the {object} at {anchor}; reconstruct the background "
                     "behind it to match the surrounding {surface} and fill the shadow naturally",
}

def build(recipe_key, **slots):
    return RECIPES[recipe_key].format(**slots)

이렇게 하면 문구가 수천 장의 이미지에서 안정적으로 유지됩니다. 레시피를 조정해야 한다면 수백 개의 호출 지점이 아니라 문자열 하나만 바꾸면 됩니다.

비교할 때는 입력 이미지를 고정하라

레시피를 튜닝할 때는 기준 이미지 한 장을 재사용하세요. 프롬프트와 입력 이미지를 동시에 바꾸면 차이를 어느 쪽에도 귀속시킬 수 없습니다.

호출 전에 슬롯을 검증하라

빈 앵커는 잘못된 앵커보다 나쁩니다——편집 범위를 조용히 넓히기 때문입니다. 모든 슬롯이 채워졌는지, 자유 텍스트 슬롯(예: 새 표지판 텍스트)이 짧은지 확인하세요.

요청당 한 번의 편집만

Kontext Max의 편집은 호출 단위로 이루어지므로, 파이프라인을 거대한 프롬프트 하나가 아니라 각 단계마다 고유 레시피와 매개변수를 가진 일련의 편집 단계로 모델링하세요. 레시피를 순차적으로 적용하는 작은 단계 실행기가 뒤엉킨 단일 지시보다 디버깅하기 쉽습니다.

렌더링된 프롬프트를 기록하라

채워진 프롬프트를 출력 참조와 레시피 버전과 함께 기록하세요. 출력 품질이 변할 때 문구가 변한 것인지 모델 동작이 변한 것인지 알아야 합니다.

편집 결과가 틀렸을 때

대부분의 실패는 세 가지 범주로 나뉩니다. 먼저 증상을 진단한 뒤 해당 수정을 적용하세요.

증상: 대상이 완전히 빗나감

편집이 다른 곳에서 일어나거나 눈에 띄는 변화가 없습니다.

  • 앵커를 넓히고 정밀하게: "문 위의 표지판" → "왼쪽 출입구 위에 걸린 나무 표지판".
  • 대상이 작다면 명시하세요: "오른쪽 아래의 작은 라벨".
  • 모델이 유사한 객체를 바꿨다면 구분어를 추가하세요: "두 표지판 중 가장 왼쪽 것".

증상: 과도 편집

한 곳만 요청했는데 모델이 세 곳을 바꿨습니다.

  • 보존 조항을 추가하거나 강화하세요: 반드시 유지해야 할 정확한 요소를 명시("자세, 의상, 배경을 그대로 유지하라").
  • 제약을 변경 지시 뒤로 옮기거나 끝에 반복하세요——위치가 중요합니다.
  • 쌓인 프롬프트를 별도 호출로 분리하세요.

증상: 드리프트

의도는 맞지만 주변 이미지가 어긋났습니다——색, 조명, 디테일이 움직였습니다.

  • 모호한 보존 요구를 구체적 불변식으로 바꾸세요: "같게 유지하라"가 아니라 "원래 화이트 밸런스, 그림자 방향, 직물 텍스처를 유지하라".
  • 스타일 형용사가 밖으로 새는지 확인하고 범위를 제한하세요("전경만").
  • 지시를 최소 형태로 줄이고 기준 이미지에서 다시 테스트하세요.

반복

레시피 실행 → 실패를 대상 빗나감, 과도 편집, 드리프트로 분류 → 해당하는 단일 수정 적용 → 동일한 기준 입력에서 다시 실행. 반복마다 변수는 하나만 바꾸세요. 두 개를 동시에 바꾸면 어느 것이 효과를 냈는지 알 수 없습니다.

짧은 실패 로그를 유지하세요: 레시피 버전, 채워진 프롬프트, 증상, 수정, 결론. 몇 개의 프로젝트를 거치면 이 로그가 어떤 단일 프롬프트보다도 가치 있어집니다.

증상에서 수정으로 가는 디버깅 루프: 실행, 실패 분류, 문구 조정, 재실행.

나만의 레시피 라이브러리 구축

Kontext Max에서 안정적인 결과를 얻는 팀은 더 나은 일회성 프롬프트를 쓰는 것이 아니라, 검증된 버전 관리된 작은 프롬프트 집합을 유지합니다.

레시피를 명시적으로 버전 관리하라

각 레시피에 키와 버전을 부여하세요(object_replace@v2). 문구를 바꾸면 버전을 올리고 이전 버전을 사용 가능하게 남겨 두세요. 미세한 문구 변화가 뚜렷이 다른 출력을 낳기 때문에, 버전 관리 없는 프롬프트 라이브러리는 조용한 회귀의 원천입니다.

고정 스위트로 테스트하라

소수의 고정 입력 이미지와 알려진 기대 편집——교체 하나, 제거 하나, 배경 교체 하나, 표지판 편집 하나——을 유지하세요. 레시피가 바뀔 때마다 이 스위트를 실행합니다. 두 가지를 봅니다: 대상이 편집되었는지, 주변 이미지가 그대로인지. 첫째는 훌륭하지만 둘째가 실패하는 레시피는 아직 준비되지 않은 것입니다.

추측 대신 레시피를 비교하라

두 문구가 모두 그럴듯할 때는 동일한 기준 입력에서 둘 다 실행하고, 보존 조항을 지키는 쪽을 택하세요. 비교는 저렴하지만, 편집된 이미지 배치를 다시 촬영하는 것은 그렇지 않습니다.

레시피가 자연스럽게 쌓이게 하라

위의 여덟 가지 패턴에서 시작하세요. 동료가 새로운 편집 사례를 해결하면 왜 이 문구가 효과적인지 설명과 함께 추가하세요. 시간이 지나면 이 라이브러리는 팀의 암묵적 프롬프트 엔지니어링 문서가 되고, 이 API를 처음 접하는 사람의 입문 자료가 됩니다.

삭제 대신 폐기하라

당신 기억의 컨텍스트 윈도우는 짧습니다. 어떤 이미지 유형에서 실패하는 레시피가 다른 유형에는 완벽할 수 있습니다. 폐기된 레시피를 보관하고 왜 폐기했는지 메모해 두어 다음 사람이 같은 실수를 반복하지 않게 하세요.

프롬프트를 코드처럼 다루세요: 버전 관리, 테스트, 리뷰, 재사용. 이 규율이 Flux-1 Kontext Max를 데모에서 파이프라인의 신뢰할 수 있는 한 부분으로 바꿔 줍니다.

영구 AI 아티팩트로 빌드 시작하기

API 키를 받아 태스크 기반의 하나의 API로 이미지, 비디오, 오디오 모델을 호출하세요.

API 문서 보기