2024년 11월 15일(금) 주간 개발트렌드

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

## AI / Developer Tools — Predicted Outputs, AI 코드 수정 Latency 최적화

OpenAI가 **24년 11월 4일 Predicted Outputs**를 API에 추가했습니다.

Predicted Outputs는 모델이 생성할 결과의 대부분을 이미 알고 있고 **일부 내용만 변경될 것으로 예상되는 경우 기존 결과를 `prediction`으로 제공해 응답 Latency를 줄이는 기능**입니다.

특히 기존 코드 파일이나 문서의 일부만 수정한 뒤 전체 결과를 다시 반환해야 하는 작업이 대표적인 사용 사례였습니다.

---

### 기존 LLM 코드 수정 방식

예를 들어 1,000줄짜리 코드 파일에서 단 3줄만 수정한다고 가정할 수 있습니다.

```text
1000줄 Code
    ↓
3줄 수정 요청
    ↓
LLM
    ↓
1000줄 전체 다시 생성
```

실제로 변경되는 부분은 매우 적지만 모델 입장에서는 전체 결과를 다시 출력해야 합니다.

```text
Original

Line 1
Line 2
Line 3
...
Line 1000


수정

Line 1
Line 2
Changed Line
...
Line 1000
```

대부분의 결과가 기존 파일과 동일한데도 전체 Token을 다시 생성하면서 사용자가 결과를 기다려야 했습니다.

---

### Predicted Outputs

Predicted Outputs에서는 **최종 응답으로 나올 가능성이 높은 기존 내용을 모델에게 미리 제공**할 수 있습니다.

```text
Original Code
     ↓
prediction
     ↓
LLM
     ↓
변경된 부분을 포함한 결과
```

개념적으로 보면 모델에게 다음과 같이 알려주는 것입니다.

```text
최종 결과는
아마 이 내용과 거의 같을 것이다.

여기에서 필요한 부분만
수정하면 된다.
```

이런 상황에서는 모델이 기존 결과와 일치하는 부분을 활용하면서 더 빠르게 응답을 생성할 수 있습니다.

---

### 예를 들어

다음과 같은 코드가 있다고 가정해보겠습니다.

```javascript
class User {
  constructor() {
    this.name = '';
    this.username = '';
  }
}
```

요청은 매우 단순합니다.

```text
username을 email로 변경해줘
```

최종 결과는 대부분 기존 코드와 같습니다.

```javascript
class User {
  constructor() {
    this.name = '';
    this.email = '';
  }
}
```

기존 방식에서는 전체 코드를 다시 생성해야 하지만 Predicted Outputs에서는 기존 파일 자체를 예상 결과로 전달할 수 있습니다.

```javascript
prediction: {
  type: 'content',
  content: existingCode
}
```

전체 결과의 대부분이 그대로 유지될 것으로 예상되는 작업에서 특히 효과적인 구조입니다.

---

### 왜 중요한가

이 기능에서 중요한 것은 모델의 Intelligence가 향상됐다는 점이 아닙니다.

핵심은 **AI Application의 실제 사용자 경험을 개선하기 위한 Inference Optimization이 API 수준으로 내려오기 시작했다는 점**입니다.

AI 모델 경쟁 초기에는 주로 다음 요소가 중요했습니다.

```text
Model

├─ Intelligence
├─ Benchmark
├─ Context Window
└─ Coding Performance
```

하지만 AI가 실제 Application과 IDE에 들어가기 시작하면서 다른 요소가 중요해졌습니다.

```text
AI Product

Intelligence
+
Latency
+
Streaming
+
Context
+
Tooling
+
UX
```

모델이 아무리 좋은 답을 만들어도 수정 결과가 나오기까지 오래 기다려야 한다면 개발 Workflow에서는 불편할 수밖에 없습니다.

---

### IDE에서는 Latency가 더 중요하다

일반적인 Chat 서비스에서는 사용자가 몇 초 정도 응답을 기다리는 상황이 어느 정도 허용될 수 있습니다.

하지만 IDE에서는 이야기가 다릅니다.

```text
Developer
    ↓
Code 수정 요청
    ↓
AI
    ↓
수정 결과
    ↓
Developer 확인
```

이 과정은 하루에도 여러 번 반복될 수 있습니다.

예를 들어 AI에게 다음과 같은 요청을 계속할 수 있습니다.

```text
이 변수 이름 바꿔줘

이 함수 async로 변경해줘

여기에 validation 추가해줘

이 부분만 refactoring 해줘

Type 정의 하나 추가해줘
```

하나하나는 작은 수정이지만 매번 몇 초씩 기다리면 개발 흐름이 끊길 수 있습니다.

```text
Latency 증가
    ↓
Developer 대기
    ↓
Context Switching
    ↓
개발 흐름 저하
```

따라서 AI Coding Tool에서는 모델 성능뿐 아니라 **수정 결과가 얼마나 빠르게 화면에 나타나는가**도 중요한 경쟁 요소가 됩니다.

---

### Code Generation과 Code Editing은 다르다

새로운 코드를 처음부터 생성하는 작업과 기존 코드를 수정하는 작업은 성격이 다릅니다.

```text
Code Generation

Blank
  ↓
LLM
  ↓
New Code
```

반면 Code Editing은 대부분의 내용이 이미 존재합니다.

```text
Code Editing

Existing Code
     ↓
Small Change
     ↓
Mostly Same Code
```

따라서 두 작업을 동일한 방식으로 처리할 필요가 없습니다.

Predicted Outputs는 바로 **Code Editing처럼 기존 결과를 상당 부분 알고 있는 Workload를 최적화하기 위한 접근 방식**입니다.

---

### Document Editing도 마찬가지

이 구조는 코드에만 적용되는 개념이 아닙니다.

문서를 조금 수정하는 작업에서도 사용할 수 있습니다.

```text
기존 Document

100 Paragraphs
      ↓
2 Paragraphs 수정
      ↓
전체 Document 반환
```

예를 들어

```text
이 문서에서 회사 이름만 변경해줘

마지막 문단만 수정해줘

이 문장의 표현만 자연스럽게 바꿔줘
```

같은 요청에서는 최종 결과 대부분을 이미 예상할 수 있습니다.

```text
Existing Document
       ↓
Prediction
       ↓
LLM Editing
       ↓
Updated Document
```

따라서 AI 기반 Document Editor에서도 활용할 수 있는 형태입니다.

---

### Accepted Prediction

Predicted Outputs에서는 모델이 생성하려는 결과와 Prediction이 일치하는 부분을 활용할 수 있습니다.

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

```text
Prediction

AAAAA
BBBBB
CCCCC
DDDDD

       ↓

Model Output

AAAAA
BBBBB
XXXXX
DDDDD
```

대부분은 기존 Prediction과 동일하고 일부만 달라지는 형태입니다.

```text
Same
Same
Changed
Same
```

Prediction이 실제 결과와 많이 일치할수록 이런 방식의 Latency Optimization이 유리해집니다.

---

### 어떤 작업에 적합한가

Predicted Outputs는 특히 **출력 결과의 대부분을 미리 알고 있는 작업**에 적합합니다.

```text
Good Use Case

├─ Code Editing
├─ Code Refactoring
├─ Document Editing
├─ Configuration 수정
├─ Template 수정
└─ 기존 파일 일부 변경
```

반대로 새로운 결과를 처음부터 만들어야 하는 작업에서는 활용도가 낮습니다.

```text
새로운 Architecture 작성

새로운 코드 전체 생성

Open-ended 질문

새로운 문서 작성
```

이 경우에는 예상 가능한 출력 자체가 거의 없기 때문입니다.

---

### Developer Tool 관점에서의 변화

Predicted Outputs는 AI Developer Tool의 성능을 바라보는 기준이 변하고 있다는 것을 보여줍니다.

초기에는 주로

```text
AI가 코드를 잘 작성하는가?
```

가 중요했습니다.

점점 다음 요소들이 함께 중요해졌습니다.

```text
Coding AI

├─ Code Quality
├─ Reasoning
├─ Repository Context
├─ Latency
├─ Streaming
├─ Editing UX
└─ Tool Integration
```

실제 IDE에서는 Benchmark 몇 점의 차이보다 **사용자가 수정 결과를 얼마나 빠르게 확인할 수 있는가**가 더 크게 체감될 수도 있습니다.

---

### AI 코드 수정 Architecture

AI Code Editor를 단순화하면 다음과 같은 구조를 생각할 수 있습니다.

```text
Editor
  ↓
Current File
  ↓
User Instruction
  ↓
LLM
  ↓
Updated File
```

Predicted Outputs를 활용하면 현재 파일 자체를 Prediction으로 활용할 수 있습니다.

```text
Editor
  │
  ├─ Current File
  │
  └─ Edit Instruction
          ↓
       LLM API
          +
      Prediction
          ↓
     Updated File
```

즉 IDE가 이미 가지고 있는 정보를 **Inference Optimization에 직접 활용하는 구조**입니다.

---

### Context와 Prediction의 차이

Prediction은 단순히 Context를 전달하는 것과 목적이 다릅니다.

Context는 모델이 작업을 이해하기 위해 사용합니다.

```text
Context
   ↓
모델이 문제를 이해
```

Prediction은 **최종 출력이 어떻게 생겼을지 예상되는 결과**를 제공합니다.

```text
Prediction
   ↓
예상 Output 제공
   ↓
Generation Latency 최적화
```

따라서 둘은 함께 사용할 수도 있습니다.

```text
Repository Context
        +
Current File
        +
Prediction
        ↓
       LLM
        ↓
Edited Result
```

---

### Backend 관점에서의 의미

AI API를 사용하는 Backend에서도 Latency Optimization이 중요한 Architecture 문제가 됩니다.

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

이 구조에서는 LLM 응답 시간이 전체 API Latency에 직접적인 영향을 줍니다.

```text
Total Latency

Network
+
Backend
+
LLM Inference
+
Output Generation
```

특히 출력이 긴 작업에서는 Output Generation 시간이 전체 Response Time의 상당 부분을 차지할 수 있습니다.

따라서 기존 결과를 활용할 수 있는 경우 이를 API 요청에 포함해 **Generation 단계를 최적화하는 전략**이 의미를 가지게 됩니다.

---

### AI UX 경쟁으로 이동

AI Model 경쟁이 성숙하면서 제품 경쟁의 기준도 확대되기 시작했습니다.

```text
초기

Better Model
     ↓
Better AI Product
```

점점 다음과 같이 바뀝니다.

```text
AI Product

Model
+
Context
+
Latency
+
Streaming
+
Caching
+
Prediction
+
Tooling
+
UX
```

같은 모델을 사용하더라도 Application Layer를 어떻게 설계하느냐에 따라 실제 사용자 경험이 크게 달라질 수 있습니다.

Predicted Outputs는 이러한 흐름을 잘 보여주는 기능입니다.

---

### 실무 영향

Predicted Outputs가 특히 의미 있는 영역은 다음과 같습니다.

```text
AI Code Editor
IDE Agent
Document Editor
Code Refactoring Tool
AI Pair Programmer
```

이런 제품에서는 사용자가

```text
파일 전체를 새로 만들어줘
```

보다

```text
여기만 고쳐줘
```

라고 요청하는 경우가 훨씬 많습니다.

따라서 기존 파일을 활용해 Output Generation Latency를 줄이는 것은 실제 개발 경험에 직접적인 영향을 줄 수 있습니다.

결국 Predicted Outputs는,

> **AI Coding 경쟁이 더 똑똑한 모델을 만드는 것뿐 아니라 실제 개발 Workflow에서 기다리는 시간을 얼마나 줄일 수 있는가까지 확장됐다는 변화**

라고 볼 수 있습니다.

2024년 11월 8일(금) 주간 개발트렌드

독자의 메모