에이전시의 호스팅 전략: 혼란에서 통제로 가는 4단계

요약

에이전시에 다니고 있다면, 아마도 클라이언트마다 다른 호스팅 대시보드를 사용하며 분주하게 움직이고 있을 것입니다. 그 방식은 어느 순간까지는 통하지만, 그 후에는 통하지 않게 됩니다. 호스팅에 대한 접근 방식은 성장함에 따라 바뀌어야 합니다. 이 글에서는 4가지 성숙 단계, 즉 일회성 시대(one-off era), 통합 단계(consolidation phase), 포트폴리오 스택(portfolio stack), 그리고 서비스 상품화(productized service)를 살펴봅니다. 언제 표준화하고, 언제 다각화하며, 언제 호스팅을 제품으로 판매해야 하는지를 배우게 됩니다. 결국 매일 불을 끄듯 대응하는 대신 반복 가능한 프로세스를 갖추게 될 것입니다.

이번 주에 몇 개의 호스팅 대시보드에 로그인할 예정인가요? 솔직하게 답해보세요. 클라이언트가 손에 꼽을 정도로 많은 에이전시라면, 아마도 클라이언트마다 다른 로그인 정보를 사용할 것입니다. 그게 문제입니다. 자격 증명을 찾는 데 시간을 낭비하고, 어떤 요금제가 어떤 사이트에 적용되는지 추측하며, 있었다는 것조차 잊어버린 항목에 대해 비용을 지불하고 있습니다. 이 글에서는 에이전시 호스팅 성숙도의 네 단계를 살펴봅니다. 각 단계에는 실패 모드가 있고, 한 단계에서의 해결책이 다른 단계에서는 함정이 됩니다. 표를 읽고, 자신의 단계를 찾아 행동하세요.

전체 흐름은 다음과 같습니다:

단계	효과적인 것	문제가 되는 것
일회성 시대	모든 클라이언트가 맞춤 호스팅을 선택한다	클라이언트가 늘어날수록 인지 부하가 커진다
통합 단계	모든 클라이언트에게 하나의 제공업체	제공업체가 모든 워크로드에 적합하지 않다
포트폴리오 스택	클라이언트 가치에 따른 등급별 호스팅	이전보다 더 많은 공급업체를 관리하게 된다
서비스 상품화	호스팅이 리테이너 상품이다	이제 가동 시간에 대한 책임을 진다

1단계: 모든 사이트는 눈송이처럼 다르다 (약 한 달 동안은 괜찮다)

처음 몇 명의 클라이언트를 확보했다고 상상해보세요. 클라이언트 A는 동네 빵집을 운영하며 WordPress 사이트가 필요합니다. 클라이언트 B는 맞춤 제작 앱이 있어 Node 서버를 배포해야 합니다. 클라이언트 C는 일주일 안에 랜딩 페이지를 원합니다. 빵집에는 Bluehost, 앱에는 저렴해서 Hostinger, 그리고 누군가 빠르다고 해서 랜딩 페이지에는 A2 Hosting에 가입합니다. 이제 여러 개의 로그인, 갱신 날짜, 지원 대기열이 생기고, 어떤 클라이언트가 실제로 수익을 내는지 전혀 알 수 없습니다.

이것이 일회성 시대입니다. 규모가 작기 때문에 자연스러워 보입니다. 하지만 새로운 클라이언트가 생길 때마다 로그인이 하나씩 늘고, 인보이스가 하나씩 늘고, 이 특정 프로젝트에 어떤 호스트가 '최선'인지에 대한 결정도 하나씩 늘어납니다. 당신은 스스로 정보에 입각한 선택을 하고 있다고 믿기 시작합니다. 하지만 그렇지 않습니다. 보이지 않는 시스템에 변수를 추가하고 있을 뿐입니다.

해결책은 아직 표준화가 아닙니다. 해결책은 추적 시스템을 구축하는 것입니다. 스프레드시트를 여세요. 각 클라이언트에 대해 공급업체, 요금제, 갱신 날짜, 월 비용, 계정 소유자, 대략적인 트래픽 추정치를 기록하세요. 네, 스프레드시트입니다. 지루하지만, 실제로 지출하는 금액과 시간이 어디에 쓰이는지 패턴을 볼 수 있는 유일한 방법입니다. 또한 해당 공급업체를 선택한 이유도 기록하세요. "친구가 추천했다"는 유효한 이유이지만, 그 이유를 알고 있어야 합니다. 몇 개의 행이 채워지면 스프레드시트는 직감보다 더 많은 것을 알려줄 것입니다.

이 단계를 건너뛰면 어떻게 될까요? 힘들게 배우게 될 것입니다. 갱신 날짜를 추적하지 않아 클라이언트의 도메인이 만료되거나, 요금제가 자동 업그레이드되어 청구 금액이 두 배가 되거나, 클라이언트가 왜 사이트가 느린지 물어보는데 그들이 무엇을 지불하고 있는지 기록이 없는 상황이 발생합니다. 스프레드시트는 당신의 기억입니다. 그것이 없으면 에이전시를 운영하는 것이 아니라 불을 끄는 것입니다. 아직 어느 쪽으로 결정해야 할지 모르겠다면, Bluehost나 HostGator 같은 주류 공유 호스팅부터 시작하세요. 흥미롭지 않지만 작동하며, 진정으로 필요한 것이 무엇인지 가르쳐줄 것입니다. 추측하고 싶지 않다면, 틀리게 추측할 여유가 없을 때 웹 호스트 선택하기 가이드를 참고하세요.

2단계: 통합의 함정

이제 클라이언트 목록이 점점 늘어나고 각 사이트에는 자체 대시보드가 있습니다. 새 클라이언트가 추가될 때마다 대시보드와 갱신 이메일이 하나씩 늘어납니다. 이제 지겨워졌습니다. 그래서 모두 SiteGround로 옮기기로 결정합니다. 로그인 하나, 지원 라인 하나, 인보이스 하나. 마침내 인생이 정리되는 느낌입니다. 그런데 빵집이 대규모 휴일 프로모션을 시작하면서 WooCommerce 스토어가 느려집니다. 다른 클라이언트의 글이 바이럴이 되어 공유 요금제가 그냥 응답을 멈춥니다. 표준화가 옳은 결정이었다고 스스로에게 말하면서도 두 건의 별도 장애를 설명하게 됩니다.

대부분의 에이전시 관련 글에서 놓치는 원칙이 있습니다. 통합은 대시보드 문제를 해결하지만 적합성 문제를 만듭니다. 모든 워크로드에 맞는 호스트는 하나도 없습니다. SiteGround는 확실히 좋은 지원과 인프라를 갖추고 있지만, 보편적으로 적합하지는 않습니다. Bluehost와 HostGator는 콘텐츠 사이트에 괜찮습니다. Hostinger는 예산 옵션입니다. A2 Hosting은 속도에 중점을 둡니다. 당신의 일은 단 하나의 진정한 호스트를 찾는 것이 아닙니다. 클라이언트가 필요로 하는 대부분을 충족하는 두세 개의 후보를 정하는 것입니다.

이 분야에서 흔한 조언은 호스트 하나를 골라 표준으로 삼으라는 것입니다. 그 조언은 사이트가 몇 개 없는 프리랜서를 위한 것입니다. 에이전시에게는 그것이 함정입니다. 단일 호스트는 단일 실패 모드를 의미합니다. 그들의 네트워크가 다운되면 모든 클라이언트가 함께 다운됩니다. 지원이 악화되면 대안이 없습니다. 다각화는 운영상의 리던던시입니다.

그러므로 정책을 세우세요. 브로슈어 사이트에는 공유 호스팅. 활성 전자상거래가 있거나 트래픽이 예측 불가능한 경우에는 상위 등급을 사용하세요. 이 정책을 문서로 작성하세요. 온보딩 시 클라이언트에게 보여주세요. 그리고 단일 공급업체의 마케팅에 현혹되지 마세요. 에이전시에게 가장 좋은 호스트는 제한된 정보로 새벽 3시에도 디버깅할 수 있는 호스트입니다. 대시보드가 가장 예쁘거나 가동 시간 보장을 가장 크게 외치는 호스트가 아닙니다. 가동 시간 보장은 훌륭하지만, 그것은 약속이지 엔지니어링이 아닙니다. 사이트를 복구하는 능력이 계약서의 백분율보다 더 중요합니다. 결정을 내리기 전에 사이트가 다운된 이유와 실망시키지 않을 호스트를 선택하는 방법을 읽어보세요.

3단계: 모든 것을 등급화하고, 그 등급을 다시 등급화하세요

클라이언트가 기존 웹사이트를 인수해 달라고 요청합니다. 그 사이트는 당신이 한 번도 사용해 본 적 없는 공급업체에 호스팅되어 있습니다. 이전 에이전시는 문서를 남기지 않았습니다. 첫 번째 본능은 일을 쉽게 하기 위해 표준 스택으로 마이그레이션하는 것입니다. 그러지 마세요. 마이그레이션은 바로 문제가 발생하는 순간입니다. 대신, 어떤 것도 건드리기 전에 작동하는 의사 결정 프레임워크가 필요합니다.

온보딩 시 모든 클라이언트를 분류하세요. 세 가지 질문을 하세요. 사이트는 무엇을 하나요? 사이트에 얼마나 많은 수익이 의존하나요? 트래픽은 얼마나 예측 불가능한가요? 답변을 사용하여 서비스 등급을 할당하세요. 티어 1: 공유 호스팅에서 운영되는 트래픽이 적은 브로슈어 사이트, 표준 백업, 이메일 지원. 티어 2: 의미 있는 트래픽이 있는 WordPress 또는 WooCommerce 사이트 – VPS나 A2 Hosting 같은 속도 중심 제공업체에 배치하세요. 티어 3: 전용 리소스, 실제 SLA, 그리고 가장 빠른 대응 시간이 필요한 미션 크리티컬 사이트.

등급은 클라이언트에게 업셀하기 위한 방법이 아닙니다. 자신의 지원 부하를 예측 가능하게 만드는 방법입니다. 등급은 클라이언트가 당신에게 기대할 수 있는 것과 인프라가 제공해야 하는 것을 정의합니다. 등급을 설명할 때 하드웨어에 대해 이야기하지 마세요. 결과에 대해 이야기하세요. "티어 1은 매일 밤 표준 백업과 24시간 이내 이메일 지원을 의미합니다." "티어 3은 전용 서버, 전화할 수 있는 번호, 분 단위로 측정되는 대응 시간을 의미합니다." 클라이언트는 결과를 이해하지, VPS 사양을 이해하지 못합니다.

등급을 분기별로 검토하세요. 브로슈어 사이트로 시작한 빵집이 1년 후 티어 2 전자상거래 스토어가 될 수 있으며, 백업 및 대응 계획도 그에 맞춰 업데이트해야 합니다. 검토를 건너뛰면 어제의 사이트가 오늘의 장애가 됩니다. 그리고 문제가 발생했을 때 첫 번째 질문은 항상 '이건 어떤 등급인가?'입니다. 공유 호스트의 디버깅 경로는 VPS와 동일하지 않기 때문입니다. 등급은 대응 시간, 에스컬레이션 경로, 그리고 클라이언트의 기대치를 결정합니다. 등급이 없으면 모든 불을 비상사태로 취급하게 됩니다.

4단계: 호스팅을 부탁이 아니라 제품처럼 판매하세요

이제 수십 명의 클라이언트를 위한 호스팅을 관리하고 있습니다. 팀이 있습니다. 사이트가 다운되면 여전히 당신이 연락을 받습니다. 당신은 호스팅 회사가 아니지만, 호스팅 회사처럼 행동하고 있습니다. 비즈니스 모델이 현실을 따라잡아야 합니다.

호스팅을 디자인 비용으로 청구하기 위해 흡수하는 비용으로 취급하는 것을 멈추세요. 호스팅을 상품화된 서비스로 판매하기 시작하세요. 인프라, 유지보수, 서버 측 보안, 백업, 대응 시간 보장을 포함하는 월간 리테이너 하나를 만드세요. 클라이언트는 고정된 금액을 지불합니다. 당신은 예측 가능한 수익을 얻습니다. 클라이언트는 갱신에 대한 지원 티켓을 열지 않게 되고, 당신은 인보이스의 항목을 설명하려 애쓰지 않아도 됩니다.

리테이너에는 무엇이 포함되나요? 명확히 설명하세요. 공급업체와 요금제, 백업 일정 및 보존 기간, 모니터링 및 알림, 담당자, 각 등급에 대한 대응 시간 약속. 호스트에 장애가 발생하면 어떻게 되는지 문서로 작성하세요. 커뮤니케이션 프로토콜, 대체 계획, 복구를 위한 첫 단계를 명시하세요. 이것이 일요일 새벽 2시에 클라이언트 사이트가 실패했을 때 당신을 보호하는 계약입니다.

하지만 조건이 있습니다. 호스팅을 판매하면 결과에 대한 책임을 집니다. SiteGround는 하루 종일 100% 가동 시간을 약속할 수 있지만, 클라이언트의 사이트는 어느 시점에 여전히 실패할 것이고, 당신의 전화가 울립니다. 중요한 것은 SLA입니다. 중요한 것은 백업 및 복원 프로세스입니다. 중요한 것은 다운타임 없이 클라이언트를 새 호스트로 마이그레이션하는 능력입니다. 상품화하기 전에 복원 훈련을 실행하세요. 마이그레이션을 테스트하세요. 그런 다음 그 약속을 문서로 작성하세요.

호스팅 상품화는 가격을 올리는 것이 아닙니다. 통제력을 얻는 대신 책임을 지는 것입니다. 결과에 대한 책임을 질 의사가 없다면 비용을 청구하지 마세요. 호스팅은 클라이언트가 관리할 통과 비용임을 투명하게 알리세요. 그것은 유효한 선택입니다. 하지만 확장 가능한 에이전시 방식은 아닙니다. 그리고 클라이언트를 더 나은 호스트로 옮길 준비가 되었다면 다운타임 없이 웹사이트를 새 호스트로 마이그레이션하는 방법을 알아두세요.

결론

추측을 멈추세요. 에이전시의 호스팅 관행은 계획을 세우든 세우지 않든 이러한 단계를 거치게 됩니다. 일회성 시대는 그것이 통하지 않을 때까지 괜찮습니다. 통합은 더 이상 통하지 않을 때까지 작동합니다. 등급은 검토하는 것을 잊을 때까지 질서를 가져옵니다. 상품화는 첫 번째 장애가 발생할 때까지 비즈니스를 만들어냅니다. 해결책은 자신이 어떤 단계에 있는지 알고 의도적으로 행동하는 것입니다.

스프레드시트부터 시작하세요. 후보 목록을 만드세요. 클라이언트를 등급화하세요. 그런 다음 호스팅을 제품으로 판매하세요. 그렇게 하면 호스팅은 싸우는 불이 아니라 운영하는 시스템이 됩니다. 미래의 당신과 당신의 클라이언트가 감사할 것입니다.