'완료' 웹사이트는 신화입니다: 상사에게 유지보수를 설득하세요

개요

대부분의 소규모 마케팅 팀은 출시를 결승선으로 여기지만, 라이브 웹사이트는 지속적인 책임이 따릅니다: 도메인 갱신, 호스팅 비용 지불, 소프트웨어 패치, 콘텐츠 업데이트가 필요합니다. 기술에 익숙하지 않은 상사에게 "더 많은 웹사이트 작업"으로 프레임을 잡으면 실패하고, "수익과 평판 보호"로 프레임을 잡으면 성공합니다. 이 기사는 출시 후 조용히 부패하는 사이트라는 실제 실패 모드를 살펴보고, 도메인 등록, 보안, 검색 가시성에 대한 구체적인 예를 들어 유지보수 예산에 대한 실용적인 근거를 제시합니다. 프로젝트에서 시스템으로의 사고 전환, 출시 후 반드시 수행해야 할 구체적인 작업, 그리고 실제로 상사를 설득하는 대화를 다룹니다. 또한 보안 논쟁이 해커로 시작해서는 안 되는 이유와 유지보수를 기술적 잡일이 아닌 비즈니스 성과에 연결하는 방법도 배우게 됩니다.

상사가 방금 웹사이트가 "완료"되었다고 선언했습니다. 그런데 왜 그 말에 배가 떨어질까요?

당신은 전에 이런 경험을 해봤을 것입니다. 4주 전에 출시했고, 하이파이브의 여운이 채 가시지도 않았습니다. 그런데 첫 수정 요청이 도착합니다 (가격 페이지에 오타가 있습니다). 그다음 영업 사원이 사이트가 Google에서 사라진 이유를 확인한 사람이 있는지 묻습니다. 그리고 비밀번호 관리자가 당신이 모르는 로그인에 대해 알림을 보냅니다. 치명적으로 고장난 것은 없지만, 그것이 바로 문제입니다: 사이트는 수백 가지 작은 방식으로 부패하고 있고, 상사는 라이브 사이트에 지속적인 작업이 필요하다고 말해주는 사람이 없었기 때문에 여전히 프로젝트가 끝났다고 믿고 있습니다.

그것이 진짜 간극입니다. 웹사이트 구축 가이드는 일반적으로 계획, 정보 구조, 와이어프레임, 디자인, 콘텐츠, 개발, 테스트, 출시를 다룹니다. 대부분의 새로운 웹사이트 소유자가 건너뛰는 계획 단계를 건너뛰게 만드는 것과 같은 간극이지만, 이번에는 출시 후의 단계입니다. 유지보수는 아홉 번째이자 보이지 않는 단계이며, 사이트가 자산으로 남을지 아니면 천천히 부채로 변할지를 결정합니다.

이 간극의 비용은 보이지 않다가 어느 순간 드러납니다: 제품 출시 중에 만료되는 도메인, 리디자인 일주일 전에 조용히 실패하는 백업, 한 달 동안 아무것도 수집하지 못한 양식. 그 어느 것도 극적이지 않습니다. 그러나 모두 비쌉니다.

빌드 모드와 라이브 모드는 다른 작업입니다

웹사이트를 관리하는 부동산처럼 생각해 보세요. 건물을 짓는 것은 프로젝트이고, 운영하는 것은 프로세스입니다. 창고를 지은 후 지붕을 점검하지 않고, 재고를 재주문하지 않으며, 직원이 퇴사할 때 자물쇠를 바꾸지 않을 것입니다. 웹사이트도 마찬가지로 행동하지만, 건축 자재가 디지털이고 비용이 적기 때문에 프로젝트/프로세스 구분이 사라집니다.

이 구분이 중요한 이유는 하나입니다: 상사가 승인하는 내용이 달라지기 때문입니다. 빌드 모드에서 목표는 "실제로 만드는 것"입니다. 라이브 모드에서 목표는 "신뢰할 수 있게 유지하는 것"입니다. 아래 표는 비기술적 이해관계자와 함께 사용하는 버전으로, "완료"로 느껴지는 각 항목이 사이트가 라이브된 후 실제로 무엇을 의미하는지 매핑합니다.

영역	상사가 "완료"라고 생각하는 의미	"완료"의 실제 의미
도메인	주소를 샀으니 우리 것이다	주소는 기간 동안 등록됩니다. ICANN의 프로세스 설명에 따르면 이름을 선택하고, 등록 대행사를 통해 가용성을 확인하고, 연락처 정보를 제공합니다. 이 정보는 갱신 알림을 받는 사람을 결정하므로 정확하고 모니터링되어야 합니다
호스팅	파일이 인터넷 어딘가에 있다	IBM은 웹 호스팅을 인터넷 접근을 위해 사이트 파일을 서버에 저장하는 것으로 정의합니다. 그 서버는 비용이 드는 지속적인 관계이며, 누군가 로그인 방법을 알아야 합니다
소프트웨어	최신 버전으로 출시했다	소프트웨어는 패치되고, 플러그인은 업데이트되며, 통합은 검토가 필요합니다. 이 모든 것은 출시 후에 발생하지 출시 전에 발생하지 않습니다
콘텐츠	카피가 승인되었다	콘텐츠는 시장과의 대화입니다. 제공 항목, 가격, 증거 자료, 제품 이름이 변경됨에 따라 콘텐츠는 낡아집니다
검색	Google이 우리가 존재한다는 것을 안다	검색 엔진은 다시 방문해야 합니다. XML 사이트맵에 새 URL을 추가하고, robots.txt 파일을 정확하게 유지하며, 기술적 기반이 건강하게 유지되어야 합니다

이 표는 두 가지 방식으로 읽을 수 있습니다. 잡일 목록으로는 압도적입니다. 웹사이트가 실제로 무엇인지 — 통제할 수 있는 입력이 있는 시스템 — 에 대한 설명으로는 명확합니다. 상사가 종결을 원하는 것은 틀린 것이 아닙니다. 그들이 종결의 모습에 대해 틀린 것입니다.

여기에 노코드 주의사항도 있습니다. 드래그 앤 드롭 빌더로 사이트를 구축했다면 플랫폼 공급업체가 서버 코드를 처리하지만, 콘텐츠, 액세스, 통합은 여전히 유지보수가 필요합니다. 노코드는 빌드 작업을 많이 제거하지만 라이브 모드 작업을 제거하지는 않습니다.

유지보수를 겁주는 이야기가 아닌 달력으로 만들기

그렇다면 어디서 시작할까요? 극적인 보안 프레젠테이션부터가 아닙니다. 가장 구체적이고 가장 감정적이지 않은 반복 작업부터 시작하고, 그 주변에 달력을 만드세요.

도메인을 예로 들어 보겠습니다. 설립자가 5년 전 개인 이메일 주소로 도메인을 등록했다고 상상해 보세요. 등록 대행사 대시보드는 한 사람만 아는 로그인 뒤에 있습니다. ICANN의 도메인 등록 프로세스는 이름 선택, 등록 대행사를 통한 가용성 확인, 연락처 정보 제공으로 시작하며, 그 연락처 정보가 등록 대행사와 실제 사람을 연결하는 끈입니다. 연락처 이메일을 모니터링하지 않으면 갱신 알림이 아무도 읽지 않는 사서함에 도착할 수 있습니다. 해결책은 기술적 개편이 아니라 스프레드시트 줄, 공유 받은 편지함, 갱신 3주 전의 달력 알림입니다. 지루합니다. 그래서 완벽한 첫 번째 항목입니다: 유지보수가 작고 관리 가능한 작업으로 이루어져 있음을 증명합니다.

이제 호스팅을 처리하세요. IBM의 설명은 간단해 보입니다 — 파일이 서버에 산다 — 하지만 모든 서버에는 저장 용량 제한, 대역폭 비용, 자격 증명이 있습니다. 호스팅을 설정한 사람이 도메인을 설정한 사람과 같고, 그 사람이 6개월 전에 떠났다면, 당신은 자신의 사이트에서 잠길 위험에 한 로그인 거리입니다. 유지보수 해결책은 모든 서비스를 하나의 문서로 옮기고, 누가 액세스 권한이 있는지 기록하고, 연례 감사를 예약하는 것입니다. 큰 예산을 요구하는 것이 아닙니다. 문이 잠기지 않도록 매달 한 시간을 요구하는 것입니다.

같은 논리가 의존하는 모든 서비스에 적용됩니다: 이메일 목록, 결제 처리업체, 양식 도구. 각각에는 로그인, 결제 주기, 원래 소유자가 떠날 경우 복구할 수 있는 사람이 있어야 합니다. 모두 하나의 표에 넣으세요. 달력으로 시작하는 것의 장점은 오래된 "그건 기술 문제다"라는 반론을 피할 수 있다는 것입니다. 갱신 및 액세스 검토 달력은 프로젝트 관리 문제이며, 비기술적 상사는 모두 프로젝트 관리를 이해합니다.

해커가 아닌 위협

보안 대화는 일반적으로 잘못된 악당으로 시작하기 때문에 실패합니다. "우리는 소규모 마케팅 사이트야."라고 스스로에게 말합니다. "아무도 우리를 노리지 않아." 그리고 아마도 당신 말이 맞을 것입니다. 그러나 가장 가능성 있는 위협은 표적 해커가 아닙니다. 방치입니다.

UpGuard의 웹사이트 보안 가이드는 표준 조치를 나열합니다: 소프트웨어 최신 상태 유지, 다중 요소 인증과 같은 강력한 인증 적용, 사용자 권한 제한, 데이터 백업, SSL/TLS 암호화 사용. 목록에서 무엇을 눈여겨보든 중요한 부분은 동사 시제입니다. 이는 출시일 체크리스트가 아닌 지속적인 관행입니다.

구체적으로 만들어 봅시다. 많은 사내 팀이 모든 사람이 사용하는 공유 관리자 로그인이 있는 사이트를 물려받습니다: 영업팀, 마케팅 인턴, 단일 블로그 게시물을 작성한 프리랜서. 아무도 그 프리랜서가 누구인지 모릅니다. UpGuard는 이를 사용자 권한 문제라고 부를 것입니다. 상사가 이미 이해하는 위험이라고 부를 수 있습니다. 누가 로그인할 수 있는지 모른다면 누가 홈페이지를 편집하고, 가격을 변경하고, 거기에 없어야 할 것을 설치할 수 있는지 알 수 없습니다. 해결책은 간단합니다: 비밀번호 재설정, 개별 계정 생성, 사람이 떠날 때 액세스 제거. 이것은 보안 프로젝트가 아니라 보안 잡일입니다.

역설적인 제안을 하겠습니다: 예산을 요청할 때 보안으로 시작하지 마세요. 소규모 팀에게 "보안"이라는 단어는 "IT 예산이 없다" 또는 "우리에게는 그런 일이 일어나지 않을 것이다"라는 반응을 불러일으킵니다. 실제로 행동을 유발하는 것은 구체적인 근접 실패입니다: SSL/TLS 인증서 만료로 인한 브라우저 경고, 실행되지 않은 백업, 여전히 로그인할 수 있는 이전 계약자. 이러한 구체적인 항목을 사용하여 월간 "사이트 건강" 블록에 대한 근거를 만드세요. 두려움을 파는 것이 아니라 역량을 파는 것입니다.

그리고 지금 새 사이트를 구축 중이라면, 첫날부터 SEO와 보안을 갖춘 노코드 사이트 출시를 다른 곳에서 다루었습니다. 그러나 첫날의 훈련은 12개월째의 훈련이 될 때만 효과가 있습니다.

검색은 당신을 기다리지 않습니다

사이트가 부패하는 두 번째 이유는 더 조용하며 사이트 외부에서 발생하기 때문입니다. 검색 엔진 최적화는 일회성 설정이 아닙니다. Digital Marketing Institute의 가이드는 SEO를 검색 순위, 사용자 경험, 브랜드 신뢰도를 개선하기 위해 콘텐츠, 구조, 기술적 요소를 최적화하는 것으로 설명합니다. "최적화"라는 단어는 완료된 상태가 아닌 시간에 따른 변화를 의미합니다.

현실적인 시나리오: 영업 책임자가 경쟁업체가 자사 제품 이름으로 당신보다 순위가 높은 이유를 묻습니다. 조사해 보니 XML 사이트맵이 출시 이후 업데이트되지 않았고, robots.txt 파일이 새 페이지 섹션을 차단하고 있음을 발견합니다. 둘 다 첫날에 완료된 것처럼 느껴졌던 기술 설정 작업입니다. 해결책은 10분짜리 월간 검토입니다: 사이트맵에 새 URL을 추가하고, 다시 제출하고, robots 파일이 최상의 콘텐츠를 숨기고 있지 않은지 확인합니다. SEO 지침에 대한 연구는 또한 HTTPS 보안이 기술 기반의 일부라고 지적합니다. 이는 방금 예약한 보안 잡일로 다시 연결됩니다.

검색 부패의 가장 나쁜 점은 점진적이라는 것입니다. 하루 만에 순위를 잃는 경우는 드뭅니다. 여기저기서 한 순위씩 잃다가 결국 경쟁업체가 페이지의 자리를 완전히 차지합니다. 검색은 또한 유지보수에 대한 최고의 비즈니스 논거입니다. 수익과 직접 연결되기 때문입니다. 검색 인프라를 유지하지 않는 사이트는 극적인 "해킹"으로 사라지는 것이 아니라 기술적 질서를 유지하는 경쟁업체에게 고객을 조용히 넘겨주는 것입니다.

수표를 쓰는 사람에게 유지보수 판매하기

이제 당신이 피해 온 대화로 이어집니다. 예산을 요청하거나 최소한 팀 달력에 여유를 요청해야 하며, 상사가 지루해하지 않고 "예"라고 말하게 만들어야 합니다.

수익 보호로 시작하세요. "기술 부채가 있습니다" 또는 "CMS를 업데이트해야 합니다"라고 말하지 마세요. "사이트는 가게 앞이고, 가게 앞은 정기적인 유지보수가 필요합니다"라고 말하세요. 앞서 만든 유지보수 달력을 증거로 사용하세요: 여기 갱신 날짜, 여기 액세스 검토, 여기 우리가 매달 실행하는 백업 테스트. 상사는 당신을 신뢰하라는 요청을 받는 것이 아니라 이미 실행 중인 시스템을 보여받는 것입니다.

그런 다음 선택권을 주세요. 두세 가지 등급을 제시하세요: 최소 유지보수(도메인, 호스팅, 백업, SSL), 건강한 유지보수(콘텐츠 업데이트와 검색 점검 추가), 적극적 성장(실험, 랜딩 페이지, 전담 지원 추가). 결정을 "얼마나 많은 돈을 쓸 수 있나요?"가 아닌 "어느 수준의 신뢰성을 원하십니까?"로 프레임하면, 상사는 기술 지출을 승인하는 것이 아니라 결과를 선택하는 것입니다.

한 가지 주의사항: 상사가 여전히 거절할 수 있습니다. 그런 경우, 상위 두 가지 위험(일반적으로 액세스 제어와 백업 검증)을 선택하고 여가 시간에 어쨌든 수정하세요. 거절을 무시하는 것이 아니라 유지보수가 측정 가능한 차이를 만든다는 것을 보여주기 위해 시간을 벌는 것입니다. 이것은 클라이언트 사이트 유지보수 성숙도 모델 뒤에 있는 것과 같은 논리입니다. "클라이언트"가 내부 이해관계자일 때도 마찬가지입니다. 이 모델은 사이트를 불이 꺼진 상태에서 프레임워크로 이동시키며, 2인 마케팅 팀에서도 에이전시만큼 잘 작동합니다.

완성된 웹사이트는 존재하지 않습니다

출시한 웹사이트는 운영하는 웹사이트가 아닙니다. 비즈니스가 변하고, 소프트웨어가 변하고, 웹 자체가 변하기 때문에 웹사이트도 변합니다. 유일한 진짜 질문은 작은 예산과 달력으로 의도적으로 그 변화를 관리할 것인지, 아니면 일련의 공황 속에서 우연히 관리할 것인지입니다.

가장 작은 구체적인 것부터 시작하세요: 달력 알림 하나, 공유 받은 편지함 하나, 계정 감사 하나. 그 화려하지 않은 작업은 오버헤드가 아닙니다. 그것들은 당신이 그토록 열심히 구축한 사이트가 조용히 녹슬지 않게 유지하는 것입니다. 상사가 다음에 무엇을 할지 묻는다면, 미소 지으며 달력을 보여주세요. 그것이 사이트의 진짜 지속적인 작업입니다.