이 글의 링크는 추후 제휴 링크로 바뀔 수 있으며, 그 경우 구매 시 수수료를 받을 수 있습니다.
이 글에서 다루는 것
이미 열어 둔 우커머스 쇼핑몰이 느려졌을 때, 그게 서버 메모리 탓인지 아닌지를 가르는 순서입니다.
사양표를 보고 고민하기 전에 지금 내 사이트의 숫자부터 읽어야 하는 분을 위한 글입니다.
읽고 나면 증상 하나에 확인할 화면 하나가 붙고, 서버를 올릴지 말지를 근거를 갖고 결정할 수 있습니다.
같은 증상인데 범인은 셋으로 갈립니다
쇼핑몰이 느리다는 말은 대개 네 가지 모습으로 옵니다.
장바구니에 담을 때 한참 도는 경우, 결제 단계에서 멈추거나 실패하는 경우, 관리자 화면의 주문 목록이 열리지 않는 경우, 흰 화면이나 500 오류가 뜨는 경우입니다.
이 네 가지는 겉보기에 비슷하지만 원인은 메모리, CPU, 데이터베이스 셋 중 하나로 갈립니다.
그런데 검색해서 나오는 조언은 대부분 '사양을 올리세요' 하나로 수렴합니다.
메모리가 원인이 아닐 때 사양만 올리면 요금만 늘고 증상은 그대로 남습니다.
그래서 순서를 뒤집습니다.
사양을 고르기 전에 증상에서 거꾸로 올라가 어디가 막혔는지부터 정합니다.
1단계. 추측하기 전에 시스템 상태 보고서에서 숫자를 읽습니다
우커머스는 자기 진단 화면을 기본으로 갖고 있습니다.
워드프레스 관리자에서 WooCommerce, 상태 순으로 들어가면 시스템 상태 보고서가 열립니다.
우커머스 공식 문서도 설치 뒤 서버가 조건을 갖췄는지는 이 화면에서 확인하라고 적어 두었습니다.
우커머스 시스템 상태 보고서 공식 설명 화면.
표의 Field Name, Description, Example 열이 각 항목이 무엇을 뜻하는지 알려 줍니다 (2026-10-10 공식 문서 확인)
① 'Server Environment' 아래의 표가 서버 쪽 숫자입니다.
그 위 WordPress Environment 구간에는 WP Memory Limit, External Object Cache 같은 항목이 있습니다.
공식 설명에 따르면 WP Memory Limit 은 '사이트가 한 번에 쓸 수 있는 최대 메모리'이고 문서의 예시값은 256 MB 입니다.
이 화면에서 먼저 적어 둘 값은 네 개입니다.
WP Memory Limit, PHP version, PHP Time Limit, External Object Cache 의 체크 여부입니다.
PHP Time Limit 은 공식 설명으로 '한 번의 작업이 시간 초과로 끊기기 전까지 사이트가 쓸 수 있는 초'이고, 문서 예시값은 1200 입니다.
주문 목록이나 일괄 작업이 중간에 끊긴다면 메모리보다 이 값이 먼저 의심 대상입니다.
결제가 되다 말다 한다면 같은 표의 fsockopen/cURL 줄을 봅니다.
공식 설명에 '결제 게이트웨이가 외부 서버와 통신해 결제를 승인할 때 cURL 을 쓸 수 있다'고 적혀 있습니다.
여기에 체크가 없으면 사양 문제가 아니라 서버 설정 문제입니다.
2단계. 요구 사양 미달인지부터 잘라 냅니다
적어 둔 값을 우커머스 공식 요구 사양과 맞춰 봅니다.
미달이면 진단이 여기서 끝납니다.
느린 것이 아니라 애초에 조건을 못 맞춘 상태이기 때문입니다.
우커머스 공식 문서의 서버 요구 사양 화면.
문서 머리말에 'WooCommerce 10.8 and later' 기준이라고 적혀 있습니다 (2026-10-10 확인)
① 'Server requirements' 아래 목록이 조건 전부입니다.
2026년 10월 10일 화면 기준으로 워드프레스 6.9 이상, PHP 8.3 이상(PHP 8.4 까지 테스트), MySQL 8.0 이상 또는 MariaDB 10.6 이상, HTTPS 지원, 그리고 ② 워드프레스 메모리 한도 256 MB 이상입니다.
같은 문서에 PHP 7.4 와 MySQL 5.6 에서도 동작은 한다는 주석이 붙어 있지만, 그 버전들은 공식 지원이 끝났고 보안 위험에 노출될 수 있다고 함께 적혀 있습니다.
'돌아가니까 괜찮다'와 '권장 환경이다'는 다른 말입니다.
3단계. 메모리가 모자랄 때만 나오는 신호
메모리 부족은 증상이 비교적 또렷합니다.
특정 동작에서만 흰 화면이나 500 오류가 재현되고, 같은 동작을 다시 하면 또 같은 자리에서 멈춥니다.
플러그인을 하나 더 켠 날부터 시작된 경우가 많습니다.
시간대와 무관하게 '그 동작'에서 반복된다면 접속자 수가 아니라 한 번의 작업이 한도를 넘긴 쪽입니다.
상품 일괄 수정, 주문 내보내기, 이미지 대량 업로드처럼 한 번에 많은 것을 다루는 작업이 대표적입니다.
반대로 아무 때나 무작위로 느려지고 특정 동작에서 재현되지 않는다면 메모리 쪽이 아닐 가능성이 큽니다.
이때 사양을 올리면 당장은 나아진 것처럼 보이다가 방문자가 조금 늘면 같은 증상이 돌아옵니다.
4단계. CPU가 밀릴 때는 증상의 모양이 다릅니다
CPU 쪽이 원인이면 증상이 사람 수를 따라 움직입니다.
한산한 새벽에는 멀쩡하다가 알림을 보낸 직후나 특정 시간대에만 전체가 같이 느려집니다.
특정 페이지가 아니라 사이트 전부가 함께 느려지는 것이 특징입니다.
데이터베이스 쪽이면 또 다릅니다.
상품 수가 늘어난 시점부터 검색, 필터, 주문 목록처럼 조회가 많은 화면만 느려지고 정적인 소개 페이지는 멀쩡합니다.
상품이 수천 개로 늘어난 뒤에 나타나는 경우가 흔합니다.
세 가지를 구분하는 가장 싼 방법은 시간과 화면을 같이 적는 것입니다.
느렸던 시각, 그때 하던 동작, 그 시각의 접속자 수 세 가지만 며칠 적어 두면 패턴이 드러납니다.
추측보다 메모 사흘이 빠릅니다.
5단계. 캐시가 걸리지 않는 경로를 세어 봅니다
블로그와 쇼핑몰이 갈리는 지점이 여기입니다.
블로그 글은 한 번 만들어 둔 화면을 모두에게 그대로 보여 줄 수 있습니다.
그래서 사람이 열 배로 늘어도 서버가 하는 일은 그만큼 늘지 않습니다.
반면 장바구니, 결제, 내 계정, 주문 조회는 사람마다 내용이 달라서 미리 만들어 둘 수 없습니다.
방문자 한 명이 늘면 서버가 할 일도 한 명분 그대로 늘어납니다.
같은 방문자 수라도 쇼핑몰이 더 무거운 이유가 이것입니다.
그래서 셀 것은 전체 방문자 수가 아니라 '장바구니에 담은 사람 수'와 '결제를 시작한 사람 수'입니다.
이 둘이 늘지 않았는데 느려졌다면 원인은 쇼핑 기능이 아니라 다른 데 있습니다.
그다음에 볼 것이 외부 오브젝트 캐시입니다.
시스템 상태 보고서의 External Object Cache 줄이 비어 있다면 데이터베이스 조회가 매번 날것으로 나가고 있다는 뜻입니다.
상품이 많은 쇼핑몰에서는 이 한 줄이 체감을 크게 바꿉니다.
증상별 점검표
| 증상 | 먼저 의심할 곳 | 확인할 화면 | 다음 조치 |
|---|---|---|---|
| 특정 동작에서만 흰 화면, 500 오류 | 메모리 | 시스템 상태 보고서 WP Memory Limit | 한도 상향, 그래도 재현되면 사양 |
| 주문 목록, 일괄 작업이 중간에 끊김 | 실행 시간 | Server Environment 의 PHP Time Limit | 시간 한도 조정, 작업을 나눠서 실행 |
| 사람이 몰리는 시간대에만 전체가 느림 | CPU | 느렸던 시각과 접속자 수 메모 | 코어 수 상향 또는 캐시 설정 |
| 검색, 필터, 주문 목록만 느림 | 데이터베이스 | External Object Cache 체크 여부 | 오브젝트 캐시 도입, 조회 줄이기 |
| 결제만 되다 말다 함 | 서버 설정 | Server Environment 의 fsockopen/cURL | 호스팅사에 해당 항목 문의 |
호스팅이 원인으로 좁혀졌을 때의 선택지
위 네 단계를 거쳐 '설정으로는 더 못 줄인다'까지 왔다면 그때가 서버를 보는 자리입니다.
관리형 클라우드 호스팅은 메모리와 코어 수를 구간으로 골라 쓰고, 모자라면 구간을 올리는 방식입니다.
클라우드웨이즈 공식 요금 페이지의 구간별 메모리와 월 요금 (2026-10-10 확인)
① 가장 낮은 Micro 구간이 1GB RAM, 1 vCPU, 25GB NVMe, 전송량 1TB 에 월 14달러입니다.
② Small 이 2GB RAM, 1 vCPU, 50GB NVMe, 2TB 에 월 28달러, ③ Medium 이 4GB RAM, 2 vCPU, 80GB NVMe, 4TB 에 월 54달러이고, 그 위 Large 는 8GB RAM, 4 vCPU 에 월 99달러입니다.
모두 세금 별도 표기입니다.
공식 카드 설명은 쇼핑몰을 가장 비싼 Large 칸('Ideal for e-com stores')에 적어 두었지만, 그 말을 그대로 따를 필요는 없습니다.
이제 막 여는 쇼핑몰이라면 낮은 구간에서 시작해 앞에서 정한 지표가 실제로 걸릴 때 올리는 편이 돈이 덜 듭니다.
구간을 올리는 일은 나중에도 되지만, 쓰지 않은 사양에 낸 돈은 돌아오지 않습니다.
구간별 메모리와 월 요금을 공식 요금 페이지에서 오늘 날짜로 직접 확인하기
같은 페이지의 전 구간 포함 항목 안내.
오브젝트 캐시는 4GB 이상 서버라는 조건이 붙어 있습니다 (2026-10-10 확인)
① 포함 항목 중 Object Cache Pro 에는 '4GB 서버 이상에서 무료'라는 조건이 달려 있습니다.
5단계에서 데이터베이스 조회가 원인으로 나왔다면 이 조건이 구간 선택의 근거가 됩니다.
반대로 메모리나 CPU가 원인이었다면 이 항목 때문에 구간을 올릴 이유는 없습니다.
카드 없이 시작하는 사흘 무료 체험 안내 (2026-10-10 확인)
① 사흘짜리 체험이 카드 없이 열립니다.
결정 전에 쓰는 가장 싼 방법은, 지금 쇼핑몰의 복사본을 올려 두고 앞에서 적어 둔 네 개의 값을 같은 화면에서 다시 읽어 보는 것입니다.
숫자가 바뀌지 않으면 원인은 서버가 아니었던 것입니다.
사흘 체험으로 같은 설정을 올려 숫자가 바뀌는지 재 보기
서버를 올려도 풀리지 않는 경우
사양은 만능이 아닙니다.
다음에 해당하면 구간을 올려도 체감은 거의 그대로입니다.
첫째, 느린 원인이 특정 플러그인 하나일 때입니다.
플러그인을 하나씩 끄며 재현되는지 보는 쪽이 빠릅니다.
둘째, 이미지 용량이 큰 상품 사진이 수백 장일 때입니다.
이건 서버가 아니라 파일 쪽 문제입니다.
셋째, 느림이 한국에서만 체감되고 해외에서는 멀쩡할 때입니다.
이건 사양이 아니라 거리와 경로 문제라 다른 해법을 봐야 합니다.
관리형 클라우드 호스팅 자체가 맞지 않는 경우도 분명히 있습니다.
결제가 달러로 이뤄져 환율에 따라 월 청구액이 달라지고, 관리 화면과 고객지원이 영어이며, 메일 호스팅은 요금에 포함되지 않고 별도 과금 항목입니다.
국내 결제와 한국어 지원이 더 중요하거나, 월 몇천 원짜리 공유 호스팅으로 충분한 규모라면 그대로 두는 편이 낫습니다.
자주 묻는 질문
메모리 부족인지 CPU 부족인지 한 가지만 보고 알 수 있나요
한 가지만 본다면 '재현되는가'입니다.
특정 동작에서 매번 같은 자리에 멈추면 메모리나 실행 시간 쪽이고, 시간대에 따라 들쭉날쭉하면 CPU 쪽입니다.
이 구분이 서면 나머지 확인은 빨라집니다.
흰 화면이 떴는데 시스템 상태 보고서도 안 열립니다
관리자 화면까지 막힌 상태라면 보고서를 볼 수 없습니다.
이때는 먼저 사이트를 열리게 만든 뒤에 진단합니다.
순서가 반대가 되면 고치는 동안 매출이 계속 빠집니다.
상품을 몇 개까지 올리면 사양을 올려야 하나요
상품 수만으로는 정해지지 않습니다.
같은 1천 개라도 옵션과 변형이 많은 상품과 단순 상품은 부담이 다릅니다.
숫자로 정하고 싶다면 상품 수 대신 장바구니에 담은 사람 수와 결제 시작 수를 기준으로 삼으세요.
지금 쓰는 공유 호스팅에서 먼저 해 볼 것이 있을까요
있습니다.
워드프레스 메모리 한도를 요구 사양인 256 MB 이상으로 올려 달라고 요청하고, PHP 버전을 8.3 이상으로 올리고, 쓰지 않는 플러그인을 지우는 것까지는 요금 변동 없이 됩니다.
그래도 같은 증상이면 그때가 서버를 보는 자리입니다.
마무리
쇼핑몰이 느릴 때 사양표를 먼저 펼치지 말고, 시스템 상태 보고서에서 네 개의 숫자부터 읽습니다.
증상이 특정 동작에서 재현되면 메모리나 실행 시간, 시간대를 타면 CPU, 조회 화면만 느리면 데이터베이스 쪽입니다.
호스팅으로 좁혀졌을 때만 구간을 보고, 그때도 가장 낮은 구간에서 시작해 지표가 걸릴 때 올립니다.
지금 쇼핑몰에서 가장 자주 겪는 증상은 넷 중 어느 쪽인가요.
상품 수와 함께 댓글로 남겨 주시면 어디부터 볼지 같이 정리해 보겠습니다.
다음 글에서는 「네이버 블로그와 워드프레스, 수익 구조가 어떻게 다른가」에 대해 알아보겠습니다.