Claude Opus 5와 Claude Fable 5 중 어느 것을 선택해야 할까요? 성공한 단 한 번의 답변만 본다면, 두 모델 모두 그럴싸한 수학적 유도를 작성할 수 있습니다. 하지만 실제 운영 환경에서의 경험을 좌우하는 것은 대부분 그와는 다른 세 가지 요소입니다. 태스크를 안정적으로 완료할 수 있는가, 레이턴시(Latency)가 대화 용도에 적합한가, 실패 후 자동으로 복구할 수 있는가입니다.

우리는 2026년 7월 25일, 동일한 OpenAI-compatible API를 사용하고 동일한 프롬프트와 파라미터로 두 모델에 대해 7가지 종류의 태스크를 테스트했습니다. 결과는 "모델이 클수록 항상 우월하다"는 단순한 이야기로 끝나지 않았습니다.

claude-fable-5는 두 모델이 모두 성공한 태스크에서는 더 빨랐으며, 출력도 간결했습니다. -
claude-opus-5는 최종적으로 7가지 모든 태스크를 커버했습니다. - Fable 5는 일반적인 코드 리뷰와 인시던트 JSON 프롬프트에서 연속적으로 content_filter를 발생시켰습니다. - Opus 5는 물리 문제에서 처음 2회는 HTTP 200을 반환했음에도 불구하고, 무관한 인사를 한 문장 반환했을 뿐이며, 3회째에야 비로소 정상적으로 완료되었습니다.

즉, 운영 환경에서의 모델 선정은 단 하나의 모델 ID에만 의존해서는 안 됩니다. 더 견고한 방법은 먼저 태스크 유형별로 주 모델을 선택하고, 그 위에 내용 검수, 재시도(Retry), 모델 폴백(Fallback)을 통해 이상 계통을 감싸는 방법입니다.

테스트 전에 모델 목록 API를 호출하여 두 개의 정확한 모델 ID가 보이는 것을 확인했습니다.

GET https://cn.crazyrouter.com/v1/models
claude-opus-5
claude-fable-5

모든 정식 요청은 동일한 endpoint를 사용했습니다.

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

공통 조건은 다음과 같습니다.

동일 system prompt
동일 user prompt
temperature = 1
...

공통 system prompt는 정확하게 답변하고 지정된 출력 형식을 따를 것만을 요구합니다. 특정 모델에 유리한 역할(Role) 설정은 추가하지 않았습니다.

Answer the user's task accurately. Follow every requested output format and length constraint exactly. Do not use external tools.

기록한 것은 최종적인 본문뿐만이 아닙니다. 다음 사항들도 기록했습니다.

• HTTP 상태 코드와 finish_reason
• response ID와 returned model
• 첫 번째 가시적 토큰(Token)까지의 시간과 총 레이턴시(Latency)
• completion tokens, reasoning tokens
• 가시적 답변이 태스크의 검수 조건을 만족했는지 여부
• 이상 요청이 동일 파라미터의 재시도로 복구 가능한지 여부

이는 Crazyrouter 게이트웨이의 엔드투엔드(End-to-End) 테스트이며, 단일 상류 채널을 지정한 실험이 아닙니다. 따라서 결과에는 모델의 동작, 상류의 필터링, 게이트웨이의 라우팅, 그 시점의 채널 상태가 동시에 반영되어 있습니다. "사용자가 이 API를 통해 실제로 무엇을 마주하게 될 것인가"를 답하기에는 적합하지만, Claude 제품군의 순수한 오프라인 능력 랭킹으로 취급해서는 안 됩니다.

모델 테스트에서 finish_reason과 출력 예산을 기록해야 하는 이유를 알고 싶다면, Claude Fable 5 vs GPT-5.5의 max_tokens 재테스트도 참조하십시오.

본 테스트에서의 1회차 납품률은 다음과 같습니다.

Claude Opus 5: 6 / 7 = 85.7%
Claude Fable 5: 5 / 7 = 71.4%

재시도 (Retry)를 포함하면 다음과 같습니다.

Claude Opus 5: 7 / 7
Claude Fable 5: 5 / 7

여기서 말하는 "납품"은 요청의 성공이 아니라, 업무 측에서 문제 요건을 충족하는 가시적인 답변을 받았음을 의미합니다. HTTP 200, 모델명, 토큰 사용량 (token usage)이 존재하더라도, 본문이 비어 있거나, 필터링되었거나, 인사말만 반환된 경우에는 태스크 실패로 처리합니다.

수학 문제에서는 3상태 마르코프 연쇄 (Markov Chain)를 사용하여, 상태 1에서 처음으로 상태 3에 도달할 때까지의 대기 시간에 대해 다음을 계산하도록 요청했습니다.

E1[τ]
E1[τ²]
Var1(τ)

두 모델 모두 다음을 반환했습니다.

E1[τ] = 5
E1[τ²] = 43
Var1(τ) = 18

또한, 양쪽 모두 일시 상태 행렬 (Transient State Matrix) Q와 1차·2차 모멘트 방정식을 작성했습니다. 이 문제에서는 "최종 수치는 맞지만 도출 과정이 일관되지 않은" 상황은 발생하지 않았습니다.

제약 탐색 (Constraint Satisfaction)에서는 A, B, C, D, E의 5개 강연을 5개의 시간대에 배치하며, 직후 인접, 전후 관계, 간격, 비인접 등의 조건을 동시에 만족하도록 요청했습니다. 둘 다 유일한 순서를 얻었습니다.

A, C, E, B, D

통계 오류 수정 문제에서는 의도적으로 잘못된 결론을 제시했습니다. "평균이 10, 분산이 4이므로 P(X≥14)=0.5"라는 내용입니다. 두 모델 모두 2차 모멘트까지만으로는 꼬리 확률 (Tail Probability)을 유일하게 결정할 수 없다고 지적하며, 단측 체비쇼프/칸텔리 부등식 (One-sided Chebyshev/Cantelli Inequality)을 통해 다음을 얻었습니다.

P(X >= 14) <= 0.2

이 세 가지 태스크를 통해 알 수 있는 점은, Fable 5의 속도 측면의 우위가 기초적인 추론의 정확성을 희생한 결과가 아니라는 것입니다. 명확하고 짧으며 검수가 용이한 수학·논리 태스크에서는 더 가벼운 제1 후보로서 충분히 사용할 수 있습니다.

이전의 Claude Fable 5 vs Claude Sonnet 5 API 테스트와 GLM-5.2 vs Fable 5 출력 예산 테스트에서도 보여주었듯이, 특정 모델이 운영에 적합한지 판단하려면 정확성, 출력 예산, 납품 형태를 종합적으로 고려해야 합니다.

물리 문제에서는 접지 감쇠 (Grounding Damping)와 결합 감쇠 (Coupling Damping)를 가진 2자유도 진동자 (2-DOF Oscillator)를 다루며, 두 개의 비감쇠 고유 진동수와 ω=8 rad/s에서의 두 질량의 복소 주파수 응답 (Complex Frequency Response)을 계산하도록 요청했습니다.

참조값은 다음과 같습니다.

ω1 = 10.0204 rad/s
ω2 = 16.2149 rad/s
|X1| = 0.14929 m, phase = -12.15°
...

Fable 5는 첫 시도에서 모든 올바른 결과를 반환했습니다. 반면, Opus 5의 초기 2회 호출에서는 운영 팀이 특히 주의해야 할 이상 현상이 발생했습니다. 인터페이스는 HTTP 200과 finish_reason=stop을 반환했지만, 본문은 다음 한 문장뿐이었습니다.

Hi! How can I help you today?

이 두 번의 응답에서는 프롬프트 토큰 (prompt tokens)이 모두 10이었으며, 실제 입력과는 명백히 일치하지 않았습니다. 동일한 요청을 3회차에 실행했을 때, Opus 5는 34.901초 후에 완전한 답변을 반환하였고, 6개의 수치는 모두 검증을 통과했습니다.

따라서 이러한 종류의 이상 현상은 "물리 문제를 계산 실수했다"라고 분류할 것이 아니라, "요청 컨텍스트 (Request Context)가 정상적으로 처리되지 않았다"라고 분류해야 합니다. 가장 간단한 방어책은 사람이 로그를 확인하는 것이 아니라, 호출 측에서 태스크 수준의 검수 (Acceptance)를 설정하는 것입니다. 답변에 ω1, ω2, X1, X2가 포함되어 있지 않으면 재시도 (Retry)합니다.

코드 문제에서는 Python의 DFS 사이클 검출기 (DFS Cycle Detector)를 리뷰하게 했습니다. 버그는 매우 일반적인 것입니다. 노드의 DFS 완료 후에 visiting 집합에서 삭제하지 않았기 때문에, 이미 처리된 노드가 여전히 재귀 스택 (Recursion Stack) 위에 있다고 오인하여, DAG (Directed Acyclic Graph)에 대해 사이클을 오검출합니다.

Opus 5는 최소한의 수정을 정확하게 지적했습니다.

visiting.discard(node)
visited.add(node)
return False

Fable 5는 코드 분석을 반환하지 않았으며, finish_reason=content_filter로 본문이 비어 있었습니다. 시스템 프롬프트 (System Prompt)의 편향이나 우발적인 라우팅 (Routing)을 제외하기 위해 3회 확인했습니다. 원래의 테스트, 깨끗한 시스템 프롬프트에서의 재테스트, 단독 문제로서의 독립적인 재시도 모두 결과는 content_filter였습니다.

엄격한 JSON 문제에도 위험한 내용은 포함되어 있지 않았습니다. 입력에는 15분간의 요청 총수, 실패 수, 채널별 요인, 재시도로 복구된 수, 대응 액션만 포함되어 있었으며, 출력으로 JSON 객체를 요구했습니다. Opus 5가 반환한 JSON은 그대로 파싱할 수 있었지만, Fable 5는 마찬가지로 연속 3회 필터링되었습니다.

이 두 종류의 실패가 보여주는 것은, 안전 필터링 (Safety Filtering) 그 자체도 모델 API의 프로덕션 능력의 일부라는 점입니다. 일반적인 코드 리뷰나 인시던트 회고 텍스트에서 안정적으로 오필터링이 발생한다면, 설령 수학 문제에서 속도가 빠르더라도 모든 업무 트래픽을 해당 모델에 맡길 수는 없습니다.

두 번의 독립적인 재시도 Response ID는 다음과 같습니다.

코드 리뷰: gen-1784915384-vGI1PtuNXZG0IJ2YiaCz
인시던트 JSON: gen-1784915390-buOWZQSnqjgHeJ6nUogF

실패한 요청의 짧은 처리 시간을 "속도 우위"로 계산하지 않기 위해, 여기서는 두 모델이 모두 성공한 4개의 공통 태스크, 즉 수학, 제약 탐색 (Constraint Search), 통계 오류 수정, 실험 설계만을 비교합니다.

이 작은 샘플에서 Fable 5의 P50 총 레이턴시는 약 24% 낮았고, 첫 번째 가시적 토큰 (Visible Token)은 약 17% 빨랐으며, 답변은 약 43% 짧아졌습니다. 채팅, 배치 요약 (Batch Summarization), 고빈도 구조화 태스크에서는 이러한 차이가 사용자의 대기 시간과 다운스트림 (Downstream) 처리량에 직접적인 영향을 미칩니다.

단, 4개 문제의 중앙값을 SLA (Service Level Agreement)로 작성해서는 안 됩니다. 상류의 부하, 캐시, 라우팅, 속도 제한 (Rate Limit)은 모두 레이턴시를 변화시킵니다. 프로덕션 투입 전에는 자사의 업무 프롬프트로 20~50회 반복하여 P50, P95, P99 및 검수를 통과한 결과 1건당 실제 비용을 집계해야 합니다.

Fable 5의 본 테스트 응답에는 cost 필드가 있으며, 7회의 합계는 약 $0.24596이었습니다. Opus 5의 사용량 (Usage)에는 동일한 기준의 cost가 제공되지 않았기 때문에, 본 기사에서는 달러 가격으로 승패를 판단하지 않습니다. 필드가 없다는 것이 무료를 의미하지는 않으며, 검증되지 않은 가격으로 보완해서도 안 됩니다.

단일 모델 호출은 구현하기 가장 쉬운 반면, 모델의 모든 우발적인 동작을 그대로 엔드 유저 (End User)에게 노출시킵니다. 이번 두 모델에 대해서는 다음과 같이 역할을 나누는 것이 더 합리적입니다.

적합한 용도:

• 회귀 테스트가 완료된 수학, 제약 추론, 짧은 요약
• 첫 번째 토큰과 전체 레이턴시에 민감한 대화
• 답변 길이를 억제하고 후처리 부하를 줄이고 싶은 태스크

전제 조건으로, 대상 태스크군에 대해 필터링 테스트가 완료되어 있어야 하며, 호출 측에서 content_filter, 빈 본문, 필수 필드 누락을 체크해야 합니다.

적합한 용도:

• 입력 타입이 예측하기 어려운 경우
• 코드 리뷰, 엄격한 JSON (Strict JSON), 복잡한 물리 등 더 넓은 태스크 커버리지 (Task Coverage)가 필요한 상황
• Fable 5가 필터링된 후, 사용자 요청을 자동으로 복구하고 싶은 상황

Opus 5 또한 검수 없이 사용해서는 안 됩니다. 이번 인사말 이상 현상이 보여주듯, HTTP 200과 stop 상태라 하더라도 업무에 필요한 답변이 포함되어 있지 않을 수 있습니다.

다음 예시에서는 먼저 Fable 5를 호출하고, 필터링, 빈 본문, 검수 실패가 발생할 경우 Opus 5로 폴백 (Fallback)합니다. Opus에서도 인사말만 반환하는 경우에는 한 번 더 재시도(Retry)합니다.

from openai import OpenAI
client = OpenAI(
api_key="YOUR_API_KEY",
...

실제 운영 환경(Production) 구현 시에는 모델(model), 응답 ID(response ID), finish_reason, 총 레이턴시 (Latency), 검수 실패 이유를 추가로 기록해야 합니다. 그렇게 함으로써 모델의 계산 실수, 출력 중단, 내용 필터링, 라우팅으로 인한 입력 누락을 구분할 수 있습니다. 이 모든 것을 단순히 모호한 "모델 실패"로 묶어서는 안 됩니다.

멀티 모델 기반을 계획하고 있다면, AI API Gateway, 애그리게이터 (Aggregator), 모델 API 직결의 차이점과 Kimi K3 vs Opus 4.8의 7차원 테스트도 참고가 될 것입니다.

이번에 얻은 가장 가치 있는 결론은 어느 모델이 더 높은 점수를 받았느냐가 아니라, 두 모델의 실패 형태가 다르다는 점입니다.

• Fable 5의 강점은 공통 태스크에서 더 빠르고 짧다는 것입니다. 리스크는 일부 일반적인 업무 프롬프트가 안정적으로 필터를 발생시킨다는 점입니다.
• Opus 5의 강점은 재시도 후에 모든 태스크를 커버했다는 것입니다. 리스크는 실제 입력과 무관한 인사말을 우연히 반환한다는 점입니다.

따라서 검증된 고빈도 태스크에서는 Fable 5를 전단에 배치하고, Opus 5를 더 광범위한 폴백 (Fallback)으로 사용하며, 양쪽 경로 모두에서 내용 수준의 검수를 수행할 것을 권장합니다. 그래야만 모델 비교 결과를 단순한 순위가 아닌 실제 신뢰성으로 전환할 수 있습니다.

이 작은 샘플만으로 "모든 태스크에서 더 강력하다"라고 결론 내릴 수는 없습니다. 수학, 제약, 통계의 오류 수정, 실험 설계에서는 둘 다 합격했습니다. Fable 5는 더 빠르고 짧았으며, Opus 5는 태스크 커버리지가 더 완전했습니다. 선택은 모델명이 아니라 구체적인 태스크 성공률에 기반하여 이루어져야 합니다.

회귀 테스트 (Regression Test)가 완료된 태스크에는 적합합니다. 이번에 여러 추론 태스크에서는 정확하고 비교적 빨랐으나, 코드 리뷰와 인시던트 JSON에서는 연속적으로 필터를 발생시켰습니다. 실제 운영 투입 전에는 실제 프롬프트로 필터율을 측정하고, Opus 5 또는 다른 모델로의 폴백을 설정해야 합니다.

HTTP 200은 인터페이스가 응답을 완료했음을 나타낼 뿐입니다. 본문이 비어 있거나, finish_reason=content_filter, 출력이 중간에 끊기거나, 인사말만 반환하는 경우 업무 태스크는 완료된 것이 아닙니다. 운영 지표에서는 HTTP 성공률뿐만 아니라 "검수 통과율"을 집계해야 합니다.

요청 시에는 claude-fable-5를 사용하였으며, 응답 내의 returned model은 프로바이더 (Provider) 접두사가 붙은 anthropic/claude-fable-5로 안정적이었습니다. 이는 정규화된 에일리어스 (Alias)로 간주할 수 있습니다. 접두사의 변화만으로는 모델이 교체되었다는 증거가 되지 않습니다.

이번 결과만으로는 판단할 수 없습니다. Fable 5의 응답에는 cost 필드가 있었지만, Opus 5에는 동일한 기준의 필드가 없었습니다. 엄격한 비용 비교는 통합된 과금 로그에서 가져와야 하며, "검수를 통과한 결과 1건당 비용"을 지표로 삼아야 합니다.

각 핵심 태스크 그룹에 대해 최소 20~50회의 반복을 권장합니다. 일반적인 입력, 경계값 입력 (Boundary Input), 긴 입력, 필터를 유발하기 쉬운 입력을 포함하십시오. 최소한 태스크 성공률, 필터율, 빈 본문율, 중단율, P50/P95/P99 레이턴시, 비용을 기록해야 합니다.

https://cn.crazyrouter.com/v1을 OpenAI 호환 베이스 URL (OpenAI-compatible base URL)로 사용하고, claude-opus-5와 claude-fable-5

를 각각 호출합니다. 프롬프트와 파라미터 (parameter)를 고정하고, 원본 응답 (response)을 저장한 뒤, 로컬 어설션 (assertion) 또는 구조 검증 (structural verification)을 통해 태스크가 실제로 완료되었는지 판정합니다.