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

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

## AI — OpenAI o1, Reasoning Model 등장

OpenAI가 9월 12일 `o1-preview`와 `o1-mini`를 공개했습니다.

기존 LLM이 Prompt를 받은 뒤 빠르게 다음 Token을 생성하며 답변하는 방식에 초점이 맞춰져 있었다면, o1은 **응답하기 전에 문제 해결에 더 많은 계산 시간을 사용하는 Reasoning Model**이라는 방향을 전면에 내세웠습니다.

특히 수학, 코딩, 과학처럼 여러 단계의 추론이 필요한 문제에서 기존 모델보다 더 강한 성능을 목표로 설계됐습니다.

[OpenAI - Learning to reason with LLMs](https://openai.com/index/learning-to-reason-with-llms/)

---

### 기존 LLM의 흐름

기존 LLM API를 단순화하면 다음과 같은 구조로 볼 수 있습니다.

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

모델의 성능을 높이는 방법도 주로 더 많은 데이터와 더 큰 모델을 학습시키는 방향에 집중돼 있었습니다.

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

즉 **모델을 학습시키는 단계에서 얼마나 많은 Compute를 사용하는가**가 중요한 경쟁 요소였습니다.

---

### o1의 새로운 방향

o1은 여기에 새로운 축을 추가했습니다.

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

어려운 문제를 받았을 때 바로 답변을 생성하기보다 **문제를 해결하는 과정에 더 많은 계산을 사용하는 방식**입니다.

이를 일반적으로 **Test-time Compute 또는 Inference-time Compute** 관점에서 볼 수 있습니다.

```text
기존

Training Compute
      ↓
Model
      ↓
Answer


Reasoning Model

Training Compute
      ↓
Model
      ↓
Test-time Compute
      ↓
Answer
```

즉 모델을 얼마나 크게 학습했는지만큼 **실제 요청을 처리할 때 얼마나 많은 계산을 사용할 것인가**가 중요해지기 시작했습니다.

---

### 왜 중요한가

이전까지 AI Model 경쟁은 대체로 다음과 같은 요소가 중심이었습니다.

```text
Parameter
+
Training Data
+
Training Compute
```

하지만 Reasoning Model이 등장하면서 새로운 성능 변수가 추가됩니다.

```text
Model
+
Inference Compute
+
Reasoning Time
```

같은 모델이라도 복잡한 문제에서는 더 많은 계산 시간을 사용해 더 나은 결과를 얻는 방향이 본격적으로 등장한 것입니다.

이 변화는 이후 Reasoning Model 경쟁으로 이어지는 중요한 흐름이 됐습니다.

```text
Reasoning Model

OpenAI o1
    ↓
OpenAI o3
DeepSeek R1
Gemini Reasoning 계열
Claude Reasoning 계열
```

2025년 이후 주요 AI 기업들이 **Reasoning과 Test-time Compute를 핵심 경쟁 영역으로 다루기 시작한 흐름**을 이해하는 데 중요한 출발점 중 하나였습니다.

---

### 모든 요청에 Reasoning이 필요한 것은 아니다

Reasoning Model이 더 복잡한 문제를 해결할 수 있다고 해서 모든 요청에 사용하는 것이 항상 좋은 것은 아닙니다.

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

```text
텍스트 분류
간단한 요약
데이터 추출
문장 변환
단순 질의응답
```

반면 다음 작업은 여러 단계의 사고가 필요할 수 있습니다.

```text
복잡한 코딩 문제
수학 문제
Architecture 설계
복잡한 계획 수립
논리 문제
과학 문제
```

따라서 AI Application에서는 다음과 같은 구조를 생각할 수 있습니다.

```text
User Request
     ↓
Task Classification
   ↙            ↘
Simple          Complex
  ↓               ↓
Fast Model    Reasoning Model
  ↓               ↓
Response        Response
```

이전에 중요해진 **Model Routing**이 Reasoning Model의 등장으로 더욱 중요한 Architecture Pattern이 된 것입니다.

---

### Latency와 성능의 Trade-off

Reasoning에 더 많은 Compute를 사용한다는 것은 일반적으로 응답 생성에 더 많은 Resource가 필요할 수 있다는 의미입니다.

따라서 AI Application에서는 새로운 Trade-off가 생깁니다.

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

결국 AI 서비스를 설계할 때는 단순히

```text
어떤 모델이 가장 좋은가?
```

만 고려하는 것이 아니라,

```text
이 요청에
얼마나 많은 추론이 필요한가?
```

까지 고려해야 하게 됩니다.

---

### Backend 관점에서의 변화

Reasoning Model이 등장하면서 Backend에서도 Model 호출 전략이 중요해집니다.

기존에는 다음과 같이 단순한 구조가 가능했습니다.

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

하지만 여러 종류의 모델을 사용하는 환경에서는 다음과 같이 발전할 수 있습니다.

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

Backend는 요청의 성격에 따라 적절한 모델을 선택해야 합니다.

판단 기준도 다양해집니다.

- Task Complexity
- Latency Requirement
- Token Usage
- Inference Cost
- Reasoning 필요 여부
- 사용자 요청 우선순위
- Model Availability

---

### Coding에서의 변화

Reasoning Model이 특히 주목받은 분야 중 하나가 Coding입니다.

단순한 코드 자동완성은 다음과 같이 처리할 수 있습니다.

```text
Code Context
    ↓
Model
    ↓
Code Completion
```

하지만 실제 개발에서 어려운 문제는 단순 Code Generation이 아닙니다.

```text
Requirement
    ↓
문제 분석
    ↓
Architecture 판단
    ↓
원인 추적
    ↓
해결 방법 선택
    ↓
Code
```

복잡한 Bug 분석이나 Algorithm 문제에서는 여러 단계의 판단이 필요하기 때문에 Reasoning Model이 더 적합한 영역이 될 수 있습니다.

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

- 복잡한 Bug 원인 분석
- Algorithm 문제
- Architecture 설계
- Refactoring 전략
- 여러 파일에 걸친 코드 분석
- 복잡한 SQL 작성
- 테스트 실패 원인 추적

AI Coding Assistant에서도 단순히 **코드를 얼마나 빠르게 생성하는가**뿐 아니라 **복잡한 개발 문제를 얼마나 잘 해결하는가**가 중요해지기 시작했습니다.

---

### Agent와 Reasoning

Reasoning Model은 AI Agent Architecture와도 밀접하게 연결됩니다.

Agent는 단순히 답변을 생성하는 것이 아니라 여러 단계의 작업을 수행해야 할 수 있습니다.

```text
Goal
 ↓
Plan
 ↓
Tool 선택
 ↓
Action
 ↓
Result 확인
 ↓
다음 Action 결정
 ↓
Final Result
```

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

```text
Agent

├─ Reasoning
├─ Memory
├─ Tool Calling
├─ Code Execution
└─ External Data
```

따라서 Reasoning 능력이 향상될수록 Agent가 더 복잡한 Workflow를 처리할 가능성도 높아집니다.

---

### AI 비용 구조의 변화

Reasoning Model은 AI 비용을 바라보는 방식에도 변화를 줬습니다.

기존에는 주로 다음 요소를 생각했습니다.

```text
Input Token
+
Output Token
=
API Cost
```

하지만 Reasoning Model에서는 **문제를 해결하기 위해 내부적으로 사용하는 Compute** 역시 중요한 개념이 됩니다.

```text
AI Cost

├─ Input
├─ Output
├─ Model Size
└─ Reasoning Compute
```

즉 AI 서비스의 비용 최적화도 점점 복잡해집니다.

---

### Model Routing과의 결합

실제 서비스에서는 모든 요청을 Reasoning Model에 보내는 것보다 작업에 따라 모델을 분리하는 방식이 현실적일 수 있습니다.

```text
Request
   ↓
AI Router
   │
   ├─ Classification
   │      ↓
   │   Small Model
   │
   ├─ Simple Chat
   │      ↓
   │   Fast Model
   │
   └─ Complex Problem
          ↓
     Reasoning Model
```

이렇게 하면 성능과 비용을 동시에 관리할 수 있습니다.

AI Architecture에서 점점 중요한 문제가

```text
어떤 Model을 사용할 것인가?
```

에서

```text
어떤 Task에
어떤 Model을
얼마나 많은 Compute로
사용할 것인가?
```

로 발전하기 시작한 것입니다.

---

### AI 경쟁의 새로운 축

o1 이전에도 LLM의 추론 능력을 개선하려는 연구는 존재했습니다.

하지만 o1의 공개는 **Reasoning과 Test-time Compute를 제품 수준의 핵심 특징으로 전면에 내세웠다는 점**에서 의미가 컸습니다.

AI 경쟁의 축도 점점 변화합니다.

```text
초기

Model Size
+
Training Data
+
Benchmark


이후

Model
+
Reasoning
+
Inference Compute
+
Tool Use
+
Agent
```

단순히 더 큰 모델을 만드는 경쟁에서 **모델이 얼마나 효과적으로 문제를 해결하도록 Compute를 사용할 수 있는가**까지 경쟁 영역이 확대된 것입니다.

---

### 실무 영향

Reasoning Model이 등장하면서 AI Application을 설계할 때 개발자가 고려해야 할 요소도 늘어났습니다.

```text
AI Application

├─ Model Selection
├─ Model Routing
├─ Reasoning 필요 여부
├─ Latency
├─ Cost
├─ Context
└─ Task Complexity
```

특히 코딩, 수학, 복잡한 분석이나 계획 수립처럼 추론이 중요한 작업에서는 단순히 Parameter 수나 모델 크기만 비교해서는 부족하게 됐습니다.

```text
Model Performance

Model Size
    +
Training
    +
Inference Compute
```

라는 관점이 중요해진 것입니다.

결국 OpenAI o1의 등장은,

> **AI 성능을 높이는 방법이 더 큰 모델을 학습하는 것에서, 실제 문제를 풀 때 더 많은 Compute를 사용하는 방향으로 확장됐다는 중요한 변화**

라고 볼 수 있습니다.

2024년 9월 13일(금) 주간 개발트렌드

독자의 메모