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

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

## AI / DevOps — AI가 코드 생성기를 넘어 '에이전트형 개발 도구'로 이동

Microsoft가 **25년 1월 13일 CoreAI - Platform and Tools 조직**을 발표하면서 2025년 Application Stack의 핵심 방향으로 **Agentic Application**을 강조했습니다.

같은 시기 Docker 역시 Container 관련 작업을 지원하는 AI Agent **Gordon**을 실험적으로 공개하면서 AI가 단순히 코드를 추천하는 도구에서 벗어나 **실제 개발 환경과 Infrastructure를 조작하는 도구**로 확장되는 흐름이 나타나기 시작했습니다.

[Microsoft - Introducing CoreAI – Platform and Tools](https://blogs.microsoft.com/blog/2025/01/13/introducing-core-ai-platform-and-tools/)

---

### 기존 AI Coding Assistant

초기의 AI Coding Assistant는 개발자가 작성하고 있는 Code를 기반으로 다음 내용을 추천하는 형태가 중심이었습니다.

```text
Developer
    ↓
Code 작성
    ↓
AI
    ↓
Code Completion
```

대표적인 사용 방식도 비교적 단순했습니다.

```text
함수 작성

Boilerplate 생성

코드 설명

Refactoring 제안

Test Code 생성
```

AI는 개발자가 요청한 결과를 **텍스트나 코드 형태로 반환하는 역할**을 담당했습니다.

```text
Prompt
  ↓
LLM
  ↓
Code
```

실제 파일을 수정하거나 Application을 실행하고 결과를 확인하는 것은 여전히 개발자의 역할이었습니다.

---

### Agentic Development Tool

Agent형 개발 도구에서는 구조가 달라집니다.

```text
Task
 ↓
AI Agent
 ↓
파일 확인
 ↓
Code 수정
 ↓
명령 실행
 ↓
결과 확인
 ↓
다음 행동 판단
 ↓
완료
```

AI가 단순히 결과를 생성하는 것이 아니라 **목표를 받은 뒤 여러 단계의 작업을 반복적으로 수행하는 구조**입니다.

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

```text
이 Test가 실패하는 원인을 찾아서 수정해줘
```

기존 Coding Assistant라면 관련 Code를 보고 수정안을 제안하는 정도였다면,

Agent는 다음과 같은 작업 흐름을 가질 수 있습니다.

```text
Repository 탐색
      ↓
관련 Code 확인
      ↓
Test 실행
      ↓
Error 분석
      ↓
Code 수정
      ↓
다시 Test 실행
      ↓
결과 확인
```

---

### 핵심은 Feedback Loop

Agent형 도구에서 중요한 부분은 단순히 Tool을 호출할 수 있다는 것이 아닙니다.

**Tool 실행 결과를 다시 Context로 받아 다음 행동을 결정할 수 있다는 점**이 핵심입니다.

```text
Think
  ↓
Act
  ↓
Observe
  ↓
Think
  ↓
Act
```

개발 작업으로 바꾸면 다음과 같습니다.

```text
문제 분석
   ↓
Command 실행
   ↓
Result 확인
   ↓
다음 작업 판단
   ↓
File 수정
   ↓
Test
```

이러한 Feedback Loop가 Coding Assistant와 Coding Agent를 구분하는 중요한 차이 중 하나입니다.

---

### Docker Gordon

Docker가 공개한 Gordon 역시 이러한 흐름을 보여주는 사례였습니다.

기존 Docker 작업에서는 개발자가 직접 명령을 작성해야 했습니다.

```bash
docker build

docker run

docker ps

docker logs
```

Container 문제가 발생하면 Log와 Configuration을 확인하고 원인을 직접 찾아야 했습니다.

```text
Container 실패
     ↓
docker logs
     ↓
Dockerfile 확인
     ↓
Configuration 수정
     ↓
다시 Build
```

AI Agent가 Container 환경을 이해하게 되면 자연어를 기반으로 이러한 작업을 지원할 수 있습니다.

```text
Developer
    ↓
"왜 이 Container가 실행되지 않아?"
    ↓
AI Agent
    ↓
Docker Context 확인
    ↓
원인 분석
    ↓
수정 방법 제안
```

즉 AI가 Source Code뿐 아니라 **Runtime과 Infrastructure 영역까지 들어가기 시작한 것**입니다.

---

### 개발 도구의 범위가 넓어진다

기존 Coding AI가 주로 Source Code를 바라봤다면 Agent형 도구는 훨씬 넓은 Context가 필요합니다.

```text
Developer Agent

├─ Source Code
├─ File System
├─ Git
├─ Terminal
├─ Build
├─ Test
├─ Docker
├─ CI/CD
└─ Cloud
```

예를 들어 Application을 수정한 뒤 실제로 정상 동작하는지 확인하려면 단순한 Code Generation으로는 부족합니다.

```text
Code 수정
   ↓
Build
   ↓
Test
   ↓
Application 실행
   ↓
Log 확인
```

AI가 이 전체 Workflow를 연결할 수 있어야 합니다.

---

### Tool Calling이 중요해진 이유

Agent가 실제 작업을 수행하려면 LLM 밖의 Tool을 사용할 수 있어야 합니다.

```text
LLM
 ↓
Tool Calling
 ↓
External System
```

Coding Agent라면 다음과 같은 Tool이 필요할 수 있습니다.

```text
Tools

├─ read_file
├─ write_file
├─ search_code
├─ run_command
├─ git_diff
├─ run_test
└─ build_project
```

LLM은 자연어로 직접 File System이나 Terminal을 조작하는 것이 아니라 **정해진 Tool Interface를 통해 Action을 실행하는 구조**를 사용합니다.

```text
Agent
 ↓
Tool 선택
 ↓
Parameter 생성
 ↓
Tool 실행
 ↓
Result 반환
 ↓
다음 Reasoning
```

---

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

2024년 말 등장한 MCP(Model Context Protocol) 역시 이 흐름과 연결됩니다.

Agent가 사용할 수 있는 Tool이 늘어나면 각각의 Integration을 직접 구현하는 것이 복잡해집니다.

```text
Agent

↔ GitHub
↔ Database
↔ Files
↔ Docker
↔ Cloud
```

MCP 같은 표준 Interface를 사용하면 다음과 같은 Architecture를 만들 수 있습니다.

```text
Agent
  ↓
MCP
  ↓
Tools

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

Reasoning Model과 Tool Calling, MCP가 결합하면서 **실제 Software Environment에서 작업을 수행하는 Agent Architecture**가 만들어지기 시작한 것입니다.

---

### Backend 구조도 달라진다

단순 LLM Application의 Backend는 비교적 단순합니다.

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

하지만 Agent Application에서는 필요한 Component가 크게 늘어납니다.

```text
Client
  ↓
Agent Backend
  ↓
Agent Runtime
  │
  ├─ LLM
  ├─ State
  ├─ Tools
  ├─ Permissions
  ├─ Execution
  └─ Logs
```

LLM API 호출만으로 Agent를 만들 수 있는 것은 아닙니다.

---

### Agent State

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

```text
Task 시작

Step 1
파일 확인

Step 2
Code 수정

Step 3
Test 실행

Step 4
Error 발생

Step 5
다시 수정
```

Backend에서는 다음과 같은 정보를 관리할 필요가 있습니다.

```text
Agent State

├─ Current Goal
├─ Conversation
├─ Tool Results
├─ Modified Files
├─ Execution History
└─ Current Step
```

Agent가 장시간 작업하거나 여러 Tool을 사용하는 환경에서는 **State Management가 중요한 Backend 설계 요소**가 됩니다.

---

### Permission

Agent가 실제 시스템을 조작할 수 있게 되면 가장 중요한 문제 중 하나가 Permission입니다.

```text
Agent

read_file
→ 상대적으로 낮은 위험


write_file
→ Code 변경


run_command
→ Process 실행


deploy
→ Production 변경
```

모든 Tool을 동일한 권한으로 제공할 수는 없습니다.

따라서 다음과 같은 구조가 필요합니다.

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

예를 들어 Tool별로 다음과 같은 정책을 적용할 수 있습니다.

```text
Read
→ 자동 허용

Write
→ 제한적으로 허용

External Request
→ 정책 확인

Production Deploy
→ 사용자 승인 필수
```

---

### Approval Workflow

Agent가 실제 Action을 수행할수록 **Human Approval**도 중요해집니다.

```text
Agent
 ↓
Code 수정
 ↓
자동 실행 가능


Agent
 ↓
Database Migration
 ↓
사용자 확인


Agent
 ↓
Production Deploy
 ↓
명시적 승인
```

Action의 위험 수준에 따라 자동화 범위를 다르게 설정해야 합니다.

```text
Low Risk
   ↓
Auto Execute


Medium Risk
   ↓
Policy Check


High Risk
   ↓
Human Approval
```

Agent System에서 중요한 것은 가능한 모든 작업을 자동화하는 것이 아니라 **어디까지 자동화할 것인지 제어하는 것**입니다.

---

### Execution Log

Agent가 여러 단계를 자동으로 수행하면 무엇을 했는지 추적할 수 있어야 합니다.

```text
Agent Run

10:01 read package.json

10:02 search auth service

10:03 modify auth.service.ts

10:04 npm test

10:05 test failed

10:06 modify auth.service.ts

10:07 npm test

10:08 success
```

이런 기록이 있어야 문제가 발생했을 때 원인을 찾을 수 있습니다.

따라서 Agent Backend에서는 일반 Application Logging 외에도 **Action Trace**가 중요해집니다.

```text
Agent Observability

├─ Prompt
├─ Reasoning Step
├─ Tool Call
├─ Tool Result
├─ File Change
├─ Error
└─ User Approval
```

---

### Sandbox

Terminal이나 Code Execution Tool을 Agent에게 제공하면 보안 문제가 발생할 수 있습니다.

```text
Agent
 ↓
run_command()
 ↓
Operating System
```

Agent가 생성한 Command를 Application Server에서 그대로 실행하는 것은 위험합니다.

따라서 실제 Architecture에서는 실행 환경을 격리할 필요가 있습니다.

```text
Agent
  ↓
Execution Service
  ↓
Sandbox
  ↓
Command
```

Sandbox에서는 다음과 같은 Resource를 제한할 수 있습니다.

```text
CPU

Memory

Network

File System

Execution Time

Process
```

Coding Agent가 발전하면서 **Sandbox Infrastructure 자체가 중요한 Platform Component**가 되기 시작했습니다.

---

### DevOps까지 AI 영역으로 들어온다

Coding Agent가 Terminal과 Docker, CI/CD를 사용할 수 있게 되면 AI의 역할은 Code Generation을 넘어 DevOps Workflow까지 확대됩니다.

```text
Source Code
     ↓
Build
     ↓
Test
     ↓
Container
     ↓
CI/CD
     ↓
Deploy
```

AI가 이 과정의 여러 단계를 이해하고 Tool을 사용할 수 있게 되는 것입니다.

```text
AI Agent

├─ Code 수정
├─ Test 실행
├─ Docker Build
├─ CI 확인
└─ Deployment 지원
```

개발과 운영 사이의 Automation Layer로 AI가 들어가기 시작합니다.

---

### 왜 중요한가

2023~2024년 Coding AI 경쟁의 핵심은 대체로 다음과 같았습니다.

```text
누가 코드를 더 잘 생성하는가?
```

2025년에는 질문이 달라지기 시작했습니다.

```text
누가 실제 개발 Task를
끝까지 수행할 수 있는가?
```

이를 위해서는 단순 Model Intelligence만으로 부족합니다.

```text
Agent

Model
+
Reasoning
+
Context
+
Tools
+
State
+
Permission
+
Execution
```

여러 Component가 하나의 System으로 결합돼야 합니다.

---

### AI Tool의 경쟁 기준 변화

Agent형 개발 도구가 등장하면서 AI Developer Tool의 경쟁 요소도 달라집니다.

```text
초기

Code Completion
+
Model Quality
```

이후에는 다음 요소가 중요해집니다.

```text
Developer Agent

├─ Model Quality
├─ Repository Context
├─ Reasoning
├─ Tool Integration
├─ Terminal
├─ Test Execution
├─ Permission
├─ Sandbox
├─ UX
└─ Observability
```

같은 AI Model을 사용하더라도 Agent Runtime과 Tooling을 어떻게 설계했는지에 따라 실제 개발 경험이 크게 달라질 수 있습니다.

---

### Backend 개발자에게 중요한 변화

Agent 기능을 Application에 넣으려는 Backend 개발자는 단순 LLM API 호출만 알아서는 부족해지기 시작했습니다.

```text
기존 AI Backend

LLM API
+
Prompt
```

Agent Backend에서는 다음 영역이 필요합니다.

```text
Agent Backend

├─ Model API
├─ Tool Calling
├─ State Management
├─ Permission
├─ Sandbox
├─ Approval
├─ Retry
├─ Timeout
└─ Observability
```

결국 Agent는 하나의 LLM Feature라기보다 **여러 Component가 연결된 Distributed Application에 가까워지는 것**입니다.

---

### 실무 영향

AI를 실제 개발 Workflow에 넣는 방식도 변화합니다.

기존에는

```text
Developer
    ↓
AI에게 질문
    ↓
Code 받음
    ↓
직접 적용
```

구조였다면,

Agent형 도구에서는

```text
Developer
    ↓
Task 전달
    ↓
Agent

├─ 분석
├─ File 수정
├─ Tool 실행
├─ Test
├─ Error 확인
└─ 재시도

    ↓
Developer Review
```

같은 구조가 가능해집니다.

따라서 AI Application Architecture에서도 **Tool Calling, State, Permission, Execution Log, Human Approval**이 핵심 Backend 요소로 들어오기 시작했습니다.

결국 앞으로의 Agentic Application 흐름은,

> **AI가 개발자의 코드를 보조하는 도구에서 실제 개발 환경 안에서 여러 단계를 수행하는 실행 주체로 이동하기 시작한 변화**

라고 볼 수 있습니다.

Model Intelligence만으로 AI Developer Tool을 평가하던 단계에서 벗어나 **Agent Runtime, Tool Interface, Permission, Sandbox, Observability까지 포함한 전체 시스템 설계**가 중요해지기 시작했습니다.

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

독자의 메모