Kimi K3 vs Claude Fable 5 vs GPT-5.6 Sol: 어떤 모델부터 테스트할까?

먼저 답하면, 많은 시도를 감당할 비용 여유가 가장 중요할 때는 Kimi K3부터, 도구 통합까지 포함한 균형 잡힌 기준이 필요할 때는 GPT-5.6 Sol부터 테스트하는 편이 합리적입니다. Claude Fable 5는 긴 작업에서 잘못된 설계 한 번이 큰 손실로 이어지는 경우를 위한 고가의 승격 경로로 두는 것이 좋습니다. 어느 모델도 공개 벤치마크 한 장만 보고 운영 트래픽으로 옮겨서는 안 됩니다.

2026년 7월 17일 현재 K3 API는 제공 중이지만, Kimi가 예고한 전체 가중치 공개일은 7월 27일입니다. 따라서 지금 당장 자체 호스팅할 수 있는 모델이라고 쓰면 안 됩니다. OpenAI API에서는 gpt-5.6 별칭이 현재 gpt-5.6-sol을 가리킵니다. 비교할 때 제품 이름뿐 아니라 실제 요청에 쓴 모델 ID도 고정해야 합니다.

같은 저장소 commit, 지시문, 도구 권한, 시간 제한, 추론 설정, 테스트와 검토 기준을 고정하십시오. 그 뒤 API 요금뿐 아니라 재시도 횟수, 지연, 검토 시간, 실패 복구까지 기록해야 합니다. 채택할 대상은 “가장 높은 종합 점수”가 아니라 같은 작업을 통과한 모델 중 총비용이 가장 낮고 데이터·운영 정책을 지키는 경로입니다.

점수보다 먼저 현재 API 조건을 맞춘다

세 모델 모두 긴 컨텍스트, 코딩, 에이전트 작업을 강조하지만 서로 바꿔 꽂을 수 있는 동일한 endpoint는 아닙니다. 가격, 최대 출력, 도구 표면, 긴 입력의 요금 변화, refusal, fallback, 데이터 보관, 향후 자체 호스팅 가능성이 다릅니다. 출력 품질이 비슷해도 이런 조건 하나가 실제 배포 결정을 바꿀 수 있습니다.

변동 사실의 소유자는 Kimi K3 발표, OpenAI Sol 모델 문서, Anthropic Fable 문서입니다. 위 가격은 직접 API 정가이며 소비자 구독의 사용량이나 제3자 router 가격이 아닙니다.

캐시되지 않은 입력 100K와 출력 20K를 쓰는 한 번의 호출을 계산하면 K3는 $0.60, Sol은 $1.10, Fable은 $2.00입니다. 도구, 재시도, 검토 전의 숫자이므로 K3를 첫 후보로 삼을 이유는 되지만 최종 작업까지 가장 싸다는 증거는 아닙니다. 저렴한 응답이 테스트에 실패하고 검토자가 의도부터 다시 만들어야 한다면 그 작업은 아직 승인되지 않았습니다.

Sol은 긴 입력의 요금 경계가 중요합니다. 270K와 275K는 크기가 비슷해 보이지만 뒤의 요청은 전체 요금 체계가 바뀝니다. 에이전트가 매 단계마다 전체 저장소, 도구 로그, 생성 파일을 컨텍스트로 돌려보내면 드문 예외가 평소 청구 방식이 될 수 있습니다. 명목상 1.05M 창만 보지 말고 입력 token의 p50, p95와 최대치를 기록해야 합니다.

Fable은 요금뿐 아니라 운영 계약도 다릅니다. Anthropic은 일부 거부가 HTTP 200과 stop_reason: refusal로 돌아올 수 있다고 설명합니다. fallback 설정은 실제 작업을 끝낸 모델을 바꿀 수도 있습니다. Fable과 Mythos 트래픽의 30일 보관 및 zero data retention 미지원은 민감한 저장소에서 품질과 무관한 중단 조건이 될 수 있습니다.

작업 유형별로 첫 테스트 대상을 고른다

반복량이 많고 약한 결과를 빠르게 버릴 수 있다면 K3부터 확인하십시오. 저장소 분류, 여러 구현 후보, 프런트엔드 반복, 자동 테스트로 일찍 탈락시킬 수 있는 일반 수정이 적합한 출발점입니다. 공개 예정 가중치는 락인과 자체 운영에 대한 새로운 선택을 만들지만, 파일·라이선스·메모리·추론 환경을 실제 공개 후 확인하기 전까지는 미래 옵션일 뿐입니다.

K3의 낮은 호출 가격이 재시도, 과도한 출력, 검토 부담으로 사라지면 일반 경로로 승격하지 마십시오. 같은 작업에서 Sol이 훨씬 적은 수정으로 통과하고 그 차이가 추가 API 비용보다 크다면 Sol로 바꿉니다. 비교 단위는 “첫 응답의 가격”이 아니라 “검토를 포함해 승인될 때까지의 가격”입니다.

중립적인 운영 기준이 필요하면 Sol부터 시작하십시오. OpenAI는 Sol을 GPT-5.6 플래그십 계층으로 두며 긴 컨텍스트, 128K 출력과 현재 도구 환경을 제공합니다. Codex를 이미 평가에 쓰는 팀에서는 결과가 모델만의 것이 아니라 파일 선택, 도구 호출, 컨텍스트 관리, 변경 확인을 수행하는 에이전트 환경의 것이기도 합니다.

Sol도 자동으로 최고의 가성비를 얻는 것은 아닙니다. 추론과 도구 루프가 출력량을 키우고 긴 요청은 전체 가격을 바꿉니다. K3보다 비싼 경로를 유지하려면 같은 작업의 승인율, 검토 시간, 운영 안정성이 가격 차이를 넘는지 측정해야 합니다. Codex에서 나온 결과를 다른 agent 환경의 결과와 그대로 섞어 읽지 마십시오.

Fable은 정의된 어려운 실패를 위한 승격 경로로 사용하십시오. 긴 저장소 변경, 원인이 모호한 디버깅, 여러 파일에 걸친 설계 변경, 잘못된 초기 판단이 전문가의 수 시간을 잃게 만드는 작업이 후보입니다. 높은 가격은 저렴한 경로가 놓친 작업을 반복해서 구하거나, 선임 검토 시간을 줄이거나, 큰 롤백을 막을 때만 정당화됩니다.

로그에는 요청한 모델과 실제 완료한 모델을 따로 저장하십시오. fallback으로 성공한 결과는 운영상 유용하지만 순수한 Fable이 혼자 작업했다는 증거는 아닙니다. 규제나 재현성이 중요하면 fallback을 끈 능력 평가와 실제 운영 설정을 쓴 평가를 분리하는 편이 안전합니다.

벤치마크 승자가 조건마다 달라지는 이유

코딩 평가 결과는 모델의 단일 속성이 아니라 다음 조합으로 보는 편이 정확합니다.

관측 결과 = 모델 + 에이전트 환경 + 추론 또는 token 예산 + 도구 + fallback + 테스트 설정

Kimi 발표표의 각주는 이 문제를 잘 보여 줍니다. 일부 평가에서 K3는 KimiCode, Fable은 Claude Code 또는 Terminus와 fallback, Sol은 Codex를 사용합니다. 모델 이름만 한 열에 모아도 실제 실행 조건이 같지 않은 행이 들어 있습니다.

이 표는 Kimi가 소유한 비교이며 중립적인 종합 순위가 아닙니다. 여기서 얻을 수 있는 결정 정보는 한 모델이 언제나 이긴다는 결론이 아니라 작업과 실행 환경이 바뀌면 승자도 바뀐다는 점입니다.

독립 종합 평가도 전체 설정 이름과 함께 읽어야 합니다. 2026년 7월 17일 Artificial Analysis는 Intelligence Index v4.1에서 K3를 57, Sol Max를 59, Fable을 60으로 표시했습니다. 다만 Fable의 표기 설정은 “Adaptive Reasoning, Max Effort, Opus 4.8 Fallback”입니다.

1점 차이보다 fallback, agent 환경, token 사용량, 평가 비용이 더 실무적입니다. Fable의 표시 점수에는 fallback이 있고 Sol의 코딩 결과는 Codex 환경과 묶이며 K3는 이 평가에서 두 경쟁 모델보다 많은 출력 token을 사용했습니다. 어느 관측도 자체 저장소의 승인율을 대신해 주지 않습니다.

토큰 가격이 아니라 승인 작업의 총비용을 계산한다

승인된 작업은 자동 검사와 팀의 검토 기준을 통과한 출력입니다. 가격표를 실제 결정으로 바꾸려면 다음 식을 씁니다.

승인 작업 총비용 = (시도당 API + 도구 + 인프라) ÷ 승인율 + 검토 시간 + 실패 복구 기대비용

승인율은 같은 작업 집합에서 측정해야 합니다. K3에는 쉬운 작업, Fable에는 어려운 작업을 주거나 Sol만 캐시된 상태로 실행하면 비교가 무너집니다. 공급자가 실패 요청을 청구하지 않아도 도구 실행, 대기, fallback 트래픽, 엔지니어의 주의는 비용으로 남습니다.

미캐시 입력 100K와 출력 20K의 가상 작업을 보겠습니다. API 시도 가격은 K3 $0.60, Sol $1.10, Fable $2.00입니다. 이제 계산법을 보이기 위해 승인율을 80%, 90%, 94%, 검토 시간을 8분, 6분, 5분, 내부 인건비를 시간당 $60으로 가정합니다. 이 수치는 모델의 실제 성능 주장이나 실측 결과가 아닙니다.

이 예는 계산 구조만 보여 줍니다. 낮은 token 가격도 반복과 검토가 늘면 총비용에서 질 수 있습니다. 고가 모델도 실제 개선 폭이 가정보다 작으면 쉽게 손해가 됩니다. 승인율, 검토 분, 중대한 실패의 복구비용을 팀 데이터로 바꾸십시오. 공급자별 요금, batch 할인, router 비용과 월간 예산은 LLM API 가격 비교에서 확인하고, K3·Sol·Fable의 작업 선택과는 분리해 계산하십시오.

같은 저장소에서 재현 가능한 평가를 실행한다

운영 이전에 작업 집합을 고정해 모델 외의 변수를 줄입니다. 평가 규모가 작아도 각 경로가 어디서 깨지는지 드러낼 수 있어야 합니다.

1. 하나의 고정 commit에서 30~50개 대표 작업을 고릅니다. 일반 수정, 여러 파일 변경, 버그 진단, 도구 실패, 긴 컨텍스트, 선임 검토가 필요했던 어려운 사례를 포함합니다.
2. system 지시, 도구 권한, network 정책, sandbox, timeout, 저장소 상태를 같게 하고 agent 환경과 version을 기록합니다.
3. 각 경로에 추론 또는 token 예산을 문서화합니다. Adaptive thinking, max effort, fallback을 쓴다면 모델 이름에 숨기지 말고 결과 열에 표시합니다.
4. 실행 전에 승인 조건을 정합니다. build, test, lint, type check, security check, 작업별 assertion, 변경 가능 파일, 검토 rubric을 고정합니다.
5. 가능하면 사람의 검토를 blind 처리합니다. 승인 여부, 재시도, 입출력 token, 실제 시간, 도구 오류, 검토 분, 롤백이 필요한 회귀를 기록합니다.
6. 안정적인 일부 작업을 다른 날에 다시 실행합니다. 출시 직후의 용량과 routing이 한 시간짜리 결과를 왜곡할 수 있기 때문입니다.

모델마다 이길 때까지 서로 다른 시험으로 조정하면 안 됩니다. 공정한 운영 구성을 위해 모델별 설정이 필요할 수 있지만 추가 prompt, 컨텍스트 축약, reasoning effort, fallback, retry 정책을 모두 남겨야 합니다. 조건을 재현할 수 없다면 다음 달 재평가나 장애 복구 때 비교 자체를 다시 만들 수 없습니다.

평가는 네 질문을 나눠 답해야 합니다. 일반 작업을 가장 낮은 총비용으로 통과하는 모델은 무엇인가. 기본 경로가 놓친 어려운 작업을 구하는 모델은 무엇인가. 실패가 모델 때문인가 agent와 tool 환경 때문인가. 가격 경계, fallback, refusal, 보관, 향후 자체 호스팅 중 어떤 조건이 배포 범위를 바꾸는가입니다.

이전 Kimi 통합을 옮기는 중이라면 과거 모델 ID와 경로 전환은 Kimi K2 API 모델 가이드를 참고하십시오. K2에서 K3로 옮기는 문제와 K3·Sol·Fable의 품질 비교를 같은 실험에 섞으면 원인을 구분하기 어려워집니다.

승격·유지·롤백 조건을 미리 정한다

K3를 일반 경로로 승격하려면 중대한 회귀가 없고 Sol 대비 승인율 차이가 합의한 범위 안이며 재시도와 검토 뒤에도 의미 있는 절감이 남아야 합니다. 복잡도 기준을 넘는 작업에는 Sol 또는 Fable을 남기고 모든 트래픽을 한 번에 이동하지 마십시오.

Sol을 기본으로 유지하려면 K3보다 승인율이나 검토 시간을 실질적으로 개선하고 도구 경로가 안정적이며 272K 초과 가격까지 포함해도 이득이 남아야 합니다. 전체 트래픽에 Fable 비용을 내는 대신 정의된 어려운 작업만 승격하는 편이 저렴할 수 있습니다.

Fable로 승격할 조건은 정해 둔 실패 유형을 구하거나 선임 검토를 충분히 줄이는 것입니다. fallback 사용 여부를 반드시 기록하십시오. 보관 정책과 맞지 않는 데이터에서는 성능이 좋아도 해당 경로를 중단해야 합니다.

이전을 보류할 조건은 차이가 반복되지 않거나 설정이 비교 가능하지 않거나 겉보기 승자가 새로운 실패를 만들 때입니다. 결과가 비슷하고 운영 조건이 불명확하다면 현재 시스템을 유지하는 것이 안전합니다.

롤백할 조건은 중대한 회귀가 기준을 넘거나 승인 작업 총비용이 baseline보다 높아지거나 p95 latency가 SLO를 깨거나 tool failure가 집중되거나 보관·fallback 정책을 위반할 때입니다. 새 경로가 모니터링된 production slice를 통과할 때까지 이전 경로와 평가 corpus를 보존하십시오.

K3는 7월 27일 이후 별도 확인이 필요합니다. 실제 가중치 공개, 라이선스, 메모리, serving 조건을 확인하고 목표 inference stack에서 같은 작업을 다시 실행하십시오. 파일을 받을 수 있다는 사실은 자체 호스팅 평가의 시작 조건이지 Kimi 호스팅 API와 같은 속도와 비용을 보장하는 결론이 아닙니다.

자주 묻는 질문

Kimi K3가 Fable 5와 GPT-5.6 Sol보다 전반적으로 더 좋은가요?

아닙니다. K3는 현재 직접 API 가격이 가장 낮고 Kimi 공개표 일부에서 앞서지만 Sol과 Fable이 앞서는 행도 있습니다. agent 환경, 추론 설정, fallback, token 사용량과 작업이 결과를 바꿉니다. K3는 경제적인 첫 후보이지 무조건적인 종합 우승자가 아닙니다.

Kimi K3 가중치를 지금 자체 호스팅할 수 있나요?

2026년 7월 17일에는 아닙니다. Kimi는 전체 가중치를 7월 27일 공개할 예정이라고 안내합니다. 공개 후에도 라이선스, 메모리, 추론 환경, 자체 작업의 품질과 비용을 확인해야 운영 옵션이라고 부를 수 있습니다.

Claude Fable 5의 높은 가격이 가치 있는 때는 언제인가요?

어려운 장기 작업에서 실패, 재시도, 선임 검토를 줄이는 측정된 효과가 $10 입력·$50 출력의 차이를 넘을 때입니다. 동시에 refusal, fallback, 30일 보관과 ZDR 미지원이 작업 정책에 맞아야 합니다.

GPT-5.6 Sol이 세 모델 중 가성비가 가장 좋은가요?

Codex나 OpenAI 도구 환경을 평가에 포함하는 팀에는 강한 기준 후보입니다. 그러나 자동으로 최저 총비용은 아닙니다. 272K 초과 입력은 요청 전체 요금을 바꾸며, 같은 작업을 충분히 통과하는 K3가 더 저렴할 수 있습니다.

코딩 작업은 어떤 모델부터 시작해야 하나요?

내부 데이터가 없다면 Sol을 기준으로 잡고 일반 작업에서 K3를 비교하며 가장 어려운 실패만 Fable에 보내는 구조가 이해하기 쉽습니다. 예산이 절대 조건이면 K3부터 시작하고 같은 저장소에서 승인율이나 검토 시간이 부족할 때만 Sol로 이동하십시오.

오래 유지되는 답은 모델 이름이 아니라 routing rule입니다. 가장 저렴한 현실적 후보부터 시작하고 같은 작업에 합격한 뒤 승격하며 정의된 어려운 사례만 상위 경로로 보내고 언제든 기존 경로로 돌아갈 수 있게 하십시오.