LLM

HuggingChat의 Omni (Router) 알아보기

harheem

22 Oct 2025 • 10 min read

요즘 저는 Hugging Face의 'Omni'를 지켜보고 있습니다. 이것은 또 하나의 단순한 챗봇이 아닙니다. 수많은 오픈소스 AI 모델들 사이에서 사용자의 질문(프롬프트)에 가장 적합한 모델을 자동으로 골라 연결해주는 지능형 라우팅 시스템입니다.

Omni는 사용자가 어떤 작업을 원하는지 파악한 뒤, Hugging Face의 방대한 라이브러리에서 번역, 코딩, 요약 등 해당 작업에 가장 뛰어난 모델을 동적으로 찾아 최적의 답변을 이끌어냅니다. 이는 우리가 지금껏 의존해온 하나의 거대한 만능 모델을 사용하는 방식과는 다릅니다.

이 똑똑한 라우팅 기능의 중심에는 Katanemo가 개발한 Arch-Router-1.5B 모델이 있습니다. 제가 특히 주목한 것은 선호도 정렬(preference-aligned)이라는 접근 방식입니다. 단순히 벤치마크 점수로 줄을 세우는 것이 아니라, 개발자가 미리 정한 정책(예: '코딩 작업엔 DeepSeek-Coder 모델 써')에 따라 쿼리를 분석하고 딱 맞는 모델로 유연하게 연결해줍니다.

이 글을 통해 Omni가 왜 지금 이 시점에 등장했는지, 어떻게 작동하는지, 그리고 이것이 AI 생태계에 어떤 의미를 던지는지 깊이 있게 분석해보고자 합니다.

1. 왜 오케스트레이터가 필요해졌나?

처음 ChatGPT가 등장했을 때, 우리는 강력하고 범용적인 단일 거대 언어 모델(LLM)에 열광했습니다. 이 one-size-fits-all 접근 방식은 AI의 가능성을 대중에게 알리는 데는 성공했지만, 곧 구조적인 한계에 부딪혔습니다.

생각해보면 당연한 이야기입니다.

성능 저하: 일반 대화에 최적화된 모델이 복잡한 코드 생성이나 전문 번역에서 특화 모델보다 성능이 떨어질 수밖에 없습니다.
비용 비효율: 간단한 질문을 처리하는 데도 거대한 모델 전체를 구동해야 하니 자원 낭비가 심합니다.
유연성 부족: 사용자는 주어진 모델 특성에 맞춰야 했고, 개발자는 다른 모델을 통합하기 어려웠습니다.

이런 한계의 해답으로, 특정 목적(번역, 코딩, 과학 연구 등)에 맞게 미세 조정한(fine-tuning) 수많은 오픈소스 '특화 모델'이 등장했습니다.

하지만 모델이 폭발적으로 늘어나니 새로운 문제가 생겼습니다. 사용자는 수백 개가 넘는 모델 중에서 자기 작업에 맞는 걸 직접 골라야 하는 선택의 역설에 빠졌습니다. 이는 AI 기술 활용의 새로운 진입 장벽이 되었습니다.

그래서 사용자가 애쓰지 않아도 프롬프트 의도를 파악해 최적의 모델로 알아서 연결해주는 중개자, 즉 오케스트레이터(Orchestrator) 또는 라우터(Router)의 필요성이 대두되었습니다.

이 구조에서 HuggingChat Omni는 사용자의 요청(프롬프트)을 가장 적합한 마이크로서비스(모델)로 안내하는 API 게이트웨이 역할을 맡은 겁니다. 이 비유를 곱씹어보면, AI의 미래가 단순히 더 큰 모델을 만드는 게 아니라, 작고 효율적인 특화 모델 생태계를 얼마나 더 똑똑하게 관리하느냐에 달려있음을 알 수 있습니다.

2. HuggingChat Omni, 그래서 정확히 무엇인가?

Omni는 그 자체로 하나의 언어 모델이 아닙니다. 사용자의 요청을 분석해 최적의 기본 모델로 지능적으로 전달하는 라우팅 기능, 즉 메타 모델(meta-model)입니다.

Omni의 가장 큰 가치는 모델 선택의 복잡성을 사용자로부터 완전히 감춰버렸다는(추상화했다는) 데 있습니다. 사용자는 더 이상 수십, 수백 개의 모델 목록을 보며 고민할 필요가 없습니다. 그저 Omni라는 단일 창구와 대화하면, 시스템이 모델을 고르는데 필요한 모든 복잡한 의사결정을 대신 처리해줍니다.

놀라운 투명성

사용자가 Omni를 활성화하고 대화를 나누면, 응답이 생성된 후 UI는 해당 응답을 만드는 데 어떤 기본 모델이 사용되었는지 명확하게 표시합니다.

예를 들어, 코딩 질문을 하면 DeepSeek-Coder가, 일반 대화를 하면 Qwen이 사용되었다고 알려주는 식입니다.

제가 Omni에서 가장 인상 깊게 본 지점도 바로 이 '투명성'입니다.

이건 시스템이 어떻게 도는지 솔직하게 보여줄 뿐만 아니라, 그 자체로 아주 훌륭한 교육적 도구로 작동한다고 생각합니다. 사용자는 벤치마크 보고서를 읽지 않고도, '아, 이런 종류의 작업에는 이 모델이 강점을 보이는구나' 하고 직접적이고 맥락적인 경험을 통해 자연스럽게 학습하게 될 수 있지 않을까요?

3. 선호도 정렬 라우팅

Omni의 지능형 라우팅은 [Arch-Router-1.5B](https://huggingface.co/katanemo/Arch-Router-1.5B)라는 경량(15억 파라미터) 오픈소스 모델이 담당합니다. 이 모델이 채택한 선호도 정렬 라우팅 방식은 기존 전략들과는 근본적인 차이가 있습니다.

기존 방식 1 (임베딩 기반): '고객 지원', 'SQL' 같은 레이블을 붙여 분류합니다. 하지만 새 작업이 추가되면 분류기를 다시 훈련해야 하는 경직성이 있습니다.
기존 방식 2 (성능 기반): MMLU 같은 정적 벤치마크 점수에 의존합니다. 하지만 벤치마크 점수가 실제 사용자의 주관적인 선호도나 특정 도메인의 품질을 제대로 반영하지 못할 때가 많습니다.

반면 선호도 정렬 라우팅은 개발자가 자연어로 쓴 라우팅 정책(예: "계약서 조항 분석 -> GPT-4o", "간단한 여행 팁 -> Gemini Flash")에 기반합니다. 라우터 모델은 사용자의 쿼리를 이렇게 사람이 정한 선호도에 매핑하는 법을 배웁니다.

이 방식의 가장 큰 장점은 유연성입니다. 정책이 바뀌거나 새 모델이 추가되어도, 라우터 모델 자체를 재훈련할 필요 없이 설정 파일만 수정하면 됩니다.

Arch-Router는 사용자 의도를 도메인(주제)과 액션(작업)으로 분류하여 "programming 도메인과 code_generation 액션에는 DeepSeek-Coder 모델을 사용하라"와 같이 정책을 구조적으로 정의합니다. 이 결정은 평균 50ms 이내로 매우 빠르게 이루어지며, 1.5B의 작은 크기 덕분에 매우 효율적입니다.

Omni는 이 로직을 외부의 설정 가능한 JSON 파일로 분리했습니다.

이는 라우팅 정책을 바꾸거나 새 모델을 추가할 때 전체 앱을 재배포할 필요 없이 설정 파일만 수정하면 된다는 뜻입니다. 모델 선택을 하드코딩된 로직이 아닌, 설정 가능한 인프라의 문제로 다룹니다.

4. 장점, 그리고 아직 남은 과제

Omni는 115개 이상의 오픈소스 모델에 대한 단일 접근점을 제공하고, 사용자의 인지적 부담을 획기적으로 줄여주며, 다중 제공업체 설정으로 시스템 안정성을 높이는 등 수많은 강점을 지니고 있습니다.

물론, 한계와 개선점도 분명히 보입니다. 사용량이 많은 시간대에는 간헐적인 오류와 응답 지연이 보고되고 있어 확장성 개선이 필요합니다. 또한 장애 발생 시 수동으로 새로고침해야 하는 경우가 발생하는 등 장애 극복 메커니즘도 더 능동적으로 개선될 여지가 있습니다.

현재 Omni는 Hugging Face가 설정한 단일 글로벌 선호도를 모든 사용자에게 적용하고 있습니다.

하지만 이 기술의 핵심 철학은 원래 사용자 정의 선호도에 있습니다. Arch-Router 기술의 진짜 잠재력은 사용자가 "나는 코딩할 때 무조건 이 모델을 쓰고 싶어"처럼 자신의 고유한 요구사항에 맞춰 라우팅 정책을 자유롭게 정의할 수 있을 때 완전히 발현될 수 있을 것입니다.

현재 Omni는 이 기술의 가능성을 보여주는 훌륭한 개념 증명(PoC)이지만, 모두를 위한 하나의 정책이라는 점에선 기술 철학과 실제 구현 사이에 약간의 간극이 있는 셈입니다. 따라서 향후 로드맵에 포함된 '사용자 정의 정책' 기능이 필수적이라고 보고 있습니다.