헤드리스 CMS 대 기존 CMS
게시 됨: 2020-10-09목차
헤드리스 CMS와 전통적인 CMS에 대한 이러한 모든 논의는 당신을 지치고 방향 감각을 잃게 만들 것입니다. 그래서 오늘 우리 기사는 문제를 완전히 이해하는 데 더 집중하고 불필요한 이야기를 모두 피하는 데 더 집중함으로써 다른 길로 나아가려고 노력할 것입니다. 과정.
기존 CMS 이해
정의
기존의 결합된 CMS는 프론트엔드(프레젠테이션 계층)와 백엔드(콘텐츠 데이터베이스 및 편집 인터페이스) 등 모든 것이 긴밀 하고 직접적으로 연결되어 있어 콘텐츠를 보다 쉽게 관리할 수 있는 일반적인 콘텐츠 관리 플랫폼입니다.

실제 사용을 위한 전통적인 CMS의 의미
이와 같이 시스템 수준에서 모든 것을 직접 연결하면 백엔드에서 변경 사항을 적용하고 최소한의 구성으로 프론트엔드에 반영할 수 있습니다. 이러한 방식으로 팀의 비기술적인 구성원이라도 웹 사이트에서 콘텐츠를 관리하고 게시하는 것이 더 쉽다는 것을 알게 될 것입니다.
전통적인 CMS의 실용성은 WordPress와 같은 블로깅 플랫폼에서 가장 잘 나타납니다. WordPress에서 콘텐츠 관리 프로세스는 대시보드의 버튼 클릭을 통해 수행되는 웹사이트의 글꼴 또는 레이아웃 변경과 함께 사용자 친화적입니다. 항상 백엔드에서 직접 플러그인을 다운로드하고 설치할 수 있으므로 WordPress에 추가 기능을 설치하는 것도 쉽습니다.
기존 CMS의 예 |
워드프레스, 스퀘어스페이스, 마젠토 |
기존 CMS가 시스템 기능을 결정하는 방식
넓은 의미에서 기존 CMS는 보수적이며 확장성이 제한적입니다.
보수적 : 시스템 자체가 경직되고 모놀리식적이기 때문에 개발자의 관점에서 기존 CMS에서 혁신하기가 어렵습니다. 그리고 기존 CMS의 프론트엔드와 백엔드가 밀접하게 연결되어 있기 때문에 프론트엔드에 구현된 모든 새로운 기능에는 자체 백엔드 지원도 필요합니다. 이것이 새로운 기능을 롤아웃하고 전체 시스템에서 안정성을 보장하기 위해 이러한 유지 관리가 필요하기 때문에 시스템 전체의 유지 관리가 기존 CMS에서 정기적인 것으로 봐야 하는 이유입니다.
제한된 확장성 : 기존 CMS의 기존 기능 위에 새 기능의 계층과 계층을 추가하는 경우 이러한 새 기능이 모두 특정 시스템에 맞게 구축되지 않았기 때문에 성능 문제가 발생할 가능성이 있습니다. 새로운 기능을 구현하는 것이 종종 기존 CMS를 사용하는 번거로운 프로세스라는 사실과 함께 확장성은 조만간 변경될 가능성이 거의 없는 기존 CMS의 고유한 단점으로 남아 있습니다.
제한 사항 | 설명 |
보수적인 | 기존 CMS는 프런트엔드와 백엔드가 밀접하게 연결된 방식으로 인해 혁신과 실험을 권장하지 않습니다. |
제한된 확장성 | 기존 CMS에서 상향 확장은 사용 가능한 선택의 부족(즉, 특정 플랫폼에 연결됨)으로 인해 어렵습니다. |
헤드리스 CMS의 경우
아마존이 어떻게 현재의 위치에 도달했는지는 우연이 아닙니다. Amazon이 완전히 분리된 CMS 로 몇 초마다 새로운 프론트엔드를 내놓고 있다는 사실과 AWS(Amazon Web Services)가 영업 이익의 70% 이상을 차지한다는 사실을 감안할 때 우리는 Amazon이 그렇게 많지 않다고 믿게 되었습니다. 전자 상거래 비즈니스를 옆에 두고 있는 기술 회사에 가깝기 때문에 전자 상거래 회사입니다. 그리고 이는 분리된 헤드리스 CMS를 통해서만 Amazon이 기존 CMS로는 달성할 수 없는 수준의 유연성과 확장성을 달성할 수 있기 때문에 의미가 있습니다.
헤드리스 CMS: 정의
"Headless"는 헤드(프론트엔드)에 주의를 기울이지 않음 으로써 헤드리스 아키텍처의 백엔드가 작동하는 방식에 관한 것입니다. 그러나 모든 시스템에는 헤드가 필요하기 때문에(가장 기본적인 시스템이라도 여전히 필요한 모든 정보를 표시하는 터미널이 있기 때문에) 헤드리스로 전환하는 것은 일반 평신도에게 그다지 실용적이지 않은 것 같습니다. 왜 머리를 잃어?
이것은 헤드리스 아키텍처가 API 를 사용하여 헤드(프레젠테이션 레이어)에 전달되는 (멀티 헤드) 콘텐츠 관리 시스템인 더 간단한 방식으로 재정의될 수 있는 경우입니다. 이러한 방식으로, 예를 들어 한 콘텐츠를 여러 프론트엔드와 여러 플랫폼에 동시에 게시할 수 있습니다. 결과적으로 이것은 헤드리스 CMS의 개발이 본질적으로 비동기적이며 백엔드에 영향을 미칠 염려 없이 프론트엔드를 변경할 수 있으며 그 반대의 경우도 마찬가지임을 의미합니다.


헤드리스 CMS의 예 |
Contentful, Kentico, Magento Commerce |
헤드리스 아키텍처의 API 이해
API는 헤드리스 아키텍처의 핵심 구성 요소로 간주될 수 있습니다. 간단히 말해서 서로 다른 시스템(다른 프로그래밍 언어를 사용하는)이 서로 통신하는 방법입니다.
API를 통해 프론트엔드의 제품 목록 페이지는 백엔드가 어떻게 작동하는지 알지 못해도 백엔드에서 데이터를 요청할 수 있습니다. 이것이 실제로 의미하는 바는 사용 중인 API가 시스템과 완전히 호환되는 한 비즈니스가 더 이상 단일 백엔드 및/또는 단일 프론트엔드로 제한되지 않고 전체 운영에 지장을 주지 않고 교체할 수 있다는 것입니다. . 또한, 하나의 프론트엔드에만 국한되지 않기 때문에 결과적으로 자동 판매기, 광고판, 웨어러블 등과 같은 인기 있는 프론트엔드 또는 비 전통적인 프론트엔드에서 콘텐츠를 사용할 수 있습니다.
헤드리스 CMS를 선택해야 하는 시점 알기
헤드리스 CMS의 장단점
헤드리스 CMS의 거의 모든 것이 API를 중심으로 돌아가기 때문에 아키텍처 자체가 더 실용적이고 기술적 입니다. 기존 CMS보다 이는 헤드리스 CMS에서 콘텐츠를 편집하고 게시하는 것이 기존의 모놀리식 아키텍처에 비해 프로세스를 손에 쥐고 있지 않다는 것을 의미합니다. 그러나 그 대가로 사용 중인 플랫폼에 제한되지 않고 원하는 유형의 콘텐츠를 만들 수 있는 훨씬 더 많은 자유 를 얻습니다.
예를 들어 Contentful과 같은 순수한 헤드리스 CMS 플랫폼에서는 콘텐츠의 청사진 역할을 하는 콘텐츠 모델 을 만들 수 있습니다. 이러한 콘텐츠 모델은 콘텐츠 팀이 콘텐츠를 만들고 다양하고 유연한 CMS의 핵심 역할을 할 수 있는 더 많은 방법을 제공합니다.

출처: 콘텐츠
아키텍처 자체가 확장성을 위해 만들어졌음에도 불구하고 헤드리스 CMS를 유지 관리 하는 것은 기존 CMS에 비해 쉬운 작업이 아닙니다. 헤드리스 CMS에서 귀하와 귀하의 팀은 모든 유지 관리 및 유지 작업(맞춤형 API 유지 관리 포함)에 대해 전적으로 책임 이 있다는 사실로 귀결됩니다. 개발하고 혁신할 수 있는 이러한 완전한 자유는 또한 스스로 의지할 수 있다는 것을 의미하며, 헤드리스 CMS를 개발하고 유지하는 것은 프로세스에 더 높은 수준의 기술과 위험이 수반되기 때문에 예상보다 비용이 많이 들 수 있습니다.
팀이 헤드리스 CMS 및 이와 관련된 모든 추상화를 처리하는 데 경험이 없다면 비즈니스의 출시 시간을 지연시킬 수도 있습니다.
헤드리스 아키텍처 자체는 단일 플랫폼과 함께 제공되는 모든 것에 얽매이지 않는 선택입니다. 예를 들어 일반적인 전자 상거래 작업의 경우 완전한 API를 갖춘 Headless Magento와 같은 유연한 헤드리스 솔루션을 선택하여 백엔드를 강화할 수 있습니다. 그런 다음 선택에 제한이 없다는 것을 알고 다른 타사 ERP를 선택하여 재정 및 물류를 관리할 수 있습니다.
장점 | 단점 |
모듈식 백엔드 및 프런트엔드 | 개발 비용이 많이 든다 |
프론트엔드와 백엔드 사이의 비동기 개발 가능 | 코딩 지식이 필요합니다 |
광고판 및 웨어러블과 같은 비전통적인 장치에서도 콘텐츠를 사용할 수 있습니다. | 높은 수준의 구현 어려움으로 인해 실제로 출시 시간이 지연될 수 있음 |
헤드리스 CMS를 선택해야 하는 경우
헤드리스 CMS는 기능적인 헤드리스 시스템을 적절하게 구현하는 데 필요한 작업량과 비용으로 인해 첨단 기술이었고 소규모 기업에서는 액세스할 수 없었습니다. 그러나 시간이 지나면서 헤드리스 CMS는 이제 주류가 되어 모든 사람이 액세스할 수 있게 되었습니다.
헤드리스 CMS와 관련된 몇 가지 단점이 있기 때문에 헤드리스로 전환하려는 기업은 비즈니스를 확장할 가능성이 있고 헤드리스를 개발하고 유지 관리하는 데 필요한 리소스가 있다고 생각할 때만 이 접근 방식을 고려해야 합니다. CMS.
실제로, 헤드리스 CMS에 대한 기본 다국어 경험이 없기 때문에 헤드리스 접근 방식을 선택하면 당연하게 여겼던 대부분의 기능을 놓치게 될 수도 있습니다. 예를 들어, 웹사이트의 사이트 검색 기능도 기능이 완전히 안정되는 데 몇 주 이상이 걸릴 수 있으므로 구현하기 어려울 수 있습니다.

전통적인 CMS가 여전히 자리를 차지하고 있습니까?
두 CMS의 장점과 단점을 모두 고려하면 웹 제공 웹사이트의 콘텐츠를 CMS만으로 쉽고 간편하게 관리하려는 기업에 전통적인 CMS가 더 적합할 것입니다. 이와 같은 경우 헤드리스로 가는 것은 상대적으로 적은 이익을 위해 더 많은 노력을 기울이는 것을 의미합니다. 이는 과잉이며 시장 출시 시간을 단축시킬 것입니다.
머리를 잃다
빠른 속도로 헤드리스 CMS를 수용하는 플랫폼 공급업체와 타사 또는 사용자 정의 개발된 외부 프런트엔드와 함께 사용할 수 있는 내부 API 호출을 가능하게 하기 위해 시스템을 지속적으로 재구성함에 따라 헤드리스 시스템 배포는 몇 년 전보다 훨씬 더 쉬운 프로세스입니다. .
Magento는 헤드리스 CMS가 우리가 앞으로 나아가면서 점점 더 주류가 되고 있음을 보여주는 한 가지 대표적인 예입니다. 시작하는 완전한 API를 통해 개발자는 헤드리스 커머스를 구축하고 유연한 콘텐츠 관리 시스템의 모든 이점을 누릴 수 있습니다. 프론트엔드 솔루션으로 프로그레시브 웹 앱과 결합하여 판매자는 전반적으로 전환율이 증가하고 기타 중요한 지표가 향상되었다고 보고하고 있습니다.
정신없이 가고 싶지만 아직 도약할 신뢰할 수 있는 솔루션 제공자를 찾지 못한 Magento 판매자를 위해 여기 SimiCart에서 매장 내 쇼핑 경험을 혁신할 준비가 된 전체 솔루션을 제공합니다.