공유 호스팅 vs VPS 차이점: 나에게 맞는 서버 선택 가이드

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

공유 호스팅과 VPS의 차이는 속도 문제가 아닙니다. 공유 호스팅은 다른 누군가가 설정하고 패치하며 수백 명의 고객이 함께 사용하는 장비의 계정을 임대하는 방식입니다. 반면 VPS(Virtual Private Server)는 root 권한이 포함된 운영 체제 전체를 임대하는 것이므로, 원하는 소프트웨어를 직접 설치하고 문제가 발생하면 스스로 해결해야 합니다.

실질적인 차이는 세 가지입니다. root 권한의 유무, 메모리가 사용자에게 할당되는지 아니면 공유 풀에서 빌려 쓰는지, 그리고 한밤중에 서버가 응답하지 않을 때 호스팅 업체가 해결하는지 아니면 사용자가 직접 해결해야 하는지입니다. 기능 비교표의 모든 항목은 이 세 가지 차이에서 비롯됩니다.

운영 중인 사이트가 단순한 페이지, 이미지, 문의 폼으로 구성되어 있다면 공유 호스팅이 적합하며 비용도 저렴합니다. 하지만 방문자가 없을 때도 계속 실행되어야 하는 프로그램이 필요한 사이트라면 VPS가 필요합니다.

공유 호스팅이 실제로 제공하는 것

하나의 Linux 서버에서 여러 고객 계정을 동시에 운영합니다. 각 계정은 문서 루트, 데이터베이스, 메일함을 포함하는 홈 디렉터리이며, 일반적으로 Apache나 LiteSpeed 같은 단일 웹 서버가 서버 내의 모든 사이트를 서비스합니다. 셸 프롬프트 대신 제어판을 제공받습니다. root 권한은 주어지지 않으므로 패키지를 설치하거나, 포트를 열거나, 백그라운드 서비스를 시작할 수 없습니다.

대부분의 공유 호스팅 업체는 CloudLinux를 운영합니다. 이 운영체제는 각 계정을 별도의 컨테이너에 격리하고 프로세서 사용 시간과 동시에 실행할 수 있는 프로세스 수에 엄격한 제한을 둡니다. 프로세스 제한을 초과한다고 해서 사이트가 느려지는 것이 아닙니다. 서버가 508 Resource Limit Is Reached이라는 오류 페이지를 반환하게 됩니다. 이 페이지는 이웃 사용자가 자원을 점유해서가 아니라, 본인의 계정이 설정된 한계치에 도달했음을 의미합니다.

이러한 거래는 의도된 것입니다. 사용자는 제어권을 포기하는 대신, 호스팅 업체로부터 커널 패치, PHP 업데이트, 인증서 갱신, 매일 밤 수행되는 백업 서비스를 제공받습니다. 대다수의 사이트 운영자에게 이는 합리적인 거래입니다.

VPS가 실제로 제공하는 것

VPS는 호스트 서버에서 실행되는 가상 머신입니다. 대부분의 Linux VPS 플랜에서 사용하는 하이퍼바이저인 KVM 환경에서, 인스턴스는 자체 커널로 부팅하며 고유한 IP 주소, 방화벽, init 시스템을 가집니다. sudo가 작동합니다. apt install가 작동합니다. systemd를 통해 시작한 프로그램은 로그아웃 후에도 계속 실행되며, 충돌 시 재시작되고, 재부팅 후에도 다시 살아납니다.

동일한 root 권한을 가지기 때문에 서버의 보안은 사용자의 책임이 됩니다. 다른 누구도 서버를 감시하지 않습니다. 바로 이러한 이유로 VPS에서 실행하는 서비스의 범위는 매우 넓습니다. 이 서버는 Linux 서버가 할 수 있는 모든 작업을 수행할 수 있기 때문입니다.

차이점 1: root 권한과 그 권한이 제공하는 기능

root 권한은 다른 모든 차이점을 만들어내는 핵심 요소입니다. 이 권한이 있으면 배포판의 모든 패키지를 설치하고, 모든 포트를 바인딩하며, systemd 유닛을 작성하고, 시스템의 모든 로그를 읽으며, sysctl을 통해 커널 설정을 변경할 수 있습니다. 이 권한이 없다면 패널에서 제공하는 목록(PHP 버전 선택기, 고정된 확장 기능 세트, cron 작업을 위한 양식 등)만 사용할 수 있습니다.

VPS에서는 시스템에 어떤 포트가 리스닝 중인지 언제든 확인할 수 있습니다.

ss -ltnp

각 행은 열려 있는 소켓과 해당 소켓을 소유한 프로세스를 나타냅니다. 따라서 시작에 실패한 서비스는 해당 행이 나타나지 않는 것으로 확인할 수 있습니다. 공유 호스팅에서는 이 질문에 대한 답을 얻을 수 없습니다. 80번과 443번 포트는 호스트의 웹 서버가 점유하고 있으며, 사용자가 어떤 설정을 하더라도 이를 가져올 수 없기 때문입니다.

차이점 2: 할당된 메모리와 빌려온 메모리

공유 호스팅은 동시에 활발하게 동작하는 계정이 적을 것이라는 가정하에 판매됩니다. 서버의 메모리는 하나의 풀(pool)로 구성되며, 귀하의 계정에 할당된 몫은 예약된 자원이 아니라 제한치에 가깝습니다. 할당량을 초과하면 PHP 프로세스가 강제 종료되며 방문자는 500 또는 508 오류를 보게 됩니다.

VPS에서는 플랜에 포함된 메모리가 귀하의 인스턴스에 온전히 귀속됩니다. free -m 명령어로 이를 확인할 수 있으며, 가상 머신 외부의 어떤 프로세스도 이 메모리를 가져갈 수 없습니다.

프로세서 시간은 예외적인 경우입니다. 대부분의 VPS 플랜은 물리적 코어를 여러 게스트가 공유하며, 이를 직접 측정할 수 있습니다.

vmstat 1 5

st 열은 steal time을 나타냅니다. 이는 가상 프로세서가 실행 준비를 마쳤음에도 물리적 코어가 다른 게스트에게 할당되어 대기한 시간의 비율입니다. 몇 퍼센트 정도의 일정한 값은 정상입니다. 두 자릿수의 수치가 지속된다면 호스트가 과도하게 할당된 상태이며, 이는 기술 지원 티켓에 근거로 제시할 수 있는 수치입니다. 공유 호스팅에는 이에 대응하는 측정값이 없는데, 이를 보여줄 수 있는 모든 도구는 root 권한을 요구하기 때문입니다. 저장 장치도 같은 방식으로 동작하므로 VPS 플랜의 기반이 되는 디스크 유형이 중요하며, 판매 페이지의 내용을 그대로 믿기보다 첫 주에 새 VPS를 직접 측정해보는 것이 좋습니다.

차이점 3: 장애 발생 시 책임 소재

공유 호스팅 환경에서는 호스트가 운영체제, 웹 서버, PHP 빌드, 인증서, 야간 백업에 대한 관리 권한을 가집니다. 서버가 응답하지 않으면 티켓을 발행하며, 이미 담당자가 문제를 해결하고 있을 것입니다. 이러한 서비스의 대가는 동일한 규칙의 이면과 같습니다. 즉, 호스트가 지원하지 않는 소프트웨어의 설치를 요구할 수 없습니다.

관리되지 않는 VPS 환경에서는 제공자가 하이퍼바이저, 네트워크, 전력 공급만을 책임집니다. 커널부터 그 위의 모든 계층은 사용자의 몫입니다. 보안 업데이트, 방화벽, 백업, 인증서 갱신, 모니터링은 모두 사용자가 직접 수행해야 하며, 고객 지원 팀은 사용자의 웹 서버 설정을 디버깅하기 위해 서버에 접속하지 않습니다. 첫날부터 이를 계획하십시오: 새 VPS에서의 첫 10분, 이어서 이해 가능한 방화벽, 자동 보안 업데이트, 그리고 최소 한 번 이상 복구해 본 백업을 준비해야 합니다.

공유 호스팅이 적절한 선택인 경우

브로슈어 사이트가 가장 명확한 사례입니다. 몇 개의 페이지, 이미지, 문의 양식, 캐싱 플러그인을 사용하는 WordPress 정도가 있고 하루 방문자가 수천 명 수준인 경우입니다. 백그라운드 작업도 없고, 특이한 런타임도 필요하지 않으며, 요청 간에 메모리에 상주해야 할 데이터도 없습니다. 공유 호스팅은 이러한 사이트를 운영하기에 충분하며, 어떤 VPS보다 비용이 저렴하고 유지보수를 전담 인력이 수행합니다. 이를 VPS로 옮기는 것은 얻는 이득은 없으면서 없던 업무만 늘어나는 결과를 초래합니다.

덜 주목받는 두 번째 사례가 있습니다. 팀 내에 로그 파일을 읽거나 apt upgrade을 실행할 사람이 없다면 공유 호스팅이 더 안전한 선택입니다. 보안 패치가 되지 않은 VPS에 데이터베이스 포트가 열려 있는 상황은 전문가가 상시 관리하는 공유 계정보다 훨씬 위험합니다. 제어 권한은 그것을 실제로 사용하는 사람이 있을 때만 장점이 됩니다.

징후 1: 계속 실행되어야 하는 프로그램이 필요한 경우

데몬은 메모리에 상주하며 작업을 대기하는 프로그램입니다. API, 챗봇, 큐 워커, 게임 서버 등이 이에 해당합니다. 공유 호스팅은 요청이 들어올 때만 코드를 실행하며, SSH(secure shell) 세션에서 실행해 둔 프로세스는 계정의 프로세스 제한에 걸려 종료됩니다.

VPS에서는 동일한 프로그램을 systemd 유닛으로 관리합니다.

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status 명령을 실행하면 프로세스 ID와 함께 Active: active (running)가 출력되어야 합니다. 만약 Active: failed (Result: exit-code)이 출력된다면, 프로그램이 종료된 시점의 출력을 보여주는 journalctl -u myapp -n 50에서 원인을 확인할 수 있습니다. 유닛 파일의 Restart=always 설정은 프로그램이 비정상 종료되었을 때 다시 실행하며, enable 설정은 재부팅 후에도 서비스를 자동으로 시작하게 합니다. systemd 서비스 및 타이머 작성하기는 VPS 운영 시 가장 먼저 제대로 익혀야 할 기술입니다.

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

패널은 제한된 목록만을 제공합니다. 애플리케이션이 해당 목록에 없는 언어 버전, 컴파일이 필요한 라이브러리, ffmpeg, 헤드리스 브라우저 또는 MySQL이 아닌 데이터베이스를 요구한다면, 공유 호스팅 환경에서는 이를 설치할 방법이 없습니다. 소프트웨어를 설치하려면 root 권한이 필요하지만, 해당 계정에는 컴파일러나 개발용 헤더 파일이 없으므로 빌드 과정에서 아무런 결과물도 생성하지 못하고 실패하게 됩니다.

VPS를 사용하면 apt install 명령어로 필요한 소프트웨어를 직접 설치하거나, 컨테이너에서 실행하여 호스트 환경을 깨끗하게 유지할 수 있습니다. 애플리케이션의 구성 요소가 하나 이상이라면 VPS에서의 Docker Compose를 사용하는 것이 일반적인 해결책입니다.

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

공유 호스팅은 폼을 통해 cron 작업을 입력받으며, 보통 5분이나 15분과 같은 최소 실행 간격을 설정합니다. 계정의 프로세서 제한을 초과하는 작업은 실행 도중 강제로 종료됩니다. 이때 사용자가 읽을 수 있는 로그에 기록이 남지 않으므로 작업은 조용히 실패합니다.

VPS에서는 crontab -e가 사용자가 작성한 모든 스케줄을 허용하며, systemd timer를 사용하는 것이 훨씬 더 좋습니다.

systemctl list-timers
journalctl -u cron -n 20

list-timers는 모든 타이머의 다음 실행 시간과 마지막 실행 결과를 출력하며, 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년 8월 기준 각 카테고리별 최소 요금제에 대한 일반적인 광고 가격입니다. 이 가격은 확정된 견적이 아니라 대략적인 참고치로 활용하고, 구매 전 현재 가격을 반드시 확인하십시오.

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

표면적인 가격 차이는 월 3 달러에서 5 달러 사이이지만, 이 숫자가 의사결정의 기준이 되어서는 안 됩니다. 공유 호스팅은 보통 1년에서 3년 치 요금을 선납해야 광고된 첫 기간 요금을 적용받으며, 갱신 시에는 12 달러 수준으로 인상됩니다. 갱신 요금을 기준으로 비교하면 상황이 달라집니다. 공유 호스팅 계정의 갱신 요금은 12 달러인 반면, 입문용 VPS는 6 달러입니다.

단, 이 비교에는 주의가 필요합니다. 두 서비스의 사양이 동일하지 않기 때문입니다. 1 vCPU, 1 GB 사양의 VPS는 웹 서버와 데이터베이스를 하나의 작은 서버에서 구동하므로, 실제 트래픽이 발생하기 시작하면 WordPress를 운영하기에 매우 빠듯합니다. 갱신된 공유 호스팅 요금제와 정직하게 비교하려면 약 15 달러 수준인 2 vCPU, 4 GB 사양을 기준으로 삼아야 합니다. 따라서 실제 추가 비용은 몇 배가 아니라 월 몇 달러 수준에 불과합니다.

더 큰 비용은 청구서에 나타나지 않습니다. VPS를 운영하려면 초기 설정에 1시간, 매달 업데이트에 몇 분, 그리고 처음 문제가 발생했을 때 해결하기 위해 저녁 시간을 할애해야 합니다. 이 시간을 본인의 시급으로 환산하면 가격 차이는 금세 좁혀집니다. 실제 VPS 운영 비용에서 사양별 상세 내용을 확인할 수 있습니다.

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

1. 하루 전에 도메인의 DNS(domain name system) TTL(time to live)을 300초로 낮추어, 전환 시 몇 시간이 아닌 몇 분 내로 변경 사항이 적용되도록 합니다.
2. DNS를 건드리기 전에 새 서버를 구축하고 해당 IP 주소에서 사이트가 정상 작동하는지 확인합니다.
3. 파일을 복사한 뒤 데이터베이스를 덤프하여 새 서버에 복원합니다.
4. 노트북의 hosts 파일을 수정하여 해당 도메인이 새 IP를 가리키도록 설정하고, 본인의 컴퓨터에서만 사이트를 테스트합니다.
5. 새 서버에서 TLS(transport layer security) 인증서를 발급받고 A 레코드를 변경한 뒤, 공유 호스팅 계정을 일주일간 유지합니다.

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는 테이블을 잠그지 않고 일관된 스냅샷을 생성하는데, 이는 작업 중에도 기존 사이트에서 주문을 계속 처리해야 할 때 중요합니다. 새 서버에서는 같은 날 인증서 설정을 완료하십시오. Let's Encrypt on Ubuntu with nginx 문서를 참고하면 DNS 레코드가 서버를 가리키는 즉시 몇 분 안에 설정을 마칠 수 있습니다.

책임 없는 리소스

앞서 언급한 4가지 징후가 귀하의 사이트 상황과 일치하지만 유지보수가 부담스럽다면, 중간 선택지로 관리형(managed) VPS가 있습니다. 할당된 메모리와 root 수준의 권한은 그대로 유지하면서, 패치 적용, 모니터링, 그리고 대개 관리 패널까지 제공업체가 담당합니다. 위 차트에서 관리형 VPS의 비용은 약 30 달러이며, 동일한 사양의 비관리형(unmanaged) VPS는 15 달러입니다. 이 비용 차이는 서버가 야간에 응답을 멈췄을 때 대신 대응해 줄 전문가를 고용하는 것과 같습니다.

관리형 VPS와 비관리형 VPS 결정하기는 이러한 상황에 처한 분들이 다음에 읽어야 할 적절한 글입니다. 만약 이미 바쁜 VPS를 운영 중인데 피크 시간대에 steal time 문제가 여전히 심각하다면, 다음 단계는 이웃이 전혀 없는 전용 서버를 고려하는 것입니다.

FAQ

VPS가 공유 호스팅보다 빠른가요?

항상 그렇지는 않습니다. 사용자가 적은 공유 서버가 단일 WordPress 페이지 처리에서 1 vCPU VPS보다 빠를 수 있습니다. VPS가 제공하는 것은 일관성입니다. 플랜에 할당된 메모리는 온전히 귀하의 것이므로, 응답 시간은 같은 장비를 사용하는 다른 사용자의 부하가 아니라 귀하의 코드에 따라 결정됩니다. 오전 3시와 오후 7시 모두 페이지가 느리다면 원인은 귀하의 코드나 데이터베이스 쿼리에 있으며, 같은 코드를 VPS로 옮겨도 문제는 그대로 유지됩니다.

공유 호스팅에서 Node.js나 Python 애플리케이션을 실행할 수 있나요?

제한적인 환경에서만 가능합니다. 일부 제어판은 Passenger를 통해 애플리케이션을 실행하며, 요청이 들어올 때만 동작합니다. 호스트의 웹 서버가 80번과 443번 포트를 점유하고 있으므로 귀하가 직접 포트를 바인딩할 수는 없습니다. 계정의 프로세스 제한으로 인해 장시간 실행되는 프로세스가 종료되므로, 요청 사이마다 워커를 메모리에 상주시키는 것도 불가능합니다. 봇, 큐 워커, 웹소켓 서버를 운영하려면 VPS가 필요합니다.

VPS를 운영하려면 Linux를 알아야 하나요?

관리형이 아닌 VPS라면 그렇습니다. SSH 키, 방화벽, 업데이트, 백업을 관리하고 로그를 확인하는 습관이 필요합니다. 초기 설정에 1시간, 이후 매달 몇 분 정도의 시간을 할애하십시오. 이러한 작업이 부담스럽다면 관리형 플랜을 통해 리소스는 할당받되 유지보수는 제공업체에 맡길 수 있습니다. 이에 관한 내용은 관리형 VPS와 비관리형 VPS 호스팅 비교에서 다룹니다.

공유 호스팅에서 VPS로 이전하는 동안 사이트가 다운되나요?

DNS TTL을 미리 낮추고 두 계정을 모두 유지하면 다운타임 없이 이전할 수 있습니다. 하루 전에 TTL을 300초로 설정하고, 파일과 데이터베이스를 복사한 뒤, 로컬 PC의 hosts 파일을 수정하여 새 서버를 테스트하고 A 레코드를 변경하십시오. 변경 직후 몇 분 동안은 일부 방문자는 이전 서버로, 일부는 새 서버로 접속하게 되므로 공유 호스팅 계정을 일주일 정도 유지하는 것이 좋습니다. 최종 데이터베이스 덤프를 수행하는 동안 사이트를 읽기 전용 모드로 전환하거나, 해당 시간 동안 발생하는 데이터 변경 사항이 유실될 수 있음을 감수해야 합니다.