2024년 12월 27일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## AI — OpenAI o3 / o3-mini 사전 공개, 추론 경쟁 급가속

OpenAI가 **24년 12월 20일 o3와 o3-mini**를 처음 공개했습니다.

당시 두 모델은 바로 일반 사용자에게 제공된 것은 아니었고, 안전성 평가를 위한 **Safety Researcher 대상 Early Access 계획**과 함께 공개됐습니다.

실제 일반 공개는 2025년에 이루어졌지만, 중요한 점은 2024년 9월 `o1`을 공개한 지 불과 몇 달 만에 OpenAI가 다음 세대 Reasoning Model을 예고했다는 것입니다.

이 발표를 통해 **Reasoning Model이 일회성 실험이 아니라 OpenAI의 핵심 Model Development 방향 중 하나라는 점**이 훨씬 명확해졌습니다.

[OpenAI - 12 Days of OpenAI](https://openai.com/12-days/)

---

### GPT 계열에서 Reasoning 계열로

기존 LLM의 성능 경쟁은 주로 Model Scaling을 중심으로 발전했습니다.

```text
더 많은 Parameter
        +
더 많은 Training Data
        +
더 많은 Training Compute
        ↓
더 높은 Model Performance
```

GPT 계열 역시 이러한 Scaling 흐름을 따라 발전했습니다.

```text
GPT-3
  ↓
GPT-3.5
  ↓
GPT-4
  ↓
GPT-4 계열
```

하지만 o1부터 새로운 성능 향상 축이 본격적으로 등장했습니다.

```text
Model
  +
Inference-time Reasoning
  ↓
Complex Problem Solving
```

모델을 학습할 때뿐 아니라 **실제 문제를 해결하는 순간에도 더 많은 Compute를 사용하는 방식**입니다.

---

### o1에서 o3로

2024년 9월 OpenAI는 `o1-preview`와 `o1-mini`를 공개했습니다.

```text
Problem
   ↓
Reasoning
   ↓
Answer
```

그리고 불과 몇 달 뒤 다음 세대인 o3를 공개했습니다.

```text
GPT-4 계열
     ↓
    o1
     ↓
    o3
```

이는 Reasoning Model이 특정 Benchmark를 위한 실험적인 Model Family가 아니라 **지속적으로 Scaling할 새로운 Model Architecture 방향**이라는 것을 보여줬습니다.

---

### 새로운 Scaling 축

기존 Scaling은 주로 Training 단계에서 이루어졌습니다.

```text
Training

Data
+
Model Size
+
Compute
   ↓
Model Capability
```

Reasoning Model에서는 여기에 또 하나의 축이 추가됩니다.

```text
Inference

Problem
   ↓
Reasoning Compute
   ↓
Answer
```

따라서 AI Model 성능을 바라보는 방식도 다음과 같이 확장됩니다.

```text
AI Performance

Training Compute
       +
Model Capability
       +
Inference Compute
```

즉 학습이 끝난 Model 자체의 능력뿐 아니라 **한 문제를 해결할 때 얼마나 많은 계산을 사용할 것인지**도 성능 변수가 되는 것입니다.

---

### Inference-time Reasoning

일반적인 LLM은 Prompt를 받은 뒤 Token을 생성하며 답변을 만듭니다.

```text
Prompt
  ↓
LLM
  ↓
Token Generation
  ↓
Answer
```

Reasoning Model에서는 문제 해결을 위한 계산 과정이 더 강조됩니다.

```text
Problem
   ↓
Reasoning Compute
   ↓
Problem Solving
   ↓
Answer
```

복잡한 수학 문제나 Algorithm, Coding, Planning처럼 여러 단계의 판단이 필요한 작업에서 이런 방식이 특히 중요합니다.

---

### 같은 모델도 Compute에 따라 달라질 수 있다

Reasoning Model에서 중요한 개념 중 하나는 **Inference에 투입되는 Compute의 양**입니다.

단순화하면 다음과 같은 Trade-off를 생각할 수 있습니다.

```text
적은 Reasoning Compute

빠른 Response
낮은 Cost
        ↓
상대적으로 단순한 문제


많은 Reasoning Compute

높은 Latency
높은 Cost
        ↓
더 복잡한 문제 해결
```

즉 Model 선택만큼 **얼마나 오래 생각하게 할 것인가**도 중요한 변수로 들어오기 시작했습니다.

---

### 기존 Model 선택 방식

이전에는 AI Application에서 Model을 선택할 때 주로 Model Size나 Capability를 비교했습니다.

```text
Simple Task
    ↓
Small Model


Complex Task
    ↓
Large Model
```

하지만 Reasoning Model이 등장하면서 구조가 더 복잡해집니다.

```text
Simple Task
    ↓
Fast Model


Medium Task
    ↓
General Model


Complex Task
    ↓
Reasoning Model
    ↓
Higher Reasoning Compute
```

Model Routing뿐 아니라 **Reasoning Effort Routing**까지 고려할 수 있게 된 것입니다.

---

### 모든 요청에 Reasoning이 필요하지 않다

Reasoning Model이 강력하다고 해서 모든 Request를 Reasoning Model로 보내는 것이 항상 효율적인 것은 아닙니다.

다음 작업은 상대적으로 많은 추론이 필요하지 않을 수 있습니다.

```text
Text Classification

Simple Extraction

Translation

간단한 Summarization

Formatting
```

반면 다음과 같은 작업에서는 Reasoning이 더 중요합니다.

```text
Complex Coding

Algorithm

Mathematics

Architecture Design

Planning

Debugging
```

따라서 Application에서는 Task Complexity에 따라 Model을 분리하는 구조가 중요해집니다.

---

### Model Routing의 발전

기존 Model Routing은 주로 Model Size를 선택하는 방식이었습니다.

```text
Request
   ↓
Router
   │
   ├─ Small Model
   └─ Large Model
```

Reasoning Model이 등장하면서 다음과 같은 형태로 확장될 수 있습니다.

```text
Request
   ↓
Task Analyzer
   ↓
Model Router
   │
   ├─ Fast Model
   │
   ├─ General Model
   │
   └─ Reasoning Model
           ↓
     Reasoning Compute
```

즉 Router가 어떤 Model을 사용할지뿐 아니라 **얼마나 많은 Compute를 사용할 것인지까지 결정하는 구조**로 발전할 수 있습니다.

---

### Backend Architecture에도 영향을 준다

AI Backend에서는 이제 단순히 LLM API 하나를 호출하는 것으로 끝나지 않을 수 있습니다.

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

Model이 다양해지면 다음과 같은 Layer가 필요해집니다.

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

Backend에서는 다음 요소를 함께 고려해야 합니다.

- Task Complexity
- Model Selection
- Reasoning Level
- Latency
- Token Usage
- Inference Cost
- Timeout
- Fallback Strategy

---

### Latency가 새로운 문제로 떠오른다

Reasoning에 더 많은 Compute를 사용하면 일반적으로 응답 시간이 길어질 가능성이 있습니다.

```text
User Request
     ↓
Reasoning Model
     ↓
Longer Compute
     ↓
Response
```

따라서 Application에서는 Model Quality만 최대화하면 되는 것이 아닙니다.

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

세 가지 요소 사이의 균형이 필요합니다.

---

### 예를 들어 Coding Assistant

Coding Assistant에서 모든 요청에 깊은 Reasoning이 필요한 것은 아닙니다.

```text
변수 이름 변경

→ Fast Model
```

반면 다음과 같은 작업은 더 많은 추론이 필요할 수 있습니다.

```text
Distributed Transaction 문제 분석

Race Condition 원인 탐색

Architecture Refactoring

Complex Bug Debugging
```

이런 작업은 Reasoning Model을 사용하는 것이 더 적합할 수 있습니다.

```text
Developer Request
       ↓
Complexity 판단
       ↓
┌───────────────┐
│               │
Simple        Complex
  ↓               ↓
Fast Model    Reasoning Model
```

---

### Coding Agent와 Reasoning

Reasoning Model은 Coding Agent에서도 특히 중요합니다.

단순 Code Completion은 비교적 짧은 작업입니다.

```text
Code Context
    ↓
Completion
```

하지만 Agent가 실제 작업을 수행하려면 여러 단계를 거쳐야 합니다.

```text
Task
 ↓
Repository 탐색
 ↓
관련 File 분석
 ↓
원인 추론
 ↓
수정 계획
 ↓
Code 변경
 ↓
Test 실행
 ↓
결과 분석
 ↓
추가 수정
```

이 과정 전체에서 Reasoning 능력이 필요합니다.

---

### Agent Architecture와 연결

2024년 AI Architecture의 흐름을 연결하면 다음과 같습니다.

```text
LLM
 ↓
Memory
 ↓
Tool Calling
 ↓
Reasoning
 ↓
Agent
```

Reasoning Model은 Agent가 복잡한 Workflow를 수행할 수 있게 하는 핵심 요소 중 하나입니다.

```text
Agent

├─ Reasoning
├─ Memory
├─ Tools
├─ MCP
└─ External Data
```

Tool을 많이 사용할 수 있어도 어떤 Tool을 언제 사용할지 판단하지 못하면 Agent의 성능은 제한됩니다.

따라서 Reasoning 능력이 Agent Architecture에서도 중요해집니다.

---

### o3-mini의 의미

OpenAI가 o3와 함께 **o3-mini**도 공개했다는 점 역시 중요했습니다.

이는 Reasoning Model에서도 하나의 Model만 제공하는 것이 아니라 **성능과 비용 사이에 여러 선택지를 만들려는 방향**을 보여줬습니다.

```text
Reasoning Model

├─ High Capability
│      ↓
│     o3
│
└─ Smaller / Efficient
       ↓
    o3-mini
```

Reasoning도 결국 Service Requirement에 따라 선택해야 하는 Resource가 되는 것입니다.

---

### Reasoning도 비용 문제다

일반적인 LLM API 비용은 주로 Token 기준으로 생각했습니다.

```text
Input Tokens
     +
Output Tokens
     ↓
API Cost
```

Reasoning Model에서는 실제 문제 해결 과정에 사용되는 Compute도 중요해집니다.

```text
AI Cost

Input
+
Output
+
Reasoning Compute
```

따라서 개발자는 단순히

```text
어떤 Model이 가장 좋은가?
```

만 고민할 수 없습니다.

```text
이 Task에
이 정도의 Reasoning 비용을
사용할 가치가 있는가?
```

라는 판단이 필요합니다.

---

### 새로운 성능-비용 곡선

Reasoning Model은 AI Service Architecture에 새로운 Trade-off를 만듭니다.

```text
Reasoning Compute ↑

Capability ↑
Latency ↑
Cost ↑
```

따라서 최적의 Point는 Application마다 다릅니다.

```text
Realtime Chat
→ Latency 중요


Coding Agent
→ Capability 중요


Batch Analysis
→ Latency보다 Quality 중요
```

하나의 설정으로 모든 Workload를 처리하기 어려워지는 것입니다.

---

### AI Infrastructure에도 영향을 준다

Inference Compute가 증가하면 Infrastructure 요구사항 역시 달라집니다.

```text
Request
  ↓
Reasoning Model
  ↓
More Compute
  ↓
GPU Usage 증가
```

대규모 서비스에서는 이 차이가 Infrastructure Cost와 직접 연결될 수 있습니다.

```text
Reasoning Request 증가
       ↓
GPU Compute 증가
       ↓
Serving Cost 증가
```

따라서 AI Infrastructure에서도 Request Scheduling과 Model Routing이 중요해집니다.

---

### Scaling의 의미가 바뀐다

기존 AI Scaling은 대부분 Model Training을 의미했습니다.

```text
More GPU
   ↓
Larger Training
   ↓
Better Model
```

Reasoning Model 시대에는 Scaling이 두 단계로 나뉩니다.

```text
Training-time Scaling
        +
Inference-time Scaling
```

즉 Model을 만드는 순간뿐 아니라 **사용하는 순간에도 Compute를 Scaling할 수 있는 구조**가 중요해졌습니다.

---

### 왜 중요한가

o1 하나만 공개됐을 때는 Reasoning Model이 새로운 실험인지 장기적인 전략인지 명확하지 않을 수도 있었습니다.

하지만 몇 달 만에 o3가 등장하면서 방향이 명확해졌습니다.

```text
2024.09
o1
 ↓
Reasoning Model 등장


2024.12
o3
 ↓
Reasoning Scaling 지속
```

Reasoning이 새로운 Model Generation의 핵심 축으로 자리 잡기 시작한 것입니다.

---

### 이후 AI 경쟁의 방향

Reasoning Model 경쟁은 이후 여러 AI Company로 빠르게 확산됩니다.

```text
Reasoning Competition

OpenAI
Anthropic
Google
DeepSeek
기타 Model Provider
```

AI 경쟁 역시 단순한 Parameter Scale에서 다음 영역으로 확대됩니다.

```text
AI Competition

├─ Model Capability
├─ Reasoning
├─ Inference Compute
├─ Tool Use
├─ Agent
├─ Context
└─ Cost Efficiency
```

Reasoning이 Model Benchmark뿐 아니라 실제 AI Product Architecture까지 영향을 주기 시작했습니다.

---

### 개발자 관점에서의 변화

개발자 입장에서 중요한 변화는 AI Model을 단순한 API Endpoint로만 보기 어려워졌다는 것입니다.

```text
기존

request()
   ↓
model
   ↓
response
```

점점 다음과 같은 Configuration 문제가 생깁니다.

```text
AI Request

├─ 어떤 Model?
├─ Reasoning이 필요한가?
├─ 얼마나 많은 Compute?
├─ 최대 Latency는?
├─ 허용 Cost는?
└─ 실패하면 어떤 Model로 Fallback?
```

AI Backend Architecture가 일반적인 Distributed System과 비슷하게 점점 더 복잡해지는 것입니다.

---

### 실무 영향

Reasoning Model이 확산되면서 개발자는 Model 선택을 다음과 같이 바라볼 필요가 생겼습니다.

```text
Model Selection

Model Size
    +
Task Complexity
    +
Reasoning Compute
    +
Latency
    +
Cost
```

예를 들어 Application 내부에서도 다음처럼 서로 다른 전략을 사용할 수 있습니다.

```text
Classification
      ↓
Small Model


Normal Chat
      ↓
General Model


Complex Coding
      ↓
Reasoning Model


Critical Analysis
      ↓
Higher Reasoning Compute
```

AI Application Architecture에서 Model Routing과 Cost Optimization이 더욱 중요해진 것입니다.

2024년 12월 20일(금) 주간 개발트렌드

독자의 메모