2025년 4월 11일(금) 주간 개발트렌드

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

## AI / Developer Tools — Copilot Agent Mode + MCP가 일반 사용자로 확대

GitHub가 **25년 4월 4일 오늘 VS Code의 Copilot Agent Mode를 전체 사용자에게 확대**했습니다.

이와 함께 **MCP(Model Context Protocol) 지원도 본격적으로 통합**됐고, 로컬 환경에서 사용할 수 있는 GitHub MCP Server도 공개됐습니다.

이 변화는 GitHub Copilot이 단순한 코드 자동완성이나 Chat 도구를 넘어, **Repository를 탐색하고 파일을 수정하며 명령을 실행하고 그 결과를 다시 검증하는 Agent형 개발 도구**로 확장되고 있음을 보여줬습니다.

[GitHub - Copilot Agent Mode Activated](https://github.blog/news-insights/product-news/github-copilot-agent-mode-activated/)

---

### 기존 Copilot의 역할

초기의 GitHub Copilot은 기본적으로 Code Completion Tool이었습니다.

```text
Developer
    ↓
Code 작성
    ↓
Copilot
    ↓
다음 Code 추천
```

이후 Copilot Chat이 추가되면서 설명과 Code Generation까지 가능해졌습니다.

```text
Developer
    ↓
Question
    ↓
Copilot Chat
    ↓
Code / Explanation
```

하지만 여전히 작업의 중심은 개발자였습니다.

```text
AI가 Code 제안
      ↓
Developer가 적용
      ↓
직접 Test
      ↓
직접 수정
```

Copilot Agent Mode는 이 구조를 바꾸기 시작했습니다.

---

### Agent Mode

Agent Mode에서는 개발자가 코드 한 줄이나 함수 하나가 아니라 **하나의 개발 Task**를 전달할 수 있습니다.

예를 들어 다음과 같은 요청입니다.

```text
회원가입 API에
email 중복 검사를 추가하고
관련 Test도 수정해줘
```

Agent는 이 작업을 처리하기 위해 Repository를 탐색해야 합니다.

```text
Task
 ↓
Repository 탐색
 ↓
관련 File 검색
 ↓
Code 분석
 ↓
여러 File 수정
 ↓
Test 실행
 ↓
Error 확인
 ↓
추가 수정
```

AI Coding Tool이 단순한 Code Generator에서 **Task Execution System**으로 발전하는 것입니다.

---

### Agent Loop

Agent Mode의 핵심은 한 번의 Code Generation이 아니라 반복적인 **Agent Loop**입니다.

```text
Goal
 ↓
Plan
 ↓
Action
 ↓
Result
 ↓
Reasoning
 ↓
다음 Action
```

개발 Workflow로 표현하면 다음과 같습니다.

```text
Project 읽기
    ↓
Code 수정
    ↓
Command 실행
    ↓
결과 확인
    ↓
Error 발생?
 ┌───────────────┐
 │               │
Yes             No
 │               │
 ↓               ↓
다시 수정        완료
```

AI가 자신의 작업 결과를 다시 보고 다음 행동을 결정하는 구조입니다.

---

### Autocomplete와 Agent의 차이

기존 Copilot의 가장 작은 작업 단위는 한 줄의 Code였습니다.

```text
Autocomplete

Current Code
    ↓
Next Code
```

Agent에서는 작업 단위가 훨씬 커집니다.

```text
Agent

Requirement
    ↓
Repository
    ↓
Implementation
    ↓
Verification
    ↓
Result
```

개발 AI 경쟁의 기준도 자연스럽게 달라집니다.

```text
기존

누가 Code를 더 잘 생성하는가?


이후

누가 개발 Task를
더 정확하게 끝까지 수행하는가?
```

---

### Multi-file Editing

실제 개발 Feature는 하나의 File에서 끝나는 경우가 많지 않습니다.

예를 들어 Backend API 하나를 수정해도 다음 파일이 연결될 수 있습니다.

```text
User Feature

├─ Controller
├─ Service
├─ Repository
├─ DTO
├─ Entity
└─ Test
```

Frontend에서도 마찬가지입니다.

```text
Feature

├─ Page
├─ Component
├─ Hook
├─ API Client
├─ Type
└─ Test
```

Agent는 Repository의 구조를 탐색한 뒤 여러 File 사이의 관계를 이해해야 합니다.

```text
Workspace
    ↓
Code Search
    ↓
Dependency 확인
    ↓
Multi-file Change
```

Repository Context가 AI Coding Tool의 핵심 경쟁력이 되는 이유입니다.

---

### Terminal까지 연결된다

개발 작업은 Source Code만 수정한다고 끝나지 않습니다.

실제 개발자는 다음과 같은 명령을 계속 사용합니다.

```bash
npm test

npm run lint

npm run build

mvn test

./gradlew test

git diff
```

Agent가 Terminal을 사용할 수 있으면 Code를 변경한 뒤 직접 결과를 확인할 수 있습니다.

```text
Agent
 ↓
Code 수정
 ↓
npm test
 ↓
Test Fail
 ↓
Error 분석
 ↓
Code 수정
 ↓
npm test
 ↓
Pass
```

Code Generation과 Verification이 하나의 Loop로 연결되는 것입니다.

---

### 테스트가 Agent의 눈이 된다

Agent가 자신의 변경이 올바른지 확인하려면 자동화된 Feedback이 필요합니다.

가장 대표적인 것이 Test입니다.

```text
Code Change
    ↓
Test
    ↓
Pass / Fail
```

Test가 없다면 다음과 같은 상태가 됩니다.

```text
Agent
 ↓
Code 수정
 ↓
정상인지 확인할 방법 부족
```

반면 Test가 충분하다면 Agent가 스스로 Error를 확인할 수 있습니다.

```text
Agent
 ↓
Code 수정
 ↓
Test
 ↓
Fail
 ↓
수정
 ↓
Test
 ↓
Pass
```

Test는 사람을 위한 Regression 방지 수단이면서 동시에 **Agent가 작업 결과를 검증할 수 있는 Machine-readable Interface**가 됩니다.

---

### Lint와 Type Check도 중요하다

Test 외에도 Agent에게 Feedback을 줄 수 있는 도구가 있습니다.

```text
Verification

├─ Unit Test
├─ Integration Test
├─ Type Check
├─ Lint
└─ Build
```

TypeScript Project라면 다음 명령이 있습니다.

```bash
tsc --noEmit
```

Java Project라면 Compiler 자체가 Feedback을 제공합니다.

```bash
./gradlew build
```

Lint 역시 Code Convention이나 기본적인 Error를 탐지할 수 있습니다.

```bash
npm run lint
```

이러한 자동 검증 수단이 많을수록 Agent가 더 안정적으로 작업할 수 있습니다.

---

### Repository 구조가 AI 성능에 영향을 준다

Agent가 Project 전체를 탐색하기 시작하면서 좋은 Architecture의 가치도 달라집니다.

예를 들어 다음과 같이 구조가 명확한 Repository가 있다고 가정할 수 있습니다.

```text
src/

├─ user/
│  ├─ controller
│  ├─ service
│  ├─ repository
│  └─ test
│
├─ auth/
└─ order/
```

Agent가 User 관련 작업을 수행해야 한다면 관련 File과 책임을 빠르게 이해할 수 있습니다.

반대로 다음과 같은 구조라면 어렵습니다.

```text
src/

├─ utils
├─ common
├─ helpers
├─ misc
└─ services
```

모든 Domain Code가 서로 섞여 있다면 사람뿐 아니라 Agent도 구조를 이해하기 어렵습니다.

```text
Clear Architecture
       ↓
Human 이해도 증가
       +
AI 이해도 증가
```

좋은 Software Architecture가 AI 시대에도 그대로 중요합니다.

---

### Repository Instruction

Agent에게 Project별 규칙을 명확하게 알려주는 것도 중요해집니다.

예를 들어 다음과 같은 규칙입니다.

```text
Business Logic은 Service Layer에서만 작성한다.

Controller에서 Repository를 직접 호출하지 않는다.

새 Feature에는 반드시 Test를 추가한다.

Package Manager는 pnpm을 사용한다.

Build와 Lint가 통과해야 작업 완료로 판단한다.
```

사람에게는 Team Convention이지만 AI Agent에게는 **작업 수행을 위한 Instruction**입니다.

```text
Repository
   +
Instructions
   ↓
Agent Context
```

AI가 Repository를 더 깊게 수정할수록 명확한 Documentation과 규칙의 가치도 커집니다.

---

### MCP 지원

Copilot Agent Mode 확대와 함께 중요한 변화가 **MCP(Model Context Protocol) 지원**입니다.

MCP는 AI Agent가 외부 Tool과 Data Source를 공통 Interface로 사용할 수 있도록 하기 위한 Protocol입니다.

기존에는 각각의 Integration을 직접 구현해야 했습니다.

```text
Agent ↔ GitHub Custom Integration

Agent ↔ Database Custom Integration

Agent ↔ Files Custom Integration

Agent ↔ Cloud Custom Integration
```

MCP를 이용하면 다음과 같은 구조로 추상화할 수 있습니다.

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

Agent가 사용할 수 있는 Tool 생태계를 확장하기 쉬워지는 것입니다.

---

### GitHub MCP Server

GitHub가 로컬 GitHub MCP Server를 공개한 것도 중요한 변화였습니다.

Copilot 같은 Agent가 GitHub의 Repository 정보와 더 직접적으로 연결될 수 있는 기반이 만들어진 것입니다.

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

```text
Copilot Agent
      ↓
     MCP
      ↓
GitHub MCP Server
      ↓
GitHub
```

Agent는 GitHub Context를 활용해 다양한 개발 작업을 수행할 수 있습니다.

예를 들어 다음과 같은 정보입니다.

```text
Repository

Issues

Pull Requests

Code

Commits
```

AI Coding Tool이 Local Workspace만 보는 것이 아니라 **GitHub의 Software Development Context까지 연결되는 구조**입니다.

---

### Agent + MCP

Agent와 MCP를 결합하면 AI Developer Tool의 Architecture가 크게 확장됩니다.

```text
Coding Agent

├─ Local Workspace
├─ Terminal
├─ Git
└─ MCP
     │
     ├─ GitHub
     ├─ Database
     ├─ Cloud
     └─ Documentation
```

AI가 단순히 Source Code를 읽는 것을 넘어 개발자가 실제로 사용하는 외부 시스템에 접근할 수 있게 됩니다.

---

### MCP가 중요한 이유

Agent에게 Tool을 하나씩 Custom Integration으로 붙이면 Tool이 늘어날수록 Complexity가 커집니다.

```text
Agent
 ├─ GitHub Adapter
 ├─ DB Adapter
 ├─ Cloud Adapter
 ├─ Slack Adapter
 └─ File Adapter
```

MCP는 이를 공통 Interface로 만드는 방향입니다.

```text
Agent
 ↓
MCP Client
 ↓
MCP Servers
```

Model이나 Agent Product를 바꾸더라도 동일한 MCP Server를 재사용할 수 있는 구조를 목표로 할 수 있습니다.

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

AI Tool Integration이 점점 표준 Protocol 기반 생태계로 발전하기 시작한 것입니다.

---

### AI Coding Tool의 Architecture

2025년의 Coding Agent를 단순화하면 다음과 같은 구조가 됩니다.

```text
Developer
    ↓
Coding Agent
    │
    ├─ Model
    ├─ Repository Context
    ├─ File Tools
    ├─ Terminal
    ├─ Test
    └─ MCP
         ↓
    External Tools
```

좋은 Coding Agent를 만들기 위해 Model Intelligence만 중요한 것이 아닙니다.

```text
Agent Quality

Model
+
Context
+
Tools
+
Verification
+
Integration
```

전체 System Design이 중요해집니다.

---

### 개발 환경 자체가 AI Interface가 된다

기존에는 다음 요소들이 주로 사람의 개발 생산성을 위한 것이었습니다.

```text
Test

Lint

Build Script

Directory Structure

Documentation
```

Agent가 등장하면서 이들이 AI에게도 중요한 Interface가 됩니다.

```text
Agent

Code 수정
 ↓
Build Script
 ↓
Test
 ↓
Lint
 ↓
Result 확인
```

즉 좋은 개발 환경은 이제 **사람이 이해하기 좋은 환경이면서 AI가 작업하고 검증하기 좋은 환경**이 됩니다.

---

### CI/CD와도 연결될 수 있다

Agent가 Local Test뿐 아니라 CI 결과를 확인할 수 있다면 Workflow는 더 확장됩니다.

```text
Agent
 ↓
Code 수정
 ↓
Pull Request
 ↓
CI

├─ Build
├─ Test
├─ Lint
└─ Security Scan
```

CI에서 Error가 발생하면 다시 Agent가 분석할 수 있습니다.

```text
CI Failure
    ↓
Agent
    ↓
Error 분석
    ↓
Code 수정
```

Coding Agent가 Local Development에서 Pull Request와 CI까지 연결되는 방향으로 확장될 수 있습니다.

---

### Permission도 중요해진다

Agent가 사용할 수 있는 Tool이 많아질수록 Permission 관리도 중요해집니다.

```text
Tool

read_file
→ Read


edit_file
→ Write


run_command
→ Execute


GitHub Merge
→ Repository 변경


Deploy
→ Production 변경
```

모든 Action을 자동으로 허용해서는 안 됩니다.

```text
Agent
 ↓
Permission Layer
 ↓
Tool
```

위험 수준에 따라 다른 정책을 적용할 수 있습니다.

```text
Read
→ 자동 허용


Local Edit
→ Review


Terminal Command
→ 확인 가능


Production Action
→ 사용자 승인
```

Agent Capability가 커질수록 **Agent Control Architecture**도 중요해집니다.

---

### 코드 작성보다 검증이 중요해진다

AI가 Code를 작성하는 속도는 이미 상당히 빨라졌습니다.

Agent 시대에는 더 큰 문제가 생깁니다.

```text
많은 Code 생성 가능
       ↓
그 Code를 누가 검증할 것인가?
```

Test와 Lint는 자동화할 수 있지만 모든 문제를 탐지할 수는 없습니다.

```text
Test Pass
   ≠
Correct Architecture
```

다음 문제는 여전히 개발자가 확인해야 합니다.

- Domain 설계가 적절한가
- Transaction 범위가 올바른가
- Race Condition은 없는가
- Security 문제가 없는가
- Performance 문제가 없는가
- 요구사항을 정확하게 구현했는가
- 불필요한 Complexity가 생기지 않았는가

AI Agent가 강력해질수록 **Code Review와 Architecture 판단 능력의 가치가 오히려 커질 수 있습니다.**

---

### 개발자의 역할 변화

기존 개발 Workflow는 다음과 같았습니다.

```text
Developer

Requirement
 ↓
Code 작성
 ↓
Test
 ↓
Fix
```

Agent 기반 Workflow에서는 일부 Implementation을 위임할 수 있습니다.

```text
Developer

Requirement
 ↓
Agent에게 Task 전달
 ↓
Agent 실행
 ↓
Result Review
 ↓
Architecture / Logic 검증
```

개발자는 점점 다음 영역에 더 집중할 수 있습니다.

```text
Problem Definition

Architecture

Domain Modeling

Review

Verification

Decision Making
```

Code를 직접 입력하는 능력보다 **AI가 생성한 결과의 품질을 판단할 수 있는 능력**이 중요해지는 것입니다.

---

### 2025년 Coding AI의 흐름

2025년 초 몇 달 동안 AI Developer Tool의 변화는 매우 빠르게 진행됐습니다.

```text
2월

Copilot Agent Mode 공개


2월

Claude Code 공개


4월

Copilot Agent Mode 전체 확대
+
MCP 지원
```

Coding Agent가 실험적인 기능에서 일반 개발자가 실제로 사용할 수 있는 Product로 빠르게 내려오기 시작했습니다.

---

### 왜 중요한가

Copilot Agent Mode의 전체 확대와 MCP 지원에서 중요한 것은 기능 하나하나가 아닙니다.

AI Coding Tool의 기본 Architecture가 달라지고 있다는 점입니다.

```text
1세대

Autocomplete


2세대

Chat


3세대

Agent
 ↓
Repository
 ↓
Tools
 ↓
Verification


4세대 방향

Agent
 ↓
MCP
 ↓
External Ecosystem
```

AI가 Editor 안에서 Code를 추천하는 것을 넘어 **실제 Software Development Environment의 여러 Tool을 사용하는 실행 주체**로 변하고 있습니다.

---

### 실무 영향

Agent 시대에는 AI Model 자체를 잘 선택하는 것만으로 충분하지 않습니다.

AI가 작업하고 스스로 검증할 수 있는 개발 환경을 만드는 것도 중요합니다.

```text
AI-friendly Development Environment

├─ Clear Repository Structure
├─ Unit Test
├─ Integration Test
├─ Type Check
├─ Lint
├─ Build Script
├─ Documentation
└─ Repository Instruction
```

여기에 MCP를 통해 외부 Tool을 연결할 수 있습니다.

```text
Coding Agent
     ↓
    MCP
     ↓
  GitHub
  Database
   Cloud
  Documentation
```

결국 Copilot Agent Mode와 MCP의 일반 사용자 확대는,

> **AI Coding Tool이 코드 자동완성에서 Repository와 Tool을 직접 사용하며 개발 Task를 수행하는 Agent Platform으로 전환되고 있음을 보여주는 변화**

라고 볼 수 있습니다.

그리고 이 변화는 Software Engineering의 기본 원칙을 약하게 만드는 것이 아니라 오히려 **Test, Build Automation, Clear Architecture, Documentation 같은 검증 가능한 개발 환경의 중요성을 더욱 높이고 있습니다.**

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

독자의 메모