Headless CMS, Strapi를 적용해본 소감

아래의 요구사항을 만족하는 서비스를 혼자서, 가능한 빠른 시일 내에 개발해야 한다면 어떻게 하겠는가? 단, 백엔드에서 처리해야 할 비즈니스 로직이 복잡하지는 않지만 어느 정도의 커스텀은 필요하다.

 

관리자페이지, 백엔드 개발, 커스텀 프론트엔드

 

프론트엔드 개발자로서 내린 결론은 Headless CMS를 도입하는 것이었다. 아직 국내에 많이 알려지진 않은것 같지만, 지난 3개월 간 Headless CMS를 도입하여 개발 및 운영을 해보니 본 프로젝트에 적합한 선택이었다는 생각이 든다.

Headless CMS라는 개념을 처음 접하게 된 것은 작년쯤 Jamstack이라는 개발 트렌드를 접하게 되면서이다. 프론트엔드 개발자로서 백엔드 개발의 부담을 덜어주는 컨셉이나 서비스는 항상 관심이 간다. Jacstack도 그중에 하나였고 언젠가 한번쯤 도입해보고 싶었다.

 

Jamstack

Jamstack은 서버리스 웹앱 디자인 컨셉이다. JAM이라는 단어가 JavaScript, API, Markup에서 파생되었고 이 세가지 개념으로 이해할 수 있다.

Markup - prebuilt 마크업으로 static HTML 파일을 호스팅한다.

API - 인증 등의 비즈니스 로직을 서버가 처리하는 대신에 Firebase, Okta 등이 제공하는 API를 사용한다. 복잡한 비즈니스 로직의 경우에는 AWS Lambda, Google Cloud Functions 등을 사용해서 작성하여 API로 제공한다. 일일이 모든 API를 작성하지 않아도 되기 때문에 개발 시간이 단축된다.

JavaScript - 클라이언트에서 사용자 인터랙션을 처리하고 이벤트를 만든다. 써드파티 API나 서버리스 백엔드와 연결해주고 호스팅하기만 하면 된다.

Jamstack, 출처: CloudBytes

 

Headless CMS

Heasdless CMS는 Jamstack에서 API를 제공하는 역할을 한다고 보면 된다. WordPress같은 전통적인 CMS는 HTML, CSS, 이미지 등의 모든 컨텐츠를 하나의 큰 버킷에 담아둔다. 이들은 컨텐츠를 저장하고 관리하는 백엔드 시스템과 컨텐츠를 사용자에게 전달하는 프론트엔드 시스템으로 이루어져 있고 서로 강하게 연결돼 있다(coupled). 컨텐츠가 코드와 얽혀있기 때문에 코드를 재사용할수가 없다. 그런데 요즘 상황은 어떤가? 웹사이트 뿐만 아니라 모바일 앱, 광고, 스마트워치, 냉장고 등 컨텐츠가 소비되는 디지털 채널과 디바이스는 점차 확대되고 있는데 전통적인 CMS는 이에 대응하기 위한 유연성이 떨어졌다.

Headless CMS는 머리(프론트엔드 시스템)를 몸(백엔드 시스템)에서 분리하여 컨텐츠 소비에 대한 유연성을 제공한다. 다시 말해 머리가 분리된 몸이라고 볼 수 있다. 컨텐츠를 사용자에게 어떻게 보여줘야 하는지는 관여하지 않고 저장된 컨텐츠를 API를 통해서 공유해줄 뿐이다. 이제 컨텐츠는 headless CMS가 제공하는 API를 호출하여 가져오고 이를 다양한 시스템, 소프트웨어, 웹사이트와 통합할 수 있다. 컨텐츠는 한 곳에서 관리할 수 있으면서도 프론트엔드측의 자율성은 높아진 것이다. 원하는 만큼 여러 개의 머리를 부착하여 다양한 채널에서 다양한 모습으로 컨텐츠를 소비할 수 있다.

 

Traditional CMS vs Headless CMS, 출처: HubSpot

 

참고로 Decoupled CMS라는 유사한 아키텍처도 있다. Decoupled CMS는 백엔드와 프론트엔드 시스템을 분리하고 컨텐츠를 API를 통해 제공한다는 점에서 유사하다. 하지만 Decoupled CMS는 기본적인 디스플레이를 위한 프론트엔드 코드 템플릿을 제공한다는 점에서 다르다. 전통적인 CMS와 Headless CMS의 절충이라고 볼 수 있다.

 

Strapi

Strapi는 Headless CMS 중에서 가장 유명한 오픈소스다.  자바스크립트로 작성되었고, 커뮤니티도 가장 커서 처음 도입하기에 적절하다고 판단했다. 공식 문서가 잘 되어있는 편이다. 플러그인 적용, 커스텀 코드 작성, 배포까지 공식 문서를 참고해서 진행하는 데 무리가 없었다. 반복적인 기능들을 자동으로 처리해주고 코드를 커스텀하게 작성할 수도 있었다.  몇 가지 특징들을 소개하고자 한다.

 

CMS 대쉬보드 제공

 

Headless CMS를 선택한 이유다. 클라이언트에게 관리자페이지를 제공해야 했는데 별도로 관리자페이지를 작성할만한 여유가 없었기 때문이다. 메뉴의 Content Manager에서 컨텐츠를 관리할 수 있다. 이외에 관리자 계정 관리, Public/Authenticated 사용자 권한 관리, 비밀번호 찾기 이메일 템플릿 관리 등의 기능을 제공한다.

 

Strapi Dashboard

 

자동으로 REST API 생성

 

컨텐츠 타입을 생성하면 자동으로 CRUD REST API를 생성해준다. 참고로 GraphQL 플러그인을 설치하면 GraphQL 엔드포인트도 제공한다. 컨텐츠 타입은 컬렉션 타입과 싱글 타입이 있으며 개발 환경에서 생성할 수 있고 다른 데이터와 릴레이션도 설정할 수 있다. GUI를 통해서 컨텐츠 타입을 생성할 수 있고 생성된 것도 GUI로 확인할 수 있어서 좋았다.

 

Strapi 대쉬보드에서 컨텐츠 타입 생성하기

 

커스텀 코드 가능

 

물론 커스텀 코드도 작성할 수 있다. Routes, Polices, Middleswares, Controllers, Services 등을 커스텀하게 작성할 수 있다. 예를 들어 controller의 경우 세 가지 방식으로 커스텀 로직을 작성할 수 있다.

1. 신규 - 완전히 새로운 코드
2. 확장 - 기존 코어 로직을 유지하면서 wrapping하는 코드
3. 덮어쓰기 - 기존 코어 로직을 대체하는 코드

필자의 경우 데이터를 create 및 update할 때 relation 관계에 있는 다른 데이터의 counting 수를 업데이트 해주기 위해 Controllers에서 기존 코어 로직을 확장하는 커스텀 로직을 작성하여 처리하였다.

 

플러그인 제공

 

Strapi가 제공하는 다양한 플러그인을 설치해서 사용할 수 있다. 설치는 Strpai 대쉬보드의 Marketplace나 npm packages를 통해서 할 수 있으며 기존 플러그인을 확장하거나 새로 개발하는 것도 가능하다. 필자는 사용자 계정 및 인증, 이메일, 데이터 import/exprot, sentry, ckeditor, 미디어 업로드 플러그인을 적용해서 사용했다.

 

결론

지난 3개월간 headless CMS인 Strapi로 개발 및 운영해보니 지금까지 만족스럽다. 클라이언트에게 컨텐츠를 관리할 수 있는 대쉬보드를 별도로 개발하지 않고 제공할 수 있고 그러면서도 프론트엔드를 커스텀하게 작성할 수 있다는 점이 가장 큰 이점이었다. 운영하면서 별다른 개발적인 이슈는 없었다. 본 프로젝트에서 다양한 채널과 디바이스로 컨텐츠를 제공할 필요는 없었다. 이러한 컨셉은 웹사이트의 약관에 적절하지 않을까 생각이 든다. 회원가입 과정에서 앱과 웹에서 동일한 약관을 보여줘야 하는 경우에 약관을 headless CMS로 관리하는 것이다. 약관은 종종 업데이트되야 하는데 이 때도 대쉬보드에서 편리하게 컨텐츠를 수정할 수 있다는 이점이 있을 것 같다. 

 

참조

https://cloudbytes.dev/snippets/what-is-jamstack-and-why-should-you-be-using-it

What is Jamstack and why should you be using it?

https://cloudinary.com/blog/developer_experience_for_a_modern_web_jamstack_delivers

Developer Experience for a Modern Web: JAMstack Delivers

https://blog.hubspot.com/website/headless-cms

What Is a Headless CMS? What Content Marketers Should Know