최고 모델 하나 고르는 시대는 끝났어요

”제일 잘하는 모델” 이라는 질문이 이제 안 먹혀요

지난주에 Show HN에 Echo라는 프로젝트가 올라왔어요. GLM-5.2, Kimi K2.7 같은 오픈웨이트 모델 여러 개를 풀에 넣어두고, 요청마다 어떤 모델을 얼마나 태울지 동적으로 결정하는 라우터예요. 제작자 주장으로는 자체 평가 믹스에서 Fable(Claude 최신 모델) 수준의 벤치 총점을 약 1/3 비용에 냈다고 해요.

숫자는 자가 평가라 아직 3자 검증이 없어요. 그래도 눈에 들어온 건 접근 방식이에요. Echo의 성패와 무관하게, 이 방향이 다음 12개월 프로덕션 AI 아키텍처의 기본값이 될 가능성이 큽니다.

이제 질문은 “어떤 모델이 제일 세냐” 가 아니라 “요청별로 어떤 모델에 얼마나 태울까” 로 바뀌었어요.

Oracle 실험이 알려준 것

Echo 제작자가 먼저 해본 실험이 흥미롭습니다. 오픈웨이트 모델 여러 개를 준비해 같은 문제에 모두 돌리고, “만약 정답을 미리 알고 매 문제마다 최적 모델을 고를 수 있다면” 이라는 가상의 시스템을 만들었어요. Oracle이라고 부르죠.

예상대로 Oracle은 어떤 개별 모델보다 훨씬 잘했어요. 다만 결과를 본 뒤에야 최적을 고를 수 있으니 배포는 불가하죠.

여기서 중요한 건 다음입니다. Oracle과 최강 단일 모델의 간격이 꽤 컸다는 점이에요. 즉, 단일 모델 하나로 버티고 있다면 지금도 적잖은 성능을 테이블 위에 두고 있는 셈입니다. 문제만 잘 분리해 태스크-모델 매칭을 할 수 있다면요.

새 이야기도 아니에요. Random Forest가 왜 강한지, Kaggle 상위권이 늘 앙상블을 쓰는지와 같은 원리죠. 약한 학습기 여러 개가 강한 학습기 하나를 이긴다. LLM에서도 이 원리가 실제로 작동하기 시작했어요.

약한 모델이 특정 구간에선 최강이에요

Echo 제작자가 언급한 대목입니다. “전체적으로 약한 모델이 특정 문제나 조합의 일부에서는 극도로 유용할 수 있다.”

우리 상황에 대입해볼게요. 사내에서 사양서(spec) 검토 에이전트를 만든다고 가정하면, 내부에는 여러 서브태스크가 있어요.

• CAD 도면 PDF에서 치수 뽑아내기 → 시각·수치 정확도가 관건
• 구조 계산 서술 검증 → 수학 추론
• KS 기준 대비 조항 매칭 → 도메인 텍스트 이해
• 최종 리포트 산문 요약 → 자연스러운 국문 서술

GPT-5나 Claude Opus 하나로 다 처리하면 편하긴 해요. 하지만 마지막 산문 요약 때문에 앞의 모든 서브태스크까지 최상위 모델 단가를 적용받는 꼴이 됩니다. 산문 요약은 더 저렴한 오픈웨이트 모델로도 충분히 가능하거든요.

그래서 라우팅이 필요합니다. 요청을 뜯어 파트별로 다른 모델에 자동 배분하는 방식이죠.

동적 컴퓨트 할당 — “쉬운 건 싸게, 어려운 건 여럿이”

Echo는 단순한 모델 라우터와 다릅니다. 요청마다 “얼마나” 계산할지도 함께 결정해요.

간단한 프롬프트(예: “이 사양서 문단을 3줄로 요약해줘”)는 작은 모델 하나에 짧게 태우고 끝. 어려운 프롬프트(예: “이 구조 계산이 KDS 41 기준에 부합하는지, 안전율 계산까지 재검증해줘”)는 여러 모델에 역할을 나눠 돌리고 결과를 합칩니다. 앙상블이지만 모든 요청에 풀 앙상블 비용을 내지 않고, 필요할 때만 여러 모델을 부르는 구조예요.

이 방식이 특히 눈에 띄었어요. 엔지니어링 팀이 일하는 방식과 닮아 있기 때문입니다. 쉬운 티켓은 주니어가, 아키텍처 결정은 시니어가, 특정 도메인 이슈는 해당 전문가가 맡죠. 배분이 좋으면 팀 산출물은 시니어 한 명의 출력보다 훨씬 낫습니다. Echo가 노리는 역할이 바로 이겁니다. LLM 팀의 매니저 역할.

그럼 왜 지금이냐

라우팅 아이디어는 새롭지 않아요. OpenRouter 같은 상용 라우팅도 있었고, 국내에서도 조건별 스위칭 코드를 많이 짰습니다. 다만 그동안은 대체로 “싼 모델 먼저, 실패하면 비싼 모델로 폴백” 하는 규칙 기반이었죠.

지금 달라진 점은 두 가지입니다.

첫째, 오픈웨이트 모델 품질이 실전 투입 가능한 수준으로 올라왔다는 점. GLM, Kimi, DeepSeek 같은 모델이 특정 태스크에선 GPT-4 세대와 맞붙을 수 있어요. 라우팅 대상 풀 자체가 의미가 생겼습니다.

둘째, 비용 압박이 체감될 만큼 커졌다는 점. Show HN 댓글에 이런 사례가 있었죠. 어떤 사용자가 Fable에서 서브에이전트를 병렬로 돌리다 75분 만에 $120을 태웠다고요. 프로모션 크레딧이어서 다행이지, 청구서였다면 하룻밤에 회의 한 번 열릴 금액이에요.

우리도 곧 비슷해집니다. 사내 에이전트 하나 만들어 팀원 20명이 돌리기 시작하는 순간, 월 API 비용은 급격히 뛰어요. **단가를 1/3로 낮출 수 있다면 ‘지금 못 만드는 걸 만들 수 있게 된다’**로 연결됩니다. 승인 못 받던 프로젝트가 승인선에 올라오죠.

OpenAI 호환 엔드포인트가 왜 결정적이냐

Echo의 실용적인 선택이 하나 더 있어요. OpenAI 호환 API를 그대로 제공합니다. 코드에서 base_url 한 줄만 바꾸면, 그날 오후 실제 프롬프트로 A/B 테스트가 가능해요.

이게 중요한 이유는 대부분의 사내 AI 툴이 이미 OpenAI SDK로 작성돼 있기 때문이에요. 새 라우팅 서비스가 아무리 좋아도 “SDK 갈아엎고 우리 프로토콜 배우세요” 하면 채택이 어렵죠. 호환 유지로 즉시 대체가 가능해지는 순간, 실험 비용이 30분으로 떨어집니다.

앞으로 라우팅/앙상블 서비스를 고를 때 체크할 포인트는 이 정도예요:

1. 기존 SDK를 그대로 쓸 수 있는가(= base_url 교체로 끝나는가)
2. 요청별 라우팅 결과를 확인할 수 있는가(관측 가능성)
3. 실패 시 원본 모델로 폴백 가능한가
4. 우리 도메인 데이터로 자체 평가를 붙일 수 있는가

Echo는 아직 2번이 약해요. “라우팅 결정이 우리 제품의 핵심이라 공개하지 않는다”고 합니다. 프로덕션 도입에선 이 부분이 걸림돌일 수 있지만, 방향 자체는 설득력 있어요.

이번 주에 해볼 만한 것

결론이 “지금 당장 Echo를 프로덕션에 넣자”는 건 아니에요. 아직은 일러요. 벤치는 자가 평가고, 라우팅 로직은 블랙박스이며, 코딩/에이전트 태스크에서는 오할당 이슈가 있다고 제작자도 인정했어요.

대신 이번 주엔 이걸 권합니다.

여러분의 사내 AI 워크플로우에서 ‘굳이 GPT-5급이 필요 없는데 편해서 쓰는’ 서브태스크 3개를 골라보세요. 요약, 분류, 태깅, 간단한 추출 같은 것들요. 그 3개를 GLM-4.5나 Kimi 같은 오픈웨이트 모델(또는 GPT-4o mini급)로 바꿔도 품질이 얼마나 유지되는지, 여러분 실제 프롬프트로 재보세요. 자체 평가 20~30개면 충분합니다.

십중팔구 품질 하락이 미미할 거예요. 그 순간 이미 라우팅 시대의 첫 결정을 내린 겁니다. 모델 하나에 올인하지 않는다. Echo가 자동화하려는 일을, 손으로 먼저 검증해 보는 거예요.

그 감이 잡히면, 6개월 뒤 Echo든 다른 라우터든 진짜 물건이 나왔을 때 남들보다 3개월 먼저 도입할 수 있어요. 지금 준비해서 가져갈 수 있는 가장 실용적인 이점입니다.