사이트는 열리는데 결제만 실패한다. 호스팅사는 서버가 정상이라고 답한다. 플러그인을 업데이트한 뒤 관리자 화면이 깨졌지만 누가 이전 버전으로 되돌릴지는 정해져 있지 않다. 백업 화면에는 매일 성공 기록이 남지만 실제로 복원해 본 사람은 없다.
이런 문제는 호스팅 상품의 성능보다 책임의 빈칸에서 시작되는 경우가 많다.
관리형 WordPress 호스팅은 서버와 WordPress Platform 운영 부담을 줄여준다. 그렇다고 Plugin·Theme·Custom Code와 사업 기능까지 호스팅사가 모두 책임한다는 뜻은 아니다. 직접 VM을 운영하면 통제권이 넓어지는 대신 Guest OS부터 PHP·DB·WordPress·백업·모니터링까지 대부분을 직접 맡아야 한다. 관리형 인프라는 이 가운데 일부를 외부 운영자에게 맡길 수 있지만 계약에 적히지 않은 WordPress Application 업무가 저절로 포함되지는 않는다. Amazon Web Services, Inc.
따라서 WordPress 운영 모델은 월 서버비가 아니라 다음 질문으로 골라야 한다.
Core·Runtime·Database·Plugin·Code·Backup·Restore·Security·Monitoring·Incident를 누가 실행하고 누가 최종 판단하며 지원 범위 밖의 문제는 누가 이어받는가?
편집 고지: IXC는 Cloudways Affiliate Program, Kinsta Affiliate Program, Rocket.net Affiliate Program에 참여한다. 이 글에는 제휴 링크를 사용하지 않았으며 해당 관계를 기술적 우위나 추천 순위의 근거로 삼지 않았다.
‘관리형’은 하나의 책임 표준이 아니다
관리형 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으로 구분돼 있다. Kinsta®
Cloudways는 OS 패치·보안 업데이트·방화벽·Machine Orchestration을 Managed Server 범위로 설명한다. 반면 Application Support는 도메인 연결, 백업·복원, SSL, 기본적인 구성 지원 등으로 구분하고 WordPress Core·Plugin·Theme 업데이트 자동화는 SafeUpdates라는 별도 기능으로 제공한다. Cloudways Help Center
같은 ‘관리형’이라는 이름을 사용해도 실제 책임 범위가 다르다. 상품명보다 Support Scope, Exclusion, Add-on, Incident Escalation을 먼저 읽어야 하는 이유다.
WordPress 운영은 네 개의 책임 층으로 나눠야 한다
WordPress를 하나의 프로그램으로만 보면 책임이 섞인다. 운영 계약에서는 최소한 다음 네 층을 분리해야 한다.
| 책임 층 | 포함되는 항목 | 장애가 났을 때 묻는 질문 |
|---|---|---|
| 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, 고객 공지, 복구 승인 | 누가 영향도를 판단하고 복구 완료를 승인하는가 |
호스팅사가 첫 번째와 두 번째 층을 관리해도 세 번째 층의 사업 기능까지 자동으로 보증하지는 않는다. 서버가 HTTP 200을 반환해도 결제 Callback, 예약 확정, 회원 가입, 관리자 Workflow는 실패할 수 있다.
WordPress의 Site Health는 PHP 버전, Plugin·Theme 상태, 구성 문제 등을 진단하는 유용한 내부 도구다. 그러나 이 기능만으로 외부 사용자가 로그인·결제·문의 제출에 성공하는지는 확인할 수 없다. 이는 Site Health의 공식 진단 범위와 사용자 여정 모니터링의 차이에서 도출되는 운영상 판단이다.
세 운영 모델을 같은 기준으로 정의하기
이 글에서 비교하는 세 모델은 다음과 같다.
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로 이전되는 것은 아니다. AWS의 Shared Responsibility Model도 EC2 고객이 Guest OS의 업데이트·보안 패치와 Application Software를 관리한다고 구분한다. Amazon Web Services, Inc.
Managed Infrastructure
이 글에서 Managed Infrastructure는 특정 회사의 표준 상품명이 아니라 계약형 운영 모델을 뜻한다. 서버·OS·Runtime·Database Engine·백업 실행·인프라 모니터링·1차 장애 대응을 내부 Platform Team이나 외부 운영자에게 맡기되, Plugin·Theme·Custom Code와 사업 기능은 별도의 WordPress Application Owner가 맡는 방식이다.
계약에 WordPress 유지보수까지 명시하면 범위가 넓어질 수 있다. 반대로 “서버 관리”만 적혀 있으면 Core·Plugin Update나 Application Incident는 포함되지 않을 가능성이 크다.
19개 책임 축으로 비교하기
아래 표는 일반적인 기본 책임 모델이다. 실제 계약과 Plan의 Support Scope가 표보다 우선한다.
Software와 변경 책임
| 비교 축 | 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 내용과 기능 검증을 책임진다. |
WordPress는 Core·Plugin·Theme를 최신 상태로 유지할 것을 권고하고 Plugin·Theme별 자동 업데이트 기능을 제공한다. 그러나 자동 실행 여부와 변경 후 기능 검증은 별개의 책임이다. 주요 관리형 호스팅사 역시 Core Update, Plugin Update, Custom Code 지원을 서로 다른 범위로 구분한다.
보호와 운영 책임
| 비교 축 | 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가 용량 계획과 변경을 제안하고 사업 책임자가 비용·위험을 승인한다. |
WordPress 공식 문서는 Backup이 Database와 Files를 함께 다뤄야 하며 빠르게 복구할 방법을 알아야 한다고 설명한다. NIST는 Backup 파일을 생성하는 데서 끝내지 않고 유지하고 시험할 것을 권고한다. 따라서 “Backup 제공”과 “정해진 시간 안에 복구 가능”은 같은 상태가 아니다.
통제와 비용 책임
| 비교 축 | 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 계약 사이에 업무가 빠질 때 생긴다. |
직접 운영이 항상 저렴하지 않은 이유는 Server 요금과 총운영비가 다르기 때문이다. 반대로 관리형 상품이 모든 조직에서 경제적인 것도 아니다. 사용하지 않는 Platform 기능, Traffic 기준 과금, Add-on, 제약으로 인한 재개발 비용이 생길 수 있다.
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 HostO: Infrastructure Operator — 직접 운영에서는 내부 담당자, 관리형 인프라에서는 계약된 운영자| 운영 업무 | 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 |
이 Matrix는 기본 모델이다. 계약에 Plugin Update, WordPress Maintenance, Application Monitoring, 24시간 Incident Response가 명시되면 일부 R과 A가 바뀔 수 있다. 반대로 계약서에 “서버 관리”만 적혀 있다면 Core·Plugin·Application 업무가 Operator에게 넘어갔다고 해석해서는 안 된다.
RACI의 A는 여기서 운영상 Accountability를 뜻한다. 법적 손해배상 책임이나 SLA 책임은 실제 계약과 약관으로 별도 판단해야 한다.
관리형 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이 깨졌을 때 누가 대응할지까지 답할 수 있어야 한다.
관리형 인프라가 맞는 경우
다음과 같은 상황에서는 관리형 인프라를 검토할 수 있다.
Server·OS·Runtime의 통제권은 유지하고 싶지만 내부 인프라 운영 인력이 부족하다.
여러 WordPress 사이트나 다른 Application을 하나의 운영 기준으로 관리해야 한다.
Backup, Monitoring, Patch, Incident의 운영 주체를 외부 또는 별도 Platform Team으로 통합하려 한다.
Hosting Platform의 Plugin·Server 제약보다 이식성과 구성 자유도가 중요하다.
WordPress Application을 맡을 개발자·에이전시는 별도로 존재한다.
다만 관리형 인프라만 계약하고 WordPress Application Owner를 정하지 않으면 새로운 공백이 생긴다. Operator는 서버가 정상이라고 보고하고 개발자는 서버 문제라고 판단하며 사업 담당자는 어느 쪽에 요청해야 할지 모르는 상황이다.
가격은 월 서버비가 아니라 총운영비로 비교해야 한다
세 모델을 비교할 때는 다음 식을 사용해야 한다.
WordPress 총운영비
=Hosting·Infrastructure 요금 + Managed Service 요금 + Update·Compatibility Test 시간 + Backup·Monitoring·Security 도구 + On-call·Incident 대응 + Restore Drill + 변경 실패·중단 비용 + 운영 인계·Exit 비용
직접 운영은 Hosting 요금만 보면 가장 저렴할 수 있다. 그러나 담당자의 Patch 시간, Monitoring 도구, 야간 장애 대응, 복원 시험과 문서화가 추가된다.
관리형 WordPress 호스팅은 많은 기능을 묶어서 제공하지만 Traffic·Storage·Site 수·Add-on·Support Plan에 따라 비용 구조가 달라질 수 있다.
관리형 인프라는 Server 비용과 운영비를 분리해 볼 수 있지만 WordPress Application 유지보수까지 포함하려면 별도 범위와 비용이 필요하다.
어느 방식이 싸다고 일반화할 수 없다. 현재 팀이 이미 보유한 역량, 사이트의 실패 비용, 지원 시간, 변경 빈도와 통제 요구를 함께 계산해야 한다.
계약 전에 답을 받아야 할 12가지 질문
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의 연락과 인계 순서
이 세 가지가 정해져 있다면 세 모델 중 어느 것을 선택해도 운영 구조를 설명할 수 있다. 반대로 이것이 없다면 ‘관리형’이라는 이름이나 낮은 월 요금만으로는 누가 사이트를 복구할지 알 수 없다.