들어가며
이전에 그룹 블로그 개편을 진행하며 도입하게된 Strapi(보통 스트라피 라고 읽는것 같습니다)에 대해서 소개해 보려고 합니다.
우선 기본적으로 커스텀한 프론트개발 환경은 당연한 조건이었고 데이터베이스, 관리자 페이지와 api가 필요했었습니다.
프론트개발 환경은 next.js로 확정이었지만 백엔드는 조금 고민이었죠…
Node.js의 express또는 express를 이용한 각종 프레임웍을 사용할수도 있었지만 직접 하나하나 작업해 주어야 하는 부분들이 블로그를 만드는데 있어서 그리 효율적이지 못할것 같다는 생각이 들었습니다.
그러던 와중에 같은 그룹의 이OO(코공)주임님의 추천으로 Strapi에 대해서 알게되었고 흥미가 생겨 Strapi를 사용하여 블로그 백엔드 구축 및 관리자 페이지까지 비교적 쉽고 빠르게 구축할수 있었던 경험을 얻게되어 소개해보려고 합니다.
Headless CMS란?
헤드리스 CMS는 Content Management System의 약어로, 웹사이트의 콘텐츠를 관리하는 시스템을 말합니다. 그러나 헤드리스라는 용어가 붙어 헤드리스 CMS라고 불리우는 이 시스템은 기존의 CMS와는 다소 다른 특징을 가지고 있습니다.
기존의 CMS는 프론트엔드와 백엔드가 결합된 형태로, 콘텐츠를 생성, 관리하고 사용자에게 보여주는 기능까지 모두 포함하고 있습니다. 이는 사용자에게 보여지는 웹사이트의 디자인(프론트엔드)과 콘텐츠를 관리하는 부분(백엔드)이 한 덩어리로 묶여있는 형태입니다.
반면, 헤드리스 CMS는 이 두 부분을 분리한 형태로, 프론트엔드와 백엔드가 분리되어 있습니다. 즉, 콘텐츠를 생성하고 관리하는 백엔드 부분만을 가지고 있으며, 이를 어떻게 보여줄지는 개발자가 따로 결정하고 구현할 수 있습니다. 이를 가능하게 하는 기술이 바로 API입니다. API를 통해 콘텐츠를 요청하고 받아오며, 이를 다양한 플랫폼에서 사용할 수 있게 됩니다.
이렇게 구성된 헤드리스 CMS의 장점은 다음과도 같습니다.
플랫폼 독립적: 헤드리스 CMS는 콘텐츠를 어떤 플랫폼에서든 보여줄 수 있습니다. 웹사이트뿐만 아니라 모바일 앱, IoT 디바이스 등 다양한 플랫폼에서 콘텐츠를 사용할 수 있습니다.
유연성: 프론트엔드와 백엔드가 분리되어 있기 때문에, 각각을 독립적으로 개발하고 관리할 수 있습니다. 이는 개발자에게 큰 유연성을 제공하며, 새로운 기술을 적용하거나 디자인을 변경하는 등의 작업을 보다 쉽게 할 수 있습니다.확장성: 콘텐츠를 관리하는 부분과 이를 보여주는 부분이 분리되어 있기 때문에, 각 부분을 개별적으로 확장할 수 있습니다. 이는 시스템의 확장성을 높이며, 대규모 프로젝트에도 적합합니다.
그러나 헤드리스 CMS에도 몇 가지 단점도 존재합니다.
개발 복잡성: 프론트엔드와 백엔드가 분리되어 있기 때문에, 각 부분을 따로 개발해야 합니다. 이는 개발 과정을 복잡하게 만들 수 있습니다.전체적인 관리 필요: 기존 CMS에서는 플러그인이나 확장 기능을 통해 쉽게 기능을 추가할 수 있지만, 헤드리스 CMS에서는 이런 기능을 직접 개발하고 관리해야 합니다.표준
CMS 기능 부족: 헤드리스 CMS는 헤드리스라는 특성 상, 일부 표준 CMS 기능이 부족할 수 있습니다. 예를 들어, 사용자에게 콘텐츠를 어떻게 보여줄지에 대한 미리보기 기능이 제한적일 수 있습니다.
이처럼 헤드리스 CMS는 그 특성상 기존의 CMS와는 다르게 동작하며, 이에 따라 그 장단점이 존재합니다. 이를 고려하여 프로젝트의 요구 사항과 목표에 맞게 적절한 CMS를 선택하는 것이 중요합니다.
왜 Strapi였나?
개인적으로 직접 경험해본 Strapi는 프론트엔드 개발자들로만 구성되어 있는 조직에서는 상당히 효율적인 도구가 될수 있다고 생각합니다.
물론 요구사항이나 개발규모를 봐가며 프로젝트에 도입을 고려해봐야 하겠지만 적어도 당장에 api를 개발해줄 백엔드 개발자가 없는 환경에서 불가피하게 api가 필요한 상황이라면 Node.js Koa기반으로 제작된 Strapi는 충분히 대체해줄수 있는 좋은 선택지라고 생각합니다.
- 어드민 제공 : 블로그를 개편을 진행하면서 초기에 제가 가장 고민했던 부분이 관리자페이지(admin)이었는데요 에디터 연동, 이미지파일 처리등등 다소 번거로운 부분들을 직접 구축해야 하나 하는것도 고민이었습니다.근데 Strapi는 기본으로 admin 화면을 그냥 만들어줍니다 물론 해당 admin 화면을 사용하지 않고 api만 사용하고 직접 admin을 직접 개발할수도 있겠죠 선택지는 사용하는 사람의 몫입니다.
- 확장성과 유연함 : CMS라서 상당히 제한적이고 ****틀이 견고할것 같지만 ****그렇지는 않습니다 ****기본적인 기본적인 CRUD는 admin 페이지에서 마우스 몇번의 클릭만으로 생성됩니다 단순한 api를 생성한다면 생산성 또한 큰장점이기도 합니다. 그외에도 개발 요구사항에 맞출수 있는 api커스텀 자유도가 상당히 높은편이라고 생각합니다 복잡한 쿼리일경우 raw sql을 작성해 데이터를 처리 할 수도 있습니다. 물론 여기서 부터 코드작성은 이뤄져야 합니다 공식 홈페이지에서 풀 커스터마이징이 가능한 개발자우선 프레임웍이라고 소개하고있죠 Strapi는 오픈소스이며 커밋의 대부분이 스트라피 직원이 아닌 일반 컨트리뷰터일만큼 유지보수와 버그 수정이 굉장히 자주 이루어진다는 장점이 있습니다
- Node기반 : Node(javascript)로 개발되었기 때문에 프론트엔드 개발자에게는 친숙하게 다룰 수 있습니다
- 플러그인과 프로바이더 : 구글 로그인 등 15개의 인증 Provider 및 플러그인들은 생산성과 개발 속도를 빠르게 도와줍니다.
아쉬운부분
- 어드민 커스텀 : 어드민 페이지를 커스터마이징 하기 어렵다는 부분은 저로선 좀 아쉬운 부분이었습니다 Strapi v3에서는 가능하다는 글은 봐왔는데 v4에 들어서며 어드민 페이지에 대한 자유도를 낮춘건 다소 아쉬운 부분이라고 생각합니다 물론 방법이 아주없는건 아니지만 그다지 추천하는 방법은 아니며 나는 많은 부분이 커스텀한 어드민이 필요하다고 한다면 Strapi로는 api생성만 하고 어드민은 별도로 구축해야 할것 같습니다.
- 커뮤니티 : Node(javascript)로 제작된 CMS로는 사용자가 비교적 많은 편이지만 php의 Wordpress처럼 널리 알려져 있지않고 커뮤니티 규모가 크지않아 이로 인해 문제 해결에 필요한 리소스를 찾기 어렵거나, 특정 문제에 대한 솔루션을 찾는데 시간이 걸릴 수 있습니다.
마치며
이번 블로그에서는 Strapi가 어떤 용도이며 어떻게 사용하면 좋을지에 대해서 직접 사용해보고 느낀점을 토대로 간략히 소개해 봤습니다 다음 포스팅에서는 블로그api를 Strapi로 어떻게 개발하였는지 또 요구사항에 맞춰 어떤 작업들을 Strapi를 통해 진행했는지 소개해보려고 합니다.
그럼 이만 이번포스팅 마치겠습니다
글 읽어주셔서 감사합니다.