기초부터 운영까지 워드프레스 자주 묻는 질문

웹사이트를 만들고 운영하는 소프트웨어입니다. 서버에 설치해 두면 브라우저에서 로그인해 글을 쓰고 메뉴를 바꾸고 디자인을 고를 수 있습니다 — 그때마다 HTML 을 직접 손댈 필요가 없습니다.

이런 종류의 프로그램을 CMS(콘텐츠 관리 시스템)라고 부릅니다. 블로그로 시작했지만 지금은 회사 홈페이지 · 쇼핑몰 · 예약 사이트 · 포트폴리오까지 대부분의 웹사이트를 만들 수 있습니다.

wordpress.org 는 소프트웨어를 내려받는 곳입니다. 내 서버에 직접 설치하고, 그 사이트의 파일과 데이터베이스를 전부 내가 소유합니다. 흔히 “설치형” 이라고 부릅니다.

wordpress.com 은 그 소프트웨어를 대신 돌려 주는 회사 서비스입니다. 설치가 필요 없는 대신 요금제에 따라 쓸 수 있는 플러그인과 코드 수정 범위가 제한됩니다.

이 사이트에서 다루는 것은 설치형(.org) 입니다. 지원 사업도 설치형만 대상으로 합니다.

워드프레스 자체는 무료이고, GPL 이라는 오픈소스 라이선스로 배포됩니다. 상업적으로 써도 되고, 원하면 코드를 고쳐도 됩니다.

다만 사이트를 운영하는 데는 돈이 듭니다 — 서버(호스팅) 비용과 도메인 비용은 별도이고, 유료 테마나 플러그인을 고르면 그 비용도 더해집니다. 자세한 항목은 비용 · 호스팅 분류에 정리해 두었습니다.

회사 소개 사이트 · 블로그 · 매거진 · 포트폴리오 · 예약 페이지 · 온라인 상점까지 넓게 씁니다. 무엇을 만들지는 테마(생김새)와 플러그인(기능)의 조합이 정합니다.

반대로 잘 맞지 않는 경우도 있습니다. 실시간 협업 도구나 복잡한 사내 업무 시스템처럼 화면마다 로직이 다른 애플리케이션은 처음부터 전용으로 개발하는 편이 낫습니다.

테마는 생김새입니다. 글꼴 · 색 · 레이아웃 · 메뉴 위치처럼 사이트가 어떻게 보이는지를 담당하며, 한 번에 하나만 활성화됩니다.

플러그인은 기능입니다. 문의 폼 · 결제 · SEO 도구 · 백업처럼 워드프레스가 기본으로 하지 않는 일을 붙여 줍니다. 여러 개를 동시에 켤 수 있습니다.

테마를 바꾸면 옷이 바뀌고, 플러그인을 끄면 그 기능이 사라집니다 — 이 구분을 알아 두면 문제가 생겼을 때 어디를 봐야 할지가 분명해집니다.

글을 쓰고 메뉴를 만들고 이미지를 올리는 일상 운영은 코드를 몰라도 됩니다. 테마를 고르고 색을 바꾸는 정도도 대부분 관리자 화면에서 됩니다.

코드가 필요해지는 지점은 대체로 셋입니다 — ① 테마가 제공하지 않는 레이아웃을 만들 때 ② 플러그인끼리 충돌해 원인을 찾을 때 ③ 서버 설정을 손볼 때. 앞의 둘은 노하우에서 다루고, 셋째는 저희가 지원 사업으로 대신하는 일입니다.

정확히 말하면, 워드프레스가 약한 것이 아니라 널리 쓰이고 코드가 공개되어 있어 공격자의 관심이 끊이지 않는다는 뜻입니다. 그것은 개방성의 이면이지 결함이 아닙니다.

실제로 취약점은 대개 공개되는 날 패치도 함께 나옵니다. 사고는 그 패치를 적용하지 않은 채 몇 해가 지난 사이트에서 일어납니다 — 즉 문제는 도구가 아니라 방치입니다.

업데이트를 제때 하고, 안 쓰는 플러그인을 지우고, 관리자 계정을 관리하면 대부분 막힙니다. 그 작업을 대신 맡는 것이 저희가 하는 일입니다.

관리자로 로그인한 뒤 알림판 첫 화면 오른쪽 아래 “한눈에 보기” 영역에 “WordPress x.x 버전 실행 중” 이라고 표시됩니다. 도구 → 사이트 건강 → 정보 에서도 볼 수 있습니다.

버전이 최신보다 여러 단계 뒤에 있다면 그 사이에 공개된 보안 패치가 전부 빠져 있다는 뜻입니다. 무엇이 밀려 있는지 한 번에 보고 싶으시면 무료 진단 도구를 쓰실 수 있습니다.

빌더형 서비스는 시작이 빠릅니다. 서버를 고를 필요도, 업데이트를 챙길 필요도 없습니다. 대신 기능과 디자인이 그 서비스가 허용하는 범위 안으로 제한되고, 사이트를 다른 곳으로 옮기기 어렵습니다.

워드프레스는 소유와 이동이 자유롭습니다. 파일과 데이터베이스가 전부 내 것이라 서버를 바꿔도 사이트가 그대로 따라옵니다. 대신 업데이트와 백업을 스스로 챙겨야 합니다.

“오래 운영할 것인가, 얼마나 바꿔 나갈 것인가” 가 갈림길입니다. 관리 부담이 걱정이시면 그 부분만 맡기는 방법도 있습니다.

관리자 화면과 대부분의 주요 플러그인이 한국어를 지원하고, 한글 폰트와 검색 노출도 설정으로 충분히 다룰 수 있습니다.

국내 환경에서 따로 챙길 것은 있습니다 — 네이버 검색 등록은 구글과 절차가 다르고, 국내 결제(PG) 연동은 해외 플러그인이 그대로 맞지 않는 경우가 많으며, 한글 주소(슬러그)는 서버 설정에 따라 문제가 되기도 합니다.

이런 지점은 SEO 와 서버 · 인프라 노하우에서 하나씩 다룹니다.

고정으로 드는 것은 둘입니다 — 도메인(연 단위)과 호스팅(월 단위). 워드프레스 소프트웨어 자체는 무료입니다.

여기에 선택 항목이 붙습니다: 유료 테마(대개 1회 구매), 유료 플러그인(연 단위 갱신이 많습니다), 그리고 직접 하지 않는 작업의 인건비.

금액은 업체와 사양에 따라 크게 달라지므로 여기에 적지 않습니다. 다만 가장 흔한 실수는 호스팅을 너무 싸게 잡는 것입니다 — 뒤에서 성능과 보안 작업의 폭을 그 선택이 결정합니다.

웹호스팅(공유 호스팅) 은 한 서버를 여러 사이트가 나눠 씁니다. 싸고 설치가 쉽지만, 서버 설정을 바꿀 권한이 없고 옆 사이트의 부하가 내 사이트 속도에 영향을 줍니다. cPanel 같은 관리 화면을 쓰는 경우가 여기 해당합니다.

서버호스팅(VPS · 클라우드 · 전용 서버) 은 서버 한 대(또는 그 몫)를 내가 씁니다. root 권한이 있어 웹서버 · PHP · 캐시를 원하는 대로 구성할 수 있습니다.

저희 지원 사업이 서버호스팅만 받는 이유가 이것입니다 — 공유 호스팅에서는 약속드린 작업 자체가 불가능합니다.

업체 이름보다 조건을 보십시오.

• root 또는 sudo 접근 — 없으면 성능·보안 작업의 폭이 크게 줄어듭니다
• PHP 버전을 고를 수 있는가 — 오래된 PHP 에 묶이면 최신 워드프레스를 못 씁니다
• 메모리 — 워드프레스는 이미지 처리에서 메모리를 크게 씁니다. 너무 작으면 업로드가 실패합니다
• 백업 · 스냅샷 기능 — 사고가 났을 때 돌아갈 자리가 있는가
• 서버 위치 — 방문자가 국내라면 국내 리전이 응답 시간에 유리합니다

도메인 없이도 서버 주소로 접속은 되지만, 실제 운영에는 필요합니다 — 기억할 수 있고, HTTPS 인증서를 붙일 수 있고, 서버를 옮겨도 주소가 유지됩니다.

호스팅과 같은 곳에서 살 필요는 없습니다. 어디서 사든 DNS 설정에서 호스팅 서버를 가리키게 하면 됩니다. 오히려 도메인과 호스팅을 다른 곳에 두면 나중에 한쪽만 옮기기 쉽습니다.

아닙니다. 공식 디렉터리의 무료 테마로도 충분한 사이트가 많습니다.

유료 테마가 값을 하는 경우는 대체로 이미 만들어진 레이아웃이 내가 필요한 것과 거의 같을 때입니다. 그때는 개발 시간을 사는 셈이 됩니다.

다만 유료 테마에는 조건이 하나 붙습니다 — 라이선스가 만료되면 업데이트가 오지 않습니다. 갱신되지 않는 테마는 시간이 지날수록 취약점 노출이 커지므로, 구매 전에 갱신 비용까지 계산에 넣으십시오.

쓰지 마십시오. 이런 배포본(흔히 nulled 라고 부릅니다)에는 백도어가 심어져 있는 경우가 많습니다 — 설치하는 순간 사이트의 통제권을 남에게 넘기는 셈이 됩니다.

비용이 부담이시라면 무료 대안을 찾는 편이 낫습니다. 대부분의 기능은 공식 디렉터리에 무료판이 있고, 없다면 그 기능이 정말 필요한지 다시 볼 만합니다.

덧붙여, 정품이라도 갱신되지 않는 유료 플러그인은 같은 문제를 만듭니다 — 취약점이 공개돼도 패치가 오지 않기 때문입니다.

무통장입금 270,000원(VAT 포함), PayPal $200 USD 입니다. 사이트 규모에 따라 달라지지 않는 고정 금액입니다.

여기에 업그레이드 · 성능 최적화 · SEO 기술 지원 · 보안 하드닝 · Docker 기반 배포 구성이 한 건으로 들어갑니다. 포함되지 않는 항목은 지원 사업 페이지에 같은 비중으로 적어 두었습니다.

지속 관제가 필요하시면 InfraGuard 이용권이 별도로 있습니다 — 월 120,000원 / $80 이고, 캠페인 신청자에게는 한 달 체험이 기본 포함됩니다.

작업 착수 전이라면 전액 환불됩니다. 착수 후에는 진행된 범위에 따라 처리하며, 기준과 절차는 환불 절차 페이지에 조건별로 적어 두었습니다.

가장 흔한 환불 사유는 호스팅 환경이 조건에 맞지 않는 경우인데, 그것을 결제 후에 알게 되는 일이 없도록 신청 단계에서 먼저 확인합니다.

길은 둘입니다.

호스팅의 자동 설치 — 많은 업체가 관리 화면에서 클릭 몇 번으로 설치해 줍니다. 가장 빠릅니다.

직접 설치 — wordpress.org 에서 압축 파일을 받아 서버에 올리고, 데이터베이스를 하나 만든 뒤 브라우저로 접속하면 설치 마법사가 뜹니다. 필요한 정보는 DB 이름 · 사용자 · 비밀번호 · 호스트 네 가지입니다.

어느 쪽이든 설치 직후에 관리자 아이디를 admin 이 아닌 것으로 두고, 비밀번호를 길게 잡으십시오 — 자동화된 로그인 시도가 가장 먼저 노리는 조합입니다.

HTTPS 인증서가 없거나 적용되지 않은 상태입니다. 요즘은 무료 인증서(Let’s Encrypt)를 대부분의 호스팅이 자동으로 발급해 주므로, 먼저 호스팅 관리 화면에서 켜 보십시오.

인증서를 붙였는데도 자물쇠가 안 뜬다면 혼합 콘텐츠일 가능성이 높습니다 — 페이지는 https 로 열리는데 안의 이미지나 스크립트가 http 주소로 남아 있는 경우입니다. 설정 → 일반의 주소 두 칸을 https 로 바꾸고, 본문에 남은 http 주소를 함께 교체해야 합니다.

사이트 주소 뒤에 /wp-admin/ 을 붙이면 됩니다 — 예: example.com/wp-admin/. 로그인되어 있지 않으면 로그인 화면(/wp-login.php)으로 넘어갑니다.

이 주소는 워드프레스라면 어디나 같기 때문에 자동화된 로그인 시도가 끊이지 않습니다. 그래서 긴 비밀번호와 2단계 인증이 실질적인 방어이고, 주소를 바꾸는 것만으로는 충분하지 않습니다.

글(post) 은 시간 순으로 쌓이는 콘텐츠입니다. 날짜가 있고, 카테고리와 태그로 묶이며, 목록에 최신 순으로 나열됩니다 — 공지 · 블로그 · 소식이 여기 해당합니다.

페이지(page) 는 시간과 무관한 고정 콘텐츠입니다. 회사 소개 · 이용약관 · 문의처럼 한 번 만들어 두고 메뉴에 거는 것들입니다. 카테고리가 없는 대신 상하 관계를 만들 수 있습니다.

헷갈리면 이렇게 판단하십시오 — “이것이 목록에 쌓여야 하는가?” 그렇다면 글, 아니면 페이지입니다.

설정 → 고유주소 에서 바꿉니다. “글 이름” 을 고르면 /글-제목/ 형태가 되어 사람도 검색엔진도 읽기 좋아집니다.

두 가지만 주의하십시오.

• 이미 발행한 글의 주소가 바뀝니다 — 기존 링크가 끊기므로, 운영 중인 사이트라면 옛 주소를 새 주소로 301 리다이렉트해 두어야 합니다
• 한글 제목은 자동 슬러그가 길어집니다 — 주소에 들어갈 때 한 글자가 여러 바이트로 인코딩되어, 긴 제목은 잘려 404 가 나기도 합니다. 글마다 영문 슬러그를 직접 지정하는 편이 안전합니다

외모 → 메뉴 에서 만듭니다. 페이지 · 글 · 카테고리 · 직접 입력한 링크를 끌어다 놓아 순서를 정하고, 오른쪽으로 밀어 넣으면 하위 메뉴가 됩니다.

만든 뒤에는 “메뉴 설정” 에서 표시 위치를 지정해야 화면에 나옵니다 — 메뉴를 저장했는데 아무 변화가 없다면 대개 이 단계를 빠뜨린 것입니다.

블록 테마(외모에 “편집기” 가 있는 경우)에서는 이 화면 대신 사이트 편집기 안의 내비게이션 블록에서 바꿉니다.

업로드 자체가 실패한다면 서버의 업로드 용량 제한(upload_max_filesize)이나 메모리 부족입니다. 호스팅 설정에서 올리거나, 이미지를 줄여서 올리면 됩니다.

사이트가 무거운 쪽이라면 원인은 대개 원본 크기 그대로 올린 사진입니다. 카메라나 휴대폰 사진은 화면에 필요한 것보다 훨씬 큽니다.

올리기 전에 가로 폭을 실제 표시 크기에 맞춰 줄이고, 가능하면 WebP 로 저장하십시오. 이미 쌓인 이미지가 많다면 성능 작업에서 한 번에 정리하는 편이 빠릅니다 — 성능 최적화 노하우에서 다룹니다.

워드프레스는 기본적으로 서버의 PHP mail() 로 메일을 보내는데, 이 방식은 인증 정보가 없어 스팸으로 분류되거나 아예 차단되는 일이 흔합니다. 코드가 잘못된 것이 아닙니다.

해결은 SMTP 발송으로 바꾸는 것입니다 — 실제 메일 계정(회사 메일, 또는 메일 발송 서비스)의 인증 정보를 넣어 그 계정으로 보내게 하면 도달률이 올라갑니다. SMTP 플러그인을 쓰면 설정 화면에서 끝납니다.

발신 도메인에 SPF · DKIM 을 맞춰 두면 한 단계 더 안정적입니다.

설정 → 일반 → 사이트 언어 에서 고르면 됩니다. 고르는 즉시 번역 파일을 내려받아 적용합니다.

같은 화면에서 시간대도 함께 맞추십시오. 시간대가 어긋나 있으면 예약 발행이 의도한 시각에 나가지 않고, 그 사실이 목록에서는 잘 보이지 않습니다 — 예약한 글이 조용히 사라진 것처럼 보이는 원인이 대개 이것입니다.

사용자마다 다른 언어를 쓰려면 각 사용자의 프로필 화면에서 따로 지정할 수 있습니다.

디자인이 마음에 드는지는 마지막에 보십시오. 먼저 볼 것은 넷입니다.

• 최근에 업데이트되었는가 — 몇 년째 갱신이 없는 테마는 다음 워드프레스 버전에서 깨질 위험이 큽니다
• 무엇을 얹어서 무겁게 만드는가 — 데모와 똑같이 보이려고 슬라이더·아이콘팩·페이지빌더를 함께 요구하는 테마는 그만큼 느려집니다
• 자식 테마를 지원하는가 — 수정 사항을 지키려면 필요합니다
• 한글에서 무너지지 않는가 — 줄바꿈과 자간이 라틴 기준으로 잡혀 있으면 제목이 이상하게 끊깁니다

테마 파일을 직접 고치면 테마를 업데이트하는 순간 그 수정이 전부 사라집니다. 자식 테마는 원본을 그대로 두고 바꿀 부분만 따로 얹는 방식이라, 업데이트가 와도 내 수정이 남습니다.

CSS 한두 줄만 바꿀 것이라면 추가 CSS(외모 → 사용자 정의하기)로도 충분합니다. 자식 테마가 필요해지는 것은 템플릿 파일을 바꾸거나 함수를 추가할 때입니다.

바꿔 말하면 기준은 이것입니다 — 업데이트가 지워도 되는 수정인가? 아니라면 자식 테마입니다.

글과 페이지의 내용 자체는 남습니다 — 데이터베이스에 따로 저장되기 때문입니다. 사라지는 것은 그것을 보여 주던 방식입니다.

실제로 깨지는 것들:

• 메뉴 위치 — 새 테마의 위치에 다시 지정해야 합니다
• 위젯 — 영역 이름이 다르면 자리를 잃습니다
• 테마 전용 숏코드 — 이전 테마가 제공하던 [button] 같은 것은 글 안에 글자 그대로 남습니다
• 커스터마이저 설정 — 색·로고는 테마마다 따로 저장됩니다

운영 중인 사이트라면 복제본에서 먼저 바꿔 보고 확인한 뒤 옮기십시오.

테마의 커스터마이저에 폰트 설정이 있으면 거기서, 없으면 추가 CSS 로 font-family 를 지정합니다.

한글 웹폰트에는 라틴에 없는 두 가지 주의점이 있습니다.

• 용량이 큽니다. 글자 수가 많아 파일이 무겁습니다 — 서브셋으로 나눠 필요한 구간만 받게 하면 첫 화면이 빨라집니다
• 기본 행간이 좁습니다. 대부분의 테마가 라틴 기준(1.5 안팎)이라 받침 때문에 답답해 보입니다. 본문은 1.7 전후가 편합니다

외부 폰트 CDN 대신 서버에 직접 올려 쓰는 편이 속도와 개인정보 양쪽에 낫습니다.

써도 됩니다. 코드 없이 레이아웃을 잡을 수 있다는 이점이 분명합니다.

다만 대가가 있습니다 — 레이아웃이 데이터베이스 안에 들어갑니다. 그러면 그 빌더를 끄는 순간 화면이 무너지고, 다른 사이트로 옮기거나 버전 관리를 하기가 어려워집니다. 프론트에 추가로 실리는 스크립트와 스타일도 속도에 영향을 줍니다.

절충안은 범위를 정해 두는 것입니다. 자주 손대는 본문에는 쓰고, 헤더 · 푸터 · 반복되는 템플릿처럼 사이트의 골격에는 쓰지 않는 식입니다 — 저희도 이 사이트를 그렇게 운영합니다.

가장 흔한 원인은 줄어들지 못하는 요소 하나입니다 — 원본 크기가 큰 이미지, 폭이 고정된 표, 아주 긴 URL 처럼 끊을 수 없는 문자열. 그 하나가 화면 너비를 밀어내면 페이지 전체에 가로 스크롤이 생깁니다.

브라우저 개발자 도구의 반응형 모드로 폭을 줄여 가며 어느 요소가 튀어나오는지부터 찾으십시오. 대개 이미지에 max-width: 100%, 표에 가로 스크롤 컨테이너를 주면 해결됩니다.

⚠ “가로 스크롤이 안 생기니 괜찮다” 로 판단하지 마십시오 — 상위 요소가 넘침을 잘라 내고 있으면 스크롤 없이 내용만 잘려 보입니다.

클래식 테마는 PHP 템플릿 파일로 화면을 그리고, 색이나 로고 같은 설정은 커스터마이저에서 바꿉니다. 오래된 방식이지만 여전히 널리 쓰입니다.

블록 테마는 헤더 · 푸터까지 블록으로 만들어 사이트 편집기에서 전부 편집합니다. 외모 메뉴에 “편집기” 가 있으면 블록 테마입니다.

둘 중 무엇이 낫다기보다 손에 익은 쪽이 낫습니다. 다만 블록 테마는 아직 생태계가 얇아, 필요한 기능의 플러그인이 클래식 전제로 만들어져 있는 경우가 있습니다 — 도입 전에 쓸 플러그인들이 대응하는지 확인하십시오.

운영 사이트에서 직접 고치지 마십시오. 순서는 이렇습니다.

1. 복제본을 만든다 — 파일과 데이터베이스를 그대로 옮긴 별도 환경(스테이징). 검색엔진에 잡히지 않게 막아 둡니다
2. 거기서 바꾸고 확인한다 — 테마 교체 · 메뉴 · 위젯 · 폼 동작까지
3. 주소 목록을 맞춘다 — 없어지는 페이지가 있으면 새 주소로 301 리다이렉트를 미리 정해 둡니다. 이것을 빠뜨리면 리뉴얼 직후 검색 유입이 떨어집니다
4. 옮기고, 옛 주소를 확인한다

이 절차 전체를 어떻게 진행하는지는 작업 과정에 단계별로 적어 두었습니다.

설치 화면에 나오는 정보만으로도 대부분 판단됩니다.

• 마지막 업데이트 — 6개월 이상 갱신이 없으면 일단 보류하십시오
• 활성 설치 수 — 사용자가 많을수록 문제가 빨리 드러나고 빨리 고쳐집니다
• 내 워드프레스 버전과 호환 표기
• 지원 게시판의 미해결 글 — 질문에 답이 달리는가

여기에 하나 더 — “이 기능이 정말 플러그인이어야 하는가?” 코어나 테마가 이미 하는 일을 플러그인으로 덧붙이는 경우가 생각보다 많습니다.

개수 자체에 정답은 없습니다. 가벼운 플러그인 서른 개보다 무거운 하나가 더 나쁠 수 있습니다.

실제로 봐야 할 것은 이것입니다 — 그 플러그인이 모든 페이지에서 무엇을 로드하는가. 문의 페이지에서만 쓰는 폼 플러그인이 전 페이지에 스크립트와 스타일을 얹고 있다면, 그것이 개수보다 큰 문제입니다.

기준을 하나 두자면 “지금 이 플러그인이 무슨 일을 하는지 설명할 수 있는가” 입니다. 설명하지 못하는 플러그인은 켜 둘 이유도 없습니다.

순서대로 하나씩 끄지 말고 반씩 나누십시오. 20개라면 10개를 끄고 확인 — 증상이 사라지면 범인은 끈 쪽에, 남아 있으면 켠 쪽에 있습니다. 이렇게 하면 20개도 다섯 번이면 좁혀집니다.

플러그인을 전부 꺼도 그대로라면 테마 문제입니다 — 기본 테마로 잠깐 바꿔 확인하십시오.

⚠ 운영 사이트에서 하지 마십시오. 플러그인을 끄는 동안 방문자에게 그 기능이 사라진 화면이 그대로 보입니다. 복제본에서 재현한 뒤 거기서 좁히는 것이 원칙이고, 그럴 여유가 없다면 최소한 트래픽이 가장 적은 시간대를 고르십시오.

무엇을 깔지보다 몇 개를 깔지가 먼저입니다 — “올인원 보안” 플러그인을 두 개 이상 켜면 방화벽 계층이 겹쳐 서로의 요청을 막고, 문제가 생겼을 때 원인 추적이 사실상 불가능해집니다. 하나만 쓰십시오.

그리고 플러그인이 대신해 줄 수 없는 것이 있습니다. 밀린 업데이트 · 약한 관리자 비밀번호 · 서버 설정은 플러그인 바깥의 문제라, 그것을 그대로 둔 채 보안 플러그인만 얹으면 안심만 늘고 노출은 그대로입니다.

순서는 업데이트 → 계정 → 서버 설정 → 그다음이 플러그인입니다.

먼저 서버에 이미 캐시가 있는지 확인하십시오. nginx 나 호스팅이 페이지 캐시를 걸어 두고 있는데 플러그인 캐시를 또 얹으면, 두 계층의 무효화 시점이 어긋나 “관리자에게는 바뀐 페이지, 방문자에게는 옛 페이지” 가 나옵니다. 원인 찾기가 가장 성가신 종류의 버그입니다.

서버 캐시가 없는 공유 호스팅이라면 캐시 플러그인이 실질적인 도움이 됩니다. 하나만 쓰고, 설정에서 결제·로그인·폼 제출 경로는 캐시에서 제외하십시오.

저희는 서버 계층에서 처리합니다 — 캐시를 애플리케이션이 아니라 nginx 와 Redis 에 두는 이유는 계층마다 책임을 하나씩만 주기 위해서입니다.

합리적인 걱정입니다. 다만 업데이트를 미루는 쪽이 더 위험합니다 — 밀린 기간만큼 공개된 취약점에 그대로 노출되고, 나중에 한꺼번에 올릴수록 깨질 확률도 커집니다.

무섭지 않게 하는 방법은 순서를 정해 두는 것입니다.

1. 백업 먼저 — 파일과 데이터베이스 둘 다. 돌아갈 자리가 있으면 업데이트는 되돌릴 수 있는 작업이 됩니다
2. 한 번에 하나씩 — 여러 개를 동시에 올리면 무엇이 깨뜨렸는지 알 수 없습니다
3. 올린 뒤 확인 — 첫 화면 · 문의 폼 · 결제 같은 핵심 경로만 빠르게

중요한 사이트라면 복제본에서 먼저 올려 보는 것이 가장 확실합니다.

아닙니다. 지우십시오.

비활성화된 플러그인의 파일은 서버에 그대로 남아 있고, 그 안의 취약한 코드가 직접 호출될 수 있는 경우가 있습니다. 켜져 있지 않다는 것이 접근할 수 없다는 뜻은 아닙니다. 게다가 비활성 플러그인은 업데이트 알림도 잘 눈에 띄지 않아 그대로 낡아 갑니다.

다만 삭제하면 그 플러그인이 만든 데이터가 함께 사라질 수 있으니, 백업을 먼저 하고 지우십시오. 다시 쓸 가능성이 있다면 설정만 내보내 두면 됩니다.

돈을 쓰기 전에 설계를 한 번 뒤집어 보십시오. 유료 기능이 필요해 보이는 상황이 사실은 데이터를 잘못 나눠 담아서인 경우가 많습니다.

흔한 예가 “항목을 여러 개 반복해서 넣고 싶다” 입니다. 유료 기능(반복 필드)을 사는 대신 그 항목 자체를 별도 콘텐츠 종류로 만들면, 정렬·검색·API 가 전부 기본 기능으로 해결되고 관리 화면도 오히려 단순해집니다.

저희도 이 사이트를 그렇게 만들었습니다 — 유료 라이선스를 우회하는 것이 아니라, 제약을 전제로 설계를 다시 잡는 편이 결과가 낫기 때문입니다.

PHP 가 실행 도중 멈췄는데 오류 메시지가 화면에 표시되지 않는 상태입니다. 거의 항상 직전에 바꾼 것이 원인입니다 — 방금 켠 플러그인, 방금 올린 업데이트, 방금 붙여 넣은 코드.

순서대로 하십시오.

1. 오류를 보이게 한다 — wp-config.php 에서 WP_DEBUG 와 WP_DEBUG_LOG 를 켜면 wp-content/debug.log 에 원인이 남습니다. 어느 파일 몇 번째 줄인지까지 나옵니다
2. 범인을 끈다 — 관리자에 못 들어가면 FTP/SSH 로 wp-content/plugins/문제플러그인 폴더 이름을 바꾸면 그 플러그인이 비활성화됩니다
3. 테마도 의심한다 — 플러그인이 아니면 테마 폴더 이름을 바꿔 기본 테마로 떨어뜨립니다

⚠ 고친 뒤 `WP_DEBUG` 를 반드시 끄십시오. 켜 둔 채로 두면 오류 메시지에 서버 경로가 그대로 노출됩니다.

먼저 비밀번호 재설정 메일을 시도하십시오. 메일이 오지 않는다면 사이트의 메일 발송 자체가 안 되는 것일 수 있습니다 — 그 경우는 다른 문제입니다.

메일로 안 되면 서버에서 직접 바꿉니다. 데이터베이스 관리 도구(phpMyAdmin 등)에서 wp_users 테이블의 해당 사용자 user_pass 를 MD5 함수로 새 값으로 넣으면 로그인됩니다(워드프레스가 로그인 시 자동으로 최신 방식으로 다시 저장합니다). WP-CLI 를 쓸 수 있으면 wp user update 한 줄이 더 안전합니다.

비밀번호가 맞는데도 로그인 화면으로 되돌아온다면 쿠키·주소 설정을 보십시오 — 사이트 주소가 www 유무나 http/https 로 어긋나 있으면 이런 증상이 납니다.

둘 다 있어야 복구됩니다.

• 파일 — 특히 wp-content/(테마 · 플러그인 · 업로드 이미지)와 wp-config.php
• 데이터베이스 — 글 · 페이지 · 설정 · 사용자가 전부 여기 있습니다

파일만 있고 DB 가 없으면 빈 사이트가 복구되고, DB 만 있고 이미지가 없으면 글마다 깨진 이미지가 남습니다.

보관은 같은 서버 밖에 두십시오 — 서버가 통째로 문제가 났을 때 그 안의 백업도 함께 못 씁니다. 주기는 콘텐츠가 바뀌는 빈도에 맞추되, 큰 작업 직전에는 언제나 한 벌 받아 둡니다.

한 번 복구해 보는 것 말고는 방법이 없습니다. 받아 둔 백업이 실제로 살아나는지는 사고가 났을 때가 아니라 미리 확인해야 합니다.

방법은 간단합니다 — 임시 서버나 로컬 환경에 백업을 풀어 사이트를 세워 보고, 첫 화면 · 로그인 · 이미지 · 문의 폼이 정상인지 봅니다. 여기서 자주 드러나는 문제가 DB 는 있는데 업로드 이미지가 빠져 있는 경우와, 주소가 옛 도메인으로 박혀 있어 링크가 전부 그쪽으로 가는 경우입니다.

이 리허설을 한 번 해 두면 백업이 “있다” 에서 “쓸 수 있다” 로 바뀝니다.

백업 → 플러그인 · 테마 → 코어 순서를 권합니다.

플러그인을 먼저 올리는 이유는, 새 코어에 대응한 플러그인 버전이 이미 나와 있는 경우가 많기 때문입니다. 코어를 먼저 올리면 낡은 플러그인이 새 코어에서 깨져 원인을 코어 탓으로 오해하기 쉽습니다.

그리고 PHP 버전은 따로 다루십시오. 워드프레스 업데이트와 같은 날에 함께 올리면 무엇이 깨뜨렸는지 알 수 없습니다 — 며칠 간격을 두고 하나씩 옮기는 편이 결국 빠릅니다.

상황에 따라 갈립니다.

보안 패치(마이너 업데이트)는 켜 두십시오. 범위가 좁아 깨질 위험이 낮고, 늦게 적용될수록 노출이 길어집니다.

메이저 업데이트와 플러그인 자동 갱신은 신중하게. 아무도 보지 않는 새벽에 자동으로 올라갔다가 사이트가 깨지면, 그 사실을 아침에야 알게 됩니다.

기준을 하나 두자면 “깨졌을 때 얼마나 빨리 알 수 있는가” 입니다. 모니터링이 있으면 자동으로 두어도 되고, 없다면 손으로 올리고 바로 확인하는 편이 낫습니다. 저희가 검증 없이 굴러오는 업데이트를 막아 두는 이유도 같습니다 — 테스트한 것을 배포한다는 원칙과 충돌하기 때문입니다.

큰 흐름은 넷입니다 — 파일 복사 → DB 복사 → wp-config.php 의 DB 접속 정보 수정 → DNS 를 새 서버로 변경.

여기서 사람들이 가장 많이 걸리는 지점은 주소가 본문 안에 박혀 있다는 것입니다. 도메인이 바뀌면 글 본문과 설정에 남은 옛 주소를 전부 바꿔야 하는데, 단순 치환(SQL 의 REPLACE)을 쓰면 안 됩니다 — 워드프레스는 일부 설정을 직렬화된 문자열로 저장하고 그 안에 길이 값이 들어 있어, 길이가 달라진 문자열로 바꾸면 그 설정이 통째로 깨집니다.

주소 치환은 직렬화를 이해하는 도구로 하십시오(WP-CLI 의 search-replace 가 이 처리를 합니다).

그리고 DNS 를 바꾸기 전에 새 서버에서 사이트가 정상인지 확인하십시오 — 바꾼 뒤에 확인하면 그 사이 방문자가 깨진 화면을 봅니다.

사이트가 수익이나 문의를 만들고 있다면 필요합니다. 스테이징은 “운영 사이트에서 실험하지 않는다” 를 가능하게 하는 장치입니다.

거창할 필요는 없습니다. 같은 서버의 하위 디렉터리에 복제본을 하나 두는 것으로도 대부분의 목적은 달성됩니다. 다만 두 가지만 지키십시오.

• 검색엔진에 잡히지 않게 막습니다 — 색인되면 같은 내용의 사이트가 둘이 되어 검색에서 서로를 갉아먹습니다
• 결제·메일 발송은 실제로 나가지 않게 합니다 — 테스트 주문이 고객에게 메일을 보내는 사고가 흔합니다

순서가 중요합니다. 지우는 것부터 하지 마십시오.

1. 현재 상태를 통째로 보존합니다 — 침해된 파일과 DB 를 그대로 복사해 둡니다. 무엇이 어떻게 들어왔는지는 이 사본에서만 알 수 있고, 지우고 나면 영영 모릅니다
2. 비밀번호를 전부 바꿉니다 — 관리자 계정 · DB · FTP/SSH · 호스팅 계정. 하나만 남겨 두면 다시 들어옵니다
3. 깨끗한 시점의 백업으로 되돌립니다 — 침해 이후 백업은 이미 오염돼 있을 수 있습니다
4. 들어온 경로를 막습니다 — 대개 오래된 플러그인이나 테마입니다. 이것을 하지 않으면 복구 직후 같은 일이 반복됩니다

⚠ 4번을 건너뛴 복구는 복구가 아닙니다 — 재발까지의 시간을 벌 뿐입니다.

댓글을 실제로 쓰고 있는지 먼저 물어보십시오. 쓰지 않는다면 기능 자체를 끄는 것이 가장 확실합니다 — 스팸 필터를 붙이는 것보다 관리 부담도 개인정보(작성자 IP · 이메일) 보관도 줄어듭니다.

⚠ 다만 설정에서 “댓글 허용” 을 끄는 것만으로는 부족합니다. 그것은 폼을 숨길 뿐이고, 스팸 봇은 폼을 보지 않고 댓글 접수 주소로 바로 요청을 보냅니다. 그 엔드포인트까지 함께 막아야 실제로 멈춥니다.

댓글이 필요한 사이트라면 스팸 필터 플러그인 하나 + 최초 댓글 승인제 조합이 무난합니다.

“갑자기” 라면 원인이 좁습니다. 최근에 바뀐 것부터 보십시오.

• 새로 켠 플러그인 · 올린 업데이트 — 시점이 겹치면 거의 확실합니다
• 늘어난 트래픽 — 정상 방문일 수도, 봇의 대량 요청일 수도 있습니다. 접속 로그를 보면 갈립니다
• 서버 자원 — 디스크가 찼거나 메모리가 부족하면 모든 것이 느려집니다
• DB 가 부풀었다 — 리비전·트랜지언트·로그 테이블이 쌓이면 조회가 느려집니다

어디가 느린지 모르겠다면 같은 페이지를 로그인 상태와 비로그인 상태로 비교해 보십시오. 비로그인만 빠르면 캐시가 동작 중이라는 뜻이고, 둘 다 느리면 서버나 DB 쪽입니다.

맡기기 전에 이 셋을 준비하시면 어디에 의뢰하든 진행이 빨라집니다.

• 증상과 시점 — 언제부터, 무엇을 한 뒤에
• 호스팅 정보 — 어떤 종류인지, root 접근이 되는지
• 백업이 있는지 — 없다면 지금 하나 받아 두십시오

버전업 · 성능 · 보안을 한 번에 정리해야 하는 상황이라면 저희 최적화 지원 사업이 그 범위입니다. 작업 과정은 여기에 단계별로 공개해 두었고, 무엇이 포함되지 않는지도 같은 비중으로 적어 두었습니다.

맡기지 않고 직접 하실 거라면 무료 진단 도구로 무엇이 밀려 있는지부터 확인해 보십시오.

체감이 아니라 같은 조건에서 잰 수치로 보십시오. 브라우저 개발자 도구의 Lighthouse 나 PageSpeed Insights 로 시작하면 됩니다.

재는 방법에 규칙이 있습니다.

• 같은 URL · 같은 디바이스 프로파일 · 같은 시간대에서 3회 측정하고 중앙값을 씁니다. 1회 측정치는 흔들립니다
• 캐시를 데운 뒤 잽니다 — 첫 요청은 캐시 미스라 실제 사용자 경험이 아닙니다
• 로그인 상태로 재지 마십시오 — 관리 바와 캐시 우회 때문에 방문자가 겪는 것과 다릅니다

저희가 전/후 리포트를 만들 때 쓰는 규칙도 이것과 같습니다.

대부분의 사이트에서 순서는 이렇습니다.

1. 이미지 — 표시 크기보다 큰 원본을 그대로 올린 경우가 가장 흔하고, 효과도 가장 큽니다
2. 페이지 캐시 — 같은 페이지를 매번 PHP 로 만들지 않게 합니다
3. 안 쓰는 플러그인 정리 — 전 페이지에 스크립트·스타일을 얹는 것들부터
4. PHP 버전 · OPcache — 오래된 PHP 를 쓰고 있으면 올리는 것만으로 차이가 납니다
5. DB 정리 — 리비전·트랜지언트가 쌓이면 조회가 느려집니다

⚠ 순서를 뒤집어 세밀한 튜닝부터 하는 경우가 많은데, 큰 이미지 하나가 나머지 전부보다 무거운 상황이 흔합니다. 재고 나서 고치십시오.

페이지 캐시가 완성된 화면을 저장한다면, 오브젝트 캐시는 그 화면을 만드는 데 쓴 DB 조회 결과를 저장합니다.

둘의 역할이 다릅니다. 페이지 캐시는 비로그인 방문자에게 효과가 크지만 로그인 사용자·관리자·장바구니처럼 사람마다 다른 화면에는 쓸 수 없습니다. 그 영역을 오브젝트 캐시가 맡습니다 — 반복되는 조회가 DB 까지 가지 않게 됩니다.

그래서 회원 사이트나 상점처럼 로그인 사용자가 많은 사이트에서 체감 차이가 큽니다. 반대로 정적인 소개 사이트라면 페이지 캐시만으로도 충분할 수 있습니다.

먼저 버전을 정확히 파악하십시오 — 워드프레스 코어 · 테마 · 각 플러그인의 현재 버전. 알려진 취약점은 “이 소프트웨어의 이 버전 범위” 단위로 공개되므로, 버전을 모르면 판정할 수 없습니다.

그다음 취약점 데이터베이스와 대조합니다. 무료 진단 도구로 이 과정을 자동화할 수 있습니다 — 저희가 만든 사이트 진단 플러그인도 코어 · 플러그인 · 테마를 한 번에 조회합니다.

⚠ 한 가지 주의 — “취약점 없음” 이 “안전함” 은 아닙니다. 공개된 목록에 없을 뿐이고, 약한 비밀번호나 잘못된 파일 권한은 CVE 로 잡히지 않습니다.

있고, 대개 플러그인보다 효과가 확실합니다.

• 파일 편집기 비활성화 — DISALLOW_FILE_EDIT 를 켜면, 관리자 계정이 탈취되어도 테마 편집기로 코드를 심는 최단 경로가 막힙니다
• 업로드 폴더에서 PHP 실행 차단 — 업로드 취약점이 원격 코드 실행으로 번지는 것을 막는 마지막 관문입니다
• XML-RPC 차단 — 쓰지 않는다면 닫으십시오. 무차별 대입 증폭 통로입니다
• 사용자 이름 노출 차단 — 작성자 목록이 열려 있으면 공격자가 아이디부터 알고 시작합니다
• 파일 권한 — 코드는 웹서버에게 읽기 전용, 쓰기는 업로드 폴더만

이 항목들은 공유 호스팅에서는 대부분 손댈 수 없습니다 — 호스팅 종류가 보안 작업의 폭을 정하는 이유입니다.

기술적인 기초부터 확인하십시오. 콘텐츠가 좋아도 읽히지 않으면 순위가 생기지 않습니다.

• 색인이 막혀 있지 않은가 — 설정 → 읽기의 “검색엔진 접근 차단” 이 켜져 있으면 아무것도 안 됩니다. 개발 중에 켜 두고 잊는 경우가 많습니다
• 사이트맵이 제출되어 있는가 — 구글 서치콘솔과 네이버 서치어드바이저 양쪽에
• 주소가 읽을 수 있는 형태인가 — ?p=123 보다 글 이름이 낫습니다
• 제목과 설명이 페이지마다 다른가 — 같은 문구가 반복되면 어느 페이지를 올려야 할지 검색엔진이 판단하지 못합니다
• 모바일에서 정상인가 · 충분히 빠른가

여기까지가 되어 있어야 콘텐츠가 값을 합니다.

순서대로 확인하십시오.

1. 설정 → 읽기 의 검색엔진 접근 차단이 꺼져 있는가
2. robots.txt 가 크롤링을 막고 있지 않은가 — 내주소/robots.txt 로 직접 열어 봅니다
3. 페이지 소스에 noindex 가 있는가 — SEO 플러그인 설정이나 테마가 넣는 경우가 있습니다
4. 서치콘솔에 등록하고 색인을 요청했는가 — 새 사이트는 저절로 발견되기까지 시간이 걸립니다

등록도 되어 있고 색인도 됐는데 순위가 낮은 것이라면 그건 다른 문제입니다 — 그때는 콘텐츠와 내부 링크 구조를 봐야 합니다.

구글과 절차가 다릅니다. 네이버 서치어드바이저에 사이트를 등록하고 소유 확인을 거친 뒤, 사이트맵과 RSS 를 제출하는 방식입니다.

워드프레스 쪽에서 준비할 것은 구글과 크게 다르지 않습니다 — 사이트맵이 정상 생성되고, 각 페이지에 제목과 설명이 있고, 색인이 막혀 있지 않으면 됩니다. 소유 확인용 HTML 태그는 SEO 플러그인의 인증 코드 입력란에 넣으면 됩니다.

다만 국내 검색은 블로그·카페 등 자체 서비스 문서의 비중이 커서, 웹사이트 하나만으로 올라오는 속도가 구글보다 느릴 수 있다는 점은 감안하십시오.

맡기기 전에 무엇을 어떻게 잴 것인지부터 합의하십시오. 그것이 없으면 작업 후에 “좋아졌다” 는 말만 남습니다.

최소한 이 셋은 정해 두는 것이 좋습니다.

• 측정 대상 URL — 어느 페이지를 기준으로 볼 것인가
• 측정 도구와 조건 — 같은 도구 · 같은 디바이스 · 3회 중앙값
• 전/후 원본 산출물 — 점수만이 아니라 리포트 파일 자체

저희 지원 사업은 이 방식으로 리포트를 드리고, 개선되지 않은 항목도 이유와 함께 그대로 적습니다. 선택적으로 보고하면 한 번 들켰을 때 나머지 수치의 신뢰까지 함께 무너지기 때문입니다.

아니요. 작업은 복제 환경에서 먼저 검증한 뒤 실서버에 적용하며, 적용 시점도 트래픽이 가장 적은 시간대로 협의합니다. 다운타임이 필요한 단계(예: PHP 버전 교체)는 사전에 고지하며 통상 수 분 이내입니다.

root(또는 sudo) 접근이 가능한 서버 호스팅 — VPS · 클라우드(AWS, GCP, Vultr 등) · 전용 서버 — 이어야 합니다. cPanel 류 공유 웹호스팅은 Docker · Redis · nginx 설정 권한이 없어 약속드린 결과를 낼 수 없기 때문에 작업하지 않습니다.

같은 URL 을 같은 조건에서 작업 전/후 각 3회 측정한 중앙값으로 리포트를 드립니다. 응답 속도 · DB 쿼리 수 · 평가 도구 점수를 수치로 비교하며, 개선되지 않은 항목도 이유와 함께 그대로 적습니다.

작업 착수 전 전체 백업(파일 + DB)을 만들고 시작합니다. 문제가 생기면 즉시 이전 상태로 복원할 수 있는 상태에서만 작업합니다.

무통장입금 270,000원(VAT 포함) 또는 PayPal $200 USD 로 결제하실 수 있습니다. 무통장입금은 입금 확인 후, PayPal 은 결제 즉시 다음 안내를 드립니다. 작업은 결제 확인 후 시작됩니다.

작업 완료 후 2주간 동일 항목 하자는 무상으로 대응합니다. 또한 Docker 구성 파일을 인계드리기 때문에, 같은 환경을 언제든 재현할 수 있고 다음 유지보수 비용도 낮아집니다.

포함 — 워드프레스 · 테마 · 플러그인 최신 버전 업그레이드, 성능 최적화(Redis 오브젝트 캐시 · nginx FastCGI 캐시 · OPcache), SEO 기술 지원, 보안 취약점 해결(PHP 권한 · nginx 하드닝), PHP 소스코드 리팩터링, Docker 기반 재현 가능한 배포 구성.

불포함 — 콘텐츠 작성과 디자인 리뉴얼, 서버 임대 비용, 유료 테마 · 플러그인 라이선스 비용, 공유 웹호스팅 환경에서의 작업.

범위를 결제 전에 적어 두는 이유는 분쟁을 만들지 않기 위해서입니다. 애매한 항목이 있으면 신청 단계에서 먼저 확인해 드립니다.

아닙니다. 신청서의 체크를 해제하시면 설치하지 않습니다.

기본 포함으로 두는 이유는 어차피 저희가 Docker 스택을 올리는 김에 함께 올라가는 구성이기 때문입니다. 별도 신청 단계를 하나 더 만들면 고객에게 번거로움만 생깁니다.

체험은 한 달 뒤 자동으로 종료되며 자동 결제로 이어지지 않습니다. 계속 쓰고 싶으시면 그때 이용권을 따로 구매하시면 됩니다.