2024년 11월 8일(금) 주간 개발트렌드

![image](https://librarian-blog-images.s3.ap-northeast-2.amazonaws.com/2a3741f8-626e-4237-b985-d52de10bb444_thumbnail_1.png)

## AI / Developer Tools — GitHub Copilot이 멀티모델 플랫폼으로 전환

GitHub가 **10월 29일 GitHub Universe**에서 GitHub Copilot에 여러 AI 모델을 추가한다고 발표했습니다.

기존 OpenAI 모델 중심에서 벗어나 **Anthropic Claude 3.5 Sonnet, Google Gemini 1.5 Pro, OpenAI o1-preview와 o1-mini** 등을 선택할 수 있는 구조로 확장되기 시작했습니다.

이 변화는 GitHub Copilot이 특정 AI 모델에 종속된 Coding Assistant가 아니라, **여러 모델을 개발 Workflow 안에서 사용할 수 있는 AI Development Platform**으로 이동하기 시작했다는 점에서 의미가 있었습니다.

[GitHub - Bringing developer choice to Copilot](https://github.blog/news-insights/product-news/bringing-developer-choice-to-copilot/)

---

### 기존 AI Coding Assistant

초기의 AI Coding Assistant는 서비스와 기반 모델이 사실상 하나의 제품처럼 묶여 있었습니다.

```text
Developer
    ↓
Copilot
    ↓
GitHub가 선택한 Model
    ↓
Code Generation
```

개발자는 Copilot을 선택할 수는 있었지만 내부에서 어떤 모델을 사용할지는 서비스 Provider가 결정하는 구조에 가까웠습니다.

따라서 AI Coding Tool을 비교할 때도 자연스럽게 기반 모델의 성능이 중요한 요소가 됐습니다.

```text
Coding Tool
    ↓
Base Model
    ↓
Coding Performance
```

---

### 멀티모델 구조로 변화

GitHub의 발표 이후 Copilot은 여러 AI 모델을 활용할 수 있는 방향으로 바뀌기 시작했습니다.

```text
GitHub Copilot
      ↓
Model Selection
      │
      ├─ GPT
      ├─ Claude
      ├─ Gemini
      └─ o1
```

하나의 Coding Assistant 안에서 서로 다른 AI Provider의 모델을 사용할 수 있게 된 것입니다.

중요한 점은 모든 모델이 동일한 특성을 가지고 있지 않다는 것입니다.

```text
Model A
→ 빠른 응답

Model B
→ Coding 강점

Model C
→ 긴 Context

Model D
→ Reasoning
```

따라서 개발자가 수행하려는 작업에 따라 모델을 선택하는 구조가 가능해지기 시작했습니다.

---

### 왜 하나의 모델로 충분하지 않은가

AI 모델은 각각 다른 특성과 Trade-off를 가지고 있습니다.

```text
Model

├─ Coding Performance
├─ Reasoning
├─ Context Window
├─ Latency
├─ Cost
└─ Tool Use
```

예를 들어 단순한 코드 생성과 복잡한 Architecture 분석은 요구하는 능력이 다릅니다.

```text
Boilerplate 생성
      ↓
Fast Model


복잡한 Bug 분석
      ↓
Reasoning Model


대규모 Repository 분석
      ↓
Long Context Model
```

따라서 하나의 모델이 모든 개발 작업에서 항상 최적이라는 전제도 점점 약해지기 시작했습니다.

---

### 작업마다 모델을 선택한다

멀티모델 Coding Assistant에서는 다음과 같은 구조를 생각할 수 있습니다.

```text
Developer Task
      ↓
Task Type
      ↓
Model Selection
      │
      ├─ Code Completion
      │      ↓
      │   Fast Model
      │
      ├─ Code Review
      │      ↓
      │   Coding Model
      │
      ├─ Architecture
      │      ↓
      │   Reasoning Model
      │
      └─ Repository Analysis
             ↓
        Long Context Model
```

즉 AI 개발 도구에서 중요한 질문이

```text
어떤 Model을 사용하는가?
```

에서

```text
어떤 작업에
어떤 Model을 사용하는가?
```

로 바뀌기 시작한 것입니다.

---

### Model Routing

이 흐름은 **Model Routing** 개념과도 연결됩니다.

Model Routing은 요청의 특성에 따라 적절한 AI Model을 선택하는 방식입니다.

```text
Developer Request
       ↓
   Model Router
       │
       ├─ Simple Coding
       │      ↓
       │   Fast Model
       │
       ├─ Complex Reasoning
       │      ↓
       │   o1
       │
       └─ Large Context
              ↓
          Long Context Model
```

초기에는 사용자가 직접 모델을 선택하는 방식이 중심이더라도, 장기적으로는 Tool이 작업의 특성을 분석해 적절한 모델을 선택하는 구조도 생각할 수 있습니다.

---

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

초기 AI Coding Assistant의 경쟁은 모델 성능과 상당히 밀접했습니다.

```text
좋은 Model
    ↓
좋은 Code Generation
    ↓
좋은 Coding Assistant
```

하지만 여러 제품이 다양한 모델을 사용할 수 있게 되면 Tool 자체의 경쟁력이 더 중요해집니다.

```text
AI Coding Platform

├─ Model
├─ Repository Context
├─ IDE Integration
├─ Pull Request Context
├─ Tooling
├─ UX
├─ Agent
└─ Model Routing
```

같은 Claude나 GPT를 사용할 수 있다면 단순히 기반 모델만으로 제품을 차별화하기 어려워집니다.

---

### Repository Context

AI Coding Tool에서 특히 중요한 요소가 **Repository Context**입니다.

개발자의 질문은 대부분 현재 Project와 연결돼 있기 때문입니다.

```text
AI Model
    +
Repository Context
    ↓
실제 Project에 맞는 답변
```

예를 들어 다음 질문은 일반적인 LLM만으로 정확하게 답하기 어렵습니다.

```text
이 API의 인증 흐름을 설명해줘

이 Service가 어떤 Repository를 호출하고 있어?

이번 변경이 어떤 Module에 영향을 줘?

이 Bug가 어디에서 발생하는지 찾아줘
```

AI Coding Tool이 Repository 전체의 구조와 Dependency를 이해할 수 있다면 같은 모델을 사용하더라도 결과의 품질이 크게 달라질 수 있습니다.

---

### Context가 경쟁력이 된다

결국 Coding AI에서는 모델 자체만큼 **모델에게 어떤 Context를 전달할 수 있는가**가 중요합니다.

```text
Model
  +
Current File
  +
Related Files
  +
Git History
  +
Pull Request
  +
Issues
  +
Dependencies
  ↓
Better Coding Assistance
```

GitHub는 Repository, Pull Request, Issue, Security Alert 등 Software Development와 관련된 많은 Context를 이미 가지고 있습니다.

따라서 Copilot의 경쟁력도 단순한 모델에서 **GitHub가 가지고 있는 개발 Context와 AI를 얼마나 잘 연결하는가**로 확장될 수 있습니다.

---

### Developer Workflow와의 결합

개발자는 IDE에서 코드만 작성하는 것이 아닙니다.

실제 Software Development Workflow는 훨씬 넓습니다.

```text
Issue
  ↓
Code
  ↓
Commit
  ↓
Pull Request
  ↓
Code Review
  ↓
CI
  ↓
Security Scan
  ↓
Merge
```

AI Coding Assistant 역시 이 전체 흐름으로 확장될 수 있습니다.

```text
AI Assistant

├─ Code Generation
├─ Code Explanation
├─ Test Generation
├─ Pull Request Review
├─ Security Analysis
├─ Dependency Analysis
└─ CI Failure Analysis
```

이 경우 단순한 Code Completion 성능만으로는 제품의 가치를 설명하기 어려워집니다.

---

### Tooling이 중요해지는 이유

AI 모델 자체는 코드를 생성할 수 있지만 실제 개발 작업을 수행하려면 다양한 Tool이 필요합니다.

```text
AI
 ↓
Tools

├─ File Search
├─ Code Search
├─ Git
├─ Terminal
├─ Test Runner
├─ Build Tool
└─ Repository API
```

예를 들어 AI에게

```text
이 Bug를 고쳐줘
```

라고 요청했다고 가정할 수 있습니다.

단순 LLM은 코드만 제안할 수 있습니다.

하지만 Coding Agent라면 다음과 같은 작업을 수행할 수 있습니다.

```text
Bug 확인
 ↓
관련 Code 검색
 ↓
원인 분석
 ↓
파일 수정
 ↓
Test 실행
 ↓
실패 확인
 ↓
다시 수정
 ↓
결과 제공
```

AI Coding Product의 경쟁력이 점점 **Model + Tool Execution**으로 확장되는 것입니다.

---

### UX도 중요한 경쟁 요소

모델 성능이 비슷해질수록 Developer Experience 역시 중요해집니다.

```text
좋은 Coding AI

Model Quality
      +
Context Quality
      +
Tool Integration
      +
UX
```

예를 들어 다음과 같은 요소가 실제 개발 생산성에 직접적인 영향을 줍니다.

- 응답 속도
- Inline Editing
- Diff 표시
- 변경사항 승인 방식
- File Context 자동 선택
- Terminal Integration
- Error Handling
- Undo / Rollback
- Model Switching

단순 Benchmark에서는 비슷한 모델이라도 실제 IDE Workflow에서는 큰 차이가 발생할 수 있습니다.

---

### Vendor Lock-in도 줄어든다

멀티모델 구조는 AI Provider에 대한 Dependency 측면에서도 의미가 있습니다.

기존에는 다음과 같은 구조였다면,

```text
Coding Tool
    ↓
Single Model Provider
```

멀티모델 환경에서는

```text
Coding Tool
    ↓
Multiple Model Providers
```

가 가능합니다.

특정 Provider의 모델 성능이나 가격 정책이 바뀌더라도 다른 모델을 선택할 수 있는 유연성이 생깁니다.

AI Application에서 이야기하던 **Model Abstraction Layer**가 Coding Tool에도 적용되기 시작한 것입니다.

---

### Backend Architecture와도 비슷하다

이 변화는 일반적인 Backend Architecture에서 외부 Service를 추상화하는 방식과도 비슷합니다.

```text
Application
    ↓
Interface
    ↓
Provider A
Provider B
Provider C
```

AI Platform에서는 이를 다음과 같이 생각할 수 있습니다.

```text
Copilot
   ↓
Model Interface
   ↓
OpenAI
Anthropic
Google
```

상위 Application은 하나의 UX를 제공하면서 내부에서 여러 Provider를 활용합니다.

---

### 모델 자체가 Commodity가 될 가능성

여러 AI 제품에서 동일한 Model Provider를 사용할 수 있게 되면 모델 자체만으로 차별화하기 어려워질 수 있습니다.

```text
Product A ─┐
Product B ─┼→ Claude
Product C ─┘
```

그렇다면 제품 경쟁력은 다른 영역으로 이동합니다.

```text
Model
  ↓
점점 공통 Resource


차별화

Context
Tooling
Workflow
UX
Agent
Data
```

AI Coding Tool에서는 특히 **Repository와 Developer Workflow에 얼마나 깊게 연결되는가**가 중요한 경쟁 요소가 됩니다.

---

### Developer Tools 시장의 변화

멀티모델 Copilot은 AI Developer Tool 시장의 구조가 변하고 있다는 신호이기도 했습니다.

기존에는

```text
AI Coding Tool
      ↓
특정 Model
```

이라는 구조가 강했다면,

점점

```text
Developer Platform
      ↓
AI Layer
      ↓
Multiple Models
      ↓
Tools / Context
```

형태로 발전하기 시작했습니다.

AI Model이 제품 전체가 아니라 **Platform 내부에서 선택 가능한 하나의 Component**가 되는 것입니다.

---

### 실무 영향

개발자 입장에서는 AI Coding Tool을 평가하는 기준도 달라질 수 있습니다.

단순히

```text
GPT를 쓰는가?

Claude를 쓰는가?
```

만 보는 것이 아니라,

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

관련 File을 제대로 찾는가?

Git Context를 활용하는가?

PR을 이해하는가?

Test를 실행할 수 있는가?

어떤 Model을 선택할 수 있는가?

작업에 따라 Model을 바꿀 수 있는가?
```

같은 요소가 중요해집니다.

특히 복잡한 Project에서는 모델의 Benchmark 점수보다 **실제 Project Context를 얼마나 정확하게 전달하고 활용하는가**가 생산성에 더 직접적인 영향을 줄 수 있습니다.

---

### AI Coding Assistant에서 AI Development Platform으로

Copilot 초기의 핵심 기능은 Code Completion이었습니다.

```text
Copilot

Code Completion
```

하지만 기능이 계속 확장되면서 다음과 같은 형태로 변하고 있습니다.

```text
Copilot

├─ Code Completion
├─ Chat
├─ Repository Context
├─ Pull Request
├─ Security
├─ Multiple Models
└─ Developer Workflow
```

따라서 Copilot을 단순한 코드 자동완성 Tool보다 **Developer Workflow 전반에 AI를 연결하는 Platform**으로 보는 것이 점점 자연스러워지고 있습니다.

---

### 실무적으로 중요한 변화

멀티모델 지원에서 가장 중요한 것은 모델의 숫자가 늘어났다는 사실 자체가 아닙니다.

더 중요한 변화는 AI Developer Tool의 구조가

```text
Product = Model
```

에서

```text
Product

=
Model
+
Context
+
Tools
+
Workflow
+
UX
+
Routing
```

으로 변화하기 시작했다는 점입니다.

결국 GitHub Copilot의 멀티모델 전환은,

> **AI Coding Tool의 경쟁력이 특정 AI 모델 자체에서 개발자의 Context와 Workflow를 얼마나 잘 연결하는가로 이동하기 시작했다는 신호**

라고 볼 수 있습니다.

2024년 11월 1일(금) 주간 개발트렌드

독자의 메모