GPT-6 Sol에서 6.1 Sol로 바꾸는 건 한 줄만 수정하면 되는 일처럼 보이고, 가격도 같습니다. 하지만 호환성을 깨는 변경 사항과 동작 방식의 변화가 있어 모델 이름만 바꾸면 오류가 발생하거나 예상치 못한 요금이 청구되거나 에이전트의 동작이 달라질 수 있습니다. OpenAI의 GPT-6 마이그레이션 가이드 에는 공식 변경 사항 대부분이 정리되어 있습니다. 이 글에서는 실제로 마이그레이션할 때 문제가 되기 쉬운 점들을 덧붙입니다.
문제가 크게 드러나는 항목부터 조용히 문제를 일으키는 항목 순으로 정리했습니다.
1. reasoning_effort: "none" 을 사용하면 400 오류가 발생합니다
확인되는 현상: 요청이 거부됩니다.
이유: 6.1 Sol은 none 이나 minimal을 지원하지 않습니다. 가장 낮은 수준은 low입니다. GPT-6 Sol과 Luna는 여전히 none을 허용하기 때문에 기존 코드는 이 모델들에서 작동했습니다.
해결 방법:
- OpenAI의 매핑 방법은
none을low로 바꾸는 것입니다.minimal을 사용했다면low부터 시작해 비교해 보세요. low는none보다 느리고 비용이 더 많이 듭니다. 추론 토큰을 생성하기 때문입니다. 자동 완성이나 실시간 분류처럼 지연 시간이 특히 중요한 경로라면 GPT-6 Sol을 계속 사용하거나 Luna로 옮기는 편이 나을 수 있습니다.
2. Chat Completions에서 도구 호출이 작동하지 않습니다
확인되는 현상: tools가 포함된 Chat Completions 요청이 실패합니다.
이유: GPT-6 Sol은 reasoning_effort가 none일 때만 Chat Completions에서 함수 호출을 허용했습니다. 저렴한 도구 호출을 위해 이 조합을 사용한 프로젝트가 많았습니다. none이 사라지면서 6.1 Sol의 Chat Completions는 도구가 없는 요청에서만 작동합니다. 도구를 사용하려면 Responses API를 사용해야 합니다. OpenAI의 Responses API로 마이그레이션하기 가이드에서 자세한 방법을 확인할 수 있습니다.
해결 방법: /v1/responses로 옮기세요. AIHubMix도 지원합니다. 매개변수는 AIHubMix Responses API 문서를 참조하세요.
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["AIHUBMIX_API_KEY"],
base_url="https://aihubmix.com/v1",
)
resp = client.responses.create(
model="gpt-6.1-sol",
reasoning={"effort": "low"}, # nested, not reasoning_effort
tools=[{
"type": "function",
"name": "get_weather",
"description": "Get the current weather for a city",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
},
}],
input="What's the weather in Shanghai today?",
)
print(resp.output)
놓치기 쉬운 사항:
- Responses에서는 매개변수가
reasoning.effort입니다.reasoning_effort를 보내면Unsupported parameter오류가 발생합니다. - 여러 턴에 걸쳐 도구를 사용할 때는 함수 결과만이 아니라 마지막 사용자 메시지 이후의 추론, function_call, function_call_output 항목을 모두 다시 보내세요.
store: false또는 ZDR을 사용할 때 추론 항목에는 기본적으로encrypted_content가 포함됩니다. 전체 기록을 다시 보내면 문제없이 작동합니다.
3. 샘플링 매개변수를 제거해야 합니다
확인되는 현상: temperature 또는 top_p가 포함된 요청이 실패합니다.
이유: 이 매개변수는 effort가 none일 때만 허용됩니다. 6.1 Sol에는 none이 없으므로 이 모델에서는 사용할 수 없습니다.
제거할 항목:
temperature,top_p,top_logprobs- Chat Completions의
logprobs - Responses의
include에 지정하는message.output_text.logprobs
신뢰도 점수나 분류 임계값을 위해 logprobs를 사용했다면 다른 방법을 찾아야 합니다. 한 가지 방법은 모델에 신뢰도를 직접 보고하도록 요청하는 구조화된 출력을 사용하는 것입니다. 또 다른 방법은 none을 지원하는 모델에서 해당 작업을 계속 처리하는 것입니다.
4. 캐싱 방식이 달라져 요금이 늘어날 수 있습니다
특히 GPT-5.5 이하 모델에서 마이그레이션하는 경우 가장 놓치기 쉬운 항목입니다. 아래 내용은 모두 OpenAI의 프롬프트 캐싱 가이드를 바탕으로 합니다.
매개변수 이름이 바뀌었습니다. prompt_cache_retention은 이제 prompt_cache_options.ttl이며, 지원되는 값은 "30m"뿐입니다.
캐시 쓰기에는 요금이 부과됩니다. 입력 요금의 1.25배이며(6.1 Sol은 백만 토큰당 $2.50), 한 번만 사용하는 긴 접두부도 캐싱을 사용하면 사용하지 않을 때보다 25% 더 비쌉니다.
브레이크포인트 위치가 바뀌었습니다. 이전 모델은 고정된 간격으로 브레이크포인트를 설정했습니다(GPT-5.5는 토큰 2,048개마다 설정). 이제 암시적 모드에서는 조건을 충족하는 가장 최근 메시지의 끝에 브레이크포인트 하나를 설정합니다. 그 결과 여러 요청에서 공유하는 더 짧은 접두부는 자동으로 재사용되지 않습니다. 시스템 프롬프트 뒤에 사용자 입력만 달라지는 여러 요청을 보내는 경우, 시스템 프롬프트 바로 뒤에 명시적 브레이크포인트를 추가하세요.
기존 메시지에 내용을 덧붙이면 캐시가 무효화됩니다. 캐시된 끝 지점이 더 긴 메시지의 중간에 놓여 일치 항목을 찾지 못합니다. 대신 새 메시지를 추가하세요.
추론 effort를 바꾸면 캐시가 무효화됩니다. reasoning.effort는 접두부의 일부입니다. configuration_update를 사용해 대화 중간에 변경하세요(2부 참조). 이 기능은 자동 압축이나 잘라내기와 함께 사용할 수 없으며, /responses/compact는 이 기능이 포함된 기록을 거부한다는 점에 유의하세요.
트래픽이 많으면 캐시 적중률이 낮아질 수 있습니다. 캐시는 개별 머신에 저장됩니다. 같은 접두부로 분당 약 15건을 초과하는 요청을 보내면 다른 머신으로 넘겨져 캐시를 적중하지 못할 수 있습니다. 캐시된 토큰도 TPM 제한에 포함됩니다.
마이그레이션 전후에 cached_tokens, cache_write_tokens, 지연 시간, 작업당 비용을 비교하세요.
5. 입력이 272K를 넘으면 가격이 두 배가 됩니다
1.05M 컨텍스트 윈도는 매력적이지만, 입력이 272K 토큰을 넘으면 요청 전체에 입력 요금 2배, 출력 요금 1.5배가 적용됩니다. 입력을 270K에서 280K로 늘리면 요청 비용이 $0.64에서 $1.27로 증가합니다(계산 방법은 3부 참조).
에이전트 세션은 길어질수록 계속 커지므로, 알아차리지 못한 채 이 기준을 넘기 쉽습니다. 클라이언트 측에서 250K 근처에 알림을 설정하고, 알림이 울리면 압축을 시작하세요.
6. 작은 max_output_tokens 값 때문에 응답이 비어 있을 수 있습니다
확인되는 현상: status: incomplete와 사유 max_output_tokens가 표시되고, 사용자에게 보이는 출력은 없지만 요금은 청구됩니다.
이유: max_output_tokens에는 추론 토큰도 포함됩니다. none에서는 충분했던 한도가 low 이상에서는 추론 토큰만으로 모두 소진될 수 있습니다.
해결 방법: OpenAI의 추론 가이드는 토큰을 최소 25,000개 확보하라고 권장합니다. 하드코딩된 제한값을 확인하세요. 특히 Chat Completions의 max_tokens에서 그대로 가져온 값에 주의해야 합니다. 예를 들어 AIHubMix 모델 페이지의 샘플 코드는 1024를 사용합니다. 간단한 텍스트 데모에는 충분하지만 실제 워크로드에서는 값을 높이세요.
7. 에이전트 동작이 달라졌으므로 권한을 다시 검토하세요
전반적으로 6.1 Sol은 6 Sol보다 더 안정적으로 작동합니다. 심각한 사고는 3분의 1로 줄었고, 도구가 고장 났을 때 이를 알려줄 가능성도 훨씬 높습니다. 그래도 몇 가지 수치는 주목할 필요가 있습니다(OpenAI 데이터를 DataCamp에서 취합):
| 동작 | 6.1 Sol | 6 Sol | Astra |
|---|---|---|---|
| 명시적인 제한을 우회하려고 계속 시도함 | 23.5% | 64.4% | 17.4% |
| 코딩 작업에서의 기만 | 1.50% | 1.30% | 0.51% |
| 다른 에이전트에게 연락함 | 38% | 26% | — |
| 승인되지 않은 작업을 실행함 | 3% | 11% | — |
6.1 Sol은 더 끈질깁니다. 막히면 더 많은 우회 방법을 시도하고 다른 에이전트와 소통하려는 의향도 더 큽니다. 자동화 에이전트에는 보통 바람직한 특성이지만, 에이전트에 폭넓은 권한을 부여했다면 위험도 커집니다.
대응 방법:
- 프롬프트에 지침을 적는 데 그치지 말고 샌드박스와 허용 목록으로 권한을 제한하세요.
- 삭제, 배포, 결제, 자격 증명에 영향을 주는 작업 등 민감한 작업은 사람의 승인을 받도록 하세요.
- 도구 호출 로그를 모두 보관하고 "테스트 통과" 또는 "수정 완료"와 같은 주장을 표본 검사하세요.
- 멀티 에이전트 환경에서는 에이전트끼리 공유할 수 있는 내용을 정확히 정의하세요.
8. 프롬프트를 조정해야 할 수 있습니다
OpenAI의 GPT-6 마이그레이션 가이드에는 몇 가지 동작 변화가 정리되어 있습니다. Astra를 대상으로 작성된 내용이지만 6.1 Sol도 같은 계열이고 성능이 비슷하므로, 다음 사항을 확인하세요.
- 질문을 더 많이 합니다. 계속 진행할 것이라고 예상한 상황에서도 멈춰 확인할 수 있습니다. 행동을 우선하고 작업을 완료하도록 지시하고, "…해줄 수 있나요?"와 같은 표현은 실제로 해당 작업을 수행하라는 요청이라고 알려주세요.
- 지시를 더 문자 그대로 따릅니다.
AGENTS.md와 SKILL.md 파일을 더 꼼꼼히 따르므로 오래된 규칙도 갑자기 적용될 수 있습니다. OpenAI는 이 파일들을 점검하고 사용자 지시가 스킬보다 우선한다고 명시할 것을 강력히 권장합니다. - Markdown, 목록, 표를 더 자주 사용하고 상투적인 표현을 반복합니다. 산문 형태의 답변을 원한다면 명시적으로 요청하세요.
- 작은 변경에도 테스트를 과도하게 수행합니다. 위험이 낮고 되돌릴 수 있는 수정은 전체 테스트를 실행할 필요가 없다고 알려주세요.
- 원하는 것보다 하위 에이전트에 작업을 덜 위임합니다. 병렬 작업을 원한다면 언제 작업을 나눌지 명확히 지시하세요.
9. 이용 가능 여부 및 배포 제한
- 일반 ChatGPT 채팅에서는 아직 사용할 수 없습니다. ChatGPT Work와 Codex에서만 사용할 수 있습니다. Enterprise 및 Edu 관리자는 기능을 활성화해야 합니다.
- Fast 모드는 EU 데이터 레지던시에서 작동하지 않습니다. Ultrafast는 미국 레지던시와 글로벌 처리만 지원합니다.
- 지식 기준일은 2026년 4월 30일입니다. 그 이후의 라이브러리, API 또는 뉴스는 웹 검색이나 RAG를 사용하세요.
- 지원되지 않는 항목: 파인튜닝, Predicted Outputs, 오디오 및 비디오 입력, Realtime 및 Assistants API.
- 속도 제한 은 6 Sol과 동일합니다. Tier 1의 500 RPM / 500K TPM부터 Tier 5의 15,000 RPM / 40M TPM까지 지원합니다. AIHubMix에서는 요청을 OpenAI 또는 Azure를 통해 처리할 수 있으며, 한 제공업체에 장애가 발생하거나 응답이 느려지면 다른 제공업체로 자동 재시도합니다.
마이그레이션 체크리스트
- [ ]
none과minimal을low로 바꾸고 지연 시간을 확인합니다 - [ ] 도구 호출 요청을 Chat Completions에서 Responses API로 옮깁니다
- [ ] 중첩 매개변수
reasoning.effort를 사용합니다 - [ ]
temperature,top_p,logprobs를 제거하고 logprobs에 의존하는 로직을 다시 설계합니다 - [ ]
prompt_cache_retention을prompt_cache_options.ttl: "30m"로 바꿉니다 - [ ] 공유 접두부 뒤에 명시적 브레이크포인트를 추가하고 길이가 최소 1,024토큰인지 확인합니다
- [ ] 대화 중간에 effort를 변경할 때
configuration_update를 사용합니다 - [ ] 입력 272K 알림을 추가합니다
- [ ]
max_output_tokens를 최소 25,000으로 설정 - [ ]
AGENTS.md, SKILL.md, 시스템 프롬프트 점검 - 샌드박스 권한, 승인 단계, 도구 로깅 검토
- 마이그레이션 전후의 성공률,
cached_tokens,reasoning_tokens, 작업당 비용 비교
Codex를 사용한다면 $openai-docs migrate this project to the GPT-6 model family을 실행해 대부분의 기계적인 변경을 처리할 수 있습니다. 그래도 체크리스트를 직접 확인하세요.
자주 묻는 질문
GPT-6 Sol에서 6.1 Sol로 전환하려면 최소한 무엇을 바꿔야 하나요? 세 가지입니다. 모델 이름을 바꾸고, none과 minimal을 low로 교체하고, temperature, top_p, logprobs 관련 항목을 모두 제거하세요. Chat Completions를 통해 도구를 호출한다면 Responses API로도 전환해야 합니다.
일반 텍스트에는 여전히 Chat Completions를 사용할 수 있나요? 네. tools가 없는 요청이라면 Chat Completions를 사용할 수 있습니다. AIHubMix 모델 페이지의 예제가 바로 이런 유형의 호출입니다.
AIHubMix는 Responses API를 지원하나요? 네. base_url을 https://aihubmix.com/v1로 설정하고 client.responses.create를 호출하세요.
업그레이드 후 캐시 적중률이 떨어졌습니다. 무엇을 확인해야 하나요? 세 가지를 확인하세요. 공유 접두부 뒤에 명시적인 중단점이 있는지, 기존 메시지에 내용을 덧붙이고 있는지, 대화 도중 reasoning.effort를 변경하고 있는지 확인합니다. 그런 다음 업그레이드 전후의 cached_tokens와 cache_write_tokens를 비교하세요.
업그레이드 후 지연 시간이 늘었습니다. 예상된 현상인가요? none을 사용했다면 그렇습니다. low도 여전히 추론 토큰을 생성합니다. 지연 시간이 중요한 경로에는 GPT-6 Sol 또는 Luna를 계속 사용하거나, 첫 토큰을 더 빨리 출력하도록 모델에 짧은 도입 문구를 요청하세요.
6.1 Sol은 6 Sol보다 권한을 넘어설 가능성이 높나요? 전반적으로는 아닙니다. 심각한 사고가 3분의 1 줄었고, 실제로 승인되지 않은 작업을 수행한 비율은 11%에서 3%로 떨어졌습니다. 다만 다른 에이전트에 연락하거나 코딩 작업에서 기만적인 행동을 할 가능성은 다소 높으므로, 프롬프트에만 의존하지 말고 샌드박스로 권한을 통제하세요.
기존 AGENTS.md와 시스템 프롬프트를 계속 사용할 수 있나요? 실행은 되지만 내용을 검토하세요. GPT-6 계열은 지시를 더 엄격하게 따르므로, 오래되었거나 서로 충돌하는 규칙이 있으면 모델이 더 자주 멈춰서 질문하거나 의도하지 않은 행동을 할 수 있습니다.
계속 읽기: GPT-6.1 Sol 시리즈
- 전환할 가치가 있는지 확신이 서지 않나요? 6.1 Sol이 6 Sol보다 뛰어난 부분과 Astra에 얼마나 근접했는지 확인하세요: GPT-6.1 Sol vs GPT-6 Sol: Astra를 거의 따라잡은 일주일간의 업그레이드.
none을low로 바꿨습니다. 다른 설정은 어떻게 해야 하나요? 사용 사례별 권장 사항과 조정 절차를 확인하세요: GPT-6.1 Sol의 추론 강도 선택하기: low부터 max까지.- 마이그레이션 후 청구 금액을 확인하세요. 캐시 적중, 272K 임계값, 추론 토큰을 설명합니다: GPT-6.1 Sol의 실제 비용: $2 / $10 가격표 너머.
