GPT-6 Sol은 2026년 9월 22일에 공개되었고, GPT-6.1 Sol은 그로부터 일주일 뒤인 9월 29일에 공개되었습니다. 기존 시스템의 모델 ID를 즉시 교체해야 할지 고민할 때, 저는 '새로운가'보다는 '현재 태스크에서 검증 가능한 개선점이 있는가'를 먼저 살펴봅니다. 특히 처리 순서에 따라 결과가 달라지는 코드, 정확한 항목 수, 사용자가 기다리는 API 응답 시간은 분리하여 평가하고 싶습니다.
9월 30일에 Crazyrouter의 https://api.crazyrouter.com/v1/chat/completions를 통해 두 모델에 동일한 영어 과제를 전송했습니다. 저장된 생성 코드는 11월 3일에 로컬에서 재실행했습니다. 이 날 새로운 추론 요청은 진행하지 않았습니다. 아래 내용은 제한적인 과제와 접근 경로에 대한 기록이며, 현재의 가동률을 측정했다고 볼 수 없습니다.
청구 이벤트(billing event)를 집계하는 함수를 구상해 보았습니다. 요구 사항은 이벤트 ID별로 첫 번째 기록을 남기고, 이후 시간 범위를 적용하며, 테스트용 계정을 제외하여 청구액과 환불액을 집계하는 것입니다. 만약 시간 범위 필터링을 먼저 진행하면, 범위 외의 최초 이벤트를 삭제하고, 범위 내에 있는 동일 ID의 후속 이벤트를 최초로 오인할 가능성이 있습니다.
예를 들어, ID가 a이고, 첫 번째 이벤트가 시각 -1에 금액 90으로 기록되었고, 후속 이벤트가 시각 5에서 발생하며, 집계 범위가 [0, 10)이라고 가정해 보겠습니다. 만약 중복 제거(deduplication)를 먼저 수행하면, 남아 있는 최초 이벤트는 범위 외이므로 이 ID의 청구액은 증가하지 않습니다. 순서를 반대로 하면 90을 오계상할 수 있습니다.
두 모델 모두 저장된 답변에서 중복 제거 로직을 먼저 배치했습니다. 각 모델로부터 얻은 총 4개의 함수를 122개 항목에 걸쳐 로컬 체크로 재확인했으며, 모두 통과했습니다. 이는 명확하게 정의된 작은 함수에 대한 결과일 뿐이며, 미지의 대규모 리포지토리나 다중 파일 수정 능력까지 보여주는 것은 아닙니다.
실무에서는 이 경계 사례(boundary case)를 회귀 테스트(regression test)에 남겨두는 것이 유용합니다. 단순히 지시문에 처리 순서를 작성하는 것뿐만 아니라, 범위 외의 최초 이벤트와 범위 내의 중복 이벤트를 같은 테스트 케이스에 포함해야 합니다. 기존 GPT-6 Sol의 출력이 그 테스트를 안정적으로 통과한다면, 이 함수만을 급하게 마이그레이션할 이유는 찾기 어렵습니다.
또 다른 과제에서는 합성된 360개의 규칙으로부터 조건에 맞는 항목 수를 답하도록 했습니다. 독립적인 계산으로 정답은 72개임을 확인했습니다. 지정된 우선 규칙(priority rule)의 존재 여부에 대한 질문도 추가했지만, 해당 규칙은 문서에 없습니다.
저장된 두 번씩의 답변에서 GPT-6 Sol은 72개를 두 번, GPT-6.1 Sol은 각각 72개와 71개를 한 번씩 반환했습니다. 존재하지 않는 우선 규칙에 대해서는 두 모델 모두 올바르게 부정했습니다. 단 한 번의 카운트 누락으로 모델 전체의 우열을 결정할 수는 없습니다. 다만, 가장 그럴듯한 설명과 정확한 집계값은 별도로 검증해야 한다는 점을 알 수 있습니다.
규정이나 청구 자료에 사용할 경우, 모델에게 해당 규칙 ID와 판단 근거를 나열하게 하고, 최종 항목 수는 중복 제거를 포함하는 프로그램으로 산출해야 합니다. 이렇게 하면 숫자가 불일치할 때 원래 항목으로 되돌아갈 수 있기 때문입니다. 금액이나 날짜가 포함된 판단이라도, 최종 값을 모델의 한 문장만 믿기보다는 다루기 쉬운 방식으로 처리하는 것이 좋습니다.
9월 30일 이벤트 추출 과제에서는 완료된 GPT-6.1 Sol의 두 번의 응답 시간이 각각 약 19.25초와 12.62초였고, GPT-6 Sol은 각각 약 22.83초와 20.62초였습니다. 반면, 다른 코드 과제에서는 같은 속도 경향이 이어지지 않았습니다.
전체적으로 각 모델에 대해 8종류의 과제를 두 번씩 실행했으며, reasoning_effort: "high" 및 출력 제한 8192 토큰을 사용했습니다. 원래 실행에는 병렬 요청(parallel request)이 포함되어 있습니다. GPT-6 Sol은 16회 중 16회가 완료했고, GPT-6.1 Sol은 16회 중 14회가 완료했으며, 후자의 규칙 검색 2회는 클라이언트 측의 약 240초 타임아웃에 도달했습니다. 이 16회는 독립적인 16개 문제가 아니라 특정 날짜의 작은 요청 그룹입니다. 이를 서비스 전체의 장애율이나 항시적인 속도 차이로 환산할 수는 없습니다.
백그라운드 처리라면 나중에 재시도가 가능하지만, 화면상에서 사용자가 기다리고 있는 상황은 다릅니다. 응답 기한(response deadline), 실패 시 표시, 그리고 재시도가 이중 쓰기(double writing)를 일으키지 않도록 사전에 설계해야 합니다. 품질 평가에서도 오답과 미완료를 같은 '실패'로 묶어 기록하지 않으면 개선해야 할 부분을 파악할 수 있습니다.
OpenAI와 호환되는 채팅 클라이언트라면, 연결의 시작점은 Crazyrouter 연동 안내에서 확인할 수 있습니다. Base URL은 https://api.crazyrouter.com/v1이며, 이번 채팅 요청 목적지는 https://api.crazyrouter.com/v1/chat/completions입니다. 모델 ID는 gpt-6-sol과 gpt-6.1-sol입니다.
사용합니다. 후자의 소수점을 웹페이지 URL에 있는 하이픈과 혼동하지 않도록 합니다.
먼저 계정에서 두 ID가 보이는지 확인하고, 실제 작업을 보내 응답을 확인합니다. 모델 목록에 올라와 있다는 것만으로는 추론(Inference) 성공이라고 할 수 없습니다. 입력(Input), 영어 지침문(English instructions), 추론 설정(Inference settings), 출력 상한(Output limit), 테스트 데이터를 고정하고 모델 ID만 변경하여 출력과 미완료된 두 가지 모두를 저장합니다. 공통 엔드포인트 사용 가능 여부와 자동 재시도(auto-retry) 또는 폴백(fallback)이 구현되어 있는 것 또한 별개입니다.
작은 함수가 기존의 GPT-6 Sol로 충분히 검증되었다면, 그 부분은 유지합니다. 수정이 반복되는 복잡한 과제에서는 GPT-6.1 Sol을 후보로 시험해 보고, 실제 재작업(rework)이 줄어드는지 확인합니다. 건수 확정 및 응답 기한은 어떤 모델을 선택하든 애플리케이션 측에서 관리하는 것이 제 판단입니다.
