Index
오랫동안 엘리멘터(Elementor), WP베이커리(WPBakery), 디비(Divi), 브릭스(Bricks)와 같은 워드프레스 페이지 빌더에 대해 부정적인 편이었습니다. 웹사이트를 제대로 만들기 위해서는 워드프레스의 구조와 HTML·CSS를 이해해야 하는데, 화면에서 요소를 끌어다 놓고 값을 입력하는 방식이 오히려 구조를 흐리게 만든다고 생각했기 때문입니다.
특히 페이지 빌더로 만들어진 웹사이트를 수정하는 일을 몇 차례 경험하면서 이런 생각은 더 강해졌습니다.
한 파트너 에이전시의 웹사이트를 수정하는 작업을 맡은 적이 있습니다. 해당 사이트는 그 회사의 대표가 직접 페이지 빌더를 이용해 운영하고 있었습니다. 디자인을 정리하고 몇 가지 기능을 추가하는 작업이었는데, 워드프레스 전문 에이전시를 운영하면서도 페이지 빌더 경험이 없던 저에게는 기존 구조를 파악하는 것부터 쉽지 않았습니다.
페이지마다 개별 스타일이 적용되어 있었고 공통 템플릿과 컴포넌트의 구분도 명확하지 않았습니다. 워드프레스 편집 화면과 페이지 빌더를 오가며 어떤 값이 어디에서 결정되는지 찾아야 했고, 결국 기존 구조를 이해해서 수정하기보다 커스텀 CSS를 계속 덧붙여 해결하는 경우가 많았습니다.
당시에는 이것을 페이지 빌더의 문제 또는 한계라고 생각했습니다.
그런데 최근 페이지 빌더를 이용해 규모가 다른 몇 개의 웹사이트를 처음부터 직접 구축하면서 생각이 조금 달라졌습니다. 첫 시작은 원해서 했던 것은 아니었고, 두 번째 부터는 직접 페이지 빌더를 권했습니다.
몇 차례 경험을 해보니 페이지 빌더 자체가 문제였던 것은 아니었습니다. 오히려 페이지 빌더를 이용하는 것이 프로젝트의 규모와 콘텐츠 구조, 운영 방식에 따라 꽤 효율적인 도구가 될 수도 있겠다 생각했습니다. 동시에 어느 시점부터 페이지 빌더가 관리하기 어려워지는지도 훨씬 명확하게 알게 되었습니다.
결국 중요한 것은 누가 어떤 프로젝트에, 어떤 방식으로 사용하는가의 문제였습니다.
페이지 빌더는 누구를 위한 도구일까?
페이지 빌더를 사용하면서 한 가지 궁금증이 생겼습니다. 페이지 빌더는 애초에 누구를 위한 도구일까요?
국내에서는 비교적 저렴한 비용으로 워드프레스 웹사이트를 제작하는 프리랜서나 소규모 제작사들이 페이지 빌더를 많이 사용하는 것으로 알고 있습니다. 정해진 예산과 기간 안에서 기업 소개 사이트나 소규모 웹사이트를 빠르게 만들어야 한다면 충분히 합리적인 선택입니다. 매번 커스텀 테마를 개발하는 것보다 이미 갖춰진 기능과 시각적인 편집 환경을 활용하는 편이 생산성 측면에서 유리할 수 있습니다.
직접 웹사이트를 만들고 싶어 하는 일반 사용자에게도 페이지 빌더는 매력적인 도구입니다. 마케터이면서 디자인 감각이 뛰어난 사람도 있고, 개발자는 아니지만 HTML과 CSS의 기본적인 원리를 이해하는 사람도 있습니다. 누군가에게는 직접 화면을 구성하고 하나씩 완성해가는 과정 자체가 재미있는 일이기도 합니다. 이런 사용자라면 페이지 빌더를 배우는 데 들어가는 시간도 비용이라기보다 자신의 업무 역량을 확장하는 과정으로 받아들일 수 있습니다.
웹사이트를 외부에서 제작하더라도 이후의 운영을 내부에서 담당해야 하는 조직도 있습니다. 별도의 개발자나 웹마스터는 없지만 마케팅팀이나 홍보팀, 디자인팀에서 웹사이트를 관리하는 경우입니다. 텍스트와 이미지만 변경하는 것을 넘어 새로운 섹션을 추가하거나 랜딩 페이지를 직접 만들어야 한다면 페이지 빌더가 제공하는 운영 자율성은 상당한 장점이 됩니다. 일정 수준의 학습만으로 제작사에 매번 요청하지 않고 직접 화면을 구성할 수 있기 때문입니다.
반대로 웹사이트의 규모가 커지고 조직이 전문화될수록 상황은 조금 달라집니다.
마케터는 콘텐츠와 캠페인을 기획하고, 디자이너는 디자인 시스템을 관리하며, 개발자는 이를 구현합니다. 웹사이트의 유지관리와 개발을 전문 외주사에 맡기는 기업도 많습니다. 이런 환경에서는 담당자가 직접 화면을 만드는 능력보다 각자의 역할에 집중하면서 웹사이트가 일관된 시스템 안에서 운영되는 것이 더 중요할 수 있습니다.
대규모 웹사이트에서는 작은 수정 하나를 쉽게 할 수 있다는 장점보다 수백 개의 콘텐츠와 여러 템플릿을 일관되게 관리하고, 변경 사항을 안전하게 배포하며, 장기간 유지보수할 수 있는 구조가 더 중요해집니다. 이 단계에서는 페이지 빌더의 자유도가 반드시 장점으로만 작용하지 않습니다.
페이지 빌더는 웹사이트를 정말 쉽게 만들어줄까?
사실 페이지 빌더가 낮춰준 것은 웹사이트 설계의 난이도라기보다 HTML과 CSS를 직접 작성해야 하는 진입장벽에 가깝습니다. 텍스트를 넣고 이미지를 배치하고 간격을 조절하는 일은 분명 쉬워졌습니다. 하지만 웹사이트를 제대로 구축하기 위해 필요한 질문들은 그대로 남아 있습니다.
어떤 콘텐츠를 일반 페이지로 만들고 어떤 콘텐츠를 포스트 타입으로 관리할 것인지, 분류 기준은 어떻게 설계할 것인지, 반복되는 화면은 어떤 템플릿으로 만들 것인지, 공통 UI는 어디까지 컴포넌트로 관리할 것인지 판단해야 합니다. 검색엔진이 콘텐츠를 제대로 이해할 수 있도록 제목과 링크, 정보 구조를 설계하는 일도 필요합니다.
페이지 빌더는 이런 결정을 대신해주지 않습니다.
레이아웃도 마찬가지입니다. 화면에서 몇 번의 클릭만으로 Flexbox나 Grid를 사용할 수 있지만, 부모와 자식 요소의 관계나 정렬 방식, 반응형 레이아웃의 원리를 이해하지 못하면 원하는 결과를 만들기 어렵습니다. CSS를 직접 작성하지 않아도 된다는 것과 CSS를 이해하지 않아도 된다는 것은 다른 이야기입니다.
무엇보다 페이지 빌더로 화면을 완성했다고 해서 웹사이트 구축이 끝나는 것도 아닙니다.
웹사이트를 공개하려면 도메인과 웹서버가 필요하고 DNS와 SSL을 설정해야 합니다. 워드프레스와 플러그인을 지속적으로 업데이트해야 하며, 백업과 복구 체계를 마련하고 적절한 보안 조치도 해야 합니다. 문의나 회원가입처럼 개인정보를 수집하는 기능이 있다면 개인정보 처리와 관련한 법적·기술적 조치도 필요합니다.
웹사이트가 느리다면 이미지와 폰트, 스크립트의 로딩 방식을 살펴봐야 하고, 검색 유입이 중요하다면 검색엔진이 사이트를 탐색하고 이해할 수 있도록 사이트 구조와 메타데이터, 구조화 데이터, 사이트맵 등도 관리해야 합니다. 접근성과 브라우저 호환성, 모바일 환경 역시 빼놓을 수 없습니다.
결국 페이지 빌더가 쉽게 만들어준 것은 웹사이트를 구성하는 수많은 작업 가운데 화면을 만드는 일부 과정이라고 보는 편이 더 정확합니다.
페이지 빌더를 사용하면 코드를 직접 작성하지 않고도 꽤 근사한 화면을 만들 수 있습니다. 하지만 그 화면을 관리 가능한 구조로 만들고, 안전하게 서비스하고, 검색될 수 있게 하고, 시간이 지나도 문제없이 운영하는 일은 여전히 별개의 전문성을 필요로 합니다.
페이지를 쉽게 만들 수 있게 된 것과 웹사이트를 쉽게 만들 수 있게 된 것은 같은 말이 아닙니다. 다시 말해 도구를 사용하는 것은 쉬워졌지만, 웹사이트를 설계하고 운영하는 일까지 쉬워진 것은 아닙니다.
전문 에이전시에게는 이런 장점이 있습니다.
직접 사용해보니 페이지 빌더는 웹사이트를 만드는 방법을 알려주는 도구라기보다 이미 웹사이트를 만드는 방법을 알고 있는 사람이 특정 작업을 더 빠르게 수행할 수 있도록 해주는 도구로 사용할 때 장점이 컸습니다.
최근 주로 사용한 Bricks는 개별 페이지의 콘텐츠만 편집하는 전통적인 페이지 빌더보다 사이트 빌더에 가까웠습니다. 헤더와 푸터부터 싱글·아카이브 템플릿, 동적 데이터, 쿼리와 반복되는 요소까지 구성할 수 있었습니다.
흥미로운 점은 이런 기능을 제대로 활용할수록 오히려 워드프레스의 포스트 타입, 템플릿, 쿼리와 콘텐츠 구조에 대한 이해가 중요해졌다는 것입니다.
디자인하면서 만드는 프로젝트에서는 페이지 빌더가 편했습니다
완성된 디자인을 정확하게 구현하는 것과 웹사이트를 만들면서 디자인까지 동시에 결정하는 것은 작업 방식이 다릅니다.
후자의 경우 요소를 배치하고, 간격을 조절하고, 크기를 변경하고, 다시 화면을 확인하는 과정이 계속 반복됩니다. 이런 탐색적인 작업에서는 페이지 빌더가 확실히 빨랐습니다.
코드를 작성하고 브라우저에서 확인하는 과정을 반복하는 것보다 화면 안에서 바로 조정할 수 있기 때문입니다.
페이지 빌더를 사용하면서 이 도구가 개발을 대신하는 것뿐 아니라 일종의 시각적 프로토타이핑 도구가 될 수도 있겠구나라는 생각을 하게 되었습니다.
전문 에이전시에게는 이런 점이 단점이 될 수 있습니다.
작은 기업 웹사이트에서는 페이지 빌더의 장점이 잘 드러났습니다. 페이지 수가 많지 않고 콘텐츠 구조가 단순하며 반복되는 템플릿도 제한적이라면 충분히 관리할 수 있었습니다. 빠르게 만들고 직접 디자인을 수정할 수 있다는 장점도 컸습니다.
하지만 규모가 커지고 콘텐츠 모델이 복잡해지면 상황이 달라졌습니다. 페이지와 템플릿이 많아지고 여러 콘텐츠 유형과 커스텀 필드가 연결되며 반복되는 컴포넌트가 늘어나면 디자인 시스템을 처음부터 제대로 설계하지 않았을 때 관리가 빠르게 복잡해집니다.
페이지 빌더로 만들 수 있는가와 페이지 빌더로 만드는 것이 적절한가는 다른 문제였습니다.
다국어 웹사이트라면 다시 생각해봐야 합니다
다국어가 추가되면 관리해야 할 콘텐츠의 양은 단순히 두 배, 세 배가 되는 것이 아닙니다. 언어별 페이지와 템플릿, 메타데이터, 내부 링크, 이미지와 구조화 데이터까지 함께 관리해야 합니다. 페이지 빌더 내부에 개별 콘텐츠와 스타일이 많이 들어가 있을수록 수정해야 할 접점도 많아집니다.
소규모 사이트에서는 충분히 감당할 수 있습니다. 하지만 콘텐츠 구조가 복잡하고 언어가 여러 개인 프로젝트라면 커스텀 테마가 오히려 더 단순하고 예측 가능한 선택이 될 수 있습니다.
그래서 다국어 사이트라면 단순히 “이 페이지 빌더가 다국어 플러그인을 지원하는가”만 볼 것이 아니라 장기간 콘텐츠와 템플릿을 어떻게 유지관리할 것인가까지 먼저 생각해야 합니다.
코딩과 페이지 빌더는 작업 방식 자체가 달랐습니다
페이지 빌더를 사용하면서 크게 느낀 차이 중 하나는 입력 방식이었습니다. 코드를 작성할 때는 하나의 화면에서 생각을 연속적으로 표현할 수 있습니다. CSS 클래스 하나를 만들고 필요한 속성을 한 번에 작성할 수 있습니다.
하지만 페이지 빌더에서는 요소를 선택하고, 레이아웃 패널을 열고, 값을 입력하고, 스타일 패널로 이동하고, 다시 반응형 설정으로 이동해야 합니다. 다른 요소를 수정하려면 다시 화면에서 해당 요소를 찾아야 합니다.
단순한 작업에서는 큰 차이가 없습니다. 하지만 작업량이 많아질수록 마우스로 UI를 탐색하는 시간도 무시하기 어렵습니다. 숙련된 개발자라면 어떤 작업에서는 직접 코딩하는 것이 훨씬 빠를 수 있습니다.
누가 웹사이트를 운영할 것인가도 중요합니다
개발자가 제작하고 이후에도 개발자가 모든 것을 관리하는 웹사이트라면 커스텀 테마의 효율성이 높을 수 있습니다. 하지만 웹사이트를 넘겨받은 기업의 담당자가 직접 운영해야 한다면 이야기가 달라집니다.
메인 화면의 섹션 순서를 바꾸고 싶거나, 새로운 영역을 추가하거나, 이미지와 텍스트뿐 아니라 화면의 구성 자체를 변경해야 할 수도 있습니다. 그때마다 개발자에게 요청해야 하는 사이트와 관리자가 직접 변경할 수 있는 사이트의 운영 경험은 분명 다릅니다.
페이지 빌더가 제공하는 시각적인 편집 환경은 이런 상황에서 상당한 장점이 됩니다.
물론 자유도를 어디까지 제공할 것인가는 또 다른 문제입니다. 운영자가 모든 디자인과 레이아웃을 자유롭게 변경할 수 있게 하는 것보다 제작자가 디자인 시스템과 템플릿, 컴포넌트를 먼저 만들어두고 운영자는 그 시스템 안에서 필요한 부분을 조정하도록 하는 방식이 더 안정적일 수 있습니다.
결국 페이지 빌더를 선택할 때는 제작자의 개발 효율뿐 아니라 누가 이 웹사이트를 만들고, 누가 앞으로 운영할 것인가도 함께 고려해야 합니다.
좋은 페이지 빌더와 좋은 선택은 같은 말이 아닙니다
Bricks나 Elementor 같은 페이지 빌더가 좋은 도구인지 아닌지를 판단하는 것과 그 도구가 지금 만들려는 웹사이트에 적합한지를 판단하는 것은 다른 문제입니다.
페이지 수가 많지 않고 빠른 제작과 시각적인 편집이 중요하거나, 운영자가 일정 범위에서 직접 화면을 수정해야 하는 프로젝트에서는 페이지 빌더가 좋은 선택일 수 있습니다. 반대로 콘텐츠 구조가 복잡하고 반복되는 템플릿이 많으며 다국어와 장기적인 확장까지 고려해야 하는 프로젝트라면 커스텀 테마가 더 적절할 수 있습니다.
좋은 페이지 빌더와 좋은 선택은 같은 말이 아닙니다.
최근에는 프로젝트를 시작하기도 전에 특정 페이지 빌더나 플러그인을 먼저 지정하는 경우를 종종 접합니다. 어떤 도구가 유명하다는 이유로 사용해야 하고, 누군가 추천했다는 이유로 특정 플러그인을 반드시 설치해야 한다고 생각하는 경우도 있습니다. 최근에는 AI가 추천한 기술 스택이 이러한 현상을 더 강하게 만들 수도 있겠다는 생각도 듭니다.
하지만 웹사이트는 유행하는 도구를 모아서 만드는 제품이 아닙니다. 먼저 어떤 콘텐츠가 필요한지, 어떤 구조로 관리할지, 누가 운영할지, 앞으로 얼마나 확장될지, 다국어가 필요한지 등을 결정해야 합니다. 목적과 콘텐츠, 구조와 운영 방식을 먼저 결정하고 그 조건을 가장 잘 해결하는 기술과 도구를 선택하는 것이 순서입니다.
결론
페이지 빌더를 직접 사용하면서 페이지 빌더에 대한 부정적인 생각은 많이 줄었습니다. 작은 웹사이트를 빠르게 만들거나 디자인과 개발을 동시에 진행해야 하는 프로젝트에서는 분명 효율적인 도구였습니다. 운영자가 직접 웹사이트의 일부를 관리해야 하는 경우에도 페이지 빌더의 시각적인 편집 환경은 분명한 장점이 있었습니다.
동시에 한계도 더 명확하게 알게 되었습니다.
사이트가 커질수록 콘텐츠 모델과 디자인 시스템, 템플릿과 컴포넌트 전략이 중요해졌고, 복잡한 콘텐츠 구조와 다국어까지 고려하면 커스텀 테마가 오히려 더 단순한 선택이 될 수도 있었습니다.
결국 중요한 것은 페이지 빌더를 쓰느냐 쓰지 않느냐가 아닙니다. 페이지 빌더를 선택하고 웹사이트를 설계하는 것이 아니라, 웹사이트를 먼저 설계한 뒤 페이지 빌더가 적합한지를 판단해야 합니다.
Index