로 전환하려는 관심이 높아지고 있는 것을 보셨을 겁니다 Gutenberg 블록 편집기. 성능 개선과 Gutenberg의 지속적인 발전으로 인해 에이전시, 팀, 그리고 사이트 소유자들 사이에서 이러한 추세가 가속화되고 있습니다. Seahawk Media이미 수많은 Divi에서 Gutenberg로의 마이그레이션을 성공적으로 완료했습니다. 이 가이드에서는 전환의 필요성, 준비 사항, 전환 과정, 그리고 흔히 발생하는 오류에 대해 다룹니다.
요약: Divi에서 Gutenberg 블록 편집기로
- Divi 5는 기존 Divi 사이트에서 사용하던 단축 코드 아키텍처에서 벗어나면서 많은 팀들에게 자연스러운 이탈 지점이 되었습니다.
- 구텐베르크를 블록 테마와 함께 사용하면 훨씬 더 간결한 HTML을 출력할 수 있으며, 이는 코어 웹 바이탈 점수를.
- Divi 레이아웃 블록을 사용하면 한 번에 한 페이지씩 마이그레이션할 수 있으므로 전체 사이트를 한 번에 다시 구축할 필요가 없습니다.
- Divi의 모든 모듈은 블로그 모듈과 테마 빌더 템플릿에 이르기까지 Gutenberg에서 바로 사용할 수 있는 기능을 제공합니다. 소개글과 슬라이더부터 시작하여 모든 모듈에 해당합니다.
- 모든 URL을 변경하지 않고 서비스 출시 전에 스키마를 검증하면 전환 기간 동안 순위를 보호할 수 있습니다.
- 일반적으로 20~40페이지 규모의 마케팅 웹사이트는 마이그레이션 범위가 제대로 설정될 경우 1~3주 정도 소요됩니다.
많은 워드프레스 사이트들이 디비(Divi) 테마를 버리고 있는 이유는 무엇일까요?
이러한 변화의 시기는 우연이 아닙니다. Elegant Themes는 기존 사이트에 영향을 미치는 방식으로 Divi를 재구성했고, WordPress는 블록 편집기가 타사 빌더 없이도 대부분의 요구 사항을 처리할 수 있을 정도로 성숙해졌습니다.
Divi 5는 자체 아키텍처를 폐지했습니다
Elegant Themes는 Divi 5를 블록 형태의 저장 형식을 기반으로 재구축하고 이전 버전에서 사용했던 숏코드 시스템을 더 이상 사용하지 않습니다. 따라서 Divi 4 사이트를 운영하고 있다면 콘텐츠는 Divi 5에서 더 이상 기반으로 사용하지 않는 숏코드 마크업에 저장되어 있습니다.
Elegant Themes는 변환을 처리하기 위한 마이그레이터를 개발했지만, 그 과정 자체가 기존 아키텍처가 단계적으로 폐지되고 있음을 보여줍니다.
어차피 마이그레이션이 필요한 상황이라면, 구텐베르크 네이티브 블록으로 전환하는 것이 장기적으로 사이트에 더 유리한지 고려해 볼 가치가 있습니다.
구텐베르크가 그 격차를 좁혔습니다
WordPress 6.8은 블록 편집기, 6.9는 2025년 12월에 출시될 예정입니다. 이제 전체 사이트 편집, theme.json을 통한 전역 스타일, 템플릿 파트 및 쿼리 루프 레이아웃을 모두 기본적으로 사용할 수 있습니다.
과거에는 독점 빌더가 필수적이었던 기능 격차가 대부분의 마케팅 사이트와 콘텐츠 중심의 워드프레스 환경. 따라서 유료 타사 빌더를 고수해야 할 이유는 몇 년 전보다 훨씬 약해졌습니다.
혼란 없이 Divi에서 Gutenberg로 전환하기
페이지 빌더에서 워드프레스 블록 편집기로 마이그레이션하여 깔끔한 레이아웃, 향상된 성능, 그리고 SEO 손실 없는 환경을 구축할 수 있도록 도와드립니다.
구텐베르크로 전환하면 실제로 얻을 수 있는 이점은 무엇일까요?
Divi에서 Gutenberg로의 마이그레이션 관련 콘텐츠의 상당수는 과정에만 초점을 맞추고 결과는 완전히 건너뛰는 경우가 많습니다.
Seahawk Media의 경험에 따르면, 성능, 비용, 장기적인 유지 관리 용이성이라는 세 가지 영역에서 지속적으로 이점이 나타납니다.
측정 가능한 성능 향상
Divi는 실제로 사용되는 요소와 관계없이 모든 페이지에 자체 CSS 및 JavaScript 번들을 로드합니다. 이러한 오버헤드는 특히 Divi 모듈 라이브러리의 일부만 사용하는 페이지에서 빠르게 누적됩니다.
구텐베르크는 적절하게 구성된 블록 테마와 함께 사용하면 불필요한 페이로드를 제거합니다. 결과적으로 출력물이 더 간결해지며, 이는 Largest Contentful Paint, Cumulative Layout Shift 및 Interaction to Next Paint 점수를 직접적으로 향상시킵니다.
이러한 핵심 웹 바이탈은 사용자 경험과 검색 순위 모두에 영향을 미칩니다. Seahawk Media에서 진행한 모든 Divi-to-Gutenberg 마이그레이션에서 성능 향상은 일관적이고 측정 가능한 결과를 보여주었습니다.
라이선스 비용이나 계약 기간 제한 없음
Divi는 업데이트 및 지속적인 사용을 위해 Elegant Themes 멤버십이 필요합니다. Gutenberg는 WordPress 코어의 일부이므로 라이선스 비용이 없으며 상용 플랫폼의 가격 결정에 영향을 받지 않습니다.
네이티브 블록으로 전환하면 콘텐츠가 더 이상 독점 형식에 묶이지 않게 됩니다.
테마를 변경하거나 개발팀을 바꿔야 하는 경우에도 콘텐츠는 그대로 유지되며 모든 표준 WordPress 설정.
단 한 페이지도 펼쳐보기 전에 무엇을 먼저 정리해야 할까요?
준비 단계는 Divi 마이그레이션이 성공하거나 심각한 문제에 직면하는 결정적인 단계입니다.
기초 작업을 완료하기 전에 페이지 재구축을 서두르는 팀은 지연, 디자인 불일치 및 SEO 문제에 직면하게 되는데, 이는 충분히 피할 수 있는 문제입니다.
Seahawk Media에서는 마이그레이션 전 감사를 모든 프로젝트에서 필수적인 부분으로 간주합니다.
사이트를 백업하고 스테이징 환경을 구축하세요
파일과 데이터베이스를 포함한 전체 운영 사이트를 스테이징 환경 . 스테이징 환경은 운영 사이트의 완전한 작동 가능한 복사본이어야 합니다.
문제가 발생한 후가 아니라, 변경 작업을 시작하기 전에 롤백 프로세스가 제대로 작동하는지 확인하십시오.
Divi에서 Gutenberg로의 마이그레이션을 운영 사이트에서 직접 실행하지 마십시오. 프로젝트가 아무리 간단해 보이더라도 그 위험은 감수할 가치가 없습니다.
사용 중인 모든 레이아웃, 템플릿 및 모듈을 감사합니다
모든 페이지, 게시물, 사용자 정의 게시물 유형및 분류 체계를 검토하십시오. 헤더, 푸터, 아카이브 레이아웃 및 단일 게시물 템플릿을 포함한 모든 Divi 테마 빌더 템플릿을 문서화하십시오. 이러한 템플릿은 특별한 주의가 필요하며 초기 범위 설정 시 종종 간과됩니다.
모든 WooCommerce 템플릿, 글로벌 모듈, 슬라이더, 문의 양식 및 내장된 단축 코드를 기록해 두세요. 목록이 완벽할수록 프로젝트 중간에 예상치 못한 문제에 부딪힐 가능성이 줄어듭니다.
철저한 사전 조사로 시작하는 프로젝트는 작업이 이미 진행 중일 때까지 범위가 명확하지 않은 프로젝트보다 훨씬 적은 시간이 소요됩니다.
무엇을 다시 만들기 전에 디자인 시스템을 먼저 꺼내세요
페이지를 수정하기 전에 현재 사용 중인 색상 팔레트, 타이포그래피 크기, 간격 값 및 버튼 스타일을 기록해 두세요. 이러한 설정은 theme.json 파일에 직접 반영되어 Gutenberg가 모든 템플릿과 패턴에서 디자인 토큰에 전역적으로 접근할 수 있도록 해줍니다.
페이지 작업이 시작되기 전에 이 단계를 완료하면 마이그레이션하는 첫 페이지부터 마지막 페이지까지 재구축된 사이트의 시각적 일관성을 유지할 수 있습니다.
이를 건너뛰면 수십 페이지를 이미 재구축한 후에 수정하기 매우 번거로운 불일치가 발생합니다.
Divi 모듈과 Gutenberg 대체 모듈
대부분의 Divi에서 Gutenberg로의 마이그레이션 전에 흔히 제기되는 우려 사항 중 하나는 기본 블록 편집기가 Divi의 기능을 그대로 재현할 수 있는지 여부입니다.
거의 모든 경우에 답은 '예'입니다. 대체 요소는 작동 방식은 다르지만 동일한 기능을 수행합니다. 다음은 가장 일반적인 Divi 요소와 해당 Gutenberg 대체 요소에 대한 간략한 참조입니다.
| 디비 요소 | 구텐베르크 대체 | 메모 |
| 섹션/행/열 | 그룹/열/스택 | 그룹 및 열 블록 내에서 레이아웃 컨트롤과 간격 설정을 사용하세요 |
| 추천 광고 | 미디어 및 텍스트 또는 그룹 차단 | 한 번만 만들면 재사용 가능한 블록 패턴이 됩니다 |
| 단추 | 버튼 블록 | theme.json의 버튼 사전 설정에 스타일을 매핑합니다 |
| 이미지/갤러리 | 이미지/갤러리 | 대체 텍스트를 유지하고 네이티브 지연 로딩을 활성화합니다 |
| 슬라이더 | 패턴이나 간단한 슬라이더 플러그인을 사용하여 블록을 덮으세요 | 가능한 한 자바스크립트 슬라이더 사용을 피하십시오 |
| 문의 양식 | 블록 지원 기능을 갖춘 유지 관리형 폼 플러그인 | 확인 메시지, GDPR 고지 사항 및 스팸 방지 기능을 마이그레이션하세요 |
| 블로그 모듈 | 쿼리 루프 블록 | 쿼리 루프 템플릿 변형을 사용하여 카드 레이아웃을 다시 생성합니다 |
| 테마 빌더 헤더 및 푸터 | 블록 테마 템플릿 구성 요소 | 패턴을 사용하여 템플릿 및 부품 디렉토리로 이동합니다 |
사이트를 손상시키지 않고 Divi에서 Gutenberg로 마이그레이션하는 방법은 무엇인가요?
체계적인 프로세스를 따르면 마이그레이션의 모든 단계에서 예측 가능성과 되돌리기 기능을 유지할 수 있습니다.
Seahawk Media에서 Divi에서 Gutenberg로 마이그레이션을 처음부터 최종 서비스 출시까지 진행하는 과정을 아래에 설명합니다.
1단계: 콘텐츠 동결 및 스테이징 환경 잠금
페이지를 마이그레이션하기 전에 운영 중인 사이트의 콘텐츠 업데이트를 중지하고 모든 작업을 스테이징 환경으로 옮기세요.
스테이징 환경에서 마이그레이션이 진행되는 동안 편집자가 라이브 사이트에 계속 게시하면, 최종적으로 라이브 환경에서 해결하기 어려운 버전 차이가 발생할 수 있습니다. 빌드 중에 의도치 않은 크롤링을 방지하려면 스테이징 환경에서 유지 관리 모드를 활성화하세요.
2단계: 아무것도 만지기 전에 기준선을 기록하세요
실행하고 Lighthouse 및 Core Web Vitals 주요 랜딩 페이지 결과를 저장하세요. 이 수치는 마이그레이션 후 성능 개선 여부를 확인하기 위한 벤치마크가 됩니다.
기준점이 없으면 추측만 할 수밖에 없습니다. 주요 전환 경로와 사용자 흐름도 기록해 두면 QA 과정에서 검증할 수 있습니다.
3단계: 블록 테마 및 theme.json 파일 구성
WordPress 6.8 이상 버전을 사용 중인지 확인하세요. 블록 테마를 설치하고 추출한 디자인 토큰을 theme.json 파일에 매핑한 후 다시 빌드하세요.
색상, 글꼴, 간격, 버튼 스타일은 모두 여기에서 전역적으로 정의해야 합니다. 이러한 기본 설정은 재구축된 사이트의 시각적 일관성을 유지하고 향후 편집을 훨씬 쉽게 만들어 줍니다.
4단계: 위험도가 낮은 페이지에서 먼저 테스트하세요
원하는 마이그레이션 방식을 먼저 실행하세요 Divi 레이아웃 블록을 하거나 완전히 수동으로 재구축하는 등
사이트 전체에 적용하기 전에 출력 품질을 신중하게 평가하세요. 테스트 페이지에서 발견되는 문제는 50개 페이지를 재구축한 후에 발견되는 문제보다 훨씬 해결하기 쉽습니다.
5단계: 템플릿 부품 및 패턴 재구성
의 헤더, 푸터 및 아카이브 템플릿을 블록 테마 템플릿 파트로 변환합니다 Divi 테마 . 내비게이션, 사이트 로고, 검색 및 동적 콘텐츠가 모두 올바르게 표시되는지 확인합니다.
템플릿 구성 요소는 페이지 콘텐츠를 마이그레이션하기 전에 반드시 제대로 작동해야 합니다. 왜냐하면 다른 모든 요소는 템플릿 구성 요소가 안정적으로 렌더링되는 것에 달려 있기 때문입니다.
6단계: 서비스 출시 전 SEO 동등성 확인
Divi 사이트에 표시되었던 모든 URL을 정확히 그대로 유지하세요. 어떤 이유로든 슬러그가 변경되면 301 리디렉션을 즉시
페이지 재구축 후 샘플 페이지에 대해 Google의 리치 결과 테스트를 실행하고, 실제 전환을 예약하기 전에 Lighthouse 점수를 기준선과 비교하세요.
Divi 마이그레이션을 지연시키는 실수
Seahawk Media에서 진행한 작업에서 문제가 발생하는 마이그레이션은 공통적인 패턴을 보입니다. 이러한 문제는 거의 항상 예방 가능하며, 프로젝트 초기에 내려진 결정에서 비롯됩니다.
- 의 전체 목록을 작성하기 전에 페이지 재구축을 시작하는 팀은 단축 코드 프로젝트 도중에 예상치 못한 문제에 부딪히는 경우가 많습니다. 감사는 처음에는 시간이 오래 걸리는 것처럼 느껴지지만, 투자하는 비용보다 훨씬 더 많은 시간을 절약해 줍니다.
- 마이그레이션 플러그인이 모든 것을 처리한다고 생각하는 것도 흔한 오류 중 하나입니다. Automattic의 플러그인은 유용하지만 모든 Divi 모듈을 지원하는 것은 아닙니다.
- 복잡한 페이지의 출력 결과는 상당한 정리 작업이 필요한 경우가 많습니다. 플러그인을 실행하고 결과를 대충 훑어본 후 작업을 완료했다고 판단하는 팀은 Divi 마크업이 페이지에 남아 나중에 프런트엔드 문제를 일으키는 경우가 흔합니다.
마이그레이션 전에 성능 기준선을 기록하지 않으면 작업이 실제로 개선되었는지 입증할 방법이 없습니다. 이해관계자와 고객은 개선에 대한 증거를 기대합니다. 기준 수치가 없으면 이를 제공할 수 없습니다.
Divi에서 Gutenberg로의 마이그레이션은 실제로 얼마나 걸릴까요?
일반적인 마케팅 웹사이트(20~40페이지)의 경우, 디자인 시스템 설정, 페이지 재구축, 품질 보증 및 SEO 검증을 포함하여 1~3주 정도 소요됩니다.
WooCommerce 연동, 사용자 정의 게시물 유형 또는 수백 개의 페이지를 포함하는 사이트는 템플릿의 복잡성과 고유 레이아웃의 양에 따라 일반적으로 4~8주가 소요됩니다.
가장 큰 시간 변수는 마이그레이션 전 사전 감사 작업의 품질입니다. 콘텐츠 목록이 완벽하게 정리되어 있고 Divi 템플릿 문서가 잘 갖춰진 사이트는 작업 범위가 불분명한 프로젝트보다 마이그레이션 속도가 훨씬 빠릅니다. 사전에 사전 감사를 진행하는 것이 전체 일정을 단축하는 가장 효과적인 방법입니다.
Divi에서 벗어날 준비가 되셨나요? 제대로 시작해 봅시다!
Divi에서 Gutenberg로의 마이그레이션은 잘 계획하면 빠르게 효과를 볼 수 있는 결정 중 하나입니다.
더 빠른 로딩 속도, 깔끔한 마크업, 라이선스 비용 절감, 그리고 워드프레스 코어와 일관성을 유지하는 코드베이스는 모두 실질적이고 측정 가능한 결과입니다.
부터 QA 및 SEO 보호 조치에 이르기까지 전체 프로세스를 처리하므로 디자인 시스템 누락되는 부분이나 오류가 발생하지 않습니다.
새로운 단계로 나아갈 준비가 되셨다면 지금 바로 저희 팀에 연락하세요. 더욱 효율적이고 빠르면서도 내구성이 뛰어난 워드프레스 사이트를 구축해 드리겠습니다.
Divi에서 Guntenberg로의 전환에 대한 FAQ
WooCommerce 스토어를 Divi에서 Gutenberg로 안전하게 이전할 수 있을까요?
네, 하지만 제품 템플릿, 장바구니 및 결제 레이아웃, 그리고 사용 중인 Divi 전용 WooCommerce 모듈에 특히 주의를 기울여야 합니다. 이러한 각 항목은 마이그레이션 과정에서 개별적으로 검토해야 합니다.
구텐베르크를 사용하려면 새 테마가 필요한가요?
반드시 그런 것은 아니지만, theme.json 파일을 사용하는 블록 테마로 전환하면 전역 스타일을 완벽하게 제어하고 사이트 편집 기능을 완전히 활용할 수 있습니다. 기존 테마도 기술적으로는 작동하지만 템플릿과 패턴을 사용하는 데 제약이 있습니다.
Divi로 전환하면 기존에 사용하던 단축 코드는 어떻게 되나요?
Divi 숏코드는 Gutenberg에서 렌더링되지 않고, 일반 텍스트 또는 깨진 마크업으로 표시됩니다. 마이그레이션 과정에서 네이티브 블록을 사용하여 숏코드 기반 콘텐츠를 다시 빌드해야 합니다.
구텐베르크로 전환하면 검색 순위에 영향을 미칠까요?
마이그레이션이 올바르게 처리된다면 순위 하락은 발생하지 않습니다. 모든 URL을 변경하지 않고, 템플릿 유형별로 메타데이터를 검증하고, 스키마 마크업을 보존하면 전환 중 및 전환 후 순위 하락을 방지할 수 있습니다.
