WordPress 호스팅: 실제로 무엇에 돈을 내는가

WordPress 호스팅은 월 3파운드 남짓에서 수백 파운드까지 걸친 가격대로 팔리는데, 그 양 끝에 있는 요금제는 거의 똑같은 말로 자신을 설명합니다. 빠릅니다. 안전합니다. 백업됩니다. 지원됩니다. 구매자가 둘을 구분할 수 있게 해줄 사양, 즉 사이트가 어떤 PHP 브랜치에서 도는지, 그 뒤에 어떤 데이터베이스 엔진이 있는지, 캐시 계층이 몇 개이고 그중 실제로 켜져 있는 것은 무엇인지는 정작 결제를 요구하는 페이지에 대개 없습니다.

그 부재는 상품의 일부입니다. “관리형"은 기술 범주가 아니라 마케팅 범주이며, 이를 정의하는 표준화 기구는 없습니다. 같은 단어를 쓰는 두 업체가 영속 오브젝트 캐시를 돌리는지, 사용자가 쓰던 캐시 플러그인을 계속 써도 되는지, 백업이 그들의 인프라 밖으로 나갈 수 있는지, 애초에 셸을 열 수 있는지에서 서로 다를 수 있습니다.

아래는 그런 페이지가 빼놓는 사양입니다. WordPress가 무엇을 요구하는지, 스택의 어느 부분이 페이지 속도를 움직이는지, 관리형 호스팅이 무엇을 더하고 무엇을 조용히 가져가는지, 그리고 각 등급의 현실적인 월 비용입니다.

WordPress 호스팅으로 실제로 무엇을 사는 걸까요? 네 가지입니다. WordPress가 스스로 공개한 기준을 충족하는 PHP 버전과 데이터베이스 엔진. 직접 설치하고 조율하지 않아도 되는 캐시 계층들. 업데이트, 스테이징, 백업, 방화벽 같은 운영 작업. 그리고 캐시할 수 없는 요청을 감당할 여유 용량입니다. 브로슈어형 사이트는 네 번째가 거의 필요 없습니다. 상점이나 회원제 사이트는 예산의 대부분을 거기에 씁니다.

WordPress 호스팅은 사양이 아니라 범주 이름입니다

한 범주 안의 가격 폭이 바로 증거입니다. 둘 다 관리형 WordPress 호스팅이라고 적힌 요금제가 월 20파운드와 250파운드에 나란히 있을 수 있고, 마케팅 문구는 그 격차를 설명하지 않습니다. 격차를 만드는 것들이 문구에 등장하지 않기 때문입니다.

싼 쪽에서 사는 것은 PHP-FPM 풀과 페이지 캐시와 관리 패널이 올라간 공유 머신의 한 조각입니다. 비싼 쪽에서 사는 것은 격리된 연산 자원, 영속 오브젝트 캐시, 스테이징 환경, 관리형 방화벽, 당신의 오류 로그를 읽어주는 지원 팀, 그리고 코어 업데이트가 템플릿을 깨뜨렸을 때 계약상 책임을 지는 상대입니다.

둘 다 정당한 상품입니다. 문제는 눈앞에 있는 것이 어느 쪽인지 구매자가 볼 수 없다는 점이고, 그래서 결정은 가격과 제휴 수수료 순으로 정렬되는 리뷰 사이트에 맡겨집니다. 결과는 양쪽 방향 모두 예측 가능합니다. 브로슈어형 사이트는 평생 다 못 쓸 150파운드 요금제에 올라앉고, WooCommerce 상점은 첫 번째 바쁜 토요일 결제에서 무너지는 5파운드 요금제에 올라앉습니다.

빠져나가는 길은 등급 이름이 아니라 네 가지 질문으로 사는 것입니다. 어떤 PHP 브랜치인가. 어떤 캐시 계층이 있는가. 캐시할 수 없는 요청을 얼마나 흡수하는가. 그리고 떠날 때 내 데이터는 어떻게 되는가.

WordPress가 서버에 실제로 요구하는 것

WordPress는 요구사항 페이지를 공개하고 있고 그것은 짧으며, 바로 그래서 건너뛰어집니다. 이것을 구매 사양으로 읽으십시오. 여기서 떨어지는 요금제는 성능을 논하기도 전에 탈락이기 때문입니다.

PHP 버전

WordPress 요구사항 페이지는 권장 기준을 “PHP 버전 8.3 이상"이라고 적고 있습니다. 같은 페이지에는 권장 사항보다 더 중요한 경고가 함께 있습니다. WordPress는 “PHP 7.4 이상과 MySQL 5.5.5 이상에서도 계속 동작하지만, 그 버전들은 공식 지원 종료에 도달했으며 사이트를 보안 취약점에 노출시킬 수 있습니다”.

함정 전체가 이 한 문장에 들어 있습니다. WordPress는 오래된 PHP 브랜치에서 부팅을 거부하지 않습니다. 잘 돌고, 겉보기에 멀쩡하며, 몇 년째 보안 수정을 받지 못한 인터프리터 위에 조용히 앉아 있습니다.

데이터베이스

같은 페이지는 “MariaDB 10.11 이상 또는 MySQL 8.0 이상"을 요구합니다. 더 오래된 엔진도 여전히 동작하고, 그래서 그렇게 많은 사이트가 거기 남아 있습니다. WordPress 자체 사용 통계를 보면 보고된 설치 여섯 건 중 약 한 건이 MySQL 5.x 릴리스를 보고하는데, 이는 명시된 하한선보다 한참 아래입니다. MySQL 5.7 하나만으로 보고 사이트의 약 12퍼센트를 차지합니다.

결과는 사이트가 망가진다는 것이 아닙니다. 캐시하기 어려운 작업 부하에 정확히 도움이 되는 엔진 개선을 놓치고, 어차피 언젠가는 해야 할 마이그레이션을 떠안는다는 것입니다.

HTTPS와 확장 모듈

HTTPS는 권장이 아니라 “모든 설치에 필수"로 적혀 있습니다. 2026년에도 인증서를 유료 옵션으로 취급하는 호스트는 요금제의 나머지 부분에 대해서도 뭔가를 말해주고 있는 셈입니다.

그 밖에 WordPress 호스팅 핸드북은 json과 mysqli를 필수로, curl, dom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, xml, zip을 강력 권장으로 지정합니다. 영업 담당에게 이름을 대볼 만한 것이 둘 있습니다. zip이 없으면 플러그인과 코어 업데이트 패키지를 풀 수 없습니다. imagick이 없으면 미디어 업로드가 더 약한 이미지 라이브러리로 내려가고, 누군가 최적화 플러그인을 손대기도 전에 이미지 품질이 떨어집니다.

PHP 버전은 청구서에서 지렛대가 가장 큰 한 줄입니다

호스트가 통제하는 모든 것 가운데 PHP 브랜치는 효과 대비 수고의 비율이 가장 좋습니다. 대부분의 패널에서는 드롭다운 하나입니다. 아무것도 다시 만들지 않고, 아무것도 옮기지 않으며, 원래 호환되던 사이트는 그저 더 빠르고 더 잘 지원되는 인터프리터 위에서 돌기 시작합니다.

그것이 몇 년째 그대로인 이유는 기술이 아니라 조직입니다. 아무도 소유하지 않습니다. 사이트를 만든 업체는 이미 떠났고, 호스트는 방치된 플러그인의 치명적 오류가 자기 책임이 되므로 일방적으로 바꾸지 않으며, 사업 쪽은 한 번도 본 적 없는 숫자를 떠올릴 이유가 없습니다.

그래서 후보 호스트에게 던질 첫 질문은 속도가 아닙니다. 이 요금제가 기본으로 어떤 PHP 브랜치를 돌리는지, 어떤 브랜치들을 제공하는지, 그리고 티켓을 열지 않고 직접 바꿀 수 있는지입니다. WordPress가 더는 권장하지 않는 브랜치만 제공하는 호스트는 나머지 모든 질문에도 동시에 답한 것입니다.

운영 서버에서 바로 바꾸지 말고 스테이징에서 시험하십시오. PHP 7.4에서 8.3으로 옮기는 사이트는 대개 관리되지 않는 플러그인에서 두세 개의 지원 중단 알림을 띄우고, 그것이 진짜 비용입니다. 반나절에서 하루 정도의 개발 공수를 잡아두십시오. 자세한 내용은 WordPress 개발자 요율과 물어봐야 할 것에서 다룹니다.

PHP 논쟁의 보안 쪽 절반

사람들이 PHP를 올리는 이유로 대는 것은 성능입니다. 정작 중요한 이유는 보안이고, 이쪽은 논쟁이 아니라 측정의 대상입니다.

PHP는 지원 버전 일정을 직접 공개합니다. 각 브랜치는 2년의 적극 지원을 받고, 이어서 2년 동안 보안 수정만 받습니다. 2026년 9월 기준으로 PHP 8.2는 2026년 12월 31일까지 보안 수정만 제공되고, PHP 8.3은 적극 지원이 2025년 12월 31일에 끝난 뒤 2027년 12월 31일까지 보안 수정만 제공됩니다. PHP 8.4는 2026년 12월 31일까지 적극 지원되고 보안 수정은 2028년 12월 31일까지이며, PHP 8.5는 적극 지원이 2027년 12월 31일까지, 보안 수정이 2029년 12월 31일까지입니다. 그보다 오래된 것은 끝났습니다. PHP 8.1은 2025년 12월 31일, PHP 8.0은 2023년 11월 26일, PHP 7.4는 2022년 11월 28일에 종료되었습니다.

이것을 WordPress 사이트가 실제로 돌리는 것과 나란히 놓아보십시오. WordPress 통계 페이지는 설치의 약 38.8퍼센트가 완전히 지원 종료된 브랜치 위에 있고, 약 23.2퍼센트가 여전히 PHP 7.4 이하라고 보고합니다. WordPress가 권장하는 PHP 8.3 기준을 충족하는 것은 약 36.4퍼센트뿐이고, 여기에 더해 24.8퍼센트는 올해 말 보안 지원이 끝나는 PHP 8.2 위에 있습니다.

즉 WordPress 사이트의 과반이 보안 수정을 받지 못하거나 몇 달 뒤 그 상태가 되는 인터프리터에서 돌아가고 있으며, 거의 모든 경우 그것은 아무도 들여다본 적 없는 호스팅 설정 하나입니다. 바로잡는 비용은 플러그인 라이선스보다 싸고, 그래서 우리 WordPress 보안 강화 체크리스트는 이것을 1단계로 둡니다.

요청이 만나는 순서로 본 캐시 계층

호스트가 내세우는 성능 주장은 거의 전부 캐시에 관한 주장이고, 거의 모든 구매자는 그것을 구분 없는 하나의 약속으로 듣습니다. 계층은 네 개이고 순서가 고정되어 있으며, 저마다 다른 종류의 일을 덜어냅니다. 아래 순서는 하나의 요청이 통과하는 순서이고, 앞선 계층이 답한 요청은 뒤쪽 계층에 결코 닿지 않습니다.

엣지, 즉 CDN 캐시

요청이 가장 먼저 만나는 것은 당신의 서버 바깥, 방문자와 가까운 접속 지점 네트워크에 있는 캐시입니다. 응답이 이미 거기에 저장되어 있다면 호스트는 그 요청을 아예 보지 못합니다.

이 계층은 연산뿐 아니라 네트워크 거리도 아낍니다. 맨체스터의 방문자가 런던의 엣지 노드에 닿으면 대서양을 왕복하지 않아도 됩니다. 정적 자산에는 사실상 공짜이고 언제나 둘 만한 가치가 있습니다. HTML에는 강력하지만 조건부입니다. 어떤 응답이 개인적인 것이어서 절대 공유하면 안 되는지를 엣지에 알려주어야 하기 때문입니다.

전체 페이지 캐시

두 번째 계층은 완성된 HTML을 저장해 PHP와 데이터베이스가 다시 돌지 않게 합니다. WordPress 호스팅 핸드북은 NGINX나 Varnish 같은 리버스 프록시를 권하며 그것이 “출력을 서버 메모리나 하드디스크에 직접 저장한다"고 설명하고, 이 계층이 작동하는지 여부를 결정하는 규칙을 덧붙입니다. “로그인한 사용자는 모두 캐시에서 제외하는 것이 좋다. 그들은 개인화된 콘텐츠를 보아야 하기 때문이다.”

값싼 호스팅을 돋보이게 하는 것이 바로 이 계층입니다. 제대로 작동할 때 방문자에게는 파일이 전달되고, PHP 버전과 데이터베이스 엔진과 플러그인 개수는 그 요청에 관한 한 의미를 잃습니다. 어느 것도 실행되지 않기 때문입니다.

오브젝트 캐시

세 번째 계층은 개별 데이터베이스 질의의 결과와 계산된 값을 캐시합니다. WordPress는 이것을 기본으로 갖추고 있지만 영속적이지는 않습니다. WP_Object_Cache 문서는 분명하게 말합니다. “기본적으로 오브젝트 캐시는 비영속적이다. 이는 캐시에 저장된 데이터가 메모리에만, 그리고 해당 요청이 지속되는 동안에만 존재한다는 뜻이다.”

영속화한다는 것은 드롭인을 통해 Redis나 Memcached를 뒤에 두는 것이고, 이는 페이지가 열릴 때마다 다시 만들어지던 캐시를 요청과 방문자를 가로질러 공유되는 캐시로 바꿉니다. 페이지 전체를 캐시할 수 없게 된 순간부터 중요해지는 계층이며, 값싼 요금제에서 가장 자주 빠져 있는 계층이기도 합니다.

옵코드 캐시

네 번째 계층은 OPcache로, PHP 파일을 컴파일한 바이트코드를 공유 메모리에 담아 인터프리터가 요청마다 다시 파싱하고 컴파일하지 않도록 합니다. 핸드북은 “운영 환경의 WordPress에서는 웹 요청에 대해 OPcache를 활성화하고 사이트나 호스팅 플랫폼 규모에 맞게 크기를 설정할 것을 권장한다"고 밝힙니다.

여기에는 배포상의 결과가 따릅니다. OPcache는 컴파일된 코드를 들고 있으므로, 배포할 때마다 그것을 초기화하거나 변경된 파일을 무효화하지 않으면 서버는 이전 버전을 계속 돌립니다. OPcache가 어떻게 무효화되는지 답하지 못하는 호스트는 플러그인을 업데이트해도 몇 분 동안 아무 일도 일어나지 않는 것처럼 보이는 호스트입니다.

브로슈어형 사이트가 거의 어떤 호스트에서도 빠른 이유

이 네 계층을 따라가면 호스팅 업계에는 불편한 결론이 나옵니다. 모든 방문자가 익명이고 모든 페이지가 캐시 가능하다면 전체 페이지 캐시가 트래픽의 거의 전부에 답하고, 그 뒤에 있는 기계의 사양은 거의 드러나지 않습니다.

그래서 쓸 만한 페이지 캐시를 갖춘 4파운드 요금제의 다섯 쪽짜리 회사 사이트가, 200파운드 요금제 위의 비대한 사이트보다 더 나은 서버 응답 시간을 낼 수 있습니다. 싼 쪽은 파일을 내주고 있고, 비싼 쪽은 PHP를 돌리고 있습니다.

지켜볼 숫자는 첫 바이트까지의 시간이고, 이것 자체는 코어 웹 바이탈이 아닙니다. Google의 Web Vitals 개요는 이를 보조 지표로 분류하며, 느린 서버 응답이 일으킨 “LCP 문제를 진단하는 데” 유용하다고 봅니다. 그것이 정확히 호스트가 통제하는 페이지 속도의 한 조각입니다.

WordPress도 이에 충분히 동의해서 코어에 써넣었습니다. WordPress 6.1에 추가된 사이트 상태의 전체 페이지 캐시 검사는 “사이트가 전체 페이지 캐시 솔루션을 쓰고 있는지, 그리고 응답 시간이 허용 범위인지"를 확인하며 기본 임계값은 600밀리초입니다. 페이지 캐시가 켜져 있다는데도 그보다 높다면 캐시가 작동하지 않는 것이고, CPU를 더 붙여도 가려지지 않습니다.

그러므로 브로슈어형 사이트에게 호스팅 업그레이드는 대개 잘못된 구매입니다. 느리게 만드는 것은 오히려 지나치게 큰 히어로 이미지, 수백 킬로바이트의 CSS를 보내는 페이지 빌더, 여섯 가지 글꼴 굵기이며, 이는 Elementor와 맞춤 테마 비교에서 정리한 논지입니다.

로그인 트래픽과 WooCommerce가 모델을 깨뜨립니다

위의 모든 이야기는 페이지 캐시가 답할 수 있다는 전제 위에 있습니다. 방문자가 로그인하는 순간 그 전제는 무너지고 호스팅의 경제학도 뒤집힙니다.

WooCommerce는 이를 직접 문서화합니다. 캐시 지침은 장바구니, 내 계정, 결제 페이지를 페이지 캐시에서 제외하라고 지시하는데, 그 페이지들은 “현재 고객과 그 장바구니에 고유한 정보를 표시하므로 동적으로 유지되어야” 하기 때문입니다. 또한 캐시를 우회해야 하는 쿠키로 woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_을 열거하고, 데이터베이스 캐싱에서는 _wc_session_을 제외하라고 권합니다.

이를 호스팅 사양으로 읽으면 아주 노골적인 말이 됩니다. 상점에서 매출을 만드는 페이지는 바로 페이지 캐시가 건드릴 수 없는 페이지입니다. 카탈로그와 상품 페이지는 익명 방문자에게 캐시할 수 있습니다. 장바구니와 결제는 누구에게도, 결코 안 됩니다.

회원제 사이트, 학습 플랫폼, 포럼, 고객 포털이 있는 모든 사이트도 마찬가지입니다. 세션 쿠키가 한 번 설정되면 대부분의 캐시 플러그인은 그 방문자에게 캐시된 HTML을 아예 내주지 않으므로, 클릭할 때마다 PHP가 돌고 데이터베이스가 두들겨 맞습니다. 여기서 오브젝트 캐시는 최적화가 아니라 구조재가 되고, 값싼 요금제는 어떤 합성 첫 페이지 테스트로도 드러나지 않는 방식으로 아픕니다. 자세한 내용은 WooCommerce 상점이 느린 이유에 있습니다.

관리형 WordPress 호스팅에 실제로 포함되는 것

형용사를 벗겨내면 관리형 호스팅은 꽤 일관된 운영 작업의 묶음으로 정리됩니다. 그 작업의 값을 정직하게 매겨볼 가치가 있습니다. 기술 인력이 없는 사업체에게는 직접 하는 것보다 사는 편이 싼 경우가 많기 때문입니다.

업데이트

관리형 요금제는 대개 코어 업데이트를 자동으로 적용하고, 때로는 플러그인 업데이트까지 맡으며, 가끔은 전후로 시각적 회귀 검사를 붙이기도 합니다. 여기서 알아두면 쓸모 있는 것은 WordPress가 이미 무료로 하고 있는 범위입니다.

WordPress는 여러 해 전부터 마이너 코어 릴리스와 번역 파일을 기본으로 자동 업데이트해왔고, 5.6부터는 새 설치에서 자동 업데이트가 켜져 있어 버전 관리 체크아웃이 감지되지 않는 한 마이너와 메이저 코어 릴리스 모두가 대상입니다. 기존 설치는 예전 동작을 유지합니다. 그러므로 돈을 내는 부분은 코어 마이너 업데이트가 아닙니다. 플러그인 업데이트, 그중 하나가 깨졌을 때의 롤백, 그리고 깨졌다는 것을 알아채는 사람입니다.

스테이징과 백업

원클릭 스테이징 환경은 정말로 가치 있고, 직접 만들기에는 정말로 성가십니다. 있느냐 없느냐가 아니라 두 가지 세부로 판단하십시오. 스테이징을 운영으로 되밀 때 라이브 데이터베이스를 덮어쓰는지, 그렇다면 복사 이후 들어온 주문과 댓글은 버려집니다. 그리고 스테이징 사이트가 검색 엔진에서 차단되고 메일 발송도 막혀 있는지입니다.

방화벽과 악성코드 검사

대부분의 관리형 요금제는 엣지의 웹 애플리케이션 방화벽과 어떤 형태의 악성코드 검사를 포함합니다. 방화벽은 실제 가치가 있습니다. 네트워크 계층의 가상 패치가 플러그인 취약점 공개와 당신의 업데이트 사이의 시간을 벌어주기 때문입니다.

검사는 들리는 것보다 약합니다. 대개 알려진 악성 파일 서명을 탐지하므로 흔한 감염은 잡고 표적형은 놓칩니다. 자물쇠가 아니라 화재경보기로 취급하고, 강화 작업은 당신 쪽에 남겨두십시오.

관리형 호스팅이 가져가는 것

제약은 아무도 읽지 않는 절반이고, 대개 기능보다 결과가 큽니다. 제약에는 방어할 만한 이유가 있지만, 그 이유는 당신 것이 아니라 제공자의 것입니다.

공개된 가장 명확한 예는 WP Engine의 금지 플러그인 목록으로, 개별 문제아가 아니라 범주 전체를 금지합니다. 캐시 플러그인은 “우리 플랫폼에 내장된 캐시 구조와 충돌할 수 있다"는 이유로 금지됩니다. 백업 플러그인은 “사이트를 쓸데없이 무겁게 만든다"는 근거로 금지됩니다. 관련 글 플러그인은 “데이터베이스를 극도로 많이 쓴다"며 금지됩니다. 알려진 취약점이 있는 플러그인은 아예 금지되고, 플랫폼 기능과 겹치는 플러그인도 마찬가지입니다.

하나하나는 모두 합당한 엔지니어링 판단입니다. 그러나 합쳐놓고 보면, 당신의 사이트가 생각했던 만큼 이식 가능하지 않다는 뜻이 됩니다. 구축물이 특정 캐시 플러그인의 설정에 의존한다면, 그 설정은 당신을 따라 움직이지 않습니다.

셸 접근은 흔히 빠지는 또 다른 항목입니다. 상당수 관리형 요금제는 SSH를 전혀 제공하지 않거나 WP-CLI가 없는 제한된 셸만 주며, 그러면 도메인 변경 뒤의 일괄 찾아 바꾸기 같은 일상 작업이 지원 티켓으로 바뀝니다. 두 가지가 더 사람들을 걸려 넘어지게 합니다. 오래 도는 프로세스에는 흔히 상한이 걸려 있어 상품 50,000건을 가져오려면 잘게 나눠야 하고, 발신 메일은 침해된 사이트가 스팸에 쓰일 것이라는 전제로 차단되거나 속도 제한되는 일이 잦습니다.

시험을 견디지 못하는 성능 주장

호스팅 마케팅은 무엇을 측정했는지 묻는 순간 무너지는 소수의 주장 위에 굴러갑니다.

“20배 빠름"은 기준점을 거의 밝히지 않습니다. 무엇보다 빠른가, 어느 페이지에서, 어떤 플러그인 구성으로, 어느 정도 동시성에서? 이 넷이 없으면 그 숫자는 이름 없는 두 양의 비율일 뿐입니다.

“무제한 대역폭"은 같은 표 안에서 월간 방문 허용치 옆에 앉아 있습니다. 애초에 WordPress 사이트의 병목이 대역폭인 경우는 드뭅니다. 병목은 동시 PHP 실행이고, 요금제는 대개 그것을 아예 언급하지 않습니다.

“가동률 99.9퍼센트"는 절대적으로 들리지만 그렇지 않습니다. 30일 한 달이면 약 43분의 다운타임을 허용합니다. 9가 셋인 것은 공유 호스팅에서 평범한 수치이고, 9가 넷이면 한 달에 약 4분이며, 그 차이는 불편과 아무도 눈치채지 못하는 장애 사이의 차이입니다. 지키지 못했을 때 그 크레딧이 실제로 얼마를 지급하는지 읽으십시오. 이 주제는 의미 있는 가동률 SLA에서 따로 다뤘습니다.

마지막 주장이 가장 흔하고 가장 오해를 부릅니다. 캐시된 첫 페이지에서 찍은 속도 측정 스크린샷입니다. 그것이 재는 것은 페이지 캐시이지 호스트가 아니며, 페이지 캐시야말로 어디서나 대체로 비슷한 부품입니다.

호스트를 제대로 시험하는 법

호스팅 시험은 어렵지 않지만, 서버를 실제로 일하게 만드는 경로에서 해야 합니다. 순서대로 다섯 단계입니다.

첫째, 캐시되지 않는 경로를 시험하십시오. 고유한 질의 문자열을 붙여 페이지 캐시를 뚫거나, 장바구니나 계정 페이지처럼 절대 캐시되지 않는 페이지를 요청하십시오. PHP를 돌리는 요청을 만들 수 없다면 당신이 재고 있는 것은 파일 서버입니다.

둘째, 반복하십시오. 한 번의 요청은 편차에 대해 아무것도 말해주지 않고, 편차야말로 값싼 호스팅의 정체가 드러나는 곳입니다. 최소 20회 표본을 잡고 Google이 필드 데이터에 쓰는 통계치인 75백분위수를 읽으십시오.

셋째, 방문자가 있는 곳에서 시험하십시오. 서버 옆 데이터센터에서 잰 응답은 리즈에 있는 고객이 받는 응답이 아닙니다.

넷째, 동시성 아래에서 시험하십시오. 캐시할 수 없는 요청을 10개나 20개 동시에 보내십시오. PHP 워커 고갈을 드러내는 유일한 시험이 이것이고, 워커 고갈이야말로 판촉 기간에 상점을 쓰러뜨리는 것입니다.

다섯째, 같은 조건끼리 비교하십시오. 같은 PHP 브랜치, 같은 플러그인 구성, 같은 테마, 같은 콘텐츠 분량입니다. 호스트를 바꾸면서 동시에 플러그인 스택까지 바꾼 마이그레이션은 둘 중 어느 것에 대해서도 아무것도 증명하지 못합니다. 후보 호스트가 아니라 실제 사이트를 대상으로 이것을 돌리고 싶다면, 그것이 바로 WordPress 성능 감사가 하는 일입니다.

호스팅이 실제로 움직이는 코어 웹 바이탈은 무엇인가

코어 웹 바이탈은 호스팅 주장과 검색 순위가 뒤섞이기 쉬운 자리이므로, 서버가 어떤 지표에 영향을 줄 수 있는지 정확히 해둘 가치가 있습니다.

지표는 셋이고 페이지 로드의 75백분위수에서 평가되며 모바일과 데스크톱으로 나뉩니다. Largest Contentful Paint는 로딩을 재고 2.5초 이하이면 양호, 2.5초에서 4.0초 사이는 개선 필요, 4.0초를 넘으면 나쁨입니다. Interaction to Next Paint는 응답성을 재고 200밀리초 이하이면 양호, 500밀리초까지는 개선 필요, 그 위는 나쁨입니다. Cumulative Layout Shift는 시각적 안정성을 재고 0.1 이하이면 양호, 0.25까지는 개선 필요, 그 위는 나쁨입니다. First Input Delay는 폐기되고 INP로 대체되었으며, INP는 2024년에 정식 코어 웹 바이탈이 되었습니다.

호스팅이 직접 움직이는 것은 그중 하나뿐입니다. 서버 응답 시간은 LCP의 일부이므로, 거기서 400밀리초를 깎는 호스트는 모든 방문자의 LCP에서 400밀리초를 깎습니다. 느린 호스트에서는 그것이 통과와 실패의 차이가 될 수 있습니다.

CLS에는 거의 아무 일도 하지 못합니다. 그것은 크기가 없는 이미지와 늦게 불려오는 글꼴에서 나옵니다. INP에도 아주 조금밖에 못 합니다. 그것은 메인 스레드의 JavaScript가 지배합니다. 규칙은 이렇습니다. LCP가 나쁘고 캐시되지 않은 서버 응답이 WordPress가 표시하는 600밀리초 선 위에 있다면 호스팅이 문제의 일부입니다. 응답이 여유로운데도 LCP가 여전히 나쁘다면 잘못은 페이지 안에 있고, 우리 2026년 코어 웹 바이탈 통과 방법 안내서가 예산을 쓸 더 나은 자리입니다.

백업, 그리고 아무도 확인하지 않는 부분

가장 싼 요금제를 빼면 모든 요금제가 백업을 광고합니다. 그런데 그 백업이 값어치가 있는지를 결정하는 질문은 사는 사람 가운데 거의 아무도 하지 않습니다.

누군가 한 번이라도 복원해본 적이 있는가

NCSC는 소규모 조직 안내에서 분명히 말합니다. 백업을 만들었다면 “그것을 어떻게 복원하는지 아는 것, 그리고 중요한 데이터가 모두 담겨 있는지 확인하는 것이 중요합니다”. 시험해보지 않은 백업은 통제가 아니라 믿음입니다.

복원을 어떻게 시작하는지, 당신 규모의 사이트라면 얼마나 걸리는지, 데이터베이스를 복원하면 업로드 디렉터리도 함께 복원되는지 제공자에게 물어보십시오. 그런 다음 필요해지기 전에 스테이징에서 한 번 해보십시오. 찾아야 할 실패 양상은 파일은 돌아오는데 데이터베이스는 오지 않는 복원, 또는 성공한 듯 보이면서 복사 이후 만들어진 모든 것을 조용히 잃는 복원입니다.

보관 기간과 주기

7일 보관의 일일 백업은 WordPress 사이트가 실제로 어떻게 망가지는지 생각해보기 전까지는 넉넉해 보입니다. 훼손된 사이트는 몇 시간 안에 발견됩니다. 오래된 글에 조용히 스팸 링크를 심는 침해는 몇 주 뒤에야 발견되고, 그때쯤이면 남아 있는 모든 사본에 그 주입이 들어 있습니다.

상업적인 것이라면 30일이 더 쓸모 있는 하한이고, 별도의 월간 사본은 값싼 보험입니다. 상점은 여기에 더해 주문량에 맞춘 데이터베이스 백업 주기가 필요합니다. 네 시간치 주문을 잃는 것은 네 시간치 블로그 편집을 잃는 것과 같은 부류의 문제가 아니기 때문입니다.

사본이 어디에 어떤 형식으로 있는가

NCSC의 다른 요점은 살아 있는 시스템에 붙어 있는 백업은 분리된 것이 아니라는 것입니다. 백업을 담은 장치는 “쓰지 않을 때는 기기에 연결된 채로 두면 안 됩니다”. 원본을 침해하는 것은 거기에도 닿을 수 있기 때문입니다. 호스팅에 적용하면, 같은 계정에 저장되고 같은 패널로만 복원되는 백업은 그것이 지키려는 대상과 운명을 함께합니다.

형식은 같은 문제의 더 미묘한 판본입니다. 백업을 읽는 유일한 방법이 제공자의 복원 버튼이라면, 당신이 가진 것은 이식 가능한 사본이 아니라 편의 기능입니다. 판별 기준은 오늘 당장 순수한 SQL 덤프와 파일 아카이브를 내려받아 유능한 개발자가 다른 어디에서든 띄울 수 있는지입니다. 그렇지 않다면 마이그레이션은 기술적 결정이기를 그만두고 협상이 됩니다.

데이터가 어디에 놓이는가, 그리고 영국 구매자에게 왜 중요한가

호스팅 결정은 곧 데이터 보호 결정이고, 영국 사업체에게 질문은 회사가 어디에 등록되어 있는가가 아니라 개인정보가 어디에 놓이고 누가 닿을 수 있는가입니다.

ICO의 국제 이전 안내는 세 단계 판정을 제시합니다. 당신의 처리에 영국 GDPR이 적용되고, 이전을 시작하는 쪽이 당신이며, 받는 조직이 별개의 법인이라면 그것은 제한된 이전입니다. ICO는 규칙이 “작고 드문 것까지 포함해 모든 제한된 이전에 적용된다"고 명시하며, “개인사업자와 자영업자를 포함해” 개인정보를 다루는 모든 조직을 대상으로 한다고 밝힙니다.

무엇이 이전에 해당하는지도 눈여겨보십시오. ICO는 개인정보를 보내는 것뿐 아니라 영국 밖 조직이 그것에 “접근할 수 있게 하는 것"까지 포함합니다. 당신의 관리 화면에 들어올 수 있는 해외 지원 팀도, 다른 지역으로 복제된 오프사이트 백업도 각각 이 정의를 충족할 수 있습니다.

모든 제한된 이전은 셋 중 하나로 덮여야 합니다. 목적지에 대한 영국의 적정성 규정, 국제 데이터 이전 계약이나 부속서 또는 구속적 기업규칙 같은 적절한 안전조치, 아니면 예외입니다. 안전조치에 의존한다면 ICO는 이전 이후에도 보호 수준이 실질적으로 낮아지지 않음을 보이는 이전 위험 평가도 요구합니다. 이 가운데 무엇도 해외 호스트를 못 쓰게 만들지는 않습니다. 다만 문서화가 필요한 결정으로 만들 뿐이고, 문서화는 이전한 뒤나 정보주체 열람 요구가 진행되는 중보다 이전하기 전이 훨씬 쌉니다.

처리자 계약에 무엇이 있어야 하는가

호스트는 처리자이고 당신은 컨트롤러이므로 서면 계약은 선택 사항이 아닙니다. ICO는 계약에 포함되어야 하는 것을 열거하는데, 그중 넷은 곧바로 호스팅 질문으로 읽힙니다.

첫째는 하위 처리자입니다. GDPR Article 28(3)(d)에 따라 처리자는 당신의 승인 없이 다른 처리자를 쓸 수 없고, 예정된 변경을 알려 이의를 제기할 수 있게 해야 하며, 사슬 아래쪽에도 동등한 의무를 부과해야 합니다. 호스팅으로 옮기면 CDN, 백업 저장처, 메일 릴레이, 그리고 기반 클라우드 사업자입니다. 목록을 요구하십시오.

둘째는 보안입니다. GDPR Article 28(3)(c)는 Article 32를 충족하는 조치를 요구하고, ICO는 그 내용을 이렇게 풀어놓습니다. 암호화와 가명처리, 처리 시스템의 복원력, “사고 발생 시 개인정보에 대한 접근을 복구할 수 있는 능력”, 그리고 “조치의 효과성을 정기적으로 시험하고 평가하는 절차"입니다. 이는 복원 시험이 모범 사례 글이 아니라 법에 적혀 있다는 뜻입니다.

셋째는 출구입니다. GDPR Article 28(3)(g)에 따라 처리자는 계약이 끝날 때 당신의 선택에 따라 모든 개인정보를 삭제하거나 반환하고 기존 사본을 삭제해야 합니다. 백업이 자기 플랫폼을 떠날 수 없는 제공자는 실무적 문제뿐 아니라 계약상 문제도 안고 있습니다. 넷째는 감사이고, GDPR Article 28(3)(h)에 따라 당신은 준수를 입증하는 데 필요한 정보와 그들의 인증 및 보고서를 받을 권리가 있습니다.

등급, 그리고 영국에서의 비용

네 개의 등급이 거의 모든 WordPress 사이트를 덮고, 등급 사이의 경계는 트래픽이 아니라 캐시할 수 없는 부하가 정합니다. 아래 구간은 영국 구매자가 월에 대체로 내는 금액입니다. 특정 업체의 가격표가 아니라 범주 구간이므로, 견적 자체가 아니라 견적의 타당성을 재는 잣대로 쓰십시오.

공유 호스팅, 월 3파운드에서 15파운드

캐시 가능한 브로슈어형 사이트에는 더할 나위 없고, 누군가 로그인하는 순간 정말로 나쁜 값이 됩니다. 보이지 않는 이웃과 PHP 용량을 나눠 쓰므로 무는 것은 평균이 아니라 부하 아래의 편차입니다. PHP 브랜치를 먼저 확인하십시오. 지원 종료된 인터프리터가 몰려 있는 곳이 이 등급이기 때문입니다.

관리형 WordPress, 월 20파운드에서 400파운드

콘텐츠 사이트와 소규모 상점에는 올바른 기본값입니다. 업데이트, 스테이징, 방화벽, 영속 오브젝트 캐시, 지원 팀을 사는 것이고, 그 대가로 위의 제약을 받습니다. 20파운드에서 100파운드 구간은 트래픽이 보통인 단일 사이트를 감당합니다. 그 위로는 대개 사이트 수, 방문 수, PHP 워커 수를 더 사는 것입니다.

VPS 또는 직접 구성한 클라우드, 15파운드에서 120파운드에 관리비 별도

적당한 클라우드 인스턴스는 월 15파운드에서 120파운드지만, 싼 쪽은 머신입니다. 누군가 운영체제에 패치를 하고, 리버스 프록시를 조율하고, 오브젝트 캐시를 운영하고, 백업을 다뤄야 하며, 그것을 사오면 월 150파운드에서 600파운드가 더 듭니다. 캐시할 수 없는 부하가 실제로 있을 때, 또는 스택에 관리형 플랫폼이 금지하는 요구가 있을 때 값어치를 합니다.

맞춤 인프라, 월 400파운드 이상

다중 지역 배포, 높은 동시성이 오는 행사, 엄격한 데이터 소재지 요구, 또는 WordPress가 여러 구성요소 가운데 하나일 뿐인 아키텍처입니다. 호스팅은 상품 선택이기를 그만두고 구축의 일부가 되며, 그것이 우리가 웹사이트 개발 프로젝트 안에서 이를 다루는 방식입니다.

페이지뷰가 아니라 캐시할 수 없는 요청으로 규모를 잡기

호스팅 요금제가 월간 방문 수로 팔리는 것은 그것이 구매자에게 익숙한 숫자이기 때문입니다. 용량 계획에는 거의 쓸모가 없습니다. 캐시된 익명 페이지뷰 10만 회는 거의 비용이 들지 않고, 로그인 상태의 1만 회는 작은 서버를 포화시킬 수 있기 때문입니다.

중요한 숫자는 동시에 발생하는 캐시 불가 요청 수이고, 계산은 단순합니다. PHP 워커 하나는 한 번에 캐시 불가 요청 하나를 처리합니다. 필요한 워커 수는 대략 최대 초당 캐시 불가 요청 수에 초 단위 평균 PHP 응답 시간을 곱한 값입니다. 초당 20건의 캐시 불가 요청이 각각 400밀리초라면 따라가는 데 약 여덟 개의 워커가 필요하고, 거기에 최소한 절반은 여유로 더 두고 싶을 것입니다.

그러니 어떤 요금제 페이지도 답하지 않는 두 가지를 물으십시오. 이 요금제는 PHP 워커를 몇 개 돌리는가, 그리고 프로세스당 메모리 상한은 얼마인가. 두 숫자는 모두 존재하지만 대개 공개되지 않습니다. 직접 물으면 지원은 보통 알려주고, 그 답은 페이지에 실린 어떤 벤치마크보다 요금제에 대해 더 많이 말해줍니다.

그다음 당신 쪽도 정직하게 추정하십시오. 로그인 상태 세션의 비율, 평균이 아니라 가장 바쁜 한 시간의 결제와 계정 트래픽, 그리고 플러그인이 뒤에서 만들어내는 admin-ajax나 REST 트래픽입니다. 마지막 것은 분석 도구에는 보이지 않고 서버 로그에는 아주 잘 보입니다.

플러그인 수와 발행량은 호스팅 결정입니다

사이트 안의 두 가지가 호스팅이 얼마나 필요한지를 정하는데, 둘 다 대개 청구서를 볼 일 없는 사람들이 내리는 콘텐츠 결정으로 취급됩니다.

첫째는 플러그인 스택입니다. 활성화된 플러그인은 모두 요청마다 불려오는 자동 로드 옵션, WordPress의 cron이 진짜 cron이 아니라서 방문자 요청 위에서 발화하는 예약 이벤트, 그리고 페이지 생성마다의 질의를 더합니다. 캐시된 브로슈어형 사이트에서 서른 개의 플러그인은 견딜 만합니다. 아무것도 캐시되지 않는 상점에서 서른 개는 결제의 모든 단계에서 서른 개가 실행된다는 뜻입니다. WordPress 코어는 이것이 언제부터 물기 시작하는지에 대해 대략의 견해를 가지고 있습니다. 영속 오브젝트 캐시 사이트 상태 검사는 글 2,000개, 사용자 2,000명, 자동 로드 옵션 600개 같은 문턱을 넘으면 오브젝트 캐시를 쓰라고 권합니다.

둘째는 발행량입니다. 리비전은 기본적으로 제한 없이 쌓이고, 미디어 라이브러리는 각각 여러 생성 크기를 가진 수만 개의 파일로 자라며, 둘 다 데이터베이스와 백업 시간을 부풀립니다. 5년 동안 매일 발행해온 사이트는 같은 디자인으로 한 달에 한 번 발행하는 사이트와 실질적으로 다른 호스팅 문제이고, 요금제 페이지는 그것을 전혀 반영하지 않습니다. 마이그레이션 견적을 내기 전에 WordPress 개발자가 해야 할 일은 요금제가 아니라 구축물을 감사하는 것입니다.

순서대로 고르기

이 순서로 밟아가면 결정은 대개 저절로 납니다. 트래픽 가운데 캐시할 수 없는 비중을 확인하십시오. 그 한 숫자가 등급을 고릅니다. PHP 브랜치와 데이터베이스 버전이 공개된 기준을 충족하는지 확인하십시오. 여기서 떨어지는 요금제는 가격과 무관하게 탈락입니다. 어떤 캐시 계층이 포함되고 어떤 것을 직접 마련해야 하는지 확인하십시오. 백업이 어디에 어떤 형식으로 있고 오늘 하나 내려받을 수 있는지 물으십시오. 그런 다음 하위 처리자, 데이터 소재지, 계약 종료 시 삭제에 관한 처리자 조항을 읽으십시오. 이 모두를 마친 뒤에야 가격이 의미를 갖습니다. 그 전까지 비교하는 것은 같은 상품조차 아니기 때문입니다.

Mecanik은 이것을 어떤 마이그레이션보다 앞서는 고정 작업으로 수행하며, 보통은 웹사이트 개발 프로젝트와 나란히 진행하고, 이후에는 WordPress 개발자 대행 서비스로 지속 지원까지 맡습니다. 플랫폼 자체가 어디로 가고 있는지 저울질하고 있다면, WordPress 7.0과 코어에 들어온 AI 클라이언트에 대한 글이 이 글의 좋은 짝입니다.

자주 묻는 질문

영국에서 WordPress 호스팅 비용은 얼마여야 하나요? 거의 전적으로 트래픽 가운데 얼마나 캐시할 수 있는지에 달려 있습니다. 익명 방문자만 있는 브로슈어형 사이트는 공유 호스팅에서 월 3파운드에서 15파운드면 충분합니다. 콘텐츠 사이트나 소규모 상점은 대개 관리형 WordPress 호스팅의 월 20파운드에서 100파운드가 맞고, 바쁘거나 멀티사이트 요금제라면 100파운드에서 400파운드로 올라갑니다. 로그인 트래픽이 많은 상점이나 회원제 사이트는 보통 머신에 월 15파운드에서 120파운드인 VPS나 클라우드 스택이 필요하고, 남에게 관리를 맡기면 월 150파운드에서 600파운드가 더 듭니다.

관리형 WordPress 호스팅은 추가 비용만큼 값어치가 있나요? 운영 담당자가 없다면 값어치가 있습니다. 업데이트, 스테이징, 백업, 방화벽, 그리고 직접 설정해야 했을 영속 오브젝트 캐시를 사는 것이기 때문입니다. 대가는 실질적인 제약입니다. 제공자는 캐시 플러그인, 백업 플러그인, 데이터베이스를 많이 쓰는 플러그인을 일상적으로 금지하고, 셸 접근을 주지 않는 경우가 많으며, 오래 도는 프로세스에 상한을 걸고 발신 메일을 차단합니다. 계약한 뒤가 아니라 계약하기 전에 그 한계를 자신의 구축물과 대조하십시오.

2026년에 WordPress는 어떤 PHP 버전이 필요한가요? WordPress는 PHP 8.3 이상을 권장합니다. PHP 7.4 이상에서도 여전히 돌지만 그 브랜치들은 지원이 종료되어 보안 수정을 받지 못합니다. PHP 8.1은 2025년 12월 31일, PHP 8.0은 2023년 11월 26일, PHP 7.4는 2022년 11월 28일에 끝났고, PHP 8.2는 2026년 12월 31일까지 보안 수정만 제공됩니다. WordPress 설치의 약 38.8퍼센트가 여전히 완전히 지원 종료된 브랜치를 보고합니다.

호스팅을 좋게 하면 코어 웹 바이탈이 개선되나요? 셋 가운데 하나만, 그것도 간접적으로만 개선됩니다. 서버 응답 시간은 Largest Contentful Paint의 일부이므로 더 빠른 호스트는 모든 방문자의 LCP를 낮춥니다. Cumulative Layout Shift에는 거의 아무 일도 하지 못하는데, 그것은 크기가 없는 이미지와 늦게 불려오는 글꼴에서 나옵니다. Interaction to Next Paint에도 아주 조금밖에 못 하는데, 그것은 메인 스레드의 JavaScript가 지배합니다. 서버 응답이 이미 여유롭다면 남은 문제는 페이지 안에 있습니다.

빠르다고 적힌 요금제인데 WooCommerce 상점이 느린 이유는 무엇인가요? 정작 중요한 페이지들을 캐시할 수 없기 때문입니다. WooCommerce는 장바구니, 내 계정, 결제가 동적으로 유지되기를 요구하고, 로그인한 구매자에게는 페이지 캐시를 우회하는 세션 쿠키를 설정합니다. 첫 페이지의 속도 측정은 캐시된 파일을 재고 있는 반면, 결제는 요청마다 PHP를 돌리고 데이터베이스를 두들깁니다. 상점이 실제로 사는 것은 캐시된 첫 페이지 수치가 아니라 캐시할 수 없는 요청을 감당할 용량입니다.