여러 참조 이미지의 드리프트를 막는 법: 구도와 스타일을 분리하기

이미지 생성 도구에 레이아웃 참조, 스타일 참조, 피사체 이미지를 함께 넣었다고 해보겠습니다. 요청은 오류 없이 끝났지만 결과는 흔한 스톡 이미지처럼 보입니다. 피사체 위치가 바뀌고, 제목을 위해 남겨 둔 여백이 사라지며, 여러 시각 스타일이 모호한 ‘AI 느낌’으로 섞입니다. 이때 프롬프트 문장을 더 길게 만드는 것부터 시작하면 원인을 찾기 어렵습니다. 먼저 각 참조 이미지에 하나의 명확한 역할을 주고, 그다음 결과를 의도한 구도와 항목별로 비교해야 합니다.

한 공개 사례에서는 에이전트가 여러 스타일 참조를 하나의 평면적인 파라미터로 이어 붙였습니다. 모델은 입력을 평균 낸 듯한 결과와 일반적인 텍스처를 반환했지만 API 오류는 발생하지 않았습니다. 이 한 사례만으로 모든 모델의 보편적인 동작을 단정할 수는 없습니다. 다만 중요한 차이는 보여 줍니다. 기술적으로 성공한 요청과 시각적으로 성공한 작업은 같은 것이 아닙니다.

실무 원칙: 한 이미지는 구도를, 다른 이미지는 외형을 맡긴다

가장 효과적인 변화는 모든 이미지를 설명 없는 동등한 참조 목록으로 취급하지 않는 것입니다. 최소한 다음 세 역할을 분리하세요.

참조 역할	통제해야 할 요소	통제하면 안 되는 요소
구도 참조	피사체 수, 위치, 상대 크기, 카메라, 크롭, 네거티브 스페이스	색상 팔레트, 재질, 붓질, 조명 스타일
피사체 참조	사람이나 사물의 정체성, 형태, 특징적인 세부 요소	전체 구도나 관련 없는 배경 오브젝트
스타일 참조	팔레트, 질감, 선의 성격, 그레인, 조명, 렌더링 언어	해당 이미지의 오브젝트, 텍스트, 구도

작업에 구도와 스타일만 필요하다면 두 이미지만 사용하세요. 참조를 많이 넣는다고 제어력이 자동으로 커지는 것은 아닙니다. 오히려 시스템이 서로 조정해야 하는 경쟁 신호가 늘어날 수 있습니다.

평면적인 참조 목록이 흔한 절충안으로 흐르는 이유

평면 목록은 “이 이미지들이 모두 중요하다”는 사실만 전달하고, 각각이 왜 중요한지는 알려 주지 않습니다. 모델이나 중간 에이전트가 관계를 추측해야 합니다. 한 이미지에서 색을, 다른 이미지에서 질감을, 세 번째 이미지에서 원치 않는 오브젝트를 가져와 보기에는 그럴듯하지만 목표와 다른 절충안을 만들 수 있습니다.

이런 실패는 구조적인 오류를 만들지 않을 수 있습니다. 인증, 업로드, 요청 문법, 응답 파싱이 모두 정상이어도 시각 결과는 요구사항을 놓칠 수 있습니다. 따라서 HTTP 성공 상태나 “generation completed” 메시지는 시각적 합격 기준이 될 수 없습니다. 생성 후 구도를 검사하는 단계가 필요합니다.

1단계: 각 참조 이미지의 역할 계약을 작성한다

긴 프롬프트를 쓰기 전에 이미지마다 다음 네 질문에 답하세요.

1. 반드시 유지해야 하는 것은 무엇인가? 예: 피사체는 왼쪽 아래에 두고, 위쪽은 제목을 위해 비우며, 카메라는 로우 앵글을 유지한다.
2. 무시해야 하는 것은 무엇인가? 예: 스타일 참조 속 인물의 정체성, 브랜드 문구, 배경 건축물은 가져오지 않는다.
3. 조건은 얼마나 엄격한가? 구도는 반드시 지켜야 하고 색은 선호 조건인지, 또는 그 반대인지 정한다.
4. 참조가 충돌하면 무엇이 우선인가? 예: 오브젝트 위치는 스타일 이미지가 암시하는 배치보다 구도 참조를 우선한다.

실제로 쓸 수 있는 역할 계약은 다음과 같습니다.

파일	역할	유지	무시	충돌 규칙
layout.png	구도	두 피사체의 대소 관계, 오른쪽 여백, 위에서 내려다보는 시점	색과 재질	공간 관계는 다른 모든 참조보다 우선
subject.png	피사체	실루엣과 특징적인 세부 요소	원래 배경과 카메라	레이아웃 속 위치는 유지한 채 피사체만 교체
style.png	스타일	따뜻한 회색 팔레트, 종이 그레인, 부드러운 그림자	이미지 속 사람과 텍스트	외형만 전달하고 콘텐츠는 복사하지 않음

“참조 1, 2, 3”이라고만 쓰는 것보다 낫습니다. 원하는 신호뿐 아니라 전달되면 안 되는 요소까지 정의하기 때문입니다.

2단계: 평면 목록을 계층적인 요청으로 바꾼다

실제 API 필드는 도구마다 다릅니다. 아래 예시는 개념을 설명하기 위한 요청 구조이며, 특정 공급자의 실제 API 계약이 아닙니다. 에이전트가 최종 요청까지 역할 정보를 보존하는지 확인하는 데 사용하세요.

references:
  - id: layout
    source: layout.png
    role: composition
    preserve: [subject_count, position, scale, camera, negative_space]
  - id: subject
    source: subject.png
    role: identity
    preserve: [shape, distinctive_details]
  - id: style
    source: style.png
    role: appearance
    preserve: [palette, texture, line_quality, lighting]
    exclude: [objects, text, composition]
priority:
  - layout
  - subject
  - style
acceptance_reference: layout.png

중요한 질문은 API가 이 필드 이름을 그대로 쓰는지가 아닙니다. 같은 의미가 전체 처리 과정에서 살아남는지가 핵심입니다. 에이전트가 실제로 보낸 최종 요청을 확인하세요. 이미지 배열이 하나의 연결된 문자열로 바뀌지는 않았는지, 역할 설명이 일반 문장에 섞여 사라지지는 않았는지, 재시도나 배치 처리 때문에 파일 순서가 달라지지는 않았는지 살펴봅니다.

대상 API가 분리된 참조 유형, 가중치, 편집 마스크를 문서로 지원한다면 역할 계약을 공식 스키마에 맞추세요. 그런 기능이 없다면 존재하지 않는 파라미터를 만들어 내지 말고 단계형 작업 방식으로 전환하세요.

3단계: 도구가 역할을 표현하지 못하면 두 단계로 나눈다

인터페이스가 구분 없는 이미지 묶음만 받는다면 먼저 구도를 고정하고 그다음 스타일을 적용하세요. 모든 신호를 한 요청에 밀어 넣는 것보다 두 변환을 나누는 편이 문제를 진단하기 쉽습니다.

단계 A: 구도와 피사체를 확정한다

구도 참조를 사용하고 꼭 필요할 때만 피사체 참조를 추가합니다. 피사체 수, 배치, 카메라, 크롭, 여백을 설명하고 재질이나 렌더링 언어는 이 단계에서 제외합니다. 아직 단순해 보여도 구조적으로 올바른 이미지를 만드는 것이 목표입니다.

단계 B: 장면을 다시 만들지 않고 외형만 적용한다

단계 A의 결과를 새 베이스 이미지로 삼아 스타일 참조와 함께 편집하거나 다시 그립니다. 피사체의 위치와 경계, 카메라, 크롭, 네거티브 스페이스는 고정하고 팔레트, 질감, 선의 성격, 조명만 바꿀 수 있다고 명시합니다.

마스크를 지원한다면 수정할 영역만 열어 두세요. 편집 모드가 없다면 단계 A 이미지를 주 참조로, 스타일 이미지를 보조 참조로 둡니다. 명시적인 가중치를 사용할 수 있는지는 현재 도구 문서에 따라 달라집니다.

4단계: 네 가지 통제 변형으로 신호가 사라지는 지점을 찾는다

복잡한 요청 하나를 계속 덧붙여 수정하지 마세요. 프롬프트, 크기, 그 밖의 통제 가능한 설정을 고정하고 네 가지 변형을 생성합니다.

테스트	입력	확인할 내용
A	구도 참조만	피사체 수, 위치, 카메라, 크롭, 여백을 유지하는가?
B	스타일 참조만	팔레트, 질감, 선, 조명 중 실제로 무엇을 전달하는가?
C	구도와 스타일을 평면 목록으로 입력	절충, 스타일 평균화, 원치 않는 콘텐츠 유입이 발생하는가?
D	구도와 스타일에 역할과 우선순위를 명시	각 목표가 테스트 C보다 의도에 가까워지는가?

이것은 모델이 “좋다”거나 “나쁘다”고 판정하는 테스트가 아닙니다. 문제가 단일 이미지 해석, 여러 이미지 결합, 에이전트의 파라미터 처리 중 어디서 시작되는지 찾기 위한 방법입니다. A와 B는 잘 작동하고 C에서 드리프트가 생기며 D에서 개선된다면 역할의 모호성이 유력한 원인 후보입니다. D가 C와 같다면 최종 페이로드를 점검하거나 단계형 방식을 사용하세요.

도구가 seed를 지원한다면 임의 차이를 줄이기 위해 모든 변형에서 같은 값을 유지하세요. seed가 없다면 비교를 결정론적인 것으로 포장하지 말고, 변형마다 여러 샘플을 만든 뒤 반복되는 구조적 실패를 찾으세요.

5단계: “보기 좋다”가 아니라 목표 구도를 기준으로 합격시킨다

위험한 결과가 항상 못생긴 것은 아닙니다. 빠른 검토를 통과할 만큼 세련돼 보여도 실제 템플릿을 놓칠 수 있습니다. 스타일을 평가하기 전에 하드 제약부터 확인하세요.

하드 제약: 하나라도 틀리면 후보를 탈락시킨다

• 피사체 수가 정확하다.
• 위치와 상대 크기가 레이아웃과 일치한다.
• 카메라 방향, 크롭, 시점이 정확하다.
• 텍스트를 위한 예약 공간이나 네거티브 스페이스가 남아 있다.
• 스타일 참조의 오브젝트, 사람, 텍스트가 결과로 유입되지 않았다.
• 피사체의 특징적인 요소를 알아볼 수 있다.

소프트 제약: 통과한 후보의 순위를 정할 때 사용한다

• 팔레트가 목표에 가깝다.
• 질감과 그레인이 탁함이 아니라 의도된 표현처럼 보인다.
• 선, 가장자리, 그림자가 원하는 시각 언어와 맞는다.
• 여러 스타일의 평균이 아니라 하나의 일관된 결과처럼 보인다.

구도 참조와 각 후보를 나란히 놓고 하드 제약마다 통과 또는 실패를 기록하세요. 최종 이미지만 저장하지 말고 요청 버전, 참조 순서, 에이전트가 보낸 정확한 페이로드도 함께 보관하세요. 그래야 다음 드리프트를 재현하고 원인을 찾을 수 있습니다.

흔한 증상은 올바른 순서로 진단한다

증상	먼저 확인할 것	권장 대응
스타일은 강하지만 구도가 바뀜	스타일 이미지가 동등한 주 참조로 처리됐는가?	구도 우선순위를 높이거나 구도와 스타일을 단계로 분리
구도는 맞지만 스타일이 약함	프롬프트가 추상적인 분위기 단어로만 되어 있는가?	관찰 가능한 팔레트, 재질, 선, 조명 특성을 명시
여러 스타일이 일반적인 외형으로 섞임	충돌하는 스타일 이미지를 함께 넣었는가?	하나를 주 스타일로 정하고 나머지는 각각 한 특성만 담당
스타일 이미지의 피사체가 결과에 나타남	외형만 전달하라는 제한을 적었는가?	오브젝트, 텍스트, 구도를 명시적으로 제외
프롬프트 수정이 결과에 반영되지 않음	에이전트가 새 파라미터를 실제로 보냈는가?	상위 입력 화면이 아니라 최종 페이로드를 비교
API는 성공하지만 결과가 계속 드리프트함	기술적 성공을 시각적 합격으로 사용하고 있는가?	하드 구도 게이트와 통제 비교를 추가

재사용할 수 있는 최소 작업 흐름

1. 작업을 완성하는 데 필요한 참조만 선택한다.
2. 각 이미지에 하나의 주 역할을 주고, 유지·무시·충돌 규칙을 작성한다.
3. 최종 에이전트 요청에서 배열, 순서, 역할 정보가 평면화되지 않았는지 확인한다.
4. 평면 목록과 역할 분리 버전을 비교하기 전에 구도 전용, 스타일 전용 기준 결과를 만든다.
5. 스타일을 비교하기 전에 하드 구도 제약으로 후보를 탈락시킨다.
6. 후보, 참조, 요청 버전, 합격 결과를 함께 저장한다.
7. 인터페이스가 역할을 표현하지 못하면 구도를 먼저 만들고 스타일을 나중에 적용한다.

목표는 프롬프트를 더 길게 쓰는 것이 아닙니다. 모든 시각 신호에 담당자가 있는 작업 흐름을 만드는 것입니다. “이 속성은 어떤 이미지가 통제하는가, 충돌하면 어떤 규칙이 이기는가, 무엇을 통과로 볼 것인가”에 답할 수 있다면 여러 참조 이미지는 더 이상 모델이 혼자 해석해야 하는 모호한 이미지 더미가 아닙니다.