홈페이지 보안 점검, 운영자가 직접 확인할 항목

사이트가 잘 열리니까 보안은 괜찮은 것 같은데, 누가 챙기고 있는 거였더라?

홈페이지를 외주로 제작하고 나면, 보안은 대개 관심 밖으로 밀려납니다. 사이트가 정상적으로 열리고 문의가 들어오는 동안에는 “별문제 없으니 괜찮겠지”라는 생각이 자연스럽게 자리 잡습니다. 그러다 어느 날 검색 결과에 이상한 페이지가 노출되거나, 관리자 페이지 로그인이 안 되거나, 문의폼으로 스팸이 대량으로 쌓이고 나서야 보안이 그동안 누구의 책임이었는지 되묻게 됩니다.

문제는 이 시점에서 책임 소재가 명확하지 않다는 데 있습니다. 제작을 맡긴 업체와의 계약은 이미 끝났고, 호스팅은 또 다른 곳에서 관리하고 있으며, 도메인은 담당자가 바뀌며 갱신 주체가 불분명해진 경우도 많습니다. 보안 사고는 기술적인 문제이기 이전에, “누가 무엇을 지켜보고 있어야 했는가”라는 운영의 공백에서 시작됩니다.

이 글은 보안 전문가나 개발자를 위한 기술 점검표가 아닙니다. 코드를 직접 다루지 않는 운영 담당자가 자기 홈페이지를 놓고 직접 눈으로 확인할 수 있는 항목과 외주사·유지보수사에 점검을 요청해야 하는 항목을 구분해, 무엇을 챙기고 무엇을 위임해야 하는지 정리하는 데 목적이 있습니다. 보안 솔루션을 새로 도입하라는 이야기가 아니라, 지금 운영 중인 사이트에서 실제로 손이 닿는 범위를 점검하는 관점입니다.

기업·기관 규모와 무관하게 적용할 수 있도록, 특정 솔루션이나 호스팅 환경에 종속되지 않는 기준으로 정리했습니다. 워드프레스 기반이든 맞춤 개발 사이트든, 콘텐츠 관리 시스템(CMS, 쉽게 말해 관리자 페이지를 통해 콘텐츠를 직접 수정하는 도구)을 쓰든, 점검의 큰 틀은 동일합니다.

보안 사고라고 하면 대기업의 대규모 개인정보 유출을 먼저 떠올리기 쉽지만, 실제 공격은 규모를 가리지 않습니다. 오히려 보안에 큰 리소스를 투입하기 어려운 중소 규모 사이트가 더 손쉬운 표적이 됩니다. 공격자 입장에서 방치된 사이트는 들이는 노력 대비 성공률이 높은 대상이기 때문입니다.

최근 사고의 양상도 운영자가 알아둘 만합니다. 2025년 들어 두드러진 공격 방식 중 하나는 크리덴셜 스터핑(credential stuffing)입니다. 다른 사이트에서 이미 유출된 아이디·비밀번호 조합을 가져와, 같은 비밀번호를 재사용하는 사용자가 있을 것이라는 전제로 무작위 로그인을 시도하는 방식입니다. 정교한 해킹 기술이 필요하지 않고, 사람들이 여러 사이트에 같은 비밀번호를 쓰는 습관만으로 성립하기 때문에 피해가 반복됩니다. 관리자 계정 역시 예외가 아닙니다.

규모가 큰 기업도 자유롭지 못합니다. 2025년 상반기에는 한 유통 계열사 쇼핑몰에서 수개월에 걸쳐 150만 건이 넘는 개인정보가 빠져나간 정황이 뒤늦게 발견되기도 했습니다. 보안에 상당한 투자를 하는 곳에서도 이런 일이 일어난다는 점은, 자원이 적은 사이트일수록 기본적인 점검의 공백이 그대로 위험으로 이어진다는 의미이기도 합니다.

관계 기관의 집계에서도 해킹으로 인한 개인정보 유출 신고는 최근 늘어나는 추세로 보고되고 있으며, 원인을 보면 정교한 공격 기술뿐 아니라 업무 과실이나 설정 오류 같은 관리상의 빈틈도 적지 않은 비중을 차지합니다. 바꿔 말하면, 대단한 보안 솔루션이 없어서가 아니라 기본적인 관리가 비어 있어서 발생하는 사고가 여전히 많다는 의미입니다. 운영자 입장에서 다행인 점은, 이런 관리상의 빈틈은 대부분 비용 없이 점검으로 메울 수 있는 영역이라는 것입니다.

방치된 사이트가 위험한 이유는 단순히 공격 대상이 되기 때문만은 아닙니다. 사고가 발생해도 한참 동안 인지하지 못한다는 점이 더 큰 문제입니다. 변조된 페이지가 검색 엔진에 그대로 수집되면 회사명을 검색했을 때 엉뚱한 내용이 노출되고, 이는 신뢰도에 직접적인 타격을 줍니다. 개인정보가 포함된 문의 데이터가 빠져나간 경우라면 법적·경제적 책임 문제로까지 번질 수 있습니다. 보안 점검은 사고를 막기 위한 활동인 동시에, 사고가 나더라도 빨리 알아차리기 위한 활동입니다.

본격적인 점검 항목으로 들어가기 전에, 운영자가 가장 먼저 정리해야 할 것은 “이 항목을 내가 직접 볼 수 있는가, 아니면 누군가에게 요청해야 하는가”입니다. 홈페이지 보안은 한 사람이 전부 책임지는 영역이 아니라, 운영자·제작사·호스팅사· 유지보수사가 각자의 몫을 나눠 갖는 구조이기 때문입니다. 이 구분이 흐릿하면 모두가 “다른 쪽에서 챙기겠지”라고 생각하다 공백이 생깁니다.

크게 네 가지 책임 주체로 나눠볼 수 있습니다.

1. 1

   운영자 본인

   계정 비밀번호 관리, 퇴사자 권한 회수, 도메인·인증서 만료일 인지처럼 기술 지식 없이도 챙길 수 있는 영역입니다.

2. 2

   호스팅·인프라 제공사

   서버 자체의 보안과 네트워크 차원의 방어를 담당합니다.

3. 3

   제작사 또는 유지보수사

   코드 취약점, 보안 업데이트, 관리자 페이지 접근 통제처럼 개발 영역의 점검이 필요한 부분입니다.

4. 4

   데이터의 처리 주체

   사이트가 직접 다루는 문의·회원 정보가 어디에 어떻게 저장되는지에 대한 책임입니다.

이 글의 점검 항목은 위 구분을 따라 네 영역으로 나눠 설명합니다. 각 항목마다 운영자가 직접 확인할 수 있는지, 아니면 요청이 필요한지를 함께 표시했습니다. 직접 확인이 가능한 항목은 오늘 바로 점검할 수 있고, 요청이 필요한 항목은 제작사나 유지보수사에 무엇을 물어봐야 하는지 정리하는 용도로 쓰면 됩니다.

여기서 한 가지 짚어둘 점은, 책임 분담의 기준이 계약서에 명시되어 있어야 한다는 것입니다. 유지보수 계약을 맺을 때 보안 점검이 포함 범위에 들어가는지, 사고 발생 시 대응이 계약에 포함되는지는 업체마다 다릅니다. 점검을 통해 “이 항목은 우리가 직접 볼 수 없고 요청해야 하는 영역”이라는 사실을 확인했다면, 그 요청을 받아줄 주체가 계약상 존재하는지까지 확인하는 것이 안전합니다.

가장 먼저 점검할 영역이자, 다행히 운영자가 기술 지식 없이도 대부분 직접 확인할 수 있는 부분입니다. 방문자가 사이트에 접속하고 데이터를 주고받는 통로가 안전한지를 보는 것입니다.

기술적으로 정교한 해킹보다, 허술한 계정 관리에서 비롯되는 사고가 훨씬 많습니다. 앞서 언급한 크리덴셜 스터핑이 대표적입니다. 이 영역은 대부분 운영자가 직접 관리할 수 있고, 동시에 가장 자주 방치되는 부분이기도 합니다.

홈페이지가 단순한 소개용 페이지를 넘어 문의폼이나 회원 기능을 갖추는 순간, 보안의 무게중심은 개인정보로 옮겨갑니다. 이 영역은 운영자가 단독으로 판단하기 어렵고, 제작사·유지보수사와 함께 확인해야 하는 부분이 많습니다.

마지막 영역은 운영자가 직접 손대기 어렵고, 대부분 유지보수사나 인프라 제공사의 책임에 속합니다. 그렇다고 운영자가 몰라도 되는 것은 아닙니다. “이 항목들이 관리되고 있는가”를 확인하고 요청하는 것까지가 운영자의 몫입니다.

지금까지 네 영역에 걸쳐 항목을 살펴봤습니다. 모든 항목을 한 번에 완벽하게 갖추려 하면 부담스러우니, 운영자 입장에서 우선순위를 정리하면 다음과 같습니다.

먼저, 비용 없이 오늘 할 수 있는 것부터 합니다. 관리자 비밀번호 점검, 쓰지 않는 계정 정리, 수집 항목 최소화, SSL·도메인 만료일 확인은 비용이 들지 않으면서 사고 가능성을 가장 크게 줄이는 항목입니다. 보안 강화라고 하면 새로운 솔루션 도입을 떠올리기 쉽지만, 실제로 사고의 다수는 이 기본 항목의 공백에서 시작됩니다.

다음으로, 요청해서 확인할 것을 정리합니다. 데이터 저장 구조, 보안 업데이트 주기, 백업 복구 가능 여부, 관리자 접근 통제는 운영자가 직접 볼 수 없으므로, 제작사·유지 보수사에 물어볼 질문 목록으로 만들어두면 됩니다. 답이 명확하게 돌아오지 않는 항목이 있다면, 그 자체가 관리 공백의 신호입니다.

점검 자체는 일회성으로 끝나지 않지만, 특히 놓치면 안 되는 두 시점이 있습니다.

1. 1

   외주 제작이 끝나고 사이트를 인계받는 시점

   임시 계정 정리, 관리자 권한 이관, 도메인·인증서 소유권 확인, 데이터 저장 구조 설명을 한 번에 정리해두면 이후 운영이 훨씬 수월해집니다.

2. 2

   담당자가 바뀌거나 유지보수 계약이 갱신·종료되는 시점

   책임 주체가 바뀌는 순간이 공백이 가장 잘 생기는 때입니다. 인계와 계약 갱신 자리에서 점검 항목을 함께 확인하세요.

오늘 할 수 있는 점검부터 시작해, 외주사·유지보수사에 물어볼 항목을 분리해 두면 보안은 ‘새로 도입할 것’이 아니라 ‘이미 운영 중인 사이트에서 메우는 것’이 됩니다. 운영 단계에서 유지보수 범위를 어디까지 두는 게 적정한지 더 살펴보고 싶다면 유지보수 가이드를 함께 참고하시면 좋습니다.

• 관리자 비밀번호가 추측 가능한 단어를 포함하고 있지 않다
• 퇴사자·외주 종료자·임시 관리자 계정이 정리되어 있다
• 담당자별로 권한이 분리되어 있고 공용 계정 사용을 최소화했다
• 주소창 자물쇠와 SSL 인증서 만료일을 확인할 수 있다
• 도메인 만료일과 결제 수단의 유효 여부를 알고 있다
• 문의·신청 데이터가 어디에 저장되는지 제작사 답변을 받았다
• 수집하는 개인정보 항목이 실제 필요한 만큼인지 점검했다
• 보안 업데이트·백업·관리자 접근 통제의 관리 주체가 계약에 명시되어 있다