OpenRouter Fusion: 모델 3개를 묶어 Claude Fable 5를 절반값에 1% 차이로 추격

OpenRouter가 6월 중순 Fusion을 공개했다. 하나의 모델을 호출하는 대신, 같은 프롬프트를 기본 3~5개 모델에 동시에 던지고 판정 모델이 그 답들을 하나로 합성하는 API다.

핵심 수치가 인상적이다. 저가 패널인 Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro 조합이 단일 GPT-5.5와 단일 Claude Opus 4.8을 모두 앞섰다. 그리고 현재 가장 비싼 축인 Claude Fable 5와의 점수 차이는 1% 이내(벤치마크 64.7% 대 65.3%), 그런데 비용은 Fable 5의 약 절반이었다.

한눈에 보기

패널 모델: 기본 3~5개 병렬 호출, 웹 검색·웹 페치 활성화
성능: 저가 패널이 Fable 5 대비 1% 차이(64.7% vs 65.3%)
비용: 동급 성능을 단일 최강 모델의 약 절반 값에
과금: 패널 멤버 전부 + 판정 호출의 누적 토큰 합산

합의가 단일 모델보다 강한 이유

Fusion의 작동은 단순하다. 프롬프트가 들어오면 서로 강점이 다른 모델들이 병렬로 답을 만든다. 그다음 판정 모델이 그 답들을 비교해 합의, 모순, 부분적으로만 맞는 부분, 한 모델에만 있는 통찰, 공통의 맹점을 구조화한 뒤 최종 답을 다시 쓴다.

이건 새 모델을 훈련한 게 아니다. 이미 있는 모델들을 조합하는 오케스트레이션 레이어다. 한 모델이 틀린 자리를 다른 모델이 메우고, 판정 단계가 그 차이를 골라낸다. 단일 모델 하나에 모든 걸 거는 베팅을 분산한 셈이다.

흥미로운 지점은 비싼 모델을 안 써도 된다는 데 있다. 중급·저가 모델 여러 개의 합의가, 한 개의 최고가 모델보다 잘 나올 수 있다는 걸 수치로 보여줬다.

비용 구조: 함정이자 기회

과금은 정직하지만 무겁다. 패널에 4개 모델을 넣으면 4번의 완성 비용에 판정 호출 비용까지 더해 누적 합산으로 청구된다. 한 번의 요청이 다섯 번의 요청 값이 될 수 있다.

그럼에도 절반값이 나오는 이유는 패널을 저가 모델로 짤 수 있기 때문이다. 단일 Fable 5 한 방보다, 저가 모델 셋에 판정 한 번을 합친 묶음이 더 싸면서 비슷한 품질을 낸다. Quality 프리셋과 Budget 프리셋으로 이 균형을 조절하고, 판정 모델도 직접 지정할 수 있다.

여기서 갈린다. 모든 요청을 Fusion으로 돌리면 토큰 비용이 폭증한다. 하지만 품질이 결과를 좌우하는 소수의 핵심 작업, 가령 계약서 검토, 투자자 자료 초안, 고객 응대 카피의 최종본에만 Fusion을 붙이면, 비싼 단일 모델보다 싸게 더 나은 결과를 얻는다.

1인 팀에게 무엇이 바뀌나

지금까지 인디 메이커와 AI 우선 팀의 고민은 "어느 모델에 베팅할 것인가"였다. 모델은 분기마다 순위가 뒤집힌다. 한 곳에 묶이면 다음 분기에 손해를 본다.

Fusion은 그 질문 자체를 비튼다. 모델을 고르는 대신 묶는다. 특정 벤더에 종속되지 않고, 어느 한 모델의 품질이 떨어져도 패널 전체가 받쳐준다. 1인 SaaS 개발자가 직접 라우팅 로직과 판정 파이프라인을 짜던 일을, API 한 줄로 대체할 수 있다는 뜻이다.

물론 비용 통제는 본인 몫이다. 모든 호출을 합의로 돌리는 순간 청구서가 다섯 배가 된다. 어디에 합의를 쓰고 어디에 단일 모델로 충분한지를 가르는 판단, 그게 새로운 실력이 된다.

anyAX 관점

어느 모델에 베팅할 것인가. 분기마다 순위가 뒤집히는 시장에서 이 질문은 늘 함정이었고, Fusion은 질문 자체를 무효로 만든다. 모델은 빌려 쓰는 인프라이고, 어느 한 벤더에 묶이는 순간 다음 분기에 손해를 본다는 게 핵심이다. 저가 패널 셋의 합의가 Fable 5를 1% 차이로 따라잡고 비용은 절반이라면, 단일 최강 모델에 묶일 이유가 사라진다.

인프라가 평준화되면 가치는 그 위에서 난다. 3~5개 모델을 동시에 던지면 청구서가 다섯 배로 뛰는 구조이므로, 모든 호출을 합의로 돌리는 건 어리석다. 계약서 검토, 투자자 자료 초안, 고객 응대 카피의 최종본처럼 품질이 결과를 좌우하는 길목에만 Fusion을 붙이고 나머지는 싼 단일 호출로 끝내는 것, 그 라우팅 설계가 곧 인디 메이커의 실력이 된다.

API 한 줄이 직접 짜던 판정 파이프라인을 대체하는 시대에, 1인 SaaS 개발자가 쥐는 레버는 모델을 고르는 손이 아니라 비용을 어디에 쓸지 가르는 머리다. 도구가 한 칸 더 좋아졌다고 격차가 벌어지지 않는다. 같은 도구를 어느 길목에 끼워 넣을지 아는 쪽이 벌린다.