Drupal 보안은 오픈소스 CMS 세계에서 공개된 절차가 플랫폼의 평판보다 나은 몇 안 되는 영역입니다. Drupal 보안팀은 정해진 공개 일정에 따라 움직이고, 모든 권고문에 문서화된 수치 척도로 점수를 매기며, 코어와 수만 개의 컨트리뷰트 프로젝트에 걸쳐 수정을 조율합니다.

현장의 기록은 그 절차가 받아 마땅한 평가보다 나쁩니다. Drupal 사이트는 실제로 침해당하고, 그 원인이 아무도 몰랐다는 것인 경우는 거의 없습니다. 권고문은 제때, 어느 수요일에 공개되어 있었습니다. 패치는 그다음 주에야 운영 환경에 도착했습니다. 이 글이 다루는 것은 바로 그 간격이며, 보안 강화도 방화벽도 파일 권한도 그 간격을 견딜 만한 것으로 만들거나 짧게 줄이기 위해 존재합니다.

위험을 정하는 것은 어떤 모듈을 쓰고 있느냐가 아니라 얼마나 빨리 패치하느냐입니다. 코어 권고문은 매달 한 번의 수요일 구간에, 컨트리뷰트 프로젝트 권고문은 매주 수요일에 공개되며, 둘 다 공개된 척도로 0에서 25점까지 점수가 매겨집니다. 매우 심각한 코어 결함은 공개 후 몇 시간 안에 악용된 전례가 있습니다. 2014년 SQL 인젝션 권고문 이후 공식 지침은, 일곱 시간 안에 패치하지 못한 사이트는 이미 침해된 것으로 간주하라는 것이었습니다. 코어 패치를 하루 업무일 안에 배포하지 못하는 사이트는 존재하는 위험의 거의 전부를 떠안고 있습니다.

Drupal 보안 권고 절차는 실제로 어떻게 굴러가는가

Drupal 사이트를 운영하는 사람 대부분은 이 절차 문서를 읽어 본 적이 없습니다. 아까운 일입니다. 얼마만큼의 예고를, 어떤 형태로, 어느 요일에 받게 되는지가 거기에 그대로 적혀 있기 때문입니다.

릴리스 구간

보안팀은 달력에 맞춰 공개합니다. 컨트리뷰트 프로젝트 권고문은 매주 수요일에 나갑니다. 코어는 매달 첫째 수요일에 버그 수정과 기능 릴리스 구간을, 셋째 수요일에 보안 릴리스 구간을 둡니다. 보안 릴리스 시점에 관한 문서에 그렇게 정해져 있습니다. 구간이 있다는 것은 무언가가 나온다는 약속이 아닙니다. 관리자가 어느 날을 지켜봐야 하는지 알도록 존재할 뿐입니다.

가끔은 사전 예고가 나옵니다. 매우 심각한 코어 릴리스를 앞두고 보안팀은 공개 예고를 내보내는데, 보통 월요일입니다. PSA-2026-05-18이 2026년 5월 20일 릴리스를 두고 그렇게 했고, 17:00에서 21:00 UTC라는 구간을 알리면서 먼저 자기 브랜치의 최신 패치 릴리스로 올려 두라고 사이트 소유자들에게 일렀습니다. 업그레이드 문제를 미리 드러내기 위해서였습니다. 이틀이 받을 수 있는 최대한의 예고입니다.

코어 권고문과 컨트리뷰트 프로젝트 권고문

이 둘은 보장 수준이 다른 별개의 체계입니다. 코어 권고문은 지원되는 마이너 브랜치를 한 번에 두 개, 최신 것과 그 앞의 것을 대상으로 삼습니다. 실제로는 코어 릴리스 일정에 따라 11.4.x와 11.3.x가 해당하고, Drupal 10이 2026년 12월 9일에 수명을 다할 때까지는 10.6.x도 범위에 남습니다. 2026년 9월 초 기준으로 현재 릴리스는 11.4.5, 11.3.16, 10.6.15입니다. Drupal 12.0.0과 11.5.0은 2026년 12월 7일이 있는 주에 예정되어 있고, 그 시점에 11.3.x와 10.6.x에 대한 지원은 끝납니다.

컨트리뷰트 쪽 범위는 선택 가입이며 조건이 붙습니다. 권고문은 보안 권고 절차 및 권한 정책에 따라 관리자가 신청해 승인을 받은 프로젝트의, 지원되는 메이저 브랜치의 안정 릴리스에 대해서만 발행됩니다. 알파, 베타, 릴리스 후보 버전에 머무는 모듈은 이 체계 밖에 있고, 관리자가 한 번도 신청하지 않은 모듈도 마찬가지입니다. 사이트가 평소처럼 돌아가는 동안 두 사실 모두 관리 화면에서는 보이지 않습니다.

진짜 부담은 건수입니다. 2026년 8월 26일 수요일 하루에만 보안팀은 컨트리뷰트 프로젝트 권고문 열 건을 공개했고, 모두 보통 심각 등급이었습니다. 예순 개의 모듈을 돌리는 사이트라면 한 해에도 여러 번 이름이 오르내리게 되고, 그 꾸준한 흐름이 시간이 갈수록 코어의 비상사태보다 더 큰 비용이 됩니다.

위험 점수, 그리고 그것이 CVSS가 아닌 이유

모든 권고문에는 25점 만점의 숫자가 붙습니다. 이 척도는 NIST의 공통 오용 점수 체계, 곧 NISTIR 7864에 기반하며 보안 위험 등급 설명 페이지에 문서화되어 있습니다. 여섯 가지 지표가 입력이 됩니다. 공격 난이도, 필요한 인증, 기밀성 영향, 무결성 영향, 알려진 익스플로잇의 존재 여부, 그리고 대상 분포입니다. 구간은 심각하지 않음 0에서 4, 덜 심각 5에서 9, 보통 심각 10에서 14, 심각 15에서 19, 매우 심각 20에서 25로 나뉩니다.

대상 분포가 점수에 들어가기 때문에, 흔치 않은 구성에서만 물리는 결함은 CVSS에서 받았을 값보다 낮게 나옵니다. 2026년 6월 17일의 SA-CORE-2026-005, CVE-2026-55803으로 추적되는 PHP 객체 인젝션 문제는 18점을 받았고, 바로 그 이유로 매우 심각이 아니라 심각으로 분류되었습니다.

컨트리뷰트 모듈이 지원 중단으로 표시될 때

보안팀은 자원봉사 관리자에게 무언가를 고치라고 강제할 수 없습니다. 관리자가 응답을 멈추면 문서화된 절차에 따라, 반복된 연락 시도 끝에 프로젝트를 지원 중단으로 표시합니다. 그때부터 프로젝트 페이지는 사이트 소유자에게 활발히 관리되는 대안을 고르거나, 누군가에게 비용을 지불해 결함을 고치게 하고 모듈을 다시 배포할 수 있게 하라고 경고합니다.

그 조언은 옳고 또 비쌉니다. 어떤 모듈이 지원 중단으로 표시될 무렵이면 그것은 대개 하중을 받는 부재가 되어 있고, 교체한다는 것은 데이터 이관, 템플릿 수정, 그리고 한 차례의 회귀 테스트 전부를 뜻하기 때문입니다. 값싸게 움직일 수 있는 순간은 방치되기 직전의 릴리스, 곧 관리자가 조용해졌지만 아직 아무것도 망가지지 않은 시점이고, 그때 들여다보는 사람은 거의 없습니다.

Drupal 7은 수명이 끝났고, 연장 지원은 안전과 같은 말이 아니다

Drupal 7은 2025년 1월 5일에 수명을 다했습니다. PSA-2025-01-06에서 확인된 사실입니다. 그날 이후 보안팀은 Drupal 7 코어와 그 컨트리뷰트 모듈 및 테마에 대한 지원과 권고문 제공을 멈췄습니다. 공지는 이제 Drupal 7의 보안 문제가 조율 없이 공개될 수 있으며 제로데이가 발생할 수 있다고 분명히 밝혔습니다.

상업적인 연장 지원 시장은 있습니다. Drupal 협회는 연장 보안 지원 제공자 프로그램 아래 HeroDevs와 Tag1 Consulting을 포함한 업체를 인증했고, 이들은 실제로 패치를 만들어 냅니다. 아무것도 없는 것보다는 낫지만, 지원을 받는 것과 같지는 않습니다. 업체는 자기가 다루기로 정한 코어와 일정 범위의 모듈을, 자기 일정에 맞춰, 돈을 내는 고객을 위해 고칩니다. 여러분의 사이트가 기대고 있는 나머지 생태계는 범위 밖입니다.

지원이 끊긴 CMS는 협력사 보안 점검 설문에서도, 사고 이후 보험사 앞에서도 변호하기 어렵습니다. Drupal 이전 비용과 선택지, 기한을 다룬 안내에 빠져나가는 데 드는 비용을 정리해 두었습니다.

역사가 남긴 형태: Drupalgeddon과 그 뒤

세 건의 사건이 패치 속도에 대한 커뮤니티의 사고방식을 만들었습니다. 모두 코어의 인젝션 또는 원격 코드 실행 결함이었고, 모두 몇 시간에서 며칠 안에 대규모 자동화 악용을 불렀습니다.

2014년 10월의 일곱 시간

최초의 Drupalgeddon은 SA-CORE-2014-005로 2014년 10월 15일에 공개되었습니다. CVE-2014-3704는 Drupal 7의 데이터베이스 추상화 계층에 있던 SQL 인젝션 결함으로, 익명 사용자도 악용할 수 있었고 25점 만점에 25점을 받았습니다. 7.32 미만의 모든 Drupal 7 사이트가 영향을 받았습니다.

이것을 이정표로 만든 것은 후속 공지였습니다. PSA-2014-003은 발표 몇 시간 만에 자동화된 공격이 패치되지 않은 사이트를 침해하기 시작했으며, 공개 일곱 시간 뒤인 그날 23:00 UTC까지 패치하지 않은 사이트는 침해된 것으로 간주해야 한다고 소유자들에게 알렸습니다. 침해되었을 수도 있다가 아닙니다. 침해되었다입니다. 공격자가 모든 데이터를 가져가고 백도어를 심었을 수 있다고도 경고했는데, 바로 그 지점이 패치 문제를 사고 대응 문제로 바꿉니다.

Drupalgeddon 2와 3

2018년 3월 28일에 공개된 SA-CORE-2018-002는 CVE-2018-7600으로, Drupal 7과 Drupal 8의 여러 하위 시스템에 걸친 원격 코드 실행 결함이었고 25점 중 24점을 받았습니다. Drupal 7.0에서 7.57까지, 그리고 8.5.0까지의 8.x 브랜치가 영향을 받았으며 공개 익스플로잇은 약 2주 만에 뒤따랐습니다.

4주 뒤인 2018년 4월 25일에는 SA-CORE-2018-004가 나왔습니다. CVE-2018-7602는 관련 코드에 있던 또 하나의 원격 코드 실행 문제로 25점 중 20점을 받았고, 권고문은 이미 실제로 악용되고 있다고 적었습니다. 교훈은 그 간격에 있습니다. 3월에 패치하고 나서 주의를 거둔 사이트는 4월에 다시 노출되었습니다.

2026년 5월, 그리고 달라지지 않은 것

이 형태는 지나간 이야기가 아닙니다. SA-CORE-2026-004는 2026년 5월 20일에 공개되었습니다. CVE-2026-9082는 PostgreSQL을 쓰는 사이트에 영향을 주는 SQL 인젝션 결함으로, 25점 중 23점의 매우 심각 등급을 받았고 8.9부터 11.3.9까지 모든 브랜치를 포함했습니다. 5월 22일 04:30 UTC에 권고문은 실제 환경에서 탐지된 악용 시도를 기록하도록 개정되었습니다. 공개에서 관측된 공격까지 48시간이 채 되지 않았습니다.

이 가운데 어느 것도 보안팀을 비판하는 말이 아닙니다. 이틀의 예고를 주었고, 알린 구간 안에 내보냈으며, 상황이 바뀌자 권고문을 갱신했습니다. 무너지는 쪽은 운영자입니다. 권고문에서 패치된 운영 환경까지 연습된 경로가 없습니다.

Drupal 보안이 실제로 무너지는 지점

머리기사를 가져가는 것은 코어지만 그것이 가장 작은 부분입니다. 우리가 감사하는 사이트에서 문제가 되는 발견은 패치되지 않은 코어 릴리스인 경우가 드뭅니다. 코어 업데이트는 관리 화면에 나타나고 누군가는 알아채기 때문입니다. 노출은 다른 곳에 있습니다.

아무도 갖고 있지 않은 모듈 목록

전형적인 중간 규모 Drupal 사이트는 마흔에서 여든 개의 컨트리뷰트 모듈을 돌리고, 각각 다른 관리자와 다른 주기를 갖습니다. 그 자리에서 아무도 답하지 못하는 질문은 그중 어느 것에 아직 활동하는 관리자가 있는지, 어느 것이 권고 정책의 대상인지, 그리고 어느 것이 2년째 커밋 하나 없는지입니다. 그 목록을 만드는 데는 오후 한나절이 듭니다.

아무도 주인이 아닌 커스텀 모듈

가장 흔한 심각한 발견은 이미 떠난 외주 개발자가 작성한 커스텀 모듈입니다. 대개 연동에 가까운 일을 합니다. CRM 전송, 맞춤 폼 처리기, 결제 콜백 같은 것들입니다. 더 오래된 API에 맞춰 쓰였고, 테스트가 없으며, 그것이 무엇을 검증하는지 팀의 누구도 말하지 못합니다. 커스텀 코드는 정의상 권고 체계 밖에 있습니다. 거기에 SQL 인젝션이 있다고 알려 주는 수요일 메일은 오지 않고, 상태 보고서는 모든 것을 최신으로 표시합니다. 다른 소프트웨어 개발 작업과 똑같은 리뷰 규율이 필요합니다.

Drupal 아래의 스택

Drupal은 PHP이고, PHP 버전은 저마다의 일정으로 수명을 다합니다. 어떤 사이트는 CMS 층위에서는 완전히 패치되어 있으면서도 1년 전에 보안 수정이 끊긴 PHP 버전 위에서 돌아갈 수 있습니다. 호스팅이 유지보수 대화에 한 번도 들어오지 않았기 때문입니다. 파일 권한과 소유권에 관한 지침은 웹 서버가 자기가 실행하는 파일을 쓸 수 있어서는 안 된다는 원칙에 서 있지만, 배포 스크립트가 간단해진다는 이유로 쓰기 가능한 코드 디렉터리를 그대로 두고 돌아가는 사이트가 적지 않습니다.

Drupal 사이트는 원래 어떻게 패치되어야 하는가

답은 지루하고, 그래서 실행되지 않은 채 남습니다. 권고문에서 운영 환경까지 연습된 경로를 없애 주는 도구는 없으며, 그 경로를 한 번 만들어 두는 비용은 첫 번째 비상사태보다 쌉니다.

Composer 작업 흐름

Drupal 8 이후는 전부 Composer 프로젝트입니다. 코어 패키지를 의존성과 함께 갱신한 다음, 데이터베이스 업데이트를 적용하고 캐시를 다시 만듭니다.

1composer update "drupal/core-*" --with-all-dependencies
2drush updatedb
3drush cache:rebuild

Drush 대신 update.php를 써도 됩니다. 앞뒤로 상태 보고서를 확인하십시오. 중요한 것은 명령 자체가 아니라, 그것들이 운영 환경이 아닌 어딘가에서 먼저 돌아간다는 사실입니다.

진짜 복제본인 스테이징

스테이징 환경은 그것이 운영 환경을 비출 때에만 도움이 됩니다. 같은 모듈 구성, 같은 PHP 버전, 최근에 익명화한 데이터베이스여야 합니다. 낡은 스테이징 사이트는 아무 뜻도 없는 초록불을 내놓고, 그것은 스테이징이 아예 없는 것보다 나쁩니다. 자신감을 만들어 내기 때문입니다.

순서는 운영 환경을 스테이징으로 내려받고, 업데이트를 적용하고, 데이터베이스 업데이트를 실행하고, 사이트를 상업적으로 쓸모 있게 만드는 페이지와 폼을 한 번씩 밟아 본 다음 배포하는 것입니다. 제대로 된 파이프라인이 있으면 45분에서 90분입니다. 없으면 하루 반입니다.

자동화, 그리고 그 한계

의존성 자동 업데이트가 가장 도움이 되는 곳은 건수가 많고 심각도가 낮은 쪽, 곧 컨트리뷰트 모듈의 흐름입니다. 모듈 업데이트마다 풀 리퀘스트를 하나씩 열고 각각에 대해 테스트를 돌리는 봇은, 매달의 수작업 청소를 검토 대기열로 바꿔 놓습니다. 코어도 같은 방향으로 가고 있습니다. 자동 업데이트 작업은 Package Manager 모듈 위에 세워져 있고, 이 모듈은 코어에 포함되지만 아직 실험 단계입니다.

현실적인 시간 예산

관리되는 Drupal 사이트는 일상적인 모듈 업데이트에 한 달에 대략 반나절, 여기에 해당되는 코어 보안 릴리스마다 한 시간에서 세 시간이 듭니다. 한 해에 한두 번, 그날 저녁 안에 처리해야 하는 매우 심각한 릴리스를 위한 여유도 더하십시오. 사내 팀 대부분이 예산에 넣은 적 없는 숫자가 이것이고, 그래서 이 작업이 밀립니다.

패치 너머의 보안 강화

보안 강화는 패치를 대신하지 않습니다. 공개된 취약점 가운데 여러분의 설치 환경에서 실제로 악용 가능한 것의 수를 줄이고, 패치를 곧바로 내보낼 수 없을 때 시간을 벌어 줍니다. Drupal에 고유한 항목들은 값싸고 한 번 해 두면 남습니다.

신뢰 호스트와 파일 시스템

신뢰 호스트 패턴을 설정하십시오. Drupal은 Symfony의 신뢰 호스트 장치를 쓰고, settings.php의 trusted_host_patterns 설정에 사이트가 응답하는 도메인과 일치하는 정규식으로 적습니다. 다른 Host 헤더를 단 요청은 400으로 거부됩니다. 이것이 없으면 공격자는 위조한 헤더로 비밀번호 재설정 링크와 캐시된 절대 URL을 오염시킬 수 있습니다.

공개적으로 읽히면 안 되는 것에는 비공개 파일 시스템을 쓰고, 공개 파일 디렉터리 안에서 PHP가 실행되지 못하게 하십시오. Drupal은 Apache에서 실행을 막는 .htaccess 파일을 함께 배포하지만, nginx에는 그에 해당하는 넣기만 하면 되는 파일이 없어서 규칙을 서버 설정에 직접 써야 합니다. 몇 해 전 Apache에서 nginx로 옮긴 사이트는 이 보호를 소리 없이 잃은 경우가 잦습니다.

그다음 소유권 모델을 적용합니다. 디렉터리는 750, 코드 파일은 640, 파일 디렉터리는 웹 서버만 쓸 수 있게, settings.php는 소유자만 읽을 수 있게 둡니다.

권한, 관리 경로, 그리고 한 차례의 점검

관리 경로를 제한하십시오. 편집자가 사무실 세 곳에서 일하는 사이트라면 로그인과 관리 경로가 인터넷 전체에서 닿을 이유가 없고, IP 허용 목록이나 인증을 거치는 프록시 하나면 자격 증명을 노리는 공격의 한 부류를 통째로 걷어냅니다.

그다음 권한 표를 감사합니다. 모듈을 하나 설치할 때마다 표는 자라고, 발견되는 것은 거의 언제나 같은 모양입니다. 텍스트 필터를 관리할 수 있는 편집자 역할, 또는 임의의 PHP를 실행할 수 있는 역할입니다. 둘 다 훔친 편집자 비밀번호를 원격 코드 실행으로 바꿔 놓고, 그러면 피싱 메일 한 통이 서버 침해가 됩니다.

무엇을 두고 논쟁하기 전에 먼저 Security Review 모듈을 돌리십시오. 손으로 하면 성가신 점검들을 자동으로 해 줍니다. 파일 시스템 권한, 안전하지 않은 텍스트 형식, 콘텐츠 안의 PHP나 JavaScript, 오류 표시 노출, 업로드 확장자, 실패한 로그인, 위험한 권한, 그리고 신뢰 호스트 설정입니다. 2026년 1월에 나온 3.1.3 버전은 Drupal 11과 함께 Drupal 10.3 이상을 지원합니다.

방화벽이 사 주는 것과 사 주지 못하는 것

웹 애플리케이션 방화벽은 가상 패치이며, Drupal 협회가 보안팀과 함께 운영하는 유료 서비스 Drupal Steward를 바로 그렇게 자리매김하고 있습니다. 특정한 매우 심각한 코어 취약점에 네트워크 층위의 완화를 적용해, 권고문과 배포 사이의 간격 동안 사이트를 보호합니다. 공개된 가격은 한 달에 100만 건의 HTTP 요청을 처리하는 사이트가 20 미국 달러 미만, 1000만 건을 넘으면 100 미국 달러 미만입니다.

한계는 프로젝트가 스스로 밝히고 있습니다. 모든 문제를 이 방식으로 완화할 수는 없고, 이 장치는 웹 서버에 대한 요청을 통해 악용되는 취약점만 다룹니다. 방화벽은 탈취된 관리자 비밀번호에도, 악성 모듈 업데이트에도, 여러분 자신의 코드에 있는 결함에도 아무 일도 하지 못합니다. 패치 구간을 넓히는 이유가 아니라 그 구간에 대한 보험으로 다루십시오. WordPress 보안 강화 체크리스트에서도 같은 관점을 취하고 있습니다.

침해의 비용과 복구의 실제

Drupal 침해로부터의 복구는 패치가 아닙니다. 공격자가 코드 실행에 도달한 순간, 작업상의 전제는 파일이 쓰였고 자격 증명이 빠져나갔으며 지속성 장치가 설치되었다는 것입니다. 2014년에 보안팀이 Drupal 7 소유자들에게 한 말이 바로 그것이었습니다. 침해된 사이트를 제자리에서 청소하는 일은 복구의 옷을 입은 추측입니다.

방어할 수 있는 접근은 버전 관리에서 새 호스트 위에 코드베이스를 다시 세우고, 검사를 거친 뒤에 콘텐츠와 업로드된 파일만 복원하고, 사이트가 지니고 있던 모든 자격 증명을 교체하고, 침해된 디스크 이미지를 지우는 대신 보존하는 것입니다. 마지막 단계는 압박 속에서 사람들이 건너뛰는 것이고, 무슨 일이 있었는지에 대한 유일한 증거입니다.

상업적인 비용이 재구축인 경우는 드뭅니다. 다운타임, 포렌식 작업, 고객 커뮤니케이션, 그리고 규제 절차입니다. 사고 상황에서의 재구축은 보통 5,000에서 20,000파운드의 엔지니어링이고, 대개 전체에서 가장 작은 항목입니다.

영국의 데이터 보호 의무

개인 데이터가 열람되었거나 열람되었을 수 있다면, UK GDPR의 시계는 조사를 마쳤을 때가 아니라 인지한 때부터 돌기 시작합니다. ICO의 침해 지침은 신고 대상 침해를 부당한 지체 없이, 인지 후 72시간을 넘기지 않고 신고하도록 요구하며, 그보다 오래 걸렸다면 사유를 제시해야 합니다. 침해가 개인의 권리와 자유에 높은 위험을 초래할 가능성이 큰 경우에는 해당 개인에게도 부당한 지체 없이 알려야 합니다.

ICO는 그림이 불완전하다는 것이 기한을 놓칠 이유가 되지 않는다고 분명히 말합니다. 아는 것을 신고하고 뒤에 보완하라는 것입니다. 요구될 때 신고하지 않으면 최대 870만 파운드 또는 전 세계 매출의 2퍼센트에 이르는 과징금이 부과될 수 있습니다.

그 시계 때문에 포렌식 질문이 중요해집니다. 로그가 없고 어떤 버전이 돌고 있었는지 기록도 없는 사이트는 어떤 데이터가 열람되었는지 말할 수 없고, 결국 최악의 경우를 신고하게 됩니다. 사고가 난 뒤가 아니라 그 전에 웹사이트 보안 감사를 받아야 하는 근거가 이것입니다.

Drupal 보안 유지보수 계약에 들어가야 할 것

업데이트를 적용해 주겠다고만 약속하는 유지보수 계약은 살 가치가 없습니다. 업데이트 적용은 쉬운 쪽 절반이기 때문입니다. 돈을 내고 사는 것은 매우 심각한 권고문이 나온 날의 대응 경로이고, 그것이 작동한다는 것을 증명하는 산출물은 리허설입니다.

값을 치를 만한 범위는 여러분의 정확한 모듈 구성에 맞춘 권고 피드 모니터링, 스테이징과 테스트와 롤백 계획을 갖춘 월간 패치 주기, 매우 심각한 코어 릴리스를 위한 합의된 업무 외 대응 구간, 방치된 모듈에 대한 분기별 검토와 대체안의 비용 산정, PHP와 플랫폼 버전 추적, 그리고 연 1회 설정 검토를 포함합니다.

영국에서 모니터링만 하는 계약은 대략 한 달 250에서 450파운드입니다. 스테이징과 테스트, 배포까지 포함하는 중간 규모 사이트용 계약은 한 달 600에서 1,500파운드에 가깝고, 모듈 수와 커스텀 코드의 양에 따라 오르내립니다. 주기마다 얼마만큼의 회귀 테스트가 필요한지를 그 둘이 정하기 때문입니다. 600에서 900파운드인 에이전시 일당에 견주면, 그 구간의 위쪽은 대략 엔지니어 이틀을 사는 셈입니다. Drupal 개발자 단가와 검증에 관한 글에 숫자가 정리되어 있습니다.

간격을 좁히기

Drupal은 견줄 만한 거의 모든 플랫폼보다 더 많은 예고와 더 많은 구조를 줍니다. 권고문은 일정에 맞춰 나오고, 매우 심각한 릴리스는 이틀의 예고와 함께 도착합니다. 한 줄짜리 패치를 배포하는 데 2주가 걸리는 사이트에는 그중 어느 것도 도움이 되지 않습니다.

Mecanik은 Drupal 패치와 보안 강화를 웹사이트 보안 감사와 이어지는 소프트웨어 개발 작업의 일부로 다룹니다. 첫 계약은 대개 수정이 아니라 재고 조사입니다. 자기 모듈 가운데 어느 것이 아직 지원되는지 말하지 못하는 사이트가 대부분이기 때문입니다. 플랫폼 자체를 저울질하고 있다면 2026년 Drupal 웹 개발 안내가 그 이야기를 다룹니다.

자주 묻는 질문

Drupal은 얼마나 자주 보안 업데이트를 내놓습니까? 컨트리뷰트 프로젝트 권고문은 매주 수요일에 공개되고, Drupal 코어는 매달 셋째 수요일에 보안 릴리스 구간을 두지만 구간이 있다고 해서 릴리스가 보장되지는 않습니다. 매우 심각한 코어 릴리스에는 보통 이틀쯤 앞서 날짜와 시간 구간을 알리는 공개 예고가 먼저 나옵니다.

Drupal 보안 위험 점수 25점 만점에 20점은 무슨 뜻입니까? Drupal은 NIST 공통 오용 점수 체계에 기반한 방식으로 모든 권고문에 0에서 25점을 매기며, 공격 난이도와 필요한 인증, 기밀성과 무결성 영향, 알려진 익스플로잇의 존재 여부, 영향을 받는 사이트의 수를 함께 봅니다. 20에서 25점에 해당하면 매우 심각이고, 그날 안에 패치하라는 뜻입니다.

2026년에도 Drupal 7을 안전하게 운영할 수 있습니까? 없습니다. Drupal 7은 2025년 1월 5일에 수명을 다했고 Drupal 보안팀은 그 코어와 컨트리뷰트 모듈, 테마에 대해 더 이상 권고문을 내지 않으므로, 결함이 조율된 수정 없이 공개될 수 있습니다. 상업적 연장 지원은 업체가 정한 조건에 따라 한정된 코드만 다루므로 이전 기간에는 도움이 되지만 지원을 받는 것과 같지는 않습니다.

공격자는 Drupal 취약점을 얼마나 빨리 악용합니까? 최악의 경우 몇 시간입니다. 2014년 10월 SQL 인젝션 권고문 이후 Drupal 보안팀은 일곱 시간 안에 패치하지 못한 사이트는 이미 침해된 것으로 간주하라고 소유자들에게 알렸습니다. 2026년 5월에는 매우 심각한 코어 SQL 인젝션을 노린 악용 시도가 공개 이틀도 되지 않아 실제 환경에서 탐지되었습니다.

웹 애플리케이션 방화벽이 있으면 Drupal 패치가 필요 없어집니까? 아닙니다. Drupal Steward 같은 방화벽은 웹 요청을 통해 악용되는 특정한 매우 심각한 코어 결함에 가상 패치를 제공해 배포 구간 동안 시간을 벌어 줍니다. 탈취된 관리자 비밀번호나 오염된 모듈, 여러분 자신의 코드에 있는 결함에는 손을 쓸 수 없으므로, 간격의 위험을 줄일 뿐 간격을 닫아 주지는 않습니다.