공유 호스팅과 VPS, 무엇을 선택해야 할까?

공유 호스팅과 VPS: 간단한 답

공유 호스팅과 VPS의 차이는 속도 문제가 아니다. 공유 호스팅에서는 다른 사람이 구성하고 패치하며 여러 고객이 함께 사용하는 장비의 계정을 임대한다. 관리되지 않는 VPS(가상 사설 서버)에서는 root 액세스 권한이 있는 전체 운영 체제를 임대하므로, 원하는 소프트웨어를 설치할 수 있다. 동시에 직접 발생시킨 문제도 직접 복구해야 한다.

실제로 다른 점은 3가지다. root 권한이 있는지 여부가 다르다. 메모리 할당량과 보장 범위는 요금제에 따라 다르다. 한밤중에 서버가 응답하지 않을 때 호스트가 문제를 해결하는지, 아니면 직접 해결해야 하는지도 다르다. 기능 비교표의 모든 항목은 이 3가지에서 비롯된다.

사이트가 페이지, 이미지, 문의 양식으로 구성되어 있다면 많은 사이트에서 공유 호스팅이 적합하다. 방문자가 없어도 계속 실행되어야 하는 프로그램이 사이트에 필요하다면, VPS를 선택하기 전에 공유 호스트가 지속 실행 서비스를 지원하는지 확인한다.

공유 호스팅에서 실제로 제공하는 것

하나의 Linux 서버에서 여러 고객 계정을 동시에 운영합니다. 각 계정에는 홈 디렉터리, document root, 데이터베이스, mailbox가 있으며, 일반적으로 Apache 또는 LiteSpeed인 단일 웹 서버가 서버의 모든 사이트를 제공합니다. control panel을 사용하며, 일부 호스팅 업체는 shell prompt도 제공합니다. root 권한은 제공되지 않지만, 일부 제공업체에서는 홈 디렉터리에 설치하는 소프트웨어, 허용된 포트, background service를 사용할 수 있습니다.

많은 공유 호스팅 업체는 CloudLinux를 실행합니다. CloudLinux는 각 계정을 경량 container로 분리하고 processor time, memory, disk I/O, process 수, entry process 수에 제한을 둡니다. 각 제한을 초과하면 증상이 다르게 나타납니다. processor 또는 I/O 제한에 도달하면 사이트 응답이 느려지지만 사이트가 중단되지는 않습니다. memory 또는 process 제한에 도달하면 일반적으로 500 및 503 오류가 나타납니다. Apache에서는 508 Resource Limit Reached라는 제목의 오류 페이지가 entry-process 제한 때문에 표시됩니다. LiteSpeed는 entry process를 다른 방식으로 처리합니다. 어느 경우든 한도를 초과한 것은 자신의 계정이며, 다른 사용자가 자신의 할당량을 가져간 것이 아닙니다.

이러한 절충은 의도된 것입니다. 사용자는 제어 권한을 일부 포기하고, 그 대신 호스팅 업체가 kernel을 패치하고 지원되는 소프트웨어를 유지 관리합니다. 인증서 갱신과 백업 일정은 요금제에 따라 달라집니다. 매우 많은 사이트에서는 이러한 절충이 합리적입니다.

VPS가 실제로 제공하는 것

VPS는 호스트 서버에서 실행되는 가상 머신이다. KVM에서는 인스턴스가 자체 커널로 부팅하고 자체 IP 주소, 자체 방화벽, 자체 init 시스템을 사용한다. 관리형이 아닌 root 액세스가 가능한 Linux VPS에서는 sudo가 작동한다. Debian 또는 Ubuntu 설치에서는 apt install가 작동한다. systemd를 통해 시작한 프로그램은 로그아웃한 뒤에도 계속 실행된다. 적절한 재시작 및 부팅 설정을 적용하면 충돌 후 다시 시작하고 재부팅 후에도 다시 실행된다.

바로 이 root 액세스 때문에 시스템 보안은 사용자의 책임이 된다. 다른 사람이 시스템을 모니터링하지 않는다. 사람들이 VPS에서 실행하는 항목의 범위가 넓은 이유도 여기에 있다. 해당 서버는 Linux 서버에서 수행할 수 있는 모든 작업을 수행한다.

차이 1: root 접근 권한과 이를 통해 가능한 작업

root는 운영 체제를 제어할 수 있는 권한을 제공합니다. root 권한이 있으면 배포판에서 패키지를 설치하고, 모든 포트를 바인딩하고, systemd unit을 작성하고, 시스템의 모든 로그를 읽고, sysctl으로 커널 설정을 변경할 수 있습니다. root 권한이 없어도 패널이 항상 한계가 되는 것은 아닙니다. alwaysdata에서는 ad_install_pecl을 사용해 PHP 확장 모듈을 추가로 설치할 수 있습니다.

VPS에서는 어떤 프로세스가 수신 대기 중인지 항상 시스템에 확인할 수 있습니다.

ss -ltnp

각 소켓 행에는 TCP listener가 표시됩니다. 프로세스 세부 정보는 권한에 따라 달라집니다. 따라서 TCP에서 수신 대기해야 하는 서비스가 시작에 실패하면 해당 행이 표시되지 않습니다. 공유 호스팅에서는 호스트가 80 및 443 포트를 제어하더라도 소켓 정보에 접근할 수 있는지와 직접 listener를 실행할 수 있는지는 provider에 따라 다릅니다.

차이 2: 할당된 메모리와 빌린 메모리

공유 호스팅은 여러 계정이 동시에 바쁘지 않다는 전제로 판매된다. 서버의 메모리는 하나의 풀로 관리되며, 계정에 제공되는 메모리는 예약량이 아니라 제한이다. CloudLinux에서는 물리 메모리 제한에 도달하면 프로세스가 종료되고 방문자에게 500 또는 503 오류가 표시될 수 있다.

VPS에서 free -m는 게스트에 표시되는 메모리를 보고할 뿐, 회수할 수 없는 물리 메모리가 예약되었다는 증거는 아니다. 호스트는 ballooning을 통해 게스트 메모리를 회수할 수 있다. 이 작업이 요금제에서 허용되는지는 제공업체의 리소스 보장 정책에 따라 결정된다.

공유 CPU VPS 요금제에서는 프로세서 시간도 공유 리소스다. 다음 명령으로 steal time을 직접 측정할 수 있다.

vmstat 1 5

st 열은 steal time이다. 이는 가상 프로세서가 실행할 준비가 되었지만 물리 코어가 다른 게스트에 할당되어 있던 시간의 비율이다. 과다 할당을 입증하는 보편적인 정상 비율이나 임계값은 없다. 지속적인 steal time은 지원 티켓에 제시할 수 있는 수치다. vmstat는 일반적인 조회에 root 권한이 필요하지 않지만 관련 /proc 파일에 접근해야 하며, 공유 호스트에서는 해당 정보가 제한될 수 있다. 스토리지도 확인해야 할 리소스다. 따라서 VPS 요금제에 사용되는 디스크 유형이 중요하며, 판매 페이지를 그대로 신뢰하기보다 첫 주에 새 VPS를 직접 측정하는 것이 좋다.

고장 발생 시 책임 주체

공유 호스팅에서는 호스트가 운영 체제, 웹 서버, 지원되는 PHP 빌드를 관리한다. 인증서와 백업 지원 범위는 요금제에 따라 달라진다. 시스템이 응답하지 않으면 티켓을 제출해야 하며, 응답은 호스트의 지원 체계에 따라 달라진다. 이 방식의 비용은 같은 원칙의 다른 측면이다. 지원 환경 밖의 소프트웨어는 호스트의 설치 및 서비스 정책에 맞아야 한다.

관리되지 않는 VPS에서는 제공업체가 하이퍼바이저, 네트워크 및 전원을 관리한다. 커널부터 그 위의 모든 요소는 사용자가 관리해야 한다. 보안 업데이트, 방화벽, 백업, 인증서 갱신 및 모니터링은 모두 사용자의 책임이며, 지원팀은 웹 서버 설정을 디버깅하기 위해 시스템에 로그인하지 않는다. 첫날부터 이를 계획해야 한다. 새 VPS에서 처음 10분 동안 할 일, 이해하고 있는 방화벽, 자동 보안 업데이트, 최소 한 번 복원해 본 백업 순서로 준비한다.

공유 호스팅이 적합한 경우

브로슈어 사이트가 가장 분명한 사례다. 페이지와 이미지, 문의 양식, 캐싱 플러그인을 사용하는 WordPress 정도가 있고, 트래픽이 요금제의 리소스 제한 이내인 경우다. 백그라운드 작업은 없다. 특수한 런타임도 없다. 요청 사이에 메모리에 계속 유지해야 하는 요소도 없다. 공유 호스팅은 이러한 사이트에 적합하고, 서버 유지 관리를 전문 인력에게 맡길 수 있다. 공유 호스팅이 모든 VPS보다 저렴한 것은 아니므로 가격을 비교해야 한다. 사이트를 VPS로 옮겨도 얻는 것은 없고, 기존에 없던 관리 작업만 추가된다.

덜 주목받는 두 번째 사례도 있다. 운영 측에서 로그 파일을 확인하거나 apt upgrade을 실행할 사람이 없다면 공유 호스팅이 더 안전한 선택이다. 데이터베이스 포트가 외부에 열린 상태로 패치되지 않은 VPS는 전문 운영자가 최신 상태로 유지하는 공유 계정보다 더 나쁜 결과를 초래한다. 제어 권한은 누군가가 실제로 사용할 때만 장점이 된다.

징후 1: 계속 실행 상태를 유지해야 하는 프로그램이 필요하다

데몬은 메모리에 상주하면서 작업을 기다리는 프로그램이다. 예를 들면 API, 챗봇, 큐 작업자, 게임 서버가 있다. 공유 호스팅의 정책은 서비스마다 다르다. DreamHost는 공유 요금제에서 지속 실행 프로세스를 금지하지만, alwaysdata는 유료 요금제에서 감독되는 사용자 지정 서비스를 제공한다.

VPS에서는 같은 프로그램이 systemd unit이 된다.

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status은 프로세스 ID와 함께 Active: active (running)을 출력해야 한다. Active: failed (Result: exit-code)을 출력한다면 중지된 시점에 프로그램 자체가 출력한 내용을 보여 주는 journalctl -u myapp -n 50에 원인이 기록되어 있다. unit 파일의 Restart=always은 충돌 후 프로그램을 다시 시작하고, enable은 재부팅 후 프로그램을 다시 시작한다. systemd 서비스와 타이머 작성은 제대로 익혀 둘 가치가 있는 첫 번째 VPS 기술이다.

징후 2: 패널에서 제공하지 않는 런타임이 필요하다

패널에는 목록이 표시된다. 애플리케이션에 목록에 없는 언어 버전, 컴파일해야 하는 라이브러리, ffmpeg, 헤드리스 브라우저 또는 패널에서 제공하지 않는 데이터베이스가 필요하다면 제공업체의 설치 규칙을 확인해야 한다. cPanel은 MySQL을 지원하며, 호스트에서 활성화한 경우 PostgreSQL도 지원한다. 홈 디렉터리에 소프트웨어를 설치할 때 항상 root 권한이 필요한 것은 아니다. DreamHost는 공유 서버에서 zlib와 사용자 지정 Python 버전을 컴파일하는 방법을 문서화하고 있다.

VPS에서는 apt install로 설치하거나 컨테이너에서 실행해 호스트를 깨끗하게 유지할 수 있다. 애플리케이션이 둘 이상의 구성 요소로 이루어지면 VPS에서 Docker Compose 사용이 일반적인 방법이다.

징후 3: cron 작업이 예정된 시간에 실행되어야 합니다

공유 호스팅은 폼을 통해 cron 작업을 받으며, 호스트가 자체적으로 최소 실행 간격을 설정할 수 있습니다. CloudLinux에서는 계정의 프로세서 제한에 도달한 작업을 종료하지 않고 속도를 낮춥니다. 따라서 장시간 실행되는 작업이 다음 실행 예정 시각에도 계속 실행 중일 수 있습니다. 계정이 이미 프로세스 상한에 도달한 경우에는 작업이 새 프로세스를 전혀 시작하지 못합니다. 이 상황의 일부는 확인할 수 있습니다. cPanel의 Cron Email 설정을 사용하면 각 작업의 출력이 이메일로 전송됩니다. 이 기능을 제공하는 CloudLinux 호스트에서는 패널의 Resource Usage 페이지에 계정이 도달한 제한과 발생한 fault 수가 표시됩니다. 시스템 로그에 대한 접근 권한과 제한을 높일 권한은 호스트에 있지만, 일부 제공업체는 시작 및 종료 시각이 포함된 작업 로그를 제공합니다.

VPS에서는 crontab -e 설치된 cron 구현이 지원하는 일정을 허용합니다. 하지만 systemd timer를 사용하는 편이 더 좋습니다.

systemctl list-timers
journalctl -u cron -n 20

list-timers 현재 메모리에 로드된 timer의 다음 트리거 시각과 마지막 트리거 시각을 출력합니다. 해당 서비스의 종료 결과를 출력하는 것은 아닙니다. cron journal의 내용은 설치된 cron 서비스와 로깅 설정에 따라 달라집니다. 작업이 실행되지 않으면 서비스 상태와 로그를 확인하여 작업이 시작되지 않은 것인지, 시작했지만 실패한 것인지 구분해야 합니다. 예약 작업 디버깅의 대부분은 이 차이를 확인하는 과정입니다.

징후 4: 이웃 계정 때문에 응답 시간이 느려진다

증상은 구체적이다. 코드를 변경하지 않은 동일한 페이지가 밤에는 빠르게 응답하지만 저녁 7시에는 느리게 응답한다. 다른 대상을 탓하기 전에 자신의 장비에서 측정한다.

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer은 응답의 첫 번째 바이트까지 걸린 시간이며, 단위는 초다. 20개의 값이 서로 비슷하다면 일관된 타이밍을 보여 줄 뿐, 원인이 서버, 코드 또는 데이터베이스 중 어디에 있는지는 보여 주지 않는다. 새벽 3시에는 안정적이고 사용량이 많은 시간대에는 수백 밀리초씩 변동한다면, 이웃 계정을 탓하기 전에 계정의 리소스 사용량, 요청량 및 서버 로그를 비교한다. 이 측정값에는 연결 설정과 서버 처리가 포함되므로, 이것만으로 원인을 확정할 수는 없다.

실제로 이전에 드는 비용

다음은 2026년 11월 4일에 확인한 광고 가격 예시입니다. 전체 범주의 평균이나 가장 저렴한 요금제가 아닙니다. 공유 호스팅, 4 GB VPS, 관리형 서비스 예시는 연간 결제 기준 DreamHost의 Web Hosting Launch, Stack 4, Managed VPS Business입니다. 1 GiB VPS는 월별 상한 요금이 적용되는 DigitalOcean의 일반 Basic Droplet입니다. 구매하기 전에 현재 가격을 확인해야 합니다.

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

표면적인 가격 차이는 한 달 2.89달러에서 6달러까지지만, 이 숫자만으로 결정할 수는 없습니다. 공유 호스팅 예시는 1년 요금을 선불로 결제해야 하며, 갱신 후에는 한 달에 10.99달러입니다. 갱신 요금끼리 비교하면 결과가 달라집니다. 공유 계정은 10.99달러이고, 입문용 VPS는 6달러입니다. 이 예시에서는 초기 할인 요금이 없으므로 DigitalOcean의 두 금액이 같습니다.

단, 사양이 같지 않으므로 이 비교에 주의해야 합니다. 1 vCPU와 1 GB를 사용하는 VPS에서는 웹 서버와 데이터베이스가 하나의 작은 서버에서 실행됩니다. 실제 트래픽이 발생하면 WordPress에는 여유가 부족할 수 있습니다. 2 vCPU와 4 GB를 사용하는 예시는 갱신 후 한 달에 11.99달러이지만, 공유 계정의 제한과 VPS 용량은 직접 비교할 수 없습니다. 이 예시에서 공유 호스팅 대비 갱신 요금 차이는 한 달에 1달러입니다.

더 큰 비용은 청구서에 나타나지 않습니다. VPS를 설정하는 데 한 시간이 들고, 매달 업데이트에 몇 분이 필요하며, 처음 문제가 발생했을 때 해결하는 데 저녁 시간을 쓰게 됩니다. 자신의 시간당 요율을 적용해 이 비용을 계산하면 가격 차이는 빠르게 줄어듭니다. 실제로 VPS에 드는 비용에서 사양별 차이를 더 자세히 설명합니다.

공유 호스팅에서 트래픽 손실 없이 사이트 이전하기

1. 하루 전에 도메인의 DNS(Domain Name System) TTL(Time To Live)을 300초로 낮추고, 전환하기 전에 이전 TTL이 만료될 때까지 기다린다. 로컬 캐시는 갱신하는 데 더 오래 걸릴 수 있다.
2. DNS를 변경하기 전에 새 서버를 구축하고, 새 서버의 IP 주소로 사이트가 정상 작동하는지 확인한다.
3. 파일을 복사한 다음 데이터베이스를 덤프하고 새 서버에 복원한다.
4. 노트북의 hosts 파일을 사용해 테스트한다. 이 파일은 해당 노트북에서만 도메인이 새 IP를 가리키도록 설정한다.
5. A 레코드를 변경하기 전에 DNS 검증 또는 기존의 유효한 인증서를 사용해 새 서버에서 TLS(Transport Layer Security) 인증서를 발급하고, 공유 호스팅 계정은 일주일 동안 유지한다.

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig의 응답은 두 번째 열에 TTL을 출력하므로, 다른 항목을 전환하기 전에 낮춘 값이 실제로 적용되었는지 확인할 수 있다. --single-transaction은 테이블을 잠그지 않고 InnoDB 테이블의 일관된 스냅샷을 생성한다. 트랜잭션을 지원하지 않는 테이블과 동시에 수행되는 스키마 변경은 별도로 처리해야 하며, 이후에 생성된 주문은 해당 스냅샷에 포함되지 않는다. 새 서버에서는 당일에 인증서가 작동하도록 설정한다. DNS 레코드가 새 서버를 가리키면 Ubuntu에서 nginx로 Let's Encrypt 설정하기를 몇 분 만에 완료할 수 있다.

책임 부담 없이 리소스 사용

사이트가 4가지 징후에 해당하지만 직접 유지 관리하고 싶지 않다면, 관리형 VPS가 중간 선택지다. 제공업체가 합의된 유지 관리 작업을 처리하지만, root 액세스와 관리 범위는 요금제에 따라 다르다. DreamHost의 관리형 VPS에는 root 액세스가 포함되지 않는다. 위 차트에서는 2 GB 관리형 예시가 31.99달러이고 4 GB 비관리형 예시는 11.99달러이므로, 동일한 크기를 비교한 것이 아니다. 이 차액은 서버가 밤에 응답하지 않을 때 다른 사람이 대응하도록 하는 비용이다.

관리형 VPS와 비관리형 VPS 중 선택하기가 이에 해당한다면 다음으로 읽을 내용이다. 이미 부하가 높은 VPS를 운영 중이고 피크 시간대에도 관리에 빼앗기는 시간이 여전히 많다면, 그다음 단계는 이웃이 전혀 없는 전용 서버다.

FAQ

공유 호스팅보다 VPS가 빠릅니까?

항상 그런 것은 아니다. 사용량이 적은 공유 서버가 단일 WordPress 페이지에서 1 vCPU VPS보다 빠를 수 있다. 할당된 메모리가 CPU 경합까지 없애지는 않는다. 공유 CPU VPS에서는 인접한 인스턴스가 여전히 응답 시간에 영향을 줄 수 있으며, 메모리 보장 범위는 제공업체에 따라 다르다. 페이지가 3am뿐 아니라 7pm에도 느리다면 코드, 데이터베이스 쿼리, 호스팅 리소스 제한을 확인해야 한다. 시간대만으로 원인을 판단할 수는 없다.

공유 호스팅에서 Node.js 또는 Python 애플리케이션을 실행할 수 있습니까?

제공업체의 제한 범위 내에서는 가능할 수 있다. 일부 패널은 Passenger를 통해 애플리케이션을 대신 시작하며, 요청이 들어올 때 실행한다. 호스트가 80 및 443 포트를 소유하고 있어도 다른 허용된 리스너를 사용할 수 없는 것은 아니다. alwaysdata의 Public Cloud에서는 IPv6를 통해 8300~8499 포트에서 사용자 지정 서비스를 허용한다. 지속 프로세스 정책도 호스트마다 다르다. 따라서 봇, 큐 워커 또는 websocket 서버에는 VPS가 일반적으로 필요한 것이 아니라, 이를 명시적으로 지원하는 요금제가 필요하다.

VPS를 운영하려면 Linux를 알아야 합니까?

관리되지 않는 VPS라면 그렇다. SSH 키, 방화벽, 업데이트, 백업을 관리하고 로그를 읽는 습관이 필요하다. 초기 설정에는 1시간을 배정하고, 이후에는 매월 몇 분씩 관리할 시간을 확보해야 한다. 이러한 작업을 원하지 않는다면 managed 요금제를 이용할 수 있다. 이 경우 합의된 유지 관리 업무를 제공업체에 맡기며, 이것이 managed VPS와 unmanaged VPS 호스팅의 차이에서 다루는 선택이다.

공유 호스팅에서 VPS로 이전하는 동안 사이트가 중단됩니까?

DNS TTL을 낮추고 두 계정을 모두 실행하면 중단을 피하는 데 도움이 되지만, 원활한 이전을 보장하지는 않는다. 하루 전에 TTL을 300초로 설정하고 이전 TTL이 만료되도록 기다린다. 파일과 데이터베이스를 복사한 다음, 노트북의 hosts 파일을 통해 새 서버를 테스트하고 A 레코드를 변경한다. 변경하는 동안 일부 방문자는 이전 서버에 연결되고 일부는 새 서버에 연결된다. 캐시 업데이트에 5분보다 오래 걸릴 수도 있으므로 공유 계정을 1주일 동안 유지해야 한다. 최종 데이터베이스 덤프와 복원 중에는 쓰기 작업을 일시 중지한다. 이후 쓰기가 유실되지 않도록 이전 사이트를 읽기 전용으로 유지하거나 해당 요청을 새 서버로 전달한다.