2025년 4월 4일(금) 주간 개발트렌드

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

## AI — Gemini 2.5 Pro, 'Thinking Model' 경쟁 본격화

Google이 **25년 3월 25일 Gemini 2.5 Pro Experimental**을 공개했습니다.

Gemini 2.5 Pro는 Google이 **Thinking Model**이라고 부른 새로운 세대의 모델로, 답변을 바로 생성하는 것보다 복잡한 문제를 해결하기 위해 내부적으로 더 많은 추론 과정을 사용하는 방향을 강조했습니다.

특히 **Coding, Mathematics, Science, Long Context Processing** 같은 복잡한 작업에서 높은 성능을 목표로 설계됐습니다.

OpenAI의 o-series, DeepSeek R1, Claude 3.7 Sonnet에 이어 Google까지 Reasoning을 핵심 Model Architecture로 가져오면서 **추론 모델이 일부 특수 작업용 모델이 아니라 차세대 Foundation Model의 기본 방향으로 자리 잡기 시작했습니다.**

[Google - Gemini 2.5](https://blog.google/innovation-and-ai/models-and-research/google-deepmind/gemini-model-thinking-updates-march-2025/)

---

### 기존 LLM의 구조

기존 LLM을 단순화하면 다음과 같은 구조였습니다.

```text
Prompt
  ↓
Model
  ↓
Answer
```

사용자의 요청을 받고 바로 Token을 생성하면서 답변을 만들어가는 방식입니다.

모델의 성능을 높이는 방법 역시 주로 Training 단계의 Scaling에 집중돼 있었습니다.

```text
더 많은 Data
      +
더 큰 Model
      +
더 많은 Training Compute
      ↓
더 높은 Model Capability
```

GPT-3에서 GPT-4로 이어진 초기 LLM 경쟁도 이런 흐름을 중심으로 발전했습니다.

---

### Thinking Model

Reasoning Model에서는 새로운 성능 향상 축이 추가됩니다.

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

모델을 얼마나 크게 학습했는가뿐 아니라 **실제 문제를 해결할 때 얼마나 효과적으로 Compute를 사용하는가**도 중요해진 것입니다.

```text
AI Performance

Training
   +
Model Capability
   +
Inference-time Reasoning
```

Gemini 2.5는 Google이 이러한 Thinking Capability를 모델 설계의 핵심으로 가져왔다는 점에서 의미가 있었습니다.

---

### Reasoning Model 경쟁

2024년부터 Reasoning Model 경쟁은 빠르게 확대됐습니다.

```text
2024.09

OpenAI o1
    ↓

2024.12

OpenAI o3 공개
    ↓

2025.01

DeepSeek R1
    ↓

2025.02

Claude 3.7 Sonnet
    ↓

2025.03

Gemini 2.5 Pro
```

처음에는 OpenAI의 독특한 Model Family처럼 보였던 Reasoning 방식이 몇 달 만에 주요 AI 기업들의 공통적인 개발 방향으로 확산됐습니다.

---

### 특수 모델에서 기본 모델 구조로

초기의 Reasoning Model은 일반적인 Chat Model과 별도의 Model Family처럼 보였습니다.

```text
General Model

GPT
Claude
Gemini


Reasoning Model

o1
o3
R1
```

하지만 Gemini 2.5 시점부터 흐름이 달라지기 시작했습니다.

```text
Foundation Model

        +
Built-in Reasoning

        ↓

General Purpose
Thinking Model
```

Google은 Thinking Capability를 Gemini 2.5 Model Family의 중요한 설계 방향으로 가져갔습니다.

Reasoning이 특정 문제를 위한 별도의 기능이 아니라 **기본적인 Model Intelligence를 구성하는 요소**로 이동하기 시작한 것입니다.

---

### Coding에서 Reasoning이 중요한 이유

Coding은 단순히 Source Code를 생성하는 작업만 있는 것이 아닙니다.

다음 요청은 비교적 단순합니다.

```text
DTO 하나 만들어줘

Button Component 만들어줘

SQL INSERT 작성해줘
```

하지만 실제 개발에서 어려운 문제는 다음과 같습니다.

```text
Race Condition 원인 분석

복잡한 Bug Debugging

Architecture 변경

Repository 전체 Refactoring

성능 Bottleneck 분석
```

이런 문제는 단순 Code Generation보다 여러 단계의 판단이 필요합니다.

```text
Problem
 ↓
Repository 이해
 ↓
Dependency 확인
 ↓
원인 추론
 ↓
해결 방법 비교
 ↓
Code 변경
```

Reasoning Model의 발전이 Coding AI와 특히 밀접하게 연결되는 이유입니다.

---

### Coding Agent와의 연결

2025년에는 Copilot Agent Mode와 Claude Code 같은 **Coding Agent**도 등장하기 시작했습니다.

Coding Agent는 다음과 같은 Workflow를 수행합니다.

```text
Task
 ↓
Repository 탐색
 ↓
관련 File 확인
 ↓
Reasoning
 ↓
Code 수정
 ↓
Test
 ↓
Error 확인
 ↓
다시 수정
```

이 과정에서는 계속해서 판단이 필요합니다.

```text
어떤 File을 볼까?

무엇이 원인인가?

어디를 수정할까?

Test 실패 원인은 무엇인가?

다음에는 무엇을 해야 하는가?
```

따라서 Agent가 강력해질수록 기반 Model의 Reasoning Capability도 중요해집니다.

```text
Reasoning Model
       +
Tool Use
       +
Repository Context
       ↓
Coding Agent
```

Gemini 2.5가 Coding Performance를 강조한 것도 이런 AI Developer Tool의 변화와 연결됩니다.

---

### Long Context

Gemini Model의 중요한 특징 중 하나는 **긴 Context를 처리하는 능력**입니다.

Context Window가 커지면 Model이 한 번에 더 많은 정보를 입력으로 받을 수 있습니다.

```text
Small Context

Current File
     ↓
Model


Long Context

Repository
+
Document
+
History
+
Large Dataset
     ↓
Model
```

Coding에서는 특히 큰 장점이 있습니다.

실제 Software는 하나의 File로 구성되지 않기 때문입니다.

```text
Repository

├─ Controller
├─ Service
├─ Repository
├─ Domain
├─ Configuration
├─ Tests
└─ Documentation
```

복잡한 문제를 해결하려면 여러 File 사이의 관계를 이해해야 합니다.

---

### Long Context + Reasoning

긴 Context만 있다고 복잡한 문제를 잘 해결하는 것은 아닙니다.

```text
Large Context
     ↓
많은 정보
```

하지만 그 정보에서 필요한 부분을 찾아 관계를 분석하고 결론을 내리려면 Reasoning이 필요합니다.

```text
Long Context
      +
Reasoning
      ↓
Large-scale Problem Solving
```

따라서 AI Coding Agent에서는 다음 두 능력이 함께 중요합니다.

```text
Context

얼마나 많은 Code를 볼 수 있는가?


Reasoning

그 Code를 얼마나 잘 이해하고
문제를 해결할 수 있는가?
```

Gemini 2.5 Pro는 이 두 영역을 동시에 강조한 모델이었습니다.

---

### Model 선택 기준이 복잡해진다

초기 AI Application에서는 Model을 선택하는 기준이 비교적 단순했습니다.

```text
GPT-4가 좋은가?

Claude가 좋은가?

Gemini가 좋은가?
```

하지만 Model 종류와 특성이 다양해지면서 단순한 Provider 비교만으로는 부족해졌습니다.

```text
Model Selection

├─ Coding
├─ Reasoning
├─ Long Context
├─ Latency
├─ Cost
├─ Tool Calling
├─ Multimodal
└─ Agent Performance
```

같은 Model Provider 안에서도 Workload에 따라 적합한 Model이 달라질 수 있습니다.

---

### Coding Workload

Coding Agent에서는 다음 요소가 중요할 수 있습니다.

```text
Coding Performance

Repository Context

Reasoning

Tool Calling

Latency
```

예를 들어 대규모 Repository를 분석해야 한다면 Long Context가 중요할 수 있습니다.

```text
Large Repository
      ↓
Long Context Model
```

복잡한 Bug를 해결해야 한다면 Reasoning이 더 중요할 수 있습니다.

```text
Complex Bug
    ↓
Reasoning Model
```

반대로 간단한 자동완성에서는 Latency가 가장 중요할 수 있습니다.

```text
Autocomplete
    ↓
Fast Model
```

---

### Latency와 Reasoning의 Trade-off

Reasoning에는 일반적으로 추가적인 Compute가 필요합니다.

```text
Reasoning Compute 증가
        ↓
복잡한 문제 해결 능력 증가 가능
        ↓
Latency 증가 가능
```

따라서 항상 가장 깊은 Reasoning을 사용하는 것이 최적은 아닙니다.

```text
Simple Task

낮은 Latency
      ↓
Fast Model


Complex Task

높은 Reasoning
      ↓
Thinking Model
```

AI Application에서는 **Quality와 Latency 사이의 Trade-off**를 고려해야 합니다.

---

### Cost도 중요한 변수

Inference Compute가 증가하면 Cost 역시 중요한 문제가 됩니다.

```text
AI Request Cost

Input
+
Output
+
Inference Compute
```

Reasoning Model에서는 단순 Token 수뿐 아니라 **문제를 해결하기 위해 사용하는 Compute 수준**까지 비용 구조에 영향을 줄 수 있습니다.

따라서 개발자는 다음을 함께 봐야 합니다.

```text
Performance

Cost

Latency
```

Benchmark에서 가장 높은 점수를 기록한 Model이 실제 서비스에서도 항상 가장 좋은 선택은 아닙니다.

---

### Model Routing

이런 환경에서 중요해지는 것이 **Model Routing**입니다.

모든 Request를 하나의 Model에 보내는 대신 Task의 특성에 따라 다른 Model을 사용할 수 있습니다.

```text
User Request
     ↓
AI Router
     │
     ├─ Simple Task
     │      ↓
     │   Fast Model
     │
     ├─ Large Context
     │      ↓
     │ Long Context Model
     │
     └─ Complex Reasoning
            ↓
       Thinking Model
```

Application이 자동으로 적절한 Model을 선택하는 구조입니다.

---

### Coding에서도 Routing이 가능하다

개발 작업도 Complexity가 모두 다릅니다.

```text
변수 이름 변경

→ Fast Model


DTO 생성

→ Small Model


Repository 분석

→ Long Context Model


Concurrency Bug

→ Reasoning Model
```

따라서 AI Coding Tool에서도 하나의 Model을 모든 작업에 사용하는 것보다 **Task별 Model Routing**이 더 효율적일 수 있습니다.

---

### AI Backend의 변화

기존 LLM Backend는 비교적 단순했습니다.

```text
Client
  ↓
Backend
  ↓
LLM
  ↓
Response
```

Model이 다양해지면서 새로운 Layer가 필요해집니다.

```text
Client
  ↓
Backend
  ↓
AI Gateway
  ↓
Model Router
  │
  ├─ Fast Model
  ├─ Long Context Model
  └─ Reasoning Model
```

Backend에서는 다음 요소까지 관리해야 합니다.

```text
Task Complexity

Model Capability

Latency

Token Usage

Cost

Fallback

Rate Limit
```

AI Model Selection 자체가 Backend Architecture 문제가 되고 있는 것입니다.

---

### AI Provider보다 Workload가 중요해진다

예전에는 Model Provider를 선택하는 질문이 중요했습니다.

```text
OpenAI?

Anthropic?

Google?
```

하지만 여러 Provider가 모두 강력한 Model을 제공하기 시작하면서 더 중요한 질문은 바뀝니다.

```text
이 Workload에는
어떤 Model 특성이 필요한가?
```

예를 들어 다음과 같습니다.

```text
Task A

Real-time Chat
→ Latency


Task B

Large Repository
→ Context


Task C

Complex Coding
→ Reasoning


Task D

Mass Processing
→ Cost
```

Provider 이름보다 **실제 Workload 특성에 맞는 Model을 선택하는 능력**이 중요해지는 것입니다.

---

### Benchmark만 보면 안 되는 이유

Model Provider는 다양한 Benchmark 결과를 제공합니다.

```text
Coding Benchmark

Math Benchmark

Science Benchmark

Reasoning Benchmark
```

하지만 Production Application에서는 Benchmark 외에도 많은 요소가 중요합니다.

```text
Production Evaluation

├─ Quality
├─ Latency
├─ Cost
├─ Context
├─ Reliability
├─ Tool Calling
└─ Rate Limit
```

특히 동일한 Task를 반복적으로 처리한다면 작은 비용 차이가 전체 비용에 큰 영향을 줄 수 있습니다.

---

### 직접 평가가 중요해진다

결국 AI Model 선택은 실제 Application Dataset으로 평가하는 것이 가장 중요합니다.

```text
Real Workload
    ↓
Model A
Model B
Model C
    ↓
Evaluation
```

예를 들어 Coding AI를 만든다면 실제 Repository의 Task를 기준으로 비교할 수 있습니다.

```text
Task Success Rate

Latency

Cost

Code Quality

Test Pass Rate
```

AI Model Benchmark에서 Product Benchmark로 평가 기준이 이동하는 것입니다.

---

### Reasoning이 기본 Capability가 된다

2024년 Reasoning Model이 처음 등장했을 때는 특별한 Model Category처럼 보였습니다.

```text
Normal Model
      vs
Reasoning Model
```

하지만 2025년 초의 흐름은 점점 다음 방향으로 바뀌고 있었습니다.

```text
Foundation Model
        ↓
Reasoning 기본 탑재
```

OpenAI, DeepSeek, Anthropic, Google이 모두 Reasoning을 중요한 Model Capability로 가져가기 시작했기 때문입니다.

---

### AI Model 경쟁의 새로운 구조

AI Model 경쟁 기준도 빠르게 확대됐습니다.

```text
초기

Model Size
+
Training Data


이후

Reasoning
+
Long Context
+
Coding
+
Multimodal
+
Tool Use


Production

Cost
+
Latency
+
Reliability
```

Model Intelligence 하나만으로 경쟁하는 시대에서 **실제 Application에 얼마나 효율적으로 사용할 수 있는가**까지 경쟁 영역이 넓어졌습니다.

---

### 실무 영향

Gemini 2.5 Pro 등장 이후 개발자가 Model을 선택하는 방식은 점점 더 Workload 중심으로 변하고 있습니다.

```text
Model Selection

Task
 ↓
Requirement 분석
 ↓
┌────────────────────────┐
│                        │
Coding                 Large Context
│                        │
↓                        ↓
Coding Model        Long Context Model


Complex Reasoning        Fast Request
│                        │
↓                        ↓
Thinking Model         Fast Model
```

그리고 각 Model은 다시 다음 기준으로 비교할 수 있습니다.

```text
Quality
+
Latency
+
Cost
+
Context
```

결국 Gemini 2.5 Pro의 등장은,

> **Reasoning이 일부 고난도 문제를 위한 특수 기능에서 차세대 Foundation Model이 기본적으로 갖춰야 할 핵심 Capability로 이동하고 있음을 보여주는 사건**

이라고 볼 수 있습니다.

OpenAI o-series, DeepSeek R1, Claude 3.7에 이어 Google까지 Thinking Model을 핵심 방향으로 가져가면서 AI 경쟁은 더 이상 단순히 **어느 회사의 Model을 사용할 것인가**의 문제가 아니게 됐습니다.

개발자는 이제 실제 Workload를 기준으로 **Coding 성능, Long Context, Reasoning Latency, Inference Cost를 함께 측정하고 적절한 Model을 선택하는 Architecture**를 고민해야 하는 단계로 들어갔습니다.

2025년 3월 28일(금) 주간 개발트렌드

독자의 메모