페이지 빌더를 두고 의견이 갈리는 이유는 둘 다 사실이기 때문입니다. 빌더는 진짜로 유용하고, 동시에 진짜로 비용이 있습니다. 어느 한쪽만 말하는 조언은 결정에 도움이 안 됩니다.
빌더가 정말 잘하는 것
빌더의 핵심 가치는 하나입니다 — 개발자를 거치지 않고 페이지를 바꿀 수 있게 하는 것입니다. 이벤트 페이지의 문구를 오늘 바꿔야 하는데 담당자가 코드를 만질 수 없다면, 빌더는 그 일을 몇 분으로 줄입니다. 이것은 작은 가치가 아닙니다. 마케팅 담당자가 스스로 페이지를 만들 수 있느냐는 회사의 실행 속도를 직접 바꿉니다.
디자이너에게도 이점이 있습니다. 시안을 코드로 넘기기 전에 실제 콘텐츠로 배치를 시험해 볼 수 있고, 그 과정에서 발견하는 문제가 적지 않습니다.
대가 — 레이아웃이 데이터가 됩니다
빌더로 만든 화면은 파일이 아니라 데이터베이스에 저장됩니다. 3회차에서 본 “추가 CSS” 문제와 같은 계열인데, 규모가 훨씬 큽니다. 레이아웃 전체가 그렇게 됩니다.
가장 뒤늦게 드러나는 비용은 이관 가능성입니다. 빌더를 비활성화하면 그 페이지들은 대개 원래 모습으로 돌아가지 않습니다. 즉 빌더를 바꾸거나 걷어내는 일이 “설정 변경” 이 아니라 페이지를 다시 만드는 일이 됩니다. 페이지가 다섯 장일 때는 쉽고, 여든 장이 되면 사실상 불가능합니다.
디자인 일관성도 조용히 새어 나갑니다. 빌더는 편집자에게 색과 여백을 자유롭게 고를 자유를 주는데, 그 자유가 곧 여덟 종류의 회색과 열두 가지 여백이 됩니다. 이것은 편집자의 잘못이 아니라, 자유도가 높으면 반드시 생기는 결과입니다.
경계선을 그으면 둘 다 가질 수 있습니다
실무에서 가장 잘 작동하는 답은 “쓴다 / 안 쓴다” 가 아니라 어디까지 쓰는가입니다.
기준은 바뀌는 빈도와 소유자입니다. 사이트의 뼈대(헤더 · 푸터 · 공통 템플릿)는 자주 바뀌지 않고 디자이너와 개발자가 소유하므로 코드에 둡니다. 자주 바뀌고 마케팅 담당자가 소유하는 페이지는 빌더에 둡니다. 그러면 빌더를 걷어내야 할 때 잃는 것이 일부 페이지로 한정됩니다.
빌더를 쓰기로 했다면 한 가지를 정기적으로 확인합니다. 스테이징 사본에서 빌더를 잠시 비활성화하고 어느 페이지가 무너지는지 보는 것입니다. 그 목록이 곧 “이 플러그인에 묶여 있는 범위” 이고, 목록이 계속 늘고 있다면 경계선이 새고 있다는 뜻입니다.
빌더가 성능에 미치는 영향은 테마 · 플러그인 아카이브에서 더 다루고, 빌더로 만든 사이트를 유지하면서 속도와 보안을 정비하는 작업은 최적화 지원 사업에 포함됩니다.
다음 회차
마지막 회차는 테마 감사입니다. 테마가 실제로 무엇을 내려받고 있는지 재고, 안 쓰는 것을 안전하게 걷어내는 방법을 다룹니다.