Smart Routes로 요청 나눠 보내기

무엇을 하는 기능인가

모든 요청을 같은 모델로 보내면, 간단한 번역에도 가장 비싼 모델을 쓰게 됩니다. Smart Routes는 요청마다 알맞은 모델을 골라 보내고, 앱은 바뀌지 않는 모델 이름 하나만 계속 쓰게 합니다.

앱은 모델 자리에 다음 값을 넣습니다.

@route/<slug>

어느 모델로 보낼지에 대한 정책을 Nexus에서 바꿔도 연결된 앱은 손댈 필요가 없습니다.

업무 예를 들면(설명을 위한 예입니다), 사내 챗 앱이 @route/office 하나만 부르게 하고, 코드 관련 요청은 온라인의 성능 좋은 모델로, 요약과 번역은 사내 Mac의 로컬 모델로 보내는 식입니다.

화면은 Console Serving 묶음의 Smart Routes입니다.

Smart Route 하나의 구성

• 앱이 계속 쓸 수 있는 고정된 이름
• 믿을 수 있는 fallback 대상
• 일의 종류별 선택지인 lane (선택)
• 멀티모달 요청을 위한 이미지 fallback (선택)
• 모든 경로에 대한 Data Protection 동작

요청이 들어오면 Nexus는 맞는 lane을 고르거나 fallback을 씁니다. 대상은 모델 하나일 수도 있고 Smart Balancer 풀일 수도 있습니다. 후자의 경우 어떤 종류의 모델을 쓸지는 경로 정책이, 그 가운데 가장 상태가 좋은 곳이 어디인지는 balancer가 정합니다.

라우터 준비하기

Smart Routes는 작은 로컬 분류기를 씁니다. 경로를 정하려고 요청을 다른 온라인 서비스로 보낼 필요가 없게 하려는 것입니다.

1. Smart Routes를 엽니다.
2. Prepare router를 고릅니다.
3. 호환되는 로컬 런타임을 고릅니다. MLX, llama.cpp, Ollama가 예로 나와 있습니다.
4. 지원되는 경우 Nexus가 분류 모델을 설치하거나 설정하게 둡니다.
5. 준비가 끝날 때까지 유효한 fallback 모델을 하나 유지합니다.

라우터를 쓸 수 없으면 Nexus는 설정된 fallback을 씁니다. 앱이 보낼 곳을 잃지는 않습니다.

Smart Route 만들기

기본 제공되는 route에서 시작하거나, 빈 설정에서 직접 만듭니다.

1. 알아보기 쉬운 이름과 바뀌지 않을 slug를 정합니다.
2. 기본 fallback을 지정합니다.
3. 다른 대상을 써야 하는 일의 종류마다 선택지(lane)를 추가합니다.
4. 선택지마다 When to use it 설명을 분명하게 씁니다.
5. 선택지마다 모델 또는 Smart Balancer 풀을 배정합니다.
6. 가능한 모든 경로에 대해 Data Protection을 검토합니다.
7. 대표적인 프롬프트로 시험한 뒤 검증하고 켭니다.
8. @route/<slug> 값을 앱의 모델 이름으로 씁니다.

문서는 첫 route를 일부러 작게 만들라고 권합니다. 믿을 만한 fallback 하나와 뜻이 분명한 lane 한두 개면 충분합니다. 복잡하게 만드는 것은 실제 트래픽에서 뚜렷한 이유가 보일 때로 미룹니다.

lane 설명 쓰는 법

경로가 엉뚱하게 잡히는 원인은 대부분 설명에 있습니다. 문서가 가장 길게 다루는 부분입니다.

설명이 하는 일

앱이 @route/<slug>를 보내면 요청은 그 Smart Route로 들어옵니다. 그 뒤 Nexus는 요청을 각 선택지의 이름과 When to use it 설명에 견줍니다. 이 설명이 그 lane에 무엇이 속하는지를 알려 주는 주된 근거입니다.

slug는 분류에 영향을 주지 않습니다. slug는 바뀌지 않고 읽기 쉽게 정하면 되고, 분류 지시로 쓰려고 하면 안 됩니다.

요청된 “행동”을 중심으로 쓴다

메시지의 주제나 대상 모델의 강점이 아니라, 사용자가 무엇을 해 달라고 하는지를 적습니다. 좋은 설명에는 보통 다음이 들어갑니다.

• 주된 행동: 작성, 디버깅, 요약, 번역, 분석, 추출 등
• 함께 묶일 만한 가까운 예 몇 가지
• 다른 lane과 헷갈릴 수 있을 때의 경계
• 다른 선택지와 뚜렷이 구별되는 구체적인 표현

문서의 예시를 뜻만 옮기면 이렇습니다.

선택지	설명의 방향	좋은 이유
Code	코드를 쓰고, 고치고, 다듬고, 설명하는 일. API, 오류, 스택 추적 포함	행동과 그에 딸린 여러 형태를 함께 적었습니다
Summarize	주어진 글, 문서, 회의록, 코드를 요약. 코드를 고쳐 달라는 요청에는 쓰지 않음	코드 요약과 코드 수정의 경계를 그었습니다
Translate	사용자가 준 글을 뜻과 형식을 지키며 다른 언어로 옮김	글의 주제가 아니라 요청된 변환을 적었습니다
Deep analysis	근거를 비교하고, 장단점을 따지고, 여러 단계의 추론으로 자세한 결론을 내는 일	“복잡한 요청”이라고만 하지 않고 눈에 보이는 일을 적었습니다

피해야 할 설명도 문서에 나와 있습니다. “가장 좋은 모델을 쓴다”, “어려운 질문”, “일반적인 요청”, “기술에 관한 모든 것” 같은 표현, 그리고 여러 선택지가 모두 “분석”, “복잡한 작업”, “높은 품질”이라고만 적는 경우입니다. 이런 설명은 분류할 근거가 너무 적거나 서로 심하게 겹칩니다.

붙여 넣은 내용보다 의도가 우선

Nexus는 요청 전체에서 사용자가 하려는 행동을 분류하려고 합니다. 붙여 넣은 코드, 문서, 인용문, 제목, 예시는 “작업할 재료”로 보고, 그것 자체를 작업으로 여기지 않습니다.

• “이 SQL 마이그레이션을 요약해 줘”는 요약 lane에 맞아야 합니다. 코딩 lane이 아닙니다.
• “이 오류 메시지를 스페인어로 번역해 줘”는 내용이 오류에 관한 것이어도 번역입니다.
• “이 함수의 버그를 고쳐 줘”는 코드를 바꾸는 것이 요청된 행동이므로 코딩입니다.

설명은 이런 경계가 분명히 드러나게 씁니다.

fallback을 의도적으로 쓴다

기본 fallback은 네 경우에 요청을 받습니다.

• 뚜렷하게 맞는 선택지가 없을 때
• 라우터가 요청을 분류하지 못할 때
• 고른 선택지가 설정된 대상을 쓸 수 없을 때
• 요청 종류가 그에 맞는 엔드포인트용 fallback을 필요로 할 때

fallback은 믿을 수 있는 범용 모델로 고릅니다. fallback과 똑같은 일을 하는 “무엇이든 받는” lane은 만들지 않습니다. 넓은 lane이 있으면 좁은 설명들이 구별되기 어려워집니다.

켜기 전에 시험하기

Prompt lab의 Try a prompt로 요청이 어디로 갈지 미리 봅니다. 미리 보기는 라우터에만 묻습니다. 대상 모델을 부르지 않고, 프롬프트를 저장하지도 않습니다.

적어도 다음 네 가지는 시험합니다.

• 선택지마다 누가 봐도 분명한 예 하나씩
• 두 선택지에 걸칠 수 있는 경계 사례
• fallback으로 가야 하는 요청
• 다른 범주의 내용을 붙여 넣은 요청

엉뚱한 선택지로 간다면 모델을 바꾸기 전에 설명부터 다듬습니다. 검증(validation)은 설정과 대상이 쓸 수 있는 상태인지를 확인하고, 프롬프트 시험은 설명이 일을 정확히 묘사하는지를 확인합니다. 둘은 확인하는 것이 다릅니다.

결정을 들여다보는 세 화면

탭	보여 주는 것
Live	요청 속도, lane 선택, fallback, 최근 경로 결정
Insights	충분한 자료가 쌓였을 때, 나눠 보낸 트래픽과 fallback을 품질·지연 시간·비용 근거로 비교
Routes	경로 대상, lane, 보호 동작, 켜짐 상태 관리

요청 기록에는 경로 결정을 설명하는 데 필요한 정보만 남고, 프롬프트와 응답 본문은 저장되지 않습니다.

대화의 연속성

Nexus는 지원되는 요청 형식에서 대화의 정체를 파악해, 이어지는 턴을 쓸모 있는 같은 대상에 두려고 합니다. 이렇게 하면 프롬프트 캐시가 유지되고, 바뀌지 않는 앞부분을 다른 대상에서 되풀이해 처리하지 않아도 됩니다.

일의 성격이 크게 바뀌면, Nexus는 같은 대상을 고집하기보다 더 나은 lane을 고를 수 있습니다.

민감한 데이터 보호

보호를 건 lane과 fallback마다 Nexus가 어떻게 할지 정합니다.

• 정리된(cleaned) 요청을 보낸다
• 요청을 막는다
• 지정한 민감 데이터용 경로로 보낸다

보호 점검 자체가 실행되지 못할 때의 동작도 고릅니다. 원본 요청을 그대로 보내면 민감한 내용이 드러날 수 있으므로, 대상과 업무 흐름이 허용할 때만 그렇게 설정합니다. 설정 방법은 Data Protection에 있습니다.

보호 대상 데이터를 온라인 제공업체나 원격 기기로 보내기 전에는 Nexus 보안 모델을 읽어 두라고 문서는 권합니다.

한도와 요금제 변경

Smart Routes 문서가 적은 한도입니다.

요금제	활성 Smart Route 수
Free	2개
Pro	무제한
Enterprise	계정에 배정된 한도

Free에서 세 번째 활성 route를 만들거나 켜려고 하면 Nexus가 Runtime API 단계에서 막습니다.

한도가 더 낮은 요금제로 옮기면, Nexus는 남는 route의 설정은 보관하되 실행되지 않게 합니다. route, 자격 증명, 모델, 사용 기록은 지워지지 않습니다.

한 가지 알아 둘 점이 있습니다. Nexus 요금 페이지의 비교표는 Free의 Smart Routes를 3으로 적어, 문서의 “활성 2개”와 다릅니다. 어느 쪽이 지금 제품과 맞는지는 공식 자료만으로 판단할 수 없으므로, 실제 앱에서 확인하는 편이 정확합니다. 요금제별 차이는 Nexus 요금제별 기능 차이에 모았습니다.

참고한 문서

• Nexus 문서: Smart Routes
• Nexus 문서: Presets
• Msty Nexus 요금