2024년 9월 6일(금) 주간 개발트렌드

## Frontend / Cloud — Vercel이 Frontend PaaS에서 Application Platform으로 확장

Vercel이 **8월 28일 Vercel Marketplace**를 공개했습니다.

Marketplace를 통해 Supabase, Upstash를 비롯한 외부 데이터·인프라 서비스를 Vercel 프로젝트와 직접 연결할 수 있는 구조가 등장했습니다.

기존 Vercel이 주로 **Next.js 애플리케이션을 배포하는 Frontend Platform**이라는 이미지가 강했다면, 점점 Database, Cache, Storage, AI 등의 서비스를 하나의 개발 경험 안에서 연결하는 **Application Platform**으로 확장되기 시작했습니다.

---

### 기존 Vercel의 이미지

Vercel은 Next.js를 만든 회사이기도 하기 때문에 오랫동안 Frontend Deployment Platform이라는 이미지가 강했습니다.

```text
Next.js
  ↓
Vercel
  ↓
Frontend Deployment
```

개발자는 Git Repository를 연결하면 Build와 Deployment, CDN 등을 비교적 간단하게 구성할 수 있었습니다.

대표적인 역할은 다음과 같았습니다.

- Next.js 배포
- Preview Deployment
- CDN
- Serverless Functions
- Edge Functions
- Domain 관리
- CI/CD

Frontend 개발자가 Infrastructure를 깊게 다루지 않고도 Web Application을 배포할 수 있다는 것이 Vercel의 강점이었습니다.

---

### Marketplace의 등장

Vercel Marketplace는 Application에서 필요한 외부 서비스를 Vercel Project와 더 쉽게 연결할 수 있도록 만들었습니다.

```text
Vercel Project
      │
      ├─ Database
      ├─ Cache
      ├─ Storage
      ├─ Queue
      └─ AI Service
```

개발자는 서비스마다 별도의 설정 과정을 거치는 대신 Vercel 환경에서 필요한 Integration을 연결하고 Application에서 사용할 수 있게 됩니다.

---

### Application Platform으로의 확장

Vercel의 역할은 점점 단순한 Frontend Hosting을 넘어가고 있었습니다.

```text
기존

Next.js
  ↓
Frontend Deployment
```

점점 다음과 같은 형태로 확장됩니다.

```text
Application

├─ Frontend
├─ Serverless
├─ Database
├─ Cache
├─ Storage
└─ AI
```

Vercel이 모든 Infrastructure를 직접 제공한다기보다는 **여러 서비스를 연결하는 중심 Platform 역할**을 하기 시작한 것입니다.

---

### 왜 중요한가

전통적인 Web Application에서는 Frontend와 Backend Infrastructure가 비교적 명확하게 분리돼 있었습니다.

```text
Frontend
   ↓
Backend API
   ↓
Database
   ↓
Infrastructure
```

예를 들어 AWS에서 서비스를 구축한다면 다음과 같은 Resource를 직접 구성할 수 있습니다.

```text
Route53
   ↓
CloudFront
   ↓
ALB
   ↓
ECS / EC2
   ↓
RDS
   ↓
ElastiCache
```

이 방식은 높은 자유도와 확장성을 제공하지만 작은 서비스나 초기 Startup에서는 Infrastructure 구성 자체가 상당한 작업이 됩니다.

---

### 새로운 SaaS Stack

Vercel과 Managed Service를 조합하면 훨씬 단순한 Architecture를 만들 수 있습니다.

```text
Next.js
   ↓
Vercel
   ├─ Serverless
   ├─ Supabase
   └─ Upstash
```

또는 전체 서비스를 다음과 같이 구성할 수도 있습니다.

```text
Frontend / API
     ↓
   Vercel
     │
     ├─ Database → Supabase
     ├─ Cache → Upstash
     ├─ Storage → Managed Storage
     └─ AI → AI Provider
```

각 Infrastructure를 직접 설치하고 관리하는 대신 **Managed Service를 조립해 하나의 Application을 만드는 방식**입니다.

---

### Frontend와 Backend의 경계 변화

Next.js 같은 Full Stack Framework가 발전하면서 Frontend와 Backend의 경계도 점점 흐려지고 있습니다.

기존에는 다음과 같이 역할이 명확했습니다.

```text
Frontend

React
   ↓
REST API
   ↓
Backend

Spring / Node.js
   ↓
Database
```

하지만 Next.js에서는 Server Component, Route Handler, Server Action 등을 통해 Server-side Logic까지 같은 Project에서 처리할 수 있습니다.

```text
Next.js

├─ UI
├─ Server Component
├─ API
├─ Server Action
└─ Authentication
```

여기에 Vercel의 Serverless Infrastructure와 외부 Managed Service가 연결되면 작은 서비스에서는 별도의 Backend Application 없이도 상당한 기능을 구현할 수 있습니다.

---

### 작은 SaaS에서의 장점

초기 SaaS를 만든다고 가정하면 전통적인 Cloud Infrastructure에서는 많은 요소를 직접 결정해야 합니다.

```text
AWS

├─ VPC
├─ Subnet
├─ Security Group
├─ ECS
├─ ALB
├─ RDS
├─ ElastiCache
├─ S3
└─ CloudWatch
```

반면 Managed Platform 중심으로 구성하면 훨씬 단순해질 수 있습니다.

```text
Next.js
   +
Vercel
   +
Supabase
   +
Upstash
```

이 구조에서는 개발자가 Infrastructure보다 Product 구현에 더 집중할 수 있습니다.

---

### 개발 속도의 변화

Startup이나 개인 SaaS에서는 초기 단계에서 가장 중요한 Resource가 반드시 Infrastructure 성능인 것은 아닙니다.

오히려 다음 요소가 중요할 수 있습니다.

```text
Idea
 ↓
MVP
 ↓
User Feedback
 ↓
Iteration
```

Infrastructure를 직접 구축하는 시간이 줄어들수록 Product를 더 빠르게 시장에 내놓을 수 있습니다.

```text
Traditional Infra

Infrastructure 구축
       ↓
Application 개발
       ↓
Deployment


Managed Platform

Application 개발
       ↓
Deploy
```

Vercel Marketplace 같은 Platform Integration은 이 차이를 더욱 줄여줍니다.

---

### Backend가 필요 없어지는 것은 아니다

다만 이런 흐름이 **전통적인 Backend가 필요 없어진다는 의미는 아닙니다.**

서비스가 복잡해지면 여전히 별도의 Backend Architecture가 필요할 수 있습니다.

예를 들어 다음과 같은 요구사항이 있다면 독립적인 Backend Service가 더 적합할 수 있습니다.

- 복잡한 Domain Logic
- 대규모 Transaction 처리
- Background Job
- 복잡한 Event Processing
- Microservice Architecture
- 장시간 실행되는 Process
- 복잡한 Network 구성
- 세밀한 Infrastructure Control

이 경우 Architecture는 다시 다음과 같이 구성될 수 있습니다.

```text
Vercel
   ↓
Backend API
   ↓
Database / Cache / Queue
```

즉 중요한 것은 Backend의 소멸이 아니라 **작은 서비스에서 Backend Infrastructure를 직접 구성해야 하는 시점이 뒤로 밀리고 있다는 점**입니다.

---

### Cloud 관점에서의 변화

Cloud Infrastructure도 점점 Resource 자체보다 **Developer Experience** 중심으로 추상화되고 있습니다.

기존 Cloud 환경에서는 개발자가 Infrastructure Resource를 직접 조립했습니다.

```text
Compute
+
Network
+
Database
+
Storage
+
Load Balancer
```

최근 Platform에서는 이러한 요소를 Application 중심으로 추상화합니다.

```text
Application
     ↓
Platform
     ↓
Managed Services
```

개발자는 Infrastructure 자체보다 Application에 필요한 기능을 선택하고 연결하는 방식으로 개발할 수 있습니다.

---

### 실무 영향

이러한 구조는 특히 다음과 같은 프로젝트에서 효과적입니다.

- 개인 SaaS
- Startup MVP
- Internal Tool
- Admin Service
- AI Application
- 소규모 Web Service
- Prototype

예를 들어 작은 SaaS라면 다음 Stack만으로도 상당한 수준의 서비스를 만들 수 있습니다.

```text
Next.js
   ↓
Vercel

Database
   ↓
Supabase

Cache / Queue
   ↓
Upstash

AI
   ↓
LLM API
```

직접 Kubernetes Cluster를 만들거나 AWS에 VPC, ECS, RDS 등을 처음부터 구성하지 않고도 Production 수준의 Application을 빠르게 구축할 수 있는 선택지가 늘어난 것입니다.

---

### Architecture 선택 기준

물론 Managed Platform이 항상 정답은 아닙니다.

서비스 규모가 커질수록 다음 요소를 함께 고려해야 합니다.

- 비용
- Vendor Dependency
- Runtime 제한
- Serverless 실행 시간
- Database Connection
- Networking
- Scaling Pattern
- Observability
- Infrastructure Control

초기에는 개발 속도가 중요하지만 규모가 커질수록 비용과 Infrastructure 제어권이 중요해질 수 있습니다.

```text
초기 서비스

Development Speed
        ↓
Managed Platform


서비스 성장

Cost
+
Scalability
+
Infrastructure Control
        ↓
Architecture 재검토
```

따라서 Vercel과 Managed Service 조합은 Infrastructure를 없애는 것이 아니라 **Infrastructure 운영의 상당 부분을 Platform Provider에게 위임하는 방식**이라고 보는 것이 정확합니다.

---

### Vercel의 방향

Vercel Marketplace의 등장은 Vercel이 단순한 Next.js Hosting Platform에 머물지 않겠다는 방향을 보여줬습니다.

```text
Frontend Platform
       ↓
Full Stack Platform
       ↓
Application Platform
```

Application을 구성하는 Database, Cache, Storage, AI 등의 서비스를 직접 연결하면서 개발자가 Vercel을 중심으로 전체 Application Stack을 구성할 수 있도록 확장하고 있는 것입니다.

결국 Vercel Marketplace는,

> **Frontend Deployment Platform이 여러 Managed Service를 연결하는 Application Platform으로 확장되기 시작했다는 흐름**

을 보여주는 사례라고 볼 수 있습니다.

동시에 이는 Frontend, Backend, Cloud Infrastructure 사이의 경계가 점점 흐려지고 있으며 **작은 팀이 훨씬 적은 Infrastructure 운영 비용으로 서비스를 만들 수 있는 방향으로 Web Development가 변화하고 있다는 신호**이기도 했습니다.

---

## 요약



## 태그

Vercel  
VercelMarketplace  
NextJS  
Frontend  
Backend  
FullStack  
Cloud  
PaaS  
Serverless  
ApplicationPlatform  
Supabase  
Upstash  
Redis  
Database  
Cache  
SaaS  
Startup  
CloudInfrastructure  
WebDevelopment  
개발자  
기술트렌드

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

독자의 메모