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

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

## AI — OpenAI o3-mini, 추론 모델의 실용화

OpenAI가 **오늘 25년 1월 31일 o3-mini**를 정식 출시했습니다.

o3-mini는 코딩, 수학, 과학 같은 STEM 영역에 최적화된 **소형 Reasoning Model**로, 기존 Reasoning Model의 추론 능력을 유지하면서 비용과 Latency를 낮추는 방향으로 설계됐습니다.

특히 중요한 점은 단순히 추론 성능만 제공한 것이 아니라 **Function Calling, Structured Outputs, Streaming, Developer Message** 같은 실제 Application 개발에 필요한 API 기능을 처음부터 함께 지원했다는 것입니다.

또한 `low`, `medium`, `high` 세 단계의 Reasoning Effort를 선택할 수 있어 Task의 복잡도에 따라 **속도와 추론 깊이를 조절하는 구조**도 제공했습니다.

[OpenAI - OpenAI o3-mini](https://openai.com/ko-KR/index/openai-o3-mini/)

---

### Reasoning Model의 초기 모습

2024년 9월 OpenAI가 o1을 공개하면서 기존 LLM과 다른 새로운 Model Architecture가 본격적으로 등장했습니다.

```text
기존

Prompt
  ↓
LLM
  ↓
Answer


Reasoning Model

Problem
   ↓
Reasoning Compute
   ↓
Answer
```

복잡한 문제에서는 바로 답을 생성하기보다 더 많은 Inference Compute를 사용해 문제를 해결하는 방식입니다.

특히 다음과 같은 영역에서 강점이 있었습니다.

```text
Reasoning Workload

├─ Coding
├─ Mathematics
├─ Science
├─ Algorithm
└─ Complex Planning
```

하지만 초기 Reasoning Model은 일반적인 Application Backend에서 사용하는 Model과는 다소 거리가 있었습니다.

---

### 문제는 Application Integration

실제 AI Application에서는 Model이 똑똑한 것만으로 충분하지 않습니다.

Backend에서는 다음 기능들이 필요합니다.

```text
AI Backend

├─ Tool Calling
├─ Structured Data
├─ Streaming
├─ System Instruction
└─ API Integration
```

예를 들어 LLM이 주문을 처리해야 한다면 단순히 자연어로

```text
주문을 생성하겠습니다.
```

라고 답하는 것은 의미가 없습니다.

실제 Backend Function을 호출해야 합니다.

```text
User
 ↓
LLM
 ↓
Function Calling
 ↓
createOrder()
 ↓
Database
```

Reasoning Model 역시 이런 Application Integration 기능을 지원해야 실제 서비스에 넣을 수 있습니다.

---

### o3-mini의 중요한 변화

o3-mini는 처음부터 주요 Developer Feature를 지원했습니다.

```text
o3-mini

├─ Function Calling
├─ Structured Outputs
├─ Streaming
├─ Developer Message
└─ Reasoning Effort
```

즉 Reasoning Model이 단순히 Benchmark 문제를 잘 푸는 Model에서 벗어나 **일반적인 AI Application Architecture 안에 들어갈 수 있는 Component**가 되기 시작한 것입니다.

---

### Function Calling

Function Calling은 LLM과 실제 Application 기능을 연결하는 핵심 기능입니다.

예를 들어 사용자가 다음과 같이 요청했다고 가정해보겠습니다.

```text
이번 주 주문 내역을 보여줘
```

Model이 직접 Database를 조회하는 것이 아니라 Backend가 제공한 Tool을 선택할 수 있습니다.

```text
User
 ↓
o3-mini
 ↓
getOrders()
 ↓
Backend
 ↓
Database
 ↓
Result
 ↓
o3-mini
 ↓
Response
```

Reasoning Model에 Function Calling이 추가되면 복잡한 판단과 Tool Execution을 함께 사용할 수 있습니다.

---

### Reasoning + Tool Calling

이 조합은 특히 Agent에서 중요합니다.

단순 LLM은 다음과 같이 동작합니다.

```text
Question
   ↓
Model
   ↓
Answer
```

Tool을 사용할 수 있는 Reasoning Model은 다음과 같은 Workflow를 만들 수 있습니다.

```text
Goal
 ↓
Reasoning
 ↓
Tool 선택
 ↓
Tool 실행
 ↓
Result 확인
 ↓
추가 Reasoning
 ↓
다음 Tool
 ↓
Final Answer
```

예를 들어 Coding Agent라면 다음과 같은 작업이 가능합니다.

```text
Bug 분석
 ↓
관련 File 검색
 ↓
Code 확인
 ↓
Test 실행
 ↓
Error 분석
 ↓
수정 방법 판단
```

Reasoning 능력이 실제 Action과 연결되는 것입니다.

---

### Structured Outputs

o3-mini는 Structured Outputs도 지원했습니다.

개발자가 JSON Schema를 정의하면 Model Output을 Application에서 사용할 수 있는 구조화된 형태로 받을 수 있습니다.

```text
Reasoning
   ↓
Structured Outputs
   ↓
JSON Schema
   ↓
Typed Object
   ↓
Backend Logic
```

예를 들어 Code Review 결과를 다음과 같이 받을 수 있습니다.

```json
{
  "severity": "HIGH",
  "category": "CONCURRENCY",
  "file": "OrderService.java",
  "requiresFix": true
}
```

자연어를 다시 Parsing하는 과정 없이 Application Logic과 연결하기 쉬워집니다.

---

### Reasoning Model이 Backend Component가 된다

Function Calling과 Structured Outputs가 결합되면 Reasoning Model을 Backend Pipeline 내부에서 사용할 수 있습니다.

```text
Input
  ↓
o3-mini
  ↓
Reasoning
  ↓
Structured Result
  ↓
Business Logic
```

또는 Tool Calling을 포함하면 다음과 같습니다.

```text
User Request
     ↓
o3-mini
     ↓
Reasoning
     ↓
Tool Calling
     ↓
Backend Function
     ↓
Result
     ↓
Final Response
```

Reasoning Model이 단순한 Chatbot Model에서 **Application Logic의 일부로 들어오기 시작한 것**입니다.

---

### Streaming

Reasoning Model도 실제 사용자-facing Application에서 사용하려면 Response Latency가 중요합니다.

전체 Response가 완성될 때까지 기다리는 방식은 UX가 좋지 않을 수 있습니다.

```text
Request
 ↓
Processing
 ↓
Processing
 ↓
Processing
 ↓
Complete Response
```

Streaming을 사용하면 생성되는 결과를 순차적으로 전달할 수 있습니다.

```text
Request
 ↓
LLM
 ↓
Token
 ↓
Token
 ↓
Token
 ↓
Client
```

Chat, Coding Assistant, AI Agent Interface 같은 서비스에서 특히 중요한 기능입니다.

---

### Developer Message

o3-mini는 Developer Message도 지원했습니다.

Application 개발자가 Model의 기본 동작과 규칙을 지정할 수 있는 Layer입니다.

```text
Developer Instruction
        +
User Request
        ↓
      Model
        ↓
Response
```

예를 들어 다음과 같은 정책을 줄 수 있습니다.

```text
항상 JSON으로 응답

특정 Tool만 사용

특정 Domain 규칙 준수

사용자 요청보다 Application 정책 우선
```

Reasoning Model이 실제 Product 안에서 동작하려면 이러한 **Application-level Control**이 필요합니다.

---

### Reasoning Effort

o3-mini의 또 다른 중요한 특징은 Reasoning Effort를 조절할 수 있다는 점입니다.

```text
low

빠른 Response
낮은 Reasoning


medium

속도와 성능의 균형


high

더 많은 Reasoning
복잡한 문제
```

즉 Model을 하나 선택했다고 모든 요청에서 동일한 수준의 Compute를 사용할 필요가 없습니다.

```text
o3-mini

      ┌─ low
      ├─ medium
      └─ high
```

Inference Compute 자체가 Application Configuration이 된 것입니다.

---

### 같은 모델 안에서도 Routing이 가능해진다

기존 Model Routing은 주로 서로 다른 Model을 선택하는 방식이었습니다.

```text
Simple Task
    ↓
Small Model


Complex Task
    ↓
Large Model
```

Reasoning Effort가 등장하면 같은 Model 안에서도 다른 전략을 사용할 수 있습니다.

```text
o3-mini

Simple Coding
     ↓
Reasoning Low


Normal Problem
     ↓
Reasoning Medium


Complex Algorithm
     ↓
Reasoning High
```

따라서 AI Backend의 Routing 전략이 더욱 세분화됩니다.

---

### Model Routing

실제 Application에서는 모든 요청에 Reasoning Model을 사용할 필요가 없습니다.

예를 들어 다음 작업은 비교적 단순합니다.

```text
Classification

Formatting

Simple Extraction

Short Summary
```

이런 작업에는 빠르고 저렴한 Model이 적합할 수 있습니다.

반면 다음과 같은 작업은 Reasoning Model이 더 적합할 수 있습니다.

```text
Complex Coding

Architecture Analysis

Mathematics

Debugging

Multi-step Planning
```

따라서 다음과 같은 Architecture가 현실적입니다.

```text
User Request
     ↓
AI Router
     │
     ├─ Simple Task
     │      ↓
     │   Small Model
     │
     ├─ General Task
     │      ↓
     │ General Model
     │
     └─ Reasoning Task
            ↓
         o3-mini
```

---

### Coding에서도 같은 문제가 발생한다

Coding이라고 해서 모든 요청에 깊은 Reasoning이 필요한 것도 아닙니다.

```text
변수 이름 변경
     ↓
Fast Model


DTO 생성
     ↓
Small Model


Race Condition 분석
     ↓
Reasoning Model


Architecture 설계
     ↓
Reasoning Model
```

Application은 요청의 성격에 따라 Model을 선택해야 합니다.

```text
Coding Request
     ↓
Complexity Classification
     ↓
Model Routing
```

이 구조가 비용과 Latency를 동시에 관리하는 핵심 전략이 됩니다.

---

### 왜 비용이 중요한가

AI Service의 사용량이 증가하면 작은 Model 가격 차이도 전체 Infrastructure Cost에 큰 영향을 줍니다.

```text
1 Request
→ 작은 차이


1,000,000 Requests
→ 큰 비용 차이
```

따라서 모든 요청에 가장 높은 성능의 Model을 사용하는 방식은 비효율적일 수 있습니다.

```text
모든 Request
      ↓
High Reasoning Model
      ↓
높은 Cost
```

대신 다음과 같은 구조를 사용할 수 있습니다.

```text
전체 Request

├─ 70% Simple
│     ↓
│ Small Model
│
├─ 20% General
│     ↓
│ General Model
│
└─ 10% Complex
      ↓
  Reasoning Model
```

Model Routing이 AI Product의 Unit Economics와 직접 연결됩니다.

---

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

Reasoning을 많이 사용할수록 Response 시간이 늘어날 수 있습니다.

따라서 Architecture에서는 세 가지 요소를 함께 봐야 합니다.

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

어떤 Model이 가장 높은 Benchmark를 기록했는지만으로는 실제 Application에 적합한지 판단하기 어렵습니다.

예를 들어 실시간 Chat에서는

```text
Latency
```

가 중요할 수 있고,

복잡한 Coding Agent에서는

```text
Reasoning Quality
```

가 더 중요할 수 있습니다.

Batch Analysis에서는 Latency보다

```text
Cost
+
Accuracy
```

가 중요할 수도 있습니다.

---

### AI Backend 구조의 변화

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

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

Model 종류가 많아지면서 Architecture가 달라집니다.

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

그리고 Reasoning Level까지 들어오면 더 세분화됩니다.

```text
AI Router

├─ Small Model
├─ General Model
└─ o3-mini
      ├─ low
      ├─ medium
      └─ high
```

AI Backend가 단순 API Wrapper에서 **Inference Strategy를 관리하는 Layer**로 발전하는 것입니다.

---

### Agent에도 중요한 변화

Agent는 일반적인 Chat보다 Reasoning Model 활용도가 높을 수 있습니다.

Agent는 여러 Step을 거쳐야 하기 때문입니다.

```text
Goal
 ↓
Plan
 ↓
Tool
 ↓
Result
 ↓
Reasoning
 ↓
Next Action
```

여기에 o3-mini의 Developer Feature를 결합하면 다음과 같은 구조가 만들어집니다.

```text
Agent

├─ Reasoning
├─ Function Calling
├─ Structured Outputs
├─ Streaming
└─ Developer Instructions
```

Reasoning Model이 Agent Backend 안에서 실제로 사용할 수 있는 Component가 된 것입니다.

---

### o1에서 o3-mini까지의 변화

Reasoning Model의 발전 흐름을 보면 의미가 더 명확합니다.

```text
2024.09

o1
 ↓
Reasoning Model 등장


2024.12

o3 / o3-mini 사전 공개
 ↓
Reasoning Scaling 지속


2025.01

o3-mini
 ↓
Developer API 기능 지원
 ↓
Application Integration
```

Reasoning이 단순한 연구나 Benchmark 단계에서 **실제 Product Engineering 영역으로 내려오기 시작한 것**입니다.

---

### DeepSeek-R1과 함께 보면 더 중요한 흐름

같은 시기 DeepSeek-R1 같은 Reasoning Model도 등장하면서 시장의 경쟁 기준도 빠르게 변하고 있었습니다.

```text
Reasoning Model Competition

├─ Performance
├─ Cost
├─ Latency
├─ API Feature
├─ Open Weight
└─ Deployment Option
```

단순히 누가 더 높은 Reasoning Benchmark를 기록하는가가 아니라 **누가 실제 Application에 더 효율적으로 통합될 수 있는가**가 중요해졌습니다.

---

### 개발자 입장에서의 변화

AI Model을 선택하는 질문도 달라집니다.

기존에는

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

였다면,

점점 다음과 같이 변합니다.

```text
이 Task는 Reasoning이 필요한가?

얼마나 많은 Reasoning이 필요한가?

Function Calling이 필요한가?

Structured Output이 필요한가?

허용 가능한 Latency는?

Request당 얼마까지 사용할 것인가?
```

Model Selection 자체가 Backend Architecture의 일부가 된 것입니다.

---

### 실무 영향

o3-mini는 Reasoning Model이 실제 Application Backend에 들어가기 위한 조건을 상당 부분 갖춘 모델이었습니다.

```text
Reasoning
+
Function Calling
+
Structured Outputs
+
Streaming
+
Developer Message
```

개발자는 Reasoning Model을 단순히 별도의 실험용 Model로 사용하는 것이 아니라 기존 AI Application Architecture 안에 포함시킬 수 있게 됐습니다.

동시에 모든 요청에 Reasoning Model을 사용하는 것보다는 다음과 같은 Routing Strategy가 더욱 중요해졌습니다.

```text
Normal Request
      ↓
Fast / Cheap Model


Complex Request
      ↓
Reasoning Model


Complex Coding
      ↓
Reasoning Model
      +
Higher Reasoning Effort
```

결국 o3-mini의 등장은,

> **Reasoning Model이 Benchmark용 고성능 모델에서 Function Calling과 Structured Outputs를 갖춘 실용적인 Application Backend Component로 내려온 변화**

라고 볼 수 있습니다.

이 시점부터 AI Backend에서는 단순히 가장 강력한 Model을 선택하는 것보다 **Task마다 적절한 Model과 Reasoning Compute를 선택하는 Model Routing Architecture가 비용과 Latency, 성능을 결정하는 핵심 요소**로 더욱 중요해지기 시작했습니다.

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

독자의 메모