OmniRoute 리뷰

고객사마다 쓸 수 있는 AI 모델이 다릅니다. 어떤 곳은 이미 계약한 게 있고, 어떤 곳은 데이터를 밖으로 못 내보내고, 어떤 곳은 그냥 싼 걸 원해요. 그때마다 코드에서 모델 부르는 부분을 고치는 게 실무에서 제일 성가신 일입니다.

그래서 조간에 OmniRoute 가 올라왔을 때 열어봤습니다. 주간 별 증가 4,700개로 8위였어요. MIT 라이선스이고 TypeScript 로 만들었습니다.

엔드포인트 하나 뒤에 제공자를 세웁니다

도구는 전부 이 주소 하나만 봅니다.

내 컴퓨터에 localhost:20128/v1 로 OpenAI 호환 엔드포인트를 하나 띄웁니다. 그 뒤에 제공자들을 붙여두고, Claude Code 든 Cursor 든 Copilot 이든 전부 그 주소 하나를 보게 합니다.

핵심은 그다음입니다. 한도¹에 걸리거나 제공자가 실패하면 알아서 다음으로 넘어갑니다. 만든 쪽은 이걸 combo 라고 부르는데, 모델을 사슬로 엮어두고 자동으로 옮겨 다니는 거예요.

combo 는 OmniRoute 가 자동으로 오가는 모델의 사슬입니다. quota 가 떨어지거나, 제공자가 실패하거나, 비용이 치솟으면 combo 가 다음의 자격 있는 건강한 모델로 옮겨갈 수 있습니다.

고르는 방법이 19가지 있습니다. priority(순서대로), cost-optimized(실시간 가격으로 제일 싼 것), headroom(한도가 제일 많이 남은 것), reset-window(한도가 제일 먼저 초기화되는 것) 같은 것들이에요.

아무것도 안 정하고 모델 이름에 auto 만 써도 됩니다. 그러면 붙어 있는 제공자들로 가상 combo 를 만들어 실시간 점수로 고릅니다. auto/cheap, auto/fast, auto/coding 처럼 방향을 정해줄 수도 있고요.

Compsmag 편집팀이 일주일 써보고 적은 기록이 이 부분에서 구체적입니다. Kiro 의 rate limit 에 하루 세 번쯤 걸렸는데, 그때마다 OpenCode Free 로 넘어가는 fallback²이 매끄럽게 돌아 작업이 끊기는 게 눈에 안 보였다고 합니다.

보내기 전에 토큰을 줄입니다

내건 값과 리뷰어가 잰 값입니다.

두 번째로 눈에 띈 게 압축이에요. 요청이 나가기 전에 프롬프트를 줄여서 보냅니다. 엔진이 12개 쌓여 있고 기본은 RTK → Caveman 순서예요.

저장소가 계산식을 그대로 적어뒀습니다.

`` 합쳐진 값 = 1 − (1 − 0.80) × (1 − 0.46) = 89.2% 범위 = 78.4 – 94.6% ``

그런데 Compsmag 이 실제로 잰 값은 용도마다 달랐습니다. 챗봇 대화 기록 65%, 콘텐츠 생성 50%, 전체 평균 42%, 코딩 프롬프트는 18% 였어요.

코딩이 유독 낮은 이유가 문서에 적혀 있습니다. 코드 블록, URL, JSON, 구조화된 데이터는 보존 엔진이 항상 지킵니다. 줄이면 안 되는 걸 안 줄이니 코딩 프롬프트에서는 줄일 게 별로 안 남는 거죠. 그러니 18%는 실패가 아니라 설계대로 나온 값입니다.

대신 요청마다 50~200ms 가 더 붙었다고 하고요.

두 달 만에 숫자가 많이 달라졌습니다

7월 리뷰가 적은 값과 9월에 조회한 값입니다.

자료를 모으다가 숫자가 출처마다 다른 걸 봤어요. 어디는 271개 제공자, 어디는 290개, 어디는 352개였어요.

두 달 차이였습니다. Compsmag 이 7월에 쓴 리뷰는 제공자 237개에 별 17,000개로 적었는데, 9월 6일에 저희가 조회하니 별이 61,757개였습니다. 두 달 만에 3.6배예요. 제공자도 237에서 352로, 라우팅 전략도 17에서 19로 늘었습니다.

그런데 README 안에서도 갈립니다. 총 352개는 어디서나 같은데, 그중 무료가 몇 개인지가 다릅니다.

• 히어로 그림과 요약 줄: 90개 이상 무료
• 제공자 절 제목: 154개가 카탈로그에 무료로 표시됨
• 저장소 한 줄 설명: 150개 이상 무료
• 무료 토큰 절: 40개 풀 키에 걸쳐 455개의 무료 등급 항목

세는 단위가 서로 다른 것 같아요. "무료 등급을 가진 제공자"와 "카탈로그에 무료로 표시된 항목"과 "풀 키별 항목"은 다른 것이니까요. 다만 어느 게 어느 건지 문서가 따로 밝혀두지 않아서, 읽는 쪽에서는 그냥 숫자가 안 맞는 것처럼 보입니다.

월 15.1억 무료 토큰이라는 대표값은 오히려 계산 방식을 밝혀뒀습니다. 공표된 월 예산이 양수인 20개 풀에서만 계산하고 같은 풀은 중복을 제거했다고 적혀 있고, 스스로 "풀 중복을 제거한 정직한 계산"이라고 부릅니다.

상위 10명 중 1위가 커밋의 대부분을 차지합니다.

기여자 수도 세는 방식이 갈립니다. README 는 600명 이상이라고 적었는데, 저희가 GitHub API 로 세보니 계정이 있는 기여자가 428명, 익명까지 포함하면 590명이었습니다. 다만 커밋은 한쪽으로 몰려 있습니다. 만든 사람 한 명이 4,653커밋으로 상위 10명 커밋의 80% 를 차지합니다.

무료 제공자를 프록시로 쓰는 게 약관에 걸릴 수 있습니다

문이 다섯 개 나란히 서 있는데 열린 것과 닫힌 것이 섞여 있습니다.

여기가 제일 조심해야 할 대목이라고 봅니다.

Compsmag 이 짚은 것 중에 이런 게 있습니다. 일부 제공자는 프록시를 통한 사용을 이용약관에서 명시적으로 금지합니다. 무료 등급을 게이트웨이에 모아 쓰는 구조 자체가 그쪽 약관과 부딪힐 수 있다는 뜻이에요.

관련해서 기술 스택 표에 이런 줄이 있습니다.

은폐(Stealth) — wreq-js, JA3 / JA4 TLS 지문³ 흉내내기, 3단 프록시

TLS 지문은 접속하는 쪽이 어떤 프로그램인지 서버가 알아보는 단서예요. 그걸 흉내낸다는 건 다른 프로그램인 척한다는 이야기예요. 왜 넣었는지는 문서에 안 적혀 있는데, 지역이 막힌 곳에서 쓰려는 용도일 수도 있고 감지를 피하려는 용도일 수도 있습니다.

어느 쪽이든 고객사 일에 쓰려면 붙일 제공자의 약관을 하나씩 확인해야 하는 종류의 기능입니다. 저희가 이걸 고객사에 넣는다면 유료 계약이 있는 제공자만 붙이고 무료 등급은 안 쓸 것 같습니다.

켜자마자 안전하지는 않습니다

문은 있는데 열쇠가 바닥에 놓여 있습니다.

보안 쪽은 공식 문서가 스스로 밝혀둔 게 많더군요. 그대로 옮깁니다.

guardrail⁴이 fail-open⁵입니다. 문서에 이렇게 적혀 있어요.

이 시스템은 fail-open 입니다. guardrail 이 돌다가 예외를 던지면, 레지스트리는 그 오류를 기록하고 요청을 실패시키는 대신 다음 guardrail 로 넘어갑니다. 막는 것은 명시적인 결정이지 사고로 일어나는 일이 아닙니다.

숨긴 게 아니라 의도한 설계고 문서에 써뒀습니다. 다만 보안보다 가용성을 앞에 둔 선택이라는 건 알고 써야 합니다.

프롬프트 주입⁶ 검사도 기본 모드가 warn 입니다. block 이 아니라 경고만 남기고 통과시켜요. 검사 범위도 앞의 16,384바이트까지고요.

.env.example 을 열어보니 JWT_SECRET 과 API_KEY_SECRET 은 값이 비어 있고 "처음 돌리기 전에 반드시 설정해야 합니다"라고 적혀 있었습니다. 7월 리뷰가 지적한 박힌 기본값(omniroute-default-secret-change-me)은 지금 이 파일에 안 보입니다. 소스 안에 대체값이 남아 있는지까지는 확인하지 못했습니다.

최초 관리자 비밀번호는 여전히 CHANGEME 가 기본값입니다. 파일 자신이 "안전하지 않음, 로컬 개발용"이라고 적어뒀어요.

npm 패키지 쪽 이력도 있습니다. 2026년 5월에 Socket.dev 가 v3.8.5 를 난독화된 코드와 설치 스크립트 때문에 표시했고, 관리자가 진짜 취약점 두 개를 인정해 v3.8.6 에서 고쳤습니다. 악성코드는 확인되지 않았습니다.

지금 생각

Compsmag 이 매긴 항목별 보안 점수입니다.

붙이는 겹이 하나 늘어나는 대신 모델을 바꿔 끼우는 일이 쉬워지는 물건이죠. 고객사마다 다른 모델을 쓰는 저희 사정에는 맞는 모양이에요.

다만 쓴다면 이렇게 쓸 것 같습니다.

개발할 때 내 자리에서만. Compsmag 은 "상당한 보강 없이는 아직 기업 운영 환경에 쓸 준비가 안 됐다"고 적었고 보안 성숙도를 10점 만점에 5점으로 매겼습니다. 고객사 서버에 올릴 물건은 아직 아닙니다.

유료 계약이 있는 제공자만. 무료 등급을 모아 쓰는 게 이 도구의 제일 큰 매력인데, 그게 약관과 부딪힐 수 있는 부분이기도 합니다.

릴리스를 바로 따라가지 않기. 75일 동안 30번 릴리스가 나왔습니다. 평균 2.6일에 한 번입니다. 활발하다는 신호이기도 하고, v3.8.48 이 시작할 때 죽는 문제를 고친 hotfix 였다는 기록도 있습니다.

모르는 채로 남는 건 압축을 켠 상태에서 답변 품질이 얼마나 떨어지는지입니다. 토큰을 42% 줄였다는 숫자는 있는데, 줄인 프롬프트로 받은 답이 원래 답과 얼마나 다른지를 잰 기록은 못 찾았습니다. 코드는 보존한다니 코딩 작업은 덜 걱정되는데, 긴 대화에서 65%를 줄이면 무엇이 빠지는지는 붙여봐야 알 것 같습니다.