“어떤 모델을 호출해야 할까요?”라는 질문은 한때 API에 관한 질문처럼 들렸다. 하지만 점점 더 많은 조직에서 이는 조달, 성능 엔지니어링, 아키텍처에 관한 질문에 가까워지고 있다.
이러한 변화는 단순한 발전에 따른 것이다. 이제는 많은 제공업체가 다양한 모델을 제공하며, 모델마다 실질적으로 다른 강점, 가격, 지연 시간 특성, 배포 옵션, 계약 조건을 갖고 있다. Stripe가 OpenRouter를 인수하기로 발표한 계약은 유용한 신호다. OpenRouter의 단일 API는 80개가 넘는 제공업체의 400개가 넘는 모델을 아우르며, 작업 복잡도, 가격, 속도, 안정성, 지연 시간, 처리량, 제공업체별 비용 등을 라우팅 기준으로 포함한다.
새롭게 부상하는 역할이 반드시 새로운 직함으로 나타나는 것은 아니다. AI 플랫폼 엔지니어링, 아키텍처, 조달, 추론 운영 또는 제품 엔지니어링에 걸쳐 자리할 수 있다. 그러나 그 책임은 점점 분명해지고 있다. 어떤 모델이 어떤 작업을 처리해야 하는지, 어떤 제약 조건과 대체 경로를 적용할지, 어떤 근거를 바탕으로 결정하는 것이다.
라우팅은 인프라로 위장한 정책 결정이다
순진한 라우터는 “어떤 모델이 가장 저렴한가?”라고 묻는다. 유용한 라우터는 더 구체적으로 묻는다. “이 요청의 품질, 지연 시간, 안정성, 개인정보 보호, 운영 요구 사항을 충족하는 모델 중 가장 비용이 적게 드는 모델은 무엇인가?”
이러한 요구 사항은 작업마다 다르다. 고객 지원 분류기에는 예측 가능한 구조화된 출력과 짧은 지연 시간이 필요할 수 있다. 어려운 코딩 작업에는 더 느리지만 성능이 뛰어난 모델을 사용할 만한 이유가 있다. 대규모 요약 파이프라인에서는 더 작은 모델을 선호할 수 있으며, 특히 테스트 후 품질이 충분한 경우에는 더욱 그렇다. 규제를 받는 워크플로에서는 토큰 가격과 관계없이 특정 지역, 보존 정책 또는 제공업체 계약이 필요할 수 있다.
이 때문에 라우팅은 애플리케이션 코드에만 속하는 것이 아니라 아키텍처 검토에 포함되어야 한다. 라우팅 경로는 청구서 이상의 것을 결정한다. 데이터 거주성, 장애 노출, 관측 가능성, 응답 일관성, 도구 사용 방식, 그리고 이후 단계에서 필요한 사람의 검토량에 영향을 줄 수 있다.
진지한 라우팅 기능을 뒷받침하는 네 가지 분야
1. 조달: 눈에 띄는 토큰 가격이 아니라 서비스 전체를 비교하라
모델 가격은 쉽게 잘못 비교할 수 있다. 입력 토큰과 출력 토큰의 요율이 다를 수 있다. 캐시된 입력, 배치 처리, 우선 서비스, 긴 컨텍스트 요청은 계산을 바꿀 수 있다. 또한 제공업체의 명목 가격만으로는 재시도, 속도 제한, 지원, 최소 약정, 이그레스 비용 또는 전환에 드는 엔지니어링 비용을 거의 알 수 없다.
라우팅 담당자는 다음과 같은 항목을 포함한 모델 및 제공업체 목록을 관리해야 한다.
- 입력, 출력, 캐시, 배치 가격;
- 컨텍스트 및 출력 제한;
- 문서화된 속도 제한 및 관찰된 처리량;
- 단순한 평균 지연 시간이 아니라 지연 시간 분포;
- 가용성 및 타임아웃 동작;
- 데이터 사용, 보존, 거주성 및 계약 조건;
- 도구 호출, 구조화된 출력, 비전, 스트리밍을 포함한 지원 기능;
- 대체 경로 및 마이그레이션 옵션.
그 결과물은 모델 이름 목록이라기보다 기술 자재 명세서에 가깝다. 가격, 정책, 모델 버전 또는 비즈니스 규모가 바뀔 때 검토해야 한다.
2. 성능 엔지니어링: 리더보드가 아니라 작업을 측정하라
일반 벤치마크는 방향을 잡는 데 도움이 될 수 있지만, 라우팅 결정에는 워크로드별 테스트가 필요하다. 공개 코딩 벤치마크에서 좋은 성능을 보이는 모델이 조직의 내부 저장소, 명명 규칙, 도구 스키마 또는 보안 통제에 가장 적합한 선택이라는 보장은 없다.
민감한 자료를 제거하거나 통제한 실제 요청으로 대표성 있는 평가 세트를 구축하라. 사실 정확성, 유효한 JSON, 성공적인 도구 선택, 코드 테스트 성공, 거부 동작, 에스컬레이션 필요 여부, 허용 가능한 스타일 등 중요한 결과에 라벨을 지정하라. 그런 다음 비용, 첫 토큰까지 걸리는 시간, 총 지연 시간, 타임아웃 비율, 재시도 비율, 완료 길이를 기록하라.
결과를 너무 일찍 하나의 점수로 통합하지 마라. 가중 점수는 심각한 실패 양상을 가릴 수 있다. 예를 들어 평균 품질은 뛰어나지만 형식이 잘못된 도구 호출이 자주 발생하는 모델은 자동화된 워크플로에 적합하지 않을 수 있다. 답변이 값비싼 사람의 검토를 줄여 준다면 더 느린 모델이 경제적으로 더 나을 수도 있다.
챔피언-도전자 프로세스를 사용하라. 현재 승인된 경로를 유지하고, 동일한 코퍼스를 대상으로 대안을 테스트하며, 도전자가 명시적인 품질 및 운영 임계값을 충족할 때만 승격하라. 제공업체가 보고한 주장은 해당 모델이 여러분의 환경에서도 비슷하게 수행될 것이라는 증거가 아니라 테스트 계획에 반영할 입력으로 취급해야 한다.
3. 아키텍처: 모델 선택을 교체 가능하게 만들기
모델별 가정이 애플리케이션 전반에 스며들면 라우팅 비용이 커진다. 탄력적인 설계는 비즈니스 작업과 공급자 호출을 분리한다.
내부 기능 계약을 정의한다. 여기에는 “분류” 작업이 고정된 스키마, 신뢰도 또는 응답 거부 필드, 모델 식별자, 추적 식별자를 반환해야 한다는 내용이 포함될 수 있다. “초안 응답” 작업에는 어조 제약, 인용 요건, 최대 지연 시간 예산을 지정할 수 있다. 그러면 공급자 어댑터가 이 계약을 개별 API에 맞게 변환한다.
프롬프트, 스키마, 도구 정의, 안전 규칙, 라우팅 정책을 버전 관리한다. 각 요청을 어떤 모델 스냅샷과 공급자가 처리했는지 기록한다. 민감한 사용자 콘텐츠를 불필요하게 보존하지 않으면서도 결정을 재현할 수 있을 만큼 충분한 정보를 보존한다.
폴백을 신중하게 설계한다. 폴백은 다른 공급자, 더 작은 모델, 대기열에 넣는 워크플로, 또는 사람의 검토 경로일 수 있다. 폴백이 작업의 의미를 몰래 바꾸어서는 안 된다. 구조화된 출력이 필수라면 폴백도 동일한 계약을 지원하거나 통제된 에스컬레이션을 시작해야 한다.
4. 거버넌스: 언제 자동으로 라우팅하지 않을지 결정하기
일부 요청은 이용 가능한 가장 저렴한 모델에 보내서는 안 되며, 외부 모델에 전혀 보내서는 안 되는 경우도 있다. 라우팅 정책에는 기밀 데이터, 영향이 큰 의사 결정, 지원되지 않는 언어, 이례적으로 긴 컨텍스트, 또는 사람의 승인 절차가 필요한 작업에 대한 제외 규칙이 필요하다.
팀은 또한 모델을 기술적으로 사용할 수 있는 상태와 특정 용도로 승인된 상태를 구분해야 한다. 조달 및 법적 요건은 사업 부문마다 다를 수 있다. 평가에서 뛰어난 성능을 보인 모델이라도 데이터 처리 약관이 조직에 적합하지 않은 워크플로에서는 사용할 수 없을 수 있다.
실용적인 라우팅 표
시작 정책은 간단하고 명시적으로 정할 수 있다:
| 작업 분류 | 주요 목표 | 가능한 경로 | 에스컬레이션 조건 |
|---|---|---|---|
| 대량 추출 | 유효한 스키마와 낮은 단위 비용 | 엄격한 출력 검증을 적용하는 소형 또는 중형 모델 | 스키마 오류 또는 낮은 신뢰도 |
| 복잡한 분석 | 품질과 근거 처리 | 더 큰 지연 시간 예산을 가진 고성능 모델 | 근거 부족, 모호성 또는 정책 플래그 |
| 대화형 지원 | 빠르게 느껴지는 응답 | 낮은 지연 시간의 모델을 사용하고, 필요하면 이어서 다듬기 | 낮은 확신도 또는 사용자가 심층적인 답변을 요청한 경우 |
| 민감한 워크플로 | 승인된 데이터 처리 및 감사 가능성 | 계약상 승인된 제공업체 또는 통제된 배포 | 승인되지 않은 데이터, 작업 또는 관할권 |
정확한 표는 조직마다 달라질 것이다. 중요한 점은 라우팅 규칙을 조건문 속에 묻어두지 말고 제품, 보안, 재무, 엔지니어링 이해관계자가 읽고 이해할 수 있도록 해야 한다는 것이다.
커리어를 쌓는 사람들에게 이것이 의미하는 것
이 업무에 가장 적합한 후보자들은 여러 종류의 능숙함을 결합할 것이다. 역량과 성능 저하를 판단할 수 있을 만큼 머신러닝을 이해하고, 지연 시간, 재시도, 속도 제한, 장애 양상을 관리할 수 있을 만큼 시스템 엔지니어링을 이해하며, 총비용을 모델링할 수 있을 만큼 재무를 이해하고, 제공업체의 약속과 제한을 평가할 수 있을 만큼 조달 및 거버넌스를 이해해야 한다.
또한 의사결정 기록을 작성하는 데 익숙해야 한다. 유용한 기록에는 왜 특정 경로를 선택했는지, 어떤 증거가 이를 뒷받침하는지, 어떤 위험이 남아 있는지, 그리고 어떤 사건이 재평가를 촉발해야 하는지가 설명되어 있다. 모델 이름과 가격은 계속 바뀔 것이므로, 이는 최신 모델 이름을 암기하는 것보다 더 가치 있다.
대규모 프로덕션 시스템 없이도 간결한 포트폴리오 프로젝트로 이러한 역량을 보여줄 수 있다. 하나의 워크로드를 정하고, 비식별화된 평가 세트를 만들고, 공통 인터페이스 뒤에 세 개의 모델 제공업체 또는 로컬 모델을 연결한 다음, 여러 사용량 수준에서 품질, 스키마 유효성, 지연 시간 백분위수, 실패율, 예상 월간 비용을 비교해 보라. 민감한 입력에 대한 정책 규칙과 폴백 경로를 추가하라. 테스트 방법론과 한계를 공개하라.
프로젝트가 무엇을 입증하는지 정확히 밝혀라. 하나의 모델이 보편적으로 가장 뛰어나다는 것을 입증하는 것은 아니다. 모호한 모델 선택 문제를 측정 가능한 운영 정책으로 전환할 수 있다는 것을 입증하는 것이다.
커리어 신호
인텔리전스는 더 이상 하나의 고정된 종속성이 아니기 때문에 모델 라우팅은 전략적으로 중요해지고 있다. 인텔리전스는 서로 다른 트레이드오프와 변화하는 경제성을 지닌 서비스 포트폴리오다. 이 포트폴리오를 상호 교체 가능한 인프라로 취급하는 팀은 비용을 줄일 수 있지만, 숨겨진 품질, 규정 준수, 신뢰성 문제를 만들어낼 수도 있다. 이를 영구적인 단일 모델 약정으로 취급하는 팀은 더 나은 선택지를 놓칠 수 있다.
새롭게 부상하는 이 분야는 그 양극단 사이에 있다. 제공업체를 바꿀 수 있을 만큼 추상적이면서도 작업 품질을 유지할 수 있을 만큼 구체적이고, 선택을 정당화할 수 있을 만큼 증거에 기반한다. 이것이 모델 라우팅 분야의 커리어 기회다. 한 번 API를 선택하는 것이 아니라, 계속해서 올바른 선택을 하도록 만드는 의사결정 시스템을 구축하는 것이다.
Tom Whitfield는 AI Career Brief의 책임 있는 인간 편집자로서, AI 시대에 일하기 위한 기술, 역할, 현명한 선택을 다룬다.
