호스팅 업체에서 오는 메일은 대부분 읽히지 않습니다. 광고겠거니 하고 넘기거나, 열어봤는데 무슨 말인지 모르겠어서 일단 두거나. 카페24가 최근 보낸 PHP 지원 종료(EOS) 안내도 그렇게 묻히기 좋은 메일입니다. 그런데 이건 한 번은 열어봐야 합니다.
먼저, 우리 회사가 해당되는지부터
PHP가 뭔지 몰라도 확인은 됩니다. 메일 본문에 고객님의 대상 서비스라는 항목이 있습니다. 거기에 우리가 쓰는 호스팅 상품 이름이 적혀 있으면 해당되는 경우, 해당사항 없음이면 지금은 아무것도 안 해도 됩니다.
PHP는 홈페이지를 움직이는 프로그래밍 언어입니다. 게시판에 글이 올라가고, 문의 폼에 남긴 내용이 메일로 날아오고, 관리자 화면에서 문구를 고치는 일이 전부 이 언어로 쓴 코드 위에서 돌아갑니다. 지원 종료란 지금 쓰는 버전에 대해 만든 쪽에서 더는 보안 문제를 고쳐주지 않겠다는 뜻입니다. 부품 생산이 끊긴 차와 비슷합니다. 오늘도 잘 굴러가지만 고장 나면 손볼 방법이 없습니다.
그대로 두면 생기는 일
작은 회사 홈페이지는 노려질 일이 없다는 오해
여기서 대부분 비슷한 반응이 나옵니다. 회원 정보도 없고 결제도 안 받는 회사 소개 사이트인데, 누가 굳이 여길 건드리겠냐는 겁니다. 충분히 나올 만한 생각입니다.
다만 공격하는 쪽이 우리 회사 정보를 원하는 게 아닐 때가 많습니다. 서버 자체가 목적입니다. SK쉴더스 분석에서는 웹사이트 취약점을 노리는 목적 중 하나로 그 서버를 악성코드 퍼뜨리는 창구나 다른 컴퓨터를 원격 조종하는 거점으로 쓰는 경우를 꼽습니다. 남의 집을 창고로 쓰는 것과 비슷합니다. 창고는 넓을 필요도, 좋은 동네에 있을 필요도 없습니다. 오히려 주인이 자주 안 들르는 집이 낫습니다. 오래 들키지 않으니까요.
들어오는 방식도 생각과 다릅니다. 누가 우리 회사를 찍어놓고 노리는 게 아닙니다. 인터넷 전체를 훑으면서 잠기지 않은 문을 찾아다니는 프로그램이 있고, 걸리면 걸리는 겁니다. 회사 규모는 변수가 아닙니다. 같은 자료가 인용한 한국인터넷진흥원 집계를 보면 2024년 침해사고의 94%가 중소기업에서 일어났습니다. 정부가 지역 중소기업 홈페이지에 무료 취약점 점검을 지원하는 것도 피해가 이쪽에 쏠려 있어서입니다.
화면은 멀쩡한데 서버가 쓰이고 있는 경우
눈에 보이는 피해는 차라리 낫습니다. 홈페이지가 이상한 화면으로 바뀌거나 검색 결과에 경고가 붙으면 그날 안에 압니다. 복구에 돈과 시간이 들어도 어쨌든 대응은 시작됩니다.
문제는 아무 일도 없어 보일 때입니다. 서버 한구석에 파일 하나가 심어지고, 그게 악성코드를 퍼뜨리는 통로가 됩니다. 방문자가 보는 화면은 그대로고, 회사에서는 홈페이지가 잘 돌아간다고 생각합니다. 보안뉴스 보도를 보면 해킹당한 웹사이트 5,400여 곳이 이런 식으로 방문자에게 악성코드를 퍼뜨리는 통로로 쓰이고 있었습니다. 상당수가 소상공인 홈페이지였고, 악성코드 본체가 블록체인에 저장돼 있어 차단도 쉽지 않았다고 합니다.
이런 건 보통 밖에서 먼저 알려줍니다. 호스팅사에서 서버를 차단했다고 연락이 오거나, 다른 사건을 수사하던 기관이 기록에 남은 서버 주인을 확인하다가 회사로 연락하는 식입니다. 우리 홈페이지가 남의 범죄에 쓰였다는 걸 그 전화로 처음 아는 겁니다. 올해 상반기 침해사고 638건을 분석한 발표에서도 비슷한 지적이 나왔습니다. 공격자들이 대단한 기술을 쓰는 게 아니라 관리가 끊긴 페이지, 허술한 계정을 노린다는 것. 새 보안 장비 사기 전에 지금 돌아가는 서버부터 보라는 얘기였습니다.
미룰수록 불리해지는 이유도 있습니다. 옛날 PHP로 짠 코드를 읽을 줄 아는 개발자가 매년 줄어듭니다. 지금은 몇 군데 고쳐서 끝날 일이 몇 년 뒤엔 새로 만드는 것 말고 답이 없어지기도 합니다.
호스팅사가 대신 해주지 않는 이유
메일에서 제일 당황스러운 대목이 이겁니다. 코드 수정과 점검은 고객 책임이고 기술 지원은 안 한다고 적혀 있습니다. 돈 내고 쓰는데 이건 왜 안 해주나 싶습니다.
서버 환경을 바꾸는 일과 그 위에서 우리 홈페이지가 돌아가게 만드는 일이 다른 작업이라서 그렇습니다. 건물 배관을 새로 까는 건 건물주가 하고, 우리 집 세탁기가 새 배관에 맞는지는 입주자가 확인하는 것과 같습니다. PHP 버전을 올리면 예전 방식으로 쓴 코드에서 오류가 나는데, 어느 파일 어느 줄인지는 그 사이트 코드를 열어봐야 압니다. 호스팅사는 고객 홈페이지 코드를 들여다보지 않습니다.
안내에 나온 담당 구분은 이렇습니다.
| 작업 | 누가 하나 |
|---|---|
| PHP 버전을 바꿀 수 있는 환경 제공 | 카페24 |
| 변경 전 자료와 데이터베이스 백업 | 운영자가 직접 |
| 기존 코드가 새 버전에서 돌아가는지 확인하고 수정 | 개발 업체 또는 담당 개발자 |
| 자료 옮기기 | 운영자가 직접, 대행 없음 |
| 옮긴 뒤 도메인 연결 정보(DNS) 다시 설정 | 운영자가 직접 |
하나만 더 짚겠습니다. PHP 버전을 바꾸면 그 서버에 있던 자료와 데이터베이스가 삭제됩니다. 백업을 미리 받아두지 않으면 그동안 쌓인 게시물이며 문의 내역이 다 사라집니다. 버튼 누르면 끝나는 작업이 아닙니다.
담당자가 지금 확인할 것
기술적인 판단은 나중 일입니다. 담당자 선에서 알아볼 수 있는 것부터 정리하면 이렇습니다.
- 안내 메일의 대상 서비스 항목에 우리 호스팅 상품이 적혀 있는지
- 홈페이지 파일과 데이터베이스 백업이 어딘가에 남아 있는지
- 사이트를 만든 업체가 어디이고 지금도 연락이 되는지
- 계약서나 인수인계 문서에 유지보수 범위가 적혀 있는지
제작사와 연락이 되는 경우
만든 곳에 먼저 물어보는 게 가장 빠릅니다. 코드를 직접 짠 쪽이라 어디를 봐야 하는지 아는 상태에서 시작합니다.
연락이 닿지 않는 경우
만든 지 5년, 10년 된 사이트라면 흔한 일입니다. 업체가 문을 닫았거나, 번호가 바뀌었거나, 당시 담당자가 퇴사해서 아무도 기억을 못 하거나. 이럴 땐 다른 업체가 코드를 넘겨받아 점검부터 시작합니다. 순서는 이렇습니다.
- 지금 코드에서 새 PHP 버전과 충돌하는 부분 찾기
- 파일과 데이터베이스 백업이 제대로 되어 있는지 확인
- 실제 서버 말고 테스트 환경에서 먼저 돌려보기
- 문제없으면 실제 서버 변경, 이후 도메인 연결 다시 설정
처음 보는 코드라 시간은 더 걸립니다. 대신 그동안 쌓인 자료를 잃지 않고 넘어갑니다.
버전만 맞출지, 구조까지 볼지
어디까지 손볼지는 사이트 상태에 따라 갈립니다. 만든 지 얼마 안 됐고 코드가 정리돼 있으면 버전 맞추는 작업으로 끝납니다. 여러 담당자를 거치면서 기능이 하나씩 붙은 오래된 사이트라면 얘기가 다릅니다. 어차피 코드 전체를 봐야 하는 상황이 됩니다.
그때 페이지 구성과 내용 정리를 같이 볼 수 있습니다. 오래된 사이트는 회사 소개랑 제품 설명, 공지사항이 여기저기 흩어져 있기 마련입니다. 어떤 페이지가 무슨 역할을 하는지 정리하고 서로 연결해두면 검색엔진이 사이트를 읽는 방식이 달라집니다. 요즘 늘어난 AI 검색에서 회사 정보가 엉뚱하게 조합되지 않고 일관되게 읽힐 가능성도 같이 올라갑니다. 나중에 담당자가 직접 문구를 고치기 편한 구조를 잡아두는 것도 이때 할 수 있는 일입니다.
당장 결정할 건 많지 않습니다. 메일에서 대상 서비스 항목 확인하고, 우리 홈페이지 만든 곳이 어디인지, 연락은 되는지 알아보면 됩니다. 그 다음은 거기서 나온 답에 따라 갈립니다.
