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

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

## AI / Architecture — MCP(Model Context Protocol) 최초 공개

Anthropic이 **24년 11월 25일 Model Context Protocol(MCP)**을 오픈소스로 공개했습니다.

MCP는 AI Assistant나 Agent가 **외부 데이터와 도구에 연결되는 방식을 표준화하려는 Protocol**입니다.

GitHub, Database, File System, SaaS 같은 외부 시스템마다 AI 전용 Integration을 각각 구현하는 대신, 공통 Interface를 통해 연결할 수 있는 구조를 제시했습니다.

[Anthropic - Model Context Protocol](https://www.anthropic.com/news/model-context-protocol)

---

### 기존 AI Integration의 문제

AI Application이 외부 시스템의 데이터를 사용하거나 특정 작업을 실행하려면 각각의 Integration을 직접 구현해야 했습니다.

```text
AI ↔ GitHub Custom Integration

AI ↔ Database Custom Integration

AI ↔ Slack Custom Integration

AI ↔ Files Custom Integration
```

예를 들어 AI가 GitHub Repository를 읽고 Database를 조회하며 Slack 메시지까지 확인해야 한다면 각각 별도의 연결 코드를 만들어야 했습니다.

```text
AI Application

├─ GitHub API Client
├─ Database Connector
├─ Slack API Client
└─ File System Connector
```

연결 대상이 늘어날수록 Integration Code도 함께 증가합니다.

---

### N × M Integration 문제

AI Model과 Tool이 여러 개 존재하면 문제는 더 커집니다.

예를 들어 AI Application이 3개이고 연결해야 할 Tool이 4개라면 각각의 연결 방식을 구현해야 할 수 있습니다.

```text
AI A ───── GitHub
     ├──── Database
     ├──── Slack
     └──── Files

AI B ───── GitHub
     ├──── Database
     ├──── Slack
     └──── Files

AI C ───── GitHub
     ├──── Database
     ├──── Slack
     └──── Files
```

Model과 Tool이 늘어날수록 Integration 수가 빠르게 증가합니다.

```text
Models × Tools
      ↓
Integration Complexity 증가
```

MCP는 이 문제를 **공통 Protocol Layer**를 두는 방식으로 해결하려는 접근입니다.

---

### MCP가 제안한 구조

MCP의 핵심 아이디어는 AI와 외부 시스템 사이에 표준 Interface를 두는 것입니다.

```text
            AI
             ↓
            MCP
     ┌───────┼───────┐
   GitHub    DB     Files
```

AI Application이 각각의 서비스 구현 방식을 직접 이해하는 대신 MCP Interface를 통해 Tool이나 Data Source와 통신합니다.

조금 더 확장하면 다음과 같습니다.

```text
AI Application
      ↓
MCP Client
      ↓
MCP Protocol
      ↓
MCP Server
      ↓
External System
```

외부 시스템은 MCP Server 형태로 기능을 노출하고 AI Application은 MCP Client를 통해 해당 기능을 사용할 수 있습니다.

---

### MCP Client와 MCP Server

MCP Architecture를 단순화하면 두 가지 핵심 Component로 나눌 수 있습니다.

```text
MCP

├─ Client
└─ Server
```

MCP Client는 AI Application 측에서 동작합니다.

```text
AI Assistant
     ↓
MCP Client
```

MCP Server는 외부 Resource나 Tool을 MCP Interface로 제공합니다.

```text
MCP Server
    ↓
GitHub / DB / Files / SaaS
```

전체 구조는 다음과 같습니다.

```text
AI Assistant
     ↓
MCP Client
     ↓
MCP
     ↓
MCP Server
     ↓
External System
```

---

### Tool Interface의 표준화

AI Agent가 외부 시스템을 사용하려면 어떤 기능을 사용할 수 있는지 알아야 합니다.

예를 들어 GitHub와 연결된 Tool이 다음 기능을 제공한다고 가정할 수 있습니다.

```text
GitHub MCP Server

├─ get_repository
├─ get_issue
├─ create_issue
├─ get_pull_request
└─ search_code
```

Database Server라면 전혀 다른 Tool을 제공할 수 있습니다.

```text
Database MCP Server

├─ query
├─ get_schema
└─ list_tables
```

AI는 MCP를 통해 사용할 수 있는 Tool과 필요한 Parameter를 확인하고 호출할 수 있습니다.

```text
Agent
  ↓
Tool 발견
  ↓
Parameter 구성
  ↓
Tool 실행
  ↓
Result
  ↓
다음 Reasoning
```

---

### API와 MCP의 차이

MCP가 REST API를 대체하는 것은 아닙니다.

기존 API는 Application과 Application 사이의 통신 Interface를 정의합니다.

```text
Application A
      ↓
REST / GraphQL / gRPC
      ↓
Application B
```

MCP는 그보다 **AI Model이나 Agent가 외부 Context와 Tool을 사용할 수 있도록 연결하는 Interface**에 가깝습니다.

```text
AI / Agent
    ↓
MCP
    ↓
Tool / Data Source
```

실제 MCP Server 내부에서는 기존 REST API를 다시 호출할 수도 있습니다.

```text
AI
 ↓
MCP
 ↓
MCP Server
 ↓
REST API
 ↓
External Service
```

즉 MCP는 기존 API 위에 **AI가 이해할 수 있는 Tool Layer를 만드는 방식**으로 볼 수 있습니다.

---

### 왜 중요한가

LLM이 처음 등장했을 때 대부분의 Application은 단순했습니다.

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

하지만 AI Application이 발전하면서 외부 시스템을 사용할 필요가 생겼습니다.

```text
Agent

├─ Memory
├─ Tools
├─ Database
├─ Files
├─ Code Execution
└─ External APIs
```

여기서 새로운 문제가 등장합니다.

```text
Agent와
수많은 외부 System을
어떻게 연결할 것인가?
```

MCP는 이 문제를 개별 Integration 구현이 아니라 **Protocol 문제로 정의했다는 점**에서 중요했습니다.

---

### Backend 관점에서의 변화

기존 Backend에서는 외부 API를 연결할 때 Service별 Client를 구현하는 것이 일반적이었습니다.

```text
Backend

├─ GitHubService
├─ SlackService
├─ DatabaseService
└─ FileService
```

Agent 기반 Architecture에서는 한 단계의 추상화가 추가됩니다.

```text
Agent
  ↓
Tool Interface
  ↓
MCP
  ↓
External System
```

따라서 Backend 개발자가 고민해야 하는 문제도 달라집니다.

기존에는

```text
API Endpoint는 무엇인가?

Request Format은 무엇인가?

Authentication은 어떻게 하는가?
```

가 중심이었다면,

Agent Architecture에서는 다음과 같은 문제도 중요해집니다.

```text
어떤 Tool을 Agent에 노출할 것인가?

Tool Schema는 어떻게 설계할 것인가?

어떤 Resource를 Context로 제공할 것인가?

Agent에게 어떤 Permission을 줄 것인가?
```

---

### Tool 설계가 중요해진다

Agent에게 외부 시스템 전체를 그대로 노출하는 것은 좋은 설계가 아닐 수 있습니다.

예를 들어 Database에 직접 SQL 실행 권한을 주는 것보다 제한된 Tool을 제공할 수 있습니다.

```text
위험한 방식

Agent
  ↓
execute_sql(any query)
  ↓
Production DB
```

대신 Application 목적에 맞는 Tool을 제공할 수 있습니다.

```text
Agent

├─ get_user
├─ get_order
├─ search_products
└─ create_support_ticket
```

Agent가 수행할 수 있는 Action의 범위를 제한할 수 있기 때문입니다.

---

### Permission이 중요해진 이유

Agent가 단순히 데이터를 읽는 것과 실제 시스템을 변경하는 것은 위험 수준이 다릅니다.

```text
Read

get_issue
get_document
search_code


Write

create_issue
update_document
delete_resource
deploy_service
```

따라서 MCP 기반 Agent Architecture에서도 다음 요소가 중요해집니다.

- Authentication
- Authorization
- Tool Permission
- Read / Write Scope
- Audit Log
- User Confirmation
- Rate Limit
- Sandbox

AI가 더 많은 Tool을 사용할수록 **Agent가 무엇을 할 수 있는지 제한하는 구조**가 중요해집니다.

---

### Context 연결의 표준화

MCP에서 중요한 것은 Tool 실행만이 아닙니다.

AI가 문제를 해결하기 위해 필요한 **Context와 Resource를 가져오는 방식**도 표준화하려는 접근입니다.

```text
AI
 ↓
MCP
 ↓
Context

├─ File
├─ Document
├─ Database Data
├─ Repository
└─ Application Data
```

기존에는 AI Application마다 Context Loading Logic을 별도로 구현해야 했습니다.

```text
Custom Loader
     ↓
Prompt 생성
     ↓
LLM
```

MCP 같은 표준이 존재하면 AI Application과 Data Source 사이의 결합도를 줄일 수 있습니다.

---

### Coding Agent와 특히 잘 맞는다

MCP가 빠르게 주목받은 영역 중 하나가 Coding Agent입니다.

Coding Agent는 실제 개발 작업을 수행하기 위해 많은 Tool이 필요합니다.

```text
Coding Agent

├─ File System
├─ Git
├─ GitHub
├─ Terminal
├─ Database
├─ Documentation
└─ Cloud
```

기존 방식이라면 각각의 Tool Integration을 Coding Agent가 직접 구현해야 합니다.

```text
Coding Agent

GitHub Adapter
Git Adapter
DB Adapter
Cloud Adapter
File Adapter
```

MCP를 사용하면 다음과 같은 구조가 가능해집니다.

```text
Coding Agent
      ↓
     MCP
      ↓
 ┌────┼─────┬─────┐
GitHub Git   DB   Cloud
```

Agent 개발자와 Tool Provider 사이에 공통 Interface가 생기는 것입니다.

---

### Tool Provider가 직접 MCP Server를 제공한다

표준 Protocol이 확산되면 중요한 변화가 하나 발생합니다.

기존에는 AI Application 개발자가 Integration을 만들어야 했습니다.

```text
AI Developer
     ↓
GitHub Integration 직접 구현
```

하지만 Provider가 직접 MCP Server를 제공하면 구조가 달라집니다.

```text
GitHub / Database / Cloud Vendor
            ↓
        MCP Server
            ↓
         AI Agent
```

즉 Integration 개발의 책임 일부가 **AI Application 개발자에서 Tool Provider로 이동할 수 있습니다.**

---

### Agent 생태계의 Plug-in 구조

이 구조가 발전하면 Agent는 필요한 MCP Server를 연결해서 기능을 확장할 수 있습니다.

```text
Agent

+ GitHub MCP
+ PostgreSQL MCP
+ Slack MCP
+ Cloud MCP
+ Browser MCP
```

Application에 Plugin을 추가하는 것과 비슷한 방식입니다.

```text
Base Agent
    ↓
MCP Server 추가
    ↓
새로운 Capability
```

Agent 자체를 수정하지 않고도 사용할 수 있는 Tool을 확장하는 방향입니다.

---

### Model과 Tool의 분리

MCP의 또 다른 중요한 의미는 **Model과 Tool을 분리할 수 있다는 점**입니다.

기존에는 특정 AI Application에 Tool Integration이 강하게 결합될 수 있었습니다.

```text
Model A
  ↓
Custom GitHub Integration
```

MCP 방식에서는 다음과 같은 구조를 목표로 할 수 있습니다.

```text
Model A ─┐
Model B ─┼→ MCP → GitHub
Model C ─┘
```

AI Model을 변경하더라도 동일한 MCP Server를 다시 사용할 수 있는 구조입니다.

```text
Model
   ↓
교체 가능

MCP Tool
   ↓
재사용 가능
```

Model Provider와 Tool Provider 사이의 결합도를 낮출 수 있습니다.

---

### Agent Architecture의 변화

MCP가 등장하면서 Agent Architecture를 다음과 같이 구성할 수 있게 됩니다.

```text
             Agent
               │
      ┌────────┼────────┐
      │        │        │
  Reasoning  Memory    MCP
                        │
              ┌─────────┼─────────┐
              │         │         │
           GitHub      DB       Files
```

Agent 내부의 Reasoning과 Memory는 AI System이 담당하고,

외부 시스템 연결은 MCP Interface를 통해 처리하는 방식입니다.

이 구조는 Agent를 구성하는 Component를 보다 명확하게 분리할 수 있게 합니다.

---

### 왜 큰 전환점인가

AI Application의 발전 흐름을 보면 MCP가 등장한 이유가 자연스럽게 보입니다.

```text
1. Chatbot

Prompt
 ↓
LLM
 ↓
Answer


2. Agent

LLM
+
Memory
+
Tool


3. Agent Ecosystem

Agent
 ↓
Standard Protocol
 ↓
External Systems
```

LLM이 단순히 답변을 생성할 때는 MCP가 필요하지 않았습니다.

하지만 AI가 실제 작업을 수행하기 시작하면서 **외부 세계와 연결되는 표준 Interface가 필요해진 것**입니다.

---

### API 중심에서 Tool 중심으로

기존 Software Integration에서는 API 설계가 중심이었습니다.

```text
Application
   ↓
API
   ↓
Application
```

Agent 시대에는 그 위에 새로운 Interface가 필요해집니다.

```text
Agent
  ↓
Tool
  ↓
API
  ↓
Application
```

따라서 개발자의 질문도 바뀝니다.

```text
기존

API를 어떻게 만들까?


Agent Architecture

AI가 사용할 Tool을
어떻게 설계할까?
```

Tool Name, Description, Input Schema, Permission, Result Format 등이 새로운 Interface Design 요소가 됩니다.

---

### 실무 영향

MCP 이후 Agent를 설계할 때 중요한 문제는 단순히 LLM을 어떤 모델로 사용할 것인지가 아닙니다.

```text
Agent System

├─ Model
├─ Memory
├─ MCP
├─ Tools
├─ Permission
├─ Context
└─ Observability
```

특히 Backend와 Platform 개발자는 다음과 같은 영역을 고려해야 합니다.

- MCP Server 설계
- Tool Schema 설계
- Authentication
- Authorization
- Context 제공 범위
- Tool Permission
- Error Handling
- Audit Logging
- Rate Limiting
- Agent 실행 추적

결국 MCP의 공개는,

> **AI와 외부 시스템을 연결하는 문제를 개별 Integration 구현에서 공통 Protocol과 Tool Interface 설계의 문제로 바꾸기 시작한 전환점**

이라고 볼 수 있습니다.

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

독자의 메모