Mapping WordPress Maintenance Tools
WordPress 유지관리 도구를 비교하는 것은 어렵습니다. 어떤 곳에서는 도구를 "SaaS"라고 부르고, 다른 곳에서는 "self-hosted"라고 부릅니다. 대부분의 사람들은 두 가지 서로 다른 개념을 하나의 라벨로 혼동하곤 합니다.
선택지를 이해하려면 두 가지 별개의 축을 살펴봐야 합니다.
Axis 1: 도구가 사이트에 연결되는 방식. • Worker Plugin: 관리하는 모든 사이트에 작은 플러그인을 설치합니다. 이는 대시보드가 사이트와 통신할 수 있는 게이트웨이 역할을 합니다. • Direct SSH: 사이트에 아무것도 설치하지 않습니다. 도구가 SSH를 통해 로그인하고 WP-CLI를 사용합니다.
플러그인 방식은 쉽지만 모든 사이트에 취약점을 추가하게 됩니다. SSH 방식은 깔끔하지만 호스트에서 SSH 접속을 허용해야 합니다.
Axis 2: 대시보드가 실행되는 위치. • Hosted SaaS: 벤더가 대시보드를 운영합니다. 벤더의 클라우드에 사이트 접속 정보(credentials)가 저장됩니다. • Self-hosted: 본인의 서버에서 대시보드를 실행합니다. 데이터는 본인이 소유하지만 소프트웨어는 직접 관리해야 합니다. • Desktop App: 대시보드가 로컬 컴퓨터에서 실행됩니다. 데이터는 본인의 기기에 머뭅니다.
이 두 축은 그리드를 형성합니다. 대부분의 제품은 단 두 개의 셀에만 위치합니다.
Hosted SaaS + Worker Plugin (ManageWP, WP Umbrella) 어떤 브라우저에서도 쉽게 접속할 수 있습니다. 벤더가 가동 시간(uptime)을 관리합니다. 단점은 고객의 접속 정보를 제3자에게 맡겨야 한다는 점입니다.
Self-hosted + Worker Plugin (MainWP, InfiniteWP) 데이터를 직접 보유합니다. 특정 벤더에 의존하지 않습니다. 단점은 대시보드 자체를 직접 유지 관리해야 한다는 점입니다. 즉, 도구를 관리하는 도구를 관리하게 됩니다.
Desktop App + Direct SSH (WP Maintenance Manager) 가장 프라이빗한 방식입니다. 클라이언트 사이트에 아무것도 설치되지 않으며 데이터는 PC에 남습니다. 단점은 컴퓨터가 절전 모드로 들어가면 모니터링이 중단된다는 점입니다.
다른 조합에는 주요 제품이 거의 없습니다. 예를 들어, 클라우드 벤더에게 SSH 키를 넘겨주는 경우는 드뭅니다. 이 때문에 "Hosted SaaS + SSH" 조합은 판매하기가 매우 어렵습니다.
도구를 선택할 때 다음 세 가지 질문을 던져보세요:
- 접속 정보를 제3자 클라우드에 둘 것인가, 아니면 로컬에 보관할 것인가?
- 모든 클라이언트 사이트에 플러그인을 설치할 것인가, 아니면 설치하지 않을 것인가?
- 직접 인프라를 운영할 준비가 되었는가?
완벽한 선택은 없습니다. 모든 옵션에는 위험, 제어권, 사용 편의성 사이의 트레이드오프가 존재합니다.