엔비디아 네모 스위치야드와 LiteLLM을 활용한 아마존 베드록 코딩 에이전트 모델 라우팅 구현

에이전트 라우팅 구조 도입

아마존웹서비스 인프라 환경에서 엔비디아 네모 스위치야드(NVIDIA NeMo Switchyard)와 오픈소스 모델 게이트웨이 LiteLLM을 통합해 아마존 베드록(Amazon Bedrock) 모델로 에이전트 요청을 분기하는 참조 구현이 공개되었다. 이 구성은 클로드 코드(Claude Code)나 오픈에이아이 코덱스 콘솔 도구처럼 반복 작업으로 코드를 수정하는 코딩 에이전트가 상황에 따라 고성능 모델과 저비용 효율형 모델을 오가도록 경로를 지정한다. 클라우드 개발 키트를 통해 컨테이너 기반 인프라를 자동으로 배포하며, 단일 모델 배포군과 라우팅 적용 배포군의 작업당 비용을 직접 비교할 수 있는 측정 도구도 함께 제공된다.

코딩 에이전트는 단순 질의응답과 달리 파일을 읽고 코드를 고치며 단위 테스트를 수행하는 다중 턴 작업을 수행한다. 이때 전체 비용은 개별 토큰 단가보다 작업 완료에 필요한 왕복 횟수, 매 턴마다 다시 전달되는 대화 이력의 크기, 실패 후 재시도 빈도에 더 큰 영향을 받는다. 끝내 해결되지 못한 실패 작업에도 모든 호출 비용이 청구되므로, 모델 선택의 경제성을 판단할 때는 단순 호출 단가가 아니라 테스트를 통과한 실행 횟수 대비 총비용인 해결된 작업당 비용을 핵심 지표로 삼아야 한다는 배경에서 이번 방안이 도출되었다.

단계적 모델 전환 아키텍처

핵심 분기 방식인 단계(Stage) 라우팅은 요청에 포함된 최근 도구 실행 내역을 분석해 두 개의 후보 모델 중 하나를 동적으로 결정한다. 대화 기록이 없거나 실행 신호가 모호한 초기 상태에서는 효율 우선 설정에 따라 네모트론 3 슈퍼 120B(Nemotron 3 Super 120B) 같은 저비용 모델로 요청을 먼저 전달한다. 반면 도구 실행 결과에서 반복적인 오류나 실패 신호가 임계값을 넘어서면 클로드 오푸스 5.5(Claude Opus 5.5) 같은 고성능 모델로 승격하여 작업을 처리하도록 유도한다. 이 외에도 지정한 가중치에 따라 트래픽을 분할해 비교하는 무작위 분기 방식도 선택할 수 있다.

전체 시스템은 보안을 고려해 아마존 엘라스틱 컨테이너 서비스(Amazon ECS)의 프라이빗 서브넷 내부에서 단일 컨테이너로 동작하도록 설계되었다. 애플리케이션 로드 밸런서는 장시간 이어지는 에이전트 응답을 지원하기 위해 10분의 유휴 제한 시간을 유지하며, 웹 애플리케이션 방화벽을 통해 인터넷 프로토콜 평판 기반 차단과 5분당 2000건의 주소별 요청 제한을 적용한다. 특히 코딩 에이전트가 전송하는 소스 코드가 오탐되지 않도록 일반적인 크로스 사이트 스크립팅이나 에스큐엘 주입 검사 규칙은 본문 필터링에서 제외하고, 추론 트래픽은 가상 사설망 내부 인터페이스 엔드포인트를 거쳐 외부망 노출 없이 아마존 베드록 대화형 인터페이스로 전달된다.

해결된 작업당 비용 측정

제공되는 벤치마크 실행 스크립트는 슬러그 생성, 로마자 변환, 수식 분석기 작성, 만료 시간 지원 캐시 구현 등 다양한 난이도의 프로그래밍 과제를 수행하며 모델 성능을 계측한다. 에이전트가 코드를 수정하고 단위 테스트를 통과하기까지 소모된 모델별 토큰 사용량을 집계하여, 전체 시도 비용을 통과한 작업 수로 나눈 수치를 모델 그룹별로 산출한다. 이를 통해 복잡한 과제에서 무조건 고성능 모델만 사용하는 방식이나 저렴한 모델 단독 사용 방식에 비해 혼합 라우팅이 실제 비용 대비 성공률에서 유리한지 객관적으로 검증할 수 있다.

결과 분석 시에는 작업당 평균 비용보다 해결된 작업당 비용을 우선 확인해야 한다. 통과 작업이 적은 모델은 개별 작업 비용이 낮아 보여도 실패한 시도가 누적되어 최종 해결당 비용이 오히려 급증할 수 있기 때문이다. 특히 난이도가 높은 과제는 실패 기록이 누적된 뒤에야 고성능 모델로 승격되므로, 이 과정에서 실패한 이전 기록 전체가 다시 전송되어 처음부터 고성능 모델을 사용했을 때보다 오히려 지출이 커질 가능성도 존재한다. 따라서 작업 난이도별 세부 지표를 분리해 관찰하고 통계적 유의성을 확보할 수 있을 만큼 충분한 반복 측정을 거쳐야 한다.

적용 조건과 아키텍처 한계

이 시스템을 활용하려면 배포 환경에 대한 전제 조건과 기술적 제약을 미리 확인해야 한다. 단계 라우팅 플러그인은 반드시 고성능 모델과 효율형 모델 두 개로만 후보군을 구성해야 하며, 중간 판단 모델을 호출해야 하는 작업 분류기나 복합 라우팅 전략은 현재 구조에서 지원되지 않는다. 아울러 클라이언트는 반드시 전체 대화와 도구 실행 기록을 보존하여 전송해야 정상적인 분기 판정이 이루어지며, 기본 로드 밸런서는 일반 대화 완성 경로만 전달하므로 다른 형태의 메시지 인터페이스를 사용하는 클라이언트는 추가 경로 설정이 필요하다.

공개된 구성 요소 역시 평가용으로 명시되어 있어 운영 환경 도입에는 한계가 따른다. 스위치야드 서버 0.3.0 버전과 LiteLLM 플러그인 통합은 데모 및 평가 목적의 실험적 단계로 향후 설정 규격이나 연동 방식이 변경될 수 있다. 또한 단계 라우팅은 사후 실패 기록에 의존하므로 난이도가 높은 작업을 사전에 예측해 고성능 모델로 즉시 할당하지 못한다. 로컬 환경에서 실행되는 벤치마크 스크립트의 경우 생성된 코드를 별도의 운영체제 격리 공간 없이 직접 실행하므로 장기 인증 정보가 없는 독립된 개발 환경에서만 다루어야 한다.