산업·투자·

AI 비용 90% 줄이는 비결, 모델이 아니라 '라우터'다

한 줄 요약모델 선택보다 라우팅 설계가 AI 비용을 가른다. 퉁구즈와 코인베이스가 증명한 구조적 해법.
광고 자리 (top) — .env 에 NEXT_PUBLIC_ADSENSE_CLIENT / _SLOT_TOP 설정 시 노출

라우터 하나로 AI 비용 90% 아낀 코인베이스

톰 퉁구즈가 블로그에 올린 글 한 편이 해커뉴스에서 33점, 댓글 없이 조용히 퍼졌다. 화려한 벤치마크 점수도, 새 모델 발표도 아니다. **"대부분의 AI 작업은 기다려도 된다"**는 한 문장이 전부다.

핵심은 모델 선택이 아니라 **라우터(router)**다. 요청이 들어오면 어떤 티어의 모델이 처리할지 결정하는 작은 코드 조각. 이걸 잘 짜면 전체 트래픽의 70~80%를 로컬 모델이나 비동기 배치 추론으로 돌릴 수 있다. 비용은 실시간 추론 대비 100분의 1 수준으로 떨어진다.

브라이언 암스트롱 코인베이스 CEO도 지난주 같은 얘기를 했다. 토큰 사용량은 기하급수적으로 늘었는데 AI 지출은 절반으로 줄였다. 비결은 세 가지.

  • 더 나은 기본값(defaults)
  • 라우팅(routing)
  • 캐싱(caching)

엔지니어는 아무 모델이나 쓰게 두되, 기본 경로를 라우터가 잡는다.

세 겹으로 나뉜 라우팅의 실제 작동 원리

라우팅 문제엔 세 층이 있다. 첫째, **분류기(classifier)**는 언어 문제다. 요청이 무슨 의도인지 파악한다. 둘째, **라우터(router)**는 스케줄링 문제다. 분류된 요청을 어떤 모델 풀에 보낼지 결정한다. 둘을 섞으면 프롬프트 안에 모델 선택이 묻혀서 A/B 테스트가 불가능해진다.

셋째, **큐잉(queueing)**이다. 초안 답변, 레포 요약, 실사 메모, 야간 평가 실행. 이런 건 1초 안에 돌아와야 할 이유가 없다. 비동기 배치로 모아 처리하면 실시간 추론 대비 두 자릿수 배 이상 싸다. 퉁구즈 팀이 만든 에이전트 런타임엔 이미 이 라우터가 들어 있다. 복잡도, 컨텍스트 크기, 로컬 메모리 검색 여부로 태스크를 채점한다.

그 위에 두 피드백 루프가 얹혔다. **동기 예측기(synchronous predictor)**는 실패할 게 뻔한 어려운 태스크를 미리 잡아낸다. **야간 루프(nightly loop)**는 예측기가 놓친 새 실패 패턴을 밤새 찾아낸다. 두 루프가 다른 시간 척도에서 작동한다.

광고 자리 (inArticle) — .env 에 NEXT_PUBLIC_ADSENSE_CLIENT / _SLOT_INARTICLE 설정 시 노출

스킬 증류가 끝난 뒤, 로컬 모델이 80%를 먹는다

여기서 중요한 전제가 하나 있다. **"스킬 증류(skill distillation)가 연산 세트를 평탄화한 뒤"**라는 조건이다. 큰 모델이 도구 호출법을 배워서 작은 모델에 전수하면, 비코딩 작업 기준 에이전트 트래픽의 70~80%를 로컬 모델이 감당한다.

이 대목이 걸린다. 증류가 어느 정도 진행돼야 이 비율이 나오는지, 코딩 작업은 왜 빠지는지, 자료엔 없다. 퉁구즈 팀이 "우리 런타임에 이미 넣었다"고만 했지, 오픈소스로 풀렸는지 검증된 벤치마크가 있는지도 불분명하다. 발표문과 검증된 사실을 구분해서 읽어야 한다.

한국 기업이라면 어디부터 봐야 할까

본지가 앞서 다룬 '국내 LLM 인프라 투자 실태' 기사에서 확인했듯, 국내 대기업 여럿이 GPU 클러스터에 수백억 원을 들였다. 그런데 실시간 추론이 꼭 필요한 비중이 몇 %인지 내부 집계한 곳이 얼마나 될까. 퉁구즈 말대로라면 대다수 배치성 작업(리포트 요약, 로그 분석, 야간 배치)은 로컬 GPU나 CPU만으로도 충분하다.

반면 클라우드 GPU 요금제를 파는 쪽엔 불리한 소식이다. 라우팅만 잘 짜도 클라우드 추론 호출이 크게 줄어들 테니. 이해관계가 갈린다.

  • 모델 제공사(오픈AI, 앤스로픽 등): API 호출량 감소 시 매출 영향 가능성
  • 라우팅 미들웨어 스타트업: 비용 절감 수혜
  • 온프레미스 GPU 팜 보유 제조·금융사: 인프라 효율화 이득

구체적 매출 영향은 본지가 확인하지 못했습니다.

쉽게 풀어보면

톰 퉁구즈가 말한 건 이렇다. AI 모델 고르기에 혈안 되지 말고, '어떤 일은 싼 모델로 돌려도 되는지' 분류하는 시스템부터 만들라는 얘기다.

뷔페를 떠올려 보자. 고급 스테이크(대형 LLM)는 비싸고 줄도 길다. 그런데 손님 10명 중 7~8명은 김밥(로컬 모델)이나 샌드위치(비동기 배치)로도 배부르다. **어떤 손님이 스테이크가 필요한지, 김밥으로 충분한지 가려주는 안내원(라우터)**만 잘 두면 식당(기업) 식자재 비용이 90% 넘게 준다.

코인베이스가 정확히 이걸 했다. 손님(토큰 사용량)은 10배 늘었는데 식자재비(AI 지출)는 절반으로 줄였다. 안내원(라우터)을 잘 둔 덕분이다.

한국 기업 다수도 지금 '스테이크만 사려' 한다. GPU 더 사고, 더 큰 모델 쓰려 한다. 그런데 내부 업무 80%는 김밥으로 해결된다. 야간 리포트, 코드 리뷰 초안, 로그 요약, 회의록 정리. 이런 건 실시간 답변이 필요 없다. 밤새 배치로 돌려도 아무도 모른다.

나에게 미치는 영향

당장 확인해 볼 것 하나. 회사에서 쓰는 챗GPT나 클로드 API 호출 로그를 열어 보라. '요약', '번역', '분류', '초안 작성' 같은 태스크가 실시간으로 나가는지, 밤새 모아 배치로 보낼 수 있는지. 배치로 돌릴 수 있는 건 비동기 API로 바꾸거나, 오픈소스 소형 모델을 사내 서버에 올려서 돌리라. 토큰당 비용이 100분의 1로 떨어진다.

개발자라면 라우터부터 짜라. 모델 선택은 나중에 해도 된다. "이 요청은 복잡도 3 이하면 로컬 모델, 4 이상이면 클라우드" 같은 규칙 10줄이면 시작할 수 있다. 그게 이번 글에서 일반 독자가 오늘 바로 시도해 볼 수 있는 유일한 액션이다.

남은 건 검증이다

퉁구즈 팀이 "우리 런타임에 넣었다"고 했지만, 오픈소스로 공개됐는지, 타사 환경에서 재현 가능한지는 아직 모른다. 코인베이스 사례도 암스트롱 트윗 한 줄이 전부다. 구체적 아키텍처, 라우터 구현체, 증류 파이프라인이 검증되기 전까진 '가능성'으로만 둬야 한다.

다만 방향성은 분명하다. AI 인프라 전쟁의 다음 전선은 모델 크기가 아니라 라우팅 효율이다. 누가 더 싼 하드웨어로 더 많은 요청을 소화하느냐. 그 답을 쥔 건 거대 모델이 아니라, 요청을 가르는 작은 코드 조각이다.

이 기사의 출처

이 글은 위 원문과 커뮤니티 반응을 바탕으로 AI의 도움을 받아 작성했으며, 발행 전 사람이 확인합니다. 사실관계는 원문 링크에서 직접 확인하실 수 있습니다.

광고 자리 (bottom) — .env 에 NEXT_PUBLIC_ADSENSE_CLIENT / _SLOT_BOTTOM 설정 시 노출