Drupal 마이그레이션은 어떤 날짜가 등을 떠밀기 전까지는 다음 분기 계획에 편안하게 눌러앉아 있는 부류의 프로젝트입니다. 지금 그 역할을 하는 날짜가 두 개 있고, 그중 아직 오지 않은 것은 하나뿐입니다.

Drupal 7은 2025년 1월 5일에 공식 지원이 끝났습니다. 아직 그 버전으로 돌아가는 사이트는 이미 일 년 넘게 보안 보호 없이 운영되고 있다는 뜻입니다. Drupal 10은 2026년 12월 9일에 수명이 끝납니다. Drupal 12가 나오는 바로 그 주이며, 그 이후로는 어떤 종류의 릴리스도 나오지 않습니다. 둘 중 어느 버전에 있든 이제 질문은 움직일지 말지가 아니라 어느 경로를 택할 것이며 비용이 얼마나 드는가입니다.

지금 서 있는 자리: Drupal 10에서 Drupal 11로 가는 것은 진짜 업그레이드입니다. 같은 사이트를 제자리에서 갱신하는 일이고 보통 이 주에서 육 주면 끝납니다. Drupal 7에서 Drupal 11로 가는 것은 업그레이드가 전혀 아닙니다. 콘텐츠 이전이 딸린 재구축이며 보통 삼 개월에서 육 개월이 걸립니다. 이 둘을 혼동하는 것이 이 분야에서 가장 비싼 실수입니다. Drupal 7 사이트가 업그레이드로 견적을 받고 나서 네 배로 불어나기 때문입니다.

완전히 다른 두 가지 마이그레이션

마이그레이션이라는 한 단어가 이름 말고는 공통점이 거의 없는 두 가지 작업을 덮고 있습니다.

Drupal 10에서 11로 가는 것은 업그레이드입니다. 아키텍처가 같습니다. 엔티티와 필드, 뷰, 설정이 그대로 넘어갑니다. 작업의 대부분은 의존성 관리입니다. 사용 중인 모든 기여 모듈에 Drupal 11 호환 릴리스가 있는지 확인하고, 사용자 정의 코드에서 더 이상 권장되지 않는 API 호출을 걷어내고, 지원되는 PHP 버전으로 옮기는 일입니다. 어렵다기보다 꼼꼼한 일이며, 잘 관리된 사이트라면 이 주 정도면 마무리됩니다.

Drupal 7에서 Drupal 11로 가는 것은 재구축입니다. Drupal 8은 플랫폼을 Symfony 컴포넌트 위에 다시 썼고 모듈 API와 테마 계층, 설정 시스템을 모두 교체했습니다. 콘텐츠를 빼면 자동으로 넘어오는 것이 없고, 그 콘텐츠조차 업그레이드 스크립트가 아니라 따로 만든 이전 절차를 통해 들어옵니다. 쓰던 모듈은 더 이상 존재하지 않고, 테마는 Twig로 다시 써야 하며, 사용자 정의 코드는 다른 아키텍처 위에서 새로 구현해야 합니다.

두 번째 경우가 바로 Drupal 7 사이트가 그토록 오래 남아 있는 이유입니다. 솔직하게 말하면 사이트를 업그레이드하는 것이 아니라 새 사이트를 짓고 콘텐츠를 데려가는 것입니다.

Drupal 마이그레이션 경로별 비용

아래 수치는 영국 에이전시 요율과 복잡도가 중간 정도인 사이트를 전제로 합니다. 여기서 복잡도란 페이지 수가 아니라 콘텐츠 타입과 기여 모듈, 사용자 정의 모듈의 개수를 뜻합니다.

Drupal 10에서 11, 잘 관리된 사이트. 이 주에서 사 주, 대략 6,000에서 15,000파운드입니다. 운이 좋은 경우입니다. 모듈은 최신이고 사용자 정의 코드는 적으며 작업의 중심은 테스트입니다.

Drupal 10에서 11, 방치된 사이트. 사 주에서 팔 주, 대략 15,000에서 35,000파운드입니다. 여기서 발목을 잡는 것은 Drupal 11용 릴리스가 없는 기여 모듈, 그사이 제거된 API를 대상으로 작성된 사용자 정의 코드, 그리고 함께 올려야 하는 PHP 버전입니다. 버려진 모듈 하나하나가 결정을 요구합니다. 대체품을 찾을지, 직접 유지보수를 떠안을지, 그 동작을 새로 구현할지입니다.

Drupal 7에서 Drupal 11. 삼 개월에서 육 개월, 흔히 40,000에서 120,000파운드이며 규모가 크거나 손을 많이 댄 사이트라면 그 이상입니다. 폭이 넓은 이유는 이것이 사실상 재구축 예산이기 때문입니다. 콘텐츠 이전 자체는 오히려 작은 쪽 절반이고, 테마와 맞춤 기능, 외부 연동이 큰 쪽 절반을 차지합니다.

Drupal 7에서 다른 플랫폼으로. 이것이 정답일 때도 있습니다. 애초에 Drupal을 고른 이유가 더는 유효하지 않다면, 예를 들어 사이트가 블로그가 딸린 평범한 마케팅 사이트가 되었다면, 더 단순한 쪽으로 옮기는 편이 Drupal 안에서 이전하는 것보다 싸게 먹히고 이후 운영비도 줄어듭니다. WordPress와 맞춤 개발 비교 에서 그 경계가 어디인지 다루고 있고, Drupal 웹 개발 가이드 는 Drupal이 답이 아닌 경우도 솔직하게 적어 두었습니다.

기여 모듈이 일정을 결정하는 이유

거의 모든 Drupal 업그레이드 견적은 기여 모듈 점검에서 살거나 죽습니다. 그리고 그것이 가장 먼저 해 볼 만한 일입니다.

사이트가 사용하는 기여 모듈을 전부 적어 놓고, 각각에 대해 목표 버전과 호환되는 안정 릴리스가 있는지 확인하십시오. 나오는 결과는 네 무리로 나뉩니다. 호환 릴리스가 있어 아무것도 할 필요가 없는 것. 릴리스 후보나 이슈 큐의 패치가 있어 Composer로 적용할 수 있는 것. 버려져서 대체품을 찾거나, 직접 모듈을 떠맡거나, 그 기능을 사용자 정의 코드로 대신해야 하는 것. 그리고 Drupal 코어에 흡수된 것으로, 이 작업에서 만나는 반가운 소식입니다.

이 점검이 막연한 프로젝트를 셀 수 있는 프로젝트로 바꿔 놓습니다. 그전까지 모든 견적은 짐작일 뿐이고, 점검 없이 고정가를 내미는 업체는 크게 얹었거나 곧 변경 요청을 쏟아낼 참입니다.

같은 논리가 사용자 정의 모듈에도 적용되지만 도구가 다릅니다. Drupal의 지원 중단 검사 도구는 사용자 정의 코드를 훑어 이미 제거되었거나 제거 예정인 API 호출을 보고합니다. 덕분에 우리에게 사용자 정의 코드가 좀 있다는 말이 파일과 줄 번호의 구체적인 목록으로 바뀝니다.

실제로 무엇이 잘못되는가

거의 모든 Drupal 마이그레이션에서 되풀이되는 실패 유형이 있습니다.

환경 사이의 설정 어긋남. 변경 사항이 설정 파일로 내보내지지 않고 운영 관리 화면에서 곧바로 이루어져 왔다면 스테이징 환경은 충실한 사본이 아니며 테스트의 값어치도 생각보다 낮습니다. 이것을 마이그레이션 도중에 발견하는 일은 흔하고 언제나 시간을 잡아먹습니다.

모두가 믿었던 것만큼 구조화되어 있지 않았던 콘텐츠. Drupal 7 사이트는 아무도 문서로 남기지 않은 방식으로 콘텐츠를 쌓아 온 경우가 잦습니다. 원래 용도와 다르게 돌려쓴 필드, 워크플로 상태 노릇을 하는 분류 체계, 인라인 스타일을 그대로 달고 본문 필드에 붙여넣은 HTML 같은 것들입니다. 마이그레이션은 그 모두를 한꺼번에 드러내고, 사례마다 그 콘텐츠가 무엇을 위한 것인지 아는 사람의 판단을 요구합니다.

미디어와 파일 처리. Drupal의 미디어 처리는 Drupal 7 이후 상당히 달라졌습니다. 파일과 이미지 스타일, 삽입된 미디어가 일대일로 대응하는 경우는 드물고, 미디어 자산이 많은 사이트라면 이 항목을 콘텐츠 이전에 딸려 온다고 여기지 말고 따로 예산을 잡아야 합니다.

URL과 검색 순위의 연속성. 일정이 아니라 사업 자체를 다치게 하는 항목입니다. URL 별칭이 리디렉션 없이 바뀌면 예전 사이트가 쌓아 온 검색 순위를 잃습니다. 모든 마이그레이션에는 전체 URL 목록과 리디렉션 대응표, 그리고 공개 후 검증이 필요합니다. 트래픽을 잃지 않고 사이트를 옮기는 방법 에 관한 저희 가이드가 그 절차를 자세히 다루며, 도메인 변경만큼이나 플랫폼 변경에도 그대로 적용됩니다.

다국어 콘텐츠. 사이트가 여러 언어로 운영된다면 마이그레이션이 훨씬 오래 걸린다고 보아야 합니다. 언어 처리는 Drupal 7 이후 새로 만들어졌고, 번역된 콘텐츠와 번역된 설정, 언어별 URL 규칙이 저마다 따로 손이 갑니다.

작업 순서를 어떻게 짤 것인가

순서는 대부분의 팀이 예상하는 것보다 훨씬 중요하고, 틀리면 다시 하는 일이 생깁니다.

기여 모듈과 사용자 정의 코드 점검부터 시작하십시오. 어떤 추정보다도 앞입니다. 그다음 사이트를 지원되는 PHP 버전과 현재 메이저 버전의 최신 릴리스로 올리십시오. 그것만으로도 실제 업그레이드 작업에서 잡음 한 무리가 사라집니다. 메이저 버전을 건너는 일은 그다음입니다.

제자리에서 갈아엎는 대신 새 환경을 옛 환경 옆에 세우십시오. 그러면 콘텐츠 이전을 여러 번 시험할 자리가 생깁니다. 그리고 그 자리는 반드시 필요합니다. 마이그레이션은 진짜로 한 번 실행되기 전에 여러 번 실행되기 때문입니다.

콘텐츠 이전을 코드처럼 다루십시오. Drupal의 마이그레이션 프레임워크는 이전 절차를 설정으로 정의하고 다시 실행할 수 있게 해 줍니다. 즉 되돌리고 매핑을 고쳐 다시 돌릴 수 있다는 뜻입니다. 이전 정의를 고치는 대신 새 사이트에서 콘텐츠를 손으로 고치는 팀은 결국 다시 실행할 수 없게 되고, 그때부터 옛 사이트의 콘텐츠 변경 하나가 수작업 대조 작업으로 변합니다.

마지막으로 막바지에 콘텐츠 동결 기간을 잡되 짧게 유지하십시오. 동결이 길어지면 편집자들이 우회로를 찾기 시작하고, 그러면 바로 그 피하려던 어긋남이 생깁니다.

아예 Drupal을 떠나야 할까요

정당한 질문이고 방어적인 답이 아니라 솔직한 답을 받을 자격이 있습니다.

Drupal을 고른 이유가 여전히 유효하다면 남으십시오. 복잡한 콘텐츠 모델링, 세밀한 권한 관리, 다국어 요구, 무거운 편집 워크플로, 또는 접근성과 공공 부문 의무 같은 것들입니다. Drupal은 이 모든 영역에서 실제로 강하고, 앞으로의 업그레이드 경로도 이 년마다 오는 메이저 릴리스라는 예측 가능한 형태로 안정되어 있습니다.

사이트가 그런 요구에서 멀어졌다면 옮기는 쪽을 고려하십시오. 적지 않은 Drupal 7 사이트가 지금은 사실상 소식란과 문의 양식이 있는 마케팅 사이트입니다. 그것을 Drupal 안에서 이전한다는 것은 더 이상 쓰지 않는 능력에 재구축 가격을 치르는 일입니다.

판단의 기준은 콘텐츠 모델과 편집 업무량이어야지 개발자가 선호하는 플랫폼이어서는 안 됩니다. 더 단순한 플랫폼이 하지 못할 무엇을 Drupal이 해 주고 있는지 아무도 말로 설명하지 못한다면, 그 자체가 하나의 답입니다.

견적을 받기 전에 점검부터 받으십시오

Mecanik은 Drupal 업그레이드와 마이그레이션을 웹사이트 개발 서비스 의 일부로 수행합니다. 저희는 기여 모듈과 사용자 정의 코드 점검에서 시작합니다. 그것이 끝이 보이지 않는 프로젝트를 확정된 범위로 바꿔 주기 때문이고, 그 뒤에 작업을 다른 곳에 맡기더라도 가지고 있을 값어치가 있기 때문입니다.

Drupal 10 사이트라면 모두가 몰리는 11월이 아니라 지금 Drupal 11로 가는 단계를 계획하는 것이 분별 있는 선택입니다. Drupal 7 사이트라면 보안 상태 자체가 이미 충분한 근거입니다. 제약이 실력이 아니라 인력이라면, Drupal 개발자 채용 에 관한 저희 가이드가 무엇을 봐야 하는지 설명합니다.

지금 어느 버전을 쓰고 있는지, 기여 모듈과 사용자 정의 모듈이 대략 몇 개인지 알려 주시면, 위의 경로 가운데 실제로 어느 쪽을 마주하고 있는지 말씀드리겠습니다.

관련 게시물: 레거시 PHP 현대화: 2026 가이드 , Symfony vs Laravel 2026: 어떤 PHP 프레임워크 , API 보안: 공개 API를 지키는 2026년 실전 가이드 , 영국 의료 및 헬스케어 웹사이트 개발 2026 .

자주 묻는 질문

Drupal 10 지원은 언제 끝나나요? Drupal 10은 2026년 12월 9일에 수명이 끝나며, 이는 Drupal 12가 출시되는 바로 그 주입니다. 그 날짜 이후에는 보안 수정을 포함해 어떤 릴리스도 나오지 않습니다. 따라서 그 버전에 남아 있는 사이트는 지원 없이 운영되는 상태가 됩니다.

Drupal 마이그레이션 비용은 얼마인가요? 잘 관리된 사이트에서 Drupal 10에서 11로 올리는 작업은 보통 6,000에서 15,000파운드가 듭니다. 모듈과 사용자 정의 코드가 방치되어 있으면 15,000에서 35,000파운드까지 올라갑니다. Drupal 7에서 Drupal 11은 콘텐츠 이전이 딸린 재구축이라 흔히 40,000에서 120,000파운드 또는 그 이상입니다.

왜 Drupal 7에서 Drupal 11이 훨씬 비싼가요? 그것이 업그레이드가 아니기 때문입니다. Drupal 8은 플랫폼을 Symfony 컴포넌트 위에 다시 지으면서 모듈 API와 테마 계층, 설정 시스템을 교체했습니다. 모듈은 교체하고 테마는 Twig로 다시 쓰고 사용자 정의 코드는 새로 구현해야 하며, 콘텐츠는 따로 만든 이전 절차로 옮겨 옵니다.

Drupal 10에서 11로 올리는 데 얼마나 걸리나요? 기여 모듈이 최신이고 사용자 정의 코드가 적은 사이트라면 이 주에서 사 주가 걸립니다. 버려진 모듈이나 제거된 API를 우회해야 한다면 사 주에서 팔 주로 늘어납니다. 추정을 믿을 만하게 만들어 주는 것은 미리 진행하는 기여 모듈 점검입니다.

대신 Drupal에서 WordPress로 옮겨도 되나요? 그것이 옳은 선택일 때도 있습니다. 특히 Drupal 7 사이트가 복잡한 콘텐츠 모델링이나 세밀한 권한, 다국어 요구가 없는 평범한 마케팅 사이트가 된 경우입니다. 판단은 플랫폼 선호가 아니라 콘텐츠 모델과 편집 업무량을 근거로 내리십시오.