모델 비교에서는 하나의 종합 점수만 봐서는 실제 업무 적성을 판단하기 어렵습니다. 최종적인 답이 옳은 것, 지정된 모든 요구사항을 충족하는 것, 기계 처리가 가능한 형식으로 반환하는 것은 각각 별개의 능력이기 때문입니다.

그래서 이번에는 Crazyrouter의 동일한 OpenAI-compatible endpoint를 통해 Claude Opus 5와 GPT-5.6-SOL에 10개의 검증 과제를 실행했습니다. 평가 대상은 수학·물리의 정답, 잘못된 전제의 지적, Python 코드의 숨겨진 테스트(hidden test), 모든 서브 요구사항의 완수입니다. 엄격한 JSON 출력은 추론 문제와는 분리하여 지시 준수 테스트로 취급했습니다.

결과는 다음과 같습니다.

• 핵심 답변의 정답률: Opus 5는 10/10, GPT-5.6-SOL도 10/10
• 모든 서브 요구사항을 완료한 비율: Opus 5는 9/10, GPT-5.6-SOL은 10/10
• Python 알고리즘 2문항의 숨겨진 테스트: 두 모델 모두 2/2
• 엄격한 JSON의 첫 제출: Opus 5는 0/1, GPT-5.6-SOL은 1/1
• Opus 5는 추가 2회의 재시도에서도 JSON 이외의 문장 또는 코드 펜스(code fence)를 부가함

이 결과로부터 알 수 있는 것은, 10문항의 핵심 정답률은 동일했으나 태스크의 완수와 출력 형식의 준수에는 차이가 보였다는 점입니다. 단순한 순위로 정리하기보다 정답률·완수율·형식 준수를 나누어 읽는 것이 실운용에는 도움이 됩니다.

수학·물리·알고리즘의 정확성을 중시하는 용도에서는 이 샘플에서 명확한 차이를 확인할 수 없었습니다. 반면, 응답을 그대로 JSON으로 해석하는 처리나 모든 서브 요구사항을 한 번에 충족해야 하는 용도에서는 이번 GPT-5.6-SOL 쪽이 완전한 형태로 제출할 수 있었습니다.

이번 결과를 해석할 때는 다음의 3개 층을 혼동하지 않는 것이 중요합니다.

• 핵심 답변의 정답률
  주요 수치, 결론, 물리 모델, 알고리즘의 동작이 옳은가.
• 태스크 완수율
  질문에 나열된 서브 요구사항을 마지막까지 누락 없이 답변했는가.
• 기계적인 수용 가능 여부
  코드가 테스트를 통과하는가, JSON을 그대로 해석할 수 있는가.

예를 들어, 올바른 수치를 내놓았더라도 마지막 설명이 빠져 있다면 핵심 답변은 정답일지라도 태스크 완수라고는 판정할 수 없습니다. 또한, JSON 내의 값이 모두 정확하더라도 앞뒤에 설명문이 붙어 있다면 엄격한 JSON을 요구하는 처리에서는 수용되지 않습니다.

이러한 분리를 통해 '추론을 틀린 것'인지, '출력이 중간에 끊긴 것'인지, '형식만이 요구사항을 위반한 것'인지를 구별할 수 있습니다.

모델 API의 엔드 투 엔드(end-to-end) 대기 시간에는 모델의 추론 능력 이외의 요인이 포함됩니다.

• 게이트웨이에서 각 상류 서비스까지의 네트워크 경로
• 검증 시점의 채널 부하 및 계정 제한
• 캐시 유무
• 실제로 할당된 서비스 인스턴스
• 상류 측에서의 reasoning token 측정 방법 및 비표시 처리

단발적인 요청이 몇 초 빠르다고 해서 그것만으로 모델의 추론 능력이 높다고 판단할 수는 없습니다. 상류 환경을 고정하고 충분한 횟수를 반복하며 신뢰 구간까지 제시하지 않는 한, 대기 시간은 운영 모니터링의 지표이지 지능의 지표는 아닙니다.

따라서 이번에는 네트워크 대기 시간을 지능 스코어에서 명시적으로 제외했습니다. 또한 응답 속도에 대해서는 어느 한쪽이 우위에 있다고 판정하지 않았습니다.

이용 가능한 모델이나 접속 범위는 Crazyrouter의 모델 목록, 비용 계획은 Crazyrouter pricing에서 별도로 확인할 수 있습니다.

검증 전에 모델 목록 API를 호출하여 대상이 되는 정확한 모델 ID가 표시되는 것을 확인했습니다.

GET https://cn.crazyrouter.com/v1/models
claude-opus-5
gpt-5.6-sol

본 검증 요청에는 다음 API를 사용했습니다.

POST https://cn.crazyrouter.com/v1/chat/completions

각 테스트에서는 두 모델에 동일한 system prompt, user prompt, temperature, max_tokens를 설정했습니다. 외부 도구는 사용하지 않았으며, HTTP 200이 반환되었다는 것만으로는 합격이라 판정하지 않았습니다.

채점은 다음 절차로 진행하고 있습니다.

• 기대값, 필수 요구사항, 테스트 조건을 사전에 정의
• 두 모델에 동일한 조건으로 문제 전송
• 수치 및 필수 문자열을 자동 검사
• Python 코드는 저장하여 숨겨진 테스트(hidden test) 실행
• JSON은 실제로 파서(parser)에 전달
• 자동 판정 후 사람이 내용을 재확인
• 핵심 정답, 완수, 형식 준수를 별도로 기록

사람이 재확인을 수행한 이유는 표기 차이로 인한 거짓 음성(false negative)을 피하기 위해서입니다. LaTeX 작성 방식, 영문 대소문자, 엄격한 분수와 반올림된 소수의 차이만으로 오답이라 판정해서는 안 됩니다.

실제로 GPT-5.6-SOL은 확률 문제에서 참조용 분수를 그대로 복제하지는 않았으나, 등가인 식과 올바른 소수를 제시했습니다. 또한, Opus 5는 물리 문제의 0.302 m를 유효 숫자 2자리인 0.30 m로 표기했습니다. 둘 다 핵심적인 오류는 아닙니다.

10문항의 핵심 답변은 두 모델 모두 10/10입니다. 다만, 모든 하위 요구사항을 충족한 완전한 답변은 Opus 5가 9/10, GPT-5.6-SOL이 10/10이었습니다.

대상 패턴은 HHTH이며, 편향된 동전의 확률은 P(H)=0.62, P(T)=0.38입니다.

질문에서는 가장 긴 접두사(prefix)·접미사(suffix) 일치에 기반한 상태를 사용하여 방정식을 세우고, 추가로 다음 두 가지 점을 설명하도록 요구했습니다.

• 상태 HH 다음에 다시 H가 나왔을 때, 왜 상태가 HH로 유지되는지
• 왜 기대 대기 시간을 단순히 1/P(HHTH)라고 쓸 수 없는지

두 모델이 얻은 기대값은 올바른 것이었습니다.

E[N] ≈ 12.6547

GPT-5.6-SOL은 상태 전이와 유도를 끝까지 제시하였으며, 패턴의 중첩을 고려하여 다음 관계를 보여주었습니다.

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5 역시 올바른 상태, 방정식, 엄격한 분수 및 소수값을 제시했습니다. 하지만 응답의 finish_reason은 finish_reason=length였습니다.

이 문제에서는 max_tokens=3200이 출력 상한이 되었으며, Opus 5의 답변은 추가적인 상태 기대값을 기술하던 도중에 종료되었습니다. 그 결과, 마지막에 요구되었던 "왜 단순한 역확률을 사용할 수 없는가"에 대한 설명이 누락되었습니다.

평가는 다음과 같이 나누었습니다.

• 기대값 12.6547과 상태 방정식은 올바르므로 핵심 답변은 정답
• 마지막 설명 요구사항이 없으므로 완전한 태스크 제출로서는 불합격

즉, 올바른 중간 결과가 포함되어 있다는 것과 요청 전체를 완수했다는 것은 동일한 의미가 아닙니다.

이 점은 이전의 max_tokens에 의한 중단 재검증과도 일맥상통합니다. 검증 시에는 답변 본문뿐만 아니라 finish_reason과 출력 상한도 저장해야 합니다.

코드 생성에서는 긴 구현이나 친절한 주석이 정확성을 보장하지 않습니다. 따라서 이번에는 두 모델의 출력을 .py 파일로 저장하여, 격리된 환경에서 동일한 숨겨진 테스트를 실행했습니다.

함수에는 다음 요구사항을 설정했습니다.

• 반개구간 (Half-open interval) 시간 창을 올바르게 처리할 것
• 성공 요청과 실패 요청에 서로 다른 집계 규칙을 적용할 것
• 사용자 또는 모델이 누락된 입력을 처리할 것
• cache hit rate를 계산할 것
• cost가 동일한 경우 사용자 이름의 사전 순으로 정렬할 것
• 입력 객체를 변경하지 않을 것

두 모델의 구현 모두 숨겨진 테스트를 통과했습니다.

경로 탐색에서는 다음 조건들을 동시에 처리해야 합니다.

• 총 비용(Total cost)이 최소인 경로를 선택할 것
• 비용이 동일한 경우 latency가 최소인 경로를 선택할 것
• latency도 동일한 경우 reliability가 최대인 경로를 선택할 것
• 그래도 동일한 경우 경로의 사전 순으로 선택할 것
• banned nodes, 최대 hops, 최소 reliability, 잘못된 간선(edge)을 처리할 것

이 또한 두 모델 모두 숨겨진 테스트를 통과했습니다.

따라서 이번 코드 검증 결과는 두 모델 모두 2/2입니다. 코드의 길이 나 설명의 가독성이 아니라, 실행 결과에 기반하여 동률로 판정했습니다.

GPT-5.6-SOL의 또 다른 복잡한 물리·의존성 알고리즘 검증에 대해서는 'GPT-5.6-SOL vs GPT-5.5 고난도 물리·코드 검증'을 참조할 수 있습니다.

엄격한 JSON 과제에서는 사고 데이터를 단일 객체로 통합하고, 다음 조건을 명시했습니다.

exactly one JSON object and no Markdown

두 모델 모두 실패율, 채널 귀속, 재시도 후에도 복구되지 않은 건수를 정확히 계산했습니다. 차이점은 JSON 전후에 무엇을 출력했느냐입니다.

• GPT-5.6-SOL은 첫 시도부터 JSON만 반환하여, json.loads로 직접 파싱할 수 있었습니다.
• Opus 5는 첫 시도에 코드 펜스(code fence)와 Verification을 추가했습니다.
• Opus 5의 1차 재시도에서는 압축된 JSON 뒤에 Verification을 추가했습니다.
• Opus 5의 2차 재시도에서는 다시 코드 펜스와 설명을 추가했습니다.

따라서 엄격한 JSON의 첫 제출 결과는 다음과 같습니다.

Opus 5는 데이터나 계산을 틀린 것이 아닙니다. 모든 필드와 값은 정확했으나, 요구된 출력 형식을 위반했습니다. 이는 '계산 능력의 실패'가 아니라 '형식 및 지시 준수(instruction following)의 실패'입니다.

실제 운영 환경에서는 최소한 로컬 측에서 다음과 같은 검증을 수행할 수 있습니다.

import json
REQUIRED_KEYS = [
"window",
...

system prompt만으로는 구조화된 출력(structured output)을 보장할 수 없습니다. 더 견고하게 만들려면 공급 측에서 지원하는 구조화된 출력 파라미터를 사용하고, 로컬에서 schema 검증을 수행하며, 파싱에 실패할 경우 재시도하거나 모델을 전환하는 방식을 취해야 합니다.

다음은 OpenAI-compatible chat completions endpoint를 사용하는 최소 구성입니다. API endpoint 자체에는 UTM 파라미터를 붙이지 않습니다.

import os
import requests
BASE_URL = "https://cn.crazyrouter.com/v1"
...

재검증 시에는 최소한 다음 정보들을 저장해 두면 나중에 판정 근거를 추적하기 용이합니다.

• response ID
• returned model
• finish_reason
• 원문 답변
• 요청 시의 max_tokens
• 로컬 검증 결과
• JSON 파싱 에러
• 코드 테스트의 표준 출력(stdout) 및 종료 코드

현재 모델 표시 상태는 Crazyrouter의 모델 목록에서 확인하고, 그 후에 실제 업무용 prompt를 사용하여 소규모 회귀 테스트(regression test)를 수행하는 것이 안전합니다.

• 정답이나 허용 오차를 사전에 정의할 수 있는 수학·물리 문제
• 단위 테스트(unit test)를 실행할 수 있는 Python 알고리즘
• 잘못된 전제나 불충분한 통계적 결론을 지적하는 처리
• 로컬 검증기를 통해 성공·실패를 판정할 수 있는 작업 절차

이번에 두 모델은 10문제 모두에서 핵심 답변이 정답이었으며, 2개의 코드 과제에서도 숨겨진 테스트를 통과했습니다. 따라서 검증 가능한 처리 영역에서는 두 모델 모두 후보에 포함될 수 있습니다.

• 모든 하위 요구사항을 한 번의 응답으로 충족해야 함
• 응답 본문이 엄격한 JSON이어야 함
• 설명문에서 구조화된 데이터를 추출하는 처리를 줄이고 싶음

이것은 종합적인 지능 순위를 의미하는 것이 아닙니다. 이번 관측 범위 내에서는 GPT-5.6-SOL이 태스크 완수와 엄격한 JSON 제출을 통해 요구사항을 충족했다는 한정적인 판단입니다.

• 긴 유도 과정에는 충분한 max_tokens를 설정할 것
• 반드시 finish_reason을 확인할 것
• JSON은 다운스트림 (downstream)으로 전달하기 전에 파싱할 것
• 불필요한 Markdown이나 설명문이 있는 경우를 대비한 회귀 처리 (fallback)를 준비할 것
• 필수 서브 요구사항을 개별적으로 검사할 것
• 중단 시에는 출력 상한을 조정하여 재시도할 것

Opus 5의 추론 능력이 약했다는 결과가 아닙니다. 이번 10문항에서는 핵심 답변이 모두 정확했으며, 2개의 코드 구현도 숨겨진 테스트를 통과했습니다. 차이가 나타난 지점은 올바른 내용을 최종 응답 안에 모두 담아냈는지, 아니면 지정된 형식만으로 반환했는지의 여부입니다.

Claude 계열 모델 내에서의 제출 동작도 비교하려면, Claude Opus 5 vs Claude Fable 5 실 API 검증도 참고할 만합니다.

이번 10문항에서 두 모델의 핵심 답변은 모두 10/10이었습니다. 이 결과만으로는 어느 한쪽이 전적으로 더 똑똑하다고 판단할 수 없습니다. 용도별로 정답률, 완수율, 형식 준수율을 확인할 필요가 있습니다.

핵심 정답률은 주요 수치나 결론이 올바른지를 평가합니다. 태스크 완수율은 이에 더해 지정된 설명이나 근거 등 모든 서브 요구사항을 충족했는지를 평가합니다. 올바른 답을 내놓더라도 일부 요구사항이 누락되었다면 완수한 것으로 판정하지 않습니다.

Opus 5의 어려운 확률 문제가 max_tokens=3200에서 중단되어 finish_reason=length가 되었기 때문입니다. 기댓값 12.6547과 상태 방정식은 정확했으나, 마지막에 요구된 설명이 누락되었습니다. GPT-5.6-SOL은 모든 서브 요구사항을 완료했습니다.

아니요. 핵심적인 확률 계산은 정확했으며, 기댓값은 12.6547이었습니다. 부족했던 점은 왜 기댓값을 단순히 1/P(HHTH)로 할 수 없는지에 대한 마지막 설명이었습니다.

수학적 또는 추론적 오류와는 별개로 다루어야 합니다. Opus 5가 계산한 JSON의 필드와 값은 정확했으나, JSON 이외의 문자열을 추가했기 때문에 엄격한 형식 요구사항을 위반했습니다. 더 정확하게는 형식 및 지시 준수(instruction following)의 실패입니다.

첫 시도에서는 GPT-5.6-SOL이 1/1, Opus 5가 0/1이었습니다. Opus 5는 추가로 2회 재시도했음에도 설명문이나 코드 펜스 (code fence)를 부가하여 엄격한 JSON 요구사항을 준수하지 못했습니다.

모델의 출력을 Python 파일로 저장하고 동일한 숨겨진 테스트를 실행했습니다. 경계 조건, 정렬 규칙, 잘못된 입력, 입력 객체의 불변성 등을 검사하였으며, 두 모델 모두 2/2로 합격했습니다.

엔드 투 엔드 (end-to-end) 대기 시간에는 네트워크 경로, 채널 부하, 캐시, 상류 인스턴스, 계정 제한 등이 영향을 미칩니다. 고정된 상류 환경에서 충분한 반복을 수행하지 않는 한 모델 자체의 추론 성능과 분리할 수 없으므로, 지능 점수에는 포함하지 않았습니다.

할 수 없습니다. 이번에는 재현 가능한 소규모 샘플입니다. 실제 도입 전에는 실제 업무 문제를 사용하여 20~50회 정도 반복하며 핵심 정답률, 태스크 완수율, 코드 테스트 합격률, 형식 위반율을 별도로 집계해야 합니다.

먼저 실제 업무에서 10~30건의 프롬프트 (prompt)를 선정하고, 각 문제에 대해 기계적으로 실행 가능한 합격 조건을 정의합니다. 그 후 동일한 API 조건으로 두 모델에 동일한 입력을 보내며, 답변 본문뿐만 아니라 finish_reason, 코드 테스트, JSON 파싱 결과도 저장합니다. 미리 결론을 정해두고 유리한 사례만 선택하는 방식은 피해야 합니다.

이번 검증을 단순한 모델 순위로 요약하는 것은 적절하지 않습니다. 확인된 사실은 다음과 같이 지표별로 정리할 수 있습니다.

Claude Opus 5와 GPT-5.6-SOL은 10문항의 핵심 답변에서 모두 10/10을 기록했습니다. 모든 서브 요구사항을 완료한 비율은 Opus 5가 9/10, GPT-5.6-SOL이 10/10이었습니다. Python 숨겨진 테스트는 두 모델 모두 2/2였습니다. 엄격한 JSON의 첫 제출은 Opus 5가 0/1, GPT-5.6-SOL이 1/1이었으며, Opus 5는 추가 2회의 재시도에서도 비준수였습니다.

정답이나 숨겨진 테스트를 준비할 수 있는 업무라면 두 모델 모두 후보에 포함할 수 있습니다. 반면, 다운스트림 시스템이 JSON을 직접 처리하는 경우에는 형식 검증, 재시도, 모델 전환을 필수 구성 요소로 설계해야 합니다.

또한, 긴 추론에서는 핵심 답변의 정확성뿐만 아니라 finish_reason

및 출력 상한(output limit)을 확인해야 합니다. 이번 max_tokens=3200 사례가 보여주듯, 올바른 정답이 포함되어 있더라도 태스크(task) 전체가 완료되었다고 단정할 수 없기 때문입니다.