Alibaba는 2026-07-21에 Qwen Image 3.0 Pro를 출시했으며, ofox에서 $0에 올라왔습니다. 이 게이트웨이의 대부분의 이미지 모델이 가격이 책정되는 방식인 이미지당 비용이 숨겨진 $0 토큰이 아닙니다. 이미지당 비용도 없습니다. 이는 조용히 소모되는 체험 크레딧이 아닌, 진정한 제로(zero)입니다.

또한, 이번 주에 바로 제품을 구축하기에 적합한 종류의 무료는 아닙니다. 그 이유는 대부분의 영어 매체가 간과한 모델 카드(model card)의 중국어 설명에 적혀 있습니다: "本版本为限时免费体验版，目前为限量体验阶段" (한정 기간 무료 체험 버전이며, 현재 한정된 할당량 단계입니다). 두 가지 별개의 제약 사항이 있으며, 두 번째 제약 사항이 실제로 여러분의 오후 업무를 방해하게 될 것입니다.

여기 무료 티어(free tier)가 제공하는 것과 제한하는 것, 그리고 gpt-image-2 튜토리얼에서 복사한 코드를 망가뜨릴 세 가지 통합 세부 사항이 있습니다. 이 포스트의 모든 이미지는 2026-07-23에 생성된 모델의 원본 출력물입니다.

이 설정을 마친 후 할 수 있는 것 (그리고 할 수 없는 것)

할 수 있는 것

• OpenAI 호환 엔드포인트를 통해 토큰 및 이미지당 비용 모두 $0로, 임의의 크기로 텍스트-이미지 (text-to-image) 생성을 할 수 있습니다.

소요 시간

이미 ofox 키를 가지고 있다면 약 3분 정도 소요됩니다.

필요한 것

Ofox API 키, Python 3.8+ 또는 Node 18+, 그리고 아마 이미 설치되어 있을 openai SDK가 필요합니다.

할 수 없는 것

• 배치(batch) 작업을 실행할 수 없습니다. 발표된 할당량(quota)에 맞춰 계획을 세우세요. 가격이 다음 달에도 유지된다고 가정하지 마세요. base64를 반환받을 수 없습니다. 참조 이미지(reference images)를 사용할 수 없습니다 (아래 참조).

결정 프레임: 언제 사용해야 하는가 (그리고 언제 사용하지 말아야 하는가)

사용할 때:

• 이미지 모델을 평가 중이며, 예산을 투입하기 전에 자신의 프롬프트에 대한 Qwen 3.0 Pro의 텍스트 렌더링 성능을 테스트하고 싶을 때.
• 이미지를 가끔씩 대화형으로 생성하며, 시간당 몇 장 정도를 생성하여 429 오류가 발생하더라도 작업 실패가 아닌 재시도 정도로 끝나는 경우.
• 이미지 내부에 중국어 텍스트가 필요하지만 현재 사용 중인 모델이 이를 망가뜨릴 때. 이는 Qwen이 진정으로 차별화되는 기능이며, 검증하는 데 비용이 들지 않습니다.

사용하지 말아야 할 때:

• 대량으로 생성(bulk generation)을 수행하는 경우. 할당량(quota) 단계로 인해 처리량(throughput)을 예측할 수 없으며, 배치 작업(batch job)에서 예측 불가능한 처리량은 이미 알고 있는 비용을 지불하는 것보다 더 나쁩니다.
• 지연 시간(latency) SLA가 있는 경우. 여기서 429 오류에 대한 백오프(Backoff)는 수백 밀리초(ms)가 아니라 수십 초 단위로 측정됩니다.
• 아무도 관리하지 않아도 3개월 뒤에도 여전히 작동해야 하는 무언가를 작성하는 경우. 무료 리스팅은 명시적으로 기간이 정해져 있습니다.

중단 규칙 (Stop rule)

텍스트 렌더링(text rendering) 주장이 사실인지 알고 싶을 뿐이라면, 아래의 네 가지 테스트 이미지를 읽고 이 가이드의 나머지 부분은 건너뛰십시오. 요약하자면, 단어에는 유효하지만 시퀀스(sequences)에는 실패하며, 이를 아는 것만으로도 이득을 얻기 위해 무엇인가를 통합할 필요는 없습니다.

시스템 요구 사항 (System Requirements)

• ofox 대시보드에서 발급받은 ofox API 키.
• openai>=1.0이 포함된 Python 3.8 이상, 또는 openai 패키지가 포함된 Node 18 이상. Alibaba 계정, DashScope 키, 별도의 지역 설정(region config)은 필요하지 않습니다.
• 파일을 작성할 공간. 엔드포인트는 바이트(bytes)가 아닌 URL을 제공하며, 해당 URL은 영구적이지 않습니다.

단계별 설정 (Step-by-Step Setup)

1단계: SDK를 ofox로 지정하기

from openai import OpenAI

client = OpenAI(
...

예상 결과: 출력 없음. 만약 임포트(import)에 실패하면 pip install -U openai로 업그레이드하세요.

2단계: 모델 호출하기

resp = client.images.generate(
    model="bailian/qwen-image-3.0-pro:free",
    prompt="A ceramic mug on a linen cloth, morning light, shallow depth of field",
...

예상 결과: https://dashscope-*.oss-accelerate.aliyuncs.com/... URL이 표준 출력(stdout)에 인쇄됨.

Node 스택을 사용하는 경우:

import OpenAI from "openai";

const client = new OpenAI({
...

3단계: 만료되기 전에 바이트(bytes) 다운로드하기

import urllib.request

urllib.request.urlretrieve(resp.data[0].url, "out.png")

예상 결과: 디스크에 out.png 저장, 일반적으로 1024x1024 해상도에서 1~1.5 MB 크기.

이 단계는 선택적인 정리 작업이 아닙니다. URL을 데이터베이스에 쓰기 전에 다음 섹션을 읽으십시오.

복사한 코드를 망가뜨리는 두 가지 통합 세부 사항

base64가 아닌 URL을 반환함

현재 유통되는 대부분의 이미지 생성 튜토리얼은 b64_json을 반환하는 gpt-image-2를 기준으로 작성되어 있습니다. 이 엔드포인트의 Qwen 3.0 Pro는 url을 반환하며 b64_json은 비워둡니다. 다음과 같은 코드는:

raw = base64.b64decode(resp.data[0].b64_json)   # Qwen에서 TypeError 발생

None 값으로 인해 실패합니다. 여러 모델을 교차하여 라우팅한다면 두 가지 형태를 모두 처리하십시오:

item = resp.data[0]
raw = (base64.b64decode(item.b64_json) if item.b64_json
       else urllib.request.urlopen(item.url).read())

해당 URL은 Alibaba의 OSS를 가리키며 서명된 만료 시간이 포함되어 있습니다. 바이트(bytes) 데이터를 영구적으로 저장하십시오. 데이터베이스에 URL을 저장하면 나중에 이미지가 깨지게 됩니다.

무료 할당량은 일 단위가 아닌 순간 단위임

공식적으로 발표된 분당 요청 수(requests-per-minute)는 없으므로, 관찰 가능한 수치를 측정했습니다. 요청을 연속해서 보내면 두 번째 호출에서 429 Requests rate limit exceeded가 반환되었습니다. 두 개의 생성 프로세스를 동시에 실행하면 둘 다 429 오류가 발생하며, 하나를 종료할 때까지 어느 것도 진행되지 않았습니다. 45초부터 시작하여 점진적으로 대기 시간을 늘리는(escalating backoff) 단일 순차 워커(sequential worker)는 시도한 모든 요청을 완료했습니다.

어떠한 동시성(concurrency) 상황에서도 즉시 429가 발생하고, 엄격하게 직렬(serial)로 처리할 때 성공률이 높은 이러한 양상은 외부에서 보기에 제한된 할당량의 시험 단계(trial phase)가 갖는 전형적인 모습입니다. 이는 서비스 중단(outage)이 아니며, 더 강하게 재시도하는 것은 상황을 악화시킬 뿐입니다.

실질적인 해석: 제한기(limiter)는 전체 볼륨보다 동시성과 버스트(burst)에 훨씬 더 민감합니다. 일시 정지를 포함한 단일 스레드 루프는 임시방편이 아니라, 의도된 사용 형태입니다.

import time, openai

def generate(prompt, size="1024x1024", tries=6):
...

텍스트 렌더링 주장이 유효한가?

Alibaba의 이번 세대 핵심 홍보 포인트는 타이포그래피 (Typography)입니다. 즉, 작은 글씨의 가독성 유지, 긴 프롬프트 (Prompt)의 일관성 유지, 그리고 한 프레임 내 여러 언어 스크립트 (Scripts)의 구현입니다. 이는 검증 가능한 영역이기에 직접 확인해 보았습니다. 아래의 모든 이미지는 주어진 크기에서 모델이 생성한 가공되지 않은 결과물이며, 리터칭 (Retouching)이나 여러 시도 중 좋은 것만 골라내는 체리피킹 (Cherry-picking)을 하지 않았습니다.

테스트 1: 사양 표 내의 작은 글자 (Small print)

프롬프트는 정확한 수치가 포함된 라벨이 붙은 4개의 행과 하단의 미세한 글씨로 된 시리얼 번호 라인을 요구했습니다.

모든 수치가 정확히 나타났습니다: Pressure 9 bar, Boiler 1.6 L, Weight 12.4 kg, Warranty 24 months. 하단 라인은 Serial AT-2026-0731 / Made in Suzhou라고 읽히며, 슬래시(/)와 하이픈(-)이 포함된 시리얼 번호까지 정확합니다. 1024x1536 해상도에서 이 미세한 글씨는 대략 8pt 크기에 해당합니다. 글리프 (Glyph)가 누락되거나, 존재하지 않는 문자가 생성되거나, 작은 크기에서 글자 형태가 뭉개지는 현상이 없었습니다. 이는 보통 이미지 모델들이 한계를 드러내는 지점입니다.

테스트 2: 한 프레임 내 두 가지 스크립트

단일 표지판에 영어와 중국어를 혼용하였으며, 각 언어는 별도의 줄을 차지하고 숫자 필드는 공유하도록 설정했습니다.

두 스크립트 모두 정확합니다. 开发者专场와 注册签到는 대부분의 이미지 모델이 CJK (한중일) 언어에 대해 생성하는 글자 모양의 노이즈가 아니라, 제대로 형성된 문자입니다. 라틴 문자(Latin)와 중국어 라인은 일관된 굵기를 공유하며, 09:00이라는 숫자도 두 줄 모두 일치합니다.

서구권 이미지 모델을 사용하여 쓸만한 중국어 포스터를 만들려고 시도해 본 적이 있는 사람이라면, 이 포스트에서 가장 흥미로운 결과가 바로 이것이며, 비용을 들이지 않고 직접 검증할 수 있는 부분이기도 합니다.

테스트 3: 라벨이 붙은 여러 부품이 포함된 기술 도표

이것은 보통 모델이 무너지는 사례입니다. 프롬프트는 반드시 나타나야 할 다섯 가지 문자열(CLIENT, GATEWAY, MODEL, RESPONSE, 그리고 auth / route / inference 범례)을 지정했으며, 각 블록 아래의 캡션 (Caption)은 명시하지 않았습니다.

지정된 다섯 개의 문자열 모두 올바른 위치에 정확하게 렌더링되었습니다. 모델이 요청하지 않았음에도 수행한 작업이 주목할 만한 부분입니다. 모델은 제목을 추가하고, 화살표에 1. Request / 2. Forward / 3. Output과 같이 번호를 매겼으며, 단순히 의미 없는 채우기용 텍스트(lorem-ipsum)가 아닌 기술적으로 일관된 자체 캡션(예: 게이트웨이 아래의 "Validates authentication / Routes to endpoint")을 작성했습니다. 철자 또한 전체적으로 정확했습니다.

이 정도라면 초안 단계의 문서용 다이어그램으로는 그럴듯해 보입니다. 하지만 이것이 모델의 신뢰성을 보장하지는 않습니다. 모델이 만들어낸 캡션은 사용자의 아키텍처에 대한 모델 자체의 추측일 뿐이며, 내용이 틀렸을 때도 똑같이 자신만만하게 주장할 것이기 때문입니다.

테스트 4: 실제로 한계가 드러나는 지점

우리는 파일 트리, 구문 강조(syntax-highlighted)가 적용된 Python 코드, 그리고 1번부터 14번까지 보이는 줄 번호가 포함된 코드 에디터 스크린샷을 요청했습니다.

에디터의 외형(chrome)은 거의 완벽에 가깝습니다. 파일 이름은 정확하고 아이콘도 올바르게 매칭되었으며, 상태 표시줄(status bar)에는 요청한 대로 UTF-8 CRLF Python 3.12 Ln 8, Col 22 Spaces: 4라고 정확히 표시되었습니다. 메뉴 바도 일관성이 있으며, 구문 강조(syntax highlighting)는 키워드, 문자열, 함수 이름에 그럴듯한 색상을 할당했습니다.

이제 줄 번호 영역(gutter)을 보십시오. 줄 번호가 1, 3, 3, 4, 6, 7, 9, 8, 0, 8, 11, 11, 12, 13, 14로 나열되어 있습니다. 2, 5, 10은 없고, 여러 개의 중복된 숫자가 있으며, 뜬금없는 0도 있습니다. 그다음 마지막 코드 줄을 보면, Python에서 두 개가 필요한 곳에 단일 등호 하나만 사용된 if __name__ = "__main__":가 적혀 있습니다.

이것이 이 모델의 솔직한 한계입니다. 작은 글자나 중국어를 포함한 단어와 라벨은 정확하게 출력됩니다. 하지만 수열(Sequences)과 코드 연산자(code operators)는 그렇지 못합니다. 줄 번호 영역은 단조 증가(monotonic) 카운팅을 테스트할 수 있는 가장 순수한 방법이며, 모델은 멀리서 보면 카운팅하는 것처럼 보이지만 자세히 살펴보면 무너져 내리는 결과물을 만들어냈습니다. 동일한 약점이 ==가 있어야 할 자리에 =가 나타나는 현상에서도 동일하게 드러납니다.

실질적인 규칙: 인간이 텍스트를 언어로 읽는 모든 용도에 사용하세요. 독자가 문자 그대로 정확한 코드로 취급할 스크린샷이나, 축 레이블(axis labels)이 실제 시퀀스여야 하는 차트에는 사용하지 마세요. 이는 더 나은 프롬프트로 해결할 수 있는 프롬프트 엔지니어링 (prompt engineering) 문제가 아니라, 모델이 현재 잘하지 못하는 부분입니다.

크기: 종횡비 열거형(Aspect Ratio Enum)이 없음

여러 이미지 엔드포인트(endpoints)는 고정된 크기 목록을 허용하고 그 외의 것은 거부합니다. 이 때문에 많은 생성 코드들이 "widescreen"을 특정 벤더가 승인한 문자열로 매핑하는 룩업 테이블 (lookup table)을 포함하고 있습니다. 하지만 이 모델은 그런 방식으로 작동하지 않는 것으로 보입니다.

우리가 전달한 모든 값은 정확히 해당 해상도로 반환되었습니다. 만약 고정된 종횡비로 블로그 히어로 이미지나 소셜 카드를 생성한다면, 정사각형으로 생성한 뒤 자르는 대신 최종 치수를 직접 요청할 수 있습니다. 이는 구도가 잘려 나가는 상황을 줄일 수 있는 방법 중 하나입니다.

주의할 점은 이것이 문서화된 계약(contract)이라기보다는 관찰된 동작(observed behaviour)이라는 것입니다. 특히 출력물을 잘못된 비율에서 레이아웃이 깨지는 레이아웃에 입력하는 경우라면, 당연하게 가정하기보다는 반환된 치수를 검증하십시오.

참조 이미지: 작동시키지 못함

모델 카드(model card)에는 텍스트-투-이미지 (text-to-image)와 함께 참조 이미지 (reference-image) 입력이 나열되어 있습니다. 우리는 이 엔드포인트를 통해 이를 작동시킬 수 없었으며, 실패하는 방식이 조용히 실패하기 때문에 기록할 가치가 있습니다.

세 가지 형태를 시도했으며, 모두 동일한 소스 이미지(테스트 1의 에스프레소 포스터)를 대상으로 레이아웃과 세부 수치를 보존하면서 잉크 스케치 스타일로 재구성해달라는 프롬프트를 사용했습니다:

두 번째 시도는 얼핏 보기에 더 유사해 보이며, 자세히 살펴보면 더 많은 교훈을 줍니다. 이는 프롬프트에서 피사체를 말로 명시했기 때문에 주제와 관련이 있어 보일 뿐입니다. 테스트 1과 숫자를 비교해 보십시오. 원본 포스터에는 보일러 1.6 L 및 무게 12.4 kg라고 되어 있지만, 이 결과물에는 2.0 L 및 28 kg라고 되어 있습니다. 4행 테이블은 8개 셀 그리드가 되었고, 제품 사진은 호출선(callouts)이 있는 단면도(cutaway)가 되었으며, 보증(warranty) 행은 사라졌습니다. 일치하는 유일한 값인 9 bar는 지금까지 제작된 모든 에스프레소 머신의 표준 압력이므로, 이는 어떤 증거도 되지 못합니다.

다시 말해, 모델은 프롬프트 텍스트로부터 새로운 이미지를 생성했을 뿐 참조 이미지를 사용하지 않았습니다. 세 번째 시도는 앞선 두 시도보다 더 나쁩니다. 왜냐하면 분명히 존재하는 model 파라미터가 누락되었다고 불평하는 400 오류는, 당신이 자신의 직렬화(serialization) 과정을 20분 동안 디버깅하게 만들기 때문입니다.

정확히 말할 수 있는 점은 다음과 같습니다: 이 모델에 대해 참조 이미지(reference-image) 입력은 문서화되어 있지만, ofox의 OpenAI 호환 이미지 엔드포인트를 통해 이를 전달할 수 있는 파라미터 형태를 찾지 못했습니다. Alibaba의 네이티브 DashScope API를 통해서는 작동할 수도 있고, 혹은 우리가 시도하지 않은 올바른 파라미터 이름이 있을 수도 있습니다. 이 모델이 하지 않는 것은 '명확하게 실패를 알리는 것'입니다. 따라서 이 모델을 기반으로 구축한다면, HTTP 200 응답이 성공을 의미한다고 가정하지 말고 출력이 실제로 입력값을 반영하는지 반드시 확인하십시오.

설정 중 발생하는 일반적인 오류