1. 개요 (Executive Summary)
홈페이지 유지보수는 있으면 좋은 부가 서비스가 아닙니다. 서버·도메인·SSL 인증서·CMS가 맞물려 돌아가는 시스템을 계속 살아 있게 하는 최소한의 운영 비용입니다. 자동차를 뽑아놓고 엔진오일을 한 번도 안 갈면 어떻게 되는지는 누구나 압니다. 홈페이지도 똑같이 망가집니다. 다만 그 과정이 눈에 안 보일 뿐입니다.
"홈페이지 유지보수 비용"을 검색해 들어온 분을 위해 답부터 적습니다. 국내 중소기업 홈페이지 기준, 월 정액 유지보수는 대략 5만 원대에서 50만 원대 사이에서 계약됩니다. 콘텐츠 수정만 맡기면 아래쪽, 보안 점검·모니터링·장애 대응까지 묶으면 위쪽입니다. 사이트 규모와 업체에 따라 편차가 크니 절대 기준이 아니라 견적을 읽는 눈금으로 쓰시면 됩니다. 세부 구조는 5장에서 다룹니다.
이 글이 답하는 질문은 셋입니다. 방치하면 실제로 무슨 일이 생기는가(2장). 보안은 최소한 어디까지 해야 하는가(3장). 업체에 맡긴다면 계약서에 무엇을 적어야 하는가(4~6장).
핵심 메시지
제작비는 한 번 내는 돈이고, 유지보수비는 그 투자를 지키는 돈입니다. 수백만 원을 들여 만든 홈페이지가 SSL 인증서 하나 만료되는 순간 "안전하지 않은 사이트" 경고 화면 뒤로 사라집니다.
사고가 난 뒤의 복구 비용은 예방 비용을 늘 앞지릅니다. 해킹당한 사이트의 악성코드 제거·재구축·신뢰 회복에 드는 돈과 시간을 생각하면, 월 몇만 원의 정기 점검은 보험 중에서도 싼 보험입니다.
2. 방치된 홈페이지에 일어나는 일
방치된 홈페이지는 서서히 낡다가 어느 날 사고로 터집니다. 순서도 대체로 비슷합니다. 아무도 안 들여다보는 동안 인증서가 만료되고, 구버전 플러그인에 봇이 들어오고, 도메인 갱신 메일이 스팸함에서 잠자다 기한을 넘깁니다. 하나씩 뜯어보겠습니다.
2.1 브라우저가 먼저 등을 돌린다: SSL 만료
SSL 인증서가 만료되면 방문자는 홈페이지 대신 "연결이 비공개로 설정되어 있지 않습니다"라는 전면 경고 화면을 만납니다. 회사 사정을 모르는 방문자에게 이 화면은 "위험한 사이트"라는 뜻입니다. 뒤로 가기를 누르고, 다시 오지 않습니다.
무료 인증서인 Let's Encrypt는 유효기간이 90일이라 자동 갱신 설정이 필수고, 유료 인증서도 결제 담당자가 바뀌거나 알림 메일이 묻히면 만료됩니다. 갱신 담당자를 정해두지 않은 사이트는 언젠가 한 번은 이 경고 화면을 띄우게 됩니다.
2.2 구버전 CMS는 공개된 침입 경로다
해커가 우리 회사를 콕 집어 노린다고 생각하면 오해입니다. 실제로는 자동화된 봇이 인터넷 전체를 훑으며 알려진 취약점이 남아 있는 구버전 사이트를 찾아다닙니다. 워드프레스 플러그인의 보안 결함은 발견되면 내용이 공개되고, 패치를 안 한 사이트는 그 순간부터 문 열린 창고가 됩니다.
침입 후 벌어지는 일은 다양합니다. 웹셸을 심어 서버를 장악하거나, 본문에 도박·성인 사이트로 가는 스팸 링크를 숨겨 넣거나, 방문자를 다른 곳으로 튕겨 보냅니다. 운영자는 몇 달 뒤 "구글에서 우리 회사 검색하면 이상한 페이지가 나온다"는 제보를 받고서야 알아챕니다.
2.3 도메인 만료는 복구가 안 될 수도 있다
도메인은 소유가 아니라 임대입니다. 갱신을 놓치면 유예 기간이 지난 뒤 제3자가 그 주소를 가져갈 수 있습니다. 등록 당시 결제한 카드가 만료됐거나, 갱신 알림을 받던 담당자가 퇴사했거나, 등록 메일 계정이 죽어 있는 경우가 흔한 원인입니다. 서버는 돈 주면 다시 세우지만, 뺏긴 도메인은 돈으로도 못 찾는 경우가 있습니다. 몇 년간 쌓은 검색 노출과 명함·간판에 박힌 주소가 한 번에 날아가는 사고입니다.
2.4 낡은 정보는 조용히 신뢰를 깎는다
사고까지 안 가더라도 방치의 흔적은 방문자에게 그대로 보입니다. 3년 전 날짜가 찍힌 "새 소식", 퇴사한 직원이 걸려 있는 조직도, 눌러보면 404가 뜨는 메뉴, 바뀐 지 오래된 전화번호. 방문자는 이 회사가 아직 영업 중인지부터 의심하게 됩니다. 거래처 실사 담당자가 홈페이지를 먼저 열어보는 시대에, 낡은 홈페이지는 없느니만 못한 순간이 옵니다.
2.5 검색 엔진도 방치를 알아챈다
검색 순위도 같이 내려갑니다. 깨진 링크, 느려진 응답 속도, 만료된 SSL, 갱신 없는 콘텐츠는 모두 검색 엔진이 낮게 평가하는 신호입니다. 해킹으로 스팸 페이지가 생성되면 더 심각합니다. 구글이 검색 결과에 "이 사이트가 해킹되었을 수 있습니다"라는 표시를 붙이고, 회사명으로 검색해도 도박 키워드 페이지가 먼저 뜨는 지경까지 갑니다. 여기서 회복하려면 악성코드 제거, 재검토 요청, 순위 회복까지 몇 달이 걸립니다.
사고는 겹쳐서 온다
SSL 만료를 아무도 몰랐다는 건, 그 사이트에 백업도 모니터링도 없다는 뜻일 가능성이 높습니다. 관리 공백은 한 군데만 뚫리지 않습니다.
그래서 해킹 사고 복구 의뢰의 상당수가 "백업이 없어서 처음부터 다시 만드는" 재제작 프로젝트로 끝납니다. 복구비가 아니라 제작비를 두 번 내는 셈입니다.
3. 보안 기본기: SSL부터 백업까지
중소기업 홈페이지 보안은 다섯 가지 기본기로 사고 대부분을 막습니다. HTTPS 유지, 백업과 복구 테스트, 관리자 계정 관리, 업데이트, 웹방화벽. 고가의 보안 솔루션 이야기가 아니라, 전부 지금 쓰는 서버에서 할 수 있는 일들입니다.
3.1 HTTPS는 켜는 게 아니라 유지하는 것
제작 시점에 SSL을 적용했다고 끝이 아닙니다. 확인할 것은 세 가지입니다.
- 자동 갱신 동작 확인: Let's Encrypt라면 갱신 스크립트(cron)가 실제로 돌고 있는지, 마지막 갱신 성공 로그가 있는지 확인합니다
- 만료 알림 이중화: 만료 30일 전 알림을 담당자 개인 메일이 아니라 공용 메일이나 메신저 채널로 받게 합니다. 담당자가 바뀌어도 알림은 살아 있어야 합니다
- 갱신 후 적용 확인: 인증서 파일만 갱신되고 웹서버가 재시작되지 않아 만료 경고가 뜨는 사례가 의외로 많습니다. 갱신 뒤 브라우저에서 실제 만료일을 확인합니다
3.2 백업, 정말 복구되나요?
복구해본 적 없는 백업은 백업이 아닙니다. 백업 파일이 있다는 것과 그 파일로 사이트를 되살릴 수 있다는 것은 다른 문제입니다. DB 덤프가 중간에 깨져 있거나, 파일은 있는데 DB가 빠져 있거나, 압축이 풀리지 않는 백업을 사고 당일에 발견하는 경우가 실제로 있습니다.
- 파일과 DB를 함께: 홈페이지는 소스 파일과 데이터베이스 두 덩어리입니다. 한쪽만 백업하면 복구가 안 됩니다
- 서버 밖에 보관: 같은 서버 안의 백업은 서버 장애·해킹과 함께 사라집니다. 다른 서버나 클라우드 스토리지로 내보내야 의미가 있습니다
- 복구 리허설: 분기에 한 번은 백업본으로 테스트 환경에 실제 복원해봅니다. 여기서 걸리는 시간이 곧 장애 시 복구 시간입니다
3.3 관리자 계정: 가장 싼 침입 경로
봇의 첫 시도는 취약점 공격이 아니라 로그인입니다. 아이디 admin에 흔한 비밀번호 조합을 무한 대입하는 방식이라, 계정 관리만 해도 큰 문을 하나 닫는 셈입니다.
- 아이디 admin, administrator 사용 금지 — 대입 공격의 절반은 아이디 추측에서 시작합니다
- 퇴사자·거래 종료 업체 계정 즉시 삭제 — 계정 목록을 분기마다 한 번씩 정리합니다
- 관리자 페이지 2단계 인증 적용, 가능하면 접근 IP 제한까지
- 여러 명이 하나의 계정을 공유하지 않기 — 사고 시 누가 무엇을 했는지 추적이 안 됩니다
3.4 업데이트를 미루는 비용
업데이트 대상은 CMS 코어와 플러그인만이 아닙니다. 서버의 PHP 같은 실행 환경도 포함됩니다. PHP는 버전별로 보안 지원 기한이 있어서, 예를 들어 PHP 7.4는 2022년 11월 이후 보안 패치가 끊겼습니다. 지원 종료된 버전 위에서 돌아가는 사이트는 새 취약점이 나와도 막을 방법이 없습니다.
"업데이트하면 사이트가 깨질까 봐" 미루는 심정은 이해할 수 있지만, 순서를 지키면 위험은 관리됩니다. 백업 먼저, 적용, 주요 페이지 동작 확인. 이 세 단계를 월 1회 반복하는 것이 유지보수 계약에서 업데이트 항목이 하는 일입니다.
3.5 웹방화벽, 생각보다 문턱이 낮다
웹방화벽(WAF)은 사이트 앞단에서 공격 패턴의 트래픽을 걸러주는 장치입니다. 대기업 전유물이 아닙니다. Cloudflare는 무료 플랜에서도 기본적인 공격 차단과 트래픽 필터링을 제공하고, KISA는 중소기업 대상으로 무료 웹방화벽 '캐슬(CASTLE)'과 웹셸 탐지 도구 '휘슬(WHISTL)'을 보급합니다. 호스팅사가 자체 WAF 옵션을 제공하는 경우도 많으니, 지금 쓰는 호스팅부터 확인해볼 만합니다.
목표는 완벽이 아니라 "쉬운 표적 탈출"
어떤 보안도 침입을 100% 막지는 못합니다. 하지만 자동화 봇은 가장 만만한 사이트부터 뚫습니다. 기본기 다섯 가지를 지킨 사이트는 봇의 우선순위에서 밀려납니다.
그리고 뚫리더라도 백업과 복구 절차가 있으면 사고는 "며칠짜리 복구 작업"으로 끝납니다. 없으면 "재제작 프로젝트"가 됩니다.
4. 유지보수 범위와 주기
유지보수는 크게 네 덩어리입니다. 콘텐츠 수정, 기술 업데이트, 모니터링, 장애 대응. 업체와의 분쟁 대부분은 이 네 가지 중 어디까지가 계약 범위인지 정하지 않은 데서 생깁니다. 견적을 받기 전에 우리 회사가 무엇을 맡길지부터 이 틀로 정리해보면 대화가 빨라집니다.
4.1 어디까지가 유지보수인가?
- 콘텐츠 수정: 텍스트·이미지 교체, 팝업·배너 등록, 게시물 관리. 신규 페이지 제작이나 디자인 개편은 보통 별도 견적입니다. 이 경계가 계약서에서 가장 자주 흐려지는 지점입니다
- 기술 업데이트: CMS 코어·플러그인·서버 패키지의 정기 업데이트와 보안 패치 적용
- 모니터링: 접속 가능 여부, 응답 속도, SSL·도메인 만료일, 백업 성공 여부를 지켜보는 일. 사고를 "고객 제보로 아는" 상태에서 벗어나는 핵심입니다
- 장애 대응: 접속 불가, 해킹, 오류 발생 시 원인 파악과 복구. 대응 속도를 어떻게 약속받는지는 6장의 SLA에서 다룹니다
4.2 항목별 권장 주기
| 항목 | 주요 작업 | 권장 주기 |
|---|---|---|
| 가동 모니터링 | 접속 상태·응답 속도 자동 감시, 다운 시 알림 | 상시 (자동화) |
| 백업 | 파일·DB 백업 후 서버 외부 보관 | 주 1회 이상, 변경 잦으면 매일 |
| 복구 테스트 | 백업본으로 테스트 환경에 실제 복원 | 분기 1회 |
| 업데이트 | CMS 코어·플러그인 업데이트, 보안 패치 | 월 1회 + 긴급 패치는 즉시 |
| SSL·도메인 점검 | 만료일 확인, 갱신 상태 점검 | 월 1회 + 자동 알림 병행 |
| 콘텐츠 수정 | 텍스트·이미지·팝업 교체 | 수시 (계약 범위 내) |
| 점검 리포트 | 작업 내역·이슈·트래픽 요약 공유 | 월 1회 |
4.3 주기는 사이트 성격이 정한다
표의 주기는 출발점입니다. 회사 소개형 홈페이지라면 주 1회 백업으로 충분하지만, 주문·예약·회원 데이터가 매일 쌓이는 사이트는 매일 백업이 기본입니다. 기준은 간단합니다. "하루치 데이터가 날아가면 얼마나 아픈가"를 자문해보고, 아픈 만큼 주기를 좁히면 됩니다.
5. 유지보수 비용 구조
과금 방식은 둘로 나뉩니다. 건당 정산과 월 정액. 수정할 일이 연에 몇 번 없으면 건당이 싸고, 월 1회 이상 손댈 일이 있거나 모니터링·백업을 맡기고 싶다면 정액이 맞습니다. 이 갈림길만 정해도 견적 비교가 한결 쉬워집니다.
5.1 건당 정산: 안 쓰면 0원, 대신 지켜보는 사람도 0명
요청이 있을 때만 작업하고 그때그때 비용을 내는 방식입니다. 텍스트·이미지 교체 수준은 건당 몇만 원대, 기능을 건드리는 작업은 작업 시간 기준으로 견적이 나옵니다. 고정비가 없다는 게 장점이지만 구조적인 약점이 있습니다. 아무도 사이트를 지켜보지 않는다는 점입니다. 백업도 모니터링도 계약에 없으니, 2장에서 본 방치 리스크가 그대로 남습니다. 건당 계약을 택한다면 최소한 백업과 만료일 알림은 자체적으로라도 돌려야 합니다.
5.2 월 정액: 요금제 유형별 비교
월 정액은 포함 범위에 따라 대략 세 단계로 나뉩니다. 아래 금액대는 국내 시장에서 통용되는 수준을 눈금으로 적은 것이며, 사이트 구조와 업체에 따라 달라집니다.
| 유형 | 월 비용대 (통용 수준) | 포함 범위 | 맞는 곳 |
|---|---|---|---|
| 건당 정산 | 정액 없음, 건당 수만 원~ | 요청 시 수정 작업만 | 연 1~2회 수정, 자체 백업 가능 |
| 라이트 | 월 5만~15만 원 안팎 | 소규모 콘텐츠 수정 + 백업 + 기본 점검 | 회사 소개형 홈페이지 |
| 스탠다드 | 월 20만~50만 원 안팎 | 월 수정 횟수 보장 + 업데이트 + 모니터링 + 장애 대응 | 문의·예약이 매출로 이어지는 사이트 |
| 전담형 | 월 100만 원 이상 | 기획·개발 리소스 상시 배정, 기능 개선 포함 | 쇼핑몰·서비스형 사이트 |
5.3 견적서에서 따로 확인할 세 가지
첫째, 호스팅비·도메인비와 유지보수비를 구분해서 보십시오. 서버 임대료를 유지보수 명목에 섞어 부풀리는 견적이 있고, 반대로 유지보수비에 호스팅이 포함된 줄 알았다가 이중으로 내는 경우도 있습니다. 둘째, 계약서의 수정 횟수가 "무제한"이라면 단서 조항을 확인해야 합니다. 무제한은 대개 범위 제한과 짝을 이룹니다. 셋째, 범위 외 작업의 단가가 적혀 있는지 봅니다. 계약 범위 밖 요청이 생겼을 때 시간당 얼마인지 미리 합의돼 있어야 그때 가서 실랑이하지 않습니다.
참고로 제작 단계의 견적 구조가 궁금하다면 홈페이지 제작 비용 구조 가이드에서 항목별로 다뤘습니다. 제작 견적과 유지보수 견적은 읽는 법이 다릅니다.
"무료 유지보수 1년"의 함정
제작 계약에 흔히 붙는 "1년 무료 유지보수"는 대부분 하자보수, 즉 제작 당시의 버그 수정을 뜻합니다. 콘텐츠 수정이나 보안 업데이트는 포함되지 않는 경우가 많습니다.
계약 전에 무료 기간의 범위를 문서로 확인하십시오. "무료"라는 말만 믿고 1년을 방치하면, 무료 기간이 끝날 즈음 사이트는 이미 1년치 업데이트가 밀려 있습니다.
6. 업체와 SLA 맺는 법
SLA(Service Level Agreement)는 거창한 문서가 아닙니다. "무슨 일이 생기면, 언제까지, 무엇을 해주는가"를 숫자로 적어두는 일입니다. "성실히 대응한다" 같은 문장은 분쟁이 났을 때 아무것도 보장하지 않습니다. 다섯 항목만 숫자로 박아두면 됩니다.
6.1 계약서에 숫자로 적을 다섯 가지
- 응답 시간: 요청 접수 후 몇 시간 안에 첫 회신을 주는지. 영업시간 기준인지 24시간 기준인지, 야간·주말 장애는 어떻게 접수하는지까지 적습니다
- 장애 복구 목표: 사이트 전체 다운 기준 몇 시간 안에 복구하는지. 장애 등급(전체 다운 / 일부 기능 오류 / 단순 문의)을 나눠 등급별 목표를 두면 더 좋습니다
- 백업 주기와 보관: 얼마나 자주, 어디에, 몇 세대를 보관하는지. "백업합니다"가 아니라 "주 1회, 외부 스토리지, 최근 4세대"처럼 씁니다
- 소스코드·계정 접근권: 소스 사본과 서버·도메인·관리자 계정의 소유가 누구인지 명시합니다. 아래에서 따로 다룹니다
- 범위 외 작업 단가: 계약 범위를 벗어난 요청의 시간당 또는 건당 단가를 미리 합의합니다
6.2 소스와 계정은 회사 자산이다
가장 뼈아픈 사고 유형은 이것입니다. 유지보수 업체가 폐업하거나 연락이 끊겼는데, 도메인이 업체 명의로 등록돼 있고 서버 계정도 업체만 아는 경우. 홈페이지가 멀쩡히 떠 있어도 손댈 방법이 없습니다. 도메인 등록자(Registrant)는 반드시 회사 명의여야 하고, 서버·CMS 관리자 계정 정보는 회사도 보관해야 합니다. 소스코드 사본을 정기적으로 넘겨받는 조항이 있으면 업체를 바꿀 때도 협상력이 생깁니다.
업체를 고르는 단계라면 판단 기준을 웹에이전시 선정 가이드에 정리해뒀습니다. 유지보수 역량은 제작 포트폴리오만 봐서는 안 보이는 항목이라, 확인 질문이 따로 필요합니다.
이관 조항 한 줄이 회사를 지킨다
계약서에 "계약 종료 시 30일 이내에 소스코드·DB·계정 정보 일체를 인계한다"는 한 줄을 넣으십시오. 이 조항이 없으면 업체 변경 때 인수인계를 볼모로 잡히는 경우가 생깁니다.
좋은 업체는 이 조항을 꺼리지 않습니다. 오히려 꺼리는 반응 자체가 업체를 거르는 신호가 됩니다.
7. 결론 및 체크리스트
7.1 오늘 30분이면 확인할 수 있는 것들
긴 글을 여섯 가지 행동으로 줄이면 이렇습니다. 전부 오늘 확인할 수 있는 항목입니다.
- SSL 만료일 확인: 브라우저 주소창의 자물쇠 아이콘에서 인증서 만료일을 봅니다. 30일 미만이면 지금 갱신 담당자부터 정하십시오
- 도메인 만료일·명의 확인: 후이즈(WHOIS) 조회로 만료일과 등록자가 회사 명의인지 확인합니다
- 최신 백업 확인: 가장 최근 백업이 언제 것인지, 서버 밖에 보관돼 있는지 봅니다. 답을 아는 사람이 없다면 그게 답입니다
- 관리자 계정 정리: 계정 목록에서 퇴사자·공용 계정을 삭제하고 2단계 인증을 켭니다
- 업데이트 상태 확인: CMS 관리자 화면의 업데이트 알림 개수를 세어봅니다. 두 자릿수라면 백업 후 일정을 잡아야 합니다
- 계약서 확인: 유지보수 계약이 있다면 응답 시간·복구 목표·소스 접근권이 숫자와 문장으로 적혀 있는지 봅니다. 없다면 6장의 다섯 항목으로 갱신 협상을 하십시오
7.2 방치의 값과 관리의 값
여섯 개 중 세 개 이상에서 "모르겠다"가 나왔다면, 그 홈페이지는 이미 방치 구간에 들어와 있습니다. 사고가 나기 전이라는 것만 다를 뿐입니다.
관리의 값은 월 몇만 원에서 몇십만 원, 방치의 값은 재제작비에 매출 손실과 신뢰 회복 기간까지 얹힌 금액입니다. 홈페이지는 오픈하는 날 완성되는 게 아니라, 오픈하는 날부터 관리가 시작됩니다. 어느 쪽 값을 낼지는 사고가 나기 전에만 고를 수 있습니다.