OmniRoute: MIT 라이선스 AI 게이트웨이, 358개 제공업체·1,200개 이상 모델·토큰 압축

OmniRoute는 diegosouzapw가 공개한 MIT 라이선스 AI 게이트웨이다. 주장은 분명하다. Claude Code, Codex, Cursor, Cline, Copilot, Antigravity 같은 코딩 도구가 하나의 엔드포인트로 358개 모델 제공업체(저장소 제목은 359개 제공업체와 1,200개 이상의 모델이라고 적는다)에 접속하게 한다. 그중 150곳 넘게 무료 티어가 있고, 할당량이 바닥나면 게이트웨이가 자동으로 다음 제공업체로 넘어간다. 내세우는 숫자는 월 약 16.2억 무료 토큰, 시작 비용은 0이다. 이렇게 큰 숫자는 의심부터 해 보는 편이 맞다. 그래서 어떻게 계산했는지를 먼저 읽고 그 무게를 판단하려 한다.

README의 설명은 홍보 배너보다 훨씬 절제되어 있다. 프로젝트는 무료 티어 항목 489건을 정리해 35개의 반복 풀 키로 묶었다. 대표 숫자에는 월 예산이 공개된 양수인 17개 풀과 Groq의 모델별 상한 5개만 들어가고, 공유 풀은 중복을 제거해 한 번만 센다. 지역 신원 확인을 거쳐야 열리는 할당량, 현재는 ModelScope의 약 600만 토큰은 따로 표시하고 대표 숫자에 더하지 않는다. 첫 달에는 가입 크레딧을 더해 약 22.2억까지 늘어난다. 예산 막대에 이름이 오른 큰 항목은 Mistral 10억, Nara 2.1억, LLM7과 xKiro 각 1.5억, Groq 다섯 상한 합계 3,000만이다. 또 13개 제공업체는 약관 위험 목록에서 '피함'으로 표시되며 판단은 사용자에게 맡긴다. 제작자들은 숫자를 2주마다 다시 감사하며 오르내림이 모두 있다고 밝힌다. 이 투명성이 진짜 기여다. 무료 티어의 어려움은 찾는 데 있지 않고, 내게 실제로 무엇이 있는지 보는 데 있다.

라우팅과 비용 측면에서 OmniRoute는 19가지 라우팅 전략을 갖추고, 상위 할당량이 소진되거나 호출이 실패하면 자동으로 제공업체를 바꾼다. 여기에 RTK와 Caveman 두 겹의 압축을 쌓아 토큰을 15%에서 95%, 평균 약 89% 줄인다고 주장한다. 압축은 게이트웨이 안에서 일어나므로 상위 도구는 바꿀 필요가 없다. 다만 이 숫자는 차분히 읽어야 한다. 평균 89%는 프로젝트가 스스로 밝힌 값이고, 실제 효과는 작업 부하에 따라 달라진다. 반복되는 도구 출력, 긴 로그, 정형화된 맥락은 잘 줄지만, 밀도 높은 코드 추론이나 새로운 요구 설명은 훨씬 덜 줄어든다. 평균은 상한 참고치로 보고 자신의 실제 세션에서 측정하는 편이 안전하다. 절감 이전에 공학적 문제도 현실적이다. 제공업체마다 인터페이스 방언, 인증 방식, 속도 제한 규칙이 다르고 기준도 분당, 일당, 모델별로 제각각이다. 게이트웨이는 이 차이를 하나의 호출 면으로 접고, 각 풀의 잔량과 초기화 시점을 기억해야 한다. 라우팅 전략을 쓰면 지연, 비용, 남은 할당량, 모델 능력에 따라 다음 경로를 고를 수 있어 운에 맡기지 않아도 된다. 자동 폴백은 실패를 내부 재시도로 바꾸어, 코딩 도구에는 조금 느린 성공으로만 보인다. 오래 도는 에이전트 작업에서는 중간에 끊기면 맥락 전체를 다시 쌓아야 하므로, 이것이 개별 제공업체의 가동률 약속보다 실용적이다.

아키텍처 관점에서 이 프로젝트는 게이트웨이를 코딩 에이전트의 제어 평면으로 끌어올린다. 에이전트의 사용 패턴은 독특하다. 세션이 길고, 도구 호출이 잦고, 맥락이 되풀이해 재생되며, 할당량 압박이 크고, 속도 제한은 가장 나쁜 순간에 걸리기 쉽다. 할당량과 프로토콜 차이를 이해하고 조용히 경로를 바꿀 수 있는 중간 계층이 있으면, '어느 모델을 부를까'라는 질문을 각 도구의 설정에서 꺼내 한곳에서 관리할 수 있다. 개발자는 도구마다 열댓 개의 키와 제한 규칙을 챙기는 대신 엔드포인트 하나와 대시보드 하나, 그리고 /dashboard/free-tiers의 실시간 화면을 보면 된다. MIT 라이선스 덕분에 직접 호스팅하고 감사할 수 있다는 점은 프롬프트를 다루는 구성요소에서 특히 중요하다.

위험도 같은 곳에 모인다. 첫째, 무료 티어 약관은 언제든 바뀔 수 있다. 제공업체가 정책을 조이면 의존하는 워크플로가 즉시 영향을 받고, 프로젝트 스스로도 숫자가 움직인다고 인정한다. 둘째, 프롬프트에는 소스 코드와 내부 맥락이 자주 들어 있어서, 수십 곳의 제3자를 거치면 단일 제공업체보다 데이터 경로가 훨씬 복잡해진다. 셋째, 키와 라우팅 설정이 한곳에 모이면 게이트웨이 자체가 가치 높은 표적이 되므로 운영 서비스처럼 다뤄야 한다. 현실적인 방침은 오픈소스나 민감하지 않은 프로젝트에 쓰고, 민감한 저장소는 자체 또는 신뢰할 수 있는 유료 제공업체로 보내며, 실시간 할당량 화면을 계속 지켜보는 것이다.

업계 맥락에서 OmniRoute는 형성 중인 분업을 보여 준다. 모델 제공업체는 성능과 가격으로 경쟁하고, '많은 제공업체를 잘 쓰는 방법'은 독립된 인프라 계층이 되어 가고 있다. 무료 티어는 원래 고객 확보 수단이었지만, 체계적으로 모으면 일정을 짤 수 있는 공공 연산 풀이 된다. 학생, 독립 개발자, 자원이 적은 소규모 팀에게 특히 의미가 큰데, 에이전트 워크플로를 시험하는 문턱이 낮아지기 때문이다. 동시에 무료 할당량의 지속 가능성은 제공업체의 사업 판단에 달려 있고, 집계 계층이 성공할수록 제공업체가 규칙을 조정할 가능성도 커진다는 점을 상기시킨다. 따라서 OmniRoute는 영구 무료라는 약속이 아니라 관찰 창이자 옮겨 쓸 수 있는 설계 패턴으로 읽는 것이 합리적이다. 팀에 오래 남는 가치는 할당량 모니터링, 폴백 논리, 라우팅 정책을 자기 스택에 녹여 넣는 일이며, 이 역량은 무료 티어가 어떻게 바뀌어도 유효하고 유료 제공업체에도 그대로 쓸 수 있다.