
얼마 전 서버가 랜섬웨어에 감염됐다는 상담을 받았는데, 운영자가 가장 먼저 물은 건 복구 업체 견적이었습니다. 그런데 견적을 내기 전에 확인할 게 있었습니다. 전날 백업이 살아 있는지, 그 백업으로 어느 시점까지 되돌릴 수 있는지였습니다. 이 두 가지에 따라 랜섬웨어복구비용은 크게 달라집니다.
복구비용은 복호화 비용만이 아닙니다
랜섬웨어 사고의 비용은 보통 네 덩어리로 나눠 계산합니다. 침해 범위를 확인하는 비용, 깨끗한 서버를 다시 만드는 비용, 백업에서 데이터를 복원하고 검증하는 비용, 서비스가 멈춘 동안의 손실입니다. 고객 정보가 유출됐을 가능성이 있다면 조사와 후속 대응도 별도로 잡아야 합니다.
예를 들어 하루 주문 100건인 쇼핑몰이 이틀 멈췄다고 해봅시다. 주문 한 건의 매출이 5만 원이면 멈춘 기간의 매출 규모는 1,000만 원입니다. 이 금액이 곧 손실액은 아닙니다. 나중에 돌아온 주문도 있고 원가도 빼야 하니까요. 그래도 복구 작업비만 보고 50만 원짜리 견적과 150만 원짜리 견적을 비교하면 중요한 시간을 놓칠 수 있습니다.
몸값은 비용표의 확정 항목으로 넣기 어렵습니다. 돈을 보내도 파일이 돌아온다는 보장이 없고, 복호화가 되더라도 유출된 자료나 침입 경로가 해결되지는 않습니다. 한국인터넷진흥원도 비용을 지불하기보다 신고와 복구 방법 확인을 권고합니다.
먼저 백업의 상태와 복구 시점을 확인합니다
사이트 운영자라면 백업 파일이 ‘있다’는 말만 믿지 말고 세 가지를 확인해야 합니다. 마지막 정상 백업 시각, 감염된 서버에서 백업을 삭제하거나 바꿀 수 있었는지, 실제로 복원 시험을 해봤는지입니다. 같은 관리자 계정으로 접근되는 저장소에 백업을 쌓았다면 백업도 함께 훼손됐을 수 있습니다.
가령 새벽 2시에 데이터베이스를 백업하고 오후 4시에 감염을 발견했다면, 정상 백업이 확인돼도 최대 14시간의 주문·게시물 데이터를 따로 살펴야 합니다. 반대로 1시간마다 보관한 백업이라도 감염이 사흘 전부터 진행됐다면 가장 최근 파일이 안전하다고 단정할 수 없습니다. 로그와 파일 변경 시각을 보고 정상 복구 시점을 고르는 시간이 비용에 들어갑니다.
백업이 정상이고 서버 한 대만 영향을 받았다면 새 인스턴스를 만들고 운영체제와 애플리케이션을 설치한 뒤 데이터를 되돌리는 쪽이 작업 범위를 예측하기 쉽습니다. 백업이 없거나 데이터베이스까지 암호화됐다면 파일별 복구 가능성을 조사해야 합니다. 한국인터넷진흥원과 No More Ransom에서 해당 유형의 무료 복구 도구가 있는지 확인할 수 있지만, 모든 랜섬웨어에 쓸 수 있는 도구가 있는 것은 아닙니다.
견적은 작업 범위를 같은 기준으로 비교합니다
업체에 문의할 때는 서버 대수와 운영체제, 웹·데이터베이스 구성, 감염 발견 시각, 정상 백업의 날짜와 보관 위치를 전달합니다. 견적서에는 침해 조사, 서버 재설치, 데이터 복원, 서비스 검증이 각각 포함됐는지 확인합니다. ‘복구 성공’의 뜻도 물어야 합니다. 파일을 열 수 있게 하는 것과 주문·결제까지 정상 동작시키는 것은 작업량이 다릅니다.
예산은 작업시간으로 먼저 거칠게 계산할 수 있습니다. 예를 들어 담당자 두 명이 각각 8시간 조사하고 12시간 재구축한다면 총 40인시입니다. 시간당 내부 인건비를 5만 원으로 가정하면 인건비만 200만 원입니다. 여기에 외부 분석, 임시 서버, 야간 작업, 중단 손실이 더해집니다. 이 수치는 시세가 아니라 계산 예시입니다. 실제 금액은 서버 수와 데이터 상태, 요구 복구 시간에 따라 달라집니다.
공유 웹호스팅이라면 운영체제 재설치는 호스팅 업체의 영역일 수 있습니다. VPS나 클라우드 서버에서는 계약상 관리 범위에 따라 이용자가 직접 재구축해야 할 수도 있습니다. 같은 월 이용료라도 장애 대응과 백업 복원 지원 범위가 다르니 계약 내용을 먼저 확인하는 편이 빠릅니다.
비용을 줄이는 순서는 확산 차단부터입니다
감염을 발견하면 해당 서버의 네트워크 연결을 끊고, 연결된 백업 저장소와 공유 폴더부터 보호합니다. 그다음 로그와 감염 파일을 보존하면서 영향을 받은 계정과 서버를 확인합니다. 급하다고 감염 서버에 백업을 바로 덮어쓰면 침입 경로가 남아 다시 암호화될 수 있습니다. 새 환경에 복원하고 관리자 비밀번호와 접근키를 교체한 뒤 웹 기능을 검증하는 순서가 안전합니다.
평소에는 백업을 운영 계정과 분리해 보관하고, 한 벌은 서버에서 직접 수정할 수 없는 곳에 두는 게 좋습니다. 월 1회라도 실제 복원에 걸리는 시간을 재보면 필요한 서버 사양과 백업 보관 주기도 잡힙니다. 트래픽이 작은 사이트라면 비싼 상시 대기 서버보다 검증된 백업과 복원 절차에 먼저 돈을 쓰는 편이 낫습니다. 사고 때 비용을 가장 크게 바꾸는 건 서버 가격보다 되돌릴 수 있는 데이터의 상태였습니다.
