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

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

## AI / Backend — Structured Outputs, LLM을 API에 붙이기 쉬워짐

OpenAI가 **8월 6일 Structured Outputs**를 공개했습니다.

Structured Outputs는 개발자가 **JSON Schema를 정의하면 모델의 출력 구조가 해당 Schema를 따르도록 제어할 수 있는 기능**입니다.

이전에도 LLM에게 JSON 형태로 응답하도록 요청할 수 있었지만, 실제 서비스에서는 형식이 조금씩 깨지는 문제가 자주 발생했습니다.

---

### 기존 LLM 연동의 문제

LLM에게 JSON으로 응답하라고 Prompt를 작성하더라도 결과가 항상 일정하다는 보장은 없었습니다.

```json
{
  "name": "Park",
  "age": "???"
}
```

또는 다음처럼 예상하지 못한 형태가 반환될 수도 있었습니다.

```json
{
  "name": "Park",
  "userAge": 34
}
```

Backend에서는 결국 LLM 응답을 받은 뒤 별도의 검증 과정이 필요했습니다.

```text
LLM
 ↓
Raw Response
 ↓
JSON Parsing
 ↓
Validation
 ↓
Schema 불일치?
 ├─ Yes → Retry / Error Handling
 └─ No  → Application
```

즉 LLM의 자연어 생성 능력은 뛰어났지만 **정해진 데이터 구조를 반환해야 하는 Backend Component로 사용하기에는 불안정한 부분**이 있었습니다.

---

### Structured Outputs

Structured Outputs에서는 개발자가 원하는 데이터 구조를 JSON Schema로 정의할 수 있습니다.

예를 들어 사용자 정보를 추출한다고 하면 다음과 같은 구조를 정의할 수 있습니다.

```json
{
  "type": "object",
  "properties": {
    "name": {
      "type": "string"
    },
    "age": {
      "type": "integer"
    }
  },
  "required": ["name", "age"],
  "additionalProperties": false
}
```

이제 전체 흐름은 다음과 같이 바뀝니다.

```text
LLM
 ↓
JSON Schema
 ↓
Structured Output
 ↓
Typed Object
 ↓
Application
```

LLM의 출력을 자연어 문자열로 취급하는 것이 아니라 **Application에서 사용할 구조화된 데이터로 직접 연결하기 쉬워진 것**입니다.

---

### 기존 JSON Mode와의 차이

기존에도 JSON 형태의 출력을 생성하도록 만드는 방법은 있었습니다.

하지만 단순히 JSON이라는 형식만 보장하는 것과 **개발자가 정의한 Schema까지 만족하는 것**은 다른 문제입니다.

```text
JSON Mode

{
  ...
}

→ JSON 형식


Structured Outputs

{
  "name": string,
  "age": integer
}

→ 개발자가 정의한 Schema
```

즉 중요한 변화는 단순히 JSON을 반환하는 것이 아니라 **Application이 기대하는 데이터 Contract에 맞춰 LLM 출력을 제한할 수 있게 됐다는 점**입니다.

---

### 왜 중요한가

Backend에서 외부 시스템을 연결할 때는 일반적으로 명확한 Contract가 존재합니다.

```text
REST API
 ↓
DTO
 ↓
Validation
 ↓
Business Logic
```

하지만 LLM은 기본적으로 자유로운 자연어를 생성하기 때문에 이러한 Backend 구조와 잘 맞지 않는 부분이 있었습니다.

```text
LLM
 ↓
Unstructured Text
 ↓
Parsing
 ↓
Application
```

Structured Outputs가 등장하면서 이 사이에 명확한 데이터 구조를 둘 수 있게 됐습니다.

```text
LLM
 ↓
Schema
 ↓
Structured Data
 ↓
DTO / Typed Object
 ↓
Business Logic
```

LLM을 단순한 Chat UI가 아니라 **Backend Pipeline 내부의 하나의 Component로 사용하기 훨씬 쉬워진 것**입니다.

---

### Backend 관점에서의 변화

LLM을 실제 서비스에 연결할 때 중요한 것은 좋은 문장을 생성하는 것만이 아닙니다.

Backend에서는 결과를 프로그램이 안정적으로 처리할 수 있어야 합니다.

예를 들어 주문 문의를 분석한다고 하면 다음과 같은 데이터를 얻고 싶을 수 있습니다.

```json
{
  "category": "REFUND",
  "orderId": "A-10291",
  "reason": "damaged_product"
}
```

이 데이터를 그대로 Business Logic에 전달할 수 있다면 다음과 같은 구조를 만들 수 있습니다.

```text
User Message
     ↓
    LLM
     ↓
Structured Output
     ↓
Business Logic
     ↓
Refund Workflow
```

LLM이 자연어를 이해하고 Backend가 처리할 수 있는 **Typed Data로 변환하는 계층** 역할을 수행할 수 있게 됩니다.

---

### Data Extraction

Structured Outputs가 특히 유용한 영역 중 하나는 **비정형 데이터에서 구조화된 정보를 추출하는 작업**입니다.

```text
Email / Document / Message
           ↓
          LLM
           ↓
      JSON Schema
           ↓
Structured Data
```

예를 들어 이메일에서 다음 정보를 추출할 수 있습니다.

```json
{
  "sender": "company@example.com",
  "category": "invoice",
  "amount": 120000,
  "currency": "KRW"
}
```

이런 데이터는 이후 Database 저장이나 Workflow 실행에 바로 사용할 수 있습니다.

---

### Function Calling과의 결합

Structured Outputs는 Function Calling과 결합했을 때도 중요합니다.

Agent나 LLM이 Backend Function을 실행하려면 정확한 Parameter가 필요합니다.

```text
User
 ↓
LLM
 ↓
Function 선택
 ↓
Structured Arguments
 ↓
Backend Function
```

예를 들어 다음 Function이 있다고 가정할 수 있습니다.

```text
createOrder(
  productId: string,
  quantity: number
)
```

LLM이 다음과 같은 Arguments를 안정적으로 생성할 수 있다면,

```json
{
  "productId": "P-1004",
  "quantity": 2
}
```

Backend에서는 이를 실제 Function 호출로 연결하기 쉬워집니다.

```text
Natural Language
       ↓
      LLM
       ↓
Structured Arguments
       ↓
createOrder()
       ↓
Application
```

이 구조는 이후 AI Agent Architecture에서도 매우 중요한 패턴이 됩니다.

---

### Workflow에서도 중요한 이유

LLM을 Workflow 내부에 넣을 때 출력이 불안정하면 전체 Pipeline도 불안정해집니다.

```text
Step A
 ↓
LLM
 ↓
Step B
 ↓
Database
 ↓
Step C
```

Step B가 특정 JSON 구조를 기대하고 있는데 LLM이 다른 형태를 반환하면 Workflow 전체가 실패할 수 있습니다.

Structured Outputs를 사용하면 각 단계 사이의 Contract를 명확하게 만들 수 있습니다.

```text
Step A
 ↓
LLM
 ↓
JSON Schema
 ↓
Typed Object
 ↓
Step B
```

따라서 다음과 같은 시스템을 만들 때 활용도가 높습니다.

- Data Extraction
- Document Processing
- Function Calling
- AI Workflow
- AI Agent
- Classification
- Automation Pipeline

---

### Parsing과 Retry 코드 감소

Structured Outputs 이전에는 LLM 응답을 안전하게 사용하기 위해 Backend에서 여러 방어 로직을 작성해야 하는 경우가 많았습니다.

```text
LLM Response
     ↓
JSON.parse()
     ↓
Validation
     ↓
Invalid?
 ├─ Retry
 ├─ Repair
 └─ Error
```

예를 들어 다음과 같은 코드가 필요할 수 있었습니다.

```typescript
const result = await callLLM();

try {
  const data = JSON.parse(result);

  validate(data);

  return data;
} catch {
  return retry();
}
```

Structured Outputs를 사용하면 **출력 형식 자체를 맞추기 위한 Parsing → Validation → Retry 로직을 상당 부분 줄일 수 있게 됐습니다.**

Backend 코드도 자연스럽게 단순해집니다.

```text
LLM
 ↓
Schema
 ↓
Typed Result
 ↓
Business Logic
```

---

### 그렇다고 모든 Validation이 사라지는 것은 아니다

Structured Outputs가 Schema를 보장한다고 해서 LLM의 결과가 항상 **의미적으로 정확하다는 뜻은 아닙니다.**

예를 들어 다음 데이터는 Schema에는 맞습니다.

```json
{
  "name": "Park",
  "age": 120
}
```

`age`가 Integer라는 구조적인 조건은 만족하지만 실제 데이터가 정확한지는 별개의 문제입니다.

따라서 실제 Backend에서는 여전히 다음과 같은 검증이 필요할 수 있습니다.

```text
Schema Validation
      ↓
Business Validation
      ↓
Domain Logic
```

Structured Outputs는 **데이터의 형식을 안정시키는 기술이지 LLM의 판단 자체를 항상 정확하게 만드는 기술은 아닙니다.**

---

### 실무 영향

Structured Outputs는 LLM과 기존 Backend Application 사이에 존재하던 큰 차이를 줄였습니다.

기존에는

```text
LLM
 ↓
Natural Language
 ↓
Parsing
 ↓
Validation
 ↓
Retry
 ↓
Application
```

같은 구조가 필요했다면,

Structured Outputs 이후에는

```text
LLM
 ↓
JSON Schema
 ↓
Typed Object
 ↓
Application
```

에 가까운 구조를 만들 수 있게 됐습니다.

이 변화는 특히 **Extraction, Function Calling, Workflow, Agent**처럼 LLM 결과를 다음 프로그램 단계에서 직접 사용해야 하는 시스템에서 중요했습니다.

결국 Structured Outputs는 단순한 JSON 출력 기능이 아니라,

> **LLM을 자연어 생성기에서 실제 Software Component로 사용하기 위한 중요한 Interface**

라고 볼 수 있습니다.

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

독자의 메모