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

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

## AI / Developer Tools — Claude 3.7 Sonnet + Claude Code 등장

Anthropic이 **25년 2월 24일 Claude 3.7 Sonnet과 Claude Code**를 공개했습니다.

Claude 3.7 Sonnet은 일반적인 빠른 응답과 더 많은 추론 시간을 사용하는 **Extended Thinking을 하나의 모델에서 선택할 수 있는 Hybrid Reasoning Model**이었습니다.

동시에 공개된 Claude Code는 Terminal에서 Codebase를 읽고 실제 개발 작업을 수행하는 **Agentic Coding Tool**이었습니다.

이전까지 AI Coding Tool이 IDE 안에서 코드를 추천하거나 수정하는 형태가 중심이었다면, Claude Code는 개발자가 Terminal에서 하나의 작업을 전달하고 **Repository를 탐색하면서 작업을 수행하는 방향**을 보여줬습니다.

[Anthropic - Claude 3.7 Sonnet and Claude Code](https://www.anthropic.com/news/claude-3-7-sonnet)

---

### Claude 3.7 Sonnet의 Hybrid Reasoning

2024년 OpenAI o1 이후 AI 업계에서는 Reasoning Model이 중요한 경쟁 영역으로 떠올랐습니다.

```text
기존 LLM

Prompt
  ↓
Model
  ↓
Answer
```

Reasoning Model에서는 문제를 해결하기 위해 더 많은 계산을 사용할 수 있습니다.

```text
Problem
   ↓
Reasoning
   ↓
Answer
```

Claude 3.7 Sonnet은 이 두 방식을 별도의 모델로 나누기보다 **하나의 모델 안에서 결합하는 방향**을 선택했습니다.

```text
Claude 3.7 Sonnet

        ┌──────────────┐
        │              │
Standard Mode    Extended Thinking
        │              │
        ↓              ↓
   빠른 응답       깊은 추론
```

단순한 질문에는 빠르게 응답하고, 복잡한 문제에서는 더 많은 Reasoning Compute를 사용할 수 있는 구조입니다.

---

### 모든 문제에 깊은 추론이 필요한 것은 아니다

실제 Application에서는 모든 요청에 많은 Reasoning Compute를 사용할 필요가 없습니다.

예를 들어 다음과 같은 작업은 비교적 단순합니다.

```text
Formatting

Simple Extraction

간단한 질문

짧은 코드 생성
```

반면 다음 작업에서는 더 많은 추론이 필요할 수 있습니다.

```text
Complex Coding

Architecture 분석

Debugging

Mathematics

Multi-step Planning
```

따라서 하나의 Model에서도 작업에 따라 다른 전략을 사용할 수 있습니다.

```text
Simple Task
    ↓
Standard Response


Complex Task
    ↓
Extended Thinking
```

Reasoning Compute 자체가 AI Application에서 조절할 수 있는 Resource로 들어오기 시작한 것입니다.

---

### Coding에서는 특히 의미가 크다

실제 개발 작업은 단순히 코드를 생성하는 것보다 문제의 원인을 파악하는 과정이 더 어려운 경우가 많습니다.

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

```text
이 함수 만들어줘
```

는 비교적 단순합니다.

하지만 다음 요청은 다릅니다.

```text
이 Test가 왜 실패하는지 찾아서 수정해줘
```

이를 해결하려면 여러 단계가 필요합니다.

```text
Test 확인
   ↓
관련 Code 탐색
   ↓
Data Flow 확인
   ↓
원인 추론
   ↓
수정 방법 결정
   ↓
Code 변경
```

Coding Agent에서는 Code Generation 능력뿐 아니라 **문제를 분석하고 작업 순서를 결정하는 Reasoning 능력**이 중요합니다.

---

### Claude Code 등장

같은 날 Anthropic은 **Claude Code**를 공개했습니다.

Claude Code는 IDE의 Chat Window가 아니라 **Terminal에서 사용하는 Agentic Coding Tool**이라는 점에서 의미가 있었습니다.

기존 AI Coding Assistant를 단순화하면 다음과 같았습니다.

```text
Developer
    ↓
AI에게 질문
    ↓
Code 제안
    ↓
Developer가 적용
```

Claude Code가 제시한 방향은 조금 다릅니다.

```text
Developer
    ↓
Task 전달
    ↓
Claude Code
    ↓
Repository 탐색
    ↓
Code 수정
    ↓
개발 작업 수행
```

AI가 단순히 코드를 출력하는 것이 아니라 **Repository 안에서 실제 작업을 수행하는 Agent**로 이동하기 시작한 것입니다.

---

### Code Completion에서 Task Execution으로

초기 AI Coding Tool의 핵심은 Autocomplete였습니다.

```text
Developer가 Code 작성
        ↓
AI가 다음 Code 예측
```

이후 Chat이 추가됐습니다.

```text
Developer
    ↓
질문
    ↓
AI
    ↓
Code / 설명
```

Agentic Coding에서는 작업의 단위가 더 커집니다.

```text
Developer
    ↓
Task
    ↓
AI Agent
    ↓
Task Completion
```

예를 들어 개발자는 다음처럼 요청할 수 있습니다.

```text
회원가입 API에 validation을 추가해줘
```

Agent는 이 작업을 해결하기 위해 여러 파일을 확인해야 할 수 있습니다.

```text
Repository
    ↓
Controller 확인
    ↓
DTO 확인
    ↓
Service 확인
    ↓
Validation 추가
    ↓
Test 확인
```

AI가 다루는 단위가 **한 줄의 코드에서 하나의 개발 Task로 확대**된 것입니다.

---

### CLI가 중요한 이유

Claude Code가 Terminal 기반으로 등장한 것도 중요한 변화였습니다.

개발자가 실제로 작업하는 환경에는 Source Code만 존재하지 않습니다.

```text
Development Environment

├─ Source Code
├─ Git
├─ Build Tool
├─ Test
├─ Lint
├─ Package Manager
├─ Docker
└─ Terminal
```

실제 개발에서는 다음과 같은 명령을 끊임없이 사용합니다.

```bash
npm test

npm run lint

npm run build

git diff

./gradlew test

mvn test
```

AI가 Terminal과 연결되면 단순히 Code를 작성하는 것을 넘어 **작성한 Code를 실제 개발 도구로 검증하는 Workflow**를 구성할 수 있습니다.

---

### Agentic Coding Workflow

Agentic Coding의 기본적인 구조는 다음과 같습니다.

```text
Task
 ↓
Plan
 ↓
Repository 탐색
 ↓
Code 수정
 ↓
Test
 ↓
Result 확인
 ↓
Error 발생?
 ├─ Yes → 다시 분석 → 수정
 └─ No  → 완료
```

기존 LLM 호출과 비교하면 차이가 명확합니다.

```text
기존

Prompt
 ↓
LLM
 ↓
Answer
```

Agent는 여러 번 Tool을 사용하며 작업합니다.

```text
Goal
 ↓
Reasoning
 ↓
Action
 ↓
Result
 ↓
Reasoning
 ↓
Action
 ↓
Result
 ↓
Complete
```

**한 번의 생성이 아니라 반복적인 Feedback Loop**가 핵심입니다.

---

### 테스트의 가치가 더 커진다

Agent가 Code를 수정했을 때 중요한 질문은 하나입니다.

```text
이 Code가 정말 정상적으로 동작하는가?
```

이를 가장 쉽게 확인할 수 있는 방법이 Test입니다.

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

실패한다면 Agent가 결과를 다시 분석할 수 있습니다.

```text
Test Fail
   ↓
Error Message
   ↓
Agent
   ↓
원인 분석
   ↓
Code 수정
   ↓
Test
```

따라서 Test는 사람을 위한 Regression 방지 수단이면서 동시에 **AI Agent가 자신의 결과를 검증할 수 있는 Interface**가 됩니다.

---

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

Agent에게 Feedback을 줄 수 있는 것은 Test뿐만 아닙니다.

```text
Agent
 ↓
Code 수정
 ↓
┌─────────────┐
│             │
Type Check   Lint
│             │
└──────┬──────┘
       ↓
    Feedback
```

TypeScript Project라면

```bash
tsc --noEmit
```

을 사용할 수 있고,

Java Project라면 Compiler와 Build Tool을 통해 오류를 확인할 수 있습니다.

```bash
./gradlew build
```

이런 자동화된 검증 수단이 많을수록 Agent가 작업 결과를 확인하기 쉬워집니다.

---

### 좋은 Repository 구조가 더 중요해진다

AI Agent가 Repository를 탐색해야 한다면 Project Structure도 Agent의 성능에 영향을 줍니다.

예를 들어 다음처럼 구조가 명확한 Project가 있다고 가정해보겠습니다.

```text
src/

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

Agent가 User 관련 기능을 수정해야 한다면 관련 Code의 위치를 비교적 쉽게 파악할 수 있습니다.

반대로 Dependency와 책임이 뒤섞여 있다면 탐색 자체가 어려워집니다.

```text
Clear Architecture
       ↓
Human이 이해하기 쉬움
       +
AI가 이해하기 쉬움
```

기존 Software Engineering의 기본 원칙이 Agent 시대에도 그대로 중요합니다.

---

### Repository Instruction

Agent가 Project마다 다른 개발 규칙을 이해할 수 있도록 명시적인 Instruction을 제공하는 것도 중요해집니다.

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

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

Controller에서는 직접 DB에 접근하지 않는다.

새로운 API에는 반드시 Test를 추가한다.

Package Manager는 pnpm을 사용한다.

Lint와 Build가 모두 통과해야 한다.
```

사람에게는 Coding Convention이지만 Agent에게는 **작업 수행 규칙**입니다.

```text
Repository
     +
Project Instructions
     +
Agent
```

AI 시대에는 Project Documentation의 역할도 커질 수밖에 없습니다.

---

### 개발자는 작업 단위로 위임할 수 있다

AI Coding Tool을 사용하는 방법도 달라집니다.

기존에는 다음과 같은 요청이 많았습니다.

```text
이 함수 작성해줘

이 SQL 만들어줘

이 Type 만들어줘
```

Agent에서는 더 큰 단위의 요청이 가능해집니다.

```text
이 기능 구현해줘

관련 Test 추가해줘

Test 실패하면 수정해줘

Build까지 확인해줘
```

즉 개발자가 **Implementation Step 하나하나를 지시하는 방식에서 Goal을 전달하는 방식**으로 이동하기 시작합니다.

---

### 그렇다면 개발자에게 무엇이 중요해지는가

AI가 Implementation을 더 많이 담당할수록 개발자의 역할이 사라지는 것이 아니라 **검증해야 할 범위가 커집니다.**

Agent가 만든 Code가 Compile되고 Test를 통과하더라도 Architecture가 올바르다는 보장은 없습니다.

```text
Test Pass
   ≠
좋은 Architecture
```

예를 들어 다음 문제는 여전히 개발자가 판단해야 합니다.

- Domain Boundary가 올바른가
- Transaction 범위가 적절한가
- Race Condition 가능성이 없는가
- Security 문제가 없는가
- 불필요한 Dependency가 생기지 않았는가
- 성능 문제가 발생하지 않는가
- 요구사항을 정확하게 구현했는가

따라서 Coding Agent가 발전할수록 **Code Review와 Architecture 판단 능력의 중요성이 오히려 커질 수 있습니다.**

---

### Implementation과 Verification의 분리

Agent 기반 Workflow에서는 개발자의 역할을 다음처럼 볼 수도 있습니다.

```text
Agent

Implementation
+
반복 작업
+
자동 검증


Developer

Requirement
+
Architecture
+
Review
+
Final Decision
```

AI에게 모든 판단을 맡기는 것이 아니라 **자동화할 수 있는 Implementation을 위임하고 중요한 Engineering Decision을 사람이 검증하는 구조**입니다.

---

### Claude Code와 Copilot Agent Mode

같은 시기 GitHub 역시 Copilot Agent Mode를 공개했습니다.

두 제품 모두 중요한 방향은 비슷했습니다.

```text
Coding AI

Code Completion
      ↓
Chat
      ↓
Multi-file Editing
      ↓
Agent
```

AI Coding Tool의 경쟁 기준이 다음처럼 바뀌기 시작했습니다.

```text
기존

코드를 얼마나 잘 생성하는가?


Agent 시대

Task를 얼마나
정확하고 안정적으로
완료하는가?
```

AI Developer Tool 시장이 Autocomplete 중심에서 **Agent Execution 중심으로 이동하기 시작한 것**입니다.

---

### Reasoning과 Agent의 결합

Claude 3.7 Sonnet과 Claude Code가 같은 날 공개됐다는 점도 의미가 있습니다.

Agent가 복잡한 개발 Task를 수행하려면 단순 Code Generation보다 더 많은 판단이 필요합니다.

```text
Agent

Task
 ↓
어떤 File을 볼까?
 ↓
무엇을 수정할까?
 ↓
어떤 Command를 실행할까?
 ↓
Error의 원인은 무엇인가?
 ↓
다음 행동은 무엇인가?
```

즉 Agent가 강력해질수록 Reasoning 능력도 중요해집니다.

```text
Reasoning Model
       +
Tool Use
       +
Repository Context
       ↓
Coding Agent
```

Claude 3.7 Sonnet의 Hybrid Reasoning과 Claude Code는 이러한 방향을 동시에 보여준 사례였습니다.

---

### MCP와도 연결된다

Anthropic이 몇 달 전 공개한 MCP(Model Context Protocol)와도 자연스럽게 연결되는 흐름입니다.

Coding Agent가 개발 환경 전체에서 작업하려면 다양한 Tool이 필요합니다.

```text
Coding Agent

├─ Files
├─ GitHub
├─ Database
├─ Documentation
└─ External Services
```

MCP 같은 Tool Interface가 확산되면 Agent가 사용할 수 있는 외부 기능도 쉽게 확장할 수 있습니다.

```text
Claude Code
     ↓
MCP
     ↓
External Tools
```

Reasoning, Agent, MCP가 서로 독립적인 기술이 아니라 **하나의 Agent Architecture를 구성하는 요소**로 연결되기 시작한 것입니다.

---

### AI Coding Tool의 경쟁력이 달라진다

Agent 시대에는 AI Model 하나의 Benchmark만으로 Coding Tool의 품질을 판단하기 어려워집니다.

```text
Coding Agent Quality

Model
+
Reasoning
+
Repository Context
+
Code Search
+
Tool Use
+
Terminal
+
Testing
+
Error Recovery
+
UX
```

같은 Model을 사용하더라도 Agent Runtime과 Context Management가 다르면 실제 개발 경험도 크게 달라질 수 있습니다.

따라서 AI Coding Product의 경쟁력은 점점 **전체 Development Workflow를 얼마나 잘 이해하고 실행하는가**로 이동합니다.

---

### 실무 영향

Claude Code의 등장은 개발자가 AI를 사용하는 단위 자체가 바뀌고 있다는 것을 보여줬습니다.

기존에는

```text
Developer
    ↓
AI에게 Code 요청
    ↓
Code 복사
    ↓
직접 적용
```

이었다면,

Agent Workflow에서는

```text
Developer
    ↓
Task 전달
    ↓
Agent

├─ Repository 탐색
├─ Code 수정
├─ Test
├─ Error 분석
└─ 재수정

    ↓
Developer Review
```

형태로 발전할 수 있습니다.

결국 이번 Claude 3.7 Sonnet과 Claude Code의 등장은,

> **AI Coding Tool이 IDE 안에서 코드를 추천하는 Assistant에서 Repository와 개발 도구를 직접 다루며 하나의 Task를 수행하는 Development Agent로 확장되기 시작한 변화**

라고 볼 수 있습니다.

동시에 개발자에게 중요한 능력 역시 단순히 Code를 얼마나 빠르게 작성하는가보다 **Agent에게 정확한 Task를 전달하고, 생성된 결과의 Architecture와 Logic을 검증하고, 문제를 찾아낼 수 있는 Engineering 능력** 쪽으로 이동하기 시작했습니다.

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

독자의 메모