문제는 성능이 아니라 책임의 빈칸에서 시작한다
사이트는 열리는데 결제만 실패합니다. 호스팅사는 서버가 정상이라고 답합니다. 플러그인을 업데이트한 뒤 관리자 화면이 깨졌지만 누가 이전 버전으로 되돌릴지는 정해져 있지 않습니다. 백업 화면에는 매일 성공 기록이 남지만 실제로 복원해 본 사람은 없습니다. 이런 문제는 호스팅 상품의 성능보다 책임의 빈칸에서 시작되는 경우가 많습니다.
관리형 WordPress 호스팅은 서버와 WordPress Platform 운영 부담을 줄여 줍니다. 그렇다고 Plugin·Theme·Custom Code와 사업 기능까지 호스팅사가 모두 책임진다는 뜻은 아닙니다. 직접 VM을 운영하면 통제권이 넓어지는 대신 Guest OS부터 PHP·DB·WordPress·백업·모니터링까지 대부분을 직접 맡아야 합니다. 관리형 인프라는 이 가운데 일부를 외부 운영자에게 맡길 수 있지만 계약에 적히지 않은 WordPress Application 업무가 저절로 포함되지는 않습니다.
따라서 WordPress 운영 모델은 월 서버비가 아니라 다음 질문으로 골라야 합니다. Core·Runtime·Database·Plugin·Code·Backup·Restore·Security·Monitoring·Incident를 누가 실행하고 누가 최종 판단하며 지원 범위 밖의 문제는 누가 이어받는가.
‘관리형’은 하나의 책임 표준이 아니다
관리형 WordPress 호스팅을 설명할 때 흔히 "업데이트, 백업, 보안, 성능을 모두 알아서 처리한다"고 말합니다. 실제 상품은 그렇게 단순하지 않습니다.
WP Engine은 Platform 기능과 기본 WordPress 구성을 지원하지만 Plugin·Theme의 기능 버그와 Core·Custom Code 충돌, Custom Code 자체는 지원 범위 밖이라고 명시합니다. Plugin·Theme 자동 업데이트와 시각적 회귀 검사를 수행하는 Smart Plugin Manager도 Plan에 따라 별도 구매하거나 특정 상품에 포함되는 기능입니다.
Kinsta는 PHP Runtime과 Hosting Stack을 관리하고 PHP가 지원 종료에 도달하면 자동으로 전환합니다. 그러나 변경 전 Theme·Plugin·Custom Code의 호환성을 확인하고 Staging에서 시험하라고 안내합니다. Plugin·Theme 자동 업데이트와 시각 회귀 검사 역시 별도 Add-on으로 구분돼 있습니다.
Cloudways는 OS 패치·보안 업데이트·방화벽·Machine Orchestration을 Managed Server 범위로 설명합니다. 반면 Application Support는 도메인 연결, 백업·복원, SSL, 기본적인 구성 지원 등으로 구분하고 WordPress Core·Plugin·Theme 업데이트 자동화는 SafeUpdates라는 별도 기능으로 제공합니다.
같은 '관리형'이라는 이름을 사용해도 실제 책임 범위가 다릅니다. 상품명보다 Support Scope, Exclusion, Add-on, Incident Escalation을 먼저 읽어야 하는 이유입니다.
관측에서 복구와 개선까지 이어지는 운영 — 서비스 지표와 경보를 기준으로 대응하고 변경 이력과 사후 보고를 다음 개선에 연결합니다.
WordPress 운영은 네 개의 책임 층으로 나눈다
WordPress를 하나의 프로그램으로만 보면 책임이 섞입니다. 운영 계약에서는 최소한 아래 네 층을 분리해야 합니다.
호스팅사가 첫 번째와 두 번째 층을 관리해도 세 번째 층의 사업 기능까지 자동으로 보증하지는 않습니다. 서버가 HTTP 200을 반환해도 결제 Callback, 예약 확정, 회원 가입, 관리자 Workflow는 실패할 수 있습니다.
WordPress의 Site Health는 PHP 버전, Plugin·Theme 상태, 구성 문제 등을 진단하는 유용한 내부 도구입니다.[7] 그러나 이 기능만으로 외부 사용자가 로그인·결제·문의 제출에 성공하는지는 확인할 수 없습니다. 이는 Site Health의 공식 진단 범위와 사용자 여정 모니터링의 차이에서 나오는 운영상 판단입니다.
- Infrastructure
- Compute, Storage, Network, OS, Firewall이 들어갑니다. 장애가 났을 때 서버와 네트워크가 정상인지를 묻는 층입니다.
- Runtime & WordPress Platform
- Web Server, PHP, Database Engine, WordPress Core, Cache, Cron이 들어갑니다. WordPress가 실행 가능한 상태인지를 묻는 층입니다.
- Application & Business Function
- Plugin, Theme, MU Plugin, Custom Code, 결제·회원·폼·외부 API가 들어갑니다. 사용자가 실제 업무를 완료할 수 있는지를 묻는 층입니다.
- Recovery & Governance
- Backup Policy, Restore Test, Incident Command, 고객 공지, 복구 승인이 들어갑니다. 누가 영향도를 판단하고 복구 완료를 승인하는지를 묻는 층입니다.
세 운영 모델을 같은 기준으로 정의한다
이 글에서 비교하는 세 모델은 아래와 같이 정의합니다. Self-managed VM의 경우 AWS의 Shared Responsibility Model도 EC2 고객이 Guest OS의 업데이트·보안 패치와 Application Software를 관리한다고 구분합니다.
Managed Infrastructure는 계약에 WordPress 유지보수까지 명시하면 범위가 넓어질 수 있습니다. 반대로 "서버 관리"만 적혀 있으면 Core·Plugin Update나 Application Incident는 포함되지 않을 가능성이 큽니다.
- Managed WordPress Hosting
- WordPress에 맞춘 Runtime, Cache, Backup, Security, Staging, Support 기능을 하나의 Platform 상품으로 제공합니다. 일반적으로 Root 권한과 Server 구성 자유도는 제한되며 허용되지 않는 Plugin이나 Platform 고유 제약이 있을 수 있습니다.
- Self-managed VM / Server
- Cloud나 Hosting Provider가 물리 인프라와 가상화 계층을 운영하고 사용자가 Guest OS부터 Web Server·PHP·Database·WordPress와 Application을 직접 운영합니다. 자동 패치나 Control Panel을 설치해도 최종 운영 책임이 Provider로 이전되지는 않습니다.
- Managed Infrastructure
- 특정 회사의 상품명이 아니라 계약형 운영 모델입니다. 서버·OS·Runtime·Database Engine·백업 실행·인프라 모니터링·1차 장애 대응을 내부 Platform Team이나 외부 운영자에게 맡깁니다. Plugin·Theme·Custom Code와 사업 기능은 별도의 WordPress Application Owner가 맡습니다.
19개 책임 축 — Software와 변경 책임
아래 표부터 세 개의 표는 19개 책임 축을 세 모델에 대입한 일반적인 기본 책임 모델입니다. 실제 계약과 Plan의 Support Scope가 표보다 우선합니다. 첫 표는 Software와 변경에 관한 여섯 축입니다.
WordPress는 Core·Plugin·Theme를 최신 상태로 유지할 것을 권고하고 Plugin·Theme별 자동 업데이트 기능을 제공합니다.[2] 그러나 자동 실행 여부와 변경 후 기능 검증은 별개의 책임입니다. PHP 버전 전환도 마찬가지로, WordPress는 PHP 업그레이드 전에 Plugin·Theme 호환성을 확인하도록 안내합니다.[8] 주요 관리형 호스팅사 역시 Core Update, Plugin Update, Custom Code 지원을 서로 다른 범위로 구분합니다.
비교 축 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| WordPress Core | Host가 자동 업데이트·배포 일정을 관리하기도 합니다. Plugin·Theme·Custom Code 호환성 승인은 사이트 소유자에게 남습니다. | 설치, 업데이트, 긴급 보안 패치, 실패 복구를 모두 직접 맡습니다. | 기본적으로 Application Owner 책임입니다. 계약에 WordPress 운영이 포함되면 Operator가 실행합니다. |
| PHP / Runtime | Host가 제공 버전과 EOL 전환을 관리합니다. Application 호환성 시험은 고객·개발자 책임입니다. | PHP, Web Server, Extension, Process Manager의 패치와 구성을 직접 관리합니다. | Operator가 패치·구성을 수행하고 Application Owner가 호환성을 승인합니다. |
| Database | Host가 Database Engine을 운영해도 Schema, Query, Plugin Table, 데이터 정합성은 Application 책임입니다. | Engine, Backup, 권한, 성능, Schema, 데이터 정합성을 모두 직접 관리합니다. | Operator는 Engine·Backup을, Application Owner는 Schema·Query·데이터를 맡는 방식이 일반적입니다. |
| Plugin / Theme | 기본적으로 고객 책임인 경우가 많습니다. 자동 업데이트·회귀 검사가 별도 기능일 수 있습니다. | 선택·License·Update·Compatibility·Rollback을 모두 직접 맡습니다. | 별도 WordPress 유지보수 계약이 없으면 Application Owner 책임입니다. |
| Custom Code | 거의 항상 고객·개발자 책임입니다. Host는 Log나 Server-side 원인 파악까지만 지원합니다. | 전적으로 내부 개발·운영 책임입니다. | Application Owner 책임입니다. Operator는 Runtime·Log·배포 환경을 지원합니다. |
| Deployment | Staging·Backup·배포 도구를 제공할 수 있지만 변경 승인과 기능 검증은 사이트 소유자 책임입니다. | Pipeline, Credential, Artifact, 승인, Rollback을 직접 설계합니다. | Operator가 배포 기반을 관리하고 Application Owner가 Release 내용과 기능 검증을 책임집니다. |
19개 책임 축 — 보호와 운영 책임
두 번째 표는 Backup, Restore Test, Security, WAF/CDN, Monitoring, Incident, Performance, Scaling의 여덟 축입니다.
WordPress 공식 문서는 Backup이 Database와 Files를 함께 다뤄야 하며 빠르게 복구할 방법을 알아야 한다고 설명합니다.[1] NIST는 Backup 파일을 생성하는 데서 끝내지 않고 유지하고 시험할 것을 권고합니다.[5] 따라서 "Backup 제공"과 "정해진 시간 안에 복구 가능"은 같은 상태가 아닙니다.
비교 축 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| Backup | 자동 Backup을 제공하는 경우가 많습니다. 무엇을 보호하고 어느 시점까지 복구할지는 고객이 확인해야 합니다. | Files·Database·외부 Storage·DNS·Secret 등을 직접 식별하고 Backup Job을 운영합니다. | Operator가 Job과 실패 알림을 운영하고 사업 책임자가 RPO·보존·격리 정책을 승인합니다. |
| Restore Test | 복원 버튼이나 Support가 있어도 정기 복원 시험이 자동으로 보장되지는 않습니다. | 시험 환경, 복원 절차, 정합성 확인, 소요 시간 측정을 직접 수행합니다. | Operator와 Application Owner가 함께 수행하고 사업 책임자가 복구 완료를 승인합니다. |
| Security | Host가 Platform·WAF·Malware·Isolation을 관리하는 경우가 많습니다. 계정·권한·취약 Plugin·Custom Code는 고객 책임으로 남습니다. | OS부터 WordPress 계정·Code까지 모두 직접 관리합니다. | Operator는 Infrastructure Security를, Application Owner는 WordPress·Code·권한을 맡습니다. |
| WAF / CDN | 기본 포함될 수 있지만 Cache 예외·Origin·DNS·Business Logic 설정은 공동 검토가 필요합니다. | 제품 선택, DNS, 인증서, Origin 보호, Cache Rule을 직접 운영합니다. | 계약 범위에 따라 Operator가 구성하고 Application Owner가 기능 영향을 검증합니다. |
| Monitoring | Platform 또는 HTTP Uptime Monitoring을 제공하기도 합니다. 결제·가입·폼 같은 사용자 여정은 별도 계측이 필요합니다. | Infra·Log·APM·Uptime·Business Journey를 모두 직접 설계합니다. | Operator는 Infra·Runtime을, Application Owner는 사용자 여정과 사업 결과를 관측합니다. |
| Incident | Platform Incident는 Host가 맡지만 Plugin·Code·사업 기능 장애는 고객이 이어받아야 합니다. | 탐지·분류·완화·복구·소통을 모두 내부에서 수행합니다. | Operator가 Infrastructure Incident를, Application Owner가 Application Incident를, 사업 책임자가 외부 소통을 맡습니다. |
| Performance | Cache·CDN·Runtime 최적화를 제공하기도 합니다. 느린 Plugin·Query·Theme·외부 API는 Application 책임입니다. | 전체 Stack의 병목을 직접 진단하고 개선합니다. | Operator가 Resource·Runtime을, Application Owner가 Query·Plugin·Code를 개선합니다. |
| Scaling | Plan·Platform 한계 안에서 확장합니다. 규모 변경과 비용 승인은 고객이 맡습니다. | Capacity Planning과 Architecture 변경을 직접 수행합니다. | Operator가 용량 계획과 변경을 제안하고 사업 책임자가 비용·위험을 승인합니다. |
19개 책임 축 — 통제와 비용 책임
세 번째 표는 Support, Root/Server Access, Portability, Cost Structure, Responsibility Gap의 다섯 축입니다.
직접 운영이 항상 저렴하지 않은 이유는 Server 요금과 총운영비가 다르기 때문입니다. 반대로 관리형 상품이 모든 조직에서 경제적인 것도 아닙니다. 사용하지 않는 Platform 기능, Traffic 기준 과금, Add-on, 제약으로 인한 재개발 비용이 생길 수 있습니다.
비교 축 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| Support | WordPress 전문 Support가 장점이지만 Plugin·Code·DNS·메일 등 Exclusion을 확인해야 합니다. | Infrastructure Provider는 물리·가상화 계층까지만 지원합니다. Application 지원자는 별도로 필요합니다. | 단일 운영 창구를 만들 수 있지만 Application Development가 포함되는지는 계약에 달려 있습니다. |
| Root / Server Access | 일반적으로 제한되거나 제공되지 않습니다. Platform 안정성과 표준화를 우선합니다. | Root와 Server 설정을 직접 통제합니다. 잘못된 변경의 책임도 직접 집니다. | 고객 보유 계정, 제한된 권한 또는 Operator 전용 권한 등 계약 구조에 따라 달라집니다. |
| Portability | Platform 고유 Cache·MU Plugin·배포 기능에 의존하기 쉽습니다. Export 가능 범위를 확인해야 합니다. | 구성과 데이터의 통제는 높지만 문서·자동화가 없으면 특정 운영자에게 종속될 수 있습니다. | IaC, Credential 소유권, Backup Export, Runbook 인계 조건에 따라 달라집니다. |
| Cost Structure | Hosting 요금에 Platform·Backup·Security·Support가 묶입니다. Update Add-on이나 초과 사용 비용이 추가될 수 있습니다. | Server 요금은 낮아 보일 수 있으나 운영 인력·도구·온콜·복구 시험 비용을 별도로 부담합니다. | Infrastructure 비용과 관리 비용, 별도 Application 유지보수 비용으로 나뉩니다. |
| Responsibility Gap | Host 지원 범위 밖의 Plugin·Custom Code·사업 기능 담당자가 없을 때 생깁니다. | 기술은 모두 통제하지만 실제 담당자·온콜 시간·복구 절차가 없을 때 생깁니다. | Infrastructure 계약과 WordPress Application 계약 사이에 업무가 빠질 때 생깁니다. |
WordPress Operations RACI Matrix
RACI는 업무별로 실행자와 최종 책임자를 분리하는 방법입니다. R(Responsible)은 실제 작업을 수행하고, A(Accountable)는 결과를 최종 책임지고 승인하며, C(Consulted)는 판단 전에 협의하고, I(Informed)는 결과와 상태를 통보받습니다.
표에서는 네 역할을 씁니다. B는 Business Owner로 사업 영향, 예산, 외부 소통, 복구 승인을 맡습니다. W는 WordPress/Application Owner로 Core·Plugin·Theme·Code와 사업 기능을 맡습니다. H는 Managed WordPress Host입니다. O는 Infrastructure Operator로, 직접 운영에서는 내부 담당자이고 관리형 인프라에서는 계약된 운영자입니다.
이 Matrix는 기본 모델입니다. 계약에 Plugin Update, WordPress Maintenance, Application Monitoring, 24시간 Incident Response가 명시되면 일부 R과 A가 바뀔 수 있습니다. 반대로 계약서에 "서버 관리"만 적혀 있다면 Core·Plugin·Application 업무가 Operator에게 넘어갔다고 해석해서는 안 됩니다. RACI의 A는 여기서 운영상 Accountability를 뜻합니다. 법적 손해배상 책임이나 SLA 책임은 실제 계약과 약관으로 별도 판단해야 합니다.
운영 업무 | Managed WordPress Hosting | Self-managed VM / Server | Managed Infrastructure |
|---|---|---|---|
| PHP·Web Server·DB Engine 패치 | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| Core Update 실행 | A/R: H · C: W · I: B | A: W · R: O · I: B | 기본 A/R: W · C: O · I: B |
| Core Update 호환성 승인 | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| Plugin·Theme Update | A/R: W · C: H · I: B | A/R: W · C: O · I: B | 기본 A/R: W · C: O · I: B |
| Custom Code·Deployment | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| Backup Policy·RPO 승인 | A: B · R: W · C: H | A: B · R: W · C: O | A: B · R: W · C: O |
| Backup Job·실패 알림 운영 | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| Restore Drill 수행 | A: B · R: W+H | A: B · R: W+O | A: B · R: W+O |
| Platform Security·WAF | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| 계정·Plugin·Code 보안 | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| Infrastructure·Runtime Monitoring | A/R: H · I: W+B | A/R: O · I: W+B | A/R: O · I: W+B |
| 사용자 여정 Monitoring | A: B · R: W · C: H | A: B · R: W · C: O | A: B · R: W · C: O |
| Platform Incident 대응 | A/R: H · C: W · I: B | A/R: O · C: W · I: B | A/R: O · C: W · I: B |
| Application Incident 대응 | A/R: W · C: H · I: B | A/R: W · C: O · I: B | A/R: W · C: O · I: B |
| 고객 공지·복구 완료 승인 | A/R: B · C: W+H | A/R: B · C: W+O | A/R: B · C: W+O |
| Capacity·Scaling 결정 | A: B · R: H · C: W | A: B · R: O · C: W | A: B · R: O · C: W |
| Exit·Export·인계 | A: B · R: W · C: H | A: B · R: W+O | A: B · R: W+O |
관리형 WordPress 호스팅이 맞는 경우
다음 조건이 많다면 관리형 WordPress 호스팅이 적합할 수 있습니다. 일반적인 WordPress Stack과 Platform 제약을 수용합니다. Root 권한이나 별도 Daemon이 필요하지 않습니다. 서버보다 콘텐츠·사업 기능 운영에 집중하려 합니다. Plugin·Theme·Custom Code를 맡을 개발자나 에이전시는 별도로 존재합니다. Hosting사가 제공하는 Backup·Staging·Security·Support 범위가 현재 위험 수준에 충분합니다.
반대로 특정 Plugin이 금지될 수 없거나, 서버 설정을 세밀하게 바꿔야 하거나, Hosting사 지원 범위 밖의 Application 문제를 맡을 사람이 없다면 맞지 않을 수 있습니다.
직접 VM·서버 운영이 맞는 경우
직접 운영은 단순히 저가 VM을 고르는 선택이 아닙니다. 다음 조건을 충족해야 합니다. OS·PHP·Database·Web Server를 운영할 담당자가 있습니다. Patch, Monitoring, Backup, Restore Test를 자동화하고 실패를 확인합니다. 장애 시 응답할 On-call 또는 명확한 담당자가 있습니다. Root 권한과 Server 구성 자유도가 실제로 필요합니다. Platform 제약을 줄이는 가치가 운영 복잡성보다 큽니다.
서버 설치 경험이 있다는 이유만으로 운영 가능하다고 판단해서는 안 됩니다. 정기 패치가 중단됐을 때, Backup Job이 실패했을 때, 새 PHP 버전에서 Plugin이 깨졌을 때 누가 대응할지까지 답할 수 있어야 합니다.[8]
관리형 인프라가 맞는 경우
다음과 같은 상황에서는 관리형 인프라를 검토합니다. Server·OS·Runtime의 통제권은 유지하고 싶지만 내부 인프라 운영 인력이 부족합니다. 여러 WordPress 사이트나 다른 Application을 하나의 운영 기준으로 관리해야 합니다. Backup, Monitoring, Patch, Incident의 운영 주체를 외부 또는 별도 Platform Team으로 통합하려 합니다. Hosting Platform의 Plugin·Server 제약보다 이식성과 구성 자유도가 중요합니다. WordPress Application을 맡을 개발자·에이전시는 별도로 존재합니다.
다만 관리형 인프라만 계약하고 WordPress Application Owner를 정하지 않으면 새로운 공백이 생깁니다. Operator는 서버가 정상이라고 보고하고 개발자는 서버 문제라고 판단하며 사업 담당자는 어느 쪽에 요청해야 할지 모르는 상황입니다.
가격은 월 서버비가 아니라 총운영비로 비교한다
세 모델을 비교할 때는 다음 식을 사용해야 합니다. WordPress 총운영비는 아래 계산 항목으로 정리합니다.
직접 운영은 Hosting 요금만 보면 가장 저렴해 보입니다. 그러나 담당자의 Patch 시간, Monitoring 도구, 야간 장애 대응, 복원 시험과 문서화가 추가됩니다. 관리형 WordPress 호스팅은 많은 기능을 묶어서 제공하지만 Traffic·Storage·Site 수·Add-on·Support Plan에 따라 비용 구조가 달라질 수 있습니다. 관리형 인프라는 Server 비용과 운영비를 분리해 볼 수 있지만 WordPress Application 유지보수까지 포함하려면 별도 범위와 비용이 필요합니다.
어느 방식이 싸다고 일반화할 수 없습니다. 현재 팀이 이미 보유한 역량, 사이트의 실패 비용, 지원 시간, 변경 빈도와 통제 요구를 함께 계산해야 합니다.
- WordPress 총운영비
- 아래 여덟 비용 항목의 합계입니다.
- Hosting·Infrastructure 요금
- 총비용에 합산합니다.
- Managed Service 요금
- 총비용에 합산합니다.
- Update·Compatibility Test 시간
- 총비용에 합산합니다.
- Backup·Monitoring·Security 도구
- 총비용에 합산합니다.
- On-call·Incident 대응
- 총비용에 합산합니다.
- Restore Drill
- 총비용에 합산합니다.
- 변경 실패·중단 비용
- 총비용에 합산합니다.
- 운영 인계·Exit 비용
- 총비용에 합산합니다.
계약 전에 답을 받아야 할 12가지 질문
상품과 계약을 검토할 때 아래 열두 질문에 대한 답을 문서로 받아 둡니다. 답이 없는 질문이 곧 Responsibility Gap이 생기는 자리입니다.
- WordPress Core는 누가 언제 업데이트하는가?
- Major·Minor·Security Release의 정책이 각각 무엇인지 확인합니다. 지연할 수 있는 기간과 긴급 보안 업데이트의 예외도 필요합니다.
- Plugin·Theme Update가 기본 범위에 포함되는가?
- 단순 자동 설치인지, Staging Test·시각 회귀 검사·기능 검사·자동 Rollback까지 포함하는지 구분합니다.
- Plugin·Theme·Custom Code 충돌은 누가 해결하는가?
- Hosting Support가 Log만 제공하는지, 원인 분석까지 하는지, Code 수정도 수행하는지 확인합니다.
- PHP·Database 지원 종료 시 누가 전환을 계획하는가?
- 자동 전환 여부뿐 아니라 사전 통지, Staging 기간, 호환성 검증, 전환 실패 시 복구 방식이 필요합니다.
- Backup에는 정확히 무엇이 포함되는가?
- Database, Plugin, Theme, MU Plugin, Uploads, Custom Code, Config, 외부 Storage와 Secret을 구분합니다.
- Backup 보존기간과 저장 위치는 어디인가?
- 같은 계정·같은 Region·같은 관리 권한에만 존재하는지, 다운로드·외부 Export가 가능한지 확인합니다.
- Restore는 누가 실행하고 누가 성공을 판정하는가?
- 복원 버튼이 있다는 사실보다 요청 절차, 승인 권한, 예상 시간, 데이터 정합성 검증 항목이 중요합니다.
- Restore Drill은 얼마나 자주 수행하는가?
- 최근 시험일, 실제 소요 시간, 실패 원인, RTO·RPO 충족 여부를 Evidence로 남길 수 있어야 합니다.
- Security는 탐지만 하는가, 조치까지 하는가?
- 취약 Plugin을 알려주는 것과 업데이트·비활성화·제거·Code 수정까지 수행하는 것은 다른 범위입니다.
- Monitoring은 어디까지 보는가?
- Server·PHP·Database·HTTP Uptime뿐 아니라 로그인, 결제, 문의 제출, 예약, 관리자 Workflow를 확인하는지 묻습니다.
- Incident 대응 시간과 Escalation은 어떻게 되는가?
- 24시간 지원이 24시간 복구를 의미하지는 않습니다. Severity, 응답 목표, 담당자, Application 문제 인계, 고객 공지 책임을 확인합니다.
- 종료할 때 무엇을 가져갈 수 있는가?
- Database·Files·Backup·DNS·SSL·Credential·Log·Configuration·Runbook을 어떤 형식과 기간 안에 인계받을 수 있는지 확인합니다.
가장 위험한 모델은 ‘책임자가 없는 운영’이다
관리형 WordPress 호스팅은 서버 운영 부담을 줄이는 데 유용하지만 Application 책임까지 사라지지는 않습니다. 직접 운영은 넓은 통제권을 주지만 실제 담당자와 복구 체계가 없다면 낮은 Server 가격이 장점이 되기 어렵습니다. 관리형 인프라는 통제와 운영 지원을 조합할 수 있지만 계약 경계가 모호하면 Infrastructure와 WordPress 사이에 공백이 생깁니다.
따라서 상품을 고르기 전에 세 문서를 먼저 만들어야 합니다. 업무별 RACI Matrix, Provider와 Operator가 하지 않는 일의 목록, 장애 시 Platform·Application·Business Owner의 연락과 인계 순서입니다.
이 세 가지가 정해져 있다면 세 모델 중 어느 것을 선택해도 운영 구조를 설명할 수 있습니다. 반대로 이것이 없다면 '관리형'이라는 이름이나 낮은 월 요금만으로는 누가 사이트를 복구할지 알 수 없습니다.
