GPT Image 2.6 GIF API 사용법: 움짤 한 개 $0.03~0.06, 프레임·용량 실측

GPT Image 2.6으로 GIF 움짤을 API에서 바로 받으려면 POST /v1/images/generations 요청에 모델 gpt-image-2.6-flare 또는 gpt-image-2.6-sunburst를 넣고 output_format: "gif"를 지정하면 됩니다. 프레임 수는 frame_count, 프레임 한 장이 화면에 머무는 시간은 frame_duration_ms로 정하고, size는 애니메이션 전체가 아니라 프레임 한 장의 크기입니다. 응답의 b64_json을 base64로 디코딩해 .gif로 저장하면 끝입니다. OpenAI가 2026년 11월 4일 Images 2.6 발표와 함께 공개한 기능이며, OpenAI 이미지 생성 가이드의 GIF 출력 항목에 따르면 편집 엔드포인트(/v1/images/edits)는 GIF를 돌려주지 않습니다.

값을 고를 때 걸리는 곳은 두 가지입니다. 첫째, 프레임 상한이 문서마다 다릅니다. 2026년 11월 5일 기준 가이드는 2~64프레임, OpenAI API 레퍼런스의 images.generate 항목은 2~16프레임이라고 적고 있으므로, OpenAI에 직접 붙어 반드시 돌아가야 하는 코드는 16프레임 이하로 두는 편이 안전합니다. 둘째, GIF 한 개 값은 경로에 따라 갈립니다. OpenAI 직접 호출은 토큰 과금이라 512×512·medium·9프레임이 출력 2,073토큰, 약 $0.062였고, LaoZhang API의 gpt-image-2.6-web 경로는 프레임 수와 크기에 관계없이 회당 $0.03이지만 512×512 같은 작은 프레임은 받지 않고 한 개에 40~50초쯤 걸립니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

2026년 11월 5일 이 web 경로로 1024×1024 GIF 네 개를 만들어 보니 프레임 수와 프레임당 시간은 요청한 값 그대로였고 네 개 모두 무한 반복으로 저장돼 있었습니다. 다만 OpenAI가 권하는 "처음 자세로 돌아오라"는 루프 프롬프트를 그대로 쓴 9프레임 GIF는 마지막 프레임에서 첫 프레임으로 넘어갈 때 랜턴 위치가 툭 튀었습니다. 프롬프트만 믿지 말고 배포 전에 루프 이음새를 직접 재 봐야 하는 이유입니다.

GPT Image 2.6 GIF 요청 보내고 .gif로 저장하기: curl·Python 4단계

GIF 요청은 일반 이미지 생성 요청에 필드 세 개를 더한 것입니다. output_format을 "gif"로 바꾸고, frame_count와 frame_duration_ms를 넣고, size를 프레임 한 장 기준으로 적습니다. 응답은 스트리밍 없이 완성된 파일 하나가 한꺼번에 오므로, 클라이언트 타임아웃만 넉넉히 잡으면 저장 코드는 정지 이미지와 같습니다.

1. 호출할 주소와 키를 정합니다. OpenAI 직접이면 https://api.openai.com/v1과 OpenAI API 키를, LaoZhang API를 쓰면 https://api.laozhang.ai/v1과 경로에 맞는 그룹의 키를 씁니다(아래 경로 비교 참고).
2. 요청 본문에 model, prompt, size, quality, output_format: "gif", frame_count, frame_duration_ms를 넣습니다. 프롬프트에는 피사체, 움직임, 루프를 어떻게 닫을지(처음 자세로 돌아오기, 카메라 고정 등)를 적습니다.
3. 타임아웃을 300초 이상으로 두고 보낸 뒤, 응답 data[0].b64_json을 base64로 디코딩해 .gif 확장자로 저장합니다.
4. 저장한 파일의 프레임 수, 프레임당 시간, 반복 설정, 루프 이음새를 확인합니다. 확인용 스크립트는 아래 "루프 이음새" 절에 있습니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

curl로 OpenAI에 직접 보내는 예시입니다. 512×512, medium, 9프레임 × 200ms로 1.8초짜리 루프를 요청합니다.

curl --fail-with-body https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --max-time 300 \
  -d '{
    "model": "gpt-image-2.6-flare",
    "prompt": "An orange cat stretches on a windowsill, then yawns while light rain falls outside, flat illustration style, looping animation",
    "size": "512x512",
    "quality": "medium",
    "output_format": "gif",
    "frame_count": 9,
    "frame_duration_ms": 200
  }' -o gif.json

jq -r '.data[0].b64_json' gif.json | base64 --decode > cat.gif

파이썬 SDK에서는 GIF 전용 필드를 extra_body로 넘기면 SDK 버전과 관계없이 그대로 전송됩니다. 응답의 usage에 출력 토큰 수가 들어 있어 비용 계산에 바로 쓸 수 있습니다.

import base64
from openai import OpenAI

client = OpenAI(timeout=300)  # OPENAI_API_KEY 환경 변수 사용
# LaoZhang API 공식 포워딩이면: OpenAI(base_url="https://api.laozhang.ai/v1", api_key="...", timeout=300)

result = client.images.generate(
    model="gpt-image-2.6-flare",
    prompt="An orange cat stretches on a windowsill, then yawns while light rain falls outside, "
           "flat illustration style, looping animation",
    size="512x512",
    quality="medium",
    output_format="gif",
    extra_body={"frame_count": 9, "frame_duration_ms": 200},
)

with open("cat.gif", "wb") as f:
    f.write(base64.b64decode(result.data[0].b64_json))
print(result.usage)

frame_count·frame_duration_ms·size 범위와 GIF에서 안 되는 옵션

2026년 11월 5일 기준 OpenAI 가이드가 정한 GIF 범위는 frame_count 2~64(기본 9), frame_duration_ms 20~2000ms(10ms 단위 반올림, 기본 200), size는 auto 또는 16의 배수인 가로x세로입니다. 프레임 수, 프레임 크기, 애니메이션 개수(n)를 합친 양이 모델의 크기 한도와 요청 전체의 픽셀 예산 안에 들어가야 하고, 넘으면 셋 중 하나를 줄이라는 것이 가이드의 안내입니다. 같은 항목을 API 레퍼런스와 LaoZhang API web 경로 문서는 조금씩 다르게 적고 있어 함께 놓고 보면 다음과 같습니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

size에는 아래쪽 한계도 있습니다. LaoZhang API 문서팀이 2026년 11월 5일 OpenAI에 직접 보낸 테스트에서 256×256에 2프레임만 요청해도 No supported sheet fits로 시작하는 에러가 났습니다. 프레임을 한 장의 시트에 모아 그리는 구조라 시트 전체 픽셀에 하한이 있기 때문이고, 같은 테스트에서 512×512에 4~9프레임은 그대로 통과했습니다. 반대로 프레임 수나 크기를 키우면 위쪽 픽셀 예산에 걸리는데, 그 수치는 공개돼 있지 않습니다.

frame_count와 frame_duration_ms는 GIF 요청에서만 받는 필드이고, 재생 길이는 두 값을 곱한 값입니다. 챗GPT 앱의 GIF 화면에 있는 0.25×~2× 속도 메뉴는 앱 기능이라 API에는 대응하는 파라미터가 없고, API에서 속도를 바꾸려면 frame_duration_ms를 바꿔 다시 생성해야 합니다. 코드 없이 앱에서 움짤을 만드는 방법은 챗GPT GIF 만들기: 코드 없이 움짤 바로 생성, 프레임·속도 설정법에 정리돼 있습니다.

64프레임까지 되나, 16까지인가: OpenAI 문서끼리 다른 프레임 상한

OpenAI에 직접 보내는 코드라면 지금은 16프레임 이하로 두는 것이 맞습니다. 2026년 11월 5일 기준 가이드는 frame_count를 2~64로 적었지만 API 레퍼런스는 "2부터 16까지의 정수"와 maximum: 16을 명시하고 있고, 둘 중 어느 쪽이 실제 서버 동작인지는 아직 가려지지 않았습니다. 2026년 11월 5일의 실측과 LaoZhang API 문서팀의 측정 모두 OpenAI API에 직접 17프레임 이상을 보내 보지 않았고, 문서팀의 OpenAI 직접 테스트는 9프레임까지였습니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

LaoZhang API의 gpt-image-2.6-web 경로는 문서에 2~64프레임을 적고 있고, 2026년 11월 5일 65프레임을 보내자 400으로 거절됐습니다. 같은 날 이 경로에서 실제로 받아 본 최대치는 16프레임이며, 64프레임은 LaoZhang 문서 기준 약 2분, 약 18MB에 프레임이 눈에 띄게 물러진다고 돼 있습니다. 그래서 16프레임을 넘겨야 하는 경우에도 먼저 frame_duration_ms를 늘려 재생 길이를 확보할 수 있는지 보고, 정말 프레임이 더 필요하면 400을 받았을 때 16으로 낮춰 다시 보내는 처리를 코드에 넣어 두는 편이 안전합니다.

레퍼런스에는 "선택한 모델의 GIF preview 접근 권한이 필요하다(Requires access to the GIF preview for the selected model)"는 문장도 있습니다. 모든 계정에 바로 열린 기능이 아닐 수 있다는 뜻이고, 어떤 조직이 대상인지는 OpenAI가 밝히지 않았습니다. 정지 이미지는 되는데 GIF만 거절된다면 이 접근 권한부터 의심해 볼 만합니다.

2026년 11월 5일 실측: 4·9·16프레임 GIF의 용량과 생성 시간

1024×1024 GIF는 프레임 하나에 약 0.5MB씩 늘었습니다. 2026년 11월 5일 gpt-image-2.6-web(default 그룹 키)으로 만든 네 개는 4프레임 2.02MB, 9프레임 4.53~4.85MB, 16프레임 8.20MB였고, 생성 시간은 프레임 수와 무관하게 43.5~52.1초였습니다. 비교를 위해 OpenAI가 가이드에 올린 Sunburst 샘플 GIF 파일과 LaoZhang API 문서팀의 OpenAI 직접 측정값을 함께 놓았습니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

용량은 프레임 수에 거의 정비례합니다. 2.02MB ÷ 4, 4.53MB ÷ 9, 8.20MB ÷ 16이 모두 0.50~0.51MB이므로, 1024×1024에서 프레임 수를 두 배로 늘리면 파일도 두 배가 된다고 보고 계산하면 됩니다. 메신저 이모티콘이나 웹 페이지 반응 움짤처럼 가벼워야 하는 용도라면 512×512 이하가 가능한 토큰 과금 경로가 유리하고, 같은 9프레임에서 OpenAI 샘플은 1.28MB였습니다.

생성 시간은 부하에 따라 크게 흔들립니다. 위 web 경로 측정에서는 16프레임이 9프레임과 같은 49.3초였지만, LaoZhang 문서에는 같은 크기 기준 4~9프레임 약 35~42초, 16프레임 약 100초, 2048×2048 9프레임 약 54초(약 11MB)로 적혀 있습니다. 반면 OpenAI 직접 Flare 512×512는 11~12초였으니, 응답 속도가 중요한 서비스라면 경로부터 다시 고르는 것이 낫습니다. 프레임을 늘리면 각 프레임에 돌아가는 디테일이 줄어든다는 점도 같이 고려합니다. 스티커·반응 움짤은 4~9프레임, 로딩 애니메이션처럼 동작이 매끄러워야 하는 것은 12~16프레임에 frame_duration_ms를 100~120ms로 짧게 잡는 식으로 출발하면 됩니다.

OpenAI 직접·공식 포워딩·web·VIP: GPT Image 2.6 GIF 경로 고르기

경로는 필요한 프레임 크기와 예산으로 정합니다. 512×512 같은 작은 움짤이나 이모티콘이 필요하면 토큰 과금 경로(OpenAI 직접 또는 LaoZhang API 공식 포워딩)밖에 없고, 1024×1024 이상을 여러 개 뽑으면서 한 개 값을 고정하고 싶으면 gpt-image-2.6-web이 맞습니다. -vip 모델은 GIF를 아예 받지 않습니다. 아래 LaoZhang API 항목은 LaoZhang API의 GPT Image 2.5·2.6 문서 2026년 11월 5일 기준 내용입니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

공식 포워딩은 기존 OpenAI 코드에서 base_url과 키만 바꾸면 되고, 그룹은 요청이 아니라 키에 묶여 있습니다. 이 경로는 GIF 외에 같은 2.6 기능도 OpenAI와 똑같이 받으므로, API로 SVG 벡터 이미지 받기나 마크업으로 편집할 부분 지정하기도 같은 키로 이어서 할 수 있습니다.

web 경로를 쓸 때는 지켜야 할 것이 몇 가지 더 있습니다. size를 빼면 439×390처럼 작고 어정쩡한 크기로 돌아오므로 1024x1024처럼 항상 적고, n은 1만 받습니다. stream: true를 넣어도 완성된 GIF가 한 번에 오므로 클라이언트 타임아웃을 300초 이상으로 잡습니다. 혼잡한 시간대에는 큰 GIF나 프레임이 많은 GIF가 약 2분 뒤 429로 끝날 수 있는데, 이 경우 과금되지 않으니 잠시 뒤 다시 보내거나 프레임 수·크기를 줄이면 됩니다.

GIF 한 개 비용: 토큰 과금 약 $0.062, web 경로 회당 $0.03

OpenAI 직접 호출과 공식 포워딩은 출력 토큰으로 값을 매기므로 GIF 한 개 값은 크기·품질·프레임 수에 따라 달라지고, 512×512·medium·9프레임 한 번의 실측은 약 $0.062였습니다. web 경로는 무엇을 요청하든 회당 $0.03입니다. 계산 근거는 OpenAI API 요금 페이지의 GPT Image 2.6 이미지 출력 단가 100만 토큰당 $30(2026년 11월 5일 기준)입니다.

토큰 과금 경로의 GIF 한 개 값은 출력 토큰 × $30 ÷ 1,000,000으로 바로 나옵니다. LaoZhang API 문서팀이 2026년 11월 5일 Flare로 OpenAI에 직접 보낸 512×512·medium·9프레임 GIF는 출력 2,073토큰이었으니 2,073 × 30 ÷ 1,000,000 = $0.0622이고, low·4프레임은 1,172토큰으로 $0.0352였습니다. 프롬프트 텍스트 입력 토큰은 100만 토큰당 $5라 이 정도 길이면 $0.001도 되지 않습니다. 공식 포워딩의 OpenAI Official 그룹은 같은 값, OpenAI Official Enterprise 그룹은 20%를 더해 9프레임 기준 약 $0.075입니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

두 과금 방식이 같아지는 지점은 출력 1,000토큰입니다($0.03 ÷ $30 × 1,000,000). 위 두 측정이 모두 1,000토큰을 넘었으므로 web 경로가 받는 크기에서 개수를 많이 뽑는다면 회당 고정가가 유리하고, 512×512처럼 web 경로가 받지 않는 크기는 토큰 과금으로 가야 합니다. 1024×1024 GIF를 OpenAI 직접으로 만들었을 때의 토큰 수는 공개된 측정이 없으므로, 자기 설정으로 한 번 보내 응답의 usage.output_tokens를 위 식에 넣어 확인하는 것이 정확합니다. 2.5에서 2.6으로 옮길지와 품질별 정지 이미지 값은 GPT Image 2.6 vs 2.5 차이: high부터 같은 값, low·medium은 3~4배에서 비교합니다.

400·429·타임아웃: GPT Image 2.6 GIF 요청이 실패하는 이유

GIF 요청이 실패하는 이유는 대부분 범위 밖 값, 경로가 받지 않는 크기, 그리고 긴 생성 시간 셋 중 하나입니다. 2026년 11월 5일 범위를 벗어난 요청을 일부러 보내 보니 세 경우 모두 1~2초 만에 400이 돌아왔고 과금되지 않았습니다. web 경로에서 값이 범위를 벗어나면 message에는 요청이 받아들여지지 않았다는 말만 있어서, 원인은 param과 code로 구분해야 합니다.

에러 문구는 앞으로 바뀔 수 있으므로 코드에서는 문구 대신 HTTP 상태와 param, code 값으로 분기하는 편이 오래갑니다. 400은 고쳐서 다시 보내야 하는 요청이고, 429와 타임아웃만 같은 요청을 그대로 재시도할 대상입니다.

루프 이음새가 툭 튀는지 확인하기: 파이썬 검사 스크립트

GIF의 "루프"는 두 가지를 가리킵니다. 하나는 파일이 끝없이 반복 재생되도록 하는 설정이고, 다른 하나는 마지막 프레임에서 첫 프레임으로 넘어갈 때 움직임이 자연스럽게 이어지는지입니다. GPT Image 2.6이 만든 GIF는 앞의 것은 항상 무한 반복이었지만, 뒤의 것은 프롬프트로 부탁해도 보장되지 않았습니다.

OpenAI 이미지 프롬프트 가이드의 루프 GIF 항목은 매끄러운 루프를 위해 돌아올 시작 자세를 정해 주고 카메라를 움직일지 말지 밝히라고 권합니다. 2026년 11월 5일 이 권장을 그대로 담은 OpenAI의 원숭이 프롬프트를 web 경로에 9프레임으로 보냈더니, 마지막→첫 프레임 차이가 프레임 사이 평균 차이의 1.38배여서 재생하면 랜턴과 자세가 눈에 띄게 튀었습니다. 같은 프롬프트의 4프레임은 0.72, 16프레임은 0.93이었고, "A cute monkey with a lantern in the snow, animated." 한 줄짜리 프롬프트의 9프레임은 1.08이었습니다. 비교용으로 잰 OpenAI 공개 샘플(Sunburst)은 0.72, LaoZhang API 문서의 Flare 고양이 샘플은 0.68이었습니다. 프롬프트마다 한 개씩만 만든 결과라 루프 지시가 이음새를 보장하지 않는다는 것까지만 말할 수 있고, 모호한 프롬프트가 더 낫다는 근거는 아닙니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

그래서 생성한 GIF는 아래 스크립트로 한 번씩 재 보는 것이 빠릅니다. Pillow만 있으면 되고(pip install pillow), 프레임 수·프레임당 시간·반복 설정을 함께 출력합니다. 위 여섯 개 GIF에 돌리면 본문의 수치가 그대로 나옵니다.

# gif_seam.py — 사용법: python3 gif_seam.py loop.gif
import sys
from PIL import Image, ImageChops, ImageStat


def diff(a, b):
    d = ImageChops.difference(a, b)
    return sum(ImageStat.Stat(d).mean) / 3 / 255 * 100  # 평균 픽셀 차이(%)


path = sys.argv[1]
im = Image.open(path)
loop = im.info.get("loop")
frames, durations = [], []
try:
    while True:
        frames.append(im.copy().convert("RGB"))
        durations.append(im.info.get("duration"))
        im.seek(im.tell() + 1)
except EOFError:
    pass

steps = [diff(frames[i], frames[i + 1]) for i in range(len(frames) - 1)]
step = sum(steps) / len(steps)
seam = diff(frames[-1], frames[0])
print(f"frames={len(frames)} duration_ms={sorted(set(durations))} loop={loop} size={im.size}")
print(f"seam/step={seam / step:.2f}")

loop=0이면 파일이 무한 반복으로 설정된 것입니다. seam/step은 마지막→첫 프레임으로 넘어가는 변화가 평소 한 프레임 이동의 몇 배인지를 나타내므로, 1 이하면 이음새가 보통 걸음보다 크지 않다는 뜻이고 1을 넘을수록 되감기는 순간이 도드라집니다. 1을 넘는 GIF는 직접 재생해 보고 거슬리면 다시 생성합니다. 루프용 프롬프트를 쓰는 요령은 GPT Image 2.6 프롬프트 작성법에서 다룹니다.

구버전 openai SDK가 frame_count를 거부할 때: extra_body로 보내기

openai 파이썬 SDK가 frame_count나 frame_duration_ms에서 예상하지 못한 키워드 인자라며 TypeError를 내면 설치된 SDK가 2.6 필드를 모르는 것입니다. 이때는 두 필드를 extra_body={"frame_count": 9, "frame_duration_ms": 200}로 옮기면 SDK가 검사 없이 요청 본문에 그대로 붙여 보냅니다. 앞의 파이썬 예시가 처음부터 이 방식을 쓴 이유입니다. SDK를 올리는 방법도 있지만, OpenAI 커뮤니티의 GPT Image 2.6 SVG 스레드에 2026년 11월 5일 올라온 답변은 SVG용 svg 인자가 3.46.0부터 들어갔다는 내용뿐이고 GIF 필드가 어느 버전부터 인자로 들어갔는지는 언급하지 않습니다. extra_body는 버전에 상관없이 동작하므로 당분간은 이쪽이 안전합니다.

가지고 있는 사진을 API로 움짤로 바꿀 수 있나

지금은 기대하지 않는 편이 맞습니다. 사진을 넣는 쪽은 편집 엔드포인트인데, 2026년 11월 5일 기준 OpenAI 가이드는 GIF 출력이 생성 엔드포인트 전용이고 편집 엔드포인트는 GIF를 지원하지 않는다고 적고 있습니다. 같은 날 OpenAI API 레퍼런스의 images.edit 항목에는 output_format: "gif"와 frame_count가 들어 있어 문서끼리 어긋나지만, 지원한다는 설명은 가이드 쪽에 없습니다. LaoZhang API web 경로는 편집 요청에서 GIF를 돌려주지 않습니다.

안내: laozhang.ai는 이 블로그 운영팀의 자사 서비스입니다. 그 가격은 독립적인 비교가 아니라 자사 제시 가격입니다.

실제로 GIF가 나온 사례도 하나 있습니다. 같은 날 LaoZhang API 문서팀이 공식 포워딩으로 보낸 편집 요청이 GIF를 돌려준 일이 한 번 있었지만, 가이드가 안내하지 않는 동작이라 언제든 막힐 수 있습니다. 서비스에 넣을 코드라면 사진 속 피사체와 움직임을 프롬프트로 묘사해 생성 엔드포인트로 만드는 방식으로 짜 두는 것이 맞습니다.