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

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

## AI / Developer Tools — GPT-4.1, 코딩 특화 + 100만 토큰 Context

OpenAI가 **25년 4월 14일 GPT-4.1, GPT-4.1 mini, GPT-4.1 nano**를 API에 공개했습니다.

GPT-4.1 계열은 기존 GPT-4o보다 **Coding, Instruction Following, Long Context 처리 능력**을 강화했고, 최대 **100만 Token Context Window**를 지원했습니다.

특히 Coding에서는 단순한 함수 생성뿐 아니라 Repository를 탐색하고 여러 파일에 걸친 변경을 수행하는 Software Engineering 작업에 초점을 맞춘 개선이 이루어졌습니다.

Context Window 역시 기존 GPT-4o 계열의 128K에서 최대 1M Token까지 크게 늘어나면서 AI가 한 번에 이해할 수 있는 Code와 Document의 범위가 크게 확대됐습니다.

[OpenAI - Introducing GPT-4.1 in the API](https://openai.com/index/gpt-4-1/)

---

### 기존 AI Coding의 Context

초기 AI Coding Assistant는 대부분 현재 작성하고 있는 Code 주변을 Context로 사용했습니다.

```text
Current File
     ↓
LLM
     ↓
Code Completion
```

예를 들어 개발자가 함수 하나를 작성하면 주변 Code를 보고 다음 내용을 예측하는 형태였습니다.

```javascript
function calculateTotal(items) {
  // AI가 다음 Code를 생성
}
```

AI가 이해하는 범위 역시 비교적 작았습니다.

```text
Function

↓

File

↓

몇 개의 관련 File
```

하지만 실제 Software Engineering 문제는 대부분 하나의 File 안에서 끝나지 않습니다.

---

### 실제 Repository는 여러 Module이 연결돼 있다

Backend Application 하나만 봐도 기능 하나가 여러 Layer에 걸쳐 있을 수 있습니다.

```text
User Feature

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

Frontend 역시 마찬가지입니다.

```text
Feature

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

복잡한 Bug를 분석하거나 Architecture를 변경하려면 여러 File 사이의 관계를 동시에 이해해야 합니다.

```text
File A
  ↓
File B
  ↓
File C
  ↓
Database
```

Context Window가 작으면 필요한 Code를 개발자가 직접 골라서 Model에 제공해야 했습니다.

---

### 100만 Token Context

GPT-4.1 계열은 최대 **1M Token Context Window**를 지원했습니다.

구조적으로 보면 AI가 한 번의 요청에서 훨씬 더 많은 정보를 볼 수 있게 된 것입니다.

```text
기존

Current File
+
Related Files
        ↓
      Model


Long Context

Large Repository
+
Documentation
+
Issue
+
Logs
+
Test
        ↓
      Model
```

OpenAI는 당시 1M Token이 React Codebase 전체를 여러 번 넣을 수 있을 정도의 크기라고 설명했습니다.

Long Context 자체가 Software Engineering Workload의 중요한 Model Capability가 되기 시작한 것입니다.

---

### 함수 단위에서 Repository 단위로

AI Coding의 작업 단위도 점점 커졌습니다.

초기에는

```text
Function 생성
```

정도가 일반적이었다면,

점점

```text
File 수정
```

으로 확대됐고,

Long Context와 Coding Agent가 발전하면서

```text
Repository 분석
```

까지 가능성이 커졌습니다.

```text
Function
   ↓
File
   ↓
Module
   ↓
Repository
```

개발자가 AI에게 전달하는 요청 역시 달라질 수 있습니다.

```text
기존

"이 함수 작성해줘"
```

에서

```text
"이 인증 구조를 분석하고
Refresh Token 처리 방식을 수정해줘"
```

처럼 더 높은 수준의 Task를 전달할 수 있게 됩니다.

---

### Repository-level Coding

Repository 수준의 작업에서는 단순한 Code Generation보다 **Codebase 전체의 관계를 이해하는 능력**이 중요합니다.

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

```text
User 삭제 기능을 Soft Delete 방식으로 변경해줘
```

실제로는 여러 곳을 수정해야 할 수 있습니다.

```text
User Entity
    ↓
Repository Query
    ↓
Service Logic
    ↓
Authentication
    ↓
Admin API
    ↓
Test
```

AI가 하나의 File만 보면 일부 변경을 놓칠 수 있습니다.

Long Context를 활용하면 관련 Code를 더 넓은 범위에서 동시에 분석할 수 있습니다.

---

### Coding 성능 자체도 강화

GPT-4.1은 Long Context만 늘어난 Model은 아니었습니다.

OpenAI는 **Coding Capability 자체도 GPT-4o 대비 크게 개선**했다고 발표했습니다.

특히 실제 Software Engineering 문제를 평가하는 SWE-bench Verified에서 높은 성능 향상을 강조했습니다.

이런 Benchmark가 중요한 이유는 단순 Algorithm 문제와 실제 개발 작업의 성격이 다르기 때문입니다.

```text
Algorithm Benchmark

문제
 ↓
Code 생성
```

실제 Software Engineering에서는 다음 과정이 필요합니다.

```text
Issue 이해
   ↓
Repository 탐색
   ↓
관련 Code 발견
   ↓
원인 분석
   ↓
Patch 작성
   ↓
Test 통과
```

AI Coding Model의 경쟁이 **Code 생성 능력에서 Software Engineering Task 수행 능력으로 이동**하고 있는 것입니다.

---

### Instruction Following도 중요하다

Repository 전체를 수정하는 Agent에서는 Coding 능력만큼 **Instruction Following**도 중요합니다.

예를 들어 개발자가 다음과 같은 조건을 줬다고 가정할 수 있습니다.

```text
Controller는 수정하지 않는다.

새 Dependency를 추가하지 않는다.

기존 Repository Pattern을 유지한다.

Test를 반드시 추가한다.
```

Model이 Code를 잘 작성하더라도 이 조건을 무시하면 실제 Project에서는 사용할 수 없습니다.

```text
Good Code
+
Wrong Instruction
=
Bad Change
```

따라서 Agentic Coding에서는 다음 두 능력이 함께 필요합니다.

```text
Coding
+
Instruction Following
```

GPT-4.1이 이 두 영역을 동시에 강조한 것도 이런 Developer Tool 흐름과 연결됩니다.

---

### Long Context가 Agent에도 중요하다

2025년에는 Coding AI가 빠르게 Agent 형태로 발전하고 있었습니다.

```text
Copilot Agent Mode

Claude Code

Coding Agents
```

Agent는 단순히 Code를 생성하지 않습니다.

```text
Task
 ↓
Repository 탐색
 ↓
관련 File 확인
 ↓
Code 수정
 ↓
Test
 ↓
Error 확인
 ↓
다시 수정
```

이 과정에서 Repository Context를 얼마나 정확하게 유지할 수 있는지가 중요합니다.

```text
Agent Performance

Reasoning
+
Coding
+
Tools
+
Repository Context
```

Long Context는 Agent가 더 많은 Code와 History를 동시에 이해할 수 있는 기반이 됩니다.

---

### 대규모 Refactoring

Long Context가 특히 유용할 수 있는 작업 중 하나가 **대규모 Refactoring**입니다.

예를 들어 공통 API Client를 교체한다고 가정해보겠습니다.

```text
Old API Client

├─ Module A
├─ Module B
├─ Module C
├─ Module D
└─ Module E
```

여러 Module에서 동일한 변경이 필요할 수 있습니다.

```text
Old Client
    ↓
New Client
```

AI가 Repository 전체에서 사용 위치를 확인하고 영향을 분석할 수 있다면 Refactoring 작업의 범위를 파악하기 쉬워집니다.

---

### Architecture 분석

대규모 Context는 Code 작성뿐 아니라 Architecture 이해에도 사용할 수 있습니다.

예를 들어 다음과 같은 질문입니다.

```text
이 프로젝트에서
주문 생성 흐름을 설명해줘
```

Model은 여러 Layer를 확인해야 합니다.

```text
Controller
    ↓
Application Service
    ↓
Domain
    ↓
Repository
    ↓
Event
    ↓
External System
```

Context가 충분하면 단순한 File 설명이 아니라 **System Flow 자체를 분석하는 작업**으로 확장할 수 있습니다.

---

### Bug 분석에서도 유용하다

복잡한 Bug는 실제 원인과 Error 발생 위치가 다른 경우가 많습니다.

```text
Error

OrderController
     ↓

실제 원인

Transaction
     ↓
Event Handler
     ↓
Database
```

한 File만 보고 분석하면 원인을 찾기 어렵습니다.

```text
Logs
+
Source Code
+
Tests
+
Configuration
       ↓
      LLM
```

긴 Context를 이용하면 서로 다른 정보를 동시에 비교하는 것이 가능해집니다.

---

### 하지만 1M Context를 항상 채우는 것은 좋은 전략이 아니다

Context Window가 1M Token이라고 해서 매 Request마다 Repository 전체를 넣는 것이 가장 좋은 방법은 아닙니다.

```text
Repository 전체
      ↓
1M Context
      ↓
Model
```

이 방식에는 몇 가지 문제가 있습니다.

```text
Token Cost 증가

Request 크기 증가

Latency 증가

불필요한 Context 증가

관련 정보 탐색 난이도 증가
```

Context Capacity와 Context Strategy는 다른 문제입니다.

---

### Context가 많다고 항상 좋은 것은 아니다

Model에게 필요한 정보가 10개 File인데 Repository 전체 2,000개 File을 전달한다고 가정할 수 있습니다.

```text
Relevant Files

10


전체 Repository

2000
```

Model 입장에서는 불필요한 정보도 함께 처리해야 합니다.

```text
Useful Context
      +
Noise
      ↓
Large Context
```

따라서 중요한 것은

```text
얼마나 많이 넣을 수 있는가?
```

보다

```text
어떤 Context를 넣을 것인가?
```

입니다.

---

### Repository Indexing

대규모 Codebase에서는 Repository를 미리 분석하고 Index를 만들어 필요한 Code만 가져오는 방법을 사용할 수 있습니다.

```text
Repository
    ↓
Indexing
    ↓
Search
    ↓
Relevant Files
    ↓
LLM
```

예를 들어 다음 정보를 Indexing할 수 있습니다.

```text
File Path

Symbol

Function

Class

Import

Dependency

Embedding
```

사용자의 요청과 관련된 File을 먼저 찾고 필요한 Context만 Model에 전달하는 방식입니다.

---

### Retrieval + Long Context

Long Context와 Retrieval은 경쟁 관계가 아닙니다.

두 가지를 함께 사용할 수 있습니다.

```text
Repository
    ↓
Index / Search
    ↓
관련 Code 선택
    ↓
Long Context
    ↓
Model
```

Retrieval을 통해 Noise를 줄이고,

Long Context를 통해 선택된 여러 File과 문서를 한 번에 분석하는 방식입니다.

```text
Retrieval

무엇을 볼 것인가?


Long Context

얼마나 많이 함께 볼 것인가?
```

두 가지가 서로 다른 문제를 해결합니다.

---

### Coding Agent의 Context 전략

실제 Coding Agent에서는 다음과 같은 흐름을 사용할 수 있습니다.

```text
User Task
    ↓
Repository Search
    ↓
관련 Symbol 탐색
    ↓
필요한 File 읽기
    ↓
Context 구성
    ↓
Model
    ↓
Code 수정
```

필요하면 추가 Context를 다시 가져옵니다.

```text
Model
 ↓
정보 부족
 ↓
Search
 ↓
Additional Context
 ↓
Model
```

Repository 전체를 처음부터 Prompt에 넣기보다 **Agent가 필요할 때 Context를 탐색하는 구조**가 더 효율적일 수 있습니다.

---

### Context도 비용이다

LLM API에서는 Input Token 역시 비용과 연결됩니다.

```text
Request Cost

Input Tokens
+
Output Tokens
```

따라서 Context가 커지면 Request당 비용도 증가할 수 있습니다.

```text
10K Context

vs

100K Context

vs

1M Context
```

대규모 서비스에서는 작은 차이도 전체 비용에 큰 영향을 줄 수 있습니다.

```text
Context 증가
    ↓
Token 증가
    ↓
Cost 증가
```

Long Context를 사용할 수 있다는 것과 항상 Long Context를 사용해야 한다는 것은 전혀 다른 문제입니다.

---

### Latency도 고려해야 한다

긴 Input을 처리하려면 Model이 더 많은 정보를 읽어야 합니다.

```text
Large Context
     ↓
More Processing
     ↓
Latency 영향
```

특히 IDE처럼 빠른 Feedback이 중요한 환경에서는 Latency가 매우 중요합니다.

```text
Autocomplete

→ 매우 낮은 Latency 중요


Repository Analysis

→ 높은 Latency 허용 가능
```

따라서 Task 종류에 따라 Context 전략도 달라져야 합니다.

---

### 작업별 Context 전략

예를 들어 다음과 같이 나눌 수 있습니다.

```text
Autocomplete

Current File
+
Nearby Code
```

```text
Bug Fix

Related Files
+
Logs
+
Tests
```

```text
Architecture Analysis

Multiple Modules
+
Documentation
+
Dependency
```

```text
Large Refactoring

Repository-wide Context
+
Search
+
Index
```

모든 작업에 같은 Context Strategy를 사용하는 것은 비효율적입니다.

---

### Context Routing

Model Routing과 비슷하게 **Context Routing**도 중요한 문제가 됩니다.

```text
User Request
     ↓
Task 분석
     ↓
필요 Context 판단
     ↓
Repository Search
     ↓
Context 구성
     ↓
Model
```

Backend나 Coding Agent가 Model에게 전달할 정보를 선택하는 Layer를 갖는 것입니다.

AI Application의 품질이 Model 자체뿐 아니라 **Context Engineering**에 크게 영향을 받기 시작합니다.

---

### Context Engineering

Prompt Engineering이

```text
Model에게
어떻게 지시할 것인가?
```

의 문제라면,

Context Engineering은

```text
Model에게
무엇을 보여줄 것인가?
```

의 문제입니다.

Coding Agent에서는 특히 중요합니다.

```text
Context

├─ User Request
├─ Current File
├─ Related Files
├─ Git Diff
├─ Test
├─ Error Log
├─ Documentation
└─ Repository Rule
```

어떤 정보를 어떤 순서와 범위로 제공하는지가 결과에 영향을 줍니다.

---

### AI Coding Architecture의 변화

초기 AI Coding Tool은 구조가 단순했습니다.

```text
Editor
  ↓
Current Code
  ↓
Model
  ↓
Completion
```

점점 다음과 같이 발전합니다.

```text
Developer
    ↓
Coding Agent
    ↓
Repository Index
    ↓
Context Retrieval
    ↓
Long Context Model
    ↓
Tools
    ↓
Code Change
    ↓
Test
```

Model 하나만으로 Coding AI가 완성되는 것이 아니라 **Repository Understanding Layer 전체가 필요해지는 것**입니다.

---

### Long Context와 MCP

MCP 같은 Tool Protocol과도 연결해서 볼 수 있습니다.

Agent가 필요한 정보를 모두 Context 안에 직접 넣는 대신 외부 Tool을 통해 가져올 수 있습니다.

```text
Agent
  ↓
MCP
  ↓
Repository / Database / Docs
```

즉 Agent Architecture에는 두 가지 방식이 공존합니다.

```text
Context에 미리 제공

        +

필요할 때 Tool로 조회
```

어떤 데이터를 Context로 유지하고 어떤 데이터를 Tool로 조회할 것인지도 Architecture 결정이 됩니다.

---

### Model Routing과 함께 사용

AI Coding Platform에서는 Context뿐 아니라 Model도 작업에 따라 선택할 수 있습니다.

```text
Task
 ↓
Router
 │
 ├─ Autocomplete
 │      ↓
 │   Fast Model
 │
 ├─ Simple Edit
 │      ↓
 │ Small Model
 │
 └─ Repository Analysis
        ↓
    GPT-4.1
```

Task Complexity와 Context Size를 함께 고려하는 것입니다.

```text
Routing Criteria

Task Complexity
+
Context Size
+
Latency
+
Cost
```

AI Backend가 점점 일반적인 Resource Scheduling 문제처럼 변하고 있습니다.

---

### mini와 nano의 의미

GPT-4.1은 하나의 Model만 공개된 것이 아니었습니다.

```text
GPT-4.1 Family

├─ GPT-4.1
├─ GPT-4.1 mini
└─ GPT-4.1 nano
```

서로 다른 성능과 비용, Latency 요구사항에 맞춰 Model을 선택할 수 있게 한 구조입니다.

예를 들어 다음처럼 사용할 수 있습니다.

```text
Complex Coding
      ↓
GPT-4.1


Normal Processing
      ↓
GPT-4.1 mini


High-volume Simple Task
      ↓
GPT-4.1 nano
```

Long Context와 함께 **Model Routing을 고려한 Product Architecture**가 더욱 중요해집니다.

---

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

AI Coding Tool을 사용할 때 중요한 질문도 달라집니다.

초기에는

```text
어떤 Model이 Code를
가장 잘 생성하는가?
```

가 중요했다면,

점점 다음과 같은 질문이 중요해집니다.

```text
Repository를 얼마나 잘 이해하는가?

관련 File을 제대로 찾는가?

얼마나 많은 Context가 필요한가?

Tool을 사용할 수 있는가?

Test를 수행할 수 있는가?

Cost와 Latency는 적절한가?
```

AI Coding의 성능이 Model Benchmark 하나로 결정되지 않게 된 것입니다.

---

### 왜 중요한가

GPT-4.1의 1M Context가 중요한 이유는 단순히 Token 숫자가 커졌기 때문만은 아닙니다.

AI가 다룰 수 있는 Software Engineering Task의 범위가 넓어졌다는 점이 중요합니다.

```text
초기

Function
   ↓
AI


이후

File
   ↓
AI


Long Context + Agent

Repository
   ↓
AI
```

대형 Codebase 분석, 여러 Module에 걸친 Refactoring, Architecture 분석 같은 작업도 LLM 활용 범위에 들어오기 시작했습니다.

---

### 실무 영향

대규모 Project에서 Long Context는 강력한 기능이지만 실제 Application에서는 **무조건 많은 Context를 넣는 것보다 필요한 Context를 정확하게 선택하는 것이 더 중요**합니다.

현실적인 Coding Agent Architecture는 다음과 같은 형태가 될 수 있습니다.

```text
Repository
    ↓
Indexing
    ↓
Search / Retrieval
    ↓
Relevant Context
    ↓
GPT-4.1
    ↓
Agent
    ↓
Code Change
    ↓
Test
```

이를 통해

```text
Large Context Capability
+
Repository Indexing
+
Context Retrieval
+
Tool Use
```

를 함께 활용할 수 있습니다.

결국 GPT-4.1의 등장은,

> **AI Coding이 함수나 단일 파일을 생성하는 단계에서 대규모 Repository의 구조를 이해하고 여러 Module에 걸친 Software Engineering Task를 수행하는 방향으로 확대되고 있음을 보여주는 변화**

라고 볼 수 있습니다.

다만 1M Context가 있다고 해서 Repository 전체를 항상 입력하는 것이 최선은 아닙니다.

실제 AI Developer Tool에서는 **Repository Indexing, Context Retrieval, Tool Calling을 통해 필요한 정보만 선택하고 Long Context를 필요한 순간에 활용하는 Context Engineering 전략**이 비용과 Latency, 정확도 측면에서 더욱 중요해졌습니다.

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

독자의 메모