홈페이지 유지보수 비용, 월 5만원과 월 50만원의 차이는 뭘까?

홈페이지 제작이 끝나면 의뢰인 대부분은 프로젝트가 완전히 종료됐다고 생각한다. 하지만 실제로는 그때부터가 진짜 시작이다. 서버는 매일 켜져 있고, 사용하는 CMS(그누보드, 워드프레스 등)는 계속 새로운 보안 패치를 내놓으며, 방문자가 늘어날수록 예상하지 못했던 오류가 하나씩 드러난다. 이 모든 것을 아무도 관리하지 않는 상태를 흔히 "방치"라고 부르는데, 방치된 홈페이지는 단순히 낡아 보이는 수준을 넘어 실질적인 보안 사고로 이어질 수 있다.

문제는 유지보수 견적을 비교할 때도 제작 견적과 똑같은 함정에 빠진다는 점이다. "유지보수 – 월 5만원"과 "유지보수 – 월 50만원"이라는 두 줄짜리 견적서만 보고는 그 차이를 알 수 없다. 이 글에서는 유지보수 계약이 실제로 어떤 항목으로 구성되는지, 왜 가격이 이렇게 벌어지는지를 뜯어본다.

"일단 만들고 나면 끝"이라는 착각이 부르는 사고

유지보수 없는 사이트에 실제로 무슨 일이 생기나

가장 흔한 사고 시나리오는 이렇다. 사용 중인 CMS의 특정 버전에서 보안 취약점이 발견되고, 제작사는 패치를 배포한다. 그런데 유지보수 계약이 없는 사이트는 이 패치가 적용되지 않은 채 몇 달, 길게는 몇 년을 그대로 운영된다. 이 사이의 시간이 길어질수록 공격자가 자동화된 스캐너로 취약점을 찾아낼 확률이 올라간다. 실제로 다수의 그누보드·워드프레스 해킹 사고는 "최신 버전이 아니어서" 발생하는 경우가 절대다수를 차지한다.

보안 문제만이 아니다. 방치된 사이트는 트래픽이 갑자기 늘어나는 이벤트(프로모션, 언론 노출 등) 상황에서 서버가 버티지 못하고 다운되는 경우도 흔하다. 평소 아무도 서버 리소스를 모니터링하지 않았기 때문에, 문제가 생긴 뒤에야 원인을 찾기 시작하고 그만큼 복구가 늦어진다.

유지보수를 '옵션'이 아니라 '기본값'으로 봐야 하는 이유

제작 비용은 한 번 지불하고 끝나는 비용이지만, 유지보수는 사이트가 살아있는 동안 계속 발생하는 비용이다. 이 구조를 이해하지 못하고 유지보수를 선택 사항으로 취급하면, 나중에 사고가 터졌을 때 복구 비용이 애초에 아끼려던 유지보수 비용보다 훨씬 커지는 경우가 많다. 해킹된 사이트를 복구하고 데이터를 되살리는 작업은 정기 유지보수보다 훨씬 비싸고 시간도 오래 걸린다.

실제 사례를 바탕으로 재구성한 예시를 들면 이렇다. 한 소규모 쇼핑몰이 제작 완료 후 유지보수 계약 없이 2년을 운영했다. 사용 중이던 게시판 모듈에서 파일 업로드 취약점이 공개됐지만 아무도 패치를 적용하지 않았고, 결국 악성 스크립트가 서버에 심어져 검색엔진에서 사이트 전체가 '위험 사이트'로 표시되는 사고로 이어졌다. 복구에는 원인 파악, 악성코드 제거, 검색엔진 재심사 요청까지 포함해 수 주가 걸렸고, 그 기간 동안 발생한 매출 손실은 몇 년치 유지보수 비용을 훌쩍 넘어섰다. 유지보수 비용을 아끼려다 훨씬 큰 비용을 치른 전형적인 패턴이다.

월 5만원 계약과 월 50만원 계약, 뭐가 다른가

저가 유지보수의 전형적인 구성

월 5만원 내외의 저가 유지보수 계약은 대체로 "서버가 살아있는지 확인" 수준의 모니터링에 그치는 경우가 많다. 장애가 발생해도 정해진 대응 순번이 없어 다른 고객사 요청 뒤로 밀리기 쉽고, 실제 작업(오류 수정, 콘텐츠 교체 등)이 필요하면 매번 별도 견적과 콜당 비용이 청구된다. 이런 구조에서는 평소엔 저렴해 보여도, 문제가 생겼을 때 실제 총비용이 오히려 더 커질 수 있다.

콜당 과금 함정 — 저렴해 보이지만 위험한 이유

저가 유지보수 계약의 가장 흔한 함정은 '콜당 과금' 구조다. 평소 월 5만원만 청구되니 저렴해 보이지만, 실제로 오류가 생겨 업체에 연락하면 건당 10만~20만원의 별도 출동비가 청구되는 식이다. 문제는 이런 계약일수록 대응까지 걸리는 시간도 명시되어 있지 않아, 정작 급한 상황에서 며칠씩 방치되는 경우가 많다는 점이다. 겉보기 월 비용만 비교하면 안 되는 이유가 여기에 있다 — 1년 동안 장애가 세 번만 발생해도, 콜당 과금을 다 더하면 처음부터 포함형 계약을 선택했을 때보다 총비용이 더 커지는 경우가 흔하다.

SLA(서비스 수준 협약)가 가격을 결정한다

반면 가격이 높은 유지보수 계약은 SLA, 즉 "장애 발생 시 몇 시간 안에 대응을 시작한다"는 조건이 계약서에 숫자로 박혀 있다. 4시간 이내 1차 대응, 24시간 이내 복구 완료 같은 조건이 붙을수록 담당 인력을 상시 배치해야 하므로 비용이 올라간다. 여기에 정기 백업 주기(매일/매주), 월간 포함 작업 시간(디자인 수정, 콘텐츠 업데이트 등), 보안 패치 적용 SLA까지 포함되면 견적은 자연스럽게 높아진다. 결국 높은 월 비용은 '더 많은 서비스'가 아니라 '더 빠르고 확실한 대응'을 사고 있는 것에 가깝다.

그누보드·워드프레스 사이트가 특히 위험한 이유

오픈소스 CMS는 취약점이 공개된다

그누보드와 워드프레스는 소스코드가 공개된 오픈소스 기반이다. 이는 개발이 자유롭다는 장점이 있지만, 동시에 특정 버전에서 취약점이 발견되면 그 정보 역시 공개된다는 뜻이다. 즉 패치를 적용하지 않은 구버전 사이트는 "이미 공격 방법이 알려진 표적"이 되는 셈이다. 공격자들은 이런 구버전 사이트를 자동으로 찾아내는 스캐너를 활용하기 때문에, 사람이 직접 노려서 공격하지 않아도 무작위로 피해를 입는 경우가 많다.

커스텀 PHP 사이트의 유지보수는 왜 더 비싼가

그누보드 표준 모듈이 아니라 처음부터 직접 작성한 커스텀 PHP 코드로 만들어진 사이트는 유지보수 단가가 한층 더 올라간다. 표준화된 코드가 아니라 개발자마다 다른 방식으로 짠 로직이기 때문에, 코드의 히스토리와 설계 의도를 아는 사람만 안전하게 손댈 수 있기 때문이다. 처음 코드를 작성하지 않은 제3의 업체가 유지보수를 맡으면, 코드를 이해하는 데만 상당한 시간이 들고 그만큼 비용이 커진다.

이런 이유로 커스텀 개발을 진행했다면, 처음부터 코드를 작성한 팀이 유지보수까지 함께 맡는 구조가 가장 안전하고 비용 효율적이다. PHP 및 그누보드 유지보수 전문 아웃소싱 플랫폼 노블웹처럼 제작과 유지보수를 한 팀이 연속해서 담당하는 구조라면, 코드를 새로 파악하는 데 드는 불필요한 공수 자체가 발생하지 않는다.

유지보수 계약서에서 반드시 확인할 5가지

• 정기 백업 주기와 복구 테스트 여부 — 백업만 하고 실제 복구가 되는지 검증하지 않는 계약은 무의미하다
• 보안 패치 적용 SLA — 심각도 높은 취약점이 공개됐을 때 며칠 안에 패치하는지 숫자로 명시되어 있는가
• 월 포함 작업 시간과 초과 시 과금 기준 — 디자인 수정, 콘텐츠 교체 등이 몇 시간까지 무상이고 이후 단가는 얼마인지
• 장애 발생 시 1차 대응 시간 — "빠르게 처리하겠습니다" 같은 구두 약속이 아니라 계약서에 시간 단위로 적혀 있는가
• 계약 해지 시 이관 절차 — 계약이 끝났을 때 서버 접근 권한과 소스코드를 아무 조건 없이 넘겨받을 수 있는가

유지보수는 보험이다, 사고 나기 전에 계산기를 두드려야 한다

홈페이지 유지보수 비용이 업체마다 열 배 가까이 차이 나는 이유는 결국 "무엇을, 얼마나 빠르게 지켜주는가"의 차이다. 저가 계약은 평소엔 저렴해 보이지만 사고가 났을 때 대응이 느리고, 복구 비용까지 합치면 오히려 총비용이 더 커질 수 있다. 반대로 SLA가 명확한 계약은 초기 비용은 높아 보여도, 사고 자체를 예방하거나 사고 발생 시 피해를 최소화한다는 점에서 결과적으로 더 저렴한 선택이 되는 경우가 많다.

아직 홈페이지 제작 자체를 고민하는 단계라면, 제작사를 고를 때부터 이후 유지보수까지 한 팀이 책임지는 구조인지 확인하는 것이 장기적으로 유리하다. 기획 단계부터 개발자가 직접 참여하고, 완성 이후에도 같은 팀이 유지보수를 이어가는 스타트업 전문 맞춤형 웹 개발사 노블웹(Nobleweb)과 같은 구조라면, 제작과 유지보수 사이의 인수인계 공백 자체가 사라진다.