CMS의 새로운 형태, Headless CMS
사실 지금 와서 새로운 형태라곤 할 수 없지만, 예전에 써둔 초안을 정리해서 올려본다.
Headless CMS에 뛰어들기 전에, 문서 관리 방법의 변천사(?)를 한 번 쯤 훑어보는 것도 좋겠다.
기술 문서 관리의 변천사
미리 말해두지만, 테크니컬 라이터 입장에서 보는 문서 관리의 변천사다. 그리고 내가 이 모든 것을 겪은 것도 아니므로 정확하지 않을 수도 있다.
텍스트와 VI
아주 오래 오래전, 웹 같은 건 없고 그래픽 UI도 없던 시절, 아마도 유닉스를 사용한 시절에는 vi 편집기를 이용해 readme.txt로 문서를 썼다(고 한다). 논문 같이 복잡한 수식을 쓰기 위해서는 조판 도구인 LaTeX를 썼다. 둘 다 텍스트이고 주로 소프트웨어 배포시에 함께 배포했으니 당시에도 형상관리 툴에서 텍스트 파일을 관리하지 않았을까 생각해본다.
워드프로세스의 등장
그래픽 UI가 나타나면서 워드프로세스가 문서 작업에 동원되었다. LaTeX 보다 사용법이 월등히 쉽고 출력물도 깔끔해서 기술문서도 이것으로 많이 썼다. 다만 바이너리 파일이라는 단점 때문에 버전 관리가 쉽지 않았다. 버전별로 별도 파일을 만들어 저장하는 것이 가장 쉬운 방법이었고, 경제적으로 여유가 있다면 SharePoint를 설치해 버전 관리할 수 있었다. 개인적인 경험에 따르면, SVN에서 SharePoint로 옮기면서 그 개념 변화에 상당히 고무되었지만 실제 사용하기에는 아주 불편했다. 특히 대용량 파일은.
웹문서와 CMS
당연하게도 웹이 기존 기술 문서의 패러다임을 깨뜨렸다. vi 편집기로 텍스트를 작성하든 워드프로세스로 바이너리를 작성하든 결국 파일 단위로 관리하던 것이, 웹사이트에 문서를 게시하면서 토픽 단위로 관리할 수밖에 없게 된 것이다. 기본적인 규칙은 크게 변하지 않더라도, 기본 단위가 바뀌면서 문서 구조화 및 작성 스타일이 많이 달라졌다. 개인적으로는 이 시점에서 기존 라이팅 기법이 통하지 않게 된 게 많다고 생각한다. 글쓰는 사람도 이 시대 전 사람과 이 시대 후 사람의 생각과 스타일이 많이 다르다.
생각해보면 워드프로세스와 웹문서 사이에 온라인 헬프라는 문서 포맷이 있었다. 파일로 관리하지만 토픽 기반으로 문서를 작성하는 기법이므로 실제로 로컬 파일 문서의 패러다임을 바꾼 것은 이것일 수도 있다.
아무튼, 웹문서가 주류를 이루면서 기술 문서에서도 웹 CMS(Content Management System)가 널리 사용되었다. 물론 지금도 잘 쓰이고 있다. CMS의 특징은 다음과 같다.
- 문서 배포 플로우 관리
- 동시 작업 가능
- 데이터베이스에 저장
즉, 이때부터 로컬에 파일을 저장할 필요 없이 서버 데이터베이스에 모든 자료가 저장된다. DB 백업을 해두지 않으면 서버에 문제가 발생했을 때 데이터를 잃을 위험이 있기에 자체 서버를 운영하기보다 서비스 업체를 사용하는 편이 안전하다. 문서 자체는 CMS가 제공하는 기능을 이용해 웹UI로 버전 관리할 수 있다.
다시 처음으로, SSG
데이터베이스에 저장하는 웹사이트 방식은 사용자가 늘어나면서 응답 속도에 대한 불만이 나오기 시작했다. 단순한 HTML에서 시작해서 다양한 서비스를 제공하기 위해 복잡해졌던 웹사이트는 다시 단순한 HTML로 돌아가기 시작했다. SSG(Static Site Generator)는 마크다운 등 콘텐츠 작성에 유리한 포맷으로 작성한 여러 문서를 웹사이트로 제공할 수 있는 HTML 파일로 만들어준다. 즉, 서버에서 데이터베이스에 저장된 내용을 읽지 않고 이미 만들어진 HTML/CSS/JS 파일만 전달한다. 이 방식은 기술문서 같이 접속 환경에 따라 데이터가 변화하지 않는 웹사이트에서 빠른 서비스를 제공할 수 있다. 사용자 입장에서도 블로그처럼 고정된 콘텐츠를 기반으로 하는 웹사이트는 구태여 CMS 서비스를 이용하거나 데이터베이스를 운영할 필요 없이 정적 파일을 생성해 Git Pages같은 웹서비스에 올리는 편이 부담이 적다. 이런 바탕에는 웹에디터를 선호하지 않고 서비스가 제공하는 스타일을 벗어나고자 하는 사람들의 심리가 깔려 있으리라 생각한다.
아무튼, StaticGen이라는 웹사이트에서 보다시피 SSG는 아주 다양하다. 도구마다 상세 사용법은 다르지만, 일반적으로는 디렉터리 구조로 콘텐츠 및 템플릿을 관리하고, 완성된 웹사이트를 HTML로 빌드한 다음 웹서버에 업로드 해야 한다. 텍스트 파일 기반이므로 버전 관리는 git 같은 형상관리 도구를 많이 이용한다. 혹은 자체 제공하는 관리자 도구를 이용해 웹 UI로 관리하기도 한다.
Tip
SSG는 업데이트 될 때마다 HTML을 전부 생성해서 업로드해야 하므로 글자 하나 바뀔 때마다 전체 빌드하고 업로드 해야 하는 부담이 있다. 물론 CI 도구로 자동 처리할 수도 있지만 귀찮은 작업이다. 이런 문제를 해결하기 위해 HTML 생성 없이 마크다운을 동적 렌더링하는 도구도 있다. 정적 파일을 생성하지 않으니 SSG라 할 수 없지만, Docsify(Vue기반), DocSPA(Angular기반)를 참고하자.
Headless CMS
마침내 본래 주제로 돌아왔다. Headless CMS는 기존 CMS의 단점을 보완하고 좀 더 융통성을 주기 위한 도구다. 개인적으로는 SSG가 가진 단점인 관리의 어려움을 해결하는 방법으로서 각광받지 않았나 생각한다. 잘 알려진 Headless CMS 중 하나인 Netlify CMS는 GitHub기반 콘텐츠 관리 도구로, SSG가 하듯이 GitHub에 마크다운 파일로 콘텐츠를 작성하고 관리해준다. 물론 기존 CMS처럼 자체 서버와 데이터베이스를 사용하는 것도 있다.
엄밀히 말해 Headless CMS는 웹문서화에 있어 SSG를 대체하는 후속 도구는 아니다. 오히려 SSG와 함께 사용할 수 있는 도구로 볼 수 있다. Headless CMS에서 문서 관리는 자체 제공 기능을 이용한다. 기존 CMS와 유사하게 볼 수 있다.
그래서, Headless CMS란?
Headless CMS의 시작은 모바일 기기가 등장하면서 콘텐츠의 데이터와 뷰를 분리해 다양한 기기에서 쉽게 표출할 수 있도록 하기 위해서다. 기존 CMS는 손쉬운 사용을 위해 백엔드와 프론트엔드를 통합 제공했지만, 익숙해지다보면 뷰를 커스터마이징 하고 싶은 것이 사람 마음이 아닐까? 그래서 백엔드를 기본 제공하고 프론트엔드는 사용자에게 맡기고자 하는 CMS가 등장했다. 왜 headless라는 이름이 붙었는지 짐작할 수 있는 히스토리다.
Headless CMS와 기존 CMS와의 차이는 다음과 같다.
- Classic CMS: 서버에 데이터 저장, 출력은 자체 템플릿 사용, 클라이언트가 데이터와 뷰를 모두 받음, SSG 연동 어려움
- Headless CMS: 서버에 데이터, 출력 커스터마이징 가능, 클라이언트가 데이터만 수신 가능, SSG 연동 쉬움
프론트엔드가 없다는 말은, 결국 사용자가 프론트엔드를 설계/구현해야 한다는 뜻이다. 그러다보니 처음 시작할 때 허허벌판에 뚝 떨어진 것처럼 뭘 해야할지 모를 수도 있다. 이런 일을 없애려고 일부는 선택적으로 프론트엔드를 제공하기도 한다.
Headless CMS의 종류
Headless CMS를 보면 headless CMS를 API driven과 git-based로 분류해놓았다. Headless CMS의 기본은 API 방식이지만, SSG에서 널리 사용하는 git을 지원하기 위해 등장한 것이 git-based headless CMS로 보인다. 그 대표가 Netlify CMS인데, 앞에서 말한 것처럼 GitHub 저장소와 연동해 콘텐츠를 생성/관리할 수 있다. 이는 어떻게 보면 SSG를 잘 관리하기 위한 도구의 하나일 뿐 진정한(?) headless CMS라 볼 수 없을지 모른다.
진정한(?) headless CMS는 콘텐츠를 커스텀 필드로 구분해 저장한 후 클라이언트의 요청에 따라 필요한 데이터를 제공하는 것이다. 그래야 본래 목적대로 어떤 디바이스에서든 손쉽게 데이터를 표출할 수 있다. 이를 위해 REST API나 GraphQL 검색을 지원해야 한다. 가장 인기있는 무료 headless CMS인 Ghost나 Strapi는 REST API와 GraphQL을 모두 제공한다.
대체 headless CMS가 뭔가 싶어 위에 언급한 세 가지를 모두 설치해보았는데, 아주 잠깐 써봤지만 느낀 점은 이랬다.
- Netlify CMS: 아주 간단하고 쉬움. GitHub와 연동하므로 설치할 것도 없고 사용법도 쉬워서 그냥 접속한 후 파일 생성, 작성, 배포만 하면 끝. 뷰는 Jekyll 같은 SSG를 이용할 수 있음.
- Ghost: 설치가 상당히 까다로움. 데이터베이스가 필요하지만 알아서 설치 해줌. 기본적으로 블로그 사이트 템플릿을 제공하므로 바로 블로그를 만들어 볼 수 있으며, 자체 테마 마켓을 지원. UI가 미려하고 에디터 사용이 쉬움.
- Strapi: 데이터베이스가 필요하지만 알아서 설치 해줌. 문서나 관리자 페이지가 API 위주로 되어 있고 기본 템플릿이 없어서 처음 써보는 사용자를 바보로 만들기 쉬움. 대신 멀티랭귀지, 다양한 템플릿 언어, 다양한 데이터베이스를 지원하므로 범용적으로 쓸 수 있고, 특히 API를 자유자재로 만들 수 있음.
Ghost 살펴보기
Ghost는 무료 headless CMS 가운데 가장 선호도가 높다. Self-hosting이 가능하지만 모든 기능을 제공하지는 않는 것 같다.
관리자 페이지에 들어가면 다음처럼 기본 블로그 데이터 및 템플릿을 제공하며, 그 자리에서 프리뷰할 수 있다.
기본적으로 page와 post 데이터 타입을 제공한다. post 타입에 들어가면 다음처럼 블로그 포스팅 샘플이 있다. 여기서 포스팅을 관리한다.
포스팅을 선택하면 웹 에디터에서 바로 변경할 수 있다.
일반적인 위지윅 에디터를 쓸 수 있고, 마크다운 블록을 추가해 마크다운으로 입력할 수도 있다.
포스팅의 메타데이터를 입력할 수 있지만, 메타데이터 항목은 수정할 수 없다.
Integration에서 서비스를 등록해 API 키를 발급하면, API로 포스팅 데이터를 가져올 수 있다.
Strapi 살펴보기
Strapi는 정말 완전한 API 기반 headless CMS다. 관리자 페이지는 다음과 같은 형태다.
테스트하느라 ‘Example’이 추가되었지만 처음 실행하면 기본 콘텐츠 타입은 하나도 없으므로 직접 필요한 것을 만들어야 한다. 예를 들면, Content type builder에 들어가 블로그 포스팅을 위한 ‘Posts’를 만들고 원하는 필드를 추가한다. 여기서는 예시로 title과 content만 필드로 추가해보았다.
그러고나면 Ghost에서 본 것처럼 Post 항목에 들어가 새로운 포스팅을 추가할 수 있다. 필드를 추가할 때 text 타입을 선택하고 위지윅 에티터를 체크하면 마크다운 위지윅 에디터를 쓸 수 있다. 물론, 어차피 데이터는 텍스트로 저장되므로 프론트엔드에서 렌더링할 필요가 있다.
Roles & permissions에서 public 항목을 선택하고, 하단 permission 목록의 application에서 ‘Post’를 찾으면 기능별 API를 오픈할 수 있다. 예를 들어 Post의 ‘find’ 항목을 체크하면 모든 포스팅 데이터를 가져올 수 있다.
그래서 무엇을 선택할까?
세 headless CMS를 테스트해보니 선택은 쉬워졌다.
이미 SSG를 사용해 GitHub에 배포하는 사이트라면 Netlify CMS가 가장 쉽고 빠르다. 이걸 쓰면 git 사용법에 익숙지 않은 사용자들도 손쉽게 글을 쓸 수 있는 장점이 있다. 또 데이터베이스를 사용하지 않으니 별도 서버를 구동할 필요가 없다. 하지만 결국 기반은 SSG가 된다.
Headless CMS를 써서 완전히 새로운 웹사이트를 만들고자 하면, 특히 웹사이트가 다양한 언어를 지원해야 한다면 Strapi를 사용하는 것이 진짜 headless CMS를 익히기에 좋다. 솔직히 말해 Ghost의 UI가 훨씬 쉽고 예쁘지만, 콘텐츠 타입을 커스터마이징 할 수 없기 때문에 어차피 headless CMS를 익히고자 한다면 Strapi가 낫다. 물론, 익히고자 하는 목적이 아니라 간편하게 쓰고 싶다면 Ghost를 사용하는 것이 좋다.
Tip
Strapi와 Gatsby를 연동해 GraphQL로 headless CMS에 저장된 데이터를 가져와 서비스하는 법이 이 블로그에 잘 나와 있다.
