백업의 가치는 사고가 나기 전까지 0처럼 보입니다. 그러다 한 번 데이터가 날아가면, 그제야 "왜 백업을 안 챙겼지" 하게 됩니다. 저도 고객 사고를 겪고 나서 습관이 완전히 바뀌었습니다. 이 가이드에서는 백업·보안·복구라는 운영의 기본기를, 실제로 무엇을 어떻게 해야 하는지 중심으로 정리합니다.
왜 기본기가 사고를 가르는가
대형 해킹·장애는 드뭅니다. 실제로 사이트를 잃는 사고의 대부분은 화려한 공격이 아니라, 기본을 안 지켜서 생깁니다. 오래된 플러그인의 알려진 취약점, 약한 관리자 비밀번호, 백업 부재 — 이 세 가지가 사고의 절대다수입니다. 다행히 이 세 가지는 모두 미리 막을 수 있습니다.
1. 정기 백업: 자동으로, 주기적으로
사람이 기억해서 하는 백업은 언젠가 빠집니다. 백업은 자동화돼야 합니다.
- 주기: 업데이트가 잦은 사이트는 매일, 변동이 적으면 주 단위로.
- 범위: 파일(코드·이미지)과 데이터베이스를 모두. 한쪽만 백업하면 복구가 안 됩니다.
- 보관 위치: 같은 서버에만 두면 서버가 통째로 망가질 때 백업도 같이 사라집니다. 다른 위치(외부 스토리지)에 한 벌 더 둡니다.
- 보관 기간: 여러 시점을 보관해, 문제를 늦게 발견해도 이전 정상 시점으로 돌아갈 수 있게 합니다.
2. 복구 테스트: 열어보지 않은 백업은 백업이 아니다
가장 많이 빠뜨리는 부분입니다. 백업 파일이 실제로 복구되는지 확인하지 않으면, 정작 사고가 났을 때 "백업이 깨져 있었다"는 최악의 상황을 만납니다. 주기적으로 백업을 실제로 복원해 보는 테스트를 해야, 그 백업이 진짜 쓸 수 있는 것입니다. 복구 절차를 미리 한 번 해두면, 사고 시 당황하지 않습니다.
3. 보안 패치와 비밀번호
- 최신 상태 유지: CMS·플러그인·서버 소프트웨어의 보안 패치를 미루지 않습니다. 알려진 취약점은 공격자도 압니다.
- 강한 비밀번호 + 2단계 인증: 관리자 계정은 가장 자주 노리는 표적입니다.
- 최소 권한: 모두에게 관리자 권한을 주지 말고, 필요한 만큼만.
- 로그인 보호: 무차별 대입을 막는 시도 제한·접근 IP 제한.
4. 모니터링: 방문자보다 먼저 알기
사이트가 멈추거나 변조된 것을 방문자 항의로 알게 되는 것만큼 나쁜 일은 없습니다. 가동 상태·응답 시간을 자동 감시하고, 이상 시 알림을 받도록 해두면 사고를 빠르게 잡습니다. 파일 변조 감지·악성코드 검사도 정기적으로 돌리면 좋습니다.
5. 사고가 났을 때
- 침해가 의심되면 먼저 비밀번호를 모두 교체하고 의심 세션을 끊습니다.
- 최근 정상 백업 시점을 확인합니다.
- 복구 전, 어떻게 뚫렸는지(취약 플러그인 등) 원인을 찾습니다. 원인을 안 고치면 복구해도 다시 뚫립니다.
- 정상 시점으로 복구하고, 모든 소프트웨어를 최신으로 패치합니다.
결국은 습관
백업·패치·모니터링은 한 번 자동화해두면 평소엔 신경 쓸 일이 거의 없습니다. 문제는 그 "한 번"을 미루는 것입니다. 사고가 난 뒤 복구에 며칠을 쓰는 것보다, 처음에 자동화에 한나절을 쓰는 편이 압도적으로 쌉니다.
랜섬웨어·악성코드 대비
침입의 목적이 데이터 암호화(랜섬웨어)나 악성코드 심기일 때가 있습니다. 이때 외부에 보관한 백업이 결정적입니다. 같은 서버의 백업까지 암호화되면 소용없으니, 다른 위치에 분리 보관한 백업이 최후의 방어선입니다. 정기적인 악성코드 검사와 파일 변조 감지도 함께 돌리면, 변조를 빨리 발견해 피해를 줄일 수 있습니다.
직원·권한 관리
사고의 상당수는 외부가 아니라 관리 소홀에서 옵니다.
- 퇴사·계약 종료 시 계정을 즉시 정리합니다.
- 모두에게 관리자 권한을 주지 말고, 역할에 맞는 최소 권한만 부여합니다.
- 공용 계정 대신 개인 계정을 써, 누가 무엇을 했는지 추적할 수 있게 합니다.
외부 연동과 API 키 관리
결제·메일·외부 서비스 연동에 쓰는 API 키·비밀번호가 코드나 공개 저장소에 노출되면, 그 자체가 침입 경로가 됩니다. 키는 설정 파일·환경변수로 분리하고, 공개 영역에 올라가지 않게 합니다. 노출이 의심되면 즉시 키를 재발급합니다.
사고 대응 플랜을 미리 적어둔다
사고는 당황 속에 일어납니다. "누구에게 연락하고, 무엇을 먼저 끄고, 어느 백업으로 어떻게 복구하는지"를 평소에 한 장으로 적어두면, 실제 상황에서 시간을 크게 아낍니다. 1년에 한 번 이 문서를 보며 복구 리허설을 해두면 더 좋습니다.
한 줄 요약
자동·정기·분리 보관 백업과 복구 테스트, 최신 패치, 강한 비밀번호·2단계 인증, 최소 권한, 모니터링 — 이 기본기가 사고의 대부분을 막습니다. 화려한 방어보다, 기본을 빠짐없이 자동화하는 것이 가장 강력합니다.
방화벽과 접근 제어
백업·패치가 사후·예방이라면, 웹 방화벽(WAF)은 공격을 입구에서 거르는 장치입니다. 알려진 공격 패턴·악성 봇을 차단하고, 관리자 페이지는 특정 IP만 접근하도록 제한하면 표적이 되는 면적이 크게 줄어듭니다. 무차별 로그인 시도를 막는 횟수 제한도 기본으로 켜 둡니다.
SSL과 보안의 관계
HTTPS(SSL)는 통신을 암호화하지만, 그것만으로 사이트가 "안전"해지는 것은 아닙니다. 자물쇠가 떠도 취약한 플러그인이 있으면 뚫립니다. SSL은 통신 보안, 백업·패치·방화벽은 사이트 보안 — 둘은 다른 층위입니다. 둘 다 갖춰야 진짜 안전합니다.
정기 보안 점검 루틴
- 월 1회: 업데이트·패치 적용, 백업 정상 여부 확인.
- 분기 1회: 복구 테스트, 권한·계정 정리.
- 연 1회: 사고 대응 리허설, 비밀번호 일괄 교체.
호스팅을 고를 때 보안 기준
보안은 운영자 혼자 짊어질 일이 아닙니다. 호스팅이 자동 백업, 무료 SSL, 방화벽, 악성코드 검사, 모니터링을 기본 제공하는지 확인하세요. 플랫폼이 받쳐주면, 운영자는 콘텐츠에 집중할 수 있습니다.
사고 후 신뢰 회복
만약 사고가 났다면, 빠른 복구만큼 투명한 안내가 중요합니다. 영향받은 사용자에게 사실과 조치를 알리고, 재발 방지책을 분명히 하면 신뢰를 회복할 수 있습니다. 숨기다 더 큰 신뢰를 잃는 경우가 많습니다.
넥서스아이 호스팅은 정기 자동 백업과 보안 관리를 기본으로 제공합니다. 사고 나서 복구에 매달리기보다, 자동으로 지켜지는 환경에서 운영하시길 권합니다.
