Images 2.6는 API에 quality 및 complexity라는 두 가지 독립적인 컨트롤을 도입하고 체계적으로 문서화합니다. 제품 발표에 따르면 이미지 품질은 시각적 세부 사항과 충실도를 제어하고 복잡성은 "현장에 얼마나 많은 계획이 적용되는지"를 결정합니다. OpenAI에서는 더 빠른 편집을 위해 대부분의 편집 작업에 낮은 복잡성을 사용하고 워크플로우에 필요한 품질 계층과 짝을 이루도록 명시적으로 권장합니다. 변경 로그(2026-11-04)에는 2.6 출시 하이라이트 중 조정 가능한 복잡성도 나열되어 있습니다.

👉 PoYo에서 GPT Image 2.6 API 사용해 보기: 이미지당 가격과 온라인 플레이그라운드.

이 둘을 혼동하는 것은 "더 세밀하게 그리는 것"과 "더 많이 생각하는 것"을 하나의 손잡이로 취급하는 것입니다. 공식적인 정의는 반대 방향으로 진행됩니다. 전자는 충실도를 관리합니다. 후자는 렌더링 전 계획 깊이를 결정합니다. "매개변수를 생략하면 최대값을 의미합니다"라는 오래된 습관을 유지하면 복잡성이 자동으로 기본 high에 도달하여 편집 속도가 느려지고 원치 않는 변경이 발생할 수 있습니다.

값, 기본값 및 비용

이미지 생성 가이드 및 이미지 프롬프트 가이드에 따라:

복잡성 조정에는 별도의 청구 항목이 없습니다. 복잡성이 높을수록 대기 시간이 추가되고 원치 않는 추가 변경 사항이 추가될 수 있으므로 문서에서는 항상 최대한 활용하는 것보다 특정 작업에 대한 결과를 비교하는 것이 좋습니다. 제품 페이지에는 추가 정보가 있습니다. 요소나 제약 조건이 많은 장면은 중간 또는 높은 복잡성을 시도할 수 있습니다. 빠른 편집은 낮은 설정에 적합합니다. 복잡성이 낮을수록 배경이나 거리 표지판 교체와 같은 집중적인 변경에 적합합니다. 복잡성이 높을수록 조밀한 텍스트, 복잡한 레이아웃 및 개체 간 관계가 도움이 됩니다.

Flare가 quality=low에서 실행되면 OpenAI는 생성이 약 6초 안에 완료될 수 있다고 말합니다. medium/high 품질의 Sunburst는 보다 세부적이고 강력한 편집 일관성을 위해 배치되었습니다. 이는 모델 계층과 품질 계층이 결합된 효과입니다. 이는 복잡성에만 기인할 수 없으며 비교 없이 "한 계층이 항상 더 빠르다"고 주장해서는 안 됩니다.

A/B 방법

프롬프트 가이드는 명확한 튜닝 규칙을 제공합니다: 한 번에 하나의 설정을 변경. Freeze quality when comparing complexity; 레이아웃이 이미 정확하지만 작은 텍스트를 읽기 어려운 경우 동일한 복잡성에서 다른 quality 값을 비교하십시오. Docs use the same soccer-paper-cut prompt with fixed size="1024x1536" and quality="medium" to show Sunburst differences across low/medium/high complexity in trophy, “CHAMPIONS” sign placement, and jersey detail: at low complexity a crown appears on the trophy and a large banner sits in front of the team; medium adds laurel and crest; 높음은 표지판을 스탠드로 이동시키고 선수와 저지 접힌 부분이 전경에 남도록 합니다. The example shows that when the prompt leaves layout, text, and style under-specified, raising complexity meaningfully changes composition decisions; 레이아웃, 복사 및 스타일이 이미 프롬프트에 잠겨 있으면 복잡도가 높아져도 거의 차이가 나타나지 않을 수 있습니다.

대상 편집의 경우 공식적인 조언은 low에서 시작하여 주변 세부 사항이 그대로 유지되는지 확인하는 것입니다. 제품 발표 및 생성 가이드 언어가 일치합니다. 배경 교체 또는 거리 표지판 편집과 같은 집중적인 변경은 복잡성을 낮추는 데 적합합니다. 조밀한 텍스트, 복잡한 레이아웃 및 개체 관계는 중간/높음이 더 가치 있는 부분입니다. 마크업 편집을 사용하면 복잡성이 낮고 일반적으로 "원으로 둘러싸인 개체만 변경" 프롬프트 제약 조건에 부합하며 원을 벗어난 드리프트를 억제하는 데 도움이 됩니다.

실용적인 조합(여전히 문서화된 추론 범위 내에 있음)

"빠른 초안"을 다음과 같이 처리합니다. Flare + quality=low(또는 medium) + 편집을 위해 complexity를 low로 명시적으로 설정합니다(생략하면 기본값이 높으며 실제로 속도가 느려질 수 있기 때문). "최종 자산"을 다음과 같이 취급합니다. Flare 또는 Sunburst를 선택한 후 quality를 올리고 별도로 복잡성을 높일지 A/B합니다. max 품질이 high 복잡성과 쌍을 이루어야 한다고 가정하지 마세요. 기존 2.5 워크플로우를 마이그레이션할 때 프롬프트 가이드에서는 첫 번째 비교에서 프롬프트, 참조, 크기, 품질 및 출력 형식을 변경하지 않고 복잡성을 모델 기본값으로 남겨두고 승인 후 조정하도록 제안합니다. 크기 조정 전에 응답 시간, 실패/재시도 및 허용되는 이미지당 비용을 추적하세요.

또한 일반적인 제한 사항에 유의하세요. 복잡한 프롬프트는 최대 2분 정도 걸릴 수 있습니다. 텍스트 렌더링 및 구성 제어에는 여전히 경계가 있습니다. 매개변수는 모델 기능 범위 내에서 충실도, 계획 및 대기 시간만 교환하며 콘텐츠 조정이나 물리 수준 시뮬레이션 제한을 제거하지 않습니다. 충족되지 않은 품질을 확실히 개선하고 대기 시간 예산이 허용되는 경우에만 xhigh 및 max를 사용하십시오. 문서는 모든 메시지에 대해 더 높은 계층이 더 낫다는 것을 보장하지 않습니다.

결론: quality는 "얼마나 세밀하게 그릴 것인가"라고 답하고, complexity는 "얼마나 깊이 계획할 것인가"라고 답합니다. Images 2.6는 이를 분할하고 공식 지침에서 대부분의 편집 시나리오를 낮은 복잡성으로 조정합니다. 대신 "생략 = 최대" 습관을 유지하는 통합자는 기본적으로 높은 계획 깊이를 얻습니다. 매개변수를 명시적으로 설정하고 문서에 설명된 대로 단일 변수 비교를 실행하세요.