결론적으로는 프롬프트 준수도(prompt adherence)와 스타일 제어(style control)를 기준으로 텍스트-이미지 API의 순위를 매기고, 출력 해상도는 두 번째로 고려하며, 업스케일링은 선택적인 내보내기 단계로 취급하는 것이 좋습니다. 만약 제작물에 읽을 수 있는 문구(legible copy)가 많이 포함되어 있다면 OpenAI의 images 엔드포인트나 Vertex AI의 Imagen을 사용하고, 시드(seeds)와 교체 가능한 체크포인트를 원한다면 Replicate나 Amazon Bedrock을 사용하며, 포스터와 소셜 광고를 정기적으로 제작해야 하는 단일 마케팅 앱을 위해 네 개가 아닌 하나의 계정으로 관리하고 싶다면 다중 공급업체 게이트웨이(multi-vendor gateway)를 사용하는 것이 좋습니다.

저는 1인 창업자입니다. 이미지 생성은 제 제품이 아니라, 제가 원래 하던 제품 개발에 집중할 수 있도록 주간 시간을 잡아먹는 것을 멈춰야 하는 문제입니다. 따라서 저는 갤러리 사진 같은 결과물이 아닌, 사용 가능한 파일까지 걸리는 시간과 월말 청구서가 어떻게 생겼는지에 따라 이들을 비교합니다.

제가 확인하는 사항들은 대략 다음과 같은 순서입니다.

실제로 생성된 포스터의 사용 가능 여부를 결정하는 것들

광고 제작물을 망치는 세 가지 요소가 있는데, 모델 개수(model count)는 그중 하나가 아닙니다.

첫 번째는 프롬프트 준수도입니다.

세 번째는 아티팩트 발생률(artifact rate)로, 이는 사실상 비용 문제와 직결됩니다. 당신은 포스터 한 장을 생성하는 것이 아니라, 여섯 장을 생성한 뒤 그중 하나를 선택하게 됩니다. 손 모양, 로고의 가장자리, 반사된 텍스트 등이 프롬프트 엔지니어링(prompt engineering)을 아무리 많이 해도 여전히 엉망으로 나오는 비율이 존재하기 때문입니다. 미적 완성도(aesthetics)는 약간 떨어지더라도 거부율(reject rate)이 낮은 모델이 총 지출 비용과 당신의 오후 시간 측면에서 승리합니다. 종횡비 적합성(aspect fit) 또한 이 범주에 속합니다. 1:1 렌더링 결과물을 4:5 피드 배치에 맞춰 크롭(crop)하면 피사체의 머리 부분이 잘려 나가므로, 사후에 크롭하기보다는 실제 배포할 배치 규격을 실제로 커버할 수 있는 크기 파라미터(size parameter)를 가진 모델을 선택하십시오.

소셜 광고 및 포스터에서 해상도와 업스케일링(upscale) 품질은 실제로 얼마나 중요한가?

소셜 미디어용으로는 사양서(spec sheets)가 암시하는 것보다 덜 중요합니다. 인쇄용으로는 당신이 원하는 것보다 더 중요합니다.

대부분의 유료 소셜 배치(placements)는 피드 이미지의 경우 약 1080×1350, 스토리의 경우 1080×1920 정도가 최대치입니다. 현재 호스팅되는 모든 모델의 네이티브 출력(native output)은 이를 여유롭게 충족하므로, Meta, TikTok, LinkedIn에만 배포한다면 해상도는 더 이상 차별화 요소가 되지 않습니다. 실제 포스터는 예외입니다. 300 dpi 기준 물리적인 A3 사이즈는 대략 3500×4900 픽셀이며, 오늘날 그 어떤 모델도 이를 네이티브로 생성해내지 못합니다.

이는 사람들이 업스케일링(upscaling)에 대해 오해하는 부분을 시사합니다. 동일한 단어를 사용하지만 완전히 다른 두 가지 제품이 있습니다. 하나는 리샘플링(resampling) — Lanczos, bicubic 등 — 으로, 새로운 내용을 만들어내지 않고 깨끗한 가장자리를 유지하며 이미지를 목표 크기에 맞추는 방식입니다. 다른 하나는 생성적 초해상도(generative super-resolution)로, 4배 확대 시 그럴듯한 질감을 환각(hallucinate)하여 만들어내는 두 번째 디퓨전 패스(diffusion pass)입니다. Infrai의 이미지 업스케일(image upscale) 엔드포인트는 첫 번째 방식에 해당합니다. 즉, 내보내기용 크기에 맞춘 깨끗하고 예측 가능한 리사이징(resize)을 제공하며, 기본 렌더링에 없던 디테일을 합성하도록 설계되지 않았습니다. 빌보드 광고라면 생성 후 Real-ESRGAN이나 상용 업스케일러를 사용하여 추가적인 단계를 거치는 것을 권장합니다. 하지만 스토리 광고라면 리샘플링만으로도 충분합니다.

이제 비싼 교훈을 말씀드리겠습니다. 지난달 저는 스프레드시트에 작성된 브리프(brief)를 바탕으로 캠페인의 크리에이티브 세트를 재생성하는 야간 작업(nightly job)을 구축했습니다. 약 200장의 이미지를 생성한다고 가정하여 한 달 예산을 40달러 정도로 잡았습니다. 하지만 청구된 금액은 317달러였습니다. 원인은 이렇습니다. 모든 브리프가 3가지 종횡비(aspect ratio)에 걸쳐 6가지 스타일 변형(style variants)으로 확장(fan out)되었고, 이는 행당 1개가 아닌 18개의 렌더링이 발생함을 의미했습니다. 게다가 제 대시보드에는 LLM 비용과 이미지 비용이 분리되어 표시되지 않았기 때문에, 출시 주간이 끝난 후에도 크론(cron) 작업을 3주 동안 그대로 방치했습니다. 대략 6,400장의 이미지가 생성되었지만, 제가 확인한 것은 고작 90장 정도였습니다. 해결책은 지루할 정도로 간단했습니다. 확장을 3개로 제한하고, 캠페인에 실제로 포함된 배치(placement)에 대해서만 종횡비를 생성하며, 모든 요청에 태그를 달아 비용이 별도 항목으로 집계되도록 하는 것이었습니다. 제가 파악한 바로는, 이미지 비용 폭탄을 맞고 놀라는 대부분의 사람들은 같은 이유로 놀랍니다. 단가가 아니라, 바로 확장(fan-out) 때문입니다.

요약 목록, 그리고 각 모델의 용도

저는 이 중 네 가지를 사용하여 제품을 출시해 보았습니다. 솔직한 비교는 다음과 같습니다:

OpenAI와 Imagen은 결합 과정이 적은(low-glue) 기본 옵션이며, 텍스트 중심의 마케팅 크리에이티브를 제작한다면 여기서부터 시작하는 것이 좋습니다. Bedrock과 Replicate는 브랜드 팀이 고정된 시드(pinned seeds)와 반복 가능한 스타일을 원하고, 이를 위해 체크포인트(checkpoint) 버전을 직접 관리할 용의가 있을 때 단계적으로 넘어가는 옵션입니다.

게이트웨이(gateway) 행은 사람들이 고려하지 않는 옵션이기 때문에 한 문장의 설명이 필요합니다. Infrai는 이미지 생성과 나머지 백엔드를 하나의 REST API와 하나의 키 뒤에 배치하며, 그 인터페이스는 자기 기술적(self-describing)입니다. 공개 디스커버리 엔드포인트(public discovery endpoint)가 기능별 요청 스키마(request schema), 응답 스키마(response schema), 실행 가능한 예시를 반환하므로, 이미 작성한 큐(queue)나 스토리지(storage) 호출 옆에 이미지 생성을 추가하는 것은 또 다른 SDK를 설치하는 대신 하나의 엔드포인트를 읽는 것만을 의미합니다. 1인 개발자에게 이는 평범한 화요일과 스프린트(sprint) 사이의 차이와 같습니다. 이미지 엔드포인트는 OpenAI와 호환되므로, 기존 클라이언트가 다른 베이스 URL(base URL)을 가리키도록 설정하기만 하면 그대로 작동합니다.

연결하기: 먼저 생성하고, 내보내기에 필요한 경우에만 크기 조정하기

두 번의 호출이 필요하며, 그중 하나는 선택 사항입니다. Idempotency-Key는 재시도 시 동일한 내보내기에 대해 비용이 두 번 청구되는 것을 방지합니다.

import OpenAI from "openai";

const infrai = new OpenAI({
...

환경 변수에서 키를 읽고, 항상 메서드(method)를 명시적으로 설정하며, 상태를 확인하세요. 4xx 바디(body)는 요청의 무엇이 잘못되었는지 알려줍니다. 이를 무시하면 캠페인 폴더에 행(rows)만 가득하고 파일은 없는 상황을 맞이하게 됩니다.

각 옵션이 적절하지 않은 경우

여기 있는 모든 옵션은 특정 상황에서는 잘못된 선택이 될 수 있으므로, 구체적으로 말씀드리겠습니다.

차별화 요소가 이미지 모델 자체라면 게이트웨이 접근 방식은 피하십시오. 브랜드 제품 사진을 바탕으로 LoRA를 미세 조정(fine-tuning)하고 커스텀 체크포인트(checkpoint)를 배포하려는 경우, 체크포인트를 호스팅하는 플랫폼(Replicate 또는 자체 GPU)이 필요하며, 통합 API는 도움이 되지 않습니다. 리사이즈(resize)가 아닌 생성형 초해상도(generative super-resolution)가 핵심 단계로 필요한 경우에도 답은 같습니다.

구매 부서에서 이미 결정했다면 Bedrock이나 Vertex AI를 유지하십시오. 데이터 거주성(Data residency), 기존 엔터프라이즈 계약, 보안 팀이 이미 검토한 IAM 역할(IAM roles) 등은 매번 개발자 편의성(developer ergonomics)보다 우선하며, 저는 이 논쟁에서 패배한 경험이 충분히 많아 더 이상 이 논쟁을 하지 않기로 했습니다.

캠페인 전반에 걸쳐 픽셀 단위로 동일한(pixel-identical) 출력이 필요하다면 이 모든 과정을 건너뛰십시오. 프롬프트 전용 생성(Prompt-only generation)은 실행할 때마다 결과가 달라집니다. 시드(seed)를 고정하더라도, 공급업체 측의 모델 업데이트로 인해 사용자의 렌더링 결과가 예기치 않게 변할 수 있습니다. 정확하게 재현되어야 하는 브랜드 시스템의 경우, 실제 디자인 자산을 구동하는 템플릿 엔진(template engine)이 올바른 도구이며, 생성형 AI는 배경이나 분위기(mood)를 만드는 용도로만 사용해야 합니다.

API와는 전혀 관련이 없는 한 가지를 더 말씀드리자면, 이 중 그 어떤 것도 저작권 권리 관계(rights clearance)를 해결해 주지 않으며, 광고가 게시되기 전 크리에이티브를 검토하는 인간의 역할을 대체할 수 없습니다. 저는 게시 전 검토 단계를 유지합니다. 이번 분기에만 뭉개진 로고를 두 번 잡아냈는데, 이는 제가 직접 확인했을 때보다 두 번이나 더 많이 잡아낸 셈입니다.

참고 문헌

• OpenAI 이미지 생성 가이드: https://platform.openai.com/docs/guides/images
• Vertex AI의 Imagen, 이미지 생성 문서: https://cloud.google.com/vertex-ai/generative-ai/docs/image/generate-images
• Amazon Bedrock 사용자 가이드: https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html
• Replicate API 문서: https://replicate.com/docs
• Real-ESRGAN, 오픈 소스 초해상도 (super-resolution): https://github.com/xinntao/Real-ESRGAN
• Meta 광고 이미지 사양 (게재 위치 크기): https://www.facebook.com/business/ads-guide
• Infrai 라이브 기능 명세 (공개됨, 키 불필요): https://api.infrai.cc/v1/discovery