웹사이트를 운영하다 보면 어느 날 갑자기 사이트가 느려졌다고 느껴질 때가 있습니다. 페이지를 열었는데 한참 뒤에 화면이 나타나거나, 평소에는 괜찮다가 특정 시간대만 되면 느려지기도 합니다. 워드프레스 관리자 화면까지 답답해지는 경우도 있습니다.

서버 사양부터 높여야 할까? 고민이 되지만 대부분 그럴 필요는 없습니다.

웹사이트의 속도가 느려지는 이유는 생각보다 다양합니다. 이미지나 영상처럼 페이지 자체가 무거울 수도 있고, 특정 플러그인이 과도한 데이터베이스 쿼리를 발생시키고 있을 수도 있습니다. 스팸봇의 반복적인 접근이나 로그인 공격 때문에 서버가 바빠진 것일 수도 있습니다. 심지어 내 웹사이트에는 아무런 문제가 없는데 같은 서버를 사용하는 다른 웹사이트 때문에 느려질 수도 있습니다.

따라서 서버 사양을 높이거나 캐시 플러그인을 설치하기 전에 어디에서 문제가 발생하고 있는지부터 찾는 것이 중요합니다.

워드프레스 웹사이트가 느려졌을 때 크리에이티브밴드에서는 다음과 같은 순서로 원인을 확인합니다.

1. 먼저 웹사이트의 ‘어디가’ 느린지 확인합니다

사이트가 느리다고 해서 모두 같은 문제는 아닙니다.
먼저 몇 가지를 구분해야 합니다.

• 첫 화면이 나타나기까지 오래 걸리는가?
• 화면은 나타나지만 이미지나 콘텐츠가 늦게 표시되는가?
• 특정 페이지만 느린가?
• 사이트 전체가 느린가?
• 워드프레스 관리자 화면도 느린가?
• 처음 접속할 때만 느리고 이후에는 빨라지는가?
• 특정 시간대에만 느려지는가?

특히 중요한 것은 서버가 첫 번째 응답을 보내는 것 자체가 느린 것인지, 서버 응답 이후 브라우저가 화면을 만드는 과정이 느린 것인지 구분하는 것입니다.

전자는 TTFB(Time to First Byte), 서버 처리 속도, 데이터베이스, 캐시, 트래픽 등을 의심할 수 있습니다. 반면 서버는 빠르게 응답했는데 큰 이미지와 JavaScript를 다운로드하고 실행하느라 화면이 늦게 나타난다면 프론트엔드 최적화 문제일 가능성이 높습니다.

그래서 PageSpeed Insights의 점수가 낮다고 무조건 서버가 느리다고 판단해서는 안 됩니다. 속도 문제를 해결하는 첫 번째 단계는 최적화가 아니라 병목 구간을 찾는 것입니다.

2. 비정상적인 봇이나 공격 트래픽이 들어오고 있지 않은지 확인합니다

사이트는 그대로인데 갑자기 느려졌다면 가장 먼저 확인해볼 만한 것 중 하나가 비정상적인 접근입니다. 워드프레스는 전 세계적으로 많이 사용되는 CMS이기 때문에 자동화된 공격의 대상이 되기 쉽습니다. 봇들은 워드프레스 사이트를 발견하면 다양한 URL에 접근하며 로그인 페이지와 취약점을 찾습니다.

/wp-login.php, /wp-admin/, /xmlrpc.php뿐만 아니라 존재하지 않는 수많은 경로를 짧은 시간 동안 반복적으로 요청하기도 합니다.

특히 영문 콘텐츠가 있거나 다국어 사이트를 운영한다면 해외 검색엔진과 크롤러에 노출되는 범위가 넓어지면서 정상적인 검색봇뿐 아니라 스팸봇과 스크래퍼의 접근도 많아질 수 있습니다.

문제는 해킹에 성공해야만 서버에 문제가 생기는 것이 아니라는 점입니다. 공격자가 로그인 페이지를 찾기 위해 1분 동안 수백, 수천 개의 요청을 보내고 서버가 그 요청을 하나하나 처리한다면 그것만으로 CPU와 PHP Worker, 데이터베이스 자원이 소비됩니다.

로그인 페이지를 찾아낸 뒤에는 상황이 더 나빠질 수 있습니다. 관리자 계정을 탈취하기 위해 아이디와 비밀번호 조합을 계속 바꿔가며 로그인하는 Brute Force 공격이 이어질 수 있기 때문입니다.

Cloudflare와 같은 리버스 프록시나 WAF가 앞단에 있다면 상당수의 비정상 요청을 웹서버에 도달하기 전에 차단할 수 있습니다. 그렇지 않다면 서버가 공격 요청을 직접 받아 처리해야 합니다.

Wordfence와 같은 보안 플러그인의 로그와 서버 Access Log를 확인해 특정 IP나 URL에 비정상적으로 많은 요청이 집중되고 있지는 않은지 살펴볼 필요가 있습니다.

3. 이미지와 영상이 지나치게 무겁지 않은지 확인합니다

웹페이지에서 가장 많은 용량을 차지하는 요소는 대개 이미지와 영상입니다. 예를 들어 화면에서는 가로 400px 정도로 표시되는 이미지인데 실제로는 3,000px짜리 원본 이미지를 내려받고 있다면 사용자는 필요 이상으로 큰 파일을 다운로드하게 됩니다.

특히 목록 페이지를 주의해야 합니다. 메인페이지나 아카이브에 게시물 20개가 있고 각 게시물이 몇 MB에 이르는 원본 이미지를 호출한다면 페이지 하나를 보는 것만으로 수십 MB를 내려받게 될 수도 있습니다.

워드프레스는 업로드한 이미지로 여러 크기의 이미지를 자동 생성하고 srcset을 통해 화면 환경에 적합한 이미지를 제공할 수 있습니다. 테마를 개발할 때도 목록, 상세페이지, 썸네일 등 이미지의 용도에 맞는 크기를 사용하는 것이 중요합니다. WebP나 AVIF 같은 효율적인 이미지 포맷과 Lazy Loading 적용 여부도 확인할 필요가 있습니다.

영상은 더 주의해야 합니다.

서버에 직접 MP4나 WebM 영상을 올려 배경 영상이나 콘텐츠로 사용하면 웹서버의 트래픽과 전송량이 크게 증가할 수 있습니다. 직접 제공해야 하는 영상이라면 길이, 해상도, 비트레이트와 용량을 충분히 최적화해야 합니다. 일반적인 콘텐츠 영상이라면 YouTube나 Vimeo 같은 외부 영상 플랫폼을 이용하는 것이 서버 부담을 줄이는 방법이 될 수 있습니다.

4. CSS와 JavaScript가 페이지 렌더링을 방해하고 있지 않은지 확인합니다

이미지 용량은 크지 않은데 페이지가 버벅거리거나 화면이 늦게 완성된다면 CSS와 JavaScript도 확인해야 합니다. 워드프레스에서는 테마뿐 아니라 각각의 플러그인이 자신의 CSS와 JavaScript를 추가할 수 있습니다.

문제는 특정 페이지에서만 필요한 기능인데 사이트 전체에서 관련 파일을 불러오는 경우입니다. 슬라이더, 팝업, 폼, 차트, 애니메이션, 지도 등의 기능을 계속 추가하다 보면 실제 페이지에서는 사용하지 않는 수많은 CSS와 JavaScript가 함께 로딩될 수 있습니다.

Google Analytics, Google Tag Manager, 채팅 상담, 광고, SNS 등 외부 스크립트도 마찬가지입니다.

JavaScript가 많다고 무조건 문제가 되는 것은 아닙니다. 중요한 것은 필요한 코드만 필요한 페이지에서 적절한 시점에 실행되고 있는가입니다. Render Blocking 리소스, defer와 async 적용 여부, 사용하지 않는 CSS/JS, 과도한 웹폰트와 font-weight 등도 함께 점검합니다.

5. 플러그인이나 테마가 과도한 데이터베이스 쿼리를 만들고 있지 않은지 확인합니다

워드프레스 페이지는 단순히 HTML 파일 하나를 가져와 보여주는 방식으로 만들어지지 않습니다. 요청이 들어오면 PHP가 실행되고 데이터베이스에서 게시물, 메타데이터, 옵션, 사용자 정보 등 필요한 데이터를 가져와 페이지를 생성합니다. 따라서 특정 기능이 비효율적인 쿼리를 반복해서 실행한다면 이미지가 아무리 잘 최적화되어 있어도 서버 응답 자체가 느려질 수 있습니다.

예를 들어 게시물의 조회수를 postmeta에 저장하고 수많은 게시물을 조회수 순서대로 정렬해 인기 콘텐츠를 매번 계산한다고 가정해보겠습니다. 게시물이 적을 때는 문제가 없을 수 있습니다. 하지만 데이터가 계속 쌓이고 방문자가 늘어나면 같은 쿼리를 반복해서 실행하는 것만으로 데이터베이스 부하가 크게 증가할 수 있습니다.

복잡한 meta_query, 검색, 정렬, 관련 게시물, 방문 통계 등의 기능은 특히 주의할 필요가 있습니다.

Query Monitor 같은 도구를 이용하면 페이지가 만들어질 때 어떤 데이터베이스 쿼리가 실행되고 있는지, 어떤 쿼리가 오래 걸리는지, 어느 플러그인이나 테마에서 호출됐는지 확인하는 데 도움이 됩니다.

처음에는 문제가 없었던 기능이 데이터가 쌓인 몇 년 뒤에는 성능 문제의 원인이 될 수도 있습니다.

6. 사용자가 보지 않는 곳에서 백그라운드 작업이 실행되고 있지 않은지 확인합니다

사이트 화면에서는 특별한 일이 일어나지 않는 것처럼 보여도 서버에서는 여러 작업이 실행되고 있을 수 있습니다. 대표적인 것이 WP-Cron입니다. 예약 게시물 발행부터 이메일 발송, 플러그인 작업, 데이터 정리 등 다양한 기능이 WordPress의 예약 작업을 이용합니다.

여기에 백업 플러그인의 전체 백업, 보안 플러그인의 악성코드 검사, 이미지 최적화, 검색 인덱스 생성, 통계 데이터 처리, 외부 서비스와의 데이터 동기화 등이 동시에 실행되면 상당한 서버 자원을 사용할 수 있습니다.

특히 “매일 새벽만 되면 느려진다”거나 “일정한 시간마다 갑자기 느려진다”면 예약된 작업이 있는지 확인해볼 필요가 있습니다.

7. 외부 서비스의 응답을 기다리고 있지 않은지 확인합니다

웹사이트의 모든 요소가 내 서버에서 제공되는 것은 아닙니다. Google Analytics, Tag Manager, YouTube, Vimeo, Google Maps, SNS 게시물, 채팅 상담, 광고, 외부 웹폰트 등 다양한 외부 서비스를 사용할 수 있습니다.

외부 API에서 데이터를 가져와 페이지를 만드는 경우도 있습니다.

이때 내 서버의 상태가 아무리 좋아도 외부 서비스의 응답이 느리면 페이지의 일부 기능이나 표시가 늦어질 수 있습니다. 따라서 속도를 진단할 때는 우리 서버의 성능뿐 아니라 브라우저가 어떤 외부 서버와 통신하고 있는지도 확인해야 합니다.

브라우저 개발자 도구의 Network 패널을 확인하면 어떤 파일과 외부 요청이 오래 걸리고 있는지 비교적 쉽게 확인할 수 있습니다.

8. 캐시가 제대로 작동하고 있는지 확인합니다

워드프레스는 요청이 들어올 때마다 PHP와 데이터베이스를 이용해 페이지를 동적으로 생성할 수 있습니다. 하지만 내용이 바뀌지 않는 페이지를 방문자가 들어올 때마다 처음부터 다시 만드는 것은 비효율적입니다.

그래서 캐시를 사용합니다.

Page Cache가 정상적으로 동작하면 미리 만들어진 결과물을 제공할 수 있어 PHP와 데이터베이스가 처리해야 하는 작업을 크게 줄일 수 있습니다. 브라우저 캐시, Object Cache, PHP OPcache, CDN 등도 각각 다른 단계에서 반복 작업과 데이터 전송을 줄여줍니다.

중요한 것은 단순히 “캐시 플러그인을 설치했다”가 아닙니다. 실제 요청에서 캐시가 HIT 되고 있는지, 특정 페이지가 계속 캐시에서 제외되고 있지는 않은지 확인해야 합니다.

반대로 잘못된 캐시 설정이나 여러 최적화 플러그인의 중복 사용이 문제를 일으키는 경우도 있으므로 무조건 많은 캐시 기능을 켜는 것이 정답은 아닙니다.

9. 서버의 CPU, 메모리, 디스크와 PHP 환경을 확인합니다

앞의 요소를 확인했다면 이제 서버 자체의 상태를 살펴볼 차례입니다. CPU 사용률이 계속 높지는 않은지, 메모리가 부족하지 않은지, 디스크 공간이 가득 차지는 않았는지 확인합니다. PHP-FPM Worker가 부족하거나 데이터베이스 부하가 높아져 요청이 대기하고 있을 수도 있습니다.

특히 디스크 용량은 의외로 놓치기 쉽습니다. 백업 파일, 로그, 캐시 파일, 이미지와 영상이 오랫동안 쌓이면서 디스크가 가득 차면 데이터베이스나 PHP가 정상적으로 작업하지 못하면서 갑작스러운 장애로 이어질 수 있습니다.

서버 사양을 높이면 당장은 빨라질 수도 있습니다. 하지만 CPU를 100% 사용하게 만든 원인이 비정상적인 봇의 반복 접근이나 잘못된 데이터베이스 쿼리였다면 서버 사양을 두 배로 높이는 것은 근본적인 해결책이 아닙니다.

서버 자원이 부족하다면 먼저 ‘왜 부족해졌는가’를 확인해야 합니다.

10. 공유호스팅이라면 내 웹사이트가 원인이 아닐 수도 있습니다

마지막으로 공유호스팅을 사용하고 있다면 꼭 생각해봐야 할 문제가 있습니다. 내 웹사이트에는 아무런 변화가 없는데 어느 날 갑자기 느려질 수 있습니다. 공유호스팅은 하나의 서버 자원을 여러 사용자가 함께 이용하는 구조입니다.

따라서 내 사이트의 방문자가 늘어나지 않았고 이미지, 플러그인, 데이터베이스에도 문제가 없더라도 같은 서버에 있는 다른 웹사이트의 트래픽이나 작업량이 급증하면 영향을 받을 수 있습니다. 이 경우 사이트 운영자가 WordPress 안에서 아무리 원인을 찾아도 문제가 발견되지 않을 수 있습니다.

특히 다음과 같은 현상이 나타난다면 호스팅 환경도 의심해볼 필요가 있습니다.

• 사이트를 수정하지 않았는데 갑자기 느려졌다.
• 특정 시간대에만 반복적으로 느려진다.
• 관리자 화면과 프론트 화면이 동시에 느려진다.
• 방문자와 트래픽은 오히려 줄었는데 서버 응답은 느려졌다.
• 며칠 뒤 아무런 조치를 하지 않았는데 다시 정상으로 돌아왔다.

이럴 때는 호스팅 업체에 해당 시간대의 서버 상태와 자원 사용 상황을 문의해야 합니다. 공유호스팅의 한계가 반복적으로 나타난다면 VPS, 클라우드 서버 또는 자원 격리가 보다 명확한 호스팅 환경으로 이전하는 것도 검토해야 합니다.

무조건 서버 사양부터 높이지 마세요

웹사이트가 느려지면 가장 쉬운 해결 방법은 더 비싼 서버를 사용하는 것입니다. 하지만 서버를 업그레이드하기 전에 해야 할 일이 있습니다.

왜 느려졌는지 확인하는 것입니다.

비정상적인 봇이 초당 수많은 요청을 보내고 있다면 트래픽을 차단해야 합니다. 3MB짜리 원본 이미지를 수십 장 불러오고 있다면 이미지를 최적화해야 합니다. 특정 플러그인이 수백 개의 데이터베이스 쿼리를 반복하고 있다면 해당 기능을 개선해야 합니다. 백업과 보안 스캔이 동시에 실행되고 있다면 실행 시간을 조정할 수 있습니다.

그리고 공유호스팅의 다른 사용자가 문제라면 내 워드프레스 사이트를 아무리 최적화해도 해결되지 않습니다.

결국 웹사이트 속도 최적화에서 가장 중요한 것은 무조건 파일을 줄이고 캐시를 적용하는 것이 아니라 병목이 어디에서 발생하고 있는지 정확하게 찾아내는 것입니다.

사이트가 느려졌다면 다음 순서로 확인해보세요.

비정상 트래픽 → 이미지·영상 → CSS·JavaScript → 데이터베이스 쿼리 → 백그라운드 작업 → 외부 서비스 → 캐시 → 서버 자원 → 호스팅 환경

원인을 확인한 다음 그 원인에 맞는 최적화를 진행해야 합니다. 그것이 서버 비용을 불필요하게 높이지 않으면서 안정적으로 워드프레스 웹사이트를 운영하는 가장 좋은 방법입니다.