OpenAI가 2026년 6월 10일 ChatGPT release notes에서 모델 피커를 단순화한다고 밝혔습니다. 기존 Thinking Light, Standard, Extended, Heavy 같은 표현 대신 Instant, Medium, High, Extra High, Pro Standard, Pro Extended 형태로 바뀌는 구조입니다. Plus와 Pro 사용자에게 웹, iOS, Android 전역으로 롤아웃된다고 안내됐습니다.
이 변경은 ChatGPT UI 이야기로 끝나지 않습니다. AI 제품을 만드는 팀에게는 좋은 힌트입니다. 사용자는 모델 이름보다 “빠른 답이 필요한지”, “깊게 생각해야 하는지”, “시간이 더 걸려도 품질이 중요한지”를 더 잘 이해합니다. 모델 선택 UX를 기술명 중심에서 작업 의도 중심으로 바꿔야 한다는 신호입니다.
개발자는 모델명을 좋아합니다. GPT, Claude, Gemini, Opus, Sonnet, Flash, mini 같은 이름을 보면 대략 성능과 비용을 떠올릴 수 있습니다. 하지만 일반 사용자는 그렇지 않습니다. 같은 회사의 모델명도 버전이 바뀌면 의미가 흐려지고, “thinking” 같은 표현도 어느 정도의 시간과 비용을 뜻하는지 직관적이지 않습니다.
Instant, Medium, High는 사용자의 언어에 가깝습니다. Instant는 빠른 응답, Medium은 균형, High는 더 깊은 추론이라는 기대를 만듭니다. 제품 UX에서는 이 정도 추상화가 필요합니다. 모델명은 내부 라우팅의 입력이지, 항상 사용자에게 노출해야 하는 값은 아닙니다.
특히 B2B 제품에서는 모델 선택을 사용자에게 그대로 넘기면 지원 비용이 늘어납니다. “어떤 모델을 써야 하나요?”라는 질문이 반복되고, 잘못 고른 결과를 제품 품질 문제로 인식합니다. 선택지를 줄이는 것이 기능 축소가 아니라 성공률을 높이는 UX가 될 수 있습니다.
대부분의 AI 기능은 세 단계로 시작하면 충분합니다. 빠르게, 균형 있게, 깊게. 이름은 제품 맥락에 맞게 바꾸면 됩니다. 예를 들어 개발자 도구라면 “빠른 초안”, “표준 검토”, “깊은 분석”이 더 낫습니다. 문서 도구라면 “빠른 요약”, “정확한 정리”, “근거 포함 분석”이 맞습니다.
중요한 것은 각 단계가 실제 라우팅 정책과 연결되어야 한다는 점입니다. “빠르게”는 낮은 latency 모델, 짧은 max output, 제한된 도구 호출로 구성합니다. “균형”은 기본 모델과 적당한 reasoning effort를 씁니다. “깊게”는 더 강한 모델, 긴 컨텍스트, 도구 사용, 검증 단계를 허용합니다.
라벨만 바꾸고 내부가 같으면 사용자는 금방 알아챕니다. 반대로 내부 정책이 너무 복잡한데 UI가 모델명만 보여주면 사용자는 고르기 어렵습니다. UX와 라우터가 같이 설계돼야 합니다.
OpenAI 릴리즈 노트에는 Instant가 필요할 때 Medium으로 자동 전환할지 사용자가 설정할 수 있다는 설명도 있습니다. 이 지점이 중요합니다. 빠른 모드를 선택한 사용자가 항상 빠른 답만 원하는 것은 아닙니다. 때로는 요청이 복잡해서 더 깊은 추론이 필요합니다.
제품에서도 비슷한 설계를 할 수 있습니다. 사용자가 “빠른 모드”를 선택했더라도 입력이 길거나, 코드 변경 범위가 크거나, 여러 제약이 충돌하거나, 외부 도구 검증이 필요한 경우에는 자동으로 상위 모드로 올릴 수 있습니다. 다만 조용히 올리면 비용 불신이 생깁니다. “이 요청은 복잡해서 표준 모드로 처리합니다”처럼 짧게 알려주는 편이 좋습니다.
반대로 비용에 민감한 고객에게는 자동 전환을 끌 수 있게 해야 합니다. 관리 콘솔에서 “상위 모드 자동 전환 허용”, “월 예산 초과 시 자동 전환 금지”, “관리자 승인 필요” 같은 정책을 두면 B2B 구매자가 안심합니다.
많은 팀이 모델 라우터를 만들 때 입력 토큰 수부터 봅니다. 물론 중요합니다. 하지만 입력 길이만으로는 부족합니다. 짧은 요청도 어려울 수 있고, 긴 요청도 단순 요약일 수 있습니다.
실무 라우팅 기준은 최소 다섯 가지를 함께 봐야 합니다. 첫째, 작업 유형입니다. 요약, 분류, 코드 수정, 법률 검토, 데이터 분석은 난이도가 다릅니다. 둘째, 실패 비용입니다. 틀려도 다시 물으면 되는 작업과 고객에게 바로 노출되는 작업은 다릅니다. 셋째, 출력 형식 엄격도입니다. JSON schema, SQL, 코드 패치처럼 형식 실패가 치명적인 작업은 더 좋은 모델이나 검증 단계가 필요합니다. 넷째, 도구 사용 여부입니다. 외부 API나 파일 시스템을 건드리면 안전성이 중요합니다. 다섯째, 사용자 기대 시간입니다. 대화 중 답변과 백그라운드 리포트는 latency 기준이 다릅니다.
이 기준을 점수화하면 “Instant로 시작하되 점수가 일정 이상이면 Medium, 더 높으면 High” 같은 구조를 만들 수 있습니다.
모드를 단순화하면 과금 설명도 단순화해야 합니다. 사용량 화면에 모델명과 토큰만 나열하면 사용자는 여전히 이해하기 어렵습니다. “빠른 응답 120회”, “깊은 분석 18회”, “자동 상향 7회”처럼 UX 라벨 기준으로 보여주는 편이 낫습니다.
개발자용 상세 화면에는 실제 모델명, 입력/출력 토큰, reasoning token, 도구 호출 수를 보여주면 됩니다. 일반 사용자 화면과 관리자 상세 화면을 분리하는 것이 좋습니다. 모두에게 모든 정보를 보여주는 것은 투명성이 아니라 인지 부하가 될 수 있습니다.
ChatGPT 모델 피커 단순화의 핵심은 이름을 예쁘게 바꾼 것이 아닙니다. AI 제품에서 사용자가 고르고 싶은 것은 모델이 아니라 작업 방식입니다. 내부는 모델 라우터로 복잡해져도, 바깥은 작업 의도 중심으로 단순해야 합니다.
