2025년 6월 27일(금) 주간 트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/b28d786c-9ec3-46ec-8055-adcd53a303c5_thumbnail_2.png)


## AI — Gemini 2.5 Pro / Flash GA, Reasoning도 비용에 따라 선택하는 시대

Google이 **6월 17일 Gemini 2.5 Pro와 Gemini 2.5 Flash를 Stable/GA**로 전환했습니다.

동시에 더 낮은 비용과 높은 처리량을 목표로 한 **Gemini 2.5 Flash-Lite**도 Preview로 공개했습니다.

Gemini 2.5는 Google이 **Thinking Model Family**로 정의한 모델 계열로, 단순히 답변을 생성하는 것뿐 아니라 문제를 해결하기 전에 추가적인 Reasoning Compute를 사용할 수 있도록 설계됐습니다.

특히 개발자는 Workload에 따라 Thinking 수준을 조절할 수 있어 **성능, Latency, Cost 사이의 균형을 Application에서 직접 설계**할 수 있게 됐습니다.

[Google Developers Blog - Gemini 2.5 Thinking Model Updates](https://developers.googleblog.com/gemini-2-5-thinking-model-updates/)

---

### Reasoning Model의 초기 모습

2024년 OpenAI o1이 등장하면서 AI Model 경쟁에 새로운 축이 생겼습니다.

기존 LLM을 단순화하면 다음과 같았습니다.

```text
Prompt
  ↓
LLM
  ↓
Answer
```

Reasoning Model에서는 문제를 해결하기 위해 추가적인 Compute를 사용합니다.

```text
Problem
   ↓
Reasoning
   ↓
Inference Compute
   ↓
Answer
```

특히 다음과 같은 문제에서 효과가 컸습니다.

```text
Coding

Mathematics

Science

Complex Planning

Logical Reasoning
```

하지만 초기 Reasoning Model은 상대적으로 비싸고 느린 **고난도 작업용 모델**이라는 성격이 강했습니다.

---

### Reasoning이 기본 Model Family로 내려오기 시작했다

2025년에 들어오면서 상황이 빠르게 바뀌었습니다.

```text
OpenAI o-series

DeepSeek R1

Claude 3.7

Gemini 2.5
```

주요 AI Provider들이 Reasoning을 핵심 Model Architecture로 가져오기 시작했습니다.

Gemini 2.5에서는 더 나아가 하나의 고성능 Reasoning Model만 제공하는 것이 아니라 서로 다른 비용과 성능 특성을 가진 Model Family를 구성했습니다.

```text
Gemini 2.5

├─ Pro
├─ Flash
└─ Flash-Lite
```

Reasoning 자체가 일부 고급 사용자만 사용하는 특수 기능에서 **일반 Application에서도 선택할 수 있는 Compute 옵션**으로 내려오기 시작한 것입니다.

---

### Gemini 2.5 Pro

Gemini 2.5 Pro는 복잡한 Reasoning과 Coding, 긴 Context 처리 같은 고난도 작업을 위한 상위 Model입니다.

```text
Complex Task
     ↓
Gemini 2.5 Pro
     ↓
Deep Reasoning
     ↓
Result
```

대표적인 Workload는 다음과 같습니다.

```text
Complex Coding

Architecture Analysis

Large Document Analysis

Mathematics

Research

Multi-step Reasoning
```

Latency와 Cost보다 높은 Capability가 중요한 작업에 적합한 방향입니다.

---

### Gemini 2.5 Flash

Flash는 높은 처리 속도와 비용 효율을 고려한 Model입니다.

```text
Normal Request
      ↓
Gemini 2.5 Flash
      ↓
Reasoning
      ↓
Fast Response
```

모든 작업에 Pro 수준의 Compute가 필요하지 않기 때문에 일반적인 AI Application에서는 Flash 같은 Model의 활용도가 높을 수 있습니다.

예를 들어 다음과 같은 작업입니다.

```text
Chat

Summarization

Classification

Data Extraction

Simple Coding

Content Processing
```

Reasoning Capability를 제공하면서도 **Production Traffic을 처리하기 위한 속도와 비용을 함께 고려한 Model**입니다.

---

### Flash-Lite

Google은 동시에 **Gemini 2.5 Flash-Lite Preview**도 공개했습니다.

Flash보다 더 높은 처리량과 낮은 비용을 목표로 하는 Model입니다.

```text
Large Volume
     ↓
Flash-Lite
     ↓
Low Cost
     ↓
High Throughput
```

대표적으로 다음과 같은 작업에서 의미가 있습니다.

```text
Classification

Tagging

Simple Extraction

Content Filtering

High-volume Processing

Batch Processing
```

AI Service에서는 Request 하나의 가격 차이는 작아 보여도 Traffic이 커지면 전체 비용에 큰 영향을 줍니다.

---

### Reasoning도 하나의 Resource가 된다

이전에는 Model을 선택하면 Reasoning 수준 역시 거의 Model에 의해 결정됐습니다.

```text
Model 선택
   ↓
Capability 결정
```

Gemini 2.5의 Thinking Model 구조에서는 개발자가 **Thinking Budget을 조절하는 방식**을 사용할 수 있습니다.

개념적으로 보면 다음과 같습니다.

```text
Low Thinking

빠른 응답
낮은 Cost


Medium Thinking

속도와 성능의 균형


High Thinking

더 많은 Reasoning
높은 Capability
```

즉 Model뿐 아니라 **Inference 과정에서 Reasoning에 얼마나 많은 Compute를 사용할 것인지**도 Application 설정으로 들어오기 시작했습니다.

---

### Thinking Budget

Thinking Budget은 Model이 문제를 해결하기 위해 Reasoning에 사용할 수 있는 Compute를 조절하기 위한 개념입니다.

```text
Request
   ↓
Thinking Budget
   ↓
Reasoning
   ↓
Response
```

단순한 요청에는 많은 Reasoning이 필요하지 않습니다.

```text
"이 문장을 영어로 번역해줘"

→ 낮은 Reasoning
```

반면 복잡한 Architecture 문제라면 더 많은 Reasoning이 유용할 수 있습니다.

```text
"이 Distributed System의
동시성 문제를 분석해줘"

→ 높은 Reasoning
```

모든 Request에서 동일한 Compute를 사용할 필요가 없는 것입니다.

---

### 기존 Model Routing

Model Routing은 이미 2024년부터 중요해지고 있었습니다.

```text
Simple Task
     ↓
Small Model


Complex Task
     ↓
Large Model
```

저렴한 Model의 성능이 높아지면서 모든 Request를 가장 큰 Model에 보내는 Architecture가 비효율적으로 보이기 시작했습니다.

Gemini 2.5 Model Family는 이 구조를 더 세분화합니다.

```text
Simple Task
     ↓
Flash-Lite


General Task
     ↓
Flash


Complex Task
     ↓
Pro
```

---

### Model Routing + Reasoning Routing

이제 Model뿐 아니라 Reasoning 수준도 선택할 수 있습니다.

```text
Request
   ↓
Task Analyzer
   ↓
Model 선택
   ↓
Thinking Budget 선택
   ↓
Inference
```

예를 들어 다음과 같은 구조를 만들 수 있습니다.

```text
Simple Extraction
      ↓
Flash-Lite
      ↓
Low Thinking


Normal Chat
      ↓
Flash
      ↓
Medium Thinking


Complex Coding
      ↓
Pro
      ↓
High Thinking
```

AI Backend에서 **Model Routing과 Compute Routing이 결합**되기 시작한 것입니다.

---

### 왜 중요한가

초기의 AI Application은 하나의 Model만 연결해도 충분했습니다.

```text
Application
     ↓
LLM
```

하지만 Model Family가 다양해지면서 Architecture가 달라집니다.

```text
Application
     ↓
AI Router
     │
     ├─ Flash-Lite
     ├─ Flash
     └─ Pro
```

Backend가 단순히 LLM API를 호출하는 Layer에서 **요청의 특성에 따라 적절한 Model과 Compute를 선택하는 Layer**로 발전합니다.

---

### AI Backend Architecture

Model Routing이 들어가면 Backend 구조는 다음과 같이 확장될 수 있습니다.

```text
Client
  ↓
Backend
  ↓
AI Gateway
  ↓
Task Classifier
  ↓
Model Router
  │
  ├─ Gemini 2.5 Flash-Lite
  ├─ Gemini 2.5 Flash
  └─ Gemini 2.5 Pro
```

Router에서는 다음 요소를 판단할 수 있습니다.

```text
Task Complexity

Latency Requirement

Expected Context Size

Reasoning 필요성

Cost Budget

User Tier
```

AI Model 자체보다 **어떤 요청을 어디로 보내는가**가 서비스 품질과 비용에 직접적인 영향을 주게 됩니다.

---

### Cost Optimization

예를 들어 하루에 100만 개의 요청을 처리한다고 가정할 수 있습니다.

모든 요청에 가장 높은 성능의 Model을 사용하면 다음 구조가 됩니다.

```text
1,000,000 Requests
        ↓
Gemini 2.5 Pro
```

하지만 실제 요청 대부분이 단순한 작업일 수 있습니다.

```text
전체 요청

├─ 60% Simple
├─ 30% Normal
└─ 10% Complex
```

Routing을 사용하면 다음과 같이 구성할 수 있습니다.

```text
60%

Flash-Lite


30%

Flash


10%

Pro
```

Model Capability를 필요한 작업에만 사용하는 것입니다.

---

### AI의 Unit Economics

AI Service에서는 Model Cost가 서비스의 Unit Economics와 직접 연결됩니다.

```text
User 증가
   ↓
Request 증가
   ↓
Token 증가
   ↓
Inference Cost 증가
```

전통적인 Backend에서는 CPU와 Database 비용을 최적화했다면 AI Application에서는 **Model Inference 자체가 주요 Infrastructure Cost**가 될 수 있습니다.

따라서 다음과 같은 계산이 중요해집니다.

```text
Request당 Cost
      ×
Request 수
      =
Total AI Cost
```

Model Routing은 단순한 Architecture Pattern이 아니라 비용 관리 전략입니다.

---

### Latency도 함께 고려해야 한다

높은 Reasoning에는 더 많은 Compute가 필요할 수 있습니다.

```text
Reasoning 증가
     ↓
Capability 증가 가능
     ↓
Latency 증가 가능
```

따라서 모든 Request에서 최대 Reasoning을 사용하면 사용자 경험이 오히려 나빠질 수도 있습니다.

```text
Simple Question
      ↓
Deep Reasoning
      ↓
불필요한 대기
```

Workload에 맞는 Reasoning 수준이 필요합니다.

---

### Quality, Cost, Latency

AI Backend에서는 세 가지 요소를 동시에 고려해야 합니다.

```text
Quality
  △
 / \
Cost ─ Latency
```

높은 Quality가 필요하면 더 강한 Model이나 많은 Reasoning을 사용할 수 있습니다.

반대로 실시간 서비스에서는 Latency가 더 중요할 수 있습니다.

```text
Realtime Chat

Latency 중요
      ↓
Flash
```

복잡한 분석에서는 Quality가 중요합니다.

```text
Architecture Analysis

Reasoning Quality 중요
        ↓
Pro
```

대량 처리에서는 Cost가 중요합니다.

```text
Batch Processing

Cost 중요
     ↓
Flash-Lite
```

하나의 Model로 모든 Workload를 처리하기 어려워지는 이유입니다.

---

### Coding에서도 Model Routing이 중요하다

Coding Request 역시 복잡도가 매우 다릅니다.

```text
변수 이름 변경

→ Flash


DTO 생성

→ Flash


복잡한 Bug 분석

→ Pro


Architecture 설계

→ Pro
```

모든 Coding Request에 가장 강한 Model을 사용할 필요가 없습니다.

Coding Agent에서는 작업 단계에 따라 Model을 바꿀 수도 있습니다.

```text
Repository Search
      ↓
Flash


Complex Reasoning
      ↓
Pro


결과 요약
      ↓
Flash
```

하나의 Agent Workflow 안에서도 여러 Model을 사용할 수 있는 것입니다.

---

### Agent에서도 비용 문제가 커진다

Agent는 한 번의 Request에서 Model을 여러 번 호출할 수 있습니다.

```text
User Goal
    ↓
Model
    ↓
Tool
    ↓
Model
    ↓
Tool
    ↓
Model
```

따라서 Agent 한 번의 실행 비용은 일반 Chat보다 훨씬 커질 수 있습니다.

```text
Agent Cost

Model Call
+
Model Call
+
Model Call
+
Tool Cost
```

모든 Step에서 Pro를 사용하면 비용이 빠르게 증가할 수 있습니다.

---

### Agent 내부 Model Routing

Agent Workflow에서도 Step별로 다른 Model을 사용할 수 있습니다.

```text
Agent

Planning
   ↓
Pro


Simple Tool Result Processing
   ↓
Flash


Classification
   ↓
Flash-Lite


Complex Error Analysis
   ↓
Pro
```

Model Routing이 단순 Request Routing을 넘어 **Agent Execution Strategy**가 됩니다.

---

### Routing 기준

실제 Application에서는 다양한 기준을 사용할 수 있습니다.

```text
Routing Criteria

├─ Task Type
├─ Complexity
├─ Input Length
├─ User Plan
├─ Latency SLA
├─ Cost Budget
└─ Accuracy Requirement
```

예를 들어 유료 사용자는 더 높은 Reasoning Model을 사용할 수도 있습니다.

```text
Free User
   ↓
Flash


Premium User
   ↓
Pro
```

Product Pricing과 Model Architecture가 연결될 수도 있습니다.

---

### Fallback Strategy

여러 Model을 사용하면 Fallback Architecture도 만들 수 있습니다.

```text
Flash
  ↓
Result 부족
  ↓
Pro
```

처음부터 가장 비싼 Model을 사용하는 대신 작은 Model을 먼저 시도하고 필요한 경우 상위 Model로 Escalation할 수 있습니다.

```text
Request
   ↓
Flash
   ↓
Confidence 충분?
 ├─ Yes → Response
 └─ No
      ↓
     Pro
      ↓
   Response
```

AI Cost를 줄이기 위한 방법 중 하나입니다.

---

### Model Routing이 쉬운 문제는 아니다

다만 Task Complexity를 정확하게 판단하는 것 자체도 하나의 문제입니다.

```text
Request
   ↓
Simple?
Complex?
```

Routing Model이 잘못 판단하면,

```text
Complex Task
    ↓
Cheap Model
    ↓
Quality 감소
```

하거나,

```text
Simple Task
    ↓
Expensive Model
    ↓
Cost 증가
```

할 수 있습니다.

따라서 Routing Logic 역시 지속적으로 측정하고 개선해야 합니다.

---

### Evaluation이 중요해진다

Model이 많아질수록 Benchmark만으로 선택하기 어려워집니다.

실제 서비스의 Workload를 기준으로 평가해야 합니다.

```text
Production Tasks
       ↓
Model A
Model B
Model C
       ↓
Evaluation
```

다음과 같은 Metric을 사용할 수 있습니다.

```text
Accuracy

Task Success Rate

Latency

Token Usage

Cost

User Satisfaction
```

AI Backend에서도 **Application-specific Benchmark**가 중요해집니다.

---

### Observability도 필요하다

어떤 Request가 어떤 Model로 Routing됐는지 확인할 수 있어야 합니다.

```text
Request

Task Type: Coding

Model: Gemini 2.5 Pro

Thinking: High

Latency: 8s

Cost: X
```

이런 데이터를 수집해야 Routing Strategy가 실제로 효율적인지 판단할 수 있습니다.

```text
AI Observability

├─ Model
├─ Token
├─ Latency
├─ Reasoning
├─ Cost
└─ Result Quality
```

AI Infrastructure에서도 Monitoring과 Optimization이 중요해집니다.

---

### Reasoning Model이 Commodity가 되기 시작한다

2024년에는 Reasoning Model 자체가 매우 특별한 기능처럼 보였습니다.

```text
Reasoning
   ↓
Special Model
```

하지만 2025년 중반에는 상황이 바뀝니다.

```text
Reasoning

Pro

Flash

Lite
```

Reasoning Capability 자체가 다양한 가격대와 Performance Tier로 제공되기 시작한 것입니다.

AI 경쟁이

```text
Reasoning이 가능한가?
```

에서

```text
얼마나 빠르고
얼마나 저렴하게
Reasoning을 제공하는가?
```

로 이동합니다.

---

### Model Family 전략

Google의 Gemini 2.5 Family를 보면 이런 방향이 명확합니다.

```text
High Capability
      ↓
Pro


Balanced
      ↓
Flash


High Volume / Low Cost
      ↓
Flash-Lite
```

하나의 Model로 전체 시장을 처리하기보다 Workload별로 서로 다른 Model Tier를 제공하는 방식입니다.

---

### Cloud Compute와 비슷해진다

이 구조는 Cloud Instance를 선택하는 것과도 비슷합니다.

```text
Cloud

Small Instance
Medium Instance
Large Instance
```

Application 요구사항에 맞게 Resource를 선택합니다.

AI에서도 비슷해집니다.

```text
AI Compute

Flash-Lite
Flash
Pro
```

그리고 Thinking Budget까지 추가되면 더 세밀한 Resource Allocation이 가능합니다.

```text
Model
+
Reasoning Compute
```

Inference Compute 자체가 하나의 Cloud Resource처럼 관리되는 방향입니다.

---

### AI Backend의 역할 변화

초기 AI Backend는 단순했습니다.

```text
Prompt
 ↓
Model
 ↓
Response
```

이제는 다음과 같은 요소가 추가됩니다.

```text
AI Backend

├─ Model Routing
├─ Thinking Budget
├─ Context Management
├─ Tool Calling
├─ Cost Control
├─ Fallback
└─ Observability
```

Backend가 단순 LLM Wrapper가 아니라 **AI Compute를 관리하는 Orchestration Layer**로 발전하고 있습니다.

---

### 왜 중요한가

Gemini 2.5 Pro와 Flash의 GA는 Reasoning Model 자체가 Production Application에서 사용할 수 있는 일반적인 선택지가 됐다는 것을 보여줬습니다.

2025년 초까지만 해도

```text
Reasoning
→ High-end Model
```

이라는 이미지가 강했다면,

이제는

```text
Reasoning

High
Medium
Cheap
```

형태로 세분화되고 있습니다.

개발자는 단순히

```text
Gemini를 사용할까?
GPT를 사용할까?
```

를 선택하는 것이 아니라,

```text
이 Request에는
어떤 수준의 Model과
얼마나 많은 Reasoning이 필요한가?
```

를 판단해야 합니다.

---

### 실무 영향

현실적인 AI Backend는 다음과 같은 구조로 발전할 수 있습니다.

```text
Client
  ↓
AI Backend
  ↓
Task Analyzer
  ↓
Model Router
  │
  ├─ Simple / High Volume
  │        ↓
  │    Flash-Lite
  │
  ├─ General
  │        ↓
  │      Flash
  │
  └─ Complex Reasoning
           ↓
          Pro
```

그리고 각 Model에서도 Reasoning 수준을 조절할 수 있습니다.

```text
Model Routing
      +
Thinking Budget
      ↓
Cost / Latency / Quality 최적화
```

결국 Gemini 2.5 Pro와 Flash의 GA는,

> **Reasoning Model이 고난도 작업을 위한 특수 Model에서 벗어나 성능과 비용에 따라 선택할 수 있는 일반적인 AI Compute Resource로 이동했음을 보여주는 변화**

라고 볼 수 있습니다.

AI Backend에서도 하나의 Model을 고정해서 사용하는 구조보다 **Task에 따라 Pro, Flash, Flash-Lite를 선택하고 Reasoning Compute까지 조절하는 Model Routing Architecture**가 비용과 Latency, 서비스 품질을 결정하는 핵심 요소로 자리 잡을 것으로 보여집니다.

2025년 6월 20일(금) 주간 트렌드

독자의 메모