2025년 3월 21일(금) 주간 개발트렌드

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

## AI / Backend — OpenAI Responses API + Agents SDK 등장

OpenAI가 **25년 3월 11일 Responses API와 Agents SDK**를 공개했습니다.

Responses API는 기존 Chat Completions의 단순한 호출 방식과 Assistants API의 Tool 사용 기능을 결합한 **Agentic Application 구축용 API**로 등장했습니다.

동시에 **Web Search, File Search, Computer Use** 같은 Built-in Tool을 제공하면서 개발자가 모든 외부 기능을 직접 구현하지 않아도 모델이 여러 Tool을 사용해 복잡한 작업을 수행할 수 있는 기반이 만들어졌습니다.

Agents SDK도 함께 공개되면서 Single Agent와 Multi-Agent Workflow를 구성하고 실행 과정을 Trace할 수 있는 공식적인 Agent 개발 도구가 제공되기 시작했습니다.

[OpenAI - New tools for building agents](https://openai.com/index/new-tools-for-building-agents/)

---

### 기존 LLM Application

초기의 LLM Application은 비교적 단순했습니다.

```text
User
 ↓
Prompt
 ↓
LLM
 ↓
Response
```

Backend에서는 사용자의 입력을 Model API에 전달하고 생성된 결과를 다시 반환하면 됐습니다.

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

주요 관심사 역시 비교적 단순했습니다.

```text
Prompt

Model

Token

Streaming

Response
```

하지만 AI가 실제 작업을 수행하기 시작하면서 이 구조만으로는 부족해졌습니다.

---

### Agent Application

Agent는 단순히 질문에 답하는 것이 아니라 **목표를 달성하기 위해 여러 작업을 순차적으로 수행**할 수 있습니다.

```text
Goal
 ↓
Reasoning
 ↓
Tool
 ↓
Result
 ↓
Reasoning
 ↓
Tool
 ↓
Result
 ↓
Response
```

예를 들어 사용자가 다음과 같이 요청할 수 있습니다.

```text
최근 AI 시장 동향을 조사하고
내부 문서와 비교해서 요약해줘
```

단순 LLM이라면 자신이 가지고 있는 Context 안에서 답변해야 합니다.

Agent는 여러 Tool을 사용할 수 있습니다.

```text
User Goal
    ↓
Agent
    ↓
Web Search
    ↓
검색 결과 확인
    ↓
File Search
    ↓
내부 문서 확인
    ↓
Reasoning
    ↓
Final Response
```

AI Application이 **Single Model Call에서 Multi-step Execution 구조**로 바뀌는 것입니다.

---

### Responses API

Responses API는 이런 Agentic Application을 구축하기 위한 새로운 API Primitive로 등장했습니다.

기존 구조는 다음과 같았습니다.

```text
Application
    ↓
LLM API
    ↓
Text Response
```

Responses API에서는 Tool을 포함하는 구조를 만들 수 있습니다.

```text
Application
    ↓
Responses API
    ↓
Model
    │
    ├─ Web Search
    ├─ File Search
    ├─ Computer Use
    └─ Function
```

Model이 문제를 해결하는 과정에서 필요한 Tool을 선택해서 사용할 수 있는 기반입니다.

---

### Web Search

Web Search Tool을 사용하면 Model이 최신 Web 정보를 검색할 수 있습니다.

```text
User Question
     ↓
Model
     ↓
Web Search
     ↓
Search Result
     ↓
Model
     ↓
Answer
```

기존에는 개발자가 별도의 Search API를 연결해야 했습니다.

```text
LLM
 ↓
Custom Search Integration
 ↓
Search API
 ↓
Result
 ↓
LLM
```

Responses API에서는 OpenAI가 제공하는 Built-in Tool로 이 과정을 연결할 수 있게 됐습니다.

대표적인 활용 사례는 다음과 같습니다.

```text
Research Agent

Travel Agent

Shopping Assistant

Market Research

News Analysis
```

---

### File Search

File Search는 Model이 개발자가 제공한 문서나 데이터를 검색할 수 있도록 합니다.

```text
User Question
     ↓
Agent
     ↓
File Search
     ↓
Relevant Document
     ↓
Model
     ↓
Answer
```

기업 내부 문서 기반 AI Assistant를 만든다면 다음과 같은 구조가 가능합니다.

```text
Company Documents
       ↓
File Search
       ↓
Agent
       ↓
Employee Question
       ↓
Answer
```

RAG 기반 Application에서 직접 Retrieval Infrastructure를 구성해야 하는 부담을 줄일 수 있는 선택지가 생긴 것입니다.

---

### Computer Use

Computer Use는 Agent가 화면을 보고 Computer Interface와 상호작용할 수 있도록 하는 Tool입니다.

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

```text
Agent
  ↓
Computer Use
  ↓
UI 확인
  ↓
Click / Type
  ↓
결과 확인
  ↓
다음 행동
```

기존 Tool Calling이 API 중심이었다면 Computer Use는 **GUI 기반 Software까지 Agent가 사용할 수 있는 영역을 확장**했습니다.

```text
기존

Agent
 ↓
API


확장

Agent
 ↓
UI / Computer
```

API가 존재하지 않는 Software에서도 Agent Automation을 구성할 수 있는 가능성이 생긴 것입니다.

---

### Function Calling과 함께 사용

Built-in Tool만 사용하는 것이 아니라 개발자가 직접 만든 Function도 Agent에게 제공할 수 있습니다.

예를 들어 쇼핑 서비스라면 다음과 같은 Tool을 만들 수 있습니다.

```text
search_products()

get_product()

create_order()

cancel_order()
```

전체 Workflow는 다음과 같이 구성할 수 있습니다.

```text
User
 ↓
Agent
 ↓
search_products()
 ↓
Result
 ↓
Reasoning
 ↓
create_order()
 ↓
Backend
 ↓
Database
```

LLM이 실제 Application의 Business Function과 연결됩니다.

---

### Agents SDK

Responses API와 함께 **Agents SDK**도 공개됐습니다.

Agents SDK는 Agent Workflow를 보다 쉽게 구성하기 위한 개발 도구입니다.

```text
Agents SDK

├─ Agent
├─ Tool
├─ Handoff
├─ Workflow
└─ Tracing
```

Model API만 직접 호출해 Agent Loop를 모두 구현하는 대신 Agent의 실행 흐름을 관리할 수 있는 Framework Layer가 생긴 것입니다.

---

### Single Agent

가장 기본적인 형태는 하나의 Agent가 여러 Tool을 사용하는 구조입니다.

```text
Agent
  │
  ├─ Web Search
  ├─ File Search
  └─ Internal API
```

사용자의 Goal을 해결하기 위해 Agent가 필요한 Tool을 선택합니다.

```text
Goal
 ↓
Agent
 ↓
Tool 선택
 ↓
Result
 ↓
Reasoning
 ↓
Response
```

---

### Multi-Agent

Agents SDK는 여러 Agent가 역할을 나눠 수행하는 Workflow도 구성할 수 있도록 설계됐습니다.

```text
Main Agent
    ↓
 ┌──┼─────────┐
 ↓  ↓         ↓
Research   Coding   Support
Agent      Agent    Agent
```

각 Agent가 특정 역할을 담당하고 필요하면 다른 Agent로 작업을 넘길 수 있습니다.

예를 들어 Software Development Agent라면 다음처럼 나눌 수도 있습니다.

```text
Development Agent

├─ Planning Agent
├─ Coding Agent
├─ Test Agent
└─ Review Agent
```

Agent Application 자체가 작은 Distributed Workflow처럼 발전할 수 있는 구조입니다.

---

### Tracing

Agent가 여러 Tool을 호출하기 시작하면 Debugging이 어려워집니다.

일반 LLM Application은 비교적 단순합니다.

```text
Input
 ↓
Model
 ↓
Output
```

Agent에서는 여러 단계가 발생합니다.

```text
Input
 ↓
Reasoning
 ↓
Tool A
 ↓
Result
 ↓
Tool B
 ↓
Error
 ↓
Retry
 ↓
Tool C
 ↓
Response
```

문제가 발생했을 때 어떤 단계에서 실패했는지 확인할 수 있어야 합니다.

Agents SDK에서는 이런 Agent 실행을 추적할 수 있는 **Tracing 기능**도 중요한 구성 요소로 제공됐습니다.

```text
Agent Trace

Step 1 → Model

Step 2 → Tool Call

Step 3 → Tool Result

Step 4 → Handoff

Step 5 → Final Response
```

Agent 환경에서는 Observability가 선택 사항이 아니라 핵심 기능이 됩니다.

---

### 기존 Backend와 Agent Backend의 차이

기존 AI Backend는 비교적 단순했습니다.

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

Agent Backend에서는 훨씬 많은 Component가 필요합니다.

```text
Client
  ↓
Agent Backend
  ↓
Agent Runtime
  │
  ├─ Model
  ├─ Tools
  ├─ State
  ├─ Permission
  ├─ Retry
  ├─ Timeout
  └─ Trace
```

LLM을 호출하는 것보다 **LLM이 수행하는 작업을 안전하게 제어하는 것**이 중요해집니다.

---

### Tool Permission

Agent가 Tool을 사용할 수 있다고 해서 모든 Tool을 자유롭게 실행하게 해서는 안 됩니다.

Tool마다 위험 수준이 다릅니다.

```text
search_document

→ Read


create_file

→ Write


delete_user

→ Destructive Action


deploy_production

→ Critical Action
```

따라서 Agent Backend에는 Permission Layer가 필요합니다.

```text
Agent
 ↓
Permission Check
 ↓
Tool
```

Action의 위험 수준에 따라 실행 정책을 다르게 설정할 수 있습니다.

```text
Low Risk
→ 자동 실행


Medium Risk
→ Policy 확인


High Risk
→ 사용자 승인
```

---

### Human Approval

Agent가 외부 시스템을 변경하는 경우에는 사용자의 승인을 요구할 수도 있습니다.

```text
Agent
 ↓
주문 취소 요청
 ↓
Approval
 ↓
User Confirm
 ↓
Tool Execution
```

예를 들어 다음 작업은 자동으로 실행하기보다 확인 절차를 두는 것이 안전할 수 있습니다.

```text
Database 변경

결제

파일 삭제

Production Deploy

Email 발송

계정 변경
```

Agent Architecture에서는 **어디까지 AI에게 자율성을 줄 것인가**도 중요한 설계 문제가 됩니다.

---

### Timeout

Agent는 여러 Tool을 반복해서 사용하기 때문에 실행 시간이 길어질 수 있습니다.

```text
Agent
 ↓
Tool A
 ↓
Tool B
 ↓
Tool C
 ↓
Tool D
```

외부 API 하나가 응답하지 않으면 전체 Agent Workflow가 멈출 수도 있습니다.

따라서 Tool별 Timeout 관리가 필요합니다.

```text
Tool Call
   ↓
Timeout
   ↓
Success?
 ├─ Yes → Continue
 └─ No  → Retry / Fallback / Stop
```

일반적인 Distributed System과 비슷한 문제가 발생합니다.

---

### Retry

외부 Tool은 실패할 수 있습니다.

```text
API Timeout

Network Error

Rate Limit

Temporary Failure
```

따라서 Agent Runtime에서는 Retry Policy도 중요합니다.

```text
Tool Call
 ↓
Failure
 ↓
Retry
 ↓
Failure
 ↓
Fallback / Stop
```

하지만 모든 작업을 무작정 Retry하면 안 됩니다.

특히 Write Operation에서는 문제가 됩니다.

---

### Idempotency

예를 들어 Agent가 결제 API를 호출했다고 가정해보겠습니다.

```text
Agent
 ↓
createPayment()
 ↓
Timeout
```

Agent 입장에서는 요청이 실패했는지, 결제는 성공했지만 Response만 받지 못한 것인지 알 수 없습니다.

그 상태에서 다시 실행하면,

```text
createPayment()
 ↓
Retry
 ↓
Double Payment
```

같은 문제가 발생할 수 있습니다.

따라서 Side Effect가 있는 Tool은 **Idempotency를 고려해서 설계해야 합니다.**

```text
Agent
 ↓
Tool Call
 ↓
Idempotency Key
 ↓
Backend
 ↓
한 번만 실행
```

기존 Payment나 Distributed System에서 중요했던 개념이 Agent Backend에서도 그대로 중요해집니다.

---

### Agent와 Distributed System

Agent Architecture를 보면 기존 Backend Engineering과 상당히 비슷합니다.

```text
Agent System

├─ Retry
├─ Timeout
├─ Idempotency
├─ State
├─ Permission
├─ Logging
├─ Rate Limit
└─ Failure Handling
```

AI가 새로운 기술처럼 보이지만 실제 Production Agent를 만드는 문제는 결국 **Distributed System Engineering 문제**와 연결됩니다.

---

### State Management

Agent는 여러 단계에 걸쳐 작업하기 때문에 현재 상태를 관리해야 합니다.

```text
Goal

Step 1
 ↓
Tool A

Step 2
 ↓
Tool B

Step 3
 ↓
Result
```

Backend에서는 다음과 같은 정보를 저장할 수 있습니다.

```text
Agent State

├─ Goal
├─ Conversation
├─ Current Step
├─ Tool Results
├─ User Approval
└─ Execution Status
```

장시간 실행되는 Agent나 비동기 Workflow에서는 특히 중요합니다.

---

### Cost Limit

Agent가 반복적으로 Model과 Tool을 호출하면 비용도 예상보다 커질 수 있습니다.

```text
Agent Run

Model Call
   +
Tool
   +
Model Call
   +
Tool
   +
Model Call
```

단순 Chat Request 하나보다 훨씬 많은 Token과 Compute를 사용할 수 있습니다.

따라서 다음과 같은 제한이 필요할 수 있습니다.

```text
Agent Budget

├─ Max Model Calls
├─ Max Tool Calls
├─ Max Tokens
├─ Max Execution Time
└─ Max Cost
```

Agent가 목표를 달성하지 못한 채 무한히 반복하는 상황을 막아야 합니다.

---

### Loop Control

Agent는 Tool Result를 보고 계속 다음 행동을 결정합니다.

잘못 설계하면 반복 Loop에 빠질 수도 있습니다.

```text
Tool A
 ↓
Agent
 ↓
Tool A
 ↓
Agent
 ↓
Tool A
 ↓
...
```

따라서 Agent Runtime에서는 실행 횟수나 단계 수를 제한해야 합니다.

```text
max_steps = 20

max_tool_calls = 10

timeout = 60s
```

Reasoning 능력만큼 **Execution Control**이 중요합니다.

---

### Error Handling

Agent가 Tool을 사용할 때 다양한 Error가 발생할 수 있습니다.

```text
Tool Error

├─ Validation Error
├─ Permission Error
├─ Network Error
├─ Rate Limit
├─ Timeout
└─ Business Error
```

각 Error의 성격에 따라 대응도 달라져야 합니다.

```text
Validation Error
→ Parameter 수정


Network Error
→ Retry


Permission Error
→ Stop


Business Error
→ 사용자에게 전달
```

LLM에게 모든 Error 처리를 맡기는 것이 아니라 Backend에서 명확한 Error Contract를 제공하는 것이 중요합니다.

---

### Tool Schema 설계

Agent가 Tool을 정확하게 사용하려면 Tool Interface 자체를 잘 설계해야 합니다.

예를 들어 다음보다,

```text
execute(command: string)
```

더 제한된 Tool이 안전할 수 있습니다.

```text
getOrder(orderId)

cancelOrder(orderId)

refundOrder(orderId, reason)
```

Tool의 목적과 Input을 명확하게 만드는 것입니다.

```text
Good Tool

명확한 이름

작은 책임

정확한 Parameter

예측 가능한 Result
```

Agent 시대에는 API Design뿐 아니라 **Tool Design도 Backend Interface 설계의 중요한 영역**이 됩니다.

---

### MCP와 연결되는 흐름

2024년 말 Anthropic이 MCP(Model Context Protocol)를 공개하면서 Agent와 외부 Tool을 연결하는 표준화 흐름도 시작됐습니다.

Responses API 같은 Agent Platform과 MCP는 서로 다른 기술이지만 큰 흐름에서는 연결됩니다.

```text
Agent
 ↓
Tools
 ↓
External Systems
```

Agent가 사용할 수 있는 Tool이 많아질수록 다음 문제가 중요해집니다.

```text
Tool을 어떻게 발견할까?

Schema는 어떻게 표현할까?

Permission은 어떻게 관리할까?

Result는 어떻게 전달할까?
```

Agent Architecture의 핵심이 Model 자체에서 **Tool Ecosystem과 Execution Layer까지 확대**되고 있는 것입니다.

---

### Backend 개발자의 역할 변화

AI Application 초기에는 Backend 개발자가 주로 다음 작업을 담당했습니다.

```text
Prompt 작성

LLM API 호출

Response Parsing
```

Agent Application에서는 고려해야 할 영역이 훨씬 많습니다.

```text
Agent Backend

├─ Tool Interface
├─ Permission
├─ Authentication
├─ State
├─ Timeout
├─ Retry
├─ Idempotency
├─ Cost Limit
├─ Trace
└─ Human Approval
```

Agent System은 단순 LLM Wrapper가 아니라 하나의 **Execution Platform**에 가까워집니다.

---

### Agent Observability

일반 Backend에서는 Request Trace를 확인합니다.

```text
Request
 ↓
Service A
 ↓
Service B
 ↓
Database
```

Agent에서도 비슷한 Trace가 필요합니다.

```text
Agent Run

Model
 ↓
Tool
 ↓
Model
 ↓
Tool
 ↓
Model
```

다음 정보를 확인할 수 있어야 합니다.

```text
어떤 Tool을 호출했는가?

왜 실패했는가?

몇 번 Retry했는가?

얼마나 오래 걸렸는가?

얼마의 Token을 사용했는가?

어디에서 사용자 승인을 받았는가?
```

AI에서도 Observability가 기존 Backend Monitoring과 비슷한 수준으로 중요해지는 것입니다.

---

### 왜 중요한가

Responses API와 Agents SDK의 등장은 단순히 OpenAI API가 하나 더 추가됐다는 의미보다 큽니다.

LLM Application의 기본 구조가 바뀌고 있었기 때문입니다.

```text
1세대

Prompt
 ↓
LLM
 ↓
Response
```

Tool Calling이 들어오면서

```text
2세대

Prompt
 ↓
LLM
 ↓
Tool
 ↓
Response
```

Agent에서는

```text
3세대

Goal
 ↓
Reasoning
 ↓
Tool
 ↓
Observation
 ↓
Reasoning
 ↓
Tool
 ↓
Response
```

구조로 발전합니다.

AI가 단순한 Response Generator에서 **실제 작업을 수행하는 Runtime**으로 변하고 있는 것입니다.

---

### 실무 영향

Agent를 Production에서 운영하려면 단순히 Model 성능만 좋아서는 부족합니다.

```text
Production Agent

Model
+
Tools
+
State
+
Permission
+
Retry
+
Timeout
+
Idempotency
+
Tracing
+
Cost Control
```

예를 들어 Tool이 결제나 Database Update처럼 Side Effect를 발생시킨다면 기존 Backend Engineering에서 사용하던 Idempotency와 Transaction 개념이 그대로 중요합니다.

External API를 호출한다면 Timeout과 Retry가 필요하고,

Agent가 많은 Tool을 반복 호출한다면 Cost와 Step Limit이 필요하며,

Production Resource를 변경한다면 Approval과 Audit Log가 필요합니다.

결국 Responses API와 Agents SDK의 등장은,

> **LLM Application이 Prompt와 Response를 연결하는 구조에서 목표를 받아 여러 Tool을 사용하며 작업을 수행하는 Agent Runtime 구조로 본격적으로 이동하기 시작한 변화**

라고 볼 수 있습니다.

그리고 이 변화로 인해 AI Backend 개발에서도 **Permission, Timeout, Retry, Idempotency, Trace, Cost Control 같은 기존 Backend와 Distributed System의 핵심 개념이 Agent 실행을 제어하기 위한 중요한 설계 요소**로 다시 등장하기 시작했습니다.

2025년 3월 14일(금) 주간 개발트렌드

독자의 메모