Drupal 12: 무엇이 바뀌고 언제 옮겨야 하나

Drupal 12는 2026년 12월 7일이 있는 주에 나올 예정이고, Drupal 10은 2026년 12월 9일에 지원이 끝납니다. 두 날짜는 Drupal 코어 릴리스 일정 같은 페이지에 두 줄 간격으로 나란히 적혀 있지만, Drupal 10 사이트를 운영하는 사람 대부분은 둘 다 알아차리지 못했습니다. 새 메이저의 첫 알파는 2026년 9월 2일에 태그되었으니, 이번 릴리스의 모양은 이제 추측이 아니라 기록의 문제입니다.

이 충돌이 이야기의 전부입니다. 메이저 버전이 나오는 일 자체는 보통 사이트 소유자에게 급하지 않습니다. 생태계가 따라올 때까지 한두 해쯤 이전 메이저에 머물러 있어도 되기 때문입니다. 그런데 이번에는 새 버전이 나오는 바로 그 주에 이전 메이저가 보안 권고를 더는 받지 못합니다. 기술적인 사건이 규정 준수의 날을 세운 마감으로 바뀌는 셈입니다.

아래에서는 drupal.org가 공개한 일정, 코드에서 실제로 달라지는 것, 새 플랫폼 하한이 호스팅에 강요하는 것, 비용 구간을 붙인 현실적인 세 가지 업그레이드 경로, 그리고 12월에서 거꾸로 짠 계획을 다룹니다. 안심할 만한 대목은 일찍 나옵니다. Drupal 메이저 버전 인상은 대부분 재발명이 아니라 삭제입니다.

Drupal 12는 언제 나오고, 꼭 옮겨야 하나요. Drupal 12.0.0은 2026년 12월 7일이 있는 주에 Drupal 11.5.0과 함께 나올 예정입니다. Drupal 10은 이틀 뒤인 2026년 12월 9일에 지원이 끝나며, 그 뒤로는 보안 권고가 전혀 나오지 않습니다. Drupal 11 사이트라면 작은 업그레이드로 끝납니다. Drupal 10 사이트는 먼저 Drupal 11.4 이상을 거쳐야 하므로, 작업이 한 번이 아니라 두 번입니다.

앞으로 반년을 결정하는 두 날짜

릴리스 매니저들은 주기 전체를 미리 공개하고, 이번 주기는 유난히 깔끔합니다. Drupal 11.4.0은 2026년 6월 29일이 있는 주에 나왔고, 그 릴리스로 Drupal 11.2.x와 Drupal 10.5.x의 보안 지원이 함께 끝났습니다. 12.0.0-alpha1 태그는 2026년 9월 2일에 붙었습니다. 베타 요건은 2026년 9월 11일까지 갖춰야 했고, 12.0.0-beta1과 11.5.0-beta1은 9월 14일이 있는 주에, 릴리스 후보는 11월 9일이 있는 주에 배치되었습니다.

그리고 12월 7일이 있는 주에 세 가지가 한꺼번에 일어납니다. Drupal 12.0.0이 나오고, Drupal 11.5.0이 나란히 나오며, Drupal 11.3.x와 Drupal 10.6.x의 보안 지원이 끝납니다. 이틀 뒤인 2026년 12월 9일에는 Drupal 10 전체가 지원 종료에 이르고, 그 뒤로는 어떤 릴리스도 만들어지지 않습니다.

Drupal 10과 Drupal 12가 같은 주에 겹치는 이유

이것은 우연이 아니라 정책입니다. 릴리스 프로세스 개요는 메이저 버전이 짝수 해마다, 즉 두 해에 한 번 나오고, 각 메이저는 그 뒤로 메이저가 둘 더 나올 때까지 최소 네 해 동안 지원된다고 밝힙니다. Drupal 10.0.0은 2022년 12월 15일에 나왔습니다. Drupal 11은 2024년 8월에, Drupal 12는 2026년 12월에 나옵니다. 뒤의 것이 바로 그 두 번째 메이저이고, 네 해도 지났습니다. 시계는 정확히 예정대로 멈춘 셈입니다.

같은 정책이 마이너도 지배합니다. 각 마이너는 한 해 동안 지원되는데, 앞의 여섯 달은 버그 수정과 보안 수정, 뒤의 여섯 달은 보안 수정만 받습니다. 오늘 권고를 받는 것이 10.6.x뿐인 이유도, 11.5.0이 나오는 순간 11.3.x가 보호를 잃는 이유도 여기에 있습니다.

Drupal 11은 Drupal 12가 시작된다고 멈추지 않습니다. 같은 주에 11.5.0을 내는 것은 정책이 장기 지원 단계라고 부르는 국면의 시작입니다. 이전 메이저는 API가 맞춰진 마이너를 유지하고, Symfony의 LTS 릴리스로 옮겨 가며, 범위를 좁혀 가면서 여섯 달마다 유지보수 마이너를 받습니다. drupal.org는 Drupal 11의 지원 종료일을 확정해 공개하지 않지만, 자체 폐기 확장 문서에는 Drupal 11이 2028년 중반에서 후반까지 지원된다고 적혀 있습니다.

Drupal 10에 아직 남아 있는 사이트는 얼마나 될까

숫자는 공개되어 있고, 편하지 않습니다. drupal.org의 코어 사용 통계에 따르면 2026년 8월 23일에 시작하는 주에 코어 버전을 보고한 사이트는 468,877곳입니다. 그중 205,568곳이 Drupal 10의 어느 브랜치에, 168,857곳이 Drupal 11에 있습니다. 보고된 설치 기반의 대략 44퍼센트가 12월에 권고를 받지 못하게 되는 버전 위에 있는 셈입니다.

더 날카로운 숫자는 그 안에 있습니다. 아직 보안 보호를 받는 것은 10.6.x뿐이고, 10.6.x가 그중 139,911곳을 차지합니다. 남은 65,657곳은 10.0에서 10.5 사이에 있으며, 12월을 기다릴 것도 없이 지금 9월에 이미 지원이 끝난 마이너를 돌리고 있다는 뜻입니다.

이 집계는 Update Status 모듈을 통해 자발적으로 보고한 사이트에서 나오므로 실제 모집단은 더 크고, 기울기는 같습니다. 실무적으로 읽으면 아주 많은 조직이 같은 분기에 같은 업그레이드 작업을 예약하려 할 것이고, 10월과 11월의 병목은 코드가 아니라 에이전시의 일정이 된다는 뜻입니다.

지원 종료가 Drupal 사이트에 실제로 뜻하는 것

지원 종료는 사이트를 망가뜨리는 스위치가 아닙니다. 여러분의 Drupal 10 설치는 12월 10일에도 12월 8일과 똑같이 페이지를 내보냅니다. 달라지는 것은 Drupal 보안팀이 그 코드에 대한 권고와 패치를 더는 내지 않는다는 점이고, 그날부터 Drupal 10 코어에서 새로 발견되는 취약점은 모두 영구히 열린 채로 남습니다.

두 번째 효과는 더 느리고 더 큰 손상을 냅니다. 기여 모듈의 보안 보호는 지원되는 코어 브랜치용 안정 릴리스가 있는지에 달려 있습니다. 관리자들이 Drupal 10 호환을 버리기 시작하면 여러분 사이트의 모듈들도 조용히 권고 체계에서 빠져나갑니다. 그때 알림은 오지 않습니다. 모듈이 보안 릴리스에 나타나지 않게 될 뿐이고, 내 사이트의 사용 가능한 업데이트 보고서는 계속 초록색으로 보입니다.

세 번째 효과는 기다릴수록 출구가 비싸진다는 것입니다. 11월에 업그레이드하는 Drupal 10 사이트는 유지되는 코어 브랜치와 작동하는 업데이트 경로를 상대로 작업합니다. 같은 사이트를 이듬해 6월에 업그레이드하면 그것은 복구 프로젝트가 됩니다. 그 사이트가 의존하는 기여 모듈들이 사이트를 두고 여섯 달을 더 앞서 갔기 때문입니다.

Cyber Essentials, 보험, 계약 조항

여기서부터 지원이 끝난 CMS는 더 이상 엔지니어링만의 문제가 아닙니다. NCSC의 IT 인프라용 Cyber Essentials 요건 v3.3은 2026년 4월 자로, 범위 안 장비의 모든 소프트웨어는 라이선스가 있고 지원을 받아야 하며, 지원이 끊기면 장비에서 제거하거나 인터넷과의 모든 트래픽을 막는 정의된 부분집합을 써서 범위 밖으로 빼야 한다고 규정합니다. 이 통제는 서버, IaaS, PaaS, SaaS에 적용되므로 범위 안 서버에 있는 Drupal은 정면으로 해당됩니다.

공개된 Drupal 10 사이트를 인터넷에서 차단할 수는 없습니다. 그래서 2026년 12월 9일 이후에 가능한 답은 두 가지, 업그레이드하거나 그 통제를 통과하지 못한다고 인정하거나입니다. 조직이 Cyber Essentials나 Cyber Essentials Plus를 보유하고 해마다 갱신한다면, 그것은 다음 심사에서 서면으로 받게 될 질문입니다.

그 너머의 주장은 조심하십시오. 특정 사이버 보험이나 고객 계약이 영향을 받는지는 전적으로 그 문구에 달려 있고, 문제가 되는 조항은 대개 Drupal을 이름으로 지목하는 것이 아니라 지원되는 소프트웨어나 공급업체가 지원하는 버전을 요구하는 쪽입니다. 사고가 난 뒤가 아니라 12월 전에 자사 보험 증권과 주계약서를 읽어 보십시오. 그쪽이 싸게 알아내는 시점입니다.

Drupal 12에서 실제로 달라지는 것

거의 없습니다. 그것이 정직하고 쓸모 있는 답입니다. 12.0.0-alpha1 릴리스 노트는 분명히 말합니다. 12.0.x는 폐기된 코드가 통째로 된 폐기 모듈까지 포함해 제거되고, 의존성이 새 메이저로 갱신되며, 시스템 요구 사항이 올라간다는 점만 빼면 11.5.x와 거의 같다는 것입니다. 나머지 변경에 대해서는 11.5.x 브랜치를 읽으라고 안내합니다.

알아 둘 만한 실제 동작 변경도 몇 가지 있습니다. 기본 비밀번호 해싱 알고리즘이 argon2id로 바뀌고, argon2를 쓸 수 없는 곳에서는 커널 매개변수를 통해 bcrypt를 쓸 수 있습니다. 코어 robots.txt는 이제 질의 매개변수가 붙은 검색 결과 페이지를 막아, 검색 엔진이 끝없는 패싯 조합을 크롤링하지 못하게 합니다. robots.txt를 손본 사이트는 그 disallow 규칙을 직접 추가해야 합니다. 코어가 이미 함께 배포하는 HTMX는 beta1에서 버전 2에서 버전 4로 올라갑니다.

놓치기 쉬운 것이 하나 더 있습니다. 운영 환경에서 Windows 위에 Drupal을 직접 호스팅하는 것이 Drupal 12에서 폐기되었습니다. 자동화된 Windows 테스트 환경이 없고 거기서 테스트하는 개발자도 거의 없다는 이유입니다. 로컬 개발용 Windows는 계속 지원됩니다. 운영을 Windows에서 돌린다면 이것은 코드 변경이 아니라 앞으로 몇 달 안에 내려야 할 호스팅 결정입니다.

코어를 떠나는 확장

Drupal은 좁은 용도의 모듈을 코어에서 기여 프로젝트로 옮기는 일을 여러 해 해 왔고, Drupal 12도 그것을 이어 갑니다. alpha1 노트는 Ban, Contact, Field Layout, History, Settings Tray, Shortcut, Telephone을 제거 대상으로 적고 있으며 Stable 9 테마도 함께입니다. Text with Summary 필드 플러그인도 자체 기여 모듈로 옮겨 갔습니다. Ban은 11.3에서, Contact와 Field Layout, History, Telephone은 11.4에서, Settings Tray와 Shortcut, Text with Summary는 11.5에서 폐기되었습니다.

그중 둘은 사람들을 놀라게 할 것입니다. Shortcut과 Settings Tray는 아주 많은 편집팀이 선택 기능이라고 생각해 본 적 없이 날마다 쓰는 관리 기능이고, 특히 Settings Tray는 콘텐츠 편집자가 기대는 블록의 현장 설정을 떠받칩니다.

목록보다 다루는 방법이 더 중요합니다. 올바른 수순은 모듈을 제거하는 것이 아니라 업그레이드 전에 Composer 요구 사항에 기여 버전을 추가하는 것입니다. 제거하면 확장의 설정이 파괴되고, Drupal의 모듈 탐색은 코어를 마지막으로 보기 때문에 기여 프로젝트가 있으면 Drupal은 그냥 그것을 씁니다. 또 Drush는 확장 누락에 관한 update.php 경고를 건너뛸 수 있어서, 실패가 나중에 상태 보고서의 오류로 드러난다는 점도 기억해 두십시오.

가장 아프게 무는 변화는 Migrate Drupal의 상실

Migrate Drupal과 Migrate Drupal UI 모듈은 Drupal 12에서 제거되며, 다른 것들과 달리 기여 프로젝트로 옮겨지지 않습니다. Drupal 12는 Migrate API와 현대 Drupal용 목적지 플러그인은 유지하지만, Drupal 6과 Drupal 7의 소스 플러그인은 유지하지 않습니다.

Drupal 7 사이트를 갖고 있다면 다시 읽어 보십시오. 레거시 Drupal 데이터베이스를 읽어 현대 Drupal에 써 넣는 도구는 Drupal 11에는 있고 Drupal 12에는 없습니다. drupal.org의 안내는 분명합니다. 마이그레이션 API를 쓸 생각인 Drupal 6이나 Drupal 7 사이트는 계속 Drupal 11로 마이그레이션한 다음, 통상적인 업데이트 절차로 Drupal 11에서 Drupal 12로 옮기라는 것입니다.

이것은 막연한 의도를 딱딱한 순서 제약으로 바꿉니다. Drupal 11이 지원에서 내려간 뒤에 착륙하는 Drupal 7 재구축은 자체 소스 플러그인을 만들거나, 일회용 환경에 옛 코어를 되살려 마이그레이션을 돌리거나, 다른 방법으로 콘텐츠를 내보냈다 다시 넣어야 합니다. 셋 다 Drupal 11이 현재의 유지되는 목적지일 때 마이그레이션을 마치는 것보다 비쌉니다. 그 일의 모양은 Drupal 마이그레이션 비용과 선택지, 마감 안내서에서 자세히 다룹니다.

새로운 의존성 하한

메이저 버전은 Drupal이 플랫폼 요구 사항을 올려도 되는 자리이고, Drupal 12는 그 허가를 전방위로 씁니다. 이 하한들은 협상이 되지 않는 부분입니다. 설치 시점에 강제되기 때문입니다.

PHP 8.5, 그 아래는 안 됩니다

Drupal 12는 PHP 8.5를 요구합니다. PHP 요구 사항 표를 보면 Drupal 12.0은 PHP 8.5를 지원하고 그 아래는 모두 거부하는 반면, Drupal 11.3과 11.4는 8.3과 8.4, 8.5를 받아들입니다. 그 겹침이 여러분의 이전 경로입니다. Drupal 11.4에 머문 채로 사이트를 PHP 8.5로 옮기고, 잘 도는지 확인한 다음 Drupal을 바꾸십시오.

하한 자체는 가혹하기보다 넉넉합니다. PHP 8.5는 2025년 11월 20일에 나왔고, php.net의 지원 버전 페이지는 활성 지원을 2027년 12월 31일까지, 보안 지원을 2029년 12월 31일까지로 적고 있습니다. 거기에 착륙하면 이 대화를 다시 하기까지 세 해를 벌 수 있습니다.

데이터베이스와 Symfony

Drupal 12의 데이터베이스 서버 요구 사항은 MySQL 8.0 이상, MariaDB 10.11 이상, PostgreSQL 18 이상, 그리고 json1 확장을 갖춘 SQLite 3.45입니다. PostgreSQL 사이트라면 이 하한을 특히 꼼꼼히 확인해야 합니다. alpha1 릴리스 노트는 PostgreSQL 19라고 적었는데 요구 사항 페이지와 설치 프로그램 코드는 둘 다 18이라고 말하기 때문입니다. 데이터베이스 작업을 예약하기 전에 beta1에서 다시 확인하십시오.

그 아래에서는 Symfony가 7.4에서 8.1로, Guzzle이 7에서 8로 올라갑니다. doctrine/lexer 2, egulias/email-validator 3, guzzlehttp/psr7 2를 비롯한 몇몇 오래된 라이브러리 메이저는 지원이 끊깁니다. Symfony 클래스를 직접 타입 힌트하는 사용자 정의 코드가 이것이 드러나는 자리입니다.

하한이 호스팅에 강요하는 것

공유 호스팅과 관리형 호스팅에서 걸리는 것은 MariaDB 인상입니다. Drupal 11은 MariaDB 10.6을 받아들이는데, MariaDB 유지보수 정책에 따르면 그 커뮤니티 유지보수는 2026년 7월 6일에 끝났습니다. 그래서 Drupal 11 사이트는 지금 아주 떳떳하게 지원이 끝난 데이터베이스 엔진 위에 앉아 있을 수 있습니다. Drupal 12는 하한을 10.11로 올리고, 이쪽은 2028년 2월 16일까지 유지됩니다. 호스팅 업체가 오늘 PHP 8.5와 MariaDB 10.11을 내줄 수 없다면 Drupal 이전보다 호스팅 이전이 먼저 일어나야 하고, 그 순서 뒤집기가 두 주짜리 일을 두 달짜리로 만드는 요인입니다. 플랫폼 쪽은 Drupal을 실제로 잘 돌리는 것에 관한 글에서 다룹니다.

폐기 모델이 Drupal 12를 다룰 만하게 만드는 이유

사이트 소유자 대부분이 한 번도 설명받지 못한 구조가 여기 있고, 그것이 Drupal 메이저가 더는 무섭지 않은 이유입니다. 메이저 버전 간 연속 업그레이드 정책은 코어에 단순한 약속을 지우게 합니다. 다음 메이저 릴리스는 이전 메이저의 마지막 마이너 릴리스와 같은 공개 API를 갖는다는 약속입니다. 새 API는 마이너에서 추가되고, 옛 API는 마이너에서 폐기로 표시되며, 삭제는 오직 메이저 경계에서만 일어납니다.

실무적 귀결은 쉬운 말로 적어 둘 가치가 있습니다. 여러분의 사용자 정의 코드와 기여 모듈이 Drupal 11.5에서 폐기 경고 없이 돈다면, 그것들은 Drupal 12에서도 돕니다. 업그레이드는 다시 쓰기가 아니라 의존성 인상과 데이터베이스 업데이트가 됩니다. 깨졌을 만한 것은 모두 몇 달 전에, 여유 있을 때 고칠 수 있는 경고로 이미 보고되었기 때문입니다.

릴리스 노트가 먼저 11.4 이상으로 올리라고 하고 11.5를 강하게 권하는 이유도 이것입니다. 11.4.0 이전 릴리스에서 오는 데이터베이스 업데이트 경로는 Drupal 12에서 통째로 제거되었으므로, 11.3 이하 사이트는 11 브랜치를 먼저 올라가기 전에는 12로 가는 길이 없습니다. 그것은 조언이 아니라 없는 코드 경로입니다.

폐기를 알려 주는 도구들

일을 하는 프로젝트는 둘이고, 둘 다 지금도 유지되고 있습니다. Upgrade Status는 사이트 전체 스캐너입니다. 업그레이드해 갈 사이트가 아니라 업그레이드해 올 사이트에 설치합니다. 호출을 찾으려면 폐기된 API가 거기 있어야 하기 때문입니다. 환경이 다음 메이저의 시스템 요구 사항을 채우는지 확인하고, 기여 프로젝트를 사용 가능한 업데이트와 대조하고, 폐기된 PHP API 사용에 대해 PHPStan을 돌리고, Twig 템플릿과 info.yml, composer.json, 폐기된 설정 키를 읽습니다. 2026년 7월 2일 자 릴리스 5.0.0-alpha3은 Drupal 10.4와 11, 12 호환을 선언합니다.

찾은 것을 분류해 준다는 점도 돈을 아껴 줍니다. 문제는 기계가 고칠 수 있는 것과 사람이 고쳐야 하는 것으로 나뉘어서, 날짜를 약속하기 전에 손으로 할 절반의 비용을 낼 수 있습니다. Drush에서는 upgrade_status:analyze로 돌고, Code Climate JSON 출력은 GitLab CI에 꽂힙니다.

나머지 절반은 Drupal Rector입니다. 이쪽은 사용자 정의 모듈과 테마 안에서 기계적으로 고칠 수 있는 폐기를 다시 씁니다. --dry-run 플래그로 차이를 먼저 볼 수 있습니다. 버전 1.1.2는 2026년 8월 7일에 나왔습니다. 이 둘을 함께 쓰면 실력 있는 개발자는 중간 규모 사이트의 준비 상태 보고서를 이틀에서 사흘이면 근거 있게 만들 수 있습니다.

경로 하나, Drupal 11에서 Drupal 12로

Drupal 11.4나 11.5에 있고 기여 모듈이 최신이라면 이것은 작은 일입니다. 공식 업그레이드 안내서는 대부분 Composer 명령입니다. 버전 12 메타패키지를 --no-update로 require 하고, 명시적인 drupal/core 요구가 있으면 빼고, composer update --dry-run을 돌린 다음 실제로 돌리고, drush updatedb로 데이터베이스 업데이트를 적용합니다.

진짜 일은 그 앞뒤에 있습니다. 앞에서는 Upgrade Status를 돌리고, 실제로 쓰는 제거된 코어 확장에 기여 대체품을 추가하고, 호스팅이 PHP 8.5를 준다는 것을 확인합니다. 뒤에서는 .htaccess를 포함해 코어 스캐폴드 파일이 전부 바뀌었을 것을 각오해야 합니다. 거기에 넣은 수정은 눈감고 병합할 것이 아니라 의식적으로 다시 적용해야 합니다.

의존성이 풀리기를 거부할 때는 composer why-not drupal/core ^12가 막는 것을 지목해 줍니다. composer.json에서 모듈의 메이저 둘을 함께 허용하는 방식, 예를 들어 "^6.1 || ^7.0"은 전환 중인 프로젝트를 잇는 표준적인 방법입니다. 동작하는 패치는 있지만 태그된 릴리스가 없는 모듈이 필요하다면, Drupal Lenient Composer 엔드포인트가 바로 그 용도로 있고 지금도 유지됩니다.

경로 둘, Drupal 10에서 Drupal 12는 두 번의 도약

Drupal 10에서 Drupal 12로 바로 가는 업그레이드는 없습니다. Upgrade Status 문서가 그렇게 못박고 있고, 11.4 이전 데이터베이스 업데이트 경로의 제거가 그것을 강제합니다. Drupal 10.6에서 Drupal 11.4나 11.5로 가고, 사이트를 검증하고, 거기서 Drupal 12로 갑니다.

제대로 계획하면 이것은 두 배의 일이 아닙니다. Drupal 10에서 Drupal 11로 가는 도약이 위험의 거의 전부를 짊어집니다. 기여 모듈 호환 문제가 사는 곳도, 사용자 정의 코드가 제거된 API와 만나는 곳도 거기이기 때문입니다. 두 번째 도약은 위에서 말한 작은 쪽입니다. 둘을 하나의 변경 창에 밀어 넣으려는 팀은 대개 무엇이 무엇을 깨뜨렸는지 구분하지 못하게 됩니다.

먹히는 순서는 이렇습니다. Drupal 11 도약을 지금 하고, 11.4나 11.5 위에서 몇 주 동안 사이트를 돌려 실제 편집 작업과 트래픽이 이상한 것을 드러내게 하고, 기여 모듈이 Drupal 12용 안정 릴리스를 태그한 새해에 Drupal 12를 가져가는 것입니다. 12월 전에 첫 도약을 마치는 것이 핵심인데, 지원이 끝난 코드에서 빠져나오게 하는 것이 그 도약이기 때문입니다.

경로 셋, Drupal 7이나 8은 업그레이드가 아니라 재구축

Drupal 9보다 오래된 것은 다른 종목입니다. Drupal 7은 2025년 1월 5일에, Drupal 6은 2016년 2월에 지원이 끝났습니다. 둘 다 제자리 업그레이드가 아예 되지 않습니다. 현대적 아키텍처보다 앞선 물건이기 때문입니다. 그것들은 마이그레이션됩니다. 즉 현재 Drupal 위에 새 사이트를 짓고 Migrate API로 콘텐츠를 옮겨 넣습니다. Drupal 8 사이트에는 기술적으로 제자리 경로가 있지만, 메이저 넷을 잇달아 지나야 하고 기여 모듈이 그 하나하나를 살아남아야 해서 보통은 재구축으로 보는 편이 쌉니다.

비용을 좌우하는 것은 콘텐츠가 아닌 나머지 전부입니다. 테마는 다시 만들고, 사용자 정의 모듈은 전혀 다른 API를 상대로 다시 쓰고, 연동은 다시 붙입니다. 저희 경험으로는 콘텐츠 마이그레이션 자체가 보통 예산의 작은 쪽 절반인데, 견적을 물을 때 소유자 대부분이 기대하는 것과 정반대이고, 이것을 업그레이드가 아니라 웹사이트 개발 프로젝트로 잡는 이유이기도 합니다.

이런 사이트에 12월 마감은 다르게 작용하지만 Migrate Drupal 제거 때문에 여전히 뭅니다. 목표는 Drupal 12가 아니라 Drupal 11이어야 하고, Drupal 11은 drupal.org 자체 문서에 따르면 2028년 중반에서 후반까지 지원됩니다. 그것이 Drupal 7 소유자에게 진짜 창을 주지만, 끝이 정해진 창입니다. 2028년 목표를 맞추겠다고 2028년에 여섯 달짜리 재구축을 시작하는 것은 계획이 아닙니다.

각 경로가 영국에서 드는 비용

이것은 공개 요율이 아니라 저희 실제 납품에서 나온 사내 추정치이며, 각 구간 안의 폭은 사이트 규모보다 기여 모듈의 건강 상태가 거의 전부 결정합니다. 영국 에이전시는 이런 작업에 하루 대략 600에서 900파운드를 청구합니다. 잘 관리된 사이트의 Drupal 11에서 12로의 업그레이드는 테스트를 포함해 사흘에서 여드레이고, 대략 2,000에서 6,000파운드에 내려앉습니다. 같은 사이트라도 기여 모듈이 낡았다면 두 주에서 네 주와 6,000에서 12,000파운드를 잡으십시오.

Drupal 10 사이트는 두 도약의 값을 다 냅니다. 잘 관리되었다면 Drupal 10에서 11 도약이 6,000에서 15,000파운드, Drupal 12 도약이 2,000에서 6,000파운드를 더해 네 주에서 여덟 주에 걸쳐 합계 8,000에서 21,000파운드입니다. 방치되었다면 첫 도약만으로 15,000에서 35,000파운드가 들고 합계는 17,000에서 41,000파운드 사이에 내려앉습니다. Drupal 7 재구축은 석 달에서 여섯 달이고 흔히 40,000에서 120,000파운드이며, 크거나 손을 많이 댄 사이트는 더 높습니다.

날짜를 정하는 것은 기여 모듈 점검입니다

업그레이드 프로젝트가 코어에서 죽는 일은 드뭅니다. 죽는 곳은 목록의 열네 번째 모듈, 아무도 설치한 기억이 없고, 다음 메이저와 호환되는 릴리스가 없으며, 관리자가 2023년에 마지막으로 댓글을 단 그 모듈입니다. 날짜를 약속하기 전에 이 점검을 하십시오. 날짜를 만들어 내는 것이 바로 이 점검이기 때문입니다.

Upgrade Status를 돌려 보고서를 내보낸 다음, 모듈을 네 바구니로 나누십시오. 첫째는 목표 메이저를 지원하는 안정 릴리스가 있는 프로젝트로, 비용이 들지 않습니다. 둘째는 이슈 큐에 패치나 개발 릴리스가 있는 프로젝트로, 약간의 통합 작업이 들고 그 패치가 끝내 들어가지 않을 위험을 안습니다. 셋째는 이슈는 열려 있지만 패치가 없는 프로젝트로, 누군가 써야 합니다. 넷째는 아무 활동도 없는 프로젝트입니다.

일정을 정하는 것은 넷째 바구니이고, 그 크기는 11월이 아니라 오늘 알 수 있습니다. 기여 모듈이 서른 개인데 넷째 바구니가 비어 있는 사이트는 간단한 일입니다. 같은 사이트에 넷째 바구니가 넷이면 예산이 다른 다른 계약이고, 그 두 견적의 차이는 스캔 하루입니다.

버려진 모듈은 어떻게 할 것인가

정직한 선택지는 넷이고, 무엇이 맞는지는 그 모듈이 하는 일에 달려 있습니다. 그것이 주는 기능을 더는 쓰지 않는다면 제거하십시오. 몇 해에 걸친 편집 방향의 표류 뒤에는 팀이 예상하는 것보다 자주 이것이 사실입니다. 같은 일을 하는 유지되는 프로젝트로 바꾸되, 딸려 오는 설정 이전을 받아들이십시오.

유지보수를 넘겨받는 것도 Drupal에서는 진짜 선택지이고 들리는 것만큼 부담스럽지 않습니다. drupal.org에는 지원되지 않는 프로젝트의 관리자가 되는 절차가 문서로 있고, 사업이 의존하는 작은 모듈이라면 입양하는 편이 대체보다 쌀 수 있습니다. 비용이 한 번이 아니라 계속 드는 성격이니 정직하게 잡으십시오.

아니면 실제로 쓰는 범위로 좁힌 사용자 정의 모듈로 그 동작을 다시 구현하십시오. 기여 모듈은 모두를 위한 일반적인 문제를 풀지만, 여러분에게 필요한 것은 대개 그 좁은 한 조각입니다. 그 조각을 현재 API를 상대로 다시 만드는 일은 두 주짜리 포팅에 비해 이틀이면 끝나는 경우가 많고, 의존성을 영구히 없앱니다. 바로 이런 판단력을 가진 사람을 어떻게 가려내는지는 Drupal 개발자 채용에 관한 안내에서 다룹니다.

2026년 12월 9일에서 거꾸로 짠 일정

끝나는 날짜에서 시작하면 계획은 저절로 쓰입니다. 9월 하순까지 운영 사본을 상대로 Drupal 12용 Upgrade Status를 돌려 네 바구니를 종이에 올리십시오. 이틀에서 사흘짜리 작업이고, 나머지 전부를 정직하게 산정할 수 있게 해 주는 유일한 산출물입니다.

10월 중순까지 호스팅이 PHP 8.5와 데이터베이스 하한을 줄 수 있는지 확인하고, 아니라면 이전을 시작하십시오. 기여 모듈 문제도 이때 결정하십시오. 하나하나에 리드 타임이 붙어 있기 때문입니다. 11월 초까지 Drupal 10 사이트라면 Drupal 11.4나 11.5 업그레이드를 마치고, 새 브랜치 위에서 운영이 돌고 있어야 합니다.

12월 초에는 12.0.0 출시에 반응하는 대신 그것을 지켜보는 쪽이 됩니다. 그 시점에 Drupal 11에 있다면, 기여 프로젝트가 Drupal 12용 안정 릴리스를 태그한 뒤인 2027년 1월이나 2월에 Drupal 12를 가져가십시오. 출시 주에 업그레이드한다고 상을 주지 않고, Drupal 11.5는 그 뒤로도 지원됩니다. 상은 권고가 멈출 때 Drupal 10 위에 있지 않은 쪽에 주어집니다.

아무것도 하지 않으면 드는 비용

직접적인 비용은 2026년 12월 9일 이후에 공개되는 Drupal 코어 취약점이 여러분 사이트에서 영구히 열린 채로 남는다는 것입니다. Drupal의 권고 이력에는 공개 몇 시간 만에 악용될 만큼 심각한 원격 코드 실행 문제가 들어 있고, 공개 IP 위의 패치되지 않은 CMS는 여러분을 고른 공격자가 아니라 자동 스캐닝에 발견됩니다.

간접 비용은 더 일찍 오고 대개 더 큽니다. Cyber Essentials 심사에서 지원 소프트웨어 통제를 통과하지 못하면 그 인증을 요구하는 계약의 자격에 영향이 갈 수 있는데, 영국 공공 부문 조달에서는 흔한 일입니다. 기여 모듈은 여러분 브랜치용 수정을 더는 내지 않습니다. 그리고 업그레이드 자체가 달마다 비싸집니다. 아무도 아무것도 건드리지 않는데 코드베이스와 유지되는 생태계 사이의 간격이 벌어지기 때문입니다.

더 조용한 비용도 있습니다. 아무도 업그레이드를 허락받지 못하는 사이트는 아무도 변경을 허락받지 못하는 사이트가 되기 쉽고, 기능 개발이 멈춥니다. 모든 변경을 사라질 API를 상대로 만들어야 하기 때문입니다. 다섯 해 된 Drupal 사이트가 업그레이드가 아니라 재구축이 되는 경로가 이것입니다. 그 결정을 저울질하고 있다면 견적보다 저희 Drupal 개발 안내서가 더 나은 출발점입니다.

기다릴 만한 정당한 이유 둘

기다림이 변호되는 상황은 둘이고, 의도적으로 기다릴 때만 그렇습니다. 첫째는 이미 Drupal 11.4나 11.5에 있는 경우입니다. 그 브랜치들은 지원되고, Drupal 12를 위해 지정된 발사대이며, 기여 프로젝트가 아직 릴리스를 태그하는 첫 몇 주에 갓 나온 메이저를 가져갈 이점은 없습니다. 2027년 1분기까지 기다리는 것은 게으른 선택이 아니라 전문가의 선택입니다.

둘째는 예산이 붙은 재구축이 이미 잡혀 있는 Drupal 7 사이트입니다. Drupal 7을 Drupal 11로 옮기고 곧바로 Drupal 12로 넣는 것은 헛수고입니다. Drupal 11에 착륙해 돌려 보고, Drupal 12는 나중에 통상적인 유지보수로 가져가십시오.

변호가 안 되는 것은 예약된 계획 없이 Drupal 10에 앉아 있는 것입니다. 그것이 여러분이라면 9월 말까지 최소한 갖춰야 할 것은 스캔 보고서, 이름이 정해진 목표 브랜치, 달력에 적힌 날짜입니다. 나머지는 다 움직일 수 있습니다. 그 평가를 해 본 사람에게 맡기고 싶다면, 저희 소프트웨어 개발 팀이 버전 감사를 범위가 고정된 작업으로 해 드립니다.

어디서 시작할 것인가

스캔을 먼저 하십시오. 세상에 있는 나쁜 Drupal 업그레이드 견적은 거의 전부 스캔 없이 만들어졌고, 그래서 그 많은 견적이 양쪽으로 다 틀립니다. Upgrade Status와 Drupal Rector 출력을 이틀에서 사흘 읽으면 위의 다섯 비용 구간 중 실제로 어디에 있는지 알 수 있고, 그 하나의 숫자가 메이저 버전에 관한 어떤 일반론보다 이사회와의 대화를 크게 바꿉니다.

Mecanik은 그런 감사와 그 뒤의 업그레이드를 합니다. 12월을 마주한 Drupal 10 사이트에서도, 2027년의 차분한 이동을 계획하는 Drupal 11 사이트에서도 그렇습니다. 사용자 정의 모듈 작업과 연동, 폐기 정리는 저희 소프트웨어 개발 조직이 맡고, 재구축이나 호스팅 이전은 웹사이트 개발이 맡습니다. 이 일이 책상에 올라온 이유가 보안 태세라면 Drupal 보안 권고와 실제 위험에 관한 글에서 시작하시고, 버전 이동 중 자연 유입이 걱정이라면 Drupal SEO 설정 글이 무엇을 지켜야 하는지 다룹니다.

자주 묻는 질문

Drupal 12는 언제 나오고 Drupal 10은 언제 지원이 끝나나요? Drupal 12.0.0은 2026년 12월 7일이 있는 주에 Drupal 11.5.0과 함께 나올 예정이고, Drupal 10은 2026년 12월 9일에 지원이 끝납니다. 두 날짜 모두 Drupal 코어 릴리스 일정에 공개되어 있습니다. 같은 주에 11.3.x와 10.6.x 마이너 브랜치의 보안 지원도 끝납니다. Drupal 12.0.0-alpha1은 2026년 9월 2일에 태그되었습니다.

Drupal 10에서 Drupal 12로 바로 업그레이드할 수 있나요? 할 수 없습니다. Drupal 11.4.0 이전 릴리스에서 오는 데이터베이스 업데이트 경로가 Drupal 12에서 제거되었기 때문에, Drupal 10 사이트는 먼저 Drupal 11.4 이상으로 옮긴 다음 Drupal 12로 가야 합니다. drupal.org는 메이저 이동 전에 11.5.0 이상을 권합니다. 두 번의 도약으로 계획하시고, 위험과 비용의 거의 전부는 Drupal 10에서 11로 가는 도약이 짊어집니다.

Drupal 12의 시스템 요구 사항은 무엇인가요? Drupal 12는 PHP 8.5를 요구하며 PHP 8.4 이하 지원을 끊습니다. 데이터베이스 하한은 MySQL 8.0, MariaDB 10.11, PostgreSQL 18, 그리고 json1 확장을 갖춘 SQLite 3.45입니다. Symfony는 8.1로, Guzzle은 8.0으로 올라갑니다. 운영 환경에서 Windows 위에 Drupal을 직접 호스팅하는 것은 폐기되었지만, 로컬 개발용 Windows는 계속 지원됩니다.

Drupal 11.5와 비교해 Drupal 12에서 실제로 새로운 것은 무엇인가요? 설계상 거의 없습니다. alpha1 릴리스 노트는 12.0.x가 폐기 코드 제거, 의존성 메이저 갱신, 시스템 요구 사항 인상을 빼면 11.5.x와 거의 같다고 밝힙니다. 눈여겨볼 동작 변경은 기본 비밀번호 해싱 알고리즘이 argon2id가 된다는 점, HTMX가 버전 4로 올라간다는 점, 코어 robots.txt가 질의 매개변수가 붙은 검색 결과 페이지를 막는다는 점입니다.

영국에서 Drupal 12 업그레이드 비용은 얼마인가요? 잘 관리된 Drupal 11 사이트라면 영국 에이전시의 일반적인 요율인 하루 600에서 900파운드로 사흘에서 여드레, 대략 2,000에서 6,000파운드입니다. Drupal 10 사이트는 두 도약의 값을 다 내며, 잘 관리되었으면 8,000에서 21,000파운드, 방치되었으면 17,000에서 41,000파운드에 내려앉습니다. Drupal 7 재구축은 석 달에서 여섯 달이고 흔히 40,000에서 120,000파운드입니다. 이는 공개 요율이 아니라 사내 추정치입니다.