2024년 7월 19일(금) 주간 개발트렌드

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

## AI / Cloud — Bedrock Agent에 Memory + Code Interpretation 추가

AWS가 **7월 10일 Agents for Amazon Bedrock**에 **Memory Retention과 Code Interpretation** 기능을 Preview로 추가했습니다.

이를 통해 Bedrock Agent가 단순히 사용자의 요청에 한 번 응답하는 것을 넘어, **이전 대화의 맥락을 기억하고 필요할 경우 직접 코드를 실행하는 형태**로 확장됐습니다.

---

### 기존 LLM 애플리케이션

초기의 LLM 애플리케이션은 비교적 단순한 구조였습니다.

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

사용자가 Prompt를 전달하면 LLM이 이를 처리해 응답을 반환하는 구조입니다.

이 방식에서는 각각의 요청이 독립적으로 처리되는 경우가 많았고, 장기적인 대화 상태나 외부 도구 실행은 애플리케이션에서 별도로 구현해야 했습니다.

---

### Bedrock Agent의 변화

Memory와 Code Interpretation이 추가되면서 Agent는 이전보다 훨씬 많은 역할을 수행할 수 있게 됐습니다.

```text
Agent
├─ Memory
├─ Tool
├─ Code Execution
└─ External Data
```

단순히 LLM을 호출하는 것이 아니라 **상태를 기억하고, 필요한 도구를 선택하고, 코드를 실행하며, 외부 데이터와 연결되는 구조**가 나타나기 시작한 것입니다.

---

### Memory Retention

Memory 기능을 사용하면 Agent가 이전 대화의 정보를 유지하고 이후 상호작용에서 다시 활용할 수 있습니다.

```text
사용자
  ↓
Conversation
  ↓
Memory
  ↓
Agent
  ↓
다음 Conversation에서 Context 활용
```

기존에는 개발자가 대화 기록을 DB 등에 저장하고 필요한 Context를 다시 Prompt에 포함시키는 구조를 직접 구현해야 하는 경우가 많았습니다.

Memory 기능이 Agent 플랫폼 내부로 들어오기 시작하면서 **대화 상태 관리 자체가 Agent Runtime의 기능**으로 발전하기 시작했습니다.

---

### Code Interpretation

Code Interpretation 기능을 사용하면 Agent가 문제 해결 과정에서 직접 코드를 생성하고 실행할 수 있습니다.

예를 들어 다음과 같은 작업에 활용할 수 있습니다.

- 데이터 분석
- 수학 계산
- CSV 파일 처리
- 데이터 변환
- 간단한 프로그래밍 작업
- 계산 결과 기반 응답 생성

구조적으로 보면 다음과 같습니다.

```text
User Request
     ↓
   Agent
     ↓
코드 실행 필요 판단
     ↓
Code Interpretation
     ↓
실행 결과
     ↓
Final Response
```

LLM이 코드를 단순히 **생성하는 것**에서 벗어나, 실제로 코드를 **실행하고 결과를 다시 추론에 활용하는 형태**로 확장된 것입니다.

---

### 왜 중요한가

이 변화는 AI 애플리케이션이 단순한 Prompt / Response 구조에서 벗어나기 시작했다는 신호였습니다.

```text
기존

Prompt
  ↓
LLM
  ↓
Answer


Agent

Input
  ↓
Agent
  ├─ Memory
  ├─ Tools
  ├─ Code Execution
  └─ External Data
  ↓
Result
```

LLM 자체의 답변 능력뿐 아니라 **LLM이 어떤 Context를 기억하고 어떤 Tool을 사용하며 어떤 작업을 수행할 수 있는지**가 중요해지기 시작했습니다.

이후 AI Agent Architecture에서 일반적으로 등장하는

- Memory
- Tool Calling
- Code Execution
- External Data
- Workflow

같은 구성 요소들이 본격적으로 플랫폼 기능으로 나타나기 시작한 시점이라고 볼 수 있습니다.

---

### Backend 관점에서의 변화

Agent가 직접 Tool과 Code를 실행하기 시작하면 Backend에서 고려해야 할 요소도 달라집니다.

기존 LLM API에서는 주로 다음과 같은 흐름을 관리했습니다.

```text
Request
  ↓
LLM API
  ↓
Response
```

하지만 Agent 기반 서비스에서는 다음과 같은 구조가 필요해집니다.

```text
Client
  ↓
Backend
  ↓
Agent
  ├─ Session
  ├─ Memory
  ├─ Tool Permission
  ├─ Code Sandbox
  └─ External API
```

따라서 다음과 같은 Backend 설계 요소의 중요성이 커지기 시작했습니다.

- Session State 관리
- Conversation Memory 관리
- Tool Permission 관리
- Code 실행 환경 격리
- Sandbox 설계
- External API 접근 제어
- 실행 로그 및 추적
- Timeout / Resource 제한

---

### Sandbox가 중요한 이유

Agent가 직접 코드를 실행할 수 있다는 것은 강력한 기능이지만 동시에 보안 문제도 발생할 수 있습니다.

예를 들어 Agent가 생성한 코드를 서버에서 그대로 실행하면 위험할 수 있습니다.

```text
Agent Generated Code
        ↓
     Sandbox
        ↓
제한된 실행 환경
        ↓
      Result
```

따라서 실제 서비스에서는 코드 실행 환경을 Application Server와 분리하고 CPU, Memory, Network, File System 등의 접근을 제한하는 구조가 중요합니다.

AI Agent가 발전할수록 **LLM 자체의 보안뿐 아니라 LLM이 실행할 수 있는 Action의 범위를 제어하는 것**이 Backend의 중요한 역할이 됩니다.

---

### 실무 영향

Agents for Amazon Bedrock의 변화는 AI 애플리케이션 개발 방식이 바뀌고 있다는 것을 보여줬습니다.

기존에는 개발자가 직접 구현해야 했던

- Conversation Memory
- Tool Execution
- Code Execution
- External Data 연결

같은 기능들이 점점 AI Platform과 Agent Runtime의 기본 기능으로 들어가기 시작했습니다.

결국 AI 애플리케이션의 Backend도 단순히 LLM API를 호출하는 구조에서,

> **상태를 관리하고, Tool을 제어하며, Agent가 수행하는 작업을 안전하게 실행시키는 구조**

로 확장되기 시작했습니다.

Memory와 Code Interpretation이 추가된 Bedrock Agent는 이후 보편화되는 **Agent 기반 AI Architecture의 초기 흐름**을 보여주는 사례 중 하나였습니다.

2024년 7월 12일(금) 주간 개발트렌드

독자의 메모