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

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

## AI / Developer Tools — GitHub Copilot Agent Mode 등장

GitHub가 **어제 날짜인 25년 2월 6일 VS Code용 GitHub Copilot Agent Mode**를 공개했습니다.

기존 Copilot이 개발자가 작성하는 코드를 예측하거나 질문에 답하는 **Coding Assistant**에 가까웠다면, Agent Mode에서는 하나의 개발 작업을 전달받아 **Workspace를 탐색하고 여러 파일을 수정하며 오류를 확인하고 다시 수정하는 반복적인 Workflow**를 수행할 수 있는 방향으로 발전했습니다.

필요한 경우 Terminal Command까지 제안하면서 AI Coding Tool의 역할이 단순한 Code Generation에서 **실제 개발 Task 수행**으로 확장되기 시작했습니다.

[GitHub - GitHub Copilot: The agent awakens](https://github.blog/news-insights/product-news/github-copilot-the-agent-awakens/)

---

### 기존 GitHub Copilot

초기의 GitHub Copilot은 대표적인 **AI Code Completion Tool**이었습니다.

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

개발자가 함수나 Comment를 작성하면 다음에 들어갈 코드를 예측해주는 방식입니다.

```javascript
function calculateTotal(items) {
  // Copilot이 다음 코드 추천
}
```

이후 Copilot Chat이 등장하면서 역할이 조금 더 확장됐습니다.

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

다음과 같은 작업을 요청할 수 있었습니다.

- 코드 설명
- 함수 생성
- Refactoring
- Test Code 작성
- Error 분석
- API 사용법 질문

하지만 기본적으로는 **개발자가 요청하고 AI가 결과를 반환하는 구조**였습니다.

---

### Assistant와 Agent의 차이

Coding Assistant의 기본 구조는 다음과 같습니다.

```text
Developer
    ↓
Task
    ↓
AI
    ↓
Suggestion
    ↓
Developer 적용
```

AI는 해결 방법을 알려주지만 실제 Project를 수정하고 검증하는 과정은 개발자가 담당합니다.

Agent Mode에서는 구조가 달라집니다.

```text
Developer
    ↓
Task
    ↓
Agent
    ↓
Workspace 탐색
    ↓
Code 수정
    ↓
Error 확인
    ↓
다시 수정
    ↓
Result
```

AI가 결과 하나를 생성하는 것이 아니라 **작업을 완료하기 위해 여러 단계를 수행하는 Loop**를 가지게 된 것입니다.

---

### 하나의 작업을 끝까지 수행한다

예를 들어 다음과 같은 요청을 한다고 가정할 수 있습니다.

```text
User API에 email validation을 추가하고
관련 테스트도 수정해줘
```

기존 Coding Assistant에서는 개발자가 필요한 파일을 직접 찾아 Context로 제공하는 경우가 많았습니다.

```text
Developer

파일 검색
 ↓
관련 Code 전달
 ↓
AI에게 질문
 ↓
Code 복사
 ↓
파일 수정
 ↓
Test 실행
```

Agent Mode에서는 이 Workflow의 일부를 AI가 수행할 수 있습니다.

```text
Task
 ↓
Repository 탐색
 ↓
User 관련 File 검색
 ↓
Validation Logic 확인
 ↓
Code 수정
 ↓
Test File 확인
 ↓
Test 수정
 ↓
Error 확인
 ↓
추가 수정
```

AI Coding Tool의 단위가 **한 줄의 코드**에서 **하나의 개발 Task**로 커지기 시작한 것입니다.

---

### Multi-file Editing

실제 개발 작업은 하나의 파일에서 끝나는 경우가 많지 않습니다.

예를 들어 Backend Feature 하나를 추가해도 여러 파일이 연결될 수 있습니다.

```text
User Feature

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

기존 AI Code Completion은 현재 열려 있는 File Context에 강하게 의존했습니다.

```text
Current File
    ↓
Completion
```

Agent는 Workspace를 탐색하면서 관련 File을 찾을 수 있어야 합니다.

```text
Workspace
    ↓
Search
    ↓
Related Files
    ↓
Multi-file Change
```

이 능력이 중요해지면서 Repository 전체의 구조를 얼마나 잘 이해하는지가 Coding AI의 중요한 성능 요소가 됐습니다.

---

### Error를 보고 다시 수정한다

Agent형 개발 도구에서 중요한 특징 중 하나는 **실행 결과를 다시 입력으로 사용하는 Feedback Loop**입니다.

기존 방식은 다음과 같습니다.

```text
AI
 ↓
Code 생성
 ↓
끝
```

Agent에서는 다음과 같은 Loop가 가능합니다.

```text
Code 수정
   ↓
Validation
   ↓
Error
   ↓
Error 분석
   ↓
Code 수정
   ↓
다시 Validation
```

이를 반복하면서 Task를 해결합니다.

```text
Act
 ↓
Observe
 ↓
Reason
 ↓
Act
```

단순한 Code Generation과 가장 큰 차이가 바로 이 부분입니다.

---

### Terminal과 Agent

실제 개발에서는 Code만 수정해서 작업이 끝나지 않습니다.

다음과 같은 명령을 실행해야 합니다.

```bash
npm test

npm run lint

npm run build

mvn test

./gradlew test
```

Agent Mode는 필요에 따라 Terminal Command를 제안하면서 개발 Workflow와 연결되는 방향으로 발전했습니다.

```text
Agent

Code 수정
  ↓
Command 제안
  ↓
Build / Test
  ↓
Result 확인
  ↓
추가 수정
```

AI가 Editor 안의 코드뿐 아니라 **개발 환경 전체를 이해하기 시작한 것**입니다.

---

### 개발 AI의 경쟁 기준이 바뀐다

초기 Coding AI 경쟁에서 가장 중요한 질문은 다음과 같았습니다.

```text
누가 다음 코드를
가장 잘 예측하는가?
```

즉 Autocomplete 품질이 핵심이었습니다.

```text
Coding AI

Autocomplete Quality
        ↓
Developer Productivity
```

Agent Mode가 등장하면서 질문이 달라집니다.

```text
이 개발 Task를
어디까지 스스로 완료할 수 있는가?
```

평가 단위 역시 달라집니다.

```text
기존

한 줄의 Code


이후

하나의 Function


점점

하나의 Task


Agent

Issue → Working Code
```

---

### Repository Context가 중요해진다

Agent가 제대로 작업하려면 Repository를 이해해야 합니다.

```text
Repository

├─ Architecture
├─ Directory Structure
├─ Coding Convention
├─ Dependency
├─ Tests
├─ Build
└─ Configuration
```

예를 들어 다음 구조가 있다고 가정할 수 있습니다.

```text
src/

├─ user/
│  ├─ user.controller.ts
│  ├─ user.service.ts
│  ├─ user.repository.ts
│  └─ user.spec.ts
│
└─ auth/
```

구조가 명확하면 Agent도 관련 File을 찾고 변경 범위를 추론하기 쉬워집니다.

반대로 Project 구조가 무질서하면 AI 역시 작업을 수행하기 어려워집니다.

---

### 좋은 코드 구조가 AI에게도 중요하다

기존에는 Architecture와 Coding Convention이 주로 **사람이 코드를 이해하기 위한 것**이라고 생각할 수 있었습니다.

```text
Clean Architecture
      ↓
Human Developer
      ↓
유지보수 용이
```

Agent 시대에는 AI 역시 같은 구조의 영향을 받습니다.

```text
Clear Architecture
       ↓
Human + AI Agent
       ↓
Code 탐색 / 수정 용이
```

예를 들어 다음 요소가 중요해집니다.

- 명확한 Directory Structure
- 일관된 Naming
- 작은 Module
- 명확한 Interface
- 예측 가능한 Dependency
- 명확한 Domain Boundary

좋은 Software Architecture가 **AI가 Repository를 이해하기 쉽게 만드는 구조**이기도 한 것입니다.

---

### Test가 더욱 중요해진다

Agent가 Code를 수정했을 때 가장 중요한 질문은 다음과 같습니다.

```text
수정된 Code가
정말 정상인가?
```

AI가 자신의 Code를 검증하려면 자동화된 Test가 필요합니다.

```text
Agent
 ↓
Code 수정
 ↓
Test 실행
 ↓
Pass / Fail
```

Test가 없다면 Agent가 변경이 올바른지 판단하기 어렵습니다.

```text
No Test

Code 수정
 ↓
???
 ↓
완료라고 판단
```

반면 Test가 충분하면 명확한 Feedback을 받을 수 있습니다.

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

Test가 단순한 Regression Protection을 넘어 **AI Agent가 사용할 수 있는 Verification Interface**가 되는 것입니다.

---

### Lint도 Agent의 Feedback이다

Lint 역시 비슷합니다.

```text
Agent
 ↓
Code 수정
 ↓
ESLint
 ↓
Error
 ↓
Agent 수정
```

예를 들어 다음과 같은 문제를 자동으로 탐지할 수 있습니다.

```text
Unused Variable

Type Error

Formatting

Import Error

Coding Convention
```

AI가 만든 Code를 사람의 눈으로 일일이 확인하기 전에 Machine-readable Feedback을 제공할 수 있습니다.

---

### Type System도 중요해진다

TypeScript나 Java처럼 정적 Type 정보를 사용할 수 있는 Language에서는 Compiler 자체가 Agent에게 강력한 Feedback을 제공합니다.

```text
Agent
 ↓
Code Change
 ↓
Type Checker
 ↓
Compile Error
 ↓
Agent
```

예를 들어 TypeScript에서는

```bash
tsc --noEmit
```

Java에서는

```bash
./gradlew compileJava
```

같은 작업으로 변경 사항을 검증할 수 있습니다.

결국 Type System도 **AI가 수정 결과를 검증할 수 있는 자동화된 Feedback Channel**이 됩니다.

---

### Build Script도 중요하다

Agent가 Repository를 처음 봤을 때 다음 질문에 쉽게 답할 수 있어야 합니다.

```text
어떻게 Build하지?

어떻게 Test하지?

어떻게 Lint하지?

어떻게 실행하지?
```

따라서 표준화된 Script가 중요해집니다.

```json
{
  "scripts": {
    "dev": "next dev",
    "test": "vitest",
    "lint": "eslint .",
    "build": "next build"
  }
}
```

Agent는 이를 활용해 다음 Workflow를 수행할 수 있습니다.

```text
Code Change
   ↓
npm test
   ↓
npm run lint
   ↓
npm run build
```

자동화된 Script가 많을수록 Agent가 스스로 검증할 수 있는 범위도 넓어집니다.

---

### Repository Instruction

AI Agent에게 Project 규칙을 명시적으로 알려주는 것도 중요해집니다.

예를 들어 다음과 같은 규칙이 있을 수 있습니다.

```text
Controller에서는 Business Logic을 작성하지 않는다.

Database Access는 Repository Layer에서만 한다.

Test는 Vitest를 사용한다.

새로운 API는 Zod Validation을 사용한다.

Package Manager는 pnpm을 사용한다.
```

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

```text
Repository
   +
Instruction
   ↓
Agent Context
```

Project-specific Instruction이 Coding Agent의 품질에 직접적인 영향을 주기 시작한 것입니다.

---

### AI가 검증 가능한 Repository

Agent 시대에는 좋은 개발 환경의 조건을 다음처럼 볼 수 있습니다.

```text
AI-friendly Repository

├─ Clear Structure
├─ Tests
├─ Type Check
├─ Lint
├─ Build Script
├─ Documentation
└─ Repository Instructions
```

AI가 Code를 생성하는 것보다 **생성한 결과가 올바른지 스스로 확인할 수 있는 환경을 만드는 것**이 중요해집니다.

---

### CI/CD와도 연결된다

Agent가 Local Environment에서 Code를 검증할 수 있더라도 최종 검증은 CI/CD에서 수행할 수 있습니다.

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

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

CI 결과 역시 다시 AI에게 제공할 수 있습니다.

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

장기적으로는 Agent가 Development Loop뿐 아니라 **Pull Request와 CI Workflow까지 연결되는 구조**가 가능해집니다.

---

### Agent Loop

Coding Agent의 기본 구조를 단순화하면 다음과 같습니다.

```text
Task
 ↓
Plan
 ↓
Search
 ↓
Edit
 ↓
Execute
 ↓
Observe
 ↓
Fix
 ↓
Verify
 ↓
Result
```

이전의 LLM 호출과 비교하면 훨씬 복잡한 System입니다.

```text
기존

Prompt
 ↓
LLM
 ↓
Answer


Agent

Goal
 ↓
Reasoning
 ↓
Tool
 ↓
Result
 ↓
Reasoning
 ↓
Tool
 ↓
...
 ↓
Complete
```

AI Application 자체가 하나의 Workflow Engine처럼 발전하기 시작한 것입니다.

---

### Tool Calling이 핵심이 된다

Agent가 실제 개발 작업을 수행하려면 다양한 Tool이 필요합니다.

```text
Coding Agent

├─ read_file
├─ search_code
├─ edit_file
├─ run_test
├─ run_build
├─ git_diff
└─ terminal
```

모델의 Intelligence만 높다고 Agent가 좋은 것은 아닙니다.

```text
Agent Quality

Model
+
Context
+
Tools
+
Feedback
+
Execution
```

이 요소들이 함께 작동해야 합니다.

---

### MCP와도 연결되는 흐름

2024년 말 등장한 MCP(Model Context Protocol)는 이러한 Agent Tooling과 자연스럽게 연결됩니다.

```text
Coding Agent
      ↓
     MCP
      ↓
Tools

├─ GitHub
├─ Database
├─ Files
└─ Cloud
```

Agent가 사용할 Tool이 많아질수록 공통 Tool Interface의 중요성도 커집니다.

Coding Agent와 MCP가 거의 같은 시기에 빠르게 확산되기 시작한 이유도 이러한 구조와 연결됩니다.

---

### Permission이 중요해진다

Agent가 File을 읽는 것과 수정하는 것은 위험 수준이 다릅니다.

```text
read_file

→ Read


edit_file

→ Write


run_command

→ Execute


deploy

→ Production Change
```

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

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

Action에 따라 자동 실행 여부를 다르게 설정할 수 있습니다.

```text
Read
→ 자동 허용


Code Edit
→ 변경사항 Review


Terminal
→ Command 확인


Production
→ 명시적 승인
```

Agent가 강력해질수록 **무엇을 할 수 있는지 제한하는 설계**도 중요해집니다.

---

### 개발자의 역할도 바뀐다

AI Agent가 개발 Task의 일부를 수행하기 시작하면 개발자의 역할도 조금씩 변합니다.

기존에는

```text
Developer

직접 Code 작성
 ↓
직접 Test
 ↓
직접 수정
```

이었다면,

Agent 기반 Workflow에서는

```text
Developer

Task 정의
 ↓
Agent 실행
 ↓
Result Review
 ↓
Architecture 판단
 ↓
Merge
```

같은 형태가 늘어날 수 있습니다.

중요한 능력이 단순 Code Typing에서 **Task Definition, Architecture, Verification, Review** 쪽으로 이동하는 것입니다.

---

### 그렇다고 Agent를 그대로 믿을 수는 없다

Agent가 Test를 통과했다고 해서 항상 변경이 올바른 것은 아닙니다.

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

예를 들어 다음 문제는 자동 Test만으로 잡기 어려울 수 있습니다.

```text
잘못된 Domain 설계

불필요한 Dependency

Security 문제

성능 문제

유지보수성 저하

잘못된 Requirement 해석
```

따라서 최종 Architecture와 Business Logic 검증은 여전히 개발자가 담당해야 합니다.

```text
Agent
 ↓
Implementation
 ↓
Automated Verification
 ↓
Developer Review
```

Agent는 개발자의 판단을 없애는 것이 아니라 **Implementation과 반복 작업의 범위를 넓혀주는 도구**에 가깝습니다.

---

### 왜 중요한가

Copilot Agent Mode가 중요한 이유는 새로운 AI 기능 하나가 추가됐기 때문만은 아닙니다.

AI Coding Tool의 평가 기준 자체가 변하기 시작했기 때문입니다.

```text
2023

Code Completion


2024

Chat
+
Repository Context


2025

Agent
+
Multi-file Editing
+
Tool Execution
+
Verification
```

AI 개발 도구가 단순한 **Code Generator에서 Development Runtime으로 확장되는 흐름**입니다.

---

### Developer Tool 경쟁의 변화

앞으로 Coding AI 경쟁에서는 다음 요소들이 중요해집니다.

```text
Coding Agent

├─ Model Intelligence
├─ Repository Context
├─ Code Search
├─ Multi-file Editing
├─ Terminal Integration
├─ Test Execution
├─ Error Recovery
├─ Tool Calling
├─ Permission
└─ UX
```

같은 AI Model을 사용하더라도 Repository를 얼마나 잘 탐색하고 Tool을 얼마나 안정적으로 사용할 수 있는지에 따라 실제 성능이 크게 달라질 수 있습니다.

---

### 실무 영향

개발팀 입장에서는 AI 도구를 잘 활용하기 위해 **AI가 작업하기 좋은 Repository를 만드는 것**이 점점 중요해집니다.

```text
좋은 Agent 환경

Clear Architecture
        +
Test
        +
Lint
        +
Type Check
        +
Build Script
        +
Documentation
        +
Repository Instruction
```

이러한 환경에서는 Agent가 Code를 수정한 뒤 스스로 결과를 확인할 수 있습니다.

```text
Agent Change
     ↓
Type Check
     ↓
Lint
     ↓
Test
     ↓
Build
     ↓
Validation
```

반대로 자동화된 검증 수단이 없는 Repository에서는 AI가 아무리 좋은 Code를 만들어도 그 결과를 신뢰하기 어렵습니다.

결국 GitHub Copilot Agent Mode의 등장은,

> **AI Coding 경쟁의 단위가 코드 한 줄을 얼마나 잘 생성하는가에서 하나의 개발 작업을 얼마나 안정적으로 끝까지 수행하는가로 이동하기 시작한 변화**

라고 볼 수 있습니다.

그리고 이 변화는 좋은 Software Engineering Practice의 중요성을 오히려 높였습니다.

Test, Type System, Lint, Build Automation, 명확한 Architecture와 Repository Instruction은 이제 사람의 유지보수성을 위한 요소일 뿐 아니라 **AI Agent가 작업 결과를 스스로 검증할 수 있게 만드는 Interface**가 되고 있습니다.

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

독자의 메모