새로운 이미지 모델이 출시될 때마다 제 피드는 똑같은 내용으로 가득 찹니다. 화려한 데모와 "미쳤다"라는 단어들이죠. 빌더 (builder)로서 저는 그 모든 것을 무시하는 법을 배웠습니다. 데모는 빌드 (build) 결정을 위한 근거가 아닙니다.

새로운 이미지 모델에 대해 제가 던지는 유일한 질문은 이것입니다: 이 모델이 내 파이프라인 (pipeline)에서 어떤 노드 (node)를 삭제하는가? 왜냐하면 실제 제품에서 이미지 생성은 결코 단일 단계가 아니기 때문입니다. 그것은 체인 (chain)입니다. 베이스를 생성하고, 엉망으로 나온 텍스트를 수정하고, 브랜드 정체성을 유지하기 위해 참조 제품을 합성 (composite)하고, 배경을 제거하고, 적절한 크기로 내보내는 과정입니다. 이 각각이 하나의 노드이며, 모든 노드는 도구이자 비용이며, 문제가 발생하는 지점입니다.

그래서 저는 그러한 관점으로 GPT Image 2를 살펴보았습니다. 이것이 무엇을 목표로 하는지, 무엇을 목표로 하지 않는지, 그리고 여러분의 스택 (stack)에 무엇인가를 연결하기 전에 직접 실행해 볼 수 있는 테스트를 소개합니다.

유용한 질문은 모델이 인상적인가가 아니라, 어떤 워크플로우 (workflow) 노드를 제거하는가입니다.

앞으로의 내용을 읽는 방식에 영향을 줄 수 있는 두 가지 공개 사항을 먼저 말씀드립니다. 첫째, 저는 벤치마크 (benchmark)를 실행하지 않았습니다. 저는 측정된 수치를 제공할 수 없으며, 이토록 새로운 모델에 대해 딱 떨어지는 수치를 제시하는 누구도 믿어서는 안 됩니다. 제가 드릴 수 있는 것은 여러분이 직접 실행해 볼 수 있는 정확한 평가 (eval) 방법입니다. 둘째, 여기서 언급되는 "GPT Image 2"라는 이름과 접근 권한은 OpenAI에서 직접 제공하는 것이 아니라 제3자 플랫폼에서 온 것입니다. 모델의 정체성과 라이선스를 OpenAI의 공식 문서와 대조하여 확인하기 전까지는, 기능에 대한 주장을 해당 플랫폼의 주장으로 간주하십시오.

GPT Image 2란 무엇인가, 한 단락 요약

제가 살펴본 플랫폼에서 마케팅하는 방식에 따르면, GPT Image 2는 해당 플랫폼이 OpenAI의 이미지 계보를 넘어선 단계로 포지셔닝하는 텍el-to-image (text-to-image) 및 이미지 편집 (image-editing) 모델입니다. 맥락을 위해 설명하자면, OpenAI가 실제로 출시한 모델은 DALL·E 3와 gpt-image-1이므로, 이를 의존하기 전에 OpenAI의 문서를 통해 정확한 모델 정체성을 확인하십시오. 이 모델의 세 가지 주요 기능은 멀티 레퍼런스 퓨전 (multi-reference fusion, 최대 16개의 참조 사진을 하나의 일관된 장면으로 결합), 비라틴 문자(non-Latin scripts)를 포함하여 읽을 수 있는 이미지 내 텍스트 (legible in-image text), 그리고 자연어 사진 편집 (natural-language photo editing)입니다. 이것이 홍보 문구입니다. 이제 이를 파이프라인 노드 (pipeline nodes)에 매핑해 보겠습니다.

이 모델이 진정으로 겨냥하는 두 가지 노드

데모로 보여주기 좋은 기능 대부분은 빌더 (builder)에게는 노이즈에 불과합니다. 하지만 두 가지는 다릅니다.

노드 1: 합성 (compositing) 단계 없는 일관된 참조 (consistent references). 만약 일련의 이미지 전반에 걸쳐 동일한 제품, 캐릭터 또는 브랜드 자산이 일관되게 나타나야 했던 적이 있다면, 그 고통을 알고 계실 것입니다. 여러분은 ControlNet을 찾거나, 참조 조건부 모델 (reference-conditioned model)을 사용하거나, 수동으로 합성 (composite)하게 됩니다. 최대 16개의 참조를 퓨전 (fusing)하는 기능은 바로 그 노드를 정조준합니다. 만약 이것이 장면 전체에서 정체성 (identity)을 유지할 수 있다면, 그것은 실질적인 진보입니다.

노드 2: 이미지 내부의 텍스트. 이것은 저에게 가장 많은 시간을 소모하게 했던 부분입니다. 이미지 모델들은 역사적으로 타이포그래피 (typography)에 매우 취약했기 때문에, 워크플로우는

API 액세스를 먼저 연결하지 않고 이 두 가지를 시도해보고 싶다면, 호스팅된 GPT Image 2 플레이그라운드를 통해 브라우저에서 레퍼런스 퓨전 (reference fusion)과 이미지 내 텍스트 (in-image text) 기능을 실행할 수 있습니다. 약속드렸던 공개 사항을 말씀드리자면, 이 플랫폼은 OpenAI가 아닌 독립적인 제3자 플랫폼이며, 무료 티어는 평가 및 개인용으로만 제공됩니다. 상업적 이용은 유료 플랜을 통해 제한됩니다. 이 기능이 귀하의 업무에 실제로 유용한지 결정하는 용도로 사용하신 후, OpenAI의 문서를 통해 프로덕션 (production) 경로를 확인하시기 바랍니다.

10분 안에 실행 가능한 재현 가능한 평가 (reproducible eval)

데모 프롬프트가 아닌, 구체적인 파이프라인 작업에 모델을 실행하십시오.

제 해석이나 다른 사람의 데모를 믿지 마세요. 직접 실행해 보십시오. 이것은 제가 새로운 이미지 모델이 나올 때마다 던지는 동일한 세 가지 작업 테스트이며, 파이프라인 노드 (pipeline nodes)에 직접적으로 매핑됩니다.

작업 1 — 레퍼런스 퓨전 (Reference fusion, 일관성)
  입력: 동일한 제품 사진 3장 + 배경 사진 1장
  프롬프트: "이 제품을 이 장면에 배치하고, 스튜디오 조명을 적용하며, 라벨을 정확하게 유지할 것"
...

각 작업에 대해 통과 (pass), 부분 통과 (partial), 또는 실패 (fail) 점수를 매기고, 가장 중요한 유일한 열을 하나 추가하십시오:

| 작업              | 결과    | 파이프라인 노드를 삭제하는가? |
|------------------|---------|--------------------------|
| 레퍼런스 퓨전     | ...     | 합성 (compositing) / ControlNet |
...

점수를 매길 때 주의 깊게 살펴봐야 할 점은 다음과 같습니다. 바로 이미지 모델들이 보통 한계를 드러내는 지점이기 때문입니다. 이미지 내 텍스트(In-image text)의 경우, 훑어보지 말고 비라틴 문자(non-Latin script)를 글자 하나하나 확인하십시오. 읽을 수 있어 보이는 일본어나 힌디어라도 미묘하게 틀릴 수 있으며, "텍스트처럼 보이는 것"이 "정확한 텍스트"인 것은 아닙니다. 레퍼런스 퓨전 (Reference fusion)의 경우, 느슨한 프롬프트보다 정교하고 구체적인 프롬프트가 정체성(identity)을 더 잘 유지하는 경향이 있습니다. 따라서 결과물이 제품의 특징에서 벗어난다면, 모델이 실패했다고 결론 내리기 전에 지시어(instruction)를 더 강화해 보십시오. 마지막 열을 정직하게 채우십시오. 당신의 빌드 결정(build decision)을 내리는 것은 예쁜 결과물이 아니라 바로 그 데이터입니다.

삭제되지 않는 것들 (도구를 제거하기 전에 이 내용을 읽으세요)

강력한 모델이라 할지라도 실제 프로덕션 노드(production nodes)는 그대로 남겨둡니다.

다음은 과장된 기사들이 생략하는 부분입니다. GPT Image 2는 당신의 전체 스택(stack)을 대체하지 않으며, 대체될 것이라고 가정하는 것은 당신을 곤경에 빠뜨릴 것입니다.

• 투명 PNG 미지원. 로고, 스티커 또는 UI 에셋을 생성하는 경우, 여전히 배경 제거(background-removal) 노드가 필요합니다. 알파 채널(Alpha channel)은 제공되지 않습니다.
• 출력물에 포함된 보이지 않는 SynthID 워터마크. SynthID를 사용하여 설계 단계부터 출처(Provenance)를 추적할 수 있습니다. 이는 대부분의 용도에는 괜찮지만, 일부 상업적 또는 법적 맥락에서는 실제 고려 사항이 됩니다. 워터마크가 존재한다는 점을 인지하십시오.
• 상업적 이용은 유료 플랜 전용. 무료 티어는 평가용입니다. 결과물을 제품이나 광고에 배포하려면 유료 플랜을 사용해야 하며, 라이선스를 읽어보아야 합니다.
• 크레딧 기반 과금. 각 생성 시마다 크레딧이 소모됩니다. 대량 생성 시에는 순수 경제성 측면에서 더 저렴하거나 자체 호스팅(self-hosted) 가능한 모델이 유리할 수 있습니다.
• 호스팅 방식, 로컬 방식 아님. 오프라인, 프라이빗 또는 고도로 미세 조정(fine-tuned)된 생성이 필요한 경우, 여전히 Stable Diffusion이 해당 노드를 점유하고 있습니다. 호스팅된 API 모델은 자체 호스팅할 수 없습니다.

그렇다면, 내 스택에 포함될 수 있을까?

대부분의 작업이 "일관된 참조(consistent references)와 이미지 내 실제 텍스트"로 구성되는 경우, 이 모델은 두 개의 노드를 하나의 호출(call)로 통합하는 것을 목표로 하며, 만약 귀하의 자체 평가(eval)를 통해 이것이 확인된다면 그 가치는 매우 높습니다. 투명한 내보내기(transparent exports), 오프라인 실행(offline runs), 또는 워터마크 없는 출력이 필요한 모든 경우에는 대체제가 아니라, 경로를 지정할 수 있는 또 하나의 옵션일 뿐입니다.

이것이 새로운 모델에 대해 빌더(builder)가 얻을 수 있는 솔직한 시사점입니다. 중요한 것은 이 모델이 최고인지 여부가 아닙니다. 당신 앞에 놓인 특정 작업에 대해 이 모델이 어떤 구체적인 노드를 삭제하느냐 하는 것입니다. 세 가지 작업 테스트(three-job test)를 실행하고 마지막 열을 채운 뒤, 파이프라인이 스스로 결정하게 하십시오.

귀하의 이미지 파이프라인에서 여전히 가장 많은 시간을 잡아먹는 노드는 무엇입니까? 그것이 텍스트인지, 일관성(consistency)인지, 아니면 모델 제작자들이 아직 손대지 못한 무언가인지 궁금합니다.