서버리스 vs 전통 서버, 비용과 유지보수 관점에서

개발
·Dante Chun

서버리스가 뜬 이유

서버리스(Serverless)가 인기를 얻은 이유는 명확하다. 서버 관리를 안 해도 된다. 설정도 쉽고, 스케일링도 자동이다. 특히 Vercel 같은 플랫폼은 git push만 하면 배포가 끝난다.

하지만 몇 년간 서버리스와 전통 서버를 병행해보니, 상황에 따라 선택이 달라져야 한다는 걸 깨달았다.

비용 비교: 실제 수치로

케이스 1: 소규모 블로그/포트폴리오

월 방문자 5,000명, 정적 콘텐츠 위주

Vercel (서버리스):
- Hobby Plan: $0/월
- 밴드위스 100GB/월 포함
- 서버리스 함수 100GB-Hours 포함

전통 서버 (VPS):
- 저렴한 VPS: $5~10/월
- 직접 관리 필요 (SSL, 보안 패치 등)

결론: 서버리스 승리. 무료로 충분히 운영 가능.

케이스 2: 중규모 SaaS

일일 활성 사용자 1,000명, API 호출 많음

Vercel (서버리스):
- Pro Plan: $20/월
- 추가 밴드위스: $0.15/GB
- 추가 함수 실행: $0.18/GB-Hour
- 예상 비용: $20~100/월 (트래픽에 따라 변동)

전통 서버 (VPS):
- 중급 VPS: $20~40/월
- 고정 비용 (트래픽 무관)
- 직접 관리 필요

결론: 비슷하지만 변동성 고려 필요. 트래픽이 예측 가능하면 VPS가 유리할 수 있음.

케이스 3: 고트래픽 서비스

일일 방문자 50,000명, 이미지/동영상 많음

Vercel (서버리스):
- Pro Plan: $20/월
- 추가 밴드위스 (500GB 초과): 약 $60/월
- 추가 함수 실행: 약 $50/월
- 예상 비용: $130+/월

전통 서버 (VPS + CDN):
- 고급 VPS: $40/월
- Cloudflare 무료: $0
- 예상 비용: $40/월 (고정)

결론: 전통 서버 승리. 트래픽이 높을수록 서버리스 비용이 급증.

유지보수 관점

서버리스의 장점

1. 인프라 걱정 제로

서버리스:
- OS 업데이트? 알아서 됨
- 보안 패치? 알아서 됨
- 스케일링? 알아서 됨
- 모니터링? 기본 제공

전통 서버:
- OS 업데이트: 직접 해야 함
- 보안 패치: 직접 확인하고 적용
- 스케일링: 직접 설정
- 모니터링: 직접 구축

2. 배포 단순화

# Vercel
git push origin main  # 끝

# 전통 서버
git push origin main
ssh user@server
cd /var/www/app
git pull
npm install
npm run build
pm2 restart all
# 혹시 문제 생기면 롤백...

전통 서버의 장점

1. 예측 가능한 비용

외주 프로젝트에서 이게 중요하다. 클라이언트에게 "월 비용은 트래픽에 따라 달라집니다"라고 말하면 불안해한다.

클라이언트: "이번 달 서버비가 왜 3배야?"
나: "바이럴이 돼서..."

→ 이런 상황을 피하려면 고정 비용 인프라가 낫다.

2. 더 많은 제어권

가능한 것들:
- 커스텀 런타임 설정
- 백그라운드 작업 (크론잡)
- 웹소켓/실시간 연결
- 로컬 파일 시스템 접근
- 장시간 실행 프로세스

서버리스는 실행 시간 제한(Vercel은 기본 10초, Pro는 60초)이 있어서 특정 작업에는 부적합하다.

3. Cold Start 없음

서버리스 함수는 일정 시간 사용하지 않으면 "잠든다". 다시 깨어나는 데 시간이 걸린다(Cold Start).

일반 API 응답 시간:
- 전통 서버: 50~100ms (일정함)
- 서버리스: 50~100ms (warm) / 500~2000ms (cold)

사용자 경험에 민감한 서비스라면 Cold Start가 문제가 될 수 있다.

내 선택 기준

서버리스 선택

  • 트래픽이 적거나 예측 불가능
  • MVP나 초기 스타트업
  • 프론트엔드 + 간단한 API
  • 배포/운영에 시간 쓰고 싶지 않음
  • 클라이언트가 기술적 배경이 없음

전통 서버 선택

  • 트래픽이 높고 예측 가능
  • 장시간 실행 프로세스 필요
  • 비용 예측이 중요
  • 실시간 기능 (웹소켓 등)
  • 이미 서버 관리 경험이 있음

하이브리드 접근

실제로는 둘을 섞어 쓰는 경우가 많다.

내가 자주 쓰는 구성:

프론트엔드: Vercel (서버리스)
├── 정적 페이지
├── ISR/SSG
└── 간단한 API Routes

백엔드: Railway 또는 VPS
├── NestJS API 서버
├── 크론잡
├── 웹소켓
└── 장시간 작업

데이터베이스: Supabase 또는 직접 운영

구체적인 예

이 블로그의 구성:

  • Next.js 프론트엔드: Vercel (무료)
  • PostgreSQL: Vercel Postgres (유료 플랜)
  • 이미지: Vercel Blob

월 비용: 약 $25 (대부분 DB 비용)

고객 프로젝트 예:

  • Next.js 프론트엔드: Vercel Pro ($20)
  • NestJS 백엔드: Railway ($20)
  • PostgreSQL: Railway 포함
  • Redis: Railway 포함

월 비용: 약 $40~60 (고정)

비용 최적화 팁

1. CDN 적극 활용

이미지, JS, CSS → Cloudflare CDN (무료)
원본 서버 부하 감소 → 서버리스 비용 절약

2. ISR/SSG 활용

서버리스에서 SSR은 비용이 든다. 가능한 많은 페이지를 정적으로 생성하자.

// 비용 많이 드는 방식
export default async function Page() {
  const data = await fetch("...")
  return <Component data={data} />
}

// 비용 절약
export default async function Page() {
  const data = await fetch("...", { 
    next: { revalidate: 3600 } // 1시간 캐시
  })
  return <Component data={data} />
}

3. 사용량 알림 설정

Vercel, AWS 모두 비용 알림 설정이 가능하다. 예상치 못한 비용 폭탄을 막을 수 있다.

Vercel 설정:
Settings → Billing → Spend Management → 알림 설정

결론

서버리스 vs 전통 서버는 "어느 것이 좋다"의 문제가 아니다.

  • 서버리스: 시간을 돈으로 사는 것
  • 전통 서버: 돈을 시간으로 사는 것

1인 개발자로서 시간이 가장 귀중한 자원이라면 서버리스가 맞다. 하지만 비용이 중요하고 서버 관리에 자신이 있다면 전통 서버도 좋은 선택이다.

내 경우, 대부분의 프로젝트는 서버리스(Vercel)로 시작한다. 트래픽이 늘어서 비용이 부담되면 그때 전통 서버로 마이그레이션한다. 이 방식이 가장 효율적이었다.

다른 글