ChatGPT Images 2.5 출시: 스케치·템플릿·API 차이와 편집 방법

최종 업데이트 2026.09.23

ChatGPT Images 2.5에서 이미지를 만들고 메모지 색상만 편집하는 실제 절차를 실행해 보존 조건, 실패 기준, ChatGPT와 API의 범위를 구분했습니다.

ChatGPT Images 2.5는 대화형 화면에서 이미지를 만든 뒤, 원하는 부분만 설명해 편집할 수 있습니다. 이 글의 직접 검증에서는 코발트색 머그와 메모지를 생성하고 메모지 색상만 산호색으로 바꿨으며, 머그·구도·문구는 유지되는지 확인했습니다.

검증일: 2026년 9월 21일. OpenAI의 ChatGPT Images 2.5 공식 발표와 OpenAI Help Center의 Images 사용 안내를 현재 기준으로 다시 확인한 뒤, Windows 데스크톱의 Google Chrome에서 로그인된 ChatGPT Pro 웹 화면을 직접 실행했습니다. 입력에는 이름·이메일·계정 자료·저작권 캐릭터·API 키를 넣지 않았습니다.

먼저 결론: 생성보다 부분 편집의 보존 조건을 확인해야 한다

Images 2.5를 업무에 도입할 때 가장 먼저 확인할 질문은 “예쁜 이미지가 나왔는가”가 아니라 “바꾸라고 한 요소만 바뀌었는가”입니다. 제품 사진, 배너, 설명 카드처럼 이미 구도가 잡힌 결과를 반복해서 다듬는 흐름에서는 배경이나 주 피사체가 함께 흔들리면 다시 손보는 비용이 커집니다. 따라서 첫 실행에서는 개인정보가 없는 단순한 장면을 만들고, 두 번째 실행에서는 색상처럼 범위가 좁은 한 가지 요소만 바꾸는 것이 안전한 검증 순서입니다.

OpenAI는 공식 발표에서 Images 2.5의 개선점으로 더 선명한 디테일, 자연스러운 조명과 질감, 참조 이미지의 주제 보존, 편집 지시를 더 안정적으로 따르는 동작을 설명합니다. 또한 여러 턴의 편집에서 앞선 변경을 유지하는 일관성, Sketch·Templates·댓글 기반 편집·프롬프트 공유 같은 ChatGPT 기능을 소개합니다. 이 설명은 제품의 목표와 제공 기능을 알려 주지만 특정 사용자의 결과를 보장하지는 않습니다.

Help Center는 ChatGPT에서 대화 중 이미지를 만들 수 있고, 기존 이미지를 업로드한 뒤 바꿀 부분을 설명할 수 있다고 안내합니다. 생성에는 몇 분이 걸릴 수 있으며, Images with thinking은 Plus·Pro·Business에 제공되고 Enterprise·Edu에는 순차 제공된다고 적혀 있습니다. 따라서 같은 기능이라도 계정 등급, 롤아웃, 플랫폼에 따라 버튼과 대기 화면이 달라질 수 있습니다.

이번에 재현한 생성·편집 절차

검증 절차는 재현 가능한 입력을 짧게 고정하는 데서 시작했습니다. 첫 요청은 “Create a photorealistic product-style image of a cobalt-blue ceramic mug beside a pale-yellow sticky note on a clean white desk. Put the exact text ‘TEST NOTE’ on the note. No people, names, logos, personal data, or copyrighted characters.”였습니다. 장면에 포함할 물체, 메모지의 색, 메모지 문구, 개인정보 제외 조건을 한 번에 적어 결과를 비교하기 쉽게 했습니다.

ChatGPT Images 2.5에서 코발트색 머그와 TEST NOTE가 적힌 연노랑 메모지를 생성한 원본 화면
같은 ChatGPT 웹 세션의 원본 결과 화면입니다. 입력 프롬프트와 코발트색 머그, 연노랑 메모지, TEST NOTE 문구가 함께 보입니다.

원본이 표시된 뒤 이미지의 편집 기능을 열고 다음 요청을 보냈습니다. “Change only the sticky note color from pale yellow to coral pink. Keep the cobalt-blue mug, the desk, composition, and exact text ‘TEST NOTE’ unchanged.” 여기서 중요한 부분은 “only”와 유지할 요소를 함께 적은 것입니다. 색상만 바꾸라는 범위를 명시하지 않으면 모델이 장면의 조명이나 배경까지 다시 구성할 수 있어 비교가 어려워집니다.

ChatGPT Images 2.5에서 메모지만 산호색으로 바뀌고 코발트색 머그와 TEST NOTE 문구는 유지된 편집 결과 화면
편집 결과 화면입니다. 메모지는 산호색으로 바뀌었고, 코발트색 머그·책상·구도·TEST NOTE 문구는 화면상 유지됐습니다.

추가로 같은 대화에서 원본을 다시 선택해 메모지 색상을 soft mint green으로 바꾸는 한 턴을 더 실행했습니다. 아래 영상은 이 추가 턴을 포함해 원본 선택, 편집 문장 입력, 생성 대기, 결과 표시가 이어지는 실제 데스크톱 화면을 기록한 것입니다. 정지 이미지를 연결해 만든 영상이 아니라, 실행 중 화면을 10fps로 캡처한 VP9 WebM입니다.

실제 Chrome 세션에서 원본 이미지의 편집을 열고 색상 변경 프롬프트를 보낸 뒤 결과가 나타나는 과정을 기록한 작동 영상입니다. 영상에는 대기 화면과 결과 화면의 프레임 변화가 포함됩니다.

관찰 결과를 체크리스트로 읽는 법

이번 직접 실행의 관찰 결과는 네 가지입니다. 첫째, 자연어 한 문장으로 새 이미지를 요청하면 머그·메모지·책상이라는 장면 요소가 한 화면에 생성됐습니다. 둘째, 메모지에 지정한 TEST NOTE 문구가 결과에 나타났습니다. 셋째, 편집 요청 뒤 메모지의 색상이 연노랑에서 산호색으로 변했습니다. 넷째, 이 비교에서는 머그의 위치와 색, 책상 배경, 전체 구도, 문구가 눈으로 확인할 수 있는 범위에서 유지됐습니다.

이 결과를 “항상 정확히 보존한다”로 확대하면 안 됩니다. 이미지 모델의 생성 결과는 실행마다 달라질 수 있고, 글자 렌더링은 작은 크기나 복잡한 배경에서 흔들릴 수 있습니다. 보존 여부는 색상 이름만으로 판정하지 말고, 원본과 결과를 나란히 놓고 핵심 객체의 위치, 텍스트, 배경, 그림자, 비율을 확인해야 합니다. 제품 상세 페이지에 쓰기 전에는 실제 사용 크기에서도 문구가 읽히는지 별도로 확인해야 합니다.

업무용 검수표는 다음처럼 간단히 만들 수 있습니다.

  • 바꾸라고 한 요소가 정확히 하나인가? 여러 변경을 한 번에 요구하지 않았는가?
  • 유지해야 할 주 피사체·구도·문구를 프롬프트에 명시했는가?
  • 원본과 결과를 같은 비율과 화면 크기로 비교했는가?
  • 사람 이름, 고객 자료, 얼굴, 로고 등 민감하거나 권리 확인이 필요한 소재를 제외했는가?
  • 결과를 게시하기 전에 작은 글자, 손·제품 형태, 색상, 배경 변형을 사람이 확인했는가?

ChatGPT 화면과 API를 혼동하지 않는 방법

이번 실행은 ChatGPT 웹 화면의 생성·편집 기능을 검증한 것입니다. API 호출, 모델 ID 선택, 요청 비용, 응답 JSON, 서버 측 재시도는 실행하지 않았습니다. 따라서 이 글의 결과를 API 통합 성공이나 특정 API 모델의 품질 측정으로 읽으면 안 됩니다. API를 검토하려는 팀은 ChatGPT 화면의 기능 제공 여부와 별도로 OpenAI API 이미지 생성 도구 문서에서 인증, 이미지 입력·출력 형식, 도구 모델 선택을 확인하고, GPT Image 2.5 Sunburst 모델 문서에서 현재 모델의 역할·품질 옵션·가격 단위를 다시 확인해야 합니다.

반대로 ChatGPT 사용자에게는 API 키가 없어도 웹 화면에서 기본 생성·편집 흐름을 확인할 수 있다는 점이 중요합니다. 다만 계정 등급과 롤아웃에 따라 Images 메뉴, Templates, Sketch, 댓글 도구, 대기 화면이 다르게 보일 수 있습니다. 공식 발표가 말하는 “모든 ChatGPT·ChatGPT Work·Codex 사용자”라는 범위와 Help Center의 플랜별 기능 안내를 함께 읽고, 실제 계정에서 보이는 기능을 기준으로 내부 가이드를 작성해야 합니다.

실무에서 API가 필요한 경우에는 먼저 ChatGPT에서 원하는 결과의 편집 계약을 정합니다. 예를 들어 “배경을 유지하고 제품 색상만 바꾼다”와 같은 입력·출력 조건을 정한 뒤, API에서는 그 계약을 테스트 케이스와 비교 이미지로 옮깁니다. 화면에서 한 번 성공한 결과만으로 자동화 품질을 단정하지 말고, 정상 입력·긴 문구·저대비 배경·실패 요청을 별도 케이스로 관리하는 편이 안전합니다.

실패 조건과 한계

첫 번째 실패 조건은 편집 범위가 모호한 경우입니다. “더 예쁘게 바꿔줘”처럼 대상과 보존 조건이 없으면 어떤 부분이 바뀌어도 성공 여부를 판정하기 어렵습니다. 두 번째는 텍스트가 작거나 배경과 겹치는 경우입니다. 화면상 읽히더라도 실제 배포 크기에서 글자가 깨질 수 있습니다. 세 번째는 복잡한 인물·브랜드·제품 사진을 권리와 개인정보 확인 없이 넣는 경우입니다. 이 자동화에서는 그런 자료를 쓰지 않고, 무해한 합성 장면만 사용했습니다.

네 번째는 기능이 보이지 않는 경우입니다. 공식 문서에 기능이 적혀 있어도 계정·지역·플랫폼·롤아웃 시점에 따라 실제 화면에 아직 나타나지 않을 수 있습니다. 이때는 없는 버튼을 가정해 진행하지 말고, 관찰한 화면과 계정 조건을 기록한 뒤 보류해야 합니다. 다섯 번째는 생성 시간이 길어져 사용자가 결과를 받기 전에 탭을 닫는 경우입니다. Help Center도 이미지 생성에 몇 분이 걸릴 수 있다고 안내하므로, 자동화에서는 충분한 대기와 실패 시 재현 로그를 설계해야 합니다.

이번 검증 범위는 텍스트 프롬프트로 장면을 생성하고 색상 부분 편집을 확인하는 흐름에 한정했습니다. 템플릿 선택, Sketch 입력, 댓글 기반 편집, 기존 사용자 이미지 업로드, API 호출과 같은 별도 경로는 범위 밖입니다. 공식 발표와 Help Center의 기능 설명은 함께 확인했지만, 속도 개선 수치나 이미지 품질을 정량 측정하지 않았으므로 “최대 몇 배 빠르다” 또는 “항상 원본을 보존한다” 같은 결론은 내리지 않습니다.

도입 전에 남겨야 할 검증 기록

팀에서 같은 흐름을 쓰려면 검증일, 환경, 계정 등급, 입력 프롬프트, 원본 결과, 편집 프롬프트, 편집 결과, 보존된 요소, 실패 조건, 사람 검수자를 한 묶음으로 남기면 됩니다. 이미지 파일만 보관하면 어떤 지시를 보냈는지 알 수 없으므로, 프롬프트와 결과의 관계를 함께 기록해야 합니다. 반대로 계정 쿠키나 비공개 자료를 캡처에 남기면 안 됩니다.

게시 전 최종 확인은 원본과 결과의 비교, 대체 텍스트, 캡션, 영상 재생, 모바일 화면에서의 잘림 여부 순서로 진행하는 것이 좋습니다. 내부 링크는 dea:no의 공개 작성 원칙과 소개처럼 현재 공개된 canonical URL을 사용하고, 초안 전용 ?p=317 주소는 본문에 넣지 않아야 합니다.

공식 출처와 공개 내부 링크