Drupal 지원: 유지보수 계약이 다뤄야 할 범위

Drupal 지원을 찾는 사람 대부분은 이미 그 사이트를 소유하고 있습니다. 손을 뗀 에이전시에서 넘겨받았거나 퇴사한 개발자에게서 물려받았고, 이제 업데이트는 기한을 넘겼고 어떤 양식은 메일을 보내지 않으며 보안 권고문이 하나 떨어졌는데 그것이 우리에게 해당하는지 아무도 말하지 못합니다. 그들이 원하는 것은 영업 페이지가 아닙니다. 일이 무엇이고, 공정한 계약에는 무엇이 적혀 있으며, 얼마가 드는지를 적은 범위 문서입니다.

이 글이 바로 그 문서입니다. Drupal 사이트가 매달 진짜로 필요로 하는 일, 유지보수 계약이 값어치를 하는지 가르는 운영상의 사실, 그리고 영국의 현실적인 가격대를 늘어놓습니다. 공급업체의 제안서를 옆에 펼쳐 놓고 읽으십시오. 쓸모 있는 대목은 그 제안서가 어떤 질문에 답하지 않는지 알아차리는 부분이기 때문입니다.

일반적인 웹사이트 유지보수와 Drupal을 가르는 것은 두 가지입니다. 보안 권고문이 공개된 시간표대로 나오기 때문에 노출되는 구간을 잴 수 있고 계약에 적어 넣을 수 있다는 것. 그리고 Drupal 사이트가 각자 독립된 관리자를 둔 컨트리뷰트 모듈의 조립품이기 때문에, 계속 움직이는 업그레이드 과녁을 누군가 대신 쫓아야 한다는 것입니다.

Drupal 유지보수 계약은 무엇을 다뤄야 하는가. 여러분의 정확한 모듈 구성에 걸리는 보안 권고문 감시, 스테이징을 거쳐 정해진 주기로 적용하는 코어와 컨트리뷰트 모듈 업데이트, 백업이 실제로 복원되는지에 대한 검증, 가동과 애플리케이션 오류 감시, 그리고 자잘한 작업을 위해 명시한 변경 예산입니다. 영국에서는 단순한 소개형 사이트가 월 250파운드 정도부터, 복잡한 사이트는 2,000파운드 이상까지 갑니다. 그 아래 구간에서 사는 것은 지원이 아니라 감시입니다.

Drupal 지원은 매달 실제로 어떤 일인가

세 곳에 견적을 요청하면 Essential, Business, Enterprise라는 이름이 붙은 패키지 세 개가 오고, 하나같이 명사를 나열한 목록입니다. 명사는 일이 아닙니다. 일이란 일정대로 일어나거나 아예 일어나지 않거나 둘 중 하나인 반복 작업의 묶음이고, 쓸모 있는 접근은 공급업체에게 그 하나하나를 담당 역할과 빈도가 붙은 활동으로 설명하게 만드는 것입니다.

그런 활동이 여덟 가지 있습니다. 보안 권고문 감시와 패치. 코어와 컨트리뷰트 모듈 업데이트. 의존성과 플랫폼 버전 업그레이드. 백업 검증과 복원 시험. 가동과 애플리케이션 오류 감시. 성능 저하 점검. 콘텐츠와 편집 지원. 그리고 반드시 찾아오는 자잘한 작업을 위한 변경 예산입니다.

여덟 가지를 모두 적은 계약이 저절로 좋은 계약이 되지는 않지만, 네 가지만 적은 계약은 분명히 불완전하고 빠지는 넷은 거의 언제나 같습니다. 복원 시험, 성능 저하, 플랫폼 업그레이드, 변경 예산. 하나같이 돈이 드는 것들이고, 그래서 사라집니다.

패키지 이름이 일을 가리는 방식

“무제한 지원 티켓"은 매달 셋째 수요일에 누가 코어 보안 패치를 적용하는지에 대해 아무것도 말하지 않습니다. “선제적 모니터링"은 새벽 두 시에 사람이 경보를 읽는지, 아니면 월요일까지 쌓이는지에 대해 아무것도 말하지 않습니다. “최선의 노력"은 아무것도 말하지 않습니다.

각 표현을 세 가지 사실로 바꾸십시오. 활동, 그 빈도, 그리고 그것을 수행하는 이름이 붙은 역할입니다. 대부분의 패키지 페이지는 그 처리에서 녹아 없어지고, 살아남는 쪽이 이야기해 볼 만한 공급업체입니다.

패치 구간이 곧 제품 전체다

Drupal은 보안 릴리스를 시간표에 맞춰 공개합니다. 흔치 않은 일이고 대단히 유용합니다. 코어 보안 릴리스는 매달 셋째 수요일 구간에 나가며, America/New York 기준 1200에 시작해 계절에 따라 1600 또는 1700 UTC에 해당합니다. 컨트리뷰트 프로젝트에는 매주 수요일 보안 릴리스 구간 이 있어서, 컨트리뷰트 권고문은 코어보다 훨씬 자주, 그리고 묶음으로 도착합니다.

그 결과 취약점 자체는 위험이 아닙니다. Drupal을 돌리는 모두가 같은 취약점을 같은 순간에, 공개된 자리에서 받습니다. 위험은 권고문이 공개된 시점과 패치가 운영 사이트에 올라간 시점 사이의 간격입니다. 그 간격 동안 결함은 문서화되고 색인되며, 여러분의 공급업체보다 권고문을 빨리 읽은 사람들에게 스캔당하고 있기 때문입니다.

그 간격의 시간 수 옆에서는 지원 계약의 다른 모든 조항이 장식입니다. 그래서 예비 공급업체에게 던지는 첫 질문은 철학이 아니라 산수입니다. 다음 달 셋째 수요일, 몇 시에 사람이 권고문을 읽고, 언제까지 패치가 올라가는가. “저희 표준 SLA 안에서"는 그 질문에 대한 답이 아닙니다.

Drupal은 위험을 어떻게 채점하며, 그것이 계약에 무엇을 해야 하는가

모든 Drupal 권고문에는 숫자가 붙어 있고, 그 숫자는 이 플랫폼에서 가장 덜 쓰이는 조항 작성 도구입니다. Drupal은 NIST의 통용 오용 채점 체계, 즉 NISTIR 7864 로 취약점을 채점해 여섯 가지 지표에서 0에서 25까지의 점수를 냅니다. 공격 복잡도, 인증, 기밀성 영향, 무결성 영향, 익스플로잇 가용성, 그리고 대상 분포입니다.

점수는 공개된 다섯 등급에 대응합니다. 0에서 4는 심각하지 않음, 5에서 9는 경미하게 심각, 10에서 14는 보통 심각, 15에서 19는 심각, 20에서 25는 매우 심각입니다. 이 구간은 공개되어 있고 안정적이며 어느 쪽의 해석에도 열려 있지 않습니다.

그래서 이것은 지원 SLA의 자연스러운 척추가 되는데, 거의 아무도 그렇게 쓰지 않습니다. 나중에 공급업체가 다툴 수 있는 사적인 심각도 정의를 발명하는 대신, 대응 약속을 Drupal 점수에 직접 붙여 쓰십시오. 매우 심각은 시간 외를 포함해 명시한 시간 안에 패치, 심각은 하루 업무일 안에, 보통 심각은 다음 정기 주기에, 나머지는 묶음 처리. 제삼자가 이미 정해 두었으므로 어느 쪽도 “긴급"이 무슨 뜻이었는지 다시 꺼낼 수 없습니다.

매우 심각은 운영상 전혀 다른 사건이다

매우 심각한 코어 릴리스는 드물고, Drupal은 그것을 다르게 다룹니다. 보안팀은 사이트 소유자가 인력을 마련할 수 있도록 미리 공개 예고 를 냅니다. PSA-2026-05-18이 정확히 그렇게 했고, 2026년 5월 18일에 5월 20일 수요일로 예정된, 지원되는 모든 브랜치에 영향을 주는 매우 심각한 코어 릴리스를 경고했습니다.

그 사전 통지야말로 유지보수 계약을 짜는 축이 되어야 합니다. 비상사태를 예약으로 바꿔 주기 때문입니다. 월요일에 PSA를 알고 수요일 배포 슬롯을 잡아 둔 공급업체는 지원 서비스를 운영합니다. 목요일에야 알게 되는 공급업체는 메일링 리스트를 운영합니다.

알아 둘 만한 완화책도 있습니다. Drupal Steward 는 Drupal 협회와 보안팀이 운영하는 유료의 전 세계 분산형 웹 애플리케이션 방화벽으로, 매우 심각한 코어 취약점에 대해 네트워크 계층의 가상 패치를 제공해 업데이트를 시험하는 동안 사이트를 지켜 줍니다. 가격은 미국 달러로 공개되며 트래픽에 따라 오릅니다. 월 HTTP 요청이 100만 건 정도인 사이트는 월 20달러 미만, 1,000만 건을 넘으면 월 100달러 미만입니다. 사는 것은 시간이지 면역이 아니며, 좋은 유지보수 계약은 그 비용을 누가 내는지 적어 둡니다.

보안 권고 정책이 다루지 않는 것

보안 권고 절차 및 권한 정책 에 있는 세 가지 제외가 유지보수 계약이 해야 할 일을 바꾸는데, 대부분의 지원 계약은 셋 다 침묵합니다.

권고문은 안정 릴리스에 대해서만 발행됩니다. 사이트의 어떤 모듈이 알파, 베타, 릴리스 후보 또는 개발 버전으로 돌고 있다면 그것에 대한 권고문은 결코 나오지 않으며, 소식이 없다는 것은 아무 의미도 없습니다. 범위 역시 프로젝트별 선택 가입이지 자동이 아니어서, 범위 밖의 컨트리뷰트 모듈은 통지 경로가 전혀 없는 채로 알려진 결함을 안고 있을 수 있습니다.

그리고 사람들이 걸려 넘어지는 대목이 있습니다. 외부 라이브러리에 대해서는 권고문이 발행되지 않습니다. 어떤 컨트리뷰트 프로젝트가 그 설치를 요구하더라도 마찬가지입니다. 의존성으로 끌려 들어온 자바스크립트나 PHP 라이브러리는 여러분의 문제이고 여러분이 추적할 대상이며, Drupal 피드에는 나타나지 않습니다.

범위는 철회될 수도 있다

보안 범위는 영구적이지 않습니다. PSA-2026-07-22는 QA Accounts 모듈에서 권고 범위를 걷어 냈습니다. 그 모듈이 보안보다 편의를 앞세우며 인터넷에서 닿을 수 없는 사이트만을 상정한다는 이유였습니다.

위험의 모양이 이렇습니다. 몇 해 전 범위 안에서 설치한 모듈이 조용히 그것을 잃을 수 있고, 사이트에서는 아무것도 바뀌지 않아 알려 주지 않습니다. 설치된 모든 프로젝트에 대해 현재의 범위 상태와 릴리스 안정도를 적은 목록을 유지하는 것은 진짜 반복 업무이고, 유지보수 계약에 문서로 들어가야 합니다.

의존성과 플랫폼 업그레이드도 지원 업무다

Drupal 지원 계약에서 가장 흔히 제외되는 항목이, 결국 사이트가 살아남는지를 결정하는 항목입니다. Drupal의 플랫폼 요구 사항은 움직이고, composer update가 아니라 호스팅 교체를 요구하는 계단으로 움직입니다.

PHP 쪽에서는 Drupal 10이 최소 PHP 8.1을 요구하고 , Drupal 11은 11.1부터 PHP 8.3을 최소 요건으로 삼아 왔습니다. PHP 8.5 지원은 Drupal 11.3에서 들어왔고, Drupal 12.0은 PHP 8.5 버전만 지원합니다. 이 마지막 항목은 보이는 것보다 중요합니다. 오늘 PHP 8.1에서 편안히 도는 사이트는 Drupal 12까지 강제된 플랫폼 이동을 두 번 거쳐야 하기 때문입니다.

데이터베이스 요구 사항도 그만큼 움직였습니다. Drupal 11이 필요로 하는 것은 MySQL 8.0 이상, MariaDB 10.6 이상, PostgreSQL 16 이상, 또는 SQLite 3.45 이상입니다. Drupal 10은 MySQL 5.7.8, MariaDB 10.3.7, PostgreSQL 12를 받아들였습니다. 아직 MySQL 5.7을 제공하는 매니지드 호스트는 사소한 사항이 아니라 업그레이드 경로의 걸림돌이며, 무엇이 실제로 Drupal을 잘 돌리는가 에 관한 글이 어디로 옮겨야 하는지를 다룹니다.

Drupal 10 수명 종료는 이미 유지보수 계약의 문제다

Drupal 10은 2026년 12월 9일에 수명을 다하고 , Drupal 12는 같은 주, 12월 7일이 있는 주에 나옵니다. 11.3.x와 10.6.x 브랜치에 대한 보안 지원도 그 시점에 끝납니다. 2026년 9월 기준으로 보안 릴리스를 받는 브랜치는 11.4.x, 11.3.x, 10.6.x입니다.

달력에 비추면 그것은 대략 석 달입니다. 2026년 9월에 견적이 붙은 업그레이드 계획이 없는 Drupal 10 사이트는 12월에 급행 할증을 물거나 지원 없이 돌리거나 둘 중 하나에 시간을 쓰게 되고, 두 번째 선택지는 떠밀려서가 아니라 누군가 의식적으로 내려야 할 결정입니다.

값을 하는 유지보수 계약이라면 이미 네 가지를 내놓았어야 합니다. 현재 업그레이드 상태 보고서, 맞춤 모듈과 테마에 대한 폐기 코드 스캔, 모든 컨트리뷰트 모듈의 Drupal 11 및 12 대응 여부 점검, 그리고 서면 견적입니다. 공급업체가 지금까지 그중 하나도 내놓지 않았다면, 그것이 결론입니다. Drupal 이전의 비용과 선택지와 기한 에 대한 우리 분석이 이 작업의 내용을 짚어 주고, 같은 계획이 우리 웹사이트 개발 프로젝트 안에도 들어 있습니다.

백업은 복원을 시험하기 전까지 아무 값어치가 없다

Drupal 지원 계약은 거의 전부 백업을 약속합니다. 복원을 약속하는 계약은 아주 드물고, 그 차이가 이 항목의 값어치 전부입니다. 영국 국가사이버보안센터는 소규모 조직용 지침에서 분명하게 적어 두었습니다. 백업을 만든 뒤에는 그것을 어떻게 되돌리는지 알아야 하고, 중요한 것이 모두 들어 있는지 확인해야 한다는 것입니다.

Drupal 복원에는 움직이는 부품이 셋 있고, 부분 백업은 지겨울 만큼 규칙적으로 두 번째에서 무너집니다. 데이터베이스, 공개 및 비공개 파일 디렉터리, 그리고 설정이 필요합니다. 데이터베이스는 담았지만 파일 디렉터리는 담지 않은 백업은 콘텐츠는 멀쩡하고 이미지는 없는 사이트를 복원합니다. 감시 스크립트에는 정상 작동으로 보이고, 고객에게는 재앙으로 보입니다.

날짜가 적힌 복원 시험을 일회용 환경에 대고 수행하고, 얼마나 걸렸으며 무엇이 빠졌는지 서면으로 남기도록 요구하십시오. 대부분의 사이트에서는 분기에 한 번이 합리적인 빈도입니다. 공급업체가 한 번도 해 본 적이 없다면 그들은 자기들의 복구 시간을 모르고, 여러분도 모릅니다.

가동과 오류 감시, 그리고 가동률이 실제로 재는 것

서버가 살아 있는 것과 사이트가 동작하는 것 사이에는 큰 틈이 있고, Drupal은 정확히 그 안에 앉아 있습니다. PHP 치명적 오류, 소진된 메모리 한도, 실패한 데이터베이스 연결, 깨진 캐시 재구축은 모두 순진한 점검이 성공으로 읽는 페이지를 내놓거나, 아무도 지켜보지 않는 평범한 500을 내놓습니다.

서버에서 재는 감시는 상자가 응답한다는 것을 알려 줍니다. 애플리케이션에서 재는 감시는 진짜 페이지를 요청하고 리디렉션을 따라가며 기대한 내용이 응답 본문에 있는지 확인합니다. 이 둘은 값이 다른 별개의 제품이고, 어느 쪽인지 말하지 않은 채 “가동 감시"라고 적은 지원 제안서는 싼 쪽을 설명하고 있습니다.

그 밑에는 Drupal 자신의 로그가 있습니다. 최근 로그 메시지 보고서와 PHP 오류 로그는 실패한 cron 실행, 폐기된 함수, 요청마다 예외를 던지는 모듈이 방문자가 불평하기 훨씬 전에 드러나는 곳입니다. 누군가 정해진 주기로 그것을 읽어야 합니다. 의미 있는 가동률 SLA 에 대한 우리 글이 그 백분율이 허용 분으로 어떻게 옮겨지는지를 다룹니다.

Drupal 지원 SLA를 비판적으로 읽기

대부분의 지원 SLA는 쓰이기 위해서가 아니라 합의되기 위해 쓰였고, 빨리 읽히기 때문에 합의됩니다. 무게를 거의 다 지는 조항은 셋뿐이고, 그것을 꼼꼼히 읽는 데는 십 분이면 됩니다.

응답 시간은 해결 시간이 아니다

두 시간 응답을 약속하는 SLA는 보통 누군가 두 시간 안에 티켓을 접수한다는 약속입니다. 누군가 여러분의 사이트를 들여다본다는 약속은 아닙니다. 진심인 공급업체는 해결 목표를, 최소한 진단과 우회책의 목표를 약속하고 수정까지의 시간은 따로 적습니다.

일을 정말로 시간으로 묶을 수 없는 경우, 정직한 계약은 그렇게 적고 대신 해결까지 계속 매달리겠다고 약속합니다. 그것은 진짜 약속입니다. “두 시간 응답"만 있다면 그것은 메일을 보내겠다는 약속입니다.

심각도 정의가 모든 것을 정한다

모든 SLA에는 심각도 표가 있고, 심각도를 매기는 쪽은 보통 공급업체입니다. 그것이 빠져나갈 구멍입니다. 1순위의 정의가 “사이트 이용 불가"라면, 고객 삼분의 일에게 실패하는 결제 흐름은 3순위가 되어 다음 주에나 검토됩니다.

정의를 기술적 상태가 아니라 사업 영향 중심으로 쓰고, 계약에 실제 사례를 넣으십시오. 실패하는 결제 단계, 들어갈 수 없는 관리자 로그인, 문의 페이지의 망가진 연락 양식. 그런 다음 누가 심각도를 매기고 그 판정에 어떻게 이의를 제기할지 합의하십시오.

커버 시간은 영업시간이 아니다

“영업시간"과 “커버 시간"은 다른 것을 가리키는데도 자주 섞여 쓰입니다. 커버란 시계가 돌아가고 누군가 움직일 의무를 지는 구간입니다. 커버가 업무일 09:00부터 17:30까지라면, 12월 어느 수요일 1700 UTC에 공개된 권고문은 일러야 다음 날 아침에 집어집니다.

Drupal에 한정하면, 코어 보안 구간이 1600 또는 1700 UTC에 열린다는 점에 주목하십시오. 커버가 17:30에 끝나는 영국 공급업체는 구조적으로 그 가장자리에 서 있으므로, 매우 심각한 권고문을 위한 시간 외 조치는 따로 명시하고 따로 값을 매겨야 합니다.

무엇이 장애이고 무엇이 제외되는가

제외 조항 절은 유지보수 계약이 보이는 것보다 조용히 싸지는 자리입니다. 흔한 제외는 하나씩 보면 완전히 합당하고 합쳐 놓으면 부당합니다. 제삼자 호스팅 장애, 고객 직원이 일으킨 문제, 공급업체가 설치하지 않은 모듈의 문제, 유료 테마와 관련된 모든 것, 그리고 공급업체가 장애가 아니라 변경으로 분류하는 모든 것입니다.

마지막 항목이 날카로운 모서리입니다. 버그 수정에 설정 변경이 필요하고 설정 변경이 과금 대상이라면, 거의 모든 장애를 과금 칸으로 다시 분류할 수 있습니다. 공급업체가 장애와 변경을 어떻게 구분하는지 직접 묻고, 자기들의 최근 작업에서 각각 두 가지 예를 들어 달라고 하십시오.

제삼자가 얽힐 때 어떻게 되는지도 확인하십시오. 결제 게이트웨이, CRM 커넥터, 호스트 쪽에 잘못이 있을 때 공급업체는 수정을 조율하는가, 아니면 티켓이 범위 밖으로 닫히는가. 조율은 진짜 업무이고 값을 치를 만하지만, 계약에 그렇게 적혀 있을 때만 그렇습니다.

세 가지 유지보수 계약 모델, 정직하게 비교하기

거의 모든 Drupal 지원 방식은 세 가지 형태 중 하나이고, 각각은 서로 다른 상황에 대한 합리적인 답입니다. 실수는 한 형태를 사면서 다른 형태의 행동을 기대하는 것입니다.

월 고정 시간

여덟 시간이나 열여섯 시간 같은 시간 뭉치를 사고, 공급업체는 그것을 여러분이 요청하는 무엇에든 씁니다. 투명하고 견적끼리 비교하기 쉬우며, 자잘한 변경이 꾸준히 흐르고 우선순위를 매길 사람이 내부에 있는 조직에 맞습니다.

약점은 유지보수가 기능과 같은 주머니를 두고 경쟁한다는 것입니다. 바쁜 달에는 보안 패치가 캠페인 랜딩 페이지에게 조용히 집니다. 시간을 쓰는 사람에게는 마감이 있고 패치에는 마감의 감촉이 없기 때문입니다. 이 모델을 산다면 계약 자체에서 시간의 일부를 유지보수용으로 울타리 쳐 두십시오.

무제한 수정과 별도 견적 변경

공급업체가 월 정액으로 유지보수와 소소한 수정을 흡수하고, 합의한 문턱을 넘는 것은 따로 견적을 냅니다. 대부분의 에이전시가 미는 모델이고, 안정된 사이트와 걱정 많은 소유자에게는 진짜로 옳은 답입니다. 변동하는 위험을 예산의 고정된 한 줄로 바꿔 주기 때문입니다.

약점은 경계입니다. “소소한 수정"은 누군가 필요해지기 전까지 정의되지 않고, 문턱은 그달이 어떻게 흘러가느냐에 따라 움직입니다. 서면 정의를, 되도록 삼십 분 미만 같은 시간 상자로 요구하고, 무엇이 흡수되었는지 보여 주는 월간 보고서를 요구하십시오.

순수한 시간과 자재

유지보수 계약 없이 일당을 정하고 요청할 때만 일합니다. 업데이트를 정말로 스스로 챙기는 소유자가 있는 저위험 사이트에, 그리고 내부 역량이 있어 상시 대기보다 가끔의 전문가 도움이 필요한 조직에게는 정직한 선택입니다.

약점은 선제적인 일이 아무것도 일어나지 않는다는 것입니다. 들여다보라고 돈을 받는 사람이 없기 때문입니다. 시간과 자재는 줄서기에도 약합니다. 계약을 맺은 고객들과 같은 엔지니어를 두고 다투기 때문에, 나쁜 날의 대응은 시간이 아니라 주 단위로 재집니다.

정액 지원에 숨은 유인 문제

정액 지원에는 업계 누구도 즐겨 이야기하지 않는 구조적 문제가 있습니다. 사이트가 몇 시간을 잡아먹든 공급업체가 받는 돈이 같다면, 여러분의 사이트에 쓰는 한 시간은 모두 그들의 마진을 깎으므로 상업적으로 합리적인 행동은 가능한 한 적게 쓰는 것입니다.

그것은 대개 방치로 나타나지 않습니다. 옳은 수정보다 빠른 수정을 선호하고, 원인을 추적하기보다 증상을 누르고, 하루치 회귀 시험이 필요한 모듈 업그레이드를 미루는 형태로 나타납니다. 값싼 요금제에서는 반대 방향으로도 나타납니다. 거기서는 사이트를 정말로 한 번도 건드리지 않을 때에만 요금이 말이 되기 때문입니다.

균형추는 보고 의무입니다. 소비된 시간, 적용한 업데이트, 검토한 권고문, 닫은 티켓을 적은 월간 보고서는 소비를 양쪽 모두에게 보이게 하고, 수지가 맞지 않는 계정을 느린 서비스 저하가 아니라 대화로 만듭니다. 이 모델에 자신 있는 공급업체라면 동의합니다. 저항하는 공급업체는 그 모델이 사실 무엇을 위한 것인지 알려 주고 있는 것입니다.

운영상 좋다는 것은 어떤 모습인가

여러분의 사이트를 안전하게 떠받칠 수 있는 Drupal 공급업체와 즉흥으로 해 나가는 공급업체를 가르는 기술적 관행이 셋 있습니다. 어느 것도 특별하지 않고, 셋 다 묻기 쉽습니다.

Composer이거나, 아니면 아무것도 아니거나

Drupal 자신의 문서는 업데이트 방식을 섞는 것에 대해 단호합니다. Composer 업데이트를 다른 접근과 결합하면 사이트가 심각한 업데이트 문제를 겪을 수 있다 고, 그리고 일단 Composer가 한 모듈을 관리하면 코어도 관리해야 한다고 경고합니다. 아직도 FTP로 모듈 폴더를 올리는 공급업체는 언젠가 어떤 컨트리뷰트 모듈이 의존하던 vendor 디렉터리를 지웁니다.

composer.json과 composer.lock이 버전 관리에 들어 있는지, 그리고 Composer가 운영 환경에서 도는지 아니면 빌드 산출물을 배포하는지 물으십시오. 어느 답이든 옳을 수 있습니다. 답이 없는 것은 옳을 수 없습니다.

운영과 일치하는 스테이징 환경

PHP 버전이 다르거나 데이터베이스 버전이 다르거나 모듈 구성이 다른 스테이징 사이트는 쓸모 있는 것을 아무것도 검증하지 못합니다. 스테이징의 요점은 보안 패치가 돈이 들지 않는 곳에서 실패하게 두는 것이고, 그것은 두 환경이 깨지는 축에서 일치할 때에만 가능합니다.

스테이징을 운영에서 어떻게, 얼마나 자주 새로 고치는지, 그리고 실제 콘텐츠의 정제된 사본을 갖고 있는지 물으십시오. 시험용 노드가 셋뿐인 스테이징 사이트는 40,000행짜리 뷰를 깨뜨리는 업데이트를 드러내지 못합니다.

설정을 버전 관리에 두기

Drupal은 기본적으로 설정을 데이터베이스에 보관하고 , 설정 관리 체계는 그것을 커밋하고 검토하고 다른 환경으로 가져올 수 있는 파일로 내보내기 위해 존재합니다. 그것을 쓰는 팀은 사이트의 설정을 결정론적으로 재현할 수 있습니다. 쓰지 않는 팀은 운영 관리 화면을 눌러 가며 기도하고 있습니다.

이것은 공급업체와의 대화에서 가장 또렷한 신호입니다. 스테이징에서 한 변경이 어떻게 운영에 도달하는지 물으십시오. 답이 침묵이 아니라 설명이라면, 나머지 대화는 대개 괜찮습니다.

배포를 설명하지 못한다면 그것이 답이다

이것을 점잖게 말할 방법은 없습니다. 개발자의 노트북에서 여러분의 라이브 사이트로 코드가 어떻게 움직이는지 서두르지 않고 일 분 안에 설명하지 못하는 공급업체는 배포가 즉흥이라고 말하고 있는 것입니다. 즉흥적인 배포야말로 보안 패치가 늦어지는 이유입니다. 수요일 저녁에 아슬아슬한 수작업 절차를 돌리고 싶은 사람은 없습니다.

아무도 읽지 않는 인수인계 조항

언젠가 여러분은 공급업체를 바꿉니다. 그 순간을 다스리는 조항은 모두가 우호적일 때 쓰이고 아무도 우호적이지 않을 때 읽힙니다. 거기에는 네 가지가 평이하게 적혀 있어야 합니다.

맞춤 모듈과 테마 작업을 포함해 코드를 누가 소유하며 어떤 라이선스인지. 저장소가 어디에 있고 접근 권한이 어떻게 넘어가는지. 데이터베이스, 파일, 설정의 완전한 내보내기가 명시된 형식으로 명시된 업무일 안에 제공된다는 것. 그리고 DNS와 호스팅과 제삼자 서비스 자격 증명이 붙들리지 않고 넘겨진다는 것입니다.

실패 양상은 대개 악의가 아닙니다. 여러분의 사이트를 자기 계정에서 호스팅하고, 저장소의 유일한 사본을 쥐고 있으며, 여러분이 더는 돈을 내는 고객이 아니라서 답장에 여섯 주가 걸리는 공급업체입니다. 서명하기 전에 인수인계 조항을 요구하고, 망설임을 정보로 다루십시오.

Drupal 7: 수명 종료와 연장 지원, 그리고 둘 사이의 간극

Drupal 7 보안 지원은 2025년 1월 5일에 끝났습니다 . 커뮤니티는 패치 생산을 멈췄고, Drupal 7을 쓸모 있게 만들어 주던 거대한 컨트리뷰트 모듈 생태계도 그와 함께 유지되지 않게 되었습니다.

Drupal 협회는 연장 보안 지원 제공자 프로그램을 운영하고, HeroDevs와 Tag1 Consulting이 그 아래의 인증 벤더입니다. 올해 도저히 이전할 수 없는 조직에게 그 지원을 사는 것은 정당한 결정이고, 아무것도 하지 않는 것보다 의미 있게 낫습니다.

그것이 하지 못하는 일은 사이트를 통상적인 의미에서 안전하게 만드는 것입니다. 상용 벤더는 자기가 찾았거나 통보받은 취약점을, 자기 일정에 따라, 다루기로 합의한 모듈 구성에 대해 고칩니다. 공개 권고 절차를 되살리지 않고, 여러분이 마침 설치해 둔 모든 컨트리뷰트 모듈을 덮지 않으며, 그 모듈들이 의존하는 외부 라이브러리까지 미치지도 않습니다. 연장 지원은 지원이 끊긴 플랫폼을 통제된 방식으로 돌리는 수단이지, 지원 계약이 안전의 동의어는 아닙니다.

2026년 9월에 Drupal 7 위에 있다면, 정직한 조언은 임차료가 아니라 이전에 돈을 쓰라는 것입니다. 우리 2026년 Drupal 웹 개발 안내 가 지금의 플랫폼을 다루고, 권고 절차의 더 깊은 세부는 Drupal 보안, 권고문과 진짜 위험 에 대한 글에 있습니다.

콘텐츠 지원과 변경 예산

경계를 정하기 어렵다는 이유로 지원 계약에서 밀려나는 항목이 둘 있고, 둘 다 고객이 실제로 알아채는 항목입니다.

콘텐츠와 편집 지원이란 콘텐츠 타입을 추가할 수 있고, 제대로 걸러 내지 못하게 된 뷰를 고칠 수 있고, 담당자가 바뀐 뒤 편집자를 다시 가르칠 수 있고, 어떤 이미지 스타일이 왜 얼굴을 잘라 내는지 알아낼 수 있는 사람이 있다는 뜻입니다. 요란하지 않고 빈도가 높으며, 그것이 없는 유지보수 계약은 묻기를 그만두고 사이트를 우회해 일하는 고객을 만들어 냅니다.

변경 예산은 나머지 절반입니다. 어느 사이트에나 자잘한 작업이 줄을 섭니다. 양식의 항목 하나, 페이지를 옮긴 뒤의 리디렉션, 문의를 누가 받는지에 대한 변경. 그 줄에 월 허용량을 시간으로 이름 붙이는 것이 그것이 분기마다의 비상 프로젝트로 변하는 것을 막습니다. 작은 사이트라면 월 두 시간에서 네 시간, 바쁜 사이트라면 여덟 시간에서 열여섯 시간이 현실적인 숫자입니다.

영국에서 Drupal 지원 비용

아래 숫자는 공개된 조사가 아니라 영국 에이전시의 실제 작업에 근거한 2026년 우리 자체 추정치이고, 지원 메일함이 붙은 감시 구독이 아니라 위에 적은 여덟 가지 활동을 수행하는 공급업체를 전제로 합니다.

산문으로 말하면, 작은 소개형 사이트는 대략 월 250에서 600파운드이고 여기서 권고문 감시, 월 단위 패치 주기, 백업 검증, 그리고 한두 시간의 변경을 삽니다. 연동이 있는 중형 사이트는 대략 700에서 1,800파운드입니다. 연동이 하나 늘 때마다 코어 업데이트 뒤에 다시 시험해야 할 회귀 면이 늘기 때문입니다. 맞춤 모듈이 있는 복잡한 사이트나 다국어 사이트는 2,000파운드 언저리에서 시작해 6,000파운드 이상까지 갑니다.

공급업체가 권고문을 지켜보고 무엇이 해당하는지 알려 주되 배포는 하지 않는 감시 전용 방식은 그보다 낮아 대략 월 250에서 450파운드입니다. 그 구간을 영국 에이전시 일당 600에서 900파운드 옆에 놓으면, 1,500파운드짜리 유지보수 계약은 엔지니어 이틀에 가까운 것을 삽니다. 요율의 세부는 Drupal 개발자의 요율과 역량과 검증 에 대한 글에, 더 넓은 예산 그림은 소프트웨어 유지보수 비용 에 있습니다.

무엇이 사이트를 한 단계 위 구간으로 밀어 올리는가

본능은 지원을 트래픽으로 값 매기는 것이지만 트래픽은 거의 무관합니다. 모듈 스무 개에 연동이 없는 월 20만 방문 사이트는, CRM 커넥터와 결제 게이트웨이와 맞춤 이전이 있는 월 2,000 방문 사이트보다 떠받치기가 쌉니다.

실제로 비용을 움직이는 것은 셋입니다. 모듈 수. 컨트리뷰트 모듈 하나하나가 지켜봐야 할 권고문 흐름이고 코어 업데이트마다의 호환성 위험이기 때문입니다. 연동 수. 하나하나가 여러분 발밑에서 바뀔 수 있는 외부 약속이고 다시 돌려야 할 회귀 시험이기 때문입니다. 그리고 편집량. 바쁜 편집팀은 지원 질문과 권한 변경과 콘텐츠 모델 손질을 꾸준한 속도로 만들어 내기 때문입니다.

맞춤 코드는 그 셋 모두에 걸리는 곱셈입니다. 맞춤 모듈 코드가 12,000줄인 사이트는 마이너 릴리스마다 폐기 스캔과 회귀 통과가 필요하고, 그것은 순수하게 컨트리뷰트만 쓰는 사이트가 지지 않는 하루치 작업입니다. 가장 높은 구간이 거기서 나오고, 그것이 우리 소프트웨어 개발 프로젝트가 흔히 떠맡아 달라는 요청을 받는 작업입니다.

예비 공급업체에게 물어볼 것

여섯 가지 질문, 그리고 여러분을 걱정시켜야 할 답들입니다.

우리 사이트는 지금 어떤 Drupal 버전과 어떤 PHP 버전에서 돌고 있고, 업그레이드 경로는 무엇입니까? 찾아봐야 한다는 답은 괜찮습니다. 일주일 뒤에 오는 답은 괜찮지 않습니다. 보안 권고문이 우리에게 해당한다는 것을 어떻게 알아냅니까? “drupal.org를 지켜봅니다"는 약하고, 사이트별 모듈 목록이 여러분이 원하는 답입니다.

배포 과정을 처음부터 설명해 주십시오. 여기서의 머뭇거림이 대화 전체에서 가장 강한 부정 신호입니다. 이 사이트를 백업에서 마지막으로 복원한 것은 언제입니까? “매일 백업합니다"는 그 질문에 대한 응답이 아닙니다. 유지보수 계약에서 무엇이 제외되며, 어떤 일이 장애인지 변경인지 어떻게 정합니까? 그리고 마지막으로, 우리가 떠나면 무엇을 얼마나 빨리 받게 됩니까?

유지보수 계약이 없으면 무슨 일이 벌어지는가

이것은 경고라기보다 순서이고, 지원이 없는 모든 Drupal 사이트에서 거의 같은 속도로 흘러갑니다.

처음 몇 달은 아무 일도 일어나지 않는데, 그것이 문제입니다. 아무 일도 일어날 필요가 없다고 모두가 배우기 때문입니다. 여섯째 달과 열두째 달 사이 어딘가에서 업데이트 적체가, 업데이트가 개별적으로 안전하지 않게 되는 지점을 넘어섭니다. 어떤 모듈이 이제 더 새로운 코어를 요구하고, 그것이 더 새로운 PHP를 요구하며, 호스트는 그것을 제공하지 않기 때문입니다. 패치 하나를 적용하는 일이 프로젝트가 되었습니다.

이어서 사이트는 플랫폼 지원에서 완전히 벗어나고, 브라우저나 PHP의 변경이 눈에 보이는 무언가를 망가뜨립니다. 이제 수리는 아무도 예산에 넣지 않은 업그레이드에서 시작해 비상 작업으로 견적되고, 문서가 없는 부분은 고쳐지는 대신 다시 만들어집니다. 그 도중에 침해가 일어나고 개인 정보가 얽힌다면, 정보위원회는 72시간 안의 신고를 요구합니다 . 그 침해가 사람들의 권리와 자유에 위험을 초래할 가능성이 클 때, 인지한 시점부터 세는 기한이며, 있거나 없거나 둘 중 하나인 로그와 백업으로 지키는 기한입니다.

복구 청구서는 그것을 막았을 유지보수 계약의 몇 배가 되기 마련이고, 그 차이는 인건비가 아닙니다. 계획된 작업은 화요일에 되돌리기 계획과 함께 벌어지고, 비상 작업은 일요일에 그것 없이 벌어진다는 차이입니다.

서명하기 전에 범위를 바로잡기

이 모든 것의 요점은 여러분이 공급업체를 불신하게 만드는 것이 아닙니다. 두 제안서의 비교가 뜻을 갖게 만드는 것입니다. 지금으로서는 대부분의 Drupal 지원 견적이 설계상 비교 불가능하기 때문입니다. 말이 다르고, 제외가 다르며, 매달의 일이 무엇인지에 대한 공유된 정의가 없습니다.

여덟 가지 활동, Drupal의 위험 등급, 세 가지 유지보수 계약 모델, 여섯 가지 질문을 들고 책상 위의 것에 맞대어 보십시오. 그것을 견뎌 낸 것이 진짜 제안서입니다.

Mecanik은 웹사이트 개발 과 소프트웨어 개발 업무의 일부로 Drupal 사이트를 지원합니다. 첫 작업은 대개 수리가 아니라 재고 조사입니다. 우리에게 오는 사이트 대부분이 자기 모듈 가운데 어느 것이 아직 보안 권고문 피드 의 대상인지 말하지 못하기 때문입니다.

자주 묻는 질문

Drupal 유지보수 계약에는 무엇이 들어가야 합니까? 여덟 가지 활동입니다. 여러분의 정확한 모듈 구성에 걸리는 보안 권고문 감시, 정해진 주기의 코어와 컨트리뷰트 모듈 업데이트, 의존성과 PHP 플랫폼 업그레이드, 복원을 시험한 백업 검증, 가동과 애플리케이션 오류 감시, 성능 저하 점검, 편집 지원, 그리고 시간으로 명시한 변경 예산입니다. 네 가지만 적은 계약은 불완전하고, 대개 빠지는 것은 복원 시험, 성능 점검, 플랫폼 업그레이드, 변경 예산입니다.

영국에서 Drupal 지원은 월 얼마입니까? 2026년 우리 자체 추정으로 작은 소개형 사이트는 대략 월 250에서 600파운드, 연동이 한두 개인 중형 사이트는 700에서 1,800파운드, 맞춤 모듈이 있는 복잡한 다국어 사이트는 2,000에서 6,000파운드입니다. 감시 전용 방식은 250에서 450파운드 언저리입니다. 영국 에이전시 일당 600에서 900파운드에 견주면, 1,500파운드짜리 유지보수 계약은 엔지니어 이틀 정도를 삽니다.

Drupal은 보안 패치를 언제 배포합니까? Drupal 코어 보안 릴리스는 매달 셋째 수요일 구간에 나가며, America/New York 기준 1200에 시작해 계절에 따라 1600 또는 1700 UTC에 해당합니다. 컨트리뷰트 프로젝트에는 매주 수요일 보안 릴리스 구간이 있습니다. 매우 심각한 코어 릴리스 앞에는 공개 예고가 나가므로 사이트 소유자가 미리 인력을 마련할 수 있습니다.

Drupal 7 연장 지원은 안전한 것과 같습니까? 아닙니다. Drupal 7 보안 지원은 2025년 1월 5일에 끝났고, Drupal 협회는 연장 보안 지원 제공자 프로그램 아래 HeroDevs와 Tag1 Consulting을 인증합니다. 이 벤더들은 다루기로 한 범위를 자기 일정에 따라, 합의한 모듈 구성에 대해 고칩니다. 공개 권고 절차를 되살리지 않고, 설치해 둔 모든 컨트리뷰트 모듈을 덮지 않으며, 외부 라이브러리까지 미치지도 않습니다.

Drupal 10은 언제 수명을 다합니까? Drupal 10은 2026년 12월 9일에 수명을 다하고, 같은 주인 12월 7일이 있는 주에 Drupal 12가 나옵니다. 11.3.x와 10.6.x 브랜치에 대한 보안 지원도 같은 시점에 끝납니다. Drupal 12는 PHP 8.5 버전만 지원하므로, 더 오래된 PHP를 쓰는 사이트는 업그레이드 뒤가 아니라 앞서 호스팅을 바꿔야 합니다.