엔비디아, 코딩 에이전트용 LLM 라우팅 프록시 '스위치야드' 공개

1. 런처 경로 — 클로드 코드, 코덱스 CLI, OpenClaw 같은 코딩 에이전트를 스위치야드를 거쳐 실행한다. 파이썬 패키지 관리 도구 uv가 없으면 먼저 설치한 뒤, 공개된 스위치야드 툴을 설치하고 오픈라우터 키를 설정해 패키지된 배포판을 실행한다. 자체 TOML 설정을 쓰려면 라우트 ID와 구성 파일을 지정하면 된다.
2. 서버 경로 — 스위치야드를 독립 프록시로 띄우는 방식이다. Rust와 Cargo를 설치한 뒤 공개된 바이너리를 설치하면 기본적으로 ~/.cargo/bin에 실행 파일이 생긴다. routes.toml 설정 파일을 만들어 검증하고 서버를 시작하는 순서다.
3. 라이브러리 경로 — switchyard-libsy를 자신의 러스트 애플리케이션에 임베드한다. 이 라이브러리는 모델을 직접 호출하지 않는다. 어느 대상을 쓸지만 결정하고 실제 호출은 호출자에게 돌려주므로, 기존 프록시나 게이트웨이, 에이전트 런타임에 HTTP 스택을 새로 얹지 않고도 끼워 넣을 수 있다.

경로	대상	설치 전제
런처	Claude Code, Codex CLI, OpenClaw 사용자	uv
서버	독립 프록시로 운용하려는 팀	Rust, Cargo
라이브러리	자체 러스트 앱에 라우팅 내장	Rust 프로젝트

지금 상태는 프로덕션 이전

프로젝트 설명은 "Experimental software. Not for production use."(실험적 소프트웨어이며 프로덕션 용도가 아니다)라고 명시하고 있다. 프리알파 단계라 v1.0에 도달하기 전까지 API와 라우팅 알고리즘이 크게 바뀔 것으로 예상된다는 설명도 함께 붙어 있다. 라이선스는 Apache 2.0이며 저작권자는 엔비디아로 표기돼 있다.

무엇을 해볼 수 있나

예를 들어 팀 내부에서 클로드 코드를 표준 도구로 쓰되, 민감한 코드베이스는 자체 호스팅한 오픈소스 모델로 처리하고 일반 작업만 상용 모델로 보내는 식의 분기가 가능해진다. 또는 같은 프롬프트를 여러 오픈소스 모델에 동시에 흘려보내 응답 품질과 지연 시간을 비교하는 벤치마크 용도로도 쓸 수 있다. 신호 기반 단계 라우팅을 쓰면 응답 실패율이 높아질 때 자동으로 다른 모델로 넘기는 구성도 만들 수 있다.

에디터의 시선

엔비디아는 칩 회사지 챗봇 회사가 아니다. 그런데도 이런 라우팅 프록시를 자체 GitHub 조직에서 내놓는 이유는 단순하다 — 오픈소스 모델이 늘어날수록 그 모델을 돌릴 하드웨어를 파는 쪽이 유리해지기 때문이다. 개발자가 클로드나 GPT 대신 자체 호스팅한 모델을 더 쉽게 쓰게 만들수록, 그 모델을 굴리는 GPU 수요도 함께 늘어난다. 스위치야드는 결국 엔비디아가 자사 칩 위에서 돌아가는 vLLM·NIM 같은 서빙 스택을 코딩 에이전트 생태계와 더 가깝게 붙이려는 움직임으로 읽힌다.

비슷한 시도는 이미 여럿 나와 있다. Unsloth Desktop이 클로드 코드와 코덱스를 로컬 LLM에 연결하는 데스크톱 앱을 냈고, LiteLLM 같은 프로젝트도 API 형식 변환을 오래전부터 해왔다. 스위치야드가 다른 점은 러스트로 짠 저수준 프록시라는 점과, 라우팅 알고리즘을 직접 짜 넣을 수 있는 라이브러리 형태까지 함께 제공한다는 점이다. 다만 프리알파 단계 소프트웨어를 팀의 코딩 에이전트 앞단에 바로 붙이는 것은 아직 이르다. 개인 실험 환경에서 vLLM이나 Ollama로 돌아가는 오픈소스 모델과 클로드 코드를 연결해 A/B 비교를 해보는 정도가 지금 시점에 맞는 사용법이다. 라우팅 로직이 바뀌는 v1.0 이전까지는 프로덕션 트래픽을 맡기지 않는 편이 안전하다.

앞으로 몇 주 안에는 이 프록시를 실제 사내 에이전트 파이프라인에 붙였다는 사례들이 GitHub 이슈나 커뮤니티에 올라올 가능성이 크다. 그 피드백이 얼마나 빨리 반영되느냐가 이 프로젝트가 실험용 도구로 남을지, 팀들이 실제로 채택하는 인프라로 자리 잡을지를 가를 것이다.