
해킹당한 홈페이지 복구 전,
사라지기 쉬운 자료부터 보존하세요
홈페이지가 갑자기 광고 사이트로 연결되거나 관리자 계정이 바뀌면 가장 먼저 떠오르는 생각은 ‘빨리 원래대로 돌려놓아야 한다’입니다. 그러나 서둘러 파일을 지우고 백업을 덮어쓰는 순간, 침입 경로와 피해 범위를 알려줄 단서까지 함께 사라질 수 있습니다.
특히 회원정보, 주문정보, 결제 관련 기록이 있는 워드프레스·쇼핑몰·기업 홈페이지라면 단순 복구만으로 사고가 끝나지 않습니다. 누가 언제 어디까지 접근했는지, 어떤 계정이 사용됐는지, 외부로 데이터가 전송됐는지를 확인할 자료가 필요합니다.
이 글은 포렌식 전문가가 아닌 일반 운영자도 사고 직후 무엇을 건드리지 말아야 하는지, 호스팅사에 무엇을 요청해야 하는지, 복구 작업본과 증거본을 어떻게 분리해야 하는지를 실제 실행 순서로 설명합니다.
지금 필요한 것은 가장 빠른 삭제가 아니라, 가장 차분한 보존입니다. 🔒
한눈에 보기
이 글이 필요한 사람: 해킹 의심 화면, 관리자 계정 탈취, 악성코드, 비정상 리디렉션 또는 회원정보 접근 정황을 발견한 홈페이지 운영자입니다.
해결하는 문제: 복구를 서두르다 로그와 원본 파일을 훼손하는 일을 피하고, 서버 안팎의 자료를 보존하는 순서를 정합니다.
읽은 뒤 할 수 있는 일: 10분 안에 증거 보존 목록을 만들고, 호스팅사와 대응업체에 구체적인 자료 보존 요청을 보낼 수 있습니다.
목차
읽기 전에 확인하세요: 복구와 증거 보존은 목적이 다릅니다
중요 안내
이 글은 일반적인 정보보존 원칙을 설명하며 디지털 포렌식 감정, 법률 자문, 개인정보 유출 판단 또는 공식 신고 의무 검토를 대신하지 않습니다. 서버 구조와 계약, 처리하는 개인정보, 사고 유형에 따라 대응이 달라질 수 있으므로 중요한 결정은 한국인터넷진흥원, 개인정보보호 담당자, 변호사 또는 침해사고 대응 전문가에게 확인하세요.
단순 장애인지 침해사고인지 아직 몰라도 보존은 시작할 수 있습니다
홈페이지 오류가 반드시 해킹을 뜻하는 것은 아닙니다. 플러그인 충돌, 인증서 만료, 서버 용량 부족, 잘못된 배포도 비슷한 증상을 만들 수 있습니다.
다만 원인을 모르는 상태에서 파일을 삭제하거나 백업을 덮어쓰는 행동은 되돌리기 어렵습니다. 침해가 아닌 것으로 확인되면 보존 자료를 폐기할 수 있지만, 자료가 사라진 뒤 침해가 확인되면 다시 만들 수 없습니다.
개인정보와 주문정보가 있다면 기술 문제만으로 보지 마세요
회원 이름, 연락처, 배송지, 상담 내용, 주문내역, 접속기록처럼 개인과 연결되는 정보가 저장돼 있다면 기술 복구와 별도로 유출 여부, 통지, 신고, 고객 안내를 검토해야 합니다.
개인정보 보호법과 시행령은 일정한 유출 상황에서 정보주체 통지와 관계 기관 신고를 요구하며, 신고 대상에 해당하는 경우에는 원칙적으로 유출 사실을 안 때부터 72시간 이내 신고 기준이 적용될 수 있습니다. 구체적인 정보가 모두 확인되지 않았더라도 확인된 내용으로 우선 신고하고 추가 내용을 보완하는 절차가 규정돼 있으므로, 조사 완료를 기다리며 기록을 미루는 방식은 피해야 합니다.
빠른 판단 기준
회원·주문·결제·상담 데이터가 있다면 홈페이지를 복구하는 사람과 개인정보 유출 여부를 검토하는 사람을 가능하면 분리하세요. 한 사람이 모든 판단을 떠안으면 기술 복구가 법적 검토보다 앞서기 쉽습니다.
첫 30분, 복구보다 먼저 멈춰야 할 행동
관리자 화면에서 플러그인과 파일을 무작정 삭제하지 마세요
악성 파일처럼 보이는 항목을 발견해도 바로 삭제하면 파일 내용, 수정 시각, 소유자, 권한, 생성 경로를 확인할 기회가 사라질 수 있습니다. 워드프레스 보안 플러그인의 ‘자동 정리’ 기능도 같은 이유로 잠시 보류하는 편이 안전합니다.
관리자 화면에 접속해야 한다면 개인용 노트북보다 별도의 깨끗한 장치를 사용하고, 접속 시각과 수행한 행동을 메모하세요. 화면 확인만 했더라도 관리자 세션이나 로그가 새로 기록될 수 있습니다.
깨끗해 보이는 백업을 현재 서버에 곧바로 덮어쓰지 마세요
자동 백업은 서비스 복구에는 유용하지만 증거 보존용 원본과는 목적이 다릅니다. 백업이 이미 감염된 뒤 생성됐을 수도 있고, 복원 과정에서 현재 서버의 파일과 로그가 덮어써질 수도 있습니다.
복원 전에는 현재 서버의 스냅샷 또는 전체 복사본을 먼저 확보하고, 백업 생성 시각과 보관 위치를 기록하세요. 기업용 백업 서비스의 선택 기준이 궁금하다면 기업용 클라우드 백업 가격 비교 기준도 함께 확인할 수 있습니다.
격리와 전원 종료를 같은 조치로 생각하지 마세요
격리는 공격자와 서버 사이의 통신 또는 피해 확산을 제한하는 조치입니다. 반면 전원 종료와 재부팅은 메모리, 실행 중인 프로세스, 현재 연결, 로그인 세션 같은 휘발성 자료를 없앨 수 있습니다.
랜섬웨어가 빠르게 확산되거나 다른 시스템이 즉시 위험한 상황에서는 서비스 보호를 위해 전원을 끄는 판단이 필요할 수 있습니다. 그러나 일반적인 웹 변조나 관리자 계정 탈취라면 먼저 네트워크 격리와 스냅샷 가능 여부를 확인하는 편이 낫습니다. 전원 판단을 더 자세히 살펴보려면 랜섬웨어 감염 시 전원 종료 판단 기준을 참고하세요.
첫 30분 대응 흐름
삭제, 재설치, 덮어쓰기, 자동 정리를 중지합니다.
서비스 중단 범위를 최소화하며 외부 통신을 제한합니다.
휘발성 자료와 서버 스냅샷을 우선 확보합니다.
시각, 담당자, 수행 명령과 보관 위치를 남깁니다.
가장 먼저 사라지는 휘발성 증거부터 확인하세요
실행 중인 프로세스와 네트워크 연결은 순간의 발자국입니다
서버가 켜져 있을 때만 확인할 수 있는 정보에는 실행 중인 프로세스, 외부 연결 주소, 열린 포트, 현재 로그인 사용자, 열려 있는 파일, 메모리 내용 등이 있습니다. 재부팅하면 이 목록이 초기화되거나 크게 달라질 수 있습니다.
디지털 포렌식 지침에서는 휘발성 운영체제 자료를 수집할 때 시스템에 미치는 영향을 고려하고, 권한 있는 담당자와 법률·관리 책임자의 판단 아래 절차를 정하도록 권고합니다. 일반 운영자가 익숙하지 않은 명령을 무작정 실행하면 오히려 상태를 바꿀 수 있으므로, 수집 능력이 없을 때는 화면과 시간만 기록한 뒤 전문가에게 넘기는 편이 낫습니다.
시스템 시간과 표준시간대가 틀리면 사건 순서도 틀어집니다
웹서버 로그는 한국시간, 데이터베이스는 협정세계시, CDN은 별도 표준시간으로 기록되는 경우가 있습니다. 각 기록의 시간이 다르면 같은 접속을 서로 다른 사건으로 오해할 수 있습니다.
- 서버의 현재 시각과 표준시간대
- 마지막 부팅 시각과 최근 재부팅 이력
- 호스팅 관리 화면에 표시되는 시각 기준
- CDN·방화벽·클라우드 감사 로그의 시각 기준
- 운영자의 컴퓨터와 휴대전화에 표시된 현재 시각
일반 운영자가 멈춰야 하는 지점
서버 명령어 사용 경험이 없거나 루트 권한이 탈취된 정황이 있다면 메모리 덤프, 디스크 이미지, 악성 프로세스 종료를 직접 시도하지 않는 편이 안전합니다. 잘못된 명령 하나가 파일 시각과 로그를 바꾸고, 공격자의 자동 삭제 기능을 작동시킬 수도 있습니다.
조금 더 깊이 알고 싶다면
자료 보존 순서는 흔히 ‘사라지기 쉬운 것부터 오래 남는 것까지’ 정합니다. 메모리와 현재 연결은 전원 상태에 따라 즉시 사라질 수 있고, 서버 로그는 일정 기간 뒤 자동 순환될 수 있으며, 백업과 이메일 기록은 상대적으로 오래 남습니다.
다만 모든 환경에 같은 순서가 적용되는 것은 아닙니다. 공격이 계속 진행 중이라면 증거 수집보다 피해 확산 차단이 우선일 수 있습니다. 따라서 ‘무조건 서버를 켜둔다’ 또는 ‘무조건 전원을 끈다’가 아니라, 확산 위험과 증거 손실 위험을 함께 비교해야 합니다.
서버·웹파일·데이터베이스에서 복제할 핵심 자료
서버 전체 스냅샷이 가능하다면 파일 몇 개보다 먼저 요청하세요
가상서버나 클라우드 호스팅을 사용한다면 현재 디스크 상태를 보존하는 스냅샷 기능이 제공될 수 있습니다. 스냅샷은 서버 전체의 특정 시점을 묶어 보존하므로 웹루트만 내려받는 것보다 운영체제 설정과 숨은 파일을 함께 확인하기 좋습니다.
단, 스냅샷 생성 자체가 서버에 쓰기 작업을 발생시키거나 메모리까지 보존하지 못할 수 있습니다. 호스팅사에 ‘포렌식 보존 목적’임을 밝히고 생성 시각, 포함 범위, 보관기간, 자동 삭제 여부를 서면으로 확인하세요.
웹루트와 업로드 폴더는 숨김 파일까지 복제하세요
워드프레스라면 핵심 파일, 테마, 플러그인, 업로드 폴더뿐 아니라 환경설정 파일, 서버 규칙 파일, 숨김 파일, 임시 폴더도 확인 대상입니다. 공격자는 정상 이미지처럼 보이는 파일명이나 사용하지 않는 플러그인 폴더에 웹셸을 숨길 수 있습니다.
- 웹루트 전체와 상위 설정 디렉터리
- 테마·플러그인·업로드 폴더
- 웹서버 설정과 접근 제어 파일
- 환경변수와 데이터베이스 연결 설정
- 임시·캐시·세션 저장 폴더
- 최근 생성되거나 수정된 실행 가능 파일
데이터베이스 덤프와 계정·예약 작업을 함께 보존하세요
데이터베이스 전체 덤프에는 게시물과 회원정보뿐 아니라 관리자 계정, 권한, 플러그인 설정, 예약 작업, 리디렉션 주소가 들어 있을 수 있습니다. 표준 덤프와 함께 데이터베이스 로그 또는 최근 변경 이력이 제공되는지도 확인하세요.
서버의 사용자 계정, SSH 키, FTP 계정, 응용프로그램 비밀키, 웹훅, 예약 작업도 목록화해야 합니다. 비밀번호를 바꾸기 전에 현재 계정과 권한을 화면 또는 내보내기 파일로 남기면 공격자가 만든 계정을 나중에 구분하기 쉬워집니다.
| 보존 자료 | 확인할 내용 | 우선순위 |
|---|---|---|
| 서버 스냅샷 | 디스크 전체 포함 범위, 생성 시각, 보관기간 | 매우 높음 |
| 웹파일 원본 | 숨김 파일, 권한, 소유자, 수정 시각 유지 여부 | 높음 |
| 데이터베이스 덤프 | 전체 테이블, 계정, 설정, 예약 작업 포함 여부 | 높음 |
| 접근·오류 로그 | 보관기간, 표준시간대, 원본 형식 | 매우 높음 |
| 계정·권한 목록 | 관리자, 서버 계정, 공개키, 응용프로그램 키 | 높음 |
| 크론·예약 작업 | 실행 명령, 주기, 생성자, 최근 실행 시각 | 높음 |
이것만은 확인하세요
‘백업이 있다’는 답만 받지 말고, 현재 침해 상태의 스냅샷과 과거 정상 백업을 각각 보존했는지 확인하세요. 두 자료는 서로 대체할 수 없습니다.
사이트 밖 기록이 침입 경로를 설명합니다
호스팅·DNS·CDN 기록은 서버가 지워져도 남아 있을 수 있습니다
공격자가 서버 로그를 삭제했더라도 호스팅 관리 화면, 도메인 등록기관, DNS 서비스, CDN, 웹 방화벽에는 별도의 기록이 남아 있을 수 있습니다. 특히 DNS 변경과 관리자 로그인 이력은 홈페이지 파일을 건드리지 않고도 방문자를 피싱 페이지로 보내는 공격을 확인하는 데 도움이 됩니다.
- 호스팅 관리 화면의 로그인·설정 변경·스냅샷 이력
- 도메인 등록기관의 로그인과 연락처 변경 기록
- DNS 레코드 생성·수정·삭제 이력
- CDN과 웹 방화벽의 요청·차단·우회 기록
- 클라우드 계정의 감사 로그와 보안 경고
- 전자우편의 로그인 경고와 비밀번호 재설정 요청
화면 변조와 검색 결과도 날짜가 보이게 캡처하세요
피싱 페이지, 불법 광고, 성인 사이트 리디렉션, 검색 결과의 이상 문구가 보인다면 전체 화면과 주소창, 컴퓨터 시각이 함께 나오도록 캡처하세요. 모바일과 데스크톱에서 다르게 나타날 수 있으므로 가능하면 두 환경을 구분해 기록합니다.
캡처 파일에는 ‘메인화면’, ‘관리자 로그인’, ‘검색 결과’, ‘호스팅 경고’처럼 내용을 설명하는 이름을 붙이고 원본 파일을 별도로 보관하세요. 수사기관 제출을 고려한다면 해킹 피해 경찰 신고용 증거자료 준비 방법도 함께 확인하는 편이 좋습니다.
외주업체와의 대화도 작업 기록입니다
전화로 ‘고쳐 달라’고만 요청하면 누가 어떤 파일을 삭제했고 어느 백업을 복원했는지 나중에 확인하기 어렵습니다. 전자우편이나 업무 티켓으로 현재 상태 보존, 로그 삭제 중지, 작업 전 승인, 수행 명령 기록을 요청하세요.

해시값과 작업 기록으로 자료의 신뢰도를 지키는 방법
원본과 분석용 사본을 처음부터 나누세요
수집한 자료를 바로 열어보고 편집하면 접근 시각이나 파일 속성이 달라질 수 있습니다. 원본 보존본은 읽기 전용에 가까운 상태로 별도 저장하고, 실제 확인과 악성코드 분석은 복사본에서 진행하세요.
저장장치 하나에만 보관하면 분실과 고장 위험이 있습니다. 접근 권한이 제한된 두 곳에 복제하되, 클라우드 동기화 서비스가 파일을 자동 변환하거나 삭제하지 않는지 확인해야 합니다.
SHA-256 해시값은 파일의 디지털 지문입니다
해시값은 파일 내용을 일정한 문자열로 계산한 값입니다. 같은 파일은 같은 해시값을 만들고, 내용이 조금이라도 달라지면 보통 다른 값이 나옵니다.
수집 직후와 전달 직전에 해시값을 계산해 기록하면 자료가 중간에 달라지지 않았는지 비교할 수 있습니다. 다만 해시값만으로 수집 절차 전체가 적절했다는 사실까지 자동으로 증명되는 것은 아닙니다.
수집 기록표에는 사람과 시간도 들어가야 합니다
| 기록 항목 | 작성 예시 |
|---|---|
| 자료명 | 웹서버 접근 로그 원본 |
| 출처 | 호스팅 관리자 화면의 로그 내보내기 |
| 수집 시각 | 2026-07-22 17:40 한국시간 |
| 수집자 | 대표자 또는 지정 담당자 이름 |
| 원본 파일명 | 호스팅사가 제공한 파일명을 그대로 기록 |
| 해시값 | SHA-256 계산 결과 |
| 보관 위치 | 암호화 저장장치 1번, 제한된 클라우드 보관함 |
| 수행 작업 | 복사, 압축, 전달, 분석 여부와 시각 |
실수 방지 메모
파일명을 보기 좋게 바꾸거나 폴더 구조를 정리하고 싶더라도 먼저 원본 상태를 기록하세요. 정리는 분석용 사본에서 하고, 무엇을 바꿨는지 작업 기록에 남기는 편이 안전합니다.
복구에는 성공했지만 원인 규명에는 실패하는 실수
첫 화면만 정상으로 돌려놓고 침입 경로를 남겨두는 경우
변조된 첫 화면을 교체하면 방문자에게는 정상으로 보일 수 있습니다. 그러나 취약한 플러그인, 탈취된 관리자 계정, 노출된 비밀키, 예약 실행 백도어가 그대로 남아 있으면 며칠 뒤 같은 문제가 반복됩니다.
복구 완료의 기준은 ‘화면이 보인다’가 아니라 침입 경로가 차단되고, 악성 지속 장치가 제거되며, 새 환경에서 모니터링이 작동하는 상태입니다.
운영 서버에서 정리 도구를 바로 실행하는 경우
백신이나 악성코드 정리 프로그램은 파일을 격리·삭제·수정할 수 있습니다. 복구 작업에는 도움이 되지만 실행 전 상태를 보존하지 않았다면 공격 파일의 위치와 연관 정보를 잃을 수 있습니다.
도구를 사용해야 한다면 먼저 스냅샷과 로그를 확보하고, 어떤 도구를 어떤 설정으로 실행했는지 기록하세요. 유료 제거 서비스를 알아보는 단계라면 워드프레스 악성코드 제거 비용과 업체 선택 기준을 참고해 분석 범위와 재발 보증 조건을 비교할 수 있습니다.
모든 비밀번호를 동시에 바꾸고 기록을 남기지 않는 경우
비밀번호 변경은 필요하지만 순서 없이 한꺼번에 진행하면 어느 계정이 탈취됐는지, 어떤 세션이 종료됐는지, 공격자가 만든 계정이 무엇인지 확인하기 어려워질 수 있습니다.
- 변경 전 계정·권한·접속 세션 목록을 보존합니다.
- 전자우편과 도메인 계정처럼 복구 경로를 통제하는 계정을 먼저 보호합니다.
- 깨끗한 장치에서 비밀번호를 변경합니다.
- 다중 인증과 복구 코드를 함께 재설정합니다.
- 사용하지 않는 계정은 기록 후 비활성화합니다.
실제 적용 사례
한 소규모 쇼핑몰 운영자는 새벽에 홈페이지가 해외 도박 사이트로 연결된다는 고객 연락을 받았습니다. 그는 호스팅사에 전화해 전날 백업을 즉시 복원해 달라고 요청하려 했습니다.
다행히 복원 전에 현재 서버 스냅샷과 접근 로그 보존을 먼저 요청했습니다. 확인 결과 홈페이지 파일만 바뀐 것이 아니라 오래된 외주업체 계정으로 관리자 로그인이 이루어졌고, 데이터베이스에 새로운 관리자 계정과 예약 작업이 추가돼 있었습니다.
만약 첫 화면만 복원했다면 사이트는 잠시 정상으로 보였겠지만 예약 작업이 다시 악성 파일을 만들었을 가능성이 컸습니다. 운영자는 새 서버에 정상 코드를 다시 설치하고, 계정과 비밀키를 재발급한 뒤 주문정보 접근 로그를 별도로 검토했습니다.
이 사례의 핵심은 고가의 도구가 아니라 순서였습니다. 복구 전 상태를 한 번 보존한 덕분에 침입 경로와 재감염 원인을 함께 확인할 수 있었습니다.
증거본·분석본·복구본을 분리해야 재감염을 줄일 수 있습니다
세 가지 복사본은 목적부터 다릅니다
| 구분 | 목적 | 허용되는 작업 |
|---|---|---|
| 증거 보존본 | 사고 당시 상태 유지 | 가능한 한 열람과 변경을 최소화 |
| 분석용 사본 | 악성 파일, 계정, 로그와 침입 경로 확인 | 검색, 도구 실행, 압축 해제, 비교 분석 |
| 서비스 복구본 | 안전한 홈페이지 운영 재개 | 정상 코드 설치, 설정 재구성, 데이터 선별 복원 |
현재 서버 전체를 그대로 복제해 다시 운영하면 숨은 백도어와 악성 계정까지 함께 살아날 수 있습니다. 가능하면 깨끗한 서버 환경을 새로 만들고, 검증된 코드와 필요한 데이터만 옮기는 방식이 안전합니다.
정상 버전과 현재 파일을 코드·설정·데이터로 나눠 비교하세요
워드프레스 핵심 파일과 공식 배포본을 비교하는 것만으로는 충분하지 않습니다. 테마 사용자 정의 코드, 서버 설정, 데이터베이스 관리자 계정, 업로드 폴더, 예약 작업까지 따로 확인해야 합니다.
- 코드: 핵심 파일, 테마, 플러그인의 출처와 버전
- 데이터: 게시물, 회원, 주문, 관리자 계정의 변경 이력
- 설정: 환경변수, 서버 규칙, 파일 권한, 비밀키
- 지속 장치: 예약 작업, 시작 스크립트, 웹셸, 숨은 계정
- 외부 연결: 웹훅, 전자우편 전송, 저장소, 원격 관리 도구
무료 점검과 유료 대응업체의 차이를 비용보다 범위로 비교하세요
| 선택지 | 적합한 상황 | 확인할 한계 |
|---|---|---|
| 직접 점검 | 단순 플러그인 오류 가능성이 높고 개인정보가 없으며 정상 백업과 서버 지식이 있는 경우 | 로그 분석과 침입 범위 판단이 부족할 수 있음 |
| 일반 복구업체 | 사이트 정상화와 악성 파일 제거가 주목적인 경우 | 증거 보존, 유출 판단, 공식 보고서가 계약에 포함되는지 확인 |
| 침해사고 대응업체 | 루트 권한 탈취, 개인정보 접근, 반복 감염, 다수 서버 확산이 의심되는 경우 | 분석 범위와 산출물, 보관 방식, 비용 구조를 서면 확인 |
| 디지털 포렌식 업체 | 수사, 소송, 보험금 청구, 책임 분쟁 가능성이 있는 경우 | 증거 연속성, 감정 자격, 법정 제출 경험을 확인 |
비용을 낭비하지 않는 질문
견적을 받을 때 ‘악성코드를 지워 주나요?’만 묻지 마세요. 현재 상태 보존, 로그 분석 기간, 침입 경로 확인, 개인정보 접근 검토, 재발 점검, 작업 보고서가 각각 포함되는지 질문해야 업체 간 가격을 제대로 비교할 수 있습니다.
신고와 전문가 도움이 필요한 상황을 구분하세요
개인정보 유출이 확정되지 않아도 검토 시계는 움직입니다
유출 신고 여부를 판단하려면 먼저 어떤 개인정보가 저장돼 있었는지, 외부 접근이 있었는지, 다운로드나 전송 정황이 있는지 확인해야 합니다. ‘유출이 확정될 때까지 아무것도 하지 않는다’기보다 확인된 사실과 미확인 항목을 분리해 기록하는 방식이 안전합니다.
개인정보처리시스템이나 개인정보 처리에 이용되는 정보기기에 외부의 불법 접근이 발생해 개인정보가 유출된 경우도 시행령상 신고 검토 대상에 포함될 수 있습니다. 처리 인원, 민감정보·고유식별정보 포함 여부와 함께 공식 기준을 확인하세요.
고객정보 접근 여부를 확인하는 구체적인 방법은 고객정보 유출 로그 확인 순서에서 이어서 살펴볼 수 있습니다.
KISA 침해사고 신고와 개인정보 신고는 같은 절차가 아닙니다
정보통신서비스 제공자에게 적용될 수 있는 침해사고 신고와 개인정보 보호법상 유출 통지·신고는 법적 근거와 판단 항목이 다릅니다. 사업 형태와 서비스 성격에 따라 두 절차를 함께 검토해야 할 수 있습니다.
한국인터넷진흥원 공식 안내는 정보통신서비스 제공자가 침해사고 발생을 안 때부터 24시간 이내 신고하도록 안내하고 있으며, 사고 관련 자료 보전과 제출 요구 절차도 설명합니다. 모든 일반 홈페이지 운영자에게 동일하게 적용된다고 단정할 수는 없으므로, 자신의 서비스가 해당 범주인지 공식 상담을 통해 확인하세요.
신고 절차를 단계별로 준비해야 한다면 KISA 118 사이버사고 신고 준비 방법을 참고할 수 있습니다.
다음 신호가 보이면 일반 복구보다 전문 대응을 먼저 고려하세요
- 서버의 최고 관리자 권한이 탈취됐거나 권한 범위를 알 수 없는 경우
- 회원정보, 주문정보, 결제정보 또는 인증정보 접근 가능성이 있는 경우
- 공격자가 로그와 관리자 계정을 삭제한 정황이 있는 경우
- 랜섬웨어, 금전 요구, 자료 공개 협박을 받은 경우
- 고객사나 다른 서버로 공격이 확산된 경우
- 같은 사이트가 복구 뒤 반복해서 감염되는 경우
- 경찰 신고, 소송, 보험금 청구 또는 책임 분쟁 가능성이 있는 경우
사이버보험에 가입했다면 보험사가 지정한 신고 시점과 대응업체 선임 절차를 먼저 확인하세요. 임의로 업체와 계약하거나 비용을 지출하면 약관상 보상 검토에 영향을 줄 수 있습니다.

자주 묻는 질문
홈페이지를 먼저 차단하면 로그가 사라지나요?
점검 안내 페이지를 띄우거나 외부 접근을 제한하는 것만으로 기존 로그가 자동 삭제되는 것은 아닙니다. 다만 차단 방식을 잘못 선택해 서버를 재부팅하거나 새 설정을 덮어쓰면 일부 자료가 달라질 수 있습니다. 현재 로그 보존과 스냅샷 가능 여부를 확인한 뒤 최소 범위로 접근을 제한하세요.
호스팅사가 제공하는 자동 백업만 보존하면 충분한가요?
충분하지 않을 수 있습니다. 자동 백업은 복구 목적이어서 접근 로그, 메모리, 실행 프로세스, 호스팅 계정 로그인 이력, DNS 변경 기록까지 포함하지 않는 경우가 많습니다. 현재 침해 상태의 스냅샷과 과거 정상 백업을 별도로 보존하세요.
워드프레스 관리자에 접속해 화면을 캡처해도 되나요?
불가피하다면 가능하지만 접속 자체가 새로운 세션과 로그를 만들 수 있습니다. 깨끗한 장치를 사용하고 접속 시각, 계정, 수행한 행동을 기록하세요. 관리자 화면에서 플러그인 업데이트나 파일 삭제는 보존이 끝날 때까지 피하는 편이 좋습니다.
악성 파일을 개인 컴퓨터에 다운로드해 보관해도 되나요?
일반 업무용 컴퓨터에 직접 내려받는 것은 권하지 않습니다. 실수로 실행되거나 동기화 폴더를 통해 다른 장치로 퍼질 수 있습니다. 접근이 제한된 저장공간에 압축·암호화해 보관하고, 분석은 격리된 환경이나 전문업체를 이용하세요.
로그가 이미 삭제됐다면 무엇부터 찾아야 하나요?
호스팅사 원본 로그, CDN·웹 방화벽 로그, 클라우드 감사 로그, 도메인 계정 접속 기록, 전자우편 보안 경고, 검색엔진 캐시, 외주업체 작업 기록을 확인하세요. 서버 내부 기록이 없어도 외부 서비스의 기록을 연결하면 공격 시간대를 좁힐 수 있습니다.
해킹된 날짜를 모르면 로그를 어느 기간까지 보존해야 하나요?
최초 이상 징후보다 넓게 잡아야 합니다. 처음 발견한 날짜, 마지막 정상 확인 날짜, 최근 업데이트·외주 작업·계정 변경 날짜를 기준으로 가능한 가장 오래된 로그부터 보존하세요. 로그 보관기간이 짧다면 조사 범위를 정하기 전에 우선 전체 내보내기를 요청하는 편이 낫습니다.
개인정보 유출이 확인되지 않아도 신고를 검토해야 하나요?
네. 외부 불법 접근 정황과 개인정보 처리 범위가 있다면 유출 가능성, 신고 대상, 고객 통지 필요성을 조기에 검토해야 합니다. 다만 해킹 사실만으로 모든 사업자가 자동으로 같은 신고 의무를 지는 것은 아니므로 처리한 정보와 사고 경로를 공식 기관 또는 전문가와 확인하세요.
호스팅사에 어떤 문장으로 자료 보존을 요청해야 하나요?
“침해사고 조사를 위해 현재 서버 스냅샷, 웹서버 접근·오류 로그, 관리자 로그인과 작업 이력, 백업 목록을 원본 형식으로 보존해 주십시오. 자동 삭제와 순환 저장을 중지하고, 자료 생성 시각·표준시간대·보관기간·수행 작업을 서면으로 알려 주십시오”라고 요청하면 핵심 항목을 빠뜨릴 가능성이 줄어듭니다.
복구업체 비용은 무엇을 기준으로 비교해야 하나요?
서버 수와 데이터 용량뿐 아니라 스냅샷 보존, 로그 분석 기간, 악성코드 분석, 개인정보 접근 검토, 복구 환경 구축, 재발 모니터링, 결과 보고서가 포함되는지 비교하세요. 저렴한 견적이라도 단순 파일 삭제만 포함한다면 별도의 원인분석 비용이 다시 들 수 있습니다.
지금 15분 안에 증거 보존 목록부터 작성하세요
첫 번째 행동은 복구 버튼이 아니라 한 장의 기록표입니다
문서나 스프레드시트를 열고 자료명, 출처, 수집 시각, 담당자, 원본 파일명, 해시값, 보관 위치를 열로 만드세요. 아직 자료를 수집하지 못했다면 상태를 ‘호스팅사 요청 중’, ‘로그 보존기간 확인 중’처럼 적습니다.
- 현재 홈페이지와 호스팅 관리 화면을 시각이 보이게 캡처합니다.
- 삭제, 재설치, 덮어쓰기와 자동 악성코드 정리를 중지합니다.
- 호스팅사에 서버 스냅샷과 로그 자동 삭제 중지를 서면 요청합니다.
- 회원·주문·결제정보의 저장 여부와 관리자 계정을 목록화합니다.
- 복구 작업 전 증거 보존본이 따로 있는지 담당자와 확인합니다.
오늘 한 가지 원칙만 기억한다면
해킹된 홈페이지에서는 빠른 복구와 올바른 복구가 같은 뜻이 아닙니다. 사고 당시의 상태를 한 번 보존한 뒤 작업하면 서비스도 되살리고, 원인과 책임을 확인할 가능성도 남길 수 있습니다.
삭제하기 전에 복제하고, 복구하기 전에 기록하세요.
이 짧은 순서가 나중의 조사 비용과 재감염 위험, 설명할 수 없는 공백을 줄여 줍니다.
최종 검토: 2026-07