LLM

HuggingChat의 Omni (Router) 알아보기

harheem

22 Oct 2025 • 15 min read

Hugging Face의 HuggingChat에는 Omni라는 선택지가 있습니다. 이름만 보면 또 하나의 대화 모델처럼 보일 수 있지만, Omni의 핵심은 모델 자체가 아니라 모델을 고르는 방식에 있습니다.

사용자는 질문을 입력합니다. 시스템은 그 질문이 코딩인지, 번역인지, 요약인지, 일반 대화인지 판단합니다. 그리고 해당 요청에 더 적합한 오픈소스 모델을 골라 응답을 생성합니다.

즉, Omni는 사용자가 직접 모델 목록을 훑어보며 “이번 질문에는 어떤 모델을 써야 하지?”라고 고민하지 않게 만드는 라우터(router) 또는 오케스트레이터(orchestrator) 에 가깝습니다.

이 글에서는 HuggingChat Omni가 왜 필요한지, 내부적으로 어떤 아이디어에 기반하는지, 그리고 이 방식이 오픈소스 AI 생태계에서 어떤 의미를 갖는지 정리해 보겠습니다.

1. 왜 모델 라우터가 필요해졌을까요?

초기 ChatGPT 이후 많은 사용자는 하나의 강력한 범용 모델이 대부분의 작업을 처리하는 방식에 익숙해졌습니다. 이 방식은 단순합니다. 사용자는 하나의 모델과 대화하고, 모델은 가능한 모든 질문에 답합니다.

하지만 AI 활용 범위가 넓어지면서 이 접근 방식의 한계도 분명해졌습니다.

첫째, 모든 작업에 같은 모델이 최선은 아닙니다. 일반 대화에 강한 모델이 코드 생성, 수학 추론, 번역, 긴 문서 요약에서도 항상 가장 좋은 결과를 내는 것은 아닙니다. 어떤 모델은 코딩에 강하고, 어떤 모델은 긴 컨텍스트 처리에 강하며, 어떤 모델은 특정 언어나 도메인에서 더 안정적입니다.

둘째, 비용과 자원 측면에서도 비효율이 생깁니다. 간단한 질문까지 항상 큰 모델로 처리할 필요는 없습니다. 작업 난이도와 성격에 맞는 모델을 고르면 응답 품질과 비용 사이의 균형을 더 잘 맞출 수 있습니다.

셋째, 사용자가 직접 모델을 고르는 방식은 점점 어려워지고 있습니다. 오픈소스 모델은 빠르게 늘어나고 있고, 각 모델의 강점과 한계를 모두 파악하기는 쉽지 않습니다. 모델이 많아질수록 선택지는 풍부해지지만, 동시에 사용자의 선택 부담도 커집니다.

그래서 필요한 것이 라우터입니다.

라우터는 사용자의 프롬프트를 보고 “이 요청은 어떤 유형의 작업인가?”, “어떤 모델이 이 작업에 더 적합한가?”를 판단합니다. 사용자는 하나의 대화창을 쓰지만, 내부적으로는 여러 모델 중 하나가 선택됩니다.

HuggingChat Omni는 이 문제를 사용자 경험 차원에서 풀어낸 시도라고 볼 수 있습니다.

2. HuggingChat Omni는 무엇인가요?

Omni는 하나의 새로운 거대 언어 모델이라기보다, HuggingChat 안에서 동작하는 모델 라우팅 기능입니다.

사용자가 Omni를 선택하고 질문을 입력하면, Omni는 요청의 성격을 파악한 뒤 HuggingChat에서 사용할 수 있는 모델 중 적합한 모델을 선택합니다. 사용자는 모델을 직접 고르지 않아도 됩니다. 대신 시스템이 모델 선택 과정을 대신 처리합니다.

사용자는 “어떤 모델이 코딩에 강한가?”, “어떤 모델이 번역에 적합한가?”, “어떤 모델이 일반 대화에 안정적인가?”를 매번 판단하지 않아도 됩니다. Omni라는 하나의 진입점에 질문하면, 시스템이 뒤에서 모델 선택을 처리합니다.

이것은 단순한 편의 기능처럼 보일 수 있습니다. 하지만 실제로는 모델 사용 경험의 중심을 바꿉니다.

기존 방식에서는 사용자가 모델을 먼저 고르고, 그 모델에 질문을 맞췄습니다. Omni 방식에서는 사용자가 먼저 작업을 말하고, 시스템이 그 작업에 맞는 모델을 고릅니다.

모델 중심 경험에서 작업 중심 경험으로 이동하는 셈입니다.

3. 투명성

Omni에서 인상적인 지점은 응답 생성 후 어떤 모델이 사용되었는지 표시된다는 점입니다.

모델 라우팅 시스템에서 투명성은 매우 중요합니다. 사용자가 어떤 모델이 선택되었는지 알 수 없다면, 응답 품질을 평가하기도 어렵고, 시스템이 어떤 기준으로 작동하는지 학습하기도 어렵습니다.

예를 들어 코딩 질문을 했을 때 코딩에 강한 모델이 선택되었다면, 사용자는 자연스럽게 “이런 유형의 작업에는 이 모델이 쓰이는구나”라고 이해할 수 있습니다. 일반 대화나 요약 질문에서 다른 모델이 선택되는 것도 마찬가지입니다.

이 경험은 일종의 교육적 효과를 만듭니다.

사용자는 벤치마크 표를 따로 읽지 않아도, 실제 대화 맥락 안에서 모델의 용도와 강점을 조금씩 익히게 됩니다. 오픈소스 모델 생태계에 익숙하지 않은 사용자에게는 특히 중요한 장점입니다.

다만, 모델이 표시된다고 해서 라우팅 결정이 항상 최적이라는 뜻은 아닙니다. 라우터도 잘못 고를 수 있고, 선택된 모델의 응답 품질도 상황에 따라 달라질 수 있습니다.

그래서 사용자가 시스템의 결정을 관찰하고 평가할 수 있게 해주는 최소한의 장치로서 투명성은 필수라고 할 수 있습니다.

4. 선호도 정렬 라우팅

HuggingChat Omni의 라우팅 아이디어를 이해하려면 Katanemo의 Arch-Router-1.5B를 볼 필요가 있습니다.

Arch-Router는 이름 그대로 라우팅을 위한 모델입니다. 사용자의 요청을 읽고, 이 요청이 어떤 도메인과 작업 유형에 해당하는지 판단한 뒤, 미리 정의된 선호도에 따라 적합한 경로를 선택합니다.

여기서 중요한 개념은 선호도 정렬 라우팅(preference-aligned routing) 입니다.

기존 라우팅 방식은 크게 두 가지로 볼 수 있습니다.

하나는 임베딩이나 분류기를 이용해 요청을 특정 레이블로 나누는 방식입니다. 예를 들어 “SQL”, “고객 지원”, “번역” 같은 범주로 요청을 분류합니다. 이 방식은 단순하고 빠르지만, 새로운 작업 유형이 추가되거나 정책이 바뀌면 다시 조정해야 할 수 있습니다.

다른 하나는 모델별 벤치마크 점수에 따라 선택하는 방식입니다. 예를 들어 특정 모델이 MMLU에서 높고, 다른 모델이 코딩 벤치마크에서 높다는 식으로 점수를 비교합니다. 하지만 벤치마크 점수가 실제 사용자 선호도나 특정 업무 맥락의 품질을 항상 잘 반영하는 것은 아닙니다.

Arch-Router의 접근은 조금 다릅니다.

이 방식은 사용자가 정의한 도메인과 액션을 기준으로 라우팅 정책을 구성합니다. 예를 들어 “programming 도메인의 code_generation 작업에는 이 모델을 우선 사용한다”처럼 정책을 설정할 수 있습니다.

여기서 도메인은 요청의 주제나 분야를 뜻합니다. 법률, 의료, 여행, 프로그래밍 같은 범주가 될 수 있습니다. 액션은 사용자가 원하는 작업의 종류입니다. 요약, 번역, 코드 생성, 이미지 편집, 일정 예약 같은 작업이 여기에 해당합니다.

라우터는 사용자의 요청을 읽고, 이 요청이 어떤 도메인과 액션에 가까운지 추론합니다. 그리고 그 조합에 연결된 선호 모델을 선택합니다.

이 구조의 장점은 유연성입니다. 새 모델이 추가되거나 정책이 바뀌어도 라우터 자체를 다시 학습시키지 않고 설정을 바꿔 대응할 수 있습니다. 모델 선택을 하드코딩된 로직이 아니라 설정 가능한 정책의 문제로 다루는 것입니다.

5. 모델 선택의 추상화

Omni의 가장 큰 의미는 모델 선택을 사용자에게서 숨긴다는 데 있습니다.

여기서 “숨긴다”는 말은 부정적인 뜻이 아닙니다. 복잡한 선택 과정을 시스템이 대신 처리해 사용자가 본래 하려던 작업에 집중할 수 있게 만든다는 뜻입니다.

소프트웨어 인프라에 비유하면, Omni는 API 게이트웨이에 가깝습니다. 사용자는 여러 마이크로서비스의 위치와 특성을 직접 알 필요 없이 하나의 엔드포인트로 요청을 보냅니다. 게이트웨이는 요청을 적절한 서비스로 전달합니다.

AI 모델 생태계에서도 비슷한 일이 일어나고 있습니다. 앞으로 모델은 더 많아질 가능성이 높습니다. 하나의 거대한 모델이 모든 작업을 압도적으로 잘하는 방식도 계속 발전하겠지만, 동시에 작고 빠르며 특정 작업에 강한 모델들도 계속 등장할 것입니다.

이때 사용자가 매번 모델을 직접 고르는 방식은 오래가기 어렵습니다. 모델이 많아질수록 중요한 것은 모델 목록 자체가 아니라, 그 모델들을 어떤 기준으로 조합하고 선택하느냐입니다.

6. 아직 남은 과제

첫 번째 과제는 라우팅 품질입니다. 라우터가 사용자의 의도를 잘못 해석하면, 적합하지 않은 모델이 선택될 수 있습니다. 모델 선택이 자동화될수록 사용자는 편해지지만, 동시에 시스템이 왜 그런 선택을 했는지 알기 어려워질 수 있습니다. 그래서 선택된 모델을 표시하는 투명성은 앞으로도 중요합니다.

두 번째 과제는 안정성입니다. 라우팅 시스템은 여러 모델과 제공자를 연결하는 구조이기 때문에, 특정 모델의 장애나 지연이 전체 사용자 경험에 영향을 줄 수 있습니다. 단순히 모델을 잘 고르는 것뿐 아니라, 실패했을 때 어떻게 우회하고 복구할지도 중요합니다.

세 번째 과제는 사용자별 선호도입니다. Arch-Router의 핵심 철학은 사용자가 정의한 선호도에 따라 모델을 선택할 수 있다는 데 있습니다. 그런데 일반 사용자가 HuggingChat Omni에서 직접 라우팅 정책을 세밀하게 편집하는 경험은 아직 전면에 드러나 있지 않습니다.

현재의 Omni가 보여주는 것은 “모델 선택 자동화”에 가깝습니다. 다음 단계에서 더 흥미로운 지점은 “사용자별 라우팅 정책”이 될 가능성이 있습니다.

예를 들어 어떤 사용자는 코딩 질문에는 항상 특정 모델을 우선 쓰고 싶을 수 있습니다. 또 다른 사용자는 한국어 답변에서는 특정 모델을 선호할 수 있습니다. 기업 사용자는 보안, 비용, 지연 시간, 라이선스 조건에 따라 라우팅 정책을 다르게 설정하고 싶을 수 있습니다.

이런 설정이 사용자 경험 안으로 들어오면, Omni는 단순한 자동 선택 기능을 넘어 개인화된 모델 오케스트레이션 계층에 가까워질 수 있습니다.