홈페이지 해킹 확인이 필요해 보일 때 첫 30분에 할 일은 악성 파일을 지우거나 비밀번호를 바로 바꾸는 일이 아닙니다. 관리자와 호스팅에 누가 접근하는지, 어떤 파일이 언제 바뀌었는지, 복구에 쓸 백업이 어느 시점에 있는지부터 기록해야 원인을 지우지 않고 대응 순서를 잡을 수 있습니다.
이 글에서 다루는 내용
- 수정 전에 접속 권한과 로그인 상태를 확인하는 순서
- 호스팅 파일 관리자에서 변경 흔적을 기록하는 항목
- 백업 파일과 데이터베이스 백업을 따로 확인해야 하는 이유
- 첫 30분 안에 삭제·복원·재설치를 보류할 항목
- 접근 권한을 넘겨받은 뒤 관리 기준을 남기는 방법
홈페이지 해킹 확인 전, 화면부터 고치지 않는 이유는?
사이트 첫 화면에 낯선 문구가 보이거나, 검색 결과를 누르면 다른 주소로 이동하거나, 관리자에게 모르는 사용자 계정이 나타나면 급하게 수정 화면부터 열기 쉽습니다. 하지만 그 상태에서 파일을 삭제하거나 이전 백업으로 복원하면 “무엇이 바뀌었는지”와 “언제부터 이상했는지”를 확인할 단서도 함께 사라집니다.
첫 확인은 공개 화면과 관리자 화면을 분리해서 남기는 일입니다. 시크릿 창에서 홈페이지 주소를 열어 이상이 보이는 주소를 적고, 화면을 캡처합니다. 그다음 기존 관리자 계정으로 로그인해 사용자 목록, 최근 글·페이지 수정 목록, 플러그인 또는 테마 업데이트 화면을 각각 캡처합니다. 이때 화면에 보이는 날짜, 계정명, 파일명은 나중에 복구 기준을 정할 때 필요한 기록입니다.
다만 방문자를 다른 사이트로 보내거나 파일 다운로드를 유도하는 등 공개 화면의 피해가 진행 중이라면 기록을 남긴 뒤 호스팅 관리자에서 일시 정지 또는 점검 페이지 전환 여부를 판단합니다. 이 단계는 원인을 해결하는 조치가 아니라 추가 노출을 멈추는 조치입니다. 보안 사고 신고와 대응 정보는 KISA 보호나라에서도 확인할 수 있습니다.
첫 10분: 관리자 접근 권한을 어떻게 확인하나?
먼저 홈페이지 관리자 주소, 호스팅 관리자 주소, 도메인 관리 계정의 로그인 가능 여부를 한 장의 메모에 나눠 적습니다. 홈페이지 관리자에 들어갔다고 해서 서버와 도메인까지 통제하는 것은 아닙니다. 반대로 호스팅 계정만 있고 홈페이지 관리자 계정을 모르면 콘텐츠와 사용자 권한을 바로 점검하기 어렵습니다.
관리자 화면에서는 사용자 또는 회원 관리 메뉴를 열어 관리자 권한 계정을 확인합니다. 대표·실무자·기존 제작업체 계정 가운데 현재 용도를 설명할 수 없는 계정은 계정명, 권한, 등록일 또는 마지막 사용 흔적을 캡처합니다. 바로 삭제하지 말고 목록을 남깁니다. 삭제한 계정이 외부 접근의 흔적인지, 기존 운영자가 쓰던 계정인지 나중에 구분해야 하기 때문입니다.
호스팅 관리자에서는 계약자 정보, 로그인 계정, 연결된 도메인, 파일 관리 접근 수단을 확인합니다. 카페24를 이용 중이라면 계정과 서비스별 관리 화면의 위치는 카페24 고객센터 안내를 기준으로 찾습니다. 비밀번호 변경은 이 목록과 현재 로그인 상태를 기록한 다음 순서로 둡니다. 접근 가능한 계정을 모르고 일괄 변경하면 복구 과정에서 필요한 권한까지 잃을 수 있습니다.
다음 10분: 파일 변경은 무엇을 기록해야 하나?
호스팅 관리자에서 파일 관리 또는 파일 매니저를 열고, 홈페이지가 설치된 폴더로 이동합니다. 파일 목록을 ‘수정일’ 기준으로 정렬한 뒤 최근에 바뀐 파일과 폴더를 확인합니다. 여기서 할 일은 삭제가 아니라 파일 경로, 파일명, 수정일을 적거나 화면으로 남기는 일입니다.
특히 내가 글을 발행하거나 디자인을 고친 시점과 맞지 않는 변경은 별도 표시합니다. 관리 화면에서 콘텐츠를 수정한 적이 없는 날에 여러 파일의 수정일이 몰려 있거나, 기억하지 못하는 이름의 파일이 보인다면 그 목록이 복구 전 점검 대상이 됩니다. 파일 하나만 보고 해킹 여부를 단정하지 않습니다. 정상 업데이트나 호스팅 작업으로 수정일이 바뀌는 경우도 있기 때문입니다.
서버 오류 기록이나 접속 기록을 제공하는 호스팅이라면 같은 시간대의 기록도 보관합니다. 파일 목록과 오류 기록은 복원 뒤에 사라질 수 있으므로, 내려받기 기능이 있으면 원본을 별도 폴더에 저장하고 파일명에 확인 날짜를 붙입니다. 파일을 열어 내용을 고치거나 덮어쓰는 작업은 이 단계에서 보류합니다.
마지막 10분: 백업 상태는 파일과 데이터베이스를 따로 본다
백업이 있다는 말만으로 복구 기준이 정해지지는 않습니다. 홈페이지는 보통 파일과 데이터베이스가 함께 맞아야 이전 상태로 돌아갑니다. 호스팅 백업 화면에서 파일 백업 날짜와 데이터베이스 백업 날짜를 각각 확인하고, 이상 징후가 나타나기 전으로 보이는 시점이 있는지 적습니다.
자동 백업, 수동 내려받기, 이전 업체가 보관한 백업은 서로 다른 위치에 있을 수 있습니다. 각 백업마다 저장 위치, 생성 날짜, 파일인지 데이터베이스인지, 실제로 내려받을 권한이 있는지를 구분해 적습니다. 가장 최근 백업이 이미 문제가 생긴 뒤 생성됐을 가능성도 있으므로, 날짜가 빠르다고 곧바로 복원 대상으로 정하지 않습니다.
백업 상태를 확인한 뒤에는 관리자 계정, 호스팅 계정, 도메인 계정의 비밀번호 변경과 불필요한 계정 정리, 복원 범위 결정을 진행합니다. 검색 노출도 함께 흔들렸다면 복구 후 구글 검색 등록했는데 안 뜰 때 5가지의 확인 항목처럼 검색 도구에서 문제 페이지를 따로 점검합니다.
기록이 남은 뒤에만 복구와 관리 주체 변경을 결정한다
첫 30분의 결과물은 기술적인 해결 자체가 아니라 3가지 목록입니다. 로그인 가능한 관리자 계정 목록, 수정일이 확인된 파일 목록, 날짜별 백업 목록입니다. 이 3가지가 있어야 기존 제작업체와 연락이 닿지 않는 경우에도 누가 무엇을 확인해야 하는지 정리됩니다. 외부 기관에 침해사고를 신고할 경우 신고 절차는 KISA 보호나라 침해사고 신고 안내에서 확인할 수 있습니다.
운영자가 직접 관리하기 어려운 상태라면 이 목록을 기준으로 맡길 범위를 나눕니다. 블로그 발행, 호스팅 상태, 뉴스레터 운영처럼 매달 반복되는 항목은 워프로랩 매니지드 호스팅처럼 하나의 운영 구독으로 묶어 두면, 사고 뒤에 관리자 위치와 백업 위치부터 다시 찾는 일을 줄일 수 있습니다.
복원 후에도 끝난 것은 아닙니다. 관리자 계정의 소유자, 도메인 갱신 담당자, 백업 확인일, 업데이트 확인일을 운영 문서에 남겨야 합니다. 홈페이지 관리 주체는 새 화면을 만드는 사람이 아니라, 문제가 생겼을 때 계정·파일·백업의 위치를 확인하고 다음 조치를 결정하는 사람입니다.
참고 출처
자주 묻는 질문
홈페이지가 다른 사이트로 이동하면 바로 백업 복원을 해야 하나요?
먼저 이동이 발생한 주소와 화면을 시크릿 창에서 기록합니다.
호스팅 파일 수정일과 백업 날짜를 확인하기 전 복원하면 원인 파일과 발생 시점을 놓칠 수 있습니다.
방문자 피해가 진행 중이면 기록 뒤 일시 정지 또는 점검 페이지 전환을 먼저 판단합니다.
관리자 비밀번호는 발견 즉시 바꿔야 하나요?
현재 로그인 가능한 관리자·호스팅·도메인 계정 목록을 먼저 남깁니다.
로그인 상태와 계정 권한을 기록하지 않은 채 변경하면 복구에 필요한 접근 경로까지 끊길 수 있습니다.
목록과 백업 상태를 확인한 뒤 관련 계정의 비밀번호 변경과 불필요한 계정 정리를 진행합니다.
백업이 있으면 해킹 여부를 확인하지 않아도 되나요?
백업은 복구 후보일 뿐, 문제가 없다는 증거는 아닙니다.
파일 백업과 데이터베이스 백업의 날짜를 따로 보고 이상 징후 이전 시점인지 비교해야 합니다.
복원 전에 최근 파일 변경 목록과 관리자 계정 목록을 남겨 두어야 같은 문제가 반복됐을 때 추적할 근거가 남습니다.