VPS를 검토할 신호: 20명에서 100명 규모의 사내 서비스 운영 가이드
사내 시스템을 처음 만들 때는 Vercel, Supabase 같은 관리형 서비스를 조합하는 것이 효율적이다. 서버를 직접 관리하지 않아도 되고 사용자가 적은 시기에는 비용도 낮다.
서비스가 성장하면 이제 VPS로 옮겨야 하는지 고민하게 된다. 하지만 VPS 전환 시점은 직원 수만으로 결정할 수 없다. 같은 100명이라도 하루에 몇 번 접속하는 결재 시스템과 실시간 메시지, 파일 변환, 자동화 작업을 수행하는 시스템의 서버 요구량은 다르기 때문이다.
VPS는 사용자가 몇 명이 되었을 때 도입하는 상품이 아니다. 24시간 실행할 작업이 생기고, 서버리스의 실행 방식이 실제 업무 흐름과 맞지 않을 때 검토하는 실행 환경이다.
이 글의 상품 구성과 요금은 2026년 7월 공개 자료를 기준으로 한다. 세금, 환율, 프로모션과 계정별 무료 구간은 포함하지 않았다.
VPS란 무엇인가?
VPS는 Virtual Private Server의 약자로, 물리 서버의 일부 자원을 나눠 사용하는 가상 서버다.
쉽게 말하면 인터넷에 24시간 켜져 있는 Linux 컴퓨터 한 대를 빌리는 것이다. CPU, 메모리, 디스크와 공인 IP를 할당받고 필요한 프로그램을 직접 설치한다.
VPS에서는 다음과 같은 프로그램을 계속 실행할 수 있다.
- Node.js API 서버
- Docker 컨테이너
- 백그라운드 워커
- 작업 큐 소비자
- WebSocket 서버
- 정기 작업과 배치
- Nginx나 Caddy 같은 프록시
- 이미지, 문서, 동영상 변환 프로그램
서버를 자유롭게 사용할 수 있는 대신 운영체제 패치, 방화벽, 배포, 로그, 장애 감지와 백업은 사용자가 책임져야 한다.
VPS를 검토할 대표적인 신호
24시간 실행해야 하는 작업이 생겼다
서버리스 함수는 요청이 들어올 때 실행되는 구조다. 반면 큐 소비자, 알림 발송기, 외부 시스템 동기화처럼 계속 대기해야 하는 작업은 상시 서버가 더 자연스럽다.
이메일과 알림 발송, 문서 변환, 데이터 동기화, 예약 작업, 대량 보고서 생성, 실패 작업 재시도와 외부 API 상태 감시가 대표적이다.
작업 시간이 서버리스 실행 제한에 가까워진다
Vercel Functions는 Fluid Compute를 사용할 때 Pro 기준 기본 최대 실행 시간이 800초다. Node.js와 Python은 현재 베타 기능으로 최대 30분까지 실행할 수 있다.
그러나 요청·응답 본문은 4.5MB, 메모리는 최대 4GB 제한이 있다. 긴 작업을 실행할 수 있게 되었더라도 동영상 변환, 대용량 문서 처리, 브라우저 자동화처럼 CPU와 메모리를 지속적으로 사용하는 작업은 VPS나 전용 워커가 더 적합하다. Vercel Functions 제한과 30분 실행 지원 안내에서 현재 조건을 확인할 수 있다.
지속적인 실시간 연결이 필요하다
현재 Vercel Functions도 WebSocket을 지원한다. 하지만 연결은 해당 함수의 최대 실행 시간까지만 유지되며, 다시 연결했을 때 같은 함수 인스턴스로 연결된다는 보장이 없다.
채팅방 상태, 작업 진행 상태, 장비 연결처럼 서버 메모리에 지속적인 상태를 보관해야 한다면 VPS가 단순하다. 반대로 Supabase Realtime처럼 관리형 실시간 서비스를 사용한다면 별도의 WebSocket 서버가 필요하지 않을 수도 있다. Vercel WebSocket 안내
고정 IP나 직접적인 네트워크 설정이 필요하다
외부 ERP가 고정 IP만 허용하거나 사내 VPN, 특정 TCP·UDP 포트, 자체 프록시 규칙과 특수 Linux 패키지가 필요하다면 VPS를 검토할 이유가 생긴다.
서버리스 비용이 고정 서버보다 계속 높다
사용량이 적고 들쭉날쭉하다면 서버리스가 유리하다. 반대로 CPU 작업과 호출이 하루 종일 일정하게 발생하면 고정 비용의 VPS가 유리해질 수 있다.
한 달 사용량만 보고 이전하기보다 최소 2개월에서 3개월 동안 함수 실행 시간, CPU와 메모리 사용량, 호출 횟수, 작업 대기 시간, 재시도와 시간 초과 발생 횟수를 기록하는 것이 좋다. VPS 비용에는 서버 가격뿐 아니라 백업, 모니터링과 운영자의 관리 시간도 포함해야 한다.
사용자 수에 따른 일반 사무환경 시나리오
아래 사양은 시작점을 잡기 위한 예시다. 실제 서버 용량은 사용자 수보다 동시 작업량과 처리하는 데이터 크기로 결정해야 한다.
| 사용자 규모 | 일반적인 업무 환경 | VPS 필요성 | 권장 시작점 |
|---|---|---|---|
| 20명 | 조회, 입력, 결재, 간단한 첨부 파일 | 대부분 불필요 | 관리형 서비스 유지, 워커가 있으면 메모리 1GB급 |
| 50명 | 알림, 보고서, 파일 처리, 정기 배치 증가 | 상시 워커부터 검토 | 메모리 1GB에서 2GB급 |
| 100명 | 동시 승인, 대량 보고서, 실시간 상태, 외부 연동 | 워커와 API 분리 검토 | 메모리 2GB에서 4GB급, 업무 중요도에 따라 이중화 |
사용자 20명
일반적인 CRUD, 결재, 일정과 문서 관리 시스템은 Vercel과 Supabase만으로 충분할 가능성이 높다.
다만 매일 외부 시스템과 데이터를 동기화하거나 알림 발송 큐, 장시간 보고서 생성, 외부 장비와의 지속적인 연결이 있다면 작은 VPS를 추가할 수 있다. 이 단계에서는 전체 시스템을 옮기지 않고 워커 하나만 분리하는 것이 좋다.
사용자 50명
사용자가 50명에 가까워지면 오전 출근 시간이나 마감 시간처럼 작업이 집중되는 구간이 생긴다. 파일 업로드, 결재, 알림과 보고서 생성이 겹치면 웹 요청과 백그라운드 작업을 분리할 필요가 있다.
프론트엔드와 가벼운 API는 Vercel, 데이터베이스와 인증은 Supabase, 이미지와 첨부 파일은 R2나 S3에 둔다. 알림, 동기화와 보고서 생성은 VPS 워커가 담당한다. Docker와 Node.js 프로세스를 함께 실행한다면 메모리 2GB급부터 시작하는 것이 운영 여유를 확보하기 좋다.
사용자 100명
100명이라고 해서 반드시 EC2나 여러 서버가 필요한 것은 아니다. 사용자가 하루에 몇 차례 접속하는 사내 시스템이라면 작은 서버로도 처리할 수 있다.
다만 업무가 멈추면 회사 운영에 영향을 주는 단계라면 성능보다 장애 대응이 중요해진다. 웹 API와 워커를 분리하고, 자동 재시작, 외부 모니터링, 자동 백업, 복구 테스트와 배포 롤백 절차를 마련해야 한다. 필요하면 서버를 2대로 구성하고 로드밸런서를 둔다.
100명 단계에서 EC2를 검토하는 이유는 단순 성능보다 이중화, 네트워크 통제와 AWS 서비스 연동 때문이다.
일로와 환경에서는 어떻게 적용할까?
일로와와 같은 소규모 업무 서비스에는 다음과 같은 혼합 구성이 적합하다.
| 영역 | 권장 실행 환경 |
|---|---|
| 프론트엔드, 관리자 화면, 가벼운 API | Vercel |
| PostgreSQL, 인증, 일반적인 실시간 데이터 | Supabase |
| 이미지, 첨부 파일, 내보내기 결과 | Cloudflare R2 |
| 알림, 작업 큐, 동기화, 장시간 작업, 커스텀 WebSocket | VPS 또는 상시 컨테이너 |
현재 단계에서 전체 시스템을 VPS로 옮길 필요는 없다. 프론트엔드는 Vercel, 데이터베이스는 Supabase, 파일은 R2에 두고 상시 실행이 필요한 부분만 VPS로 분리하는 것이 좋다.
먼저 워커와 예약 작업을 분리하고, 커스텀 실시간 연결이 필요하면 같은 VPS에서 시작한다. 메모리나 CPU가 부족해지면 사양을 높이고, 워커가 웹 API에 영향을 주기 시작하면 서버를 나눈다. 이중화와 AWS 네트워크 연동이 필요해지는 시점에 EC2를 검토하면 된다.
데이터베이스까지 작은 VPS로 옮기는 것은 신중해야 한다. Supabase를 직접 호스팅하면 PostgreSQL 관리, 보안 패치, 고가용성, 백업, 장애 복구와 모니터링을 직접 책임져야 한다. Supabase 자체 호스팅 안내
대표적인 VPS와 상시 실행 서비스
| 서비스 | 유형 | 장점 | 고려할 점 |
|---|---|---|---|
| AWS Lightsail | 간편 VPS | 서울 리전, 고정 월 요금, 디스크와 전송량 포함 | 확장과 네트워크 구성이 EC2보다 제한적 |
| AWS EC2 | 고급 클라우드 VM | 다양한 사양, IAM, VPC, Auto Scaling, 로드밸런서 | 디스크, IP, 전송료가 분리되어 비용 계산이 복잡 |
| DigitalOcean Droplets | 간편 VPS | 사용하기 쉬운 화면과 문서, 예측 가능한 가격 | 사용할 리전과 한국에서의 지연 시간 확인 필요 |
| Vultr Cloud Compute | 간편 VPS | 서울 위치 선택 가능, 배포가 간단 | AWS 수준의 관리형 서비스 연동은 제한적 |
| Hetzner Cloud | 저비용 VPS | 가격 대비 CPU와 메모리가 큼 | 한국 서비스는 싱가포르 지연 시간과 전송 조건 확인 필요 |
| Railway | 관리형 애플리케이션 플랫폼 | Git과 Docker 중심 배포, 서버 관리 부담이 낮음 | 고정 VPS보다 지속 실행 비용이 높아질 수 있음 |
| Render | 관리형 애플리케이션 플랫폼 | Web Service와 Background Worker 분리가 쉬움 | 리전과 요금제별 자원 확인 필요 |
| Fly.io | 지역 분산 VM 플랫폼 | 사용자와 가까운 지역에 작은 VM 배치 가능 | 일반 VPS보다 네트워크와 볼륨 개념이 복잡 |
DigitalOcean Basic Droplet은 현재 메모리 1GB, 1 vCPU, SSD 25GB, 전송량 1,000GiB 구성이 월 $6부터다. DigitalOcean Droplet 요금
Railway, Render와 Fly.io는 엄밀하게 말하면 전통적인 VPS보다 애플리케이션 실행 플랫폼에 가깝다. SSH로 서버 전체를 관리하기보다 컨테이너와 애플리케이션을 배포한다. 서버 관리 경험이 부족하다면 VPS보다 이런 서비스가 더 안전할 수 있다.
AWS Lightsail과 EC2의 차이
Lightsail과 EC2는 모두 AWS의 가상 서버다. Lightsail은 사용하기 쉬운 VPS 상품이고, EC2는 AWS 인프라를 세밀하게 설계할 수 있는 가상 서버 서비스다.
| 항목 | AWS Lightsail | AWS EC2 |
|---|---|---|
| 요금 | 디스크, IP, 전송량을 묶은 고정 요금 | 인스턴스, 디스크, IP, 전송량을 각각 과금 |
| 설정 난이도 | 낮음 | 높음 |
| 네트워크 | 단순한 방화벽과 고정 IP | VPC, 서브넷, 보안 그룹, 라우팅을 직접 구성 |
| 서버 종류 | 제한된 사양 | 수백 가지 인스턴스 유형 |
| 확장 | 주로 서버 사양을 높이는 방식 | Auto Scaling과 로드밸런서 구성 가능 |
| AWS 권한 | 기본적인 연동 | IAM Role로 세밀한 권한 부여 가능 |
| 디스크 | 서버 사양에 포함 | EBS를 별도로 구성 |
| 전송량 | 월 요금에 비교적 큰 전송량 포함 | 인터넷 전송량 별도 과금 |
| 적합한 환경 | 작은 API, 워커, 블로그, 사내 시스템 | 고가용성, 복잡한 네트워크, 대규모 서비스 |
AWS도 Lightsail은 단순한 애플리케이션과 예측 가능한 월 요금에 적합하고, EC2는 완전한 인프라 통제와 고급 네트워크가 필요한 경우에 적합하다고 안내한다. AWS Lightsail·EC2 선택 가이드
Lightsail 요금 예시
서울 리전에서 사용할 수 있는 공인 IPv4 포함 Linux 인스턴스의 대표 구성은 다음과 같다.
| 월 요금 | 메모리 | vCPU | SSD | 전송량 |
|---|---|---|---|---|
| $5 | 0.5GB | 2 | 20GB | 1TB |
| $7 | 1GB | 2 | 40GB | 2TB |
| $12 | 2GB | 2 | 60GB | 3TB |
| $24 | 4GB | 2 | 80GB | 4TB |
자동 스냅샷은 저장량에 따라 GB당 월 $0.05가 별도로 발생한다. AWS Lightsail 요금표, Lightsail 스냅샷 요금
단순 워커를 시험할 때는 1GB $7 상품으로 시작할 수 있다. Docker, 워커와 WebSocket 서버를 함께 실행한다면 2GB $12 상품이 더 안정적인 출발점이다.
EC2 요금이 더 복잡한 이유
서울 리전의 t4g.micro는 2 vCPU, 메모리 1GB이며 시간당 약 $0.0104다. 한 달 730시간을 실행하면 인스턴스 비용은 약 $7.59다.
비슷한 40GB 구성을 만들면 gp3 디스크 약 $3.65와 공인 IPv4 한 개 약 $3.65가 추가된다. 전송료와 백업을 제외해도 합계는 약 $14.89다. t4g는 ARM 기반이므로 사용하는 Docker 이미지와 네이티브 라이브러리가 arm64를 지원하는지 확인해야 한다. x86 환경이 필요하면 t3 계열을 검토할 수 있다. AWS EC2 요금, AWS EBS 요금, AWS 공인 IPv4 요금
작은 서버 한 대만 필요하다면 Lightsail이 저렴하고 비용도 이해하기 쉽다. EC2의 장점은 더 싸다는 데 있지 않다. IAM, VPC, Auto Scaling, 다양한 인스턴스, 로드밸런서와 AWS 서비스 연동이 필요할 때 가치가 생긴다.
Lightsail로 시작한 뒤 요구사항이 커지면 인스턴스 스냅샷을 EC2의 AMI와 EBS 스냅샷으로 내보낼 수 있다. 따라서 처음부터 EC2를 선택하지 않아도 확장 경로가 막히지는 않는다. Lightsail에서 EC2로 내보내기
VPS 도입 전에 준비할 운영 항목
VPS를 사용한다면 최소한 다음 항목은 함께 준비해야 한다.
- SSH 비밀번호 로그인을 끄고 키 인증 사용
- root 직접 로그인 제한
- 필요한 포트만 방화벽에서 허용
- 운영체제와 Docker 보안 업데이트
- 애플리케이션 자동 재시작
- 외부 상태 확인과 장애 알림
- 로그 보관과 용량 제한
- 정기 스냅샷
- 데이터베이스와 파일의 별도 백업
- 배포 실패 시 이전 버전 복구 절차
- 관리자 변경에 대비한 접근 권한 관리
이 준비가 없다면 저렴한 VPS보다 관리형 컨테이너가 결과적으로 더 안전하고 저렴할 수 있다.
결론
VPS를 검토해야 하는 시점은 사용자가 50명이나 100명이 되었을 때가 아니다.
24시간 실행할 프로세스가 생기고, 장시간 작업과 재시도가 많아지거나 지속적인 실시간 연결, 고정 IP와 네트워크 통제가 필요할 때가 전환 신호다. 서버리스 비용이 여러 달 동안 지속적으로 증가하거나 장애 대응을 위해 실행 환경을 직접 통제해야 할 때도 마찬가지다.
일로와와 같은 소규모 업무 서비스는 전체 VPS 이전보다 Vercel, Supabase, R2를 유지하면서 워커와 커스텀 실시간 서버만 Lightsail이나 관리형 컨테이너로 분리하는 구성이 적합하다.
초기에는 Lightsail 1GB에서 2GB 상품으로 시작하고, 고가용성, Auto Scaling, IAM과 VPC 연동이 필요해지는 시점에 EC2로 확장하는 것이 비용과 운영 복잡성을 함께 관리하기 좋은 경로다.
함께 읽기
- 월 10달러 VPS가 정말 더 저렴할까? 숨은 운영 비용 계산하기월 10달러 안팎의 VPS를 보면 Vercel, Supabase 같은 관리형 서비스를 합친 것보다 훨씬 저렴해 보인다. 실제로 안정적인 부하가 있고 서버를 운영할 사람이 있다면 VPS가 경제적일 수 있다. 하지만 인스턴스 가격만 비교하면 백업, 저장 공간, 전송량, 보안 패치, 장애 대응 시간이 빠진다.
- 일로와 워커·실시간 서버 배포, 무엇을 선택해야 할까?Next.js 서비스의 웹 화면과 API는 Vercel에 올릴 수 있지만, 모든 프로세스를 같은 방식으로 배포할 수 있는 것은 아닙니다. WebSocket 연결을 오래 유지하는 실시간 서버와 큐를 계속 확인하는 백그라운드 워커는 일반적인 웹 요청과 실행 방식이 다릅니다.
- AWS 서비스 10개를 3개로 줄이면 무엇이 달라질까?Next.js로 웹 서비스를 만들 때 AWS 서비스를 하나씩 고르면 꽤 긴 목록이 나온다. CDN, API 입구, 함수 실행, PostgreSQL, 인증, 파일 저장, Redis, Queue, 이벤트 예약, 배포 파이프라인이 각각 다른 서비스다.
- Supabase Queues면 충분한데, QStash는 왜 쓸까?서버리스 프로젝트에 Worker를 붙일 때 QStash가 반드시 필요한 것은 아니다. 이미 Supabase를 사용하고 있다면 PostgreSQL 기반의 Supabase Queues로 작업을 저장하고, Vercel 함수가 메시지를 가져가 처리하는 구조를 만들 수 있다.
- 서버리스 프로젝트에서 Redis가 빛날 때Vercel은 코드를 실행하고, Supabase는 데이터를 영구 저장하며, QStash는 비동기 작업을 전달한다. 여기까지 이해하고 나면 Redis의 자리가 모호하게 느껴질 수 있다.