멀티모델 자동 라우팅이 부딪힌 지연과 검증의 벽

19일 오후 2시 55분, 에이전트코리아에서 한 참가자가 자신이 만들고 있는 구조를 설명하며 비슷하게 해 본 사람을 찾았다.

안녕하세요 개인 pc에 hermess 랑 omniroute 통해서 여러 모델 oauth나 api 전환 가능한 구조를 만들어보고 있는데 생각보다 원활하지 않아서 혹시 비슷하게 만들어보신분 계실까요?

여기서 hermess(대화 후반에는 헤르메스로도 적혔으며 같은 도구로 보인다)와 omniroute는 질문에 나온 도구 이름이며, 대화에서 그 기능이 따로 설명되지는 않았다. 이 토픽에는 일곱 명이 56건의 발화를 남겼다. 오후 3시 25분 무렵까지가 라우팅 이야기였고, 이후 대화는 소형 모델 학습 쪽으로 넘어갔다.

이 질문에 가장 먼저 경험을 들려준 것은 한 답변자였다. 오후 2시 57분, 그는 직접 만들었을 때 라우팅이 깔끔하지 않아 자신은 팀코덱스로 통일했다고 했다.

직접 만들었을때 라우팅이 생각보다 깔끔하지 않아서 저도 그냥 팀코덱스로 통일했습니다

팀코덱스의 정확한 정의는 대화에서 설명되지 않았다.

질문자가 그린 구조

질문자는 이어서 자신의 구조를 풀어 썼다. 라우터가 알아서 모델 선택까지 해 주는 방식이고, GPT, 제미나이, 클로드를 연결해 두었다고 했다. 목표는 지휘 역할을 하는 오케스트레이터를 가장 비용이 높은 모델로 고정해 두고, 그 아래 서브에이전트(작업을 나눠 맡는 보조 AI)가 쓰는 모델만 자동으로 고르게 하는 것이라고 했다.

이와 비교해 다른 답변자는 자기도 헤르메스(앞의 hermess와 같은 도구로 보인다)를 쓰지만 그록, 클로드, GPT를 연결해 놓고 쓰임에 따라 방을 따로 만들어 쓴다고 했다. 이는 모델 선택을 라우터에 맡기는 방식이 아니라 사람이 용도별로 나누는 방식으로 보인다. 질문자도 자신의 방식은 조금 다른 것 같다고 답했다.

앞단 선택, 비용, 추적

지적은 또 다른 답변자에게서 이어졌다. 앞단에서 모델을 고르게 하면 그 선택 단계의 시간 초과가 가장 큰 문제라고 했다.

저렇게 하면 발생하는 문제가 결국 앞단 모델선택시 timeout이

그는 비용 최적화 문제도 있어 라우터를 붙이는 일은 많지만, 추적도 너무 빡빡하다고 말했다. 다른 참가자가 매번 다른 모델을 고르다 보니 세션 안에서도 계속 달라져서 추적이 어려운 것이냐고 묻자 이 질문에 대한 직접적인 답은 이 토픽에 없었다. 계정을 연결하는 방식이면 컨텍스트 전환이 함께 연결되어 있어 오류가 날 확률이 높다는 지적도 나왔고, 질문자는 정확히 그 부분이 큰 벽이라고 인정했다.

질문자는 옵시디언 같은 것으로 중앙 데이터베이스를 꾸려 써 보려 했다고 했다. 이에 대해 같은 답변자는 그 방식은 별로라며 인계 규칙을 정해 좀 더 가볍게 생성되는 쪽을 권했다. 질문자가 말한 구조는 추천하지 않으며 오케스트레이션과 서브에이전트 구조가 가장 편하다고도 했다.

검증이 더 어렵다는 말

대화 중반에 합류한 참가자는 지난주 라이브에서 다른 사람과도 이 이야기를 해 봤다며, 그 상대도 굳이 성능 효과를 못 느끼겠다고 했다고 전했다. 이 부분은 전해 들은 이야기이다. 같은 참가자는 사실 검증이 어렵기도 하다며 자기 의견도 이렇게 밝혔다. 앞서 지적한 답변자도 오토라우팅을 굳이 해야 할 이유가 있느냐며 동의했고, 토큰을 태울 만한 효용이 나오면 하겠다고 했다.

근데 어떤 요청인지에 따라서 모델 라우팅을 동적으로 한다는건 생각보다 어려운일이고 검증이 더 어렵죠

합류한 참가자는 일을 코드로 물리적으로 나눠 놓는 것은 이미 한 도구에 있고 어렵지 않으며, 토큰 절약이 목적이라고 했다. 다만 가능은 하다며 방법도 짚었다. 자신이 써 온 로그를 오픈클로에게 주고 일을 분류하게 해 데이터셋부터 만들라는 것이다. 오픈클로가 무엇인지는 대화에서 설명되지 않았다. 앞서 지적한 답변자는 캐시 쪽에서도 손해가 크고 이것이 가장 큰 문제라고 봤고, 컨텍스트 토큰이 녹는다는 우스갯소리와 함께 KV 캐시(모델이 앞선 대화를 기억해 두는 임시 저장)라고 바로잡았다. 모델을 바꿀 때 캐시가 얼마나 손해인지 수치는 이 토픽에 나오지 않았다.

해석

이 대화에서 자동 라우팅의 이점을 직접 입증한 발언은 보이지 않는다. 대신 앞단 선택의 시간 초과, 비용 최적화의 번거로움, 매번 달라지는 선택의 추적, 계정 연결에 따른 컨텍스트 전환의 오류 가능성, 캐시 손해, 효과를 증명하기 어렵다는 점이 차례로 나왔다. 다만 가능은 하다는 의견(데이터셋을 만들어 작은 모델을 학습시키는 길)과 효율에는 의문이 함께 나왔다는 점도 같이 적어 둔다. 답변자들이 제시한 대안은 한 도구로 통일하거나, 오케스트레이션과 서브에이전트 구조를 유지하거나, 코드로 나누는 쪽이었다.

따라서 이 문답은 자동 라우팅의 실패 사례가 아니라, 실제로 만들려는 사람에게 돌아온 경험담의 목록으로 읽는 편이 안전하다. 일곱 명의 대화이고 각 지적에 구체적인 측정값은 없었다. 어느 한계가 가장 결정적인지는 이 대화만으로 판단하기 어렵다.