brunch

You can make anything
by writing

C.S.Lewis

by oksambari Sep 30. 2022

워드프레스를 CMS로만 쓴다?

워드프레스 & Frontity

워드프레스 사이트 제작 시에는 쇼핑몰이 아닌 이상 대개 템플릿을 수정 또는 제작하거나, 콘텐츠를 불러다 표시하는 워드프레스의 루프(loop)를 작성하는 부분들이 주를 이룹니다. 여기에 디자인대로 표시하기 위한 퍼블리싱 작업이 이어지게 되고요. 저는 좋은 테마를 알게 된 후부터는 개발 관련 부분은 거의 해결이 되어서 최근에는 효과를 위한 퍼블리싱을 어떻게 더 잘할지 미리 고민을 해 보는 게 주된 일이었던 것 같습니다. 작업이 빠르고 간편해진 대신 그간 시간을 들여 쌓아 온 경험들이 약간 허무해지기도 하더라고요. 


이런 상황에 뭔가 다시 시간을 내어서 알아보고 싶은 게 하나 생겼습니다. 바로 이번 글의 주제인 Headless Wordpress입니다. (워드프레스를 어드민이 있는 CMS로만 사용) 


내용 소개 전, 제가 느끼는 워드프레스가 변화해 가는 방향을 적어보겠습니다. 


워드프레스는 버전 5.0부터 기존의 에디터를 대신할 Block Editor를 기본 에디터로 탑재하고, 6.x대가 된 현재까지, 그리고 앞으로도 꾸준히 개발을 진행해 나갈 것 같습니다. 이미 많은 이들이 테마의 핵심 요소인 페이지 빌더를 가지고 사이트를 만드는 것에 익숙해지던 때에 기본 에디터로 탑재가 되어서인지 'Gutenberg' 편집기에 대한 평가는 한참 동안 1점대였습니다(지금은 2개네요). 저도 당최 이거로는 디자인대로 화면 구현이 어려워 이 편집기 기능을 아예 꺼버리는 방법으로 사이트를 제작하곤 했습니다. (※ 워드프레스에서 classic editor 플러그인을 제공 중. 즉 기존에는 원하면 Gutenberg를 설치해서 사용했는데, 5.0부터 반대로 됨) 


워드프레스의 개발 방향이 정해졌더라도 현재는 너무 이상하게들 사용이 되는 상황이라 제대로 된 안내나 가이드라인을 좀 줬으면 하는 바람도 있습니다. 가령 최근 인기가 있는 엘리멘토 빌더로 사이트를 구축하는 상황을 가정해 볼 때, 대부분은 블록 에디터와 엘리멘토 빌더가 같이 쓰이는 상태로 사이트를 제작합니다. 사이트 방문자에게 화면을 출력 시 불필요한 블록 에디터에 관련된 CSS나 JS도 같이 포함이 계속되는 거죠. 제가 보기에는 둘 중 하나를 제대로 쓰는 게 더 나아 보입니다. 



한참이나 이 상황이 잘 이해가 되지 않았습니다. 왜 이리 복잡한 상황을 만들면서까지 업데이트를 이어가는 것일까? 아직도 다른 페이지 빌더에 비하면 너무 불편한 편집기인데 대체 언제 즈음 완성이 될 것인지, 아니 과연 완성을 할 수는 있을 것인지... 


그런데 이번에 워드프레스는 CMS의 기능으로 쓰고, 프런트 앤드 화면은 javascript 기반의 속도가 매우 빠른 웹사이트를 제작하는 걸 접하게 되니, 왜 워드프레스에서 개발의 방향을 블록 에디터로 둔 것인지가 조금은 이해가 되었습니다. 


왜냐하면 블록 에디터는 json 데이터 형태로 콘텐츠가 저장이 됩니다. 거기에 워드프레스에는 json 데이터를 쉽게 얻을 수 있게 이미 REST API를 제공하고 있죠. 블록 에디터로 편집을 하게 되면 화면을 해석하는 데 드는 시간이 줄어들 수 있습니다. 이제는 화면을 javascript로만 잘 제작할 수 있다면 워드프레스는 또 다른 장점을 가질 수 있는 겁니다.(데이터를 잘 관리할 수 있는 CMS로의 역할 + 빠른 속도의 사이트) 결론적으로 제 생각에는 이 의도로 워드프레스에서는 계속 블록 에디터를 개선해 나가고 있는 상황 같습니다. 이미 대세가 된 웹사이트 제작 방식에 맞게 진화를 하고 있는 것이죠. 


그런데, 인기가 있다는 javascript로 사이트를 제작하는 방식을 계속 얼핏 얼핏 보기는 했지만 새로 다른 방식을 배우자니 뭐부터 시작을 해야 할지도 모르겠고, 아직까지 사이트 제작 시 이런 요청도 딱히 없는 것 같고 하여 알아보는 걸 계속 미뤄왔던 것이 사실입니다. 


그러던 중 최근에 'Headless Wordpress'가 눈에 띄워서 호기심에 집중해서 확인하다 보니, 이미 워드프레스를 타깃으로 하는 잘 짜인 프레임워크가 존재했었네요. >> FRONTITY 


이런 방식입니다. (※ 이와 다른 Embeded mode 방식도 있음)

1. 콘텐츠를 관리할 워드프레스 사이트 (서버 1)

2. React 프레임워크 'Frontity'를 이용해서 테마 패키지를 제작 (워드프레스와 비슷하게 테마 패키지 형태로 화면 구성)

3. 콘텐츠를 표시할 사이트를 Node.js 구동 서버에 배포 (서버 2) 

 



어떤 차이가 있는지는 실제 구동되는 모습을 보면 더 쉽게 와닿을 수 있을 듯합니다. 

1. 워드프레스 사이트 

https://oksdev-en.tk/

(※ 해외 호스팅이라 첫 로딩이 느릴 수 있음) 

2. (1)의 사이트의 REST API 데이터를 가지고 Frontity를 가지고 표시한 사이트 

https://twenty-twenty.vercel.app/  

(※ Frontity에서 기본 제공하는 twenty-twenty 테마 패키지 이용)



※ 2023.07.27 현재 
!!! ~~~.ga 도메인이 현재 문제가 있네요. (무료 도메인)
고로 워드프레스 사이트가 제대로 안 열리고, 그 데이터를 못 읽어오니 2번 사이트도 안 열리는 상황입니다. 

도메인 변경 후 해결 완료. 



테스트 시 한 것은 1)번의 사이트의 도메인을 2)사이트 제작 시 세팅값에 연결 후, javascript로 만들어진 사이트가 구동되는 서버를 제공하는 vercel이라는 서비스를 이용해서 배포를 해 본 것입니다. 모양은 똑같이 만들어졌으나 작동되는 속도에서 많이 차이가 나네요. 







Frontity를 처음 알아보는 데 도움이 됐던 테스트 순서들은 이랬습니다. 


1. 튜토리얼을 따라 해 보기 (테마 패키지의 구조를 이해. 문법이 다르지만 테마로 화면이 구성되는 wp와 유사)

https://tutorial.frontity.org/


2. Frontity의 구조 이해 하기용 문서 체크 

https://docs.frontity.org/


3. 사용되는 명령어나 추가 패키지를 설치하는 방법 (많지는 않지만 만들어진 테마 패키지 이용법)

https://api.frontity.org/





이후에는 중간중간 초보로서 막히는 부분들이나, 확인한 내용들을 이어가 보려고 합니다. 



계속.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari