GPT Image 2로 4K 이미지를 생성하는 API 설정과 검증 절차

GPT Image 2로 4K 이미지를 생성하려면 API 요청의 size를 먼저 정해야 합니다. 가로 이미지는 3840x2160, 세로 이미지는 2160x3840을 첫 검증값으로 두면 저장 후 실제 픽셀을 확인하기 쉽습니다.

모델 응답이 성공해도 바로 4K 자산이 되는 것은 아닙니다. 반환된 base64 데이터를 파일로 저장하고, width와 height를 읽어서 요청한 값과 같은지 확인해야 합니다. CMS, CDN, 이미지 최적화, frontend srcset이 파일을 줄일 수 있기 때문입니다.

직접 한 장을 만들거나 편집하려면 Image API가 가장 단순합니다. 대화형 앱, agent, 여러 tool이 연결된 workflow 안에서 이미지를 만들려면 Responses API가 맞습니다. 두 경로 모두 2560x1440을 넘는 출력은 실험적 범위로 보고 배포 전에 검증합니다.

prompt에 4K라고 쓰는 것만으로는 부족합니다. size로 픽셀을 요청하고 저장된 파일의 실제 width와 height를 확인해야 운영 자산으로 볼 수 있습니다.

size가 실제 4K 픽셀을 정한다

prompt는 장면과 스타일을 지시한다. 제품, 배경, 텍스트, 조명, 구도는 prompt로 제어하지만 최종 이미지의 픽셀은 size가 담당한다. prompt에 “4K”를 넣으면 선명한 느낌을 유도할 수는 있어도 3840px 파일을 보장하지 않는다.

첫 테스트는 단순해야 한다. prompt 하나, size 하나, quality 하나를 고정하고 저장까지 확인한다. 이 단계가 통과되어야 reference image, edit mode, 긴 텍스트, 여러 비율, batch 작업을 추가해도 원인을 추적할 수 있다.

운영 문서에는 size를 명시한다. 콘텐츠 담당자는 목표 캔버스를 이해하고, 엔지니어는 호출 전에 치수를 검증하고, 디자이너는 후처리나 crop이 중요한 영역을 망가뜨렸는지 확인할 수 있다.

hljs js复制
const result = await client.images.generate({
  model: "gpt-image-2",
  prompt: "A clean product hero image with precise Korean headline text.",
  size: "3840x2160",
  quality: "high"
});

유효한 4K와 custom size 조건

custom size는 네 가지 조건을 통과해야 한다. 긴 변은 3840px을 넘지 않아야 하고, width와 height는 16의 배수여야 하며, 긴 변과 짧은 변의 비율은 3:1을 넘지 않아야 한다. 전체 픽셀 수도 허용 범위 안에 있어야 한다.

3840x2160과 2160x3840은 첫 검증에 적합하다. 반대로 4096x2160은 시장에서 4K라고 부르기 쉽지만 긴 변이 3840을 넘으므로 GPT Image 2의 직접 size로 쓰지 않는 편이 안전하다.

API 호출 전에 로컬 validator를 둔다. 실패 메시지는 edge limit, multiple of 16, aspect ratio, pixel count 중 어떤 조건이 문제인지 말해야 한다. 그래야 prompt 수정과 size 수정이 섞이지 않는다.

hljs js复制
function isValidImageSize(width, height) {
  const pixels = width * height;
  const longEdge = Math.max(width, height);
  const shortEdge = Math.min(width, height);
  return longEdge <= 3840 && width % 16 === 0 && height % 16 === 0 &&
    longEdge / shortEdge <= 3 && pixels >= 655360 && pixels <= 8294400;
}

Image API로 직접 4K 생성하기

한 번의 요청으로 한 장의 이미지를 만들 목적이라면 Image API가 가장 짧다. model, prompt, size, quality, format을 지정하고 응답의 base64 이미지를 파일로 저장한다. 구조가 짧을수록 로그와 검증도 명확하다.

운영 로그에는 모델, size, quality, output format, 저장 경로, 실제 픽셀, 실패 사유를 남긴다. 그래야 “화질이 나쁘다”와 “4K가 아니다”를 분리할 수 있다. 같은 4K라도 quality와 prompt 안정성에 따라 결과는 크게 달라진다.

첫 구현에서 너무 많은 옵션을 켜지 않는다. 직접 생성, 저장, 측정이 끝난 뒤 reference image, edit, batch, localization image를 추가한다. 이미지 API 문제는 작은 재현 케이스가 있을수록 빨리 해결된다.

hljs js复制
import fs from "node:fs";

const image = result.data[0];
fs.writeFileSync("gpt-image-2-4k.png", Buffer.from(image.b64_json, "base64"));

Responses API로 다단계 workflow에 넣기

이미지가 앱 흐름의 일부라면 Responses API가 자연스럽다. 사용자가 제품을 설명하고, 모델이 메시지를 정리하고, 이미지 tool이 4K hero를 만들고, 마지막으로 운영 메모를 반환하는 식이다.

하지만 이 경로에서도 image tool 호출에는 명시적인 size가 들어가야 한다. 상위 텍스트 단계에서 “4K로 만들어라”라고 말하는 것만으로는 부족하다. tool result를 파일로 저장하고 실제 크기를 측정하는 과정은 동일하다.

다단계 workflow에서는 실패 지점을 나눈다. prompt planning, image tool, file save, CDN upload, frontend rendering을 구분해서 기록한다. 그렇지 않으면 모델 문제인지 pipeline 문제인지 알 수 없다.

hljs js复制
const response = await client.responses.create({
  model: "gpt-5.4",
  input: "Create a launch poster and return production notes.",
  tools: [{ type: "image_generation", model: "gpt-image-2", size: "3840x2160" }]
});

quality, format, 투명 배경 경계

quality는 작업 단계에 맞게 고른다. low나 medium은 빠른 구도 탐색에 좋고, high는 최종 후보에 적합하다. 하지만 high는 비용과 지연을 키울 수 있다. 크기 검증과 품질 비교는 따로 진행하는 편이 좋다.

PNG는 후처리와 텍스트 확인에 유리하다. JPEG나 WebP는 웹 배포에서 파일 크기를 줄일 때 유용하다. 압축 후에는 텍스트, 로고, 가는 선, UI mockup이 깨지지 않는지 다시 본다.

GPT Image 2는 투명 배경을 직접 출력하는 모델 경로로 다루지 않는다. 투명 PNG가 필요하면 생성 후 segmentation, mask, 배경 제거, 디자인 툴을 사용한다. 4K 생성과 투명 처리 과정을 분리해야 한다.

비용도 단순히 4K 한 장 가격으로 끝나지 않는다. image input, image output, text input, quality, edit, retry, batch 여부가 모두 영향을 준다. 운영 전에는 최신 공식 정보와 작은 smoke test의 실제 청구를 함께 본다.

native 4K와 2K master 후 upscale

native 4K는 처음부터 픽셀이 납품 조건인 작업에 맞다. 큰 배너, 프린트 preview, marketplace hero, 디자인 시스템에 바로 넘길 asset은 직접 4K가 단순하다.

텍스트나 구도가 아직 확정되지 않았다면 2K master가 더 현실적이다. 여러 후보를 낮은 비용으로 보고, 가장 안정적인 결과를 고른 뒤 controlled upscale을 적용한다. 특히 한국어 텍스트가 이미지 안에 들어가면 이 방식이 유리할 수 있다.

선택 기준은 줄이고 싶은 위험이다. 픽셀 부족이 가장 큰 위험이면 native 4K, 구도 반복이 가장 큰 위험이면 2K exploration, 예산이 가장 큰 위험이면 exploration과 final render의 한도를 나눈다.

저장 후 파일을 반드시 검증하기

API 응답 성공은 시작일 뿐이다. 파일이 존재하는지, 읽을 수 있는지, width와 height가 요청값과 같은지, format이 의도한 것인지 확인한다. CDN이나 CMS가 별도 preview를 만들면 공개 URL도 따로 측정한다.

검증 결과는 metadata로 저장한다. generation size, actual width, actual height, format, file size, quality, 저장 경로를 기록하면 이후 localization image, OG image, social image를 만들 때 추적이 쉽다.

크기가 틀리면 prompt를 고치기 전에 request와 pipeline을 본다. size 문자열, custom size 조건, model access, organization verification, 저장 경로, image optimizer, frontend srcset을 순서대로 확인한다.

실패와 잘못된 크기 진단

invalid size는 치수 조건 위반일 가능성이 높다. 긴 변, 16의 배수, aspect ratio, pixel count를 호출 전 로그에 남긴다. 에디터에게는 어떤 조건이 실패했는지 구체적으로 보여준다.

access error는 코드가 아니라 계정 또는 조직 상태 문제일 수 있다. GPT Image 2 사용에는 model access나 organization verification이 필요할 수 있으므로, 운영과 같은 organization과 API key로 작은 테스트를 먼저 한다.

생성은 성공했지만 최종 표시가 작다면 downstream 변환을 의심한다. original file, uploaded original, public URL, browser rendering을 따로 측정해야 CMS나 CDN이 만든 변형을 찾을 수 있다.

FAQ

prompt에 4K라고 쓰면 충분한가요?

아니요. prompt는 의도를 설명할 뿐이고 실제 픽셀은 size가 제어합니다. 저장 후 width와 height를 확인해야 합니다.

처음 쓸 size는 무엇인가요?

가로는 3840x2160, 세로는 2160x3840이 가장 명확합니다. custom size는 모든 치수 조건을 통과해야 합니다.

4096x2160을 직접 요청할 수 있나요?

권장하지 않습니다. 긴 변이 3840을 넘기 때문에 유효한 3840-edge 크기로 생성하거나 이후 upscale을 검토합니다.

Image API와 Responses API 중 무엇을 써야 하나요?

단일 이미지 생성은 Image API가 단순합니다. chat, agent, tool workflow 안의 이미지는 Responses API가 맞습니다.

투명 배경을 바로 만들 수 있나요?

GPT Image 2 경로에서 직접 투명 배경을 기대하지 마세요. 생성 후 배경 제거나 mask 처리를 별도 단계로 둡니다.

4K 요청이 실패하면 어떻게 하나요?

size, access, 저장 파일, CDN 변환을 확인합니다. 계속 불안정하면 2K master를 만들고 controlled upscale을 적용합니다.