화면과 콘텐츠를 떼어놓으면 생기는 일

1. 문구 한 줄에도 개발자를 불러야 하는 사이트

홈페이지를 오픈하고 몇 달이 지나면 꼭 이런 연락이 옵니다. 메인 문구 한 줄만 바꿔 주실 수 있나요? 이번 달 이벤트 배너만 교체해 주세요. 간단한 요청인데, 사이트가 코드 안에 글을 직접 박아 넣는 방식으로 만들어져 있다면 이 한 줄을 바꾸기 위해 개발자가 코드를 고치고 다시 배포해야 합니다. 담당자는 기다리고 비용은 쌓이니, 사이트는 점점 손이 안 가는 채로 방치되죠. 오래 운영할 사이트라면 누가 얼마나 쉽게 내용을 바꿀 수 있는지도 디자인만큼 따져 봐야 합니다.

2. 머리를 떼어낸 CMS, 헤드리스

CMS는 콘텐츠를 관리하는 시스템입니다. 워드프레스처럼 익숙한 CMS는 콘텐츠를 저장하는 부분과 화면을 그리는 부분이 한 몸으로 붙어 있습니다. 헤드리스 CMS는 여기서 화면, 그러니까 머리를 떼어낸 구조입니다. 운영자는 Strapi, Sanity, Contentful 같은 관리 화면에서 글과 이미지를 올리고, 웹사이트나 앱은 API로 그 콘텐츠를 받아 각자 원하는 모양으로 보여줍니다. 덕분에 같은 공지사항을 웹사이트와 모바일 앱, 매장 키오스크에 한 번에 내보낼 수 있고, 화면 디자인을 통째로 바꿔도 콘텐츠는 그대로 둘 수 있습니다. 디자이너와 개발자는 화면에, 운영 담당자는 내용에 집중하는 식으로 역할이 깔끔하게 나뉩니다.

3. 장점만 있는 건 아닙니다

화면과 콘텐츠가 떨어져 있다 보니 글을 쓰면서 실제 페이지에 어떻게 보일지 바로 확인하는 미리보기 기능은 따로 만들어야 하는 경우가 많습니다. 처음 구조를 잡는 데 드는 시간과 비용도 일반적인 홈페이지보다 큽니다. 어떤 정보를 어떤 항목으로 나눠 저장할지 정하는 콘텐츠 모델을 처음에 잘못 설계하면 나중에 바꾸기도 꽤 번거롭고요. 몇 페이지짜리 소개 사이트이고 내용도 거의 바뀌지 않는다면 굳이 헤드리스까지 갈 필요는 없습니다. 도구를 고르기 전에 이 사이트가 얼마나 자주, 누구 손으로 바뀔지를 먼저 따져 보는 게 순서입니다.

4. 세컨드펭귄의 시선: 오래 운영할 사이트라면 구조부터 고민합니다

지금 보고 계신 이 블로그도 헤드리스 구조로 만들어져 있습니다. 글과 이미지는 Strapi에 저장되고, 화면은 Next.js가 받아서 그립니다. 그래서 나중에 사이트 디자인을 통째로 바꾸더라도 콘텐츠는 하나도 옮길 필요가 없습니다. 클라이언트 프로젝트를 할 때도 우리는 오픈 이후를 먼저 묻습니다. 누가 어떤 내용을 얼마나 자주 바꾸는지, 앱이나 다른 채널로 넓혀 갈 계획이 있는지. 그 답에 따라 헤드리스가 맞을 수도, 단순한 구조가 맞을 수도 있습니다. 예쁘게 오픈하는 것보다 오픈한 다음 날부터 편하게 쓸 수 있는 사이트를 만드는 게 더 어렵고, 우리는 그쪽에 시간을 더 씁니다.