블록 테마와 클래식 테마, 솔직한 비교
30초 만에 블록 테마와 클래식 테마를 구분하고, 편집자와 개발자가 각각 무엇을 치르는지 확인한 뒤, 전환할지 그대로 둘지 아니면 theme.json만 추가할지 결정하세요.
게시됨
테마 폴더를 열어보세요. 안에 index.html이 들어 있는 templates 디렉터리가 있고 루트에 theme.json이 있다면 블록 테마입니다. index.php가 header.php, footer.php 같은 파일과 함께 있고 관리자 사이드바에 외모 다음 사용자 정의하기가 보인다면 클래식 테마입니다.
이 구조적 차이 하나가 누가 사이트의 무엇을 바꿀 수 있는지, 그 변경이 어디에 저장되는지, 그리고 워드프레스 플러그인 생태계의 어느 쪽이 정상적으로 동작하는지를 결정합니다.
30초 만에 구분하기
| 신호 | 클래식 테마 | 블록 테마 |
|---|---|---|
| 루트 템플릿 파일 | index.php | templates/index.html |
| 헤더와 푸터 | header.php, footer.php | parts/header.html, parts/footer.html |
| 전역 설정 | functions.php | theme.json (선택적으로 functions.php도) |
| 관리자 메뉴 | 외모 > 사용자 정의하기 | 외모 > 편집기 |
| 편집 내용 저장 위치 | 디스크의 파일 | 데이터베이스, wp_template 글로 |
| 위젯 화면 | 있음 | 없음 |
워드프레스는 templates/index.html이 있는지를 보고 판단합니다. theme.json을 함께 배포하면서도 PHP 템플릿을 유지하는 테마는 여전히 클래식으로 취급됩니다. 이 중간 상태는 흔하고 이름도 있는데, 아래에서 다룹니다.
셸에 접근할 수 있다면 명령 한 줄로 끝납니다.
wp eval 'var_dump( wp_is_block_theme() );'
WP-CLI는 직접 만들지 않은 사이트를 확인할 때 가장 빠른 방법이며, 특히 페이지 빌더가 평소의 관리자 메뉴를 숨겨 놓은 경우에 유용합니다.
사이트를 편집하는 사람에게 달라지는 것
클래식 테마에서는 헤더, 푸터, 사이드바, 색상, 로고가 모두 사용자 정의하기 뒤에 있고, 테마 제작자가 만들기로 한 컨트롤만 쓸 수 있습니다. 푸터 저작권 문구에 대한 컨트롤을 등록하지 않았다면 그 컨트롤은 존재하지 않습니다. PHP 파일을 고치거나 그대로 감수하는 수밖에 없습니다.
블록 테마에서는 사이트 편집기가 페이지 전체를 열어줍니다. 헤더, 푸터, 반복문, 404 페이지, 검색 결과 레이아웃까지 전부 블록이고, PHP를 한 번도 본 적 없는 사람도 전부 편집할 수 있습니다. 이것이 진짜 핵심 기능이며, 그 크기는 결코 작지 않습니다.
대가는, PHP를 한 번도 본 적 없는 사람이 전부 편집할 수 있다는 바로 그 점입니다. 클라이언트가 새벽 2시에 헤더에서 사이트 제목을 지워버려도 복구할 디스크상의 버전 이력이 없습니다. 사이트 편집기 자체의 리비전뿐입니다. 블록 잠금과 편집기 접근 권한 제한으로 잠가둘 수는 있지만, 잊지 않고 챙겨야 하는 별도 작업입니다.
실무에서 아프게 다가오는 두 가지 손실이 더 있습니다. 블록 테마에는 위젯 화면이 없고(위젯 영역이 템플릿 파트와 블록으로 대체됩니다), 클래식 메뉴는 내비게이션 블록으로 대체되어 항목이 익숙한 메뉴 화면이 아니라 별도의 콘텐츠 타입으로 저장됩니다.
개발자에게 달라지는 것
클래식 테마는 PHP 템플릿 계층 구조를 씁니다. 워드프레스는 정해진 사슬을 따라 요청을 해석하고 — single-{post-type}.php, 다음 single.php, 다음 singular.php, 다음 index.php — 해당 파일이 실행되어 get_header()를 호출하고 The Loop를 돌린 뒤, 여러분이 글자 단위로 통제하는 마크업을 출력합니다.
<?php get_header(); ?>
<main class="site-main">
<?php while ( have_posts() ) : the_post(); ?>
<h1><?php the_title(); ?></h1>
<?php the_content(); ?>
<?php endwhile; ?>
</main>
<?php get_footer(); ?>
블록 테마는 같은 계층 구조 이름을 .html 확장자로 쓰지만, 파일 내용은 블록 마크업입니다. 주석 형태의 블록 구분자가 들어간 HTML이고, 템플릿 태그는 없습니다.
<!-- wp:template-part {"slug":"header","tagName":"header"} /-->
<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
<!-- wp:post-title {"level":1} /-->
<!-- wp:post-content /-->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->
개발자가 곧바로 부딪히는 결과가 세 가지 있습니다.
get_header()와 get_footer()는 아예 실행되지 않습니다. 플러그인이나 오래된 자식 테마에서 그 액션에 걸어둔 코드는 조용히 아무 일도 하지 않습니다. wp_head와 wp_footer는 여전히 실행되므로 대부분의 enqueue는 살아남지만, 헤더 전용 훅은 살아남지 못합니다.
데이터베이스가 파일을 이깁니다. 누군가 사이트 편집기에서 템플릿을 저장하는 순간, 워드프레스는 그 버전을 wp_template 글로 저장하고 여러분의 파일 대신 그것을 제공합니다. 오후 내내 HTML 파일을 고쳐도 프런트엔드에는 아무 변화가 없습니다. 해당 템플릿의 커스터마이징을 지우면 파일 버전이 다시 살아납니다. 이것이 “블록 테마가 고장 났어요” 신고의 압도적 1위이며, 버그가 아닙니다.
스타일링이 theme.json으로 옮겨갑니다. 색상, 여백 스케일, 타이포그래피, 블록별 기본값이 CSS가 아니라 데이터로 선언되고 CSS는 워드프레스가 생성합니다. 훨씬 깔끔하고 훨씬 일관됩니다. 스키마가 표현하지 못하는 것이 필요해지기 전까지는요. 그 순간부터는 결국 CSS를 쓰면서 생성된 규칙과 명시도 싸움을 하게 됩니다.
{
"version": 3,
"settings": {
"color": {
"palette": [
{ "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
]
}
}
}
version 값은 지금 쓰는 워드프레스 릴리스에 맞는지 꼭 확인하세요. 스키마는 한 번 이상 개정됐고, 오래된 튜토리얼에서 버전 번호를 그대로 복사하면 설정이 조용히 무시됩니다.
functions.php가 사라지는 것은 아닙니다. 블록 테마도 enqueue, add_image_size 등록, 커스텀 글 타입을 비롯한 PHP 작업에 여전히 이 파일을 씁니다. 다만 그 안에서 템플릿 작업을 훨씬 덜 할 뿐입니다.
실제로 얻는 것과 실제로 잃는 것
블록으로 가면 얻는 것: 페이지 전체에 대한 편집기 통제권, theme.json이 강제하는 디자인 일관성, 관리할 파일 수 감소, 그리고 클래식 테마가 해내지 못했던 수준으로 편집기와 프런트엔드가 일치하는 스타일.
블록으로 가면 잃는 것: 출력 마크업에 대한 직접 통제, 훅 기반의 간명한 커스터마이징, PHP 템플릿을 전제하는 모든 것과의 호환성, 그리고 사이트의 외형이 버전 관리 안에 있다는 안심.
마지막 항목은 강조할 만합니다. 클래식 테마에서는 git log가 무엇이 바뀌었는지 알려줍니다. 블록 테마에서는 사이트 외형의 상당 부분이 배포 파이프라인이 들여다보지 않는 데이터베이스에 있습니다.
클래식 테마가 여전히 정답인 경우
- 페이지 빌더가 사이트를 돌리고 있을 때. Elementor, Divi, Beaver Builder 같은 도구는 템플릿 작업을 스스로 가져갑니다. 그 아래에 블록 테마를 깔아봐야 아무 일도 하지 않는 두 번째 템플릿 시스템이 생길 뿐입니다.
- 마크업이 정확해야 할 때. 맞춤 컴포넌트 라이브러리, 엄격한 접근성 마크업, 특이한 스키마 요구사항 — 블록 출력은 블록이 내보내는 범위에 갇혀 있고, 그것과 싸우는 비용이 PHP를 쓰는 비용보다 큽니다.
- 플러그인 템플릿이 많을 때. 멤버십, LMS, 디렉터리, 오래된 커머스 확장은 PHP 템플릿 오버라이드를 함께 배포하는 경우가 잦습니다. 블록 대응물이 생긴 것도 많지만, 없는 것도 많습니다.
- 사이트가 이미 완성되어 잘 돌아갈 때. 5년치 커스터마이징이 쌓인 테마에는 블록으로 가는 업그레이드 경로가 없고 재구축만 있습니다. “이게 더 새로운 방식이니까”는 사업적 이유가 아닙니다.
- 여러분 말고는 아무도 편집하지 않을 때. 사이트 편집기의 주된 이점은 개발자가 아닌 사람에게 통제권을 넘기는 것입니다. 그런 사람이 없다면, 아무도 쓰지 않는 이점을 위해 비용만 치르는 셈입니다.
하이브리드라는 중간 지대
클래식 테마도 theme.json을 추가하면 전역 스타일 시스템, 색상과 여백 프리셋, 일관된 편집기 스타일을 얻을 수 있습니다. PHP 템플릿과 사용자 정의하기는 그대로 둔 채로요. 워드프레스는 이것을 블록 테마로 부르지 않고 사이트 편집기도 열리지 않지만, 디자인 시스템 이점의 대부분을 훨씬 적은 작업으로 가져갈 수 있습니다.
대체로 잘 돌아가는 기존 사이트라면 보통 이것이 옳은 첫 수입니다. theme.json을 추가하고, 팔레트와 여백을 정의하고, 그것이 대체하는 CSS를 지운 다음, 나머지까지 정말 원하는지 지켜보세요.
FAQ
질문
내 워드프레스 테마가 블록 테마인지 클래식 테마인지 어떻게 알 수 있나요?
테마 폴더를 열어보세요. 블록 테마에는 index.html이 들어 있는 templates 디렉터리가 있고, 루트에 theme.json이 있는 경우가 거의 대부분입니다. 클래식 테마에는 index.php와 header.php, footer.php 같은 PHP 템플릿 파일이 있습니다. 관리자 화면에서는 블록 테마가 외모 다음에 편집기를, 클래식 테마가 외모 다음에 사용자 정의하기를 보여줍니다.
블록 테마가 클래식 테마보다 나은가요?
항상 그렇지는 않습니다. 블록 테마는 개발자가 아닌 사람에게 페이지 구석구석에 대한 실질적인 통제권을 주고 많은 PHP 상용구를 없애줍니다. 클래식 테마는 개발자에게 마크업에 대한 정밀한 통제권을 주고 지금까지 쌓인 모든 플러그인, 페이지 빌더, 훅과 잘 맞습니다. 정답은 오픈 이후 누가 사이트를 편집하느냐에 달려 있습니다.
클래식 테마를 블록 테마로 변환할 수 있나요?
스위치 하나로 되는 일은 아닙니다. 변환은 모든 PHP 템플릿을 HTML 블록 마크업으로 다시 쓰고, 스타일을 theme.json으로 옮기고, 위젯 영역과 메뉴를 블록으로 대체하는 작업입니다. 커스터마이징이 많은 테마라면 이것은 이전이 아니라 재구축입니다. 클래식 테마에 theme.json을 더하는 하이브리드 방식이 보통 더 저렴한 첫걸음입니다.
사이트 편집기에서 편집한 뒤로 템플릿 파일 수정이 반영되지 않는 이유는 무엇인가요?
누군가 사이트 편집기에서 템플릿을 편집하는 순간, 워드프레스는 그 버전을 wp_template 글로 데이터베이스에 저장하며 디스크의 파일보다 데이터베이스 사본이 우선합니다. 해당 템플릿의 커스터마이징을 지우기 전까지 파일 수정은 무시됩니다. 거의 모든 개발자가 첫 블록 테마에서 이 지점에 놀랍니다.
클래식 테마가 지금의 워드프레스에서도 계속 동작하나요?
동작합니다. 클래식 테마는 완전히 지원되며 사용 중단 경고도 뜨지 않고, 지금까지와 똑같은 PHP 템플릿 계층 구조로 실행됩니다. 사용자 정의하기도 여전히 열립니다. 워드프레스 개발의 관심은 블록 테마 쪽으로 옮겨갔으니 새 편집기 기능은 그쪽에 먼저 도착하겠지만, 클래식 테마를 깨뜨릴 계획은 없습니다.