# AI 에이전트 라우팅 최적화: 비용 90% 절감하는 방법

> 2026-07-01 · Tom Tunguz · 큐레이션 김태우
> https://challengekim.com/insights/ai-agent-routing-optimization-reduce-costs-90-percent-ko
> 원문: https://www.tomtunguz.com/ai-execution-routing/

## 핵심 요약

- **모델 선택은 마지막 결정**: 대부분의 팀이 역순으로 접근하고 있습니다. 먼저 라우팅 아키텍처를 설계해야 합니다
- **라우팅으로 비용 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가 토큰 사용량을 늘리면서도 비용을 줄인 비결은 더 비싼 모델을 버린 것이 아니라, **더 똑똑한 라우팅을 만든 것** 입니다.

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

---

원문을 바탕으로 AI 가 한국어로 요약·재구성한 글입니다. 인용·수치는 원문 링크에서 확인해 주세요. [원문 링크](https://www.tomtunguz.com/ai-execution-routing/)