웹사이트 설계 및 운영
PHP의 취약성을 계기로 생각하는 WordPress의 대안
WordPress를 계속할지, 정적 사이트나 관리 첨부 CMS에 옮길까를 비교. Cloudflare의 WAF, 문의 폼, 일반 이용·기업 이용의 요금 예를 도해 첨부로 설명합니다.
WordPress의 취약성에 대한 대응을 경험하면, 「이 앞도 같은 구조로 운영해도 좋은 것인가」라고 신경이 쓰이는 사람도 있다고 생각합니다. 마이그레이션 대상을 찾아도 전문 용어가 많아서 무엇이 바뀌는지 알기 어려울 수 있습니다.
이 기사는 개인 블로그, 취미 사이트, 기업 사이트를 운영하는 사람을 위해 WordPress를 계속하는 방법과 다른 메커니즘으로 바꾸는 방법을 정리합니다. Cloudflare를 이용하는 경우의 안전 대책, 문의 폼, 요금의 기준도 소개합니다.
WordPress를 중지하는 것은 모든 사이트의 정답이 아닙니다. "필요한 기능" "업데이트하는 사람" "보수를 담당하는 사람"을 정리하면 맞는 방법이 보입니다.
본 기사는 공식 자료에 근거한 비교와 설계상의 고찰입니다. 마이그레이션 작업이나 공격 재현, 비용 절감의 실측 결과를 소개하는 것은 아닙니다.
이번 문제는 WordPress의 기초가 되는 PHP에 있다
WordPress는 기사를 게시하고 관리하는 소프트웨어입니다. 그 동작을 지지하는 구조의 하나가, 서버상에서 움직이는 PHP입니다.
2026년 10월에는 PHP에 대해 다음과 같은 심각한 취약점이 발표되었습니다. 취약점은 공격에 악용될 수 있는 소프트웨어와 같은 약점입니다.
- CVE-2026-109618: 메모리 부족으로 처리가 중단되면 불완전한 내부 데이터가 후처리로 처리되는 문제입니다.
- CVE-2026-109619:사용한 메모리를 가리키는 내부 정보가 남아 있고 나중에 오는 요청 처리가 이전 정보를 참조하는 문제입니다.
조건에 따라 외부 타사가 서버에서 임의의 코드를 실행할 수 있습니다. 이것은 WordPress 본체의 버그와는 다른 문제이므로, WordPress나 플러그인의 갱신에 가세해, PHP측의 수정 상황도 확인할 필요가 있습니다.
수정이 처음 제공된 버전은 PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12입니다. 실제 대응은 호스팅 회사나 OS의 제공원의 안내를 확인해 주세요. 버전 번호뿐만 아니라 제공업체의 수정 적용 여부를 확인해야 합니다.
참고: IPA: 이번 PHP 취약점 및 조치/PHP 공식: OOM 처리 문제/PHP 공식: 오래된 내부 상태가 남는 문제
우선 이용 서비스의 대응 상황을 확인하고 필요한 수정을 적용합니다. 침해가 의심되는 경우 조사 및 복구도 필요합니다. 다른 서비스로 옮기는 것만으로 기존 침해가 해소되었다고 판단할 수 없습니다.
대안을 찾기 전에 기사를 작성하는 방법과 필요한 기능을 정리하십시오.
내가 비교의 출발점으로 하고 싶은 것은, 평상시의 갱신 방법입니다. 스마트폰에서 쓰고 싶은지, PC로 파일을 편집할 수 있는지. 코멘트나 회원등록, 판매기능이 필요한가. 그러면 옵션이 바뀝니다.
옵션 1: WordPress를 계속하고 유지보수를 검토합니다.
현재 편집 화면과 기능이 사용하기 쉽다면 계속 선택할 수 있습니다. 플러그인은 기능을 추가하는 부품입니다. 본체·플러그인·테마·PHP의 갱신 담당과, 백업으로부터 되돌리는 순서를 결정합니다.
유지보수 회사나 관리 서비스에 맡기는 경우에도 "플러그인 문제나 복구까지 대응하는지" 등 맡겨지는 범위를 확인합니다.
옵션 2: 관리형 CMS 및 사이트 제작 서비스 사용
CMS는 브라우저 등에서 기사를 작성·관리하는 구조입니다. 관리되는 서비스라면 서버와 같은 서비스를 운영자에게 맡길 수 있습니다. 맡기는 범위는 서비스마다 다릅니다.
편집 화면, 일본어 사용의 용이성, 필요한 기능, 요금 외에도 기사와 이미지를 내보내서 다른 서비스로 옮길 수 있는지 확인합니다. 여기에서는 특정 서비스를 안전의 순위로 늘어놓지 않습니다.
옵션 3: 정적 사이트로 만들기
정적 사이트는 미리 만든 페이지를 전달하는 방식입니다. 문장과 이미지를 중심으로 공개하는 사이트에서는 후보가 됩니다. 한편, 투고 화면은 별도로 준비해야 합니다.
HTML이라고 하는 페이지용 파일을 직접 편집하는 것, 원고로부터 페이지를 생성하는 툴을 사용하는 것, 편집용의 CMS를 조합하는 등의 방법이 있습니다. 업데이트의 용이성을 보완할수록 유지보수하는 구조가 늘어날 수 있습니다.
Cloudflare는 페이지 전송 및 안전 조치 서비스를 제공하지만 페이지 또는 Workers Static Assets을 선택하는 것만으로 WordPress와 같은 게시 화면이 표시되지 않습니다. 「기사를 쓰는 구조」와 「페이지를 나누는 장소」는 따로 생각합니다.
| 중시하고 싶은 것 | 고려할 방향 |
|---|---|
| 스마트 폰이나 브라우저로 부담없이 게시하고 싶습니다. | WordPress 계속 또는 편집 화면의 사용하기 쉬운 CMS |
| 여러 사람이 편집하고 승인하고 싶습니다. | 권한 관리 및 승인 기능이 있는 CMS |
| 문장과 이미지가 중심이며 파일 편집도 가능 | 정적 HTML 또는 페이지 생성 도구 |
| 회원·결제·구입 이력이 필요 | 전용 서비스 및 동적 처리를 포함한 검토 |
Cloudflare의 WAF로 공격을 앞으로 감소
Cloudflare에는 의심스러운 통신을 사이트 앞에서 검사하는 WAF(와프)가 있습니다. 접수의 경비에 가까운 역할로, 알려진 공격과 유사한 통신을 차단하거나, 액세스원이나 송신 횟수로 제한할 수 있습니다.
Free에는 일부 위협에 해당하는 규칙이 있으며 Pro 이상에서는 더 넓은 관리형 규칙을 사용할 수 있습니다. 관리형 규칙은 Cloudflare가 준비하고 업데이트하는 결정 규칙입니다. DDoS 대책은 대량의 통신으로 사이트를 사용할 수 없게 하는 공격에 대한 대책입니다.
이번 PHP 취약성에 대한 보호 규칙도 공개되어 있습니다. 다만 설정에 의한 적용 조건이 있어, 알려진 공격에 대한 대책입니다. Cloudflare를 사용하면 PHP 업데이트가 필요하지 않다고 판단할 수 없습니다.
참고: WAF 기능 비교/이 PHP 취약점에 대한 WAF 대책 및 조건
원래 서버가 별도로 있는 경우에는 해당 서버에 직접 액세스하여 WAF를 우회할 수 없도록 하는 대책도 필요합니다. 정적 사이트에서도 공개 계정 탈취, 외부 서비스 문제, 양식에 스팸 제출 등은 별도로 생각합니다.
문의만 Cloudflare로 처리
"정적 사이트에서는 문의할 수 없다"는 것은 아닙니다. 페이지는 정적 상태로 유지되며 쿼리를 수락하는 부분에만 처리를 추가할 수 있습니다.
Workers는 Cloudflare에서 양식 접수와 같은 작은 프로그램을 실행하는 서비스입니다. Turnstile은 봇의 전송을 줄이기 위한 메커니즘으로, Email Service는 알림 이메일을 보내는 등의 책임을 집니다.
확인된 관리자 주소로 알림만 받으면 이메일 전송은 무료입니다. 문의자에게 자동 회신하려면 모든 대상으로 보낼 수 있는 E-mail Sending 및 Workers Paid를 사용합니다. Email Sending은 정보 확인 시 베타 제공입니다.
Email Routing은 자체 도메인으로 향하는 메일을 기존 받은 편지함으로 전달하는 서비스입니다. 이메일을 읽을 수 있는 받은 편지함 자체를 제공하지는 않습니다. 또한 양식에서 관리자에게 알리는 것과 자체 도메인으로 보내는 메일을 전달하는 것은 또 다른 기능입니다.
문의를 잃지 않기 위해서는 송신 실패시의 안내, 재전송의 취급, 수신 확인 등도 설계합니다. 기밀 정보를 폼으로 너무 요구하지 않는 것, 보존처·열람할 수 있는 사람·보관 기간을 결정하는 것도 중요합니다. 기존 메일 서비스가 있는 경우 수신인을 결정하는 DNS 설정을 부주의하게 변경하지 않도록 합니다.
Turnstile에는 브라우저의 JavaScript가 필요합니다. 사용 중지 또는 전송에 실패한 경우에도 연락할 수 있도록 다른 연락 방법을 안내합니다. 사이트 본문이나 목차는 폼과 분리하여 일반 HTML로 읽을 수 있는 구성으로 할 수 있습니다.
일반 이용·기업 이용의 요금은 어느 정도?
다음은 1 도메인의 정적 사이트와 소규모 문의 양식을 가정한 구성 예입니다. CMS의 투고 화면, 회원·결제 기능, 첨부 파일 보존, 감시·재송용의 추가 서비스는 포함하지 않습니다. WordPress를 남겨두는 경우에는 그 서버 요금 등도 별도로 필요합니다.
금액은 2026년 10월 25일 현재 미국 달러입니다. 세금, 환율, 독자 도메인의 취득·갱신, 수신함, 제작·보수의 인건비는 포함하고 있지 않습니다. 「월액 최저 요금＋포함되는 이용량을 넘은 분」이라고 생각해 주세요.
일반 이용 : 관리자에게 통지 만이라면 무료 프레임으로 시작
개인 블로그나 취미 사이트 등에서 문의를 자신의 수신함에서 확인할 수 있으면 좋은 경우입니다. 자동 회신은 수행하지 않고 화면에 전송 결과를 표시합니다.
| 용도 | 사용하는 것 | 월액 기준 |
|---|---|---|
| 페이지 전달 | Pages／Workers Static Assets | $0 |
| 입구 안전 대책 | 웹사이트 Free 플랜 | $0 |
| 봇 대책 | Turnstile Free | $0 |
| 문의 접수 | Workers Free | $0(무료 프레임 내) |
| 관리자에게 알림 | 확인된 대상으로 보내기 | $0 |
| 총 기준 | $0(무료 프레임·제한 내) | |
무료 프레임으로 충분할지는 액세스 수뿐만 아니라 처리 시간이나 구현에 따라 다릅니다. 관리자에게 알림 메일이 무료이더라도 접수 프로그램의 실행 제한은 별도입니다.
기업 이용: 자동 회신 및 유료 WAF 추가
문의자에게 접수 메일을 돌려주고, 보다 넓은 WAF 룰을 이용하는 예입니다. 기업이기 때문에 반드시 이 플랜이 필요하다는 의미는 아닙니다. 사이트의 역할과 정지 시의 영향에 따라 선택합니다.
| 용도 | 사용하는 것 | 월부금 기준 |
|---|---|---|
| 페이지 전달 | Pages／Workers Static Assets | $0 |
| 유료 WAF 등 | 웹사이트 Pro 플랜 | $25 |
| 봇 대책 | Turnstile Free | $0 |
| 접수・자동 회신 | Workers Paid＋Email Sending | 최소 $5 |
| 관리자에게 알림 | 확인된 대상으로 보내기 | $0 |
| 총 기준 | 최저 $30/월 + 초과이용분 | |
Workers Paid에서는 최소 $5/월의 기본 요금에 월 3,000통의 E-mail Sending 발송 프레임이 포함됩니다. 초과분은 1,000통당 $0.35입니다. 확인된 관리자에게 보내는 전송은 이 창에 포함되지 않습니다. 재전송이나 다른 용도도 송신 프레임을 사용하기 때문에, 3,000건의 문의를 확실히 받아들여지는 보증과는 다릅니다.
연간 지불과 Business를 포함한 비교
| 구성 예 | 월별 지불 요금 | 웹사이트 플랜을 연간 지불한 월간 환산 |
|---|---|---|
| 일반 이용：Free＋Workers Free | $0(무료 프레임 내) | $0(무료 프레임 내) |
| 자동 회신 추가: Free+Workers Paid | 최소 $5 | 최소 $5 |
| 기업 이용 예: Pro+Workers Paid | 최소 $30 | 최소 $25 상당 |
| 요구사항이 엄격한 경우: Business+Workers Paid | 최소 $255 | 최소 $205 상당 |
Pro의 연금은 $240/년이고 Business의 연금은 $2,400/년입니다. 이에 Workers의 최소 $5/월과 초과이용분이 별도 발생합니다. 표의 월간 환산액을 그대로 매월 지불하는 계약이 아닙니다.
비즈니스에는 웹사이트 계획의 SLA(가용성 계약 계약)가 있지만 양식 처리 및 이메일 도착을 포함한 전체 구조에 대한 보증은 아닙니다. 지속적인 운영이 중요하다면 장애 감지, 실패 시 복구 및 베타 기능 처리를 포함하여 평가합니다.
Workers Paid는 프로그램 실행과 같은 계획입니다. Pro/Business는 웹사이트의 WAF 등의 플랜입니다. Workers Paid를 계약해도 유료 WAF가 자동으로 붙는 것은 아닙니다.
정적 파일에 대한 요청은 무료, 횟수 무제한으로 안내되지만 파일 수, 용량 등의 제한은 있습니다. WAF는 대상의 독자 도메인 등 적용 경로에의 설정이 전제로, 다른 공개 URL로부터의 액세스에도 주의가 필요합니다.
이전하기 전에 요금보다 먼저 "곤란하지 않습니까?"를 확인하십시오.
마이그레이션 후에 매번 업데이트가 부담이 되어 버리면 사이트를 계속하기 어려워집니다. 먼저 소수의 기사에서 게시물부터 공개까지를 시도하는 것이 좋다고 생각합니다.
- 업데이트: 평소 담당자가 기사를 쓰고 이미지를 넣고 게시할 수 있습니까?
- 기존 페이지: 이전 URL을 유지할 수 있습니까? 변경한다면 구 URL로부터 안내·전송할 수 있을까.
- 부속 기능: 댓글, 검색, 카테고리, RSS, 양식 등을 어떻게 인계받을 수 있습니까?
- 복구: 잘못된 내용을 게시할 때 이전 상태로 되돌릴 수 있습니까?
- 내보내기: 기사와 이미지를 백업하고 나중에 다른 곳으로 옮길 수 있습니까?
- 관리: 계정을 여러 사람이 관리할 수 있습니까? 다중 요소 인증을 설정할 수 있습니까?
워드프레스를 계속하고 유지보수 체제를 정돈하는 방법도 있습니다. 관리형 서비스에 맡기는 방법도, 공개측을 정적으로 하는 방법도 있습니다. 필요한 기능과 갱신·보수를 계속할 수 있는 범위를 확인해, 자신의 사이트에 맞는 구성을 선택하고 싶습니다.
도판은 본 기사용으로 작성한 설명도입니다. 요금・제공 조건은 변경될 수 있습니다.