저는 이번 리뷰를 위해 두 개의 WordPress 애플리케이션을 Cloudways Site Manager 에 등록했습니다. 하나는 애플리케이션 자체 사이드바 안에 있는 온보딩 화면을 통해, 다른 하나는 계정 수준에 있는 대량 흐름을 통해 등록했습니다.

그 후 네 개의 플러그인에 대해 실제 Safe Update를 실행하고, 두 사이트를 아우르는 공유 자동 업데이트 일정을 만들고, 활동 로그를 켠 다음, 계정 수준 대시보드에서 동일한 정보가 한 곳 이상에 어떻게 표시되는지, 그리고 그것이 왜 생각보다 더 중요한지 이해할 만큼 충분한 시간을 보냈습니다.

Cloudways

Cloudways에서 호스팅되는 WordPress 애플리케이션을 중앙 집중식 업데이트, Safe Updates, 활동 로그, 포트폴리오 전체 일정으로 관리하세요.

Cloudways 방문

Cloudways Site Manager란 무엇인가?

Site Manager는 이전의 Cloudways 애드온인 SafeUpdates를 대체했습니다. SafeUpdates가 할 수 없었던 일을 이해하면 현재 제품의 거의 모든 설계 결정을 설명할 수 있습니다.

SafeUpdates는 모든 작업을 SSH를 통해 실행했는데, 이는 두세 개 이상의 사이트를 관리하는 사람들에게는 특정한 문제를 만들었습니다:

• 대시보드가 없어서, 각 사이트를 하나씩 확인하지 않으면 어떤 사이트에 조치가 필요한지 알 방법이 없음
• 업데이트가 고정된 주간 일정에 묶여 있어, 클라이언트가 일일 패치를 원하든 월간 유지보수를 원하든 상관없이 동일하게 적용됨
• 시각적 회귀 테스트가 사이트당 데스크톱 페이지 3개로 제한되어 있어, 브로슈어 사이트를 넘어서면 커버리지가 매우 부족함
• 무엇이 언제, 누가 변경했는지 보여주는 감사 추적이 없음

20개 이상의 WordPress 설치를 관리하는 에이전시들은 Cloudways에, 이 도구는 규모가 커지기 전까지는 잘 작동하지만 확장에는 맞지 않는다고 사실상 전달했습니다. 그리고 확장 자체가 Cloudways를 선택한 핵심 이유였습니다.

Site Manager는 그 피드백에 대한 직접적인 답입니다. 이 맥락은 리뷰의 나머지를 읽는 데 중요합니다. Public Preview 단계에 있는 제품치고는 유난히 성숙해 보이는 부분과, 첫날 마주치게 될 온보딩 단계처럼 아직 덜 다듬어진 흔적이 남아 있는 부분이 왜 함께 존재하는지 설명해 주기 때문입니다.

Cloudways Site Manager는 무엇을 할 수 있는가?

이 배경을 바탕으로 다음 질문은 범위입니다: 이 도구가 실제로 어디까지 닿는가. 온보딩, 업데이트, 일정 설정으로 들어가기 전에 Site Manager가 무엇을 포함하고 무엇을 포함하지 않는지 정확히 짚어 두는 것이 좋습니다. 솔직한 답은 단순한 예/아니오보다 훨씬 복잡하기 때문입니다.

기본 대시보드는 Cloudways 전용입니다

계정 수준 Site Manager에 등록할 수 있었던 모든 애플리케이션은, 개별 앱 화면을 통해서든 Integrations 아래의 대량 마법사를 통해서든, 제 Cloudways 계정 안에 이미 존재하던 서버에서 가져온 것이었습니다.

외부 호스팅 설치본의 자격 증명을 붙여 넣는 입력란도 없었고, 다른 호스트에서 실행 중인 사이트를 연결하는 커넥터도 없었습니다.

이번 리뷰에서 다루는 전체 기능 세트인 Safe Update의 스테이징 클론, 시각적 회귀 테스트, 활동 로그, 대량 일정 설정 등은 모두 이 Cloudways 호스팅 기본 레이어 안에서 동작합니다.

별도의 플러그인이 더 가벼운 모니터링을 모든 사이트에 확장합니다

Cloudways는 또한 WordPress용 무료 플러그인인 Cloudways Site Manager를 제공하는데, WP Remote와 공동 개발되었습니다.

기본 대시보드와 달리, 이 플러그인은 호스팅 위치와 관계없이 WordPress 사이트에 직접 설치되므로, 동일한 중앙 집중식 보기의 한 형태에 외부 비-Cloudways 사이트를 가져올 수 있습니다.

하지만 이건 분명히 기본 대시보드와는 다른 제품이며, 둘 사이의 차이는 중요합니다:

이 플러그인은 활성화되어 있는 동안 WordPress 자체 자동 업데이트도 비활성화하는데, 이는 원격 관리 중 충돌을 피하기 위한 Cloudways의 의도적인 선택입니다.

Cloudways는 플러그인 경로를 최종 목적지라기보다 임시 단계로 분명히 설명합니다. 외부 사이트를 장기적으로 원격 관리하기보다는, 자동 백업, 원클릭 스테이징, Cloudflare 통합, 관리형 캐싱을 포함한 전체 스택을 원한다면 권장되는 최선의 방법은 해당 사이트를 Cloudways로 마이그레이션하는 것입니다.

전체 포트폴리오가 전부 Cloudways에 호스팅된 에이전시라면 이 모든 것은 중요하지 않습니다. 하지만 여전히 몇 개의 사이트를 다른 곳에서 운영하는 사람, 그리고 내가 지난 몇 년간 이야기한 대부분의 에이전시들이 적어도 몇 개는 그런 사이트를 가지고 있었습니다만, 그런 사람들에게 플러그인은 기본적인 모니터링과 업데이트를 위한 현실적인 선택입니다. 다만 기본 대시보드가 하는 일을 대신할 수는 없습니다.

Cloudways

Cloudways에서 호스팅되는 WordPress 애플리케이션을 중앙 집중식 업데이트, Safe Updates, 활동 로그, 포트폴리오 전체 일정으로 관리하세요.

Cloudways 방문

시작하기: 사이트를 온보딩하는 두 가지 방법

범위 문제가 정리되었으니, 이제 실무적인 부분이 시작됩니다. 실제로 WordPress 애플리케이션을 등록하는 일입니다. Cloudways는 기본 Site Manager로 들어가는 두 가지 방법을 제공하며, 이 둘은 같은 용도에 적합하지 않습니다.

경로 1: 애플리케이션 자체 사이드바를 통해

제가 처음 그곳에 도달한 방식은 다음과 같습니다. Cloudways 홈 대시보드에서 서버로 들어간 뒤, 그 서버에 있는 WordPress 애플리케이션을 클릭했고, 그러면 해당 앱의 Access Details 페이지로 이동했습니다.

왼쪽 사이드바에는 Access Details, Staging Management, Monitoring, Application Security, Domain Management가 나열되어 있고, 그 다음에 “New” 태그가 붙은 Site Manager가 있습니다. 그것을 클릭하자 “Simplify App Management with Site Manager”라는 제목의 화면으로 바로 이동했고, 하나의 애플리케이션만 범위로 한 채 Basic과 Pro 두 개의 플랜 카드가 나란히 보였습니다.

저는 Get Pro를 클릭했습니다. 그때부터 일이 꼬이기 시작했습니다.

화면은 “Subscribing to the Site Manager Plan…”으로 바뀌었고, Cloudways가 플러그인을 설치하고 사이트 데이터를 동기화하고 있으며, 이 작업은 애플리케이션 크기에 따라 몇 분 걸릴 수 있다는 안내가 표시되었습니다.

약 2분 동안 실행되다가 실패했고, 빨간 오류 알림으로 돌아갔습니다: “Please delete existing plugin and install again.” 저는 이전에 설치된 플러그인이 없었기 때문에, 이 메시지 자체만으로는 실제로 무엇이 잘못되었는지 알 수 없었습니다.

저는 아무것도 바꾸지 않은 채 같은 플랜 화면에서 Get Pro를 두 번째로 클릭했습니다. 그 시도는 성공했습니다. 약 3분 동안 실행된 뒤 초록색 성공 알림이 표시되며 Site Manager 플랜 구독이 완료되었다고 확인해 주었고, 앱의 Site Manager Overview 페이지로 이동했는데, 플러그인 수, 테마 수, 성능 점수, Manage Updates 표가 모두 채워진 상태였습니다.

경로 2: 계정 수준 대시보드를 통해

이건 사이트가 하나보다 많아지는 순간부터 써야 할 경로이며, 제가 정확히 찾아서 사용한 방식은 다음과 같습니다.

Cloudways 홈 대시보드에서 왼쪽 내비게이션에는 Home, Flexible, Autonomous, Integrations, Agency Partners 아이콘이 있습니다. 저는 Integrations를 클릭했습니다. 그러자 Site Manager(“New” 표시), Application Migration, DNS Made Easy, CookieYes, Equalize Digital Accessibility Checker 등이 있는 카드 패널이 열렸습니다.

Site Manager 카드를 클릭하자 경로 1과는 완전히 다른 화면으로 이동했는데, 이 화면은 Integrations → Add-Ons → Site Manager 아래에 있고, 자체 탭 행인 Overview, Manage Updates, Auto Updates, History를 가지고 있었습니다.

이 Overview 페이지가 진짜 지휘 센터입니다. 여기에는 계정 전체 통계인 Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates가 표시되고, 그 아래에는 이미 등록된 모든 앱을 나열하는 Manage Applications 표가 있습니다.

더 많은 앱을 가져오려면 표 오른쪽 상단의 Add Apps to Site Manager를 클릭했습니다. 그러자 두 단계 마법사가 열렸습니다:

1. Select Application(s): 아직 등록되지 않은 계정의 모든 WordPress 앱 목록이 체크박스 형태로 표시되며, Select All 옵션과 검색 필드가 있습니다.

목록 위의 안내문에는 스테이징 앱, 중지된 서버의 앱, 그리고 이미 이전 SafeUpdates 애드온을 실행 중인 앱은 제외된다고 적혀 있었습니다. 저는 원하는 앱을 체크하고 Select Plan을 클릭했습니다.

2. Select your Plan: Basic과 Pro가 다시 나란히 표시되며, 이번에는 선택한 애플리케이션 수와 해당 일괄 처리의 총 월 비용을 확인할 수 있었습니다. 저는 Pro를 선택하고 Enable Site Manager를 클릭했습니다.

마법사 화면에 도달한 뒤 전체 과정은 1분도 걸리지 않았고, 1단계에서 체크한 모든 앱에 한 번에 적용되었으며, 사이트마다 플랜 선택을 반복할 필요가 없었습니다.

아무도 경고하지 않는 간격

두 경로를 통해 앱을 등록해 본 뒤, 이 제품의 일상 운영 방식을 바꾸어 놓은 발견이 하나 있었습니다. 같은 서버에서 Site Manager가 이미 다른 앱 하나를 관리하고 있는 상태에서, 그 서버에 WordPress 애플리케이션 하나를 더 추가했습니다.

저는 새 앱이 자동으로 표시될 것이라고 예상했습니다. 왜냐하면 Site Manager가 이미 알고 있는 앱 바로 옆에 있었기 때문입니다. 하지만 그렇지 않았습니다. 계정 수준 대시보드의 “Total Apps on Site Manager” 숫자는 새 앱을 직접 온보딩하기 전까지 전혀 변하지 않았습니다.

이건 설계 의도이지만, 운영상 비용이 따르는 설계 의도입니다:

• 3~4개의 사이트를 관리하는 프리랜서에게는 새 사이트를 온보딩하는 걸 기억하는 것이 사소한 일입니다.
• 매주 또는 격주로 새 클라이언트 사이트를 만드는 에이전시에게는, 이것이 누군가의 체크리스트에 영구적으로 남는 반복 업무가 됩니다.
• 한 번 놓치면 그 사이트는 모니터링, 대량 업데이트, 활동 로그 바깥에 남게 되고, 원래는 단일 진실의 원천이 되어야 할 대시보드에서 보이지 않게 됩니다.

Cloudways

Cloudways에서 호스팅되는 WordPress 애플리케이션을 중앙 집중식 업데이트, Safe Updates, 활동 로그, 포트폴리오 전체 일정으로 관리하세요.

Cloudways 방문

실제로 무엇에 비용을 지불하는가

Site Manager는 정말로 쓸 만한 무료 티어와, 에이전시가 실제 워크플로를 구축할 만한 기능을 잠금 해제하는 Pro 티어로 나뉩니다.

Basic과 Pro, 기능별 비교

Basic은 기능이 줄어든 체험판이 아닙니다. 실제 사이트 개요, wp-admin을 건드리지 않고 사용자, 테마, 플러그인을 관리할 수 있는 기능, 원클릭 WordPress 싱글 사인온, Quick Updates, 그리고 특히 중앙 집중식 대시보드 자체를 포함합니다.

Cloudways는 핵심인 “모든 사이트를 한곳에서 보는” 경험을 유료 장벽 뒤에 두지 않았습니다. 유료로 제한된 것은 그 대시보드를 신뢰하고 관리할 수 있게 만드는 모든 기능입니다.

Pro는 현재 Public Preview 동안에는 표시된 가격과 관계없이 무료로 사용할 수 있으며, 정가는 앱당 월 $3이고 5개 애플리케이션을 넘으면 앱당 $2로 내려갑니다.

포트폴리오가 커질수록 Pro의 실제 비용

이 할인 기준은 Pro가 저렴하다고 단정하기 전에 계산해 볼 가치가 있습니다:

이 숫자들 중 어느 것도, 백업되지 않은 깨진 업데이트 하나가 클라이언트 신뢰에 미칠 수 있는 비용을 생각하면 터무니없지는 않습니다. 하지만 앱당 과금 방식은 포트폴리오가 커질수록 비용이 직선적으로 늘어나며, 더 높은 단계에서 더 큰 할인을 제공하는 경쟁 도구들처럼 계단식으로 내려가지는 않습니다.

같은 업데이트를 시작하는 세 가지 장소

등록과 가격 이야기를 마쳤으니, 이제 일상 사용이 실제로 어떤지 살펴볼 차례입니다. 먼저 알아둘 만한 구조가 하나 있습니다.

이것은 Site Manager 설계 중 가장 오래 이해하지 못했던 부분이며, 인터페이스 자체에는 어디에도 설명되어 있지 않습니다.

• 애플리케이션 자체의 Overview 페이지 에는 여전히 자체 Manage Updates 표가 있으며, 계정 수준 대시보드에서 볼 수 있는 것과 같은 보류 중인 플러그인 업데이트를 나열합니다.
• 계정 수준 대시보드의 행 단위 Actions 메뉴 에도 자체 Manage Updates 동작이 있으며, 같은 기본 데이터에서 불러옵니다.
• Auto Updates 탭 에서는 그와 같은 종류의 업데이트를 한 앱 또는 등록된 모든 앱에 대해 자동으로 실행되도록 일정 예약할 수 있습니다.

이것들은 같은 방으로 들어가는 세 개의 문입니다. 개별 앱 보기는 그 특정 사이트 안에서 이미 작업 중인 사람이 우연히 보류 중인 업데이트를 발견했을 때를 위한 것입니다. 계정 수준 행 동작은 전체 포트폴리오를 훑어보다가 지금 당장 하나의 사이트에 조치를 취하려는 사람을 위한 것입니다.

일정 설정 탭은 사람을 루프에서 완전히 제거하기 위한 것입니다.

Quick Update와 Safe Update

방금 설명한 세 개의 문 중 이 섹션은 첫 두 개, 즉 개별 앱 보기와 계정 수준 행 동작을 다룹니다. 둘 다 같은 업데이트 메커니즘을 열기 때문입니다.

모든 플랜 티어는 Quick Update를 제공합니다. 적용하는 데는 몇 초밖에 걸리지 않으며, 호환성 검사는 없고 사전 백업도 없이 업데이트가 바로 운영 환경에 설치됩니다.

Cloudways 자체 인터페이스 문구는 그 트레이드오프를 솔직하게 밝히며, 업데이트가 호환되지 않으면 “may carry risks if updates aren’t compatible.” 라고 경고합니다.

저는 이번 테스트에서 Quick Update를 실행하지 않았기 때문에, 실패했을 때 화면이 실제로 어떻게 보이는지 직접 설명할 수는 없습니다. 이는 이 리뷰의 실제 공백이며, 저나 실제로 실패 사례를 경험하지 않은 누구의 설명이든 적절한 수준의 의심을 가지고 보는 것이 맞습니다.

Safe Update는 Pro의 가치를 만들어 주는 핵심이며, 단순히 “백업 후 업데이트”라고 보기보다 전체 과정을 자세히 살펴볼 가치가 있습니다.

Safe Update 실행이 실제로 어떻게 보이는가

제가 정확히 어떻게 실행했는지는 다음과 같습니다. Integrations → Site Manager 아래의 계정 수준 Overview 표에서 보류 중인 업데이트가 있는 앱의 행을 찾아 끝부분의 세 점 Actions 메뉴를 클릭했습니다. 그러자 WP-Admin, App Overview, Manage Updates, Manage Plan 네 가지 옵션이 열렸고, 저는 Manage Updates를 클릭했습니다.

그러자 보류 중인 업데이트가 있는 모든 플러그인을 나열하는 모달이 열렸고, 제 경우에는 Breeze, Elementor, Object Cache Pro, WP ULike의 네 개가 있었으며, 각각 현재 버전과 업데이트될 버전이 체크된 항목으로 표시되었습니다.

목록 아래에는 Quick Update와 Safe Update 두 개의 라디오 옵션이 있었고, 각각 트레이드오프를 설명하는 한 줄짜리 설명이 붙어 있었습니다. 저는 Safe Update를 선택하고 Proceed를 클릭했습니다.

그다음 열린 모달은 하나의 진행 스피너가 아니라, 실시간으로 갱신되는 단계별 체크리스트를 보여줍니다.

Staging environment:

• Pre Snapshot
• Fetch Update Packages
• Update each plugin individually
• Post Snapshot
• Purge Cache
• Visual Regression

Production:

• 스테이징이 통과한 후 동일한 순서가 다시 반복되며, 마지막에는 캐시가 한 번 더 purge됩니다

저는 오후 6:21에 실행을 시작했고, 오후 6:27에 끝났습니다. 네 개의 플러그인에 대해, 스테이징에서 프로덕션까지 완전한 사이클을 거쳐 6분이 걸렸습니다. 모달 자체는 이 작업이 “usually takes less than a minute,”라고 안내하지만, 제 실행은 그 예상보다 훨씬 길었습니다.

표시된 예상 시간과 실제 시간 사이의 그 차이는, 여러 플러그인에 대해 Safe Update를 유지보수 시간에 실행할 때 특히 일정에 반영해 두는 것이 좋습니다. 초가 아니라 분 단위로 계획하세요. 플러그인 수가 늘수록 더 그렇습니다.

성공 알림이 결과를 확인해 주었고, 완료되는 순간 계정 수준 History 탭에는 “On-Demand Successful: Plugins (4)”로 기록되었으며, 전체 세부 정보로 연결되는 링크가 있었습니다.

그 과정을 지켜보고 즉시 그것의 영구 기록을 가리킬 수 있다는 점, 즉 조치가 일어나는 것을 본 뒤 바로 그에 대한 기록을 확인할 수 있다는 점은, 에이전시가 클라이언트에게 필요로 하는 바로 그런 증거이며, SafeUpdates에는 없던 것이었습니다.

업데이트의 유연성을 결정하는 두 가지 설정

이 둘은 둘 다 온디맨드 업데이트 화면이 아니라 일정 설정 흐름 안에 있어서 놓치기 쉽습니다:

• Visual Regression Sensitivity 는 스테이징 테스트와 프로덕션 사이의 시각적 차이를 얼마나 허용할지 제어하며, 레이아웃을 보호하기 위해 일정 비율을 넘으면 업데이트가 중단됩니다. 기본값은 가장 엄격한 설정인 “Critical, 0% difference.”입니다.
• Smart Skip for Plugin/Theme Update Failures는 기본적으로 활성화되어 있으며, 단일 플러그인 업데이트 실패가 전체 배치를 막지 않도록 합니다. 시스템은 실패한 항목 하나를 제외하고, 성공한 것들만 업데이트한 뒤, 성공한 변경 사항에 대해 시각적 회귀 검사를 실행하고, 그 변경 사항을 자동으로 운영 환경에 반영합니다.

이 두 기본값을 함께 보면, 야간 무인 업데이트 실행이 하나의 플래그된 플러그인만 큐에 남겨 두고 깨우는지, 아니면 호환되지 않는 테마 하나가 전체 프로세스를 중단시켜 사이트가 중간 상태에 멈추게 하는지를 결정합니다. 아무 일정이나 무인으로 맡기기 전에 두 설정 모두 확인할 가치가 있습니다.

Cloudways

Cloudways에서 호스팅되는 WordPress 애플리케이션을 중앙 집중식 업데이트, Safe Updates, 활동 로그, 포트폴리오 전체 일정으로 관리하세요.

Cloudways 방문

포트폴리오 전체에 걸쳐 한 번에 업데이트 예약하기

그것은 첫 두 개의 문을 다룬 내용입니다. 이 섹션은 세 번째 문, 즉 사람을 루프에서 완전히 빼는 기능을 다룹니다. 계정 수준 Site Manager 페이지에서 들어가는 Auto Updates 탭은 “여러 사이트를 하나처럼 관리한다”는 약속이 실제로 먹히는지, 아니면 무너지는지를 보여주는 곳입니다. 제 경우에는 잘 작동했습니다.

설정 방법은 다음과 같습니다. Integrations → Site Manager에서 상단 행의 Auto Updates 탭을 클릭했습니다.

아직 예약된 것이 없을 때 페이지는 빈 상태로, “No Auto Updates Schedule”와 단 하나의 버튼인 Set Auto Update Schedule을 보여주었습니다.

그 버튼을 클릭하자 “Set Auto Update Schedule” 마법사가 열렸고, 다음 단계를 한 번에 안내했습니다:

1. Day of Week and Schedule Time: 두 개의 드롭다운과 시간 입력 옆의 시간대 선택기. 저는 Friday, between midnight and 5:59am UTC로 설정했습니다.
2. Select Application: Site Manager에 이미 등록된 모든 앱의 체크리스트가 표시되며, Select All 옵션과 함께 선택된 앱 중 이미 기존 일정이 있는 경우 이 새 일정으로 대체된다는 안내가 있습니다. 저는 두 앱 모두를 선택하고 Choose Preferences를 클릭했습니다.

그다음 두 번째 화면인 “Create Auto Update Schedule”가 열렸고, 다음 항목을 다루었습니다:

3. Configure Update List: WordPress Core, Plugins, Themes의 세 개 접이식 섹션이 있으며, 각각 체크리스트와 선택된 항목 수가 표시됩니다. 제 두 앱 전체에서 선택 가능한 플러그인은 10개, 테마는 4개였고, 각 개별 플러그인과 테마에는 실제로 몇 개의 애플리케이션이 그것을 사용하는지까지 정확히 표시되어 있었습니다. 이는 수십 개의 사이트를 관리하면서 어떤 업데이트를 광범위하게 테스트할 가치가 있는지, 그리고 어떤 업데이트가 하나의 사이트에만 영향을 미치는지 판단할 때 매우 중요한 작은 디테일입니다.

4. Update Type: Quick Update 또는 Safe Update를 제공하는 드롭다운으로, 각각 온디맨드 모달에서 본 것과 같은 설명이 붙어 있습니다. Safe Update를 선택하면 그 모드에서만 보이는 추가 컨트롤인 Visual Regression Sensitivity와 Smart Skip for Plugin/Theme Update Failures가 나타났습니다.

5. Critical Updates: 기본적으로 꺼져 있는 토글로, 취약점이 발견되면 일반 일정과 별개로 보안 패치를 즉시 적용하는 용도입니다.

아래의 Set AutoUpdate Schedule를 클릭하자 저장되었고, 두 번째 단계에서 선택한 모든 앱에 적용되었으며, 사이트마다 구성을 반복할 필요가 없었습니다.

활동 로그: 실제로는 클라이언트 신뢰에 관한 부분

세 개의 문과 그 뒤의 업데이트 메커니즘은 어떻게 하는지를 설명합니다. 마지막 기능은 그 증거, 즉 업데이트 과정과는 별도로 무슨 일이 있었는지에 대한 영구 기록을 다룹니다.

이것을 켜는 방법은 다음과 같습니다.

경로 1을 통해 구독한 뒤 도착하는, 해당 앱의 Site Manager Overview 페이지에서 성능 링 옆에 “Activity Logs are Disabled”라고 표시된 카드가 있고, 짧은 설명과 단 하나의 버튼 Enable Activity Logs가 있습니다.

그것을 클릭하자 카드가 즉시 업데이트되었고, 확인 모달도 없고 추가 단계도 없었습니다. 바로 그 직후 Integrations → Site Manager 아래의 계정 수준 Manage Applications 표를 확인했더니, 해당 앱의 Activity Logs 열이 새로고침 없이 이미 Disabled에서 Enabled로 바뀌어 있었습니다.

이 기능은 Pro 뒤에 있으며, 에이전시가 결국 클라이언트에게 받게 되는 질문에 답하기 위해 존재합니다: 누가 무엇을 언제 바꿨는가?

이 기능이 없다면, 그 답은 보통 사이트 자체의 데이터베이스에 기록되는 WordPress 로깅 플러그인 안에 남는데, 이는 시간이 지나며 부풀어 오르고 변조로부터 보호도 되지 않습니다. WordPress 설치본 밖, 호스팅 레이어 안에 그 기록이 존재한다는 것은, 클라이언트 대상 사이트에 대해 확실히 다른 수준의 신뢰입니다.

Cloudways

Cloudways에서 호스팅되는 WordPress 애플리케이션을 중앙 집중식 업데이트, Safe Updates, 활동 로그, 포트폴리오 전체 일정으로 관리하세요.

Cloudways 방문

장단점

이것이 실제로 누구를 위한 것인가

전체 기능 세트, 비용, 그리고 거친 부분들을 모두 놓고 보면, 마지막 질문은 이 제품이 당신의 포트폴리오에 맞는지 여부입니다.

가장 잘 맞는 대상은 여러 개, 이상적으로는 많은 WordPress 사이트를 운영하는 에이전시나 프리랜서 개발자이며, 그 사이트들이 이미 전부 Cloudways 안에 있는 경우입니다. 이때 깨진 업데이트는 단순한 개인적 불편이 아니라 실제 클라이언트 신뢰 비용을 가져옵니다.

이것은 혼합 포트폴리오를 가진 사람에게는 부분적으로만 맞습니다. 무료 Site Manager 플러그인으로 외부 사이트의 기본 모니터링과 업데이트를 가져올 수는 있지만, 기본 대시보드를 유료로 만들 가치가 있는 기능들, 즉 스테이징 기반 Safe Update, 시각적 회귀, 활동 로그는 그 사이트들이 실제로 Cloudways로 옮겨지기 전까지는 사용할 수 없습니다.

단일 사이트 소유자에게는 그냥 불필요합니다. 무료 티어가 기술적으로는 작동하겠지만, 이 제품 전체는 단일 사이트가 만들지 않는 포트폴리오 규모의 문제를 해결하기 위해 존재합니다.

결론: 가치 있지만, Cloudways 안에서만

네, Site Manager는 채택할 가치가 있습니다. 단, 사이트가 이미 Cloudways에 있을 경우에만 그렇습니다. 그 범위 안에서 Site Manager는 약속한 바를 제공합니다. 실제 사이트 간 대시보드, 운영 환경을 건드리기 전에 백업하는 Safe Update 경로, 그리고 업데이트를 로그인마다 해야 하는 잡일이 아니라 전체 플릿 차원의 작업으로 취급하는 대량 일정 설정입니다.

그 경계 밖에서는, 명확한 마이그레이션 유도 메시지가 붙은 더 가벼운 도구일 뿐입니다. 가장 잘 맞는 대상은 클라이언트 사이트를 Cloudways로 통합하면서, 무엇이 언제 바뀌었는지 증명할 수 있는 한 곳이 필요한 에이전시입니다.

Cloudways

4.6

537 사용자 리뷰

₩14,760 /mo

시작가

Cloudways 방문

전문가 리뷰 기반 평점

• 사용자 친화성
  4.5
• 기술 지원
  4.6
• 기능
  4.8
• 신뢰도
  4.8
• 요금제
  4.3