
「프롬프트를 쓸 수 없다」의 대안: 참조 이미지 3장으로 이미지 생성을 제어하는 메커니즘과 한계
요약
텍스트 프롬프트의 한계를 극복하기 위해 참조 이미지를 직접 사용하는 '이미지 프롬프팅'의 개념과 기술적 계통을 분석합니다. 이미지 가이드, 이미지 임베딩, 캡션 매개형 방식의 차이점과 작동 원리를 설명합니다.
핵심 포인트
- 텍스트 프롬프트는 언어화 과정에서 시각적 정보의 손실이 발생함
- 이미지 가이드는 픽셀 구조를 직접 주입하여 구도와 포즈 제어에 탁월함
- 이미지 임베딩은 특징 벡터를 활용해 화풍과 스타일 재현에 강점이 있음
- 캡션 매개형은 VLM을 통해 이미지를 텍스트로 변환 후 재합성하는 방식임
이미지 생성 AI를 사용하면서 가장 많은 시간을 허비하는 부분은 어디인가요? 생성 대기 시간이 아니라, "머릿속의 이미지를 영어 프롬프트로 번역하는 작업"이라고 말하는 사람이 많을 것입니다. 조명(Lighting)이나 카메라 앵글(Camera angle)의 어휘를 익히고, 모델마다 미묘하게 다른 "효과적인 작성법"을 시도해도, 여전히 상상과 조금 어긋나는 이미지가 나오는 상황──이 루프에 공감한다면, 문제는 기술 부족이 아니라 시각적인 의도를 텍스트만으로 전달하려는 워크플로우(Workflow) 측면에 있을지도 모릅니다.
이 기사에서는 텍스트 프롬프트 대신 **참조 이미지 그 자체를 입력으로 사용하는 "이미지 프롬프팅 (Image Prompting)"**의 개념을 정리합니다. 이 방식을 간편하게 시도할 수 있는 플랫폼으로 Whisk AI를 예로 들겠지만, 이는 Google의 Gemini와 Imagen을 기반으로 피사체(Subject)・장면(Scene)・스타일(Style)의 3장 참조 이미지로부터 새로운 이미지를 합성하는 타입의 워크플로우를 제공하는 서비스 중 하나입니다. 특정 도구의 홍보가 목적이 아니라, "이미지로 지시한다"는 설계 사상 그 자체와 그 장단점을 살펴보겠습니다.
원인을 분석해 보면, 텍스트 프롬프트에는 구조적인 병목 현상이 세 가지 있습니다.
언어화의 손실: 머릿속의 비주얼은 본래 구도・질감・빛・색이 동시에 존재하는 비언어 정보입니다. 그것을 단어의 나열로 바꾸는 시점에서 반드시 정보가 결락됩니다. "감성적인 저녁 빛"을 프롬프트로 쓸 수 있는 사람은 사실 이미 사진 용어 훈련을 받은 사람입니다. -
어휘에 대한 의존: chiaroscuro, shallow depth of field, isometric view──원하는 결과를 얻기 위한 어휘는 도메인 지식 그 자체입니다. 모르는 개념은 쓸 수 없고, 쓸 수 없는 것은 생성되지 않습니다. -
모델별 방언: 같은 프롬프트라도 모델이 바뀌면 해석이 달라집니다. 어떤 모델에서 안정적이었던 작성법이 다른 모델에서는 통하지 않습니다. 프롬프트의 자산성은 상상 이상으로 낮습니다.
요컨대 "보면 알 수 있는 것을 왜 굳이 한 번 언어로 되돌리는가"라는 문제입니다. 여기서 "이미지로 직접 지시하면 된다"라는 발상이 나옵니다.
"참조 이미지를 사용한다"라고 한마디로 말해도, 기술적으로는 적어도 세 가지 계통이 있으며 성질이 상당히 다릅니다. 이 부분을 구분하지 않고 "img2img와 무엇이 다른가?"라고 생각하는 경우가 많으므로 먼저 정리하겠습니다.
이미지 가이드 (Image Guide): 참조 이미지의 픽셀 구조(윤곽, 깊이, 포즈)를 생성 과정에 직접 주입하는 방식입니다. 구도를 러프화(Rough sketch)대로 고정하고 싶거나, 포즈를 엄격하게 지정하고 싶은 용도로는 최강이지만, Stable Diffusion 계열의 로컬 환경 구축이나 컨트롤 종류별 전처리 지식이 필요하여 도입 비용이 높습니다.
이미지 임베딩 (Image Embedding): 참조 이미지를 특징 벡터(Feature vector)로 변환하여 생성 조건에 섞어 넣는 방식입니다. "이 화풍을 재현하고 싶다"라는 요구에 강하며, LoRA를 직접 제작하면 재현성도 높습니다. 다만 학습 데이터 준비나 파라미터 조정이 필요하며, 이 역시 기본적으로는 로컬 환경 + GPU의 영역입니다.
캡션 매개형 (Caption-mediated): 시각 언어 모델(VLM)이 참조 이미지를 분석하여 상세한 구조화된 캡션(Structured caption)을 자동 생성하고, 그 텍스트를 이미지 생성 모델에 전달하는 방식입니다. Google이 Whisk에서 채택한 접근법이며, 서두에서 언급한 Whisk AI도 이 계통입니다. Gemini가 각각의 DNA──피사체의 특징, 장면의 분위기, 스타일의 필치──를 언어화하고, Imagen이 재합성합니다. 사용자 입장에서는 "이미지 3장을 드래그할 뿐"이지만, 내부에서는 이미지→텍스트→이미지라는 변환이 일어나고 있습니다.
이 방식의 본질적인 특징은, 참조 이미지의 "본질(Essence)"을 추출하는 것이지 픽셀을 복제하는 것이 아니라는 점입니다. 이는 사양이며, 후술할 한계의 근원이기도 합니다.
다른 방식과 비교하기 전에, 캡션 매개형 워크플로우에서 소재로부터 사용할 수 있는 결과물까지 어떻게 진행되는지 살펴보겠습니다.
입력은 최대 3장: 피사체(무엇을), 장면(어디서), 스타일(어떤 모습으로). 전부 채울 필요는 없으며, 피사체 1장 + 스타일 1장과 같은 조합으로도 작동합니다. 여기서의 판단 기준은 "그 이미지의 어떤 요소를 이어받고 싶은가"를 스스로 명확히 해두는 것입니다. 노이즈가 많은 이미지(요소가 너무 많은 사진)는 의도하지 않은 특징까지 잡아내는 원인이 됩니다.
시스템이 VLM(Vision-Language Model)으로 각 이미지를 분석하여 생성용 프롬프트를 구성합니다. 이 타입의 도구를 선택할 때 중요한 체크포인트는, 이 중간 캡션(Intermediate Caption)이 보이는가·편집할 수 있는가입니다. 보이는 도구라면 'AI가 자신의 참조 이미지를 어떻게 해석했는지'를 확인할 수 있고, 차이가 있다면 텍스트 레벨에서 수정할 수 있습니다. 블랙박스 상태로 남아 있다면, 결과가 어긋났을 때 대응할 방법이 없습니다.
첫 번째 출력은 '참조 이미지의 재현'이 아니라 '참조 이미지의 요소를 이어받은 새로운 이미지'로서 평가해야 합니다. 체크해야 할 점은 (a) 피사체의 동일성이 어디까지 유지되고 있는가, (b) 스타일의 전사(Transfer)가 표면적인가 구조적인가, (c) 의도하지 않은 요소가 혼입되지 않았는가, 이 세 가지입니다. 여기서 '픽셀 복사(Pixel Copy)를 기대했다'는 사실을 깨닫는 사람이 가장 많습니다.
차이를 수정하는 방법은 참조 이미지를 교체하거나, 중간 캡션을 직접 편집하는 것 중 하나입니다. 경험상 유효한 방법은 이미지로 큰 틀(구도·화풍)을 고정하고, 텍스트 편집으로 세부 사항(색상, 소품, 표정)을 다듬는 역할 분담입니다. 텍스트 프롬프트를 완전히 버리는 것이 아니라, '제로 베이스에서 쓰는 것'을 '차이점(Difference)만 쓰는 것'으로 바꾸는 것이 이 워크플로우의 실용적인 활용법입니다.
다음 표는 세 가지 워크플로우를 출발점·기술·속도·제어·적용 장면·주요 한계의 6개 축으로 비교한 것입니다.
| 비교 축 | 참조 이미지 분리 워크플로우 (Whisk AI 등) | 텍스트 프롬프트 직접 작성 | img2img / ControlNet (로컬 환경) |
|---|---|---|---|
| 출발점 | 수중에 있는 참조 이미지 3장 | 머릿속 이미지의 언어화 | 러프 스케치·포즈 소재 + 환경 구축 |
| ... |
표에서 알 수 있듯이, 이것은 우열의 문제가 아니라 페이즈(Phase)의 차이입니다. 방향성을 탐색하는 단계에서는 참조 이미지 방식이 빠르고, 요구 사항이 확정된 본 제작 단계에서는 픽셀 조건부(Pixel Conditioning)의 제어력이 힘을 발휘합니다.
굿즈·머천다이즈 목업(Mock-up): 캐릭터 이미지를 에나멜 핀 스타일, 스티커 스타일, 인형 스타일로 변환하여 제조 전 프리뷰를 양산하는 용도. 스타일 프리셋이 준비되어 있는 타입의 도구가 적합하며, 이 용도에서는 '엄격한 재현'보다 '분위기 확인'이 목적이므로 캡션 매개 방식의 약점이 문제가 되지 않습니다.
캐릭터 디자인의 베리에이션 탐색: 기존 캐릭터를 다른 화풍이나 다른 상황에 배치하여 수십 가지 패턴을 시도하는 작업. 게임의 컨셉 단계나 VTuber의 의상 안 도출 등 '많이 뽑아서 고르는' 페이즈에서 생성 속도가 큰 이점이 됩니다.
블로그·LP의 비주얼 러프: 디자이너에게 의뢰하기 전에, 참고하고 싶은 사이트의 톤을 스타일 참조로 넣고 자사 모티프를 피사체로 하여 러프를 만드는 작업. 디렉션을 위한 초안(Draft)으로서는 충분한 정밀도가 나옵니다.
이 워크플로우를 권장하는 많은 기사들이 다루지 않는 점을 미리 적어둡니다.
동일성은 보장되지 않는다: 캡션 매개 방식인 이상, 참조 이미지는 한 번 텍스트로 '요약'됩니다. 특정 인물의 얼굴, 브랜드 로고, 캐릭터의 세부 디테일처럼 요약 과정에서 손실되는 정보는 재현되지 않습니다. 자신의 반려동물을 넣었을 때 '비슷한 견종의 다른 개'가 나오는 것이 이 방식의 정상적인 동작입니다. 엄격한 동일성이 필요하다면 방식 1·2의 영역입니다. -
가차(Gacha)성은 남는다: 중간 캡션을 편집할 수 있더라도 최종적인 생성은 확률적입니다. 한 번에 결정된다는 것을 전제로 하지 말고, 반복을 고려한 시간 배분이 필요합니다. -
본 제작의 대체재가 아니다: 출력이 고해상도라 하더라도, 상업용 비주얼로 내보내기 위해서는 인간의 리뷰와 수정이 전제되어야 합니다. 특히 손가락·문자·세밀한 패턴은 기존 이미지 생성 모델의 공통적인 약점으로 남아 있습니다. -
무료 범위는 체험 수준이다: 이 종류의 호스팅형 서비스의 무료 범위는 월 몇 회 생성할 수 있는 규모이므로, 업무에 활용하려면 유료 플랜을 전제로 비용을 산출해야 합니다.
참조 이미지 분리형 워크플로우가 적합한 사람은 '만들고 싶은 것은 보여줄 수 있지만, 말로 설명하기는 어려운' 페이즈에 있는 사람입니다. 구체적으로는 아이디어 탐색의 초기 단계, 스타일 실험, 목업 양산입니다. 반대로 구도의 엄격한 지정이나 특정 캐릭터의 충실한 재현이 요구 사항이라면, ControlNet이나 LoRA가 있는 로컬 환경이 여전히 정답입니다.
텍스트 프롬프트가 불필요해지는 것이 아니라, '제로 베이스에서의 언어화'가 '참조 이미지 + 차이점 편집'으로 대체되는 것──이미지 생성의 입력 인터페이스는 그 방향으로 한 걸음씩 움직이고 있습니다. 프롬프트를 쓰는 것이 힘들어서 이미지 생성을 멀리했던 사람이라면, 이 방식을 한 번 시도해 봄으로써 자신이 막혔던 것이 어휘력이 아니라 워크플로우였다는 것을 깨닫게 될 것입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기