모든 WordPress 사이트를 다시 구축하지 마세요

요약

대부분의 에이전시는 모든 WordPress 사이트를 빈 테마에서 구축합니다. 공유 기반을 사용하면 일정에서 몇 주를 줄일 수 있는데도 말이죠. 이 글은 theme.json, 블록 패턴, 동적 블록을 사용하면 각 고객의 독특한 디자인을 유지하면서 구조적 계층을 표준화할 수 있다고 주장합니다. 이 글은 팀이 변화를 망설이게 만드는 다섯 가지 반론을 직접 다룹니다: “고객이 다르다”, “사용자 정의 블록은 비싸다”, “편집기가 혼란스럽다”, “훅과 필터를 잃게 된다”, “FSE는 프로덕션 준비가 안 되었다”. 각 반론에 실용적인 반박과 점진적으로 채택할 수 있는 구체적인 패턴을 제시합니다. 그 결과는 맞춤 작업이 필요한 곳에서는 여전히 존중하는 반복 가능한 구축 프로세스입니다. 경고: 원클릭 리셋 버튼은 약속하지 않습니다.

고객 사이트 중 단 한 줄의 코드라도 공유하는 사이트가 얼마나 되나요? 저작권 줄이 아니라 실제 코드 말입니다. 답이 “거의 없다”라면 이미 그 고통을 느끼고 있을 것입니다: 같은 히어로 섹션을 아홉 번째 다시 구축하고, 같은 팀 그리드 마크업을 프로젝트마다 복사하고, 같은 전처리 조정을 반같은 테마에서 참조하고. 또한 “모든 고객은 다른 필요를 가진다”는 변명을 들어봤을 것입니다. 맞습니다. 하지만 모든 사람이 내리는 결론—모든 사이트가 맞춤 기반을 필요로 한다는—은 틀렸습니다. WordPress 생태계는 이제 디자인을 표준화하지 않고 구조적 부분을 표준화할 수 있는 방법을 제공합니다: 디자인 토큰을 위한 theme.json, 반복 레이아웃을 위한 블록 패턴, 실제 서버 측 로직이 필요한 소수의 기능을 위한 동적 블록. 이 글은 에이전시가 그 단계를 밟지 못하게 하는 반론과, 그에 맞서 밀어붙일 때 실제로 효과가 있는 것에 관한 것입니다.

“하지만 모든 고객은 다르다”는 반론

기본 원칙: 표면이 아니라 기반을 표준화하라. 구조를 공유 라이브러리에 유지하는 이유는 정확히 시각적 계층을 자유롭게 남겨두기 위해서입니다. theme.json 파일은 디자인이 아니라 디자인 토큰의 집합입니다. 색상, 간격, 타이포그래피는 마크업이 아닌 값입니다. 이것이 중요한 전환점입니다: 사이트별 theme.json이 다른 브랜드에 대해 완전히 다른 모습을 만들면서도 마크업을 공유할 수 있습니다.

두 고객을 예로 들어보죠: 로펌과 아웃도어 소매업체. 그들의 디자인 언어는 완전히 다릅니다. 하지만 둘 다 히어로 섹션, 추천사 그리드, 콜투액션 밴드가 필요합니다. 각각의 마크업을 다시 구축하는 대신 세 개의 블록 패턴을 유지하고 각 고객의 theme.json이 색상, 글꼴, 간격을 정의하게 하세요. 구조는 동일하게 유지되고, 디자인 토큰이 한 브랜드에서 다른 브랜드로 바꿔줍니다. 소매업체가 다음 봄에 색상 팔레트를 변경하면 그들의 사이트에서 파일 하나만 편집하면 됩니다—여섯 개 템플릿의 마크업이 아니라.

실용적으로, 이는 팀이 패턴을 코드로 만들고 공유 플러그인에 등록하며 각 고객 사이트의 theme.json이 페인트를 처리하게 하는 것을 의미합니다. 패턴의 클래스 이름이 아키텍처가 되고 값이 변수가 됩니다. 더 나아가 theme.json을 확장하여 사용자 정의 콘텐츠 유형이나 플러그인 출력을 위한 사용자 지정 설정을 포함할 수도 있습니다. 다만 어느 시점에 이르면 사이트 대신 구성 인터페이스를 구축하게 되는—theme.json 확장에 대한 글에서 다루는 함정—에 빠질 수 있습니다. 공유 계층을 가볍게 유지하세요: 클라이언트 간에 반복되는 것만 포함해야 합니다. “언젠가 누군가 원할 수도 있어서” 설정을 추가하고 있다면, 유지 비용이 절약보다 더 많이 드는 추상화를 만든 것입니다.

새 고객을 설정할 때 처음 30분은: 공유 패턴 플러그인을 복제하고, 고객의 팔레트와 글꼴 배율로 새 theme.json을 만들고, 로고와 바닥글을 등록하는 것입니다. 그것은 맞춤 구축이 아니라 구성 작업입니다. 나머지 고객별 작업은 콘텐츠, 구조, 그리고 진정한 맞춤 기능에 들어갑니다. 이는 모든 집을 처음부터 짓는 것과 다시 칠하고 벽지를 바꿀 수 있는 조립식 평면도 세트를 갖는 것의 차이입니다. 비유는 느슨하지만 원칙은 유효합니다: theme.json 값으로 더 많이 밀어넣을수록 마크업을 덜 건드리게 됩니다.

가장 간단한 승리 중 하나는 블록 패턴이 어떻게 작동하는지 실제로 보는 것입니다. 패턴은 사전 정의된 콘텐츠와 스타일이 있는 블록 모음일 뿐입니다. 어떤 블록 구성이든 패턴으로 저장할 수 있으며, 클라이언트는 어떻게 구축되었는지 알 필요 없이 삽입할 수 있습니다. 즉, 패턴은 비기술적 사용자를 위한 “진입점”이 됩니다. 팀이 코드에서 기본 패턴을 유지하면 클라이언트는 PHP 태그 하나 건드리지 않고 일관된 라이브러리를 얻습니다.

그런데 제가 계속 강조하는 경고: 지나치게 중앙화하지 마세요. 상상할 수 있는 모든 뉘앙스에 대한 설정이 있는 theme.json은 유지 관리의 늪입니다. 공유 패턴은 전지전능한 방향이 아니라 명확한 의견을 가져야 합니다. 클라이언트가 크게 다른 레이아웃을 필요로 한다면—예를 들어 큰 추천 그리드가 있는 매거진 홈페이지—표준 패턴 라이브러리에 맞지 않을 수 있습니다. 괜찮습니다. 표준화는 비슷한 80%의 프로젝트에서 이기는 것이지, 모든 사이트를 같은 틀에 강제로 넣는 것이 아닙니다.

“사용자 정의 블록이 예산을 초과한다”는 반론

지루해 보이지만 비용을 절약하는 반대 원칙이 있습니다: 사용자 정의 블록이 필요하다고 생각하는 대부분은 그렇지 않습니다. 코어 블록과 패턴만으로도 대부분의 레이아웃을 충당할 수 있습니다. 사용자 정의 블록은 마지막 수단이지 첫 번째 의도가 아닙니다.

전형적인 예는 팀 그리드입니다. 일회성이라면 코어 “열”과 “그룹” 블록을 사용하고 클라이언트가 아바타를 직접 넣게 하세요. 같은 “이름 아래 소셜 링크” 구조를 가진 같은 그리드를 세 고객이 요청한다면, 이제 블록 패턴의 후보입니다. 그 패턴에 새로운 옵션—호버 효과, 정렬, 별점—이 추가되기 시작하면 패턴은 관리할 수 없는 잡동사니가 되고, 그때 맞춤 블록을 작성할 때입니다. 예산을 해치는 실수는 첫 요청에 바로 맞춤 블록으로 뛰어드는 것입니다.

더 교묘한 시나리오: 클라이언트가 “사례 연구 캐러셀”을 요청합니다. 첫 번째 직관은 “캐러셀 블록이 필요해”라고 생각하는 것입니다. 하지만 정말 캐러셀이 필요한가요? 아마도 가로로 스크롤할 수 있는 게시물 그룹이 필요할 수도 있는데, 코어 블록과 약간의 CSS만으로 처리할 수 있습니다. 또는 최근 사례 연구의 동적 목록이 필요할 수도 있는데, 이는 CPT를 쿼리하는 동적 블록입니다. 질문은 “클라이언트가 원하는 기능은 무엇인가?”가 아니라 “그것이 의존하는 데이터는 무엇인가?”입니다. 데이터가 정적이고 클라이언트가 편집할 수 있다면 패턴으로 충분합니다. 데이터가 데이터베이스 쿼리에서 온다면 동적 블록이 정당합니다. 데이터가 API에서 실시간으로 업데이트되어야 한다면 REST API 통합을 고려해야 할 수도 있습니다—그것은 다른 종류의 구축으로 넘어갑니다.

실제로 블록을 만들 때 block.json은 당신의 친구입니다. 속성, 스크립트, 스타일에 대한 단일 진실 공급원이며 블록을 프로젝트 간에 이식 가능하게 만듭니다. 또한 종속성과 번역을 깔끔하게 선언할 수 있게 해줍니다. 이는 많은 고객 사이트에 라이브러리를 배포할 때 필수적입니다. 실시간 데이터에 의존하는 콘텐츠의 경우 동적 블록이 서버에서 렌더링되므로 페이지 뷰마다 JavaScript 번들을 제공할 필요가 없습니다. 그리고 블록이 발전하면 deprecation을 우아하게 처리하여 기존 콘텐츠가 깨지지 않게 할 수 있습니다—블록 deprecation 가이드가 정확한 패턴을 안내합니다.

무엇이든 구축하기 전에 이 그리드로 결정을 검토하세요:

접근 방식	가장 적합한 경우	피해야 할 경우
코어 블록	일회성 콘텐츠, 단순한 페이지	레이아웃이 많은 클라이언트에서 반복되고 풍부한 옵션이 필요함
블록 패턴	로직이 없는 반복 가능한 레이아웃	레이아웃에 조건문, 동적 데이터 또는 복잡한 상호작용이 필요함
사용자 정의 블록	반복적이거나 데이터 기반 또는 매우 특정한 동작	유일한 이유가 클래스로 처리할 수 있는 일회성 섹션인 경우

또한 첫날부터 블록 이름에 대해 생각해야 합니다. 블록 이름은 본질적으로 콘텐츠와의 계약입니다. wagent/team-grid로 부르고 나중에 wagent/team-carousel로 이름을 바꾸면 deprecation 경로를 제공하지 않는 한 기존 콘텐츠가 깨집니다. 블록이 진화함에 따라 거짓 광고가 되지 않는 일반적이고 목적 기반의 이름을 선택하세요. 이것은 플러그인 접두사에서 모두 배운 명명 규율의 일종이며 블록 이름에도 그대로 적용됩니다.

여기서 반대 관점이 가장 유용한 말일 수 있습니다: 클라이언트가 “딱 하나만” 요청해서 만든 맞춤 블록은 거의 항상 실수입니다. 정중하게 거절하고, 클래스가 있는 코어 블록을 제공하고, 시간을 아끼세요. 클라이언트로부터 더 많은 존경을 받을 것이고—유지 보수 예산에서도 더 작은 항목이 됩니다.

“클라이언트가 편집기를 망가뜨릴 것”이라는 반론

이 반론은 반만 맞습니다. 블록 편집기 자체가 문제가 아니라, 클라이언트에게 너무 많은 자유를 주는 것이 문제입니다. theme.json은 편집 가능한 것을 제한할 수 있습니다: 템플릿 편집기를 비활성화하고 허용된 블록을 제한하며 기본 스타일을 설정하여 잘못 배치된 열이 덜 피해를 주게 할 수 있습니다. 여전히 일부 클라이언트는 망가뜨릴 수 있지만, 저장된 패턴으로 페이지를 클릭 한 번에 되돌릴 수 있습니다—고전적인 편집기는 제공할 수 없었던 기능입니다.

시나리오를 그려보겠습니다. 클라이언트가 전화하여 “섹션을 옮겼는데 이제 페이지 전체가 잘못 보입니다”라고 말합니다. 클래식 테마라면 로그인하여 CSS를 조사하고 아마 한 시간 동안 레이아웃을 고치는 데 쓸 것입니다. 블록 설정에서는 페이지를 열고 콘텐츠 영역을 선택한 후 저장된 패턴으로 재설정할 수 있습니다. 패턴이 기준선이고 클라이언트의 변경 사항은 오버레이입니다. 오버레이가 잘못되면 제거하면 됩니다. 이는 더 나은 워크플로우일 뿐만 아니라 근본적으로 더 관대한 편집기입니다.

이제 미묘한 점: 대부분의 클라이언트는 많이 편집하고 싶어 하지 않습니다. 텍스트를 변경하고, 사진을 바꾸고, 섹션을 재정렬하고 싶어 합니다. 블록 패턴은 전체 사이트 구조를 노출하지 않으면서 정확히 그 기능을 제공합니다. 이러한 의미에서 편집기는 장난감이 아니라 뷰파인더입니다. 당신의 일은 클라이언트가 볼 수 있는 것을 조정하는 것입니다. 즉, “템플릿” 설정을 비활성화하고, 블록 삽입기를 선별된 목록으로 제한하며, 빈 패턴에 placeholder 작업을 미리 채울 수도 있습니다. 편집기는 웹 디자인 캔버스가 아니라 콘텐츠 입력 양식이 됩니다.

접근성 측면에서 블록 편집기의 초점 관리와 키보드 지원은 일반적으로 클래식 편집기의 템플릿 필드보다 낫습니다. 하지만 패턴에 적절한 제목 계층과 접근 가능한 이름이 있는지 여전히 확인해야 합니다. 패턴이 클라이언트 간에 공유되므로 이러한 문제를 한 번만 수정하면 되며, 이는 표준화의 또 다른 숨은 이점입니다.

진짜 어려운 부분은 내부적입니다. 팀이 블록으로 프로토타입을 배우는 것은 “PHP로 처리” 습관을 잊어야 합니다. 그것은 실제 비용이지만 사람당 일회성 비용입니다. 접근 방식을 피할 이유가 아니라 모든 곳에 적용하기 전에 하나의 패턴 라이브러리와 한 명의 관대한 클라이언트로 시작할 이유입니다. “내 클라이언트는 블록을 다룰 수 없어”라는 말이 절반만 맞다는 사실을 숨기지 마세요—아직 그들을 위해 블록 설정을 구성하지 않았을 뿐입니다.

“우리는 이미 훅과 필터를 가지고 있다”는 반론

여기서 원칙은: 훅을 버리는 것이 아니라 그 위에 레이어를 추가하는 것입니다. 블록은 표현 경계이고, 훅은 여전히 로직을 주입하는 방법입니다. 동적 블록의 렌더 콜백은 PHP에서 실행되므로 이미 신뢰하는 동일한 함수를 호출하고 동일한 필터를 적용할 수 있습니다.

필터를 사용하여 모든 게시물에 “추천 제품” 필드를 추가할 수 있는 플러그인을 상상해 보세요. 동적 블록을 사용하면 그 필터를 실행하고 출력을 블록 래퍼 안에 출력하는 서버 렌더링 블록을 포함할 수 있습니다. 클라이언트는 블록을 삽입하고, 기존 PHP 로직이 무거운 작업을 수행합니다. 아무것도 버려지지 않습니다. 더 구체적인 예로, 최근 프로젝트 게시물을 나열하는 사용자 정의 블록을 생각해 보세요. 렌더 콜백에서 get_posts()를 호출하고 루프하여 the_title() 및 the_permalink()를 적용합니다—수년간 사용해 온 동일한 템플릿 태그입니다.

또한 이것은 무엇이 전환되지 않는지에 대해 솔직해질 자리입니다. 일부 영리한 기존 테마는 페이지 컨텍스트에 따라 인수를 받는 복잡한 조건문을 가진 template-parts를 사용합니다. 그것을 블록으로 재창조하는 것은 지저분할 수 있습니다. 하지만 모든 것을 한 번에 재창조할 필요는 없습니다. 점진적인 경로는 PHP 로직을 유지하고, 동적 블록으로 감싸고, 마크업을 블록 템플릿으로 옮기는 것입니다. 기존 필터 패턴이 새 출력을 처리할 수 있는 경우가 많습니다. 그리고 로직이 템플릿 계층에 밀접하게 묶여 있다면(예: “검색 결과에서는 다르게 표시”), 특정 보기에 대해 클래식 템플릿을 계속 사용하면서 일반 페이지에는 블록을 사용할 수 있습니다.

또한 REST API는 다른 문을 열어줍니다: 다른 WordPress 사이트나 타사 서비스에서 데이터를 가져오는 블록을 구축할 수 있습니다. 동적 블록은 wp_remote_get()을 호출하여 JSON을 가져오고 프런트 엔드에서 렌더링할 수 있습니다. 이는 클라이언트가 별도의 통합을 관리하지 않고 소셜 피드, 제품 목록 또는 내부 데이터를 표시하려는 에이전시 구축에 강력한 패턴입니다. 트레이드오프는 캐싱과 오류 처리입니다—원격 API가 느리면 페이지가 느립니다. API 기반 블록을 중요한 최상단 콘텐츠에서 멀리 두거나 적절한 로딩 상태와 함께 클라이언트 측 렌더링을 사용하세요.

액션과 필터는 저장 및 렌더링 주변에서 계속 실행됩니다. 블록을 채택해도 훅 아키텍처는 사라지지 않고 새로운 컨텍스트로 이동할 뿐입니다. 액션과 필터가 새로운 블록 세계와 만나는 지점을 다시 이해해야 한다면 훅 딥 다이브가 유용한 참고 자료가 될 것입니다.

“FSE는 프로덕션 준비가 안 되었다”는 반론

충분히 인정합니다. 하지만 “위험”이 실제로 무엇을 의미하는지 물어보세요. Full Site Editing은 여러 릴리스를 거쳤고 theme.json은 안정적인 스키마로 자리 잡았습니다. 위험은 편집기가 “갑자기 고장 나는” 것이 아니라, 팀의 사용자 정의 코드가 블록 템플릿과 어색하게 공존하는 구식 PHP 템플릿에 의존할 수 있다는 것입니다. 또한 일부 타사 플러그인은 여전히 클래식 편집기나 커스터마이저를 가정합니다. 그것은 호환성 결정이지 전체 모델을 버릴 이유가 아닙니다.

유용한 사고 방식: 블록으로 작성된 콘텐츠가 있는 단순하고 반복 가능한 사이트가 가장 위험이 적습니다. 위험이 높은 클라이언트는 깊게 맞춤화된 클래식 테마나 자체 프런트 엔드를 렌더링하는 독점 플러그인을 가진 경우입니다. 그 작은 틈새에 클래식 테마를 고수하는 것은 정당한 이유입니다. 오류는 “프로덕션 준비”가 켜짐/꺼짐의 단일 스위치라고 가정하는 것입니다.

클라이언트에게 블록 테마를 제안하기 전에 빠른 체크리스트를 확인하세요:

• 클라이언트가 마이그레이션이 필요한 심하게 맞춤화된 테마를 가지고 있습니까?
• 필수 플러그인이 사이트 편집기와 REST API를 지원합니까?
• 호스팅 환경이 블록 테마가 기대하는 파일 액세스를 허용합니까?
• 블록 등록뿐만 아니라 패턴 디자인을 위한 시간을 확보했습니까?
• 클라이언트의 팀이 편집기 변경을 수용할 수 있습니까, 아니면 잠긴 템플릿이 필요합니까?

하나라도 아니요라면 범위를 조정하거나 하이브리드 접근 방식을 사용하세요. 그것은 타협이 아니라 엔지니어링 판단입니다. 하이브리드를 구축하는 경우 위의 훅과 필터 이야기를 기억하세요—theme.json이 전체적인 모양을 처리하는 동안 여전히 이전 로직을 동적 블록으로 감쌀 수 있습니다.

theme.json 버전 관리는 이론적인 문제만이 아닙니다. 클라이언트가 WordPress를 업데이트했을 때 에이전시의 맞춤 블록 라이브러리가 손상되는 것을 본 적이 있습니다. 블록의 style 파일이 변경된 핸들로 wp_register_style()에 등록되었기 때문입니다. 수정은 쉬웠지만 패닉은 실제였습니다. 간단한 테스트 프로세스—스테이징 사이트에서 업데이트를 실행하고 주요 페이지를 클릭한 후 릴리스—대부분의 예상치 못한 문제를 해결합니다.

당신이 스스로 하지 않은 반론

에이전시가 표준화를 망설이게 만드는 메타 반론이 있습니다: “그것은 큰 변화이고 클라이언트 작업 중에 할 시간이 없다.” 맞습니다—그러니 클라이언트 작업 중에 하지 마세요. 내부 프로젝트나 소규모 클라이언트를 선택하고 패턴 라이브러리 하나를 구축하세요. theme.json을 디자인 토큰 시스템으로 사용하세요. 정당한 경우에만 사용자 정의 블록을 추가하세요. 도움이 되는 곳에 기존 훅을 감싸세요. 반복하세요.

대략적인 첫 30일:

1. 지난 5개의 클라이언트 구축을 감사하고 가장 반복되는 레이아웃 요소 10개를 나열하세요.
2. 그 10개를 소수의 CSS 클래스와 함께 블록 패턴으로 전환하세요.
3. 해당 패턴을 등록하는 공유 플러그인(또는 mu-plugin)을 구축하세요. 이에 대한 플러그인 구성을 생각해 보지 않았다면 먼저 강력한 WordPress 플러그인 구축 가이드를 훑어보세요.
4. 기준 디자인과 일치하는 theme.json 하나를 만드세요. 프로젝트를 시작하면서 클라이언트별 값을 추가하세요.
5. 작은 내부 프로젝트 또는 친근한 클라이언트 하나를 선택하여 그 스택으로 마이그레이션하세요.
6. 전화하지 않고 홈페이지를 직접 편집한 클라이언트의 성공 사례 하나를 문서화하세요.

그 실험을 끝내면 벽에 걸 “블록 우선” 배지를 얻지는 못할 것입니다. 공유 기준에서 새 클라이언트 사이트를 일정에 대해 사과하지 않고 만들 수 있는 팀을 얻게 됩니다. 또한 클라이언트의 42번째 맞춤 블록 요청에 “아니요”라고 말할 수 있는 더 나은 위치에 있게 됩니다—코어 블록이 무엇을 할 수 있는지 정확히 알기 때문이거나, 동적 블록이 진정으로 더 빠를 것이라는 이유를 보여줄 수 있기 때문입니다.

여전히 일부 맞춤 사이트를 구축할 것인가요? 그렇습니다. 일부 클라이언트는 항상 사용자 정의 템플릿, 맞춤 페이지 또는 공유 모델에 강제로 넣을 가치가 없는 독점 통합이 필요할 것입니다. 목표는 맞춤 작업을 제거하는 것이 아니라 기본값이 아닌 예외로 만드는 것입니다.

반복성은 지루한 부분에서 나옵니다: 견고한 theme.json 스키마, 명확한 패턴 라이브러리, 공유 계층을 가볍게 유지하는 규율. 그것은 웨비나에서 듣는 반짝이는 버전이 아닙니다. 월요일 아침의 빈 테마 우울함을 이기는 버전입니다.