관리형 VPS vs 비관리형 VPS 차이점과 선택 기준

관리형 VPS와 비관리형 VPS: 요약

관리형 VPS와 비관리형 VPS 중 무엇을 선택할지는 제품의 문제가 아니라 인력 투입의 문제입니다. 비관리형은 패치, 방화벽, 백업, 모니터링, 그리고 새벽 2시의 재부팅까지 모두 직접 관리해야 함을 의미합니다. 관리형은 제공업체가 이 작업의 일부를 대신 수행한다는 뜻인데, 그 범위는 호스트마다 매우 크게 다릅니다. 유일하게 유용한 비교 방법은 각 요금제가 귀하의 업무 중 어떤 항목을 대신 처리해 주는지 목록을 확인하고, 이를 귀하의 시간당 비용과 비교하는 것입니다.

관리형(managed)이라는 단어에는 표준화된 정의가 없습니다. 어떤 호스트는 운영체제 패치와 티켓 응대를 제공한다는 의미로 사용합니다. 다른 호스트는 제어판만 설치해 주고 그 위의 모든 작업은 사용자에게 맡기기도 합니다. 또 다른 곳은 응답 시간이 명시된 서비스 계약을 의미하기도 합니다. 같은 용어를 사용하는 두 요금제라도 중요한 모든 면에서 다를 수 있으므로, 가격을 확인하기 전에 반드시 서비스 범위 문서를 읽어야 합니다. 서버의 용도를 아직 결정하지 못했다면, VPS로 실제로 할 수 있는 일을 먼저 정리하는 것이 더 나은 선택입니다.

관리자가 책임져야 할 작업

운영 중인 모든 서버에는 동일한 작업 목록이 존재합니다. 관리되지 않는 플랜을 사용한다면 이 목록은 모두 사용자의 몫입니다. 관리형 플랜을 사용한다면 비용을 지불하고 이 목록의 항목들을 위임하는 것입니다. 아래 목록을 확인하고 각 항목 옆에 담당자 이름을 기재하십시오.

• 운영체제 패치 및 커널 업데이트 시 필요한 재부팅.
• 서비스 추가 및 제거에 맞춰 정확하게 유지되는 방화벽 규칙. VPS를 위한 ufw 방화벽 기초에서 기본적인 규칙 설정을 다룹니다.
• SSH 접근 관리: 키 처리, 비밀번호 로그인 비활성화, 퇴사자 키 권한 회수, 그리고 잠금 상태가 되었을 때의 복구 경로 확보.
• 백업, 오프사이트 사본 보관, 그리고 실제로 수행해 본 복구 절차.
• 모니터링: 서버 연결 가능 여부, 디스크 여유 공간, 서비스 실행 상태, 인증서 만료 여부 확인.
• 로그 검토 및 로그에서 이상 징후 발견 시 대응.
• 웹 서버, 데이터베이스, 리버스 프록시, 그리고 큐 서비스(사용 시)에 대한 설정.
• 인증서 갱신 및 자동 갱신 실패 시 복구 작업.
• 용량 관리: OOM(Out of Memory) 킬러가 작동하기 전에 메모리 고갈을 미리 인지하는 것.
• 사고 대응: 원치 않는 시간에 깨어 있어야 하며 연락이 가능해야 함.

대부분의 작업은 일상적이며 스크립트로 자동화할 수 있습니다. 하지만 사고 대응은 사람이 직접 판단해야 하므로 자동화가 불가능합니다. 이것이 바로 관리형 플랜이 판매하는 핵심 가치이며, 아래의 체크리스트에서 패치 작업보다 지원 범위에 관한 질문을 더 많이 다루는 이유이기도 합니다.

관리형 서비스에 일반적으로 포함되지 않는 항목

구매자가 가장 많이 피해를 보는 부분이므로 이 내용을 정확히 파악해야 합니다. 관리형 계약은 일반적으로 운영체제와 공급자가 설치한 소프트웨어까지만 보장합니다. 애플리케이션의 경계에서 책임 범위가 끝납니다.

사용자의 코드는 사용자의 책임입니다. 애플리케이션에서 발생하는 500 에러는 서버 결함이 아닙니다. 공급자는 웹 서버 프로세스가 실행 중인지 확인한 뒤 티켓을 반환할 것입니다. 이것이 합리적인 경계입니다. 또한 이는 구매자가 기대하는 바와 실제로 구매한 서비스 사이의 가장 큰 간극이기도 합니다.

애플리케이션 수준의 문제는 일반적으로 지원 범위 밖입니다. 느린 데이터베이스 쿼리, 업데이트 후 깨진 플러그인, 잘못 설정된 캐시, 처리가 중단된 메일 큐 등은 공급자가 그 아래의 소프트웨어를 설치했더라도 지원 범위 위에 존재합니다.

대부분의 데이터 복구는 지원 범위 밖입니다. 공급자의 백업은 전체 서버 이미지를 보호하며, 이는 호스트 하드웨어 장애 발생 시를 대비한 것입니다. 사용자가 행을 삭제했거나, 잘못된 마이그레이션을 실행했거나, 6주 전에 파일을 손상시키고 오늘 발견한 경우를 위해 구축된 것은 아닙니다. 보존 기간이 얼마인지, 단일 파일을 추출할 수 있는지, 복구 작업은 누가 수행하는지 확인하십시오.

사용자가 직접 설치한 소프트웨어는 사용자의 책임입니다. Docker를 설치하면 일반적으로 호스트는 공급자가 관리하지만, 컨테이너 내부의 모든 것은 사용자가 관리합니다.

직접 수정한 설정은 지원을 무효화할 수 있습니다. 일부 계약에서는 고객이 구성 파일을 직접 수정하는 순간 해당 구성 요소가 지원 범위에서 제외됩니다. 무언가를 직접 튜닝할 계획이라면 이 점을 반드시 문의하십시오.

월간 비용 차이와 본인의 시간 가치 비교

두 견적을 비교하여 월간 비용 차이를 계산하십시오. 이 금액은 제공업체가 위 목록의 작업을 대신 처리해 주는 대가입니다. 이제 본인의 입장에서 가치를 산정해 보십시오.

• 본인의 시간당 가치는 얼마이며, 해당 목록의 작업을 자동화했을 때 매달 몇 시간이 절약됩니까?
• 이 서버에서 운영 중인 서비스가 1시간 동안 중단될 때 발생하는 비용은 얼마입니까?

자동 업데이트와 외부 모니터링이 설정된 안정적인 Ubuntu 서버는 일상적인 관리가 거의 필요하지 않습니다. 대부분의 달에는 아무런 작업도 필요하지 않습니다. 스크립트가 작업을 수행하게 되면 일상적인 업무 비용은 저렴해집니다. 비용이 발생하는 부분은 예기치 않은 장애 대응이며, 관리형 플랜은 바로 이 대응 서비스를 판매하는 것입니다. 서버가 취미 프로젝트용이라면 중단 비용이 없으므로 관리되지 않는 서버를 선택하는 것이 당연합니다. 만약 주문을 처리하는 서버라면, 지원 계약이 실제로 장애 시간을 단축하는지 신중하게 검토해야 합니다. 관리형 제공업체도 결국 사용자의 티켓을 읽고, 장애를 재현한 뒤 조치해야 하기 때문입니다.

비용 차이는 서버 대수에 따라서도 달라집니다. 관리형 서비스 비용은 보통 서버당 부과되지만, 자동화는 한 번 작성하면 복사해서 사용할 수 있습니다. 두 번째 서버를 운영하면 첫 번째 서버를 위해 작성한 스크립트의 실질 비용이 절반으로 줄어듭니다. 따라서 서버당 부과되는 비용을 결정하기 전에 여러 대의 Linux 서버를 관리하는 방법을 먼저 읽어 보십시오. 비교의 기준이 되는 기본 수치를 확인하려면 VPS의 실제 월간 비용을 통해 최저가를 파악하고, 워크로드가 커져 관리형 서비스 비용이 오차 범위 내로 들어올 정도가 되면 VPS와 전용 서버의 장단점 비교를 고려하십시오.

관리형 프리미엄 비용을 지불하기 전 호스팅 업체에 확인해야 할 질문

비용을 지불하기 전에 서면으로 답변을 요청하십시오. 판매 페이지는 서비스 범위를 정의하는 문서가 아닙니다.

1. 작업 단위별로 서비스 범위는 어디까지입니까? 브로슈어가 아닌 구체적인 목록을 요청하십시오.
2. 지원 범위에 제가 직접 설치한 소프트웨어도 포함됩니까, 아니면 귀사에서 설치한 소프트웨어만 해당합니까?
3. 패치를 자동으로 수행합니까? 커널 업데이트 시 사전에 동의를 구하지 않고 재부팅을 진행합니까?
4. 귀사가 적용한 패치로 인해 제 애플리케이션에 문제가 발생하면 누가 책임을 집니까?
5. 백업을 수행합니까? 백업 데이터는 어디에 저장되며 보관 기간은 얼마입니까? 또한 복구는 누가 수행합니까?
6. 최근에 고객 서버를 복구한 사례가 있습니까? 복구에 소요된 시간은 얼마입니까?
7. 티켓 응답 시간은 어떻게 됩니까? 일요일 오전 03:00에도 동일한 응답 시간이 보장됩니까?
8. root 권한은 제가 계속 유지합니까? root 권한을 사용하면 지원 범위가 축소됩니까?
9. 요금은 서버당 부과됩니까, 아니면 계정당 부과됩니까?
10. 서비스를 해지할 경우 무엇을 가져갈 수 있습니까? 독점적인 제어 패널 내부에 구축된 환경은 외부로 이전하기 어려울 수 있습니다.

5번 질문은 다른 대부분의 질문에 대한 답을 결정짓습니다. 이 질문에 정확하게 답변하는 업체는 이미 관련 경험이 있다는 뜻입니다. 모호한 답변은 복구 테스트를 한 번도 해본 적이 없다는 의미이며, 테스트되지 않은 백업은 단순한 복사본에 불과합니다. 5번 질문에는 위치에 관한 내용도 포함됩니다. 백업 데이터가 물리적으로 어디에 저장되는지는 기술적인 문제일 뿐만 아니라 법적인 문제이기도 하며, 호스팅 국가를 선택할 때 실제로 중요한 요소에서 이를 자세히 다룹니다.

중간 경로: 비관리형 서버와 자동화의 결합

대다수의 기술 독자는 양극단을 원하지 않습니다. 이들은 비관리형 플랜을 선택하되 반복적인 작업은 기계에 맡기고, 기계가 판단할 수 없는 영역에만 자신의 주의를 기울이기를 원합니다. 첫날에 설정을 완료하십시오. 새로운 VPS에서의 첫 10분은 비관리형 서버를 선택하는 모든 이에게 실질적인 출발점이며, SSH 접근 강화 역시 같은 첫 세션에서 수행해야 합니다.

자동 보안 업데이트

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades
cat /etc/apt/apt.conf.d/20auto-upgrades

이제 해당 파일에는 APT::Periodic::Update-Package-Lists "1";과 APT::Periodic::Unattended-Upgrade "1";가 포함되어 있어야 합니다. 파일이 없거나 두 줄 중 하나라도 0으로 되어 있다면 아무것도 실행되지 않으며, 어떠한 알림도 받을 수 없습니다.

시스템을 변경하지 말고 테스트를 수행하십시오. 패키지 이름은 unattended-upgrades이지만 명령어는 단수형임을 유의하십시오.

sudo unattended-upgrade --dry-run --debug

출력 결과에는 검토 대상인 모든 패키지가 나열되며, 보류 중인 작업이 없을 경우 No packages found that can be upgraded unattended와 같은 줄로 종료됩니다. 실제 실행 기록은 /var/log/unattended-upgrades/unattended-upgrades.log에 기록되므로, 추측하기보다 해당 파일을 확인하십시오.

커널 업데이트는 재부팅 전까지는 아무런 변화를 일으키지 않습니다. 실행 중인 커널은 부팅 시점에 로드된 커널이기 때문입니다. 재부팅이 필요한 상태가 되면 /var/run/reboot-required 파일이 나타납니다. 이 파일을 주시하거나, /etc/apt/apt.conf.d/50unattended-upgrades을 통해 기계가 직접 처리하도록 설정하십시오.

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "false";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Automatic-Reboot-WithUsers "false"는 사용자가 로그인 중일 때는 재부팅을 보류합니다. 대화형으로 사용하는 서버에서는 더 안전하지만, 아무도 로그인하지 않는 서버에서는 무의미합니다. Ubuntu의 전체 자동 업그레이드 설정에서 차단 목록 문법과 이메일 옵션을 다룹니다.

외부에서 실행되는 모니터링

서버 내부에서 실행되는 모니터링 도구는 서버가 다운되면 함께 멈추므로 서버의 장애를 알릴 수 없습니다. 체크 기능을 다른 호스트나 외부 서비스에 두십시오. 상태 모니터링을 위한 Uptime Kuma가 일반적으로 사용되는 자체 호스팅 솔루션이며, 이는 모니터링 대상과는 다른 기계에서 실행되어야 합니다.

최소한 도달 가능성, 디스크 사용량, 애플리케이션이 실제 포트에서 응답하는지 여부, 인증서 만료일 등 네 가지를 모니터링하십시오. 디스크 사용량은 많은 이들이 간과하는 부분입니다. 매일 조금씩 증가하는 로그 파일이나 데이터베이스는 아무도 예상치 못한 순간에 서버를 다운시키며, 첫 증상은 대개 서비스가 데이터를 기록하지 못하고 종료되는 것입니다.

df -h
sudo du -xh --max-depth=1 /var | sort -h
journalctl --disk-usage

하트비트(heartbeat)도 추가하십시오. 서버의 타이머가 백업이나 상태 체크가 성공할 때마다 특정 URL을 호출하게 하고, 해당 호출이 멈추면 모니터링 도구가 경고를 보내도록 합니다. 이렇게 하면 네트워크 경로가 끊겨서 외부에서 상태를 확인할 수 없는 상황에서도, 서버가 스스로 침묵을 감지하여 경고를 생성할 수 있습니다.

최소 한 번은 복원해 본 백업

sudo apt install -y restic
sudo sh -c 'umask 077; printf %s "a-long-random-passphrase" > /root/.restic-pass'
export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
export RESTIC_PASSWORD_FILE=/root/.restic-pass
sudo -E restic init

restic init은 created restic repository <id> at sftp:...을 한 번 출력합니다. 이미 존재하는 저장소에 대해 실행하면 덮어쓰는 대신 실패하게 되는데, 이는 의도한 동작입니다. 해당 암호문(passphrase) 사본을 서버 외부의 안전한 곳에 보관하십시오. 암호문 없이는 저장소를 읽을 수 없으며 복구 방법도 없습니다.

sudo -E restic backup /etc /home /srv
sudo -E restic snapshots
sudo -E restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
sudo -E restic check

restic snapshots를 실행하면 방금 수행한 오늘 날짜의 백업이 나열되어야 합니다. restic check은 저장소 구조를 검증하고 no errors were found를 출력합니다. 이제 대부분의 사람이 건너뛰는 단계를 수행하십시오.

sudo -E restic restore latest --target /tmp/restore-check
ls /tmp/restore-check/etc

예상했던 파일이 있는지 확인하십시오. 지금 확인하는 데 드는 10분이 나중에 큰 문제를 방지합니다. 이제 백업이 사람의 손에 의존하지 않도록 타이머를 설정하십시오. /etc/systemd/system/restic-backup.service를 작성하십시오.

[Unit]
Description=restic backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
Environment=RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/web01
Environment=RESTIC_PASSWORD_FILE=/root/.restic-pass
ExecStart=/usr/bin/restic backup /etc /home /srv
ExecStart=/usr/bin/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

그리고 /etc/systemd/system/restic-backup.timer을 작성하십시오.

[Unit]
Description=Run restic backup daily

[Timer]
OnCalendar=daily
RandomizedDelaySec=30m
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer
sudo systemctl start restic-backup.service
journalctl -u restic-backup.service -n 30 --no-pager
systemctl list-timers restic-backup.timer

list-timers은 다음 실행 시간과 남은 시간을 보여줍니다. 결과가 비어 있다면 타이머 대신 서비스를 활성화한 것이며, 이는 가장 흔한 실수입니다. Persistent=true은 부팅 후 놓친 작업을 실행하므로, 밤새 꺼져 있던 기계도 백업을 수행할 수 있습니다. Restic을 이용한 VPS 백업에서 저장소 구조와 보관 정책을 더 깊이 다루며, systemd 서비스와 타이머에서 유닛 파일을 줄 단위로 설명합니다.

자동화가 해결해주지 않는 것

자동화는 판단력을 대신해주지 않습니다. 02:00에 수행되는 자동 재부팅은 애플리케이션이 정상적으로 복구되는지 여부와 관계없이 진행됩니다. 따라서 모든 서비스가 스스로 시작되는지 확인하고, 깨어 있는 시간에 의도적으로 재부팅을 수행해 보십시오.

systemctl is-enabled nginx docker
sudo reboot

자동 업그레이드는 애플리케이션을 고장 내는 패키지를 설치할 수도 있으며, 파이프라인의 그 무엇도 이를 알지 못합니다. 모니터링 도구가 이를 감지해야 하므로, 업데이트를 자동화한다면 모니터링은 선택이 아닌 필수입니다. 기계는 반복적인 업무를 처리하지만, 사고 대응은 여전히 당신의 몫입니다.

관리형 서비스가 비용을 지불할 가치가 있는 경우

관리형 서비스의 장점을 공정하게 평가해야 합니다. 다음 네 가지 상황에서는 관리형 서비스를 구매하는 것이 합리적입니다.

• 팀 내에 Linux를 운영할 수 있는 인력이 없으며, 채용 계획도 없는 경우.
• 규정 준수 요구 사항에 따라 패치 책임자가 명시되어 있고, 그 책임자가 본인이 될 수 없는 경우.
• 해당 호스팅 업체가 전문으로 하는 기술 스택을 사용하여, 업체 측에서 이미 동일한 장애를 경험해 본 경우.
• 해당 업무를 수행할 인력이 조직에서 가장 몸값이 비싼 직원이며, 그 직원의 1시간 인건비가 관리형 서비스의 월 이용료보다 비싼 경우.

관리형 서비스가 자동으로 더 안전해지는 것은 아닙니다. 관리형 플랜은 관리에 소홀한 개인 소유자보다 패치를 빠르게 적용하며, 이는 분명한 이점입니다. 하지만 관리형 서비스는 종종 제어판을 설치하는데, 이는 로그인 페이지를 포함하고 자체적인 취약점 이력을 가진 거대한 네트워크 노출 애플리케이션입니다. 이는 합리적인 거래일 수 있지만, 여전히 일종의 거래입니다.

결정은 매번 동일한 항목을 검토하는 것으로 귀결됩니다. 10가지 작업을 적고, 각 견적에 따라 누가 각 작업을 담당할지 표시한 다음, 그 차이와 본인의 1시간 업무 가치를 비교하십시오. 이 과정을 수행하는 대부분의 기술 전문가는 결국 비관리형 방식을 선택하고 일상적인 작업은 자동화 도구에 맡기게 됩니다. 이는 단순히 비용을 아끼는 것이 아니라 충분히 정당화할 수 있는 선택입니다.

FAQ

관리형 VPS와 비관리형 VPS의 차이점은 무엇입니까?

비관리형 VPS는 서버 장비만 제공하므로 패치, 방화벽, 백업, 모니터링, 커널 업데이트 후 재부팅 등을 직접 관리해야 합니다. 관리형 VPS는 이러한 작업의 일부, 주로 운영체제 계층과 제공업체가 설치한 소프트웨어 관리를 제공업체에 위임합니다. 정확한 관리 범위는 용어 자체가 아닌 각 제공업체의 정책에 따라 결정되므로, 가격을 비교하기 전에 작업별 범위를 서면으로 확인하십시오.

관리형 VPS를 사용하면 직접 백업할 필요가 없습니까?

아닙니다. 제공업체의 백업은 보통 호스트 장애 시 복구를 위해 서버 전체 이미지를 보호하는 용도입니다. 파일을 실수로 삭제했거나, 잘못된 마이그레이션으로 데이터가 손상되었거나, 몇 주 전 발생한 데이터 손상을 오늘 발견한 경우에는 거의 도움이 되지 않습니다. 스냅샷 보관 기간, 단일 파일 복구 가능 여부, 복구 수행 주체를 확인하십시오. 또한 restic과 같은 도구를 사용하여 오프사이트 백업을 직접 유지하고, restic restore latest --target /tmp/restore-check를 통해 백업이 정상 작동하는지 주기적으로 테스트하십시오.

관리형 VPS가 비관리형보다 더 안전합니까?

그렇지 않습니다. 관리형 플랜은 서버에 접속하지 않는 사용자보다 패치를 빠르게 적용하므로 위험을 실질적으로 줄여줍니다. 하지만 많은 관리형 플랜은 제어판을 함께 설치하는데, 제어판은 자체 로그인 페이지를 가진 외부 노출형 대규모 애플리케이션이며 취약점 이력도 존재합니다. 자동 보안 업데이트, 방화벽 차단, SSH 키 인증을 적용하고 불필요한 서비스를 실행하지 않는 비관리형 서버가 제어판을 실행하는 관리형 서버보다 공격 표면이 더 작을 수 있습니다.

비관리형으로 시작했다가 나중에 관리형으로 전환할 수 있습니까?

대부분 가능하지만, 단순히 설정 하나를 바꾸는 것만큼 간단하지는 않습니다. 제공업체는 책임을 지기 전에 서버를 감사하거나 재구축하는 경우가 많습니다. 직접 구성한 설정을 지원할 수 없기 때문입니다. 온보딩 과정에 무엇이 포함되는지, 재설치가 필요한지, 직접 구성한 설정 중 이후 지원 범위에서 제외되는 항목이 있는지 확인하십시오.

관리형 VPS에서도 root 권한을 유지할 수 있습니까?

대부분의 관리형 VPS 플랜에서는 root 권한을 유지할 수 있지만, root 권한 사용 여부와 지원 범위는 서로 영향을 미칩니다. 일부 제공업체는 사용자가 직접 수정한 구성 요소에 대한 지원을 줄이거나 거부하며, 기술 지원 요청이 복잡해지면 자체 템플릿으로 서버를 초기화하기도 합니다. 설정을 변경하기 전에 관련 규정을 서면으로 확인하고, 구성 파일을 버전 관리 시스템에 저장하여 재구축 시 주말을 허비하지 않고 한 시간 내에 복구할 수 있도록 준비하십시오.