AI 에이전트 라우팅 최적화: 비용 90% 절감하는 실전 가이드

핵심 요약

• 모델 선택은 마지막 결정: 대부분의 팀이 역순으로 접근하고 있습니다. 먼저 라우팅 아키텍처를 설계해야 합니다
• 라우팅으로 비용 90% 이상 절감: 로컬 모델(70-80%)과 비동기 배치 추론으로 AI 지출을 획기적으로 줄일 수 있습니다
• 세 가지 라우팅 계층 필수: 스킬 분류기, 라우터, 모델 선택기가 각각 다른 역할을 담당합니다
• 대기열 처리가 핵심: 실시간 응답이 필요한 작업은 생각보다 훨씬 적습니다
• 피드백 루프로 지속적 최적화: 동기식 신호와 야간 평가로 라우팅 성능을 계속 개선합니다

에이전트 구축의 가장 큰 실수: 순서를 잘못 이해하기

대부분의 에이전트 구축 팀이 범하는 가장 흔한 실수는 무엇일까요? 바로 모델을 먼저 선택하고 아키텍처는 나중에 고르는 것 입니다.

이것이 정확히 역순입니다.

정말 중요한 것은 라우터입니다. 라우터는 간단한 코드 조각처럼 보이지만, 실제로는 각 사용자 요청을 어떤 계층의 모델이 처리할지 결정하는 지능형 트래픽 관리 시스템 입니다. 라우터를 제대로 설정하면, 다음과 같은 놀라운 결과를 얻을 수 있습니다:

• 트래픽의 70-80%가 로컬 모델에서 실행 (호출당 비용 0에 가까움)
• 비동기 모델로 AI 지출을 90% 이상 절감
• 동일한 결과 품질 유지 (올바른 라우팅이라면 가능합니다)

이를 증명하는 사례가 있습니다. 브라이언 암스트롱(Coinbase CEO) 은 지난주 흥미로운 통계를 공개했습니다. Coinbase는 토큰 사용량이 기하급수적으로 증가했음에도 불구하고, AI 지출을 절반으로 줄이는 데 성공했습니다.

그 비결이 무엇일까요? 그의 말을 직접 들어봅시다:

"토큰 사용량이 기하급수적으로 증가하는 동안 AI 지출을 일정하게 유지하는 방법: 마찰과 지출 알림을 통해서가 아닙니다. 더 나은 기본 설정, 라우팅 및 캐싱을 통해서입니다. 엔지니어는 원하는 모델을 선택할 수 있지만, 기본 설정이 중요합니다."

이 메시지는 명확합니다. 아키텍처가 모델 선택보다 우선입니다.

라우팅 아키텍처의 세 가지 핵심 계층 이해하기

에이전트 라우팅을 제대로 이해하려면, 세 가지 서로 다른 계층이 각각 어떤 역할을 하는지 알아야 합니다. 이들은 연쇄적으로 작동하며, 각 계층은 고유한 책임을 가집니다.

1단계: 스킬 분류기(Skill Classifier) - 작업 정의하기

역할: 사용자의 원시 요청을 구체적인 작업으로 변환합니다.

분류기는 다음과 같은 질문에 답합니다:

• 사용자가 실제로 무엇을 요청했는가?
• 이 요청은 어떤 작업에 해당하는가?

예를 들어:

• "메일 답장을 도와줘" → 답장 초안 작성 작업
• "이 저장소 정리해줘" → 저장소 요약 작업
• "마이그레이션을 실행해야 하는데..." → 마이그레이션 실행 작업

중요한 점: 분류기는 의도 인식(intent recognition) 문제입니다. 프롬프트의 세부 내용을 완전히 이해할 필요는 없지만, 사용자가 무엇을 하고자 하는지는 명확히 파악해야 합니다.

2단계: 라우터(Router) - 어떤 모델 계층을 사용할지 결정하기

역할: 분류된 작업을 가장 적절한 모델 계층에 배정합니다.

라우터는 다음과 같은 질문에 답합니다:

• 어떤 모델이 이 작업을 처리해야 하는가?
• 로컬 모델로 충분한가? 아니면 클라우드 모델이 필요한가?
• 실시간 응답이 필요한가? 아니면 비동기 처리가 가능한가?

핵심 차이점: 라우터는 프롬프트 자체를 읽지 않습니다. 대신 다음 정보를 활용합니다:

• 분류기로부터의 작업 레이블
• 복잡도(Complexity)
• 컨텍스트 크기(Context Size)
• 과거 성공률(Historical Success Rate)

이런 메타데이터를 통해 라우터는 빠르게 의사결정을 내립니다.

3단계: 모델 선택기(Model Selector) - 가장 저렴한 모델 선택하기

역할: 신뢰도 임계값을 충족하는 계층 내에서 가장 저렴한 모델 을 선택합니다.

모델 선택기는 이렇게 작동합니다:

1. 라우터가 "이 작업은 중급 모델이 필요하다"고 결정
2. 중급 계층의 모든 모델 중에서 신뢰도 요구사항을 만족하는 가장 싼 모델 선택
3. 필요하면 A/B 테스트를 통해 더 저렴한 모델도 시험

중요: 분류기와 라우터를 혼동하면 안 됩니다. 분류기는 언어 문제 이고, 라우터는 스케줄링 문제 입니다. 이 둘을 혼동하면 모델 선택 로직이 프롬프트 깊숙이 묻히게 되고, 동일한 작업에 대해 여러 모델을 A/B 테스트할 수 있는 능력이 사라집니다.

로컬 모델과 비동기 배치가 비용 절감의 핵심

라우팅의 진정한 강력함은 비용 구조의 차이 를 활용하는 데 있습니다.

로컬 모델: 거의 무료에 가까운 가격

로컬 컴퓨팅은 거의 무료입니다. API 호출 비용이 없고, 네트워크 지연도 없으며, 데이터 프라이버시 문제도 없습니다. 문제는 단 하나: 로컬 모델의 능력이 대규모 클라우드 모델보다 제한적이라는 것입니다.

그러면 어떻게 해야 할까요? 기술 증류(Skill Distillation) 를 사용합니다.

기술 증류란 대규모 모델(예: Claude)이 수행하는 작업을 분석하고, 그 작업을 로컬 모델도 수행할 수 있도록 학습시키는 과정입니다. 결과적으로 특정 작업에 한해서는 로컬 모델이 거의 같은 수준의 성능을 발휘합니다.

이것이 가능한 이유는 대부분의 에이전트 작업이 특정 도메인에 특화되어 있기 때문 입니다. 범용 AI 능력은 필요 없고, 그 업무만 잘하면 됩니다.

비동기 배치 추론: 수십 배 저렴한 가격

비동기 배치 추론은 실시간 추론보다 두 자릿수 이상 저렴합니다. (일부 경우 수십 배 저렴)

실시간 API와 배치 API의 가격 차이는 매우 큽니다. 왜일까요?

배치 처리는 대기 시간이 없기 때문 입니다. 즉시 응답이 필요하지 않으므로, 클라우드 제공자는 요청들을 묶어서 처리하고, 컴퓨팅 자원을 훨씬 효율적으로 사용할 수 있습니다.

그렇다면 진짜 질문은 이것입니다:

"작업 중 몇 퍼센트가 실시간 응답을 정말로 필요로 하는가?"

답은 놀랍습니다: 생각보다 훨씬 적습니다.

대기열 처리: 왜 비동기 라우팅이 작동하는가

시스템이 작업을 대기열에 넣을 수 있게 되면, 실시간 응답의 필요성은 극적으로 줄어듭니다.

다음을 생각해보세요:

• 답장 초안 작성: 1초 안에 받아야 하나요? 아니오. 사용자는 답장을 읽고 수정할 시간이 필요합니다. 1-2시간 정도면 괜찮습니다.
• 저장소 요약: 즉시 필요한가요? 아니오. 다음날 아침에 봐도 충분합니다.
• 실사 메모 작성: 실시간이 아니어야 합니다. 신중하게 작성되어야 합니다.
• 야간 평가기 실행: 이름부터 "야간(overnight)"입니다.

대부분의 에이전트 작업은 사용자가 즉시 결과를 기다리지 않습니다. 사용자는 결과를 받기를 원하지만, 즉시일 필요는 없습니다.

이 차이가 비용을 90% 절감하는 열쇠입니다.

실전 구현: 피드백 루프로 라우터 최적화하기

최적의 라우팅 시스템은 정적이지 않습니다. 지속적으로 학습하고 개선됩니다. 이를 위해 두 가지 피드백 메커니즘 이 필요합니다:

동기식 실패 모드 신호(Synchronous Failure Mode Signals)

목적: 알려진 어려운 작업을 실패하기 전에 감지합니다.

라우터는 각 수신 요청에 5가지 특징을 자동으로 주석 으로 달아줍니다:

1. 누락된 리포지토리 컨텍스트: 작업 수행에 필요한 정보가 부족한가?
2. 긴 종속성 체인: 이 작업이 다른 많은 작업에 의존하는가?
3. 위험한 마이그레이션: 이 작업이 시스템을 손상시킬 수 있는가?
4. 보안에 민감한 프롬프트: 이 요청이 민감한 정보를 다루는가?
5. 중대한 쓰기 작업: 이 작업이 중요한 데이터 변경을 포함하는가?

이런 신호 중 하나라도 감지되면, 라우터는 더 강력한 모델로 요청을 업그레이드합니다. 실패를 예방하는 것입니다.

야간 폐쇄 루프 피드백(Overnight Closed-Loop Feedback)

목적: 새로운 실패 모드를 발견하고 라우터의 가중치를 업데이트합니다.

밤새 다음과 같은 작업이 실행됩니다:

1. 배치 평가기 가 어제의 모든 추적 기록을 검토
2. 어떤 요청이 실패했는지, 왜 실패했는지 분석
3. 실패 패턴을 찾아 라우터의 가중치 조정
4. 평가 자체는 비동기 추론 을 통해 실행 (거의 무료)

동기식 신호는 알려진 위험 을 감지하고, 야간 피드백은 새로운 위험 패턴 을 발견합니다. 이 두 가지가 함께 작동하면, 시스템은 지속적으로 더 똑똑해집니다.

실제 성과: 70-80%의 트래픽을 로컬 모델로 처리

기술 증류로 작업 세트를 평탄화하면, 다음과 같은 결과를 기대할 수 있습니다:

비코딩 작업 기준:

• 70-80%의 에이전트 트래픽이 로컬 모델에서 실행
• 대부분의 나머지는 비동기 배치로 처리
• 실시간 고급 모델이 필요한 경우는 5% 미만

이것이 의미하는 바는:

• 토큰당 비용이 1/100 이하로 감소
• 스케일링해도 비용이 거의 증가하지 않음
• 응답 시간은 약간 길어지지만 (몇 초~수시간), 대부분의 사용 사례에서 받아들여질 수 있음

결론: 모델 중심에서 라우팅 중심으로의 전환

AI 에이전트를 구축할 때 가장 중요한 깨달음은 다음과 같습니다:

시스템을 모델 중심으로 설계하지 마세요. 라우팅 중심으로 설계하세요. 모델은 가장 나중에 선택하세요.

구체적으로:

1. 먼저 작업을 분류하는 방법 을 설계합니다 (스킬 분류기)
2. 그 다음 작업을 배정하는 방법 을 설계합니다 (라우터)
3. 마지막으로 어떤 모델을 사용할지 결정합니다 (모델 선택기)

이 순서를 따르면:

• ✅ AI 비용을 90% 이상 절감할 수 있습니다
• ✅ 스케일링할 때도 비용을 통제할 수 있습니다
• ✅ A/B 테스트를 통해 더 저렴한 모델을 찾을 수 있습니다
• ✅ 피드백 루프로 지속적으로 성능을 개선할 수 있습니다

Coinbase가 토큰 사용량을 늘리면서도 비용을 줄인 비결은 더 비싼 모델을 버린 것이 아니라, 더 똑똑한 라우팅을 만든 것 입니다.

당신의 에이전트도 같은 방식으로 설계하세요. 라우팅이 바뀌면 전체가 바뀝니다.

---

Original source: Most AI Work Can Wait

powered by osmu.app