콘텐츠를 웹에 올리는 간략한 역사와 이것이 효과적인 콘텐츠 관리 시스템 설계 및 구현에 중요한 이유입니다. “CMS에서는 내가 원하는 것을 할 수 없습니다. 이 CMS는 형편없어요!” 귀하는 이를 말하는 마케팅 또는 콘텐츠 팀의 개인이거나 이 피드백을 받는 공급업체 또는 개발자입니다. 한번은 현재 CMS가 형편없다고 판단하여 새로운 CMS를 찾고 있는 기업이 나에게 왔습니다. 왜? 페이지 제목의 색상을 변경할 수 없습니다. 그 질문은 저를 약간 곤란하게 만들었습니다. 왜냐하면 저는 이 매우 좌절한 팀에게 그들의 CMS가 실제로 좋을 수도 있다는 것을 설명할 가치가 있는지, 심지어 제가 그 설명을 해낼 수 있다면 결정해야 했기 때문입니다. 그들이 왜 틀렸는지 알아낼 기분이 아니라는 것을 알고 저는 "우리가 살펴보고 CMS 구현을 먼저 개선할 수 있는지 살펴보겠습니다."라고 단순화했습니다. 이제 생각할 시간이 조금 생겼으니 전체 설명을 시도해 보겠습니다. CMS가 아무리 좋거나 나쁘더라도 원하는 콘텐츠 유형을 입력하거나 원하는 레이아웃 유형을 생성할 수 있도록 허용하는 경우 모든 CMS는 어느 시점에서 실패할 것입니다. 이는 불가피한 일이며, 이는 항상 정확히 동일한 문제, 즉 프레젠테이션 유연성과 콘텐츠 구조로 귀결되기 때문입니다. 제 말의 의미를 설명하자면, 우리는 시간을 거슬러 여행을 하게 될 것입니다. 1998. 1998년에는 웹이 그다지 정교하지 않았습니다. 웹에 콘텐츠를 올리는 것은 Microsoft Publisher나 Dreamweaver와 같은 도구를 사용하는 것을 의미했습니다. 코딩에 익숙하다면 직접 HTML을 작성할 수도 있었습니다. 후드 아래에 배치). 그러나 HTML 파일을 만들고 생성된 파일을 웹 서버에 업로드하면 짜잔, 웹사이트가 생겼습니다. CMS가 전혀 없었기 때문에 CMS를 비판할 수는 없었습니다. 대신 콘텐츠는 필요할 때마다 웹 사이트 프레젠테이션에 직접 입력되므로 완벽한 프레젠테이션 유연성을 제공합니다. 콘텐츠의 표현과 레이아웃을 변경하고 싶을 때마다 가능한 모든 방법을 사용할 수 있습니다(1998년 웹의 제한된 시각적 기능은 제외). 단락 사이에 데이터 테이블을 추가하시겠습니까? 확신하는. 페이지의 왼쪽 레일을 녹색으로 변경하시겠습니까? 그것을 위해 가십시오. 페이지 제목을 굵게 표시하시겠습니까? 쉬운. webdesignmuseum.org의 Dreamweaver 이미지 — 모든 콘텐츠가 웹 페이지 내의 해당 위치에 직접 작성되는 방식을 확인하세요. 필드가 전혀 없으며 대신 인쇄용 문서를 만드는 것과 유사합니다. 그러나 이러한 표현의 유연성은 콘텐츠 구조를 희생하면서 발생합니다. 콘텐츠 구조가 전혀 없습니다. 판매하는 제품을 설명하는 페이지를 만드는 경우, 제품 제목은 한 번 입력하면 사이트 전반에 걸쳐 필요한 모든 곳에 표시되는 모든 종류의 관리 시스템에서 제품 제목으로 정의되지 않습니다. 페이지 상단의 일부 텍스트를 굵게 표시했기 때문에 제품 제목이 제품 제목이 됩니다. 두 번째 제품을 만드는 경우 콘텐츠의 일관적인 구조를 유지하려면 동일한 스타일을 유지해야 합니다. 그리고 웹사이트 어디에나 동일한 제품 제목을 입력해야 하는지 확인하는 것은 귀하의 몫입니다. 귀하의 모든 콘텐츠는 귀하가 제공하는 프레젠테이션과 밀접하게 연결되어 있으며 프레젠테이션 외부에는 존재하지 않습니다. 이를 통해 콘텐츠 작성자는 콘텐츠의 모양을 완벽하게 제어할 수 있지만 전체 웹 사이트의 레이아웃을 페이지별로, 그린 레일별로 그린 레일을 일관되게 관리해야 합니다. 번거롭고 실수가 발생하기 쉬우며 이를 감지하지 못하고 확장도 어렵고 유지 관리도 어렵습니다. 프레젠테이션을 1998년에 제작되지 않은 것처럼 보이게 하려면 코드를 알아야 합니다. 하지만 당시에는 이것이 콘텐츠를 웹으로 가져오는 유일한 방법이었습니다. 2008. 웹과 이를 뒷받침하는 기술이 발전했습니다. 그리고 TV 드라마도 정말 좋아지고 있었어요. CSS 사양은 2000년대 초반에 웹 브라우저에서 채택되어 광범위하게 지원되었습니다. 캐스케이딩 스타일시트(Cascading Stylesheets)를 의미하는 이 기능은 콘텐츠와 스타일을 모두 포함하는 코드인 HTML에 스타일을 별도로 적용할 수 있게 하여 콘텐츠와 프리젠테이션을 분리할 수 있는 기술적 능력을 부여합니다. 저와 같은 밀레니얼 세대는 CSS 파일을 교체하여 다양한 스타일을 적용함으로써 정확히 동일한 콘텐츠가 어떻게 다양한 방식으로 표시될 수 있는지 보여주는 웹사이트인 CSS Zen Garden을 통해 이 개념에 박차를 가 했습니다. 또 다른 큰 혁신은 서버 측 스크립트가 PHP와 같은 프로그래밍 언어로 웹 서버에서 실행되어 동적으로 HTML을 출력할 수 있다는 것입니다. 더 이상 사이트를 만들기 위해 정적 HTML 파일을 업로드할 필요가 없습니다. 대신, 데이터베이스에서 생성한 모든 콘텐츠를 읽고 쓰는 로직으로 해당 HTML 파일을 대체하고 사이트 페이지를 생성하는 소프트웨어가 설계되었습니다. 파리. 콘텐츠 관리 시스템이 탄생했습니다. 이제 콘텐츠가 HTML 코드에 직접 고정되는 대신 데이터베이스의 개별 필드에 일반 언어로 저장되었습니다. Turnkeylinux.org의 Drupal 이미지 — 이 Drupal 인스턴스가 일부 구조화된 필드를 갖도록 설계되었으며, 모두 웹 페이지 구성에 맞춰져 있는 동시에 일부 프리젠테이션 제어를 혼합합니다(HTML은 노출되지만, 윽!). 콘텐츠를 구조화된 필드로 저장하면 엄청난 편리함과 강력한 기능이 제공되며 사용자는 콘텐츠를 관리하기 위해 코드를 알거나 레이아웃의 모든 측면을 터치할 필요가 없습니다. 이것이 오늘날 거의 모든 마케팅 팀이 웹 활동을 위해 콘텐츠 관리 시스템을 필요로 하는 이유입니다. 그러나 이는 또한 CMS에 적용 가능한 필드가 없는 웹 페이지에 대한 새 콘텐츠를 생성하려는 경우 손이 묶여 CMS가 싫어지기 시작할 수 있음을 의미합니다. 이는 프레젠테이션 유연성과 콘텐츠 구조의 균형입니다. 프레젠테이션 유연성과 콘텐츠 구조의 균형을 보여주기 위해 레시피 세부 정보 웹 페이지를 구축하는 예를 살펴보겠습니다. 1998/하드 코딩 방식을 사용하면 컨텐츠 작성자(Dreamweaver와 같은 기술에 능숙함) 또는 본격적인 코더가 테이블을 만들고 모든 레시피 재료와 측정값을 넣을 수 있습니다. 어쩌면 측정값을 이탤릭체로 표시하여 성분 자체와 시각적으로 구분할 수도 있습니다. 각 성분의 각 측정값을 힘들게 이탤릭체로 표시해야 하지만 그렇게 할 수 있습니다. 물론 그 모양을 바꾸고 싶다면 각 레시피 페이지로 돌아가서 각 재료의 측정값에서 이탤릭체를 수동으로 제거해야 합니다. 돈. 2008년에 콘텐츠 작성자(웹에 게시해야 하는 콘텐츠 유형에 맞게 조정된 CMS 기반 웹사이트 사용)는 측정 필드의 해당 측정값과 함께 각 성분을 CMS의 성분 필드에 입력했습니다. 측정 필드를 매우 매끄럽게 만들어 콘텐츠 항목을 줄이고 작성자에게 테이블스푼, 컵 등과 같은 일반적인 측정 사이에 드롭다운을 제공하면서 숫자만 입력하도록 할 수 있습니다. 그러면 페이지가 자동으로 생성됩니다(개발자가 구현한 레이아웃에서). 모든 측정값은 개발자가 페이지에 테마를 적용했기 때문에 자동으로 기울임꼴로 표시됩니다. 하지만 이제 개발자는 빠른 CSS 변경을 통해 전체 사이트에서 테마를 단일화하도록 유연하게 변경할 수 있습니다. 콘텐츠가 프리젠테이션에 묶여 있지 않기 때문에 개발자가 방문자가 미터법과 영국식 단위 사이를 전환할 수 있도록 페이지에 토글을 추가하는 등 놀라운 작업을 수행할 수 있습니다. 여러 레시피를 입력한 필드에서 자동으로 단일 색인 페이지로 롤업할 수 있습니다. 이러한 수준의 기능과 재사용성은 구조화된 콘텐츠 없이는 불가능합니다. 이제 재료 목록을 메인 요리용 섹션과 소스용 나머지 재료의 두 섹션으로 분할할 수 있는 레이아웃을 원한다고 가정해 보겠습니다. 1998년 스타일 하드 코딩된 접근 방식의 완전한 표현 제어를 통해 콘텐츠 작성자(다시 말하지만, HTML 파일을 직접 조작하는 것이 매우 편안하고 필요한 모든 페이지에서 이 작업을 수동으로 수행해야 함)는 테이블을 두 개로 빠르게 분할할 수 있었습니다. 특정 레시피에 대해 두 테이블 사이에 "소스" 라벨을 추가하면 완료됩니다. CMS의 구조화된 콘텐츠 접근 방식에서는 CMS 필드가 현재 허용되지 않기 때문에 CMS 인터페이스에서 지원하는 각 목록의 제목 필드와 함께 여러 재료 목록을 갖는 새로운 기능을 개발해야 합니다. 저것. CMS가 제공하는 놀라운 성능과 확장성에도 불구하고 이제는 CMS가 싫고 나쁘다고 생각합니다. 때로는 유연성 부족이 장애가 되기 때문입니다. 2018. 클라우드 서비스는 웹 개발자를 위한 "서버리스" 컴퓨팅 개념이 구체화될 정도로 널리 보급되었으며, 이를 통해 Headless CMS가 탄생했습니다. 컨텐츠와 프리젠테이션의 완전한 분리 — 헤드리스 CMS는 컨텐츠 만 캡처 하고 해당 컨텐츠가 웹에 어떻게 표시될지 또는 웹에 전혀 표시될지에 대해 전혀 가정하지 않습니다. Sanity.io의 Sanity CMS 이미지 — 이 Sanity 인스턴스는 콘텐츠 캡처만 위해 설계되었으며 프레젠테이션을 제안하는 필드가 없거나 웹 페이지 레이아웃에 전혀 공급되지 않는지 확인하세요. 기본적으로 Headless CMS는 프레젠테이션 유연성이 전혀 없는 구조화된 콘텐츠일 뿐입니다. 이로 인해 여러 디지털 채널을 지원하는 이상적인 CMS가 됩니다. 콘텐츠는 Headless CMS에서 웹 사이트로 게시될 수 있을 뿐만 아니라 디지털 간판, 모바일 앱 등으로 전송될 수도 있습니다. -독립적인 콘텐츠 구조가 정말 빛납니다. 토너먼트 결과를 업데이트한다고 상상해 보세요. Headless CMS에서 최종 경기 점수를 업데이트하면 웹 사이트, 이벤트의 디지털 간판 및 모바일 앱이 모두 한 번에 업데이트될 수 있으며, CMS는 결과에 대한 통제권을 전혀 부여하지 않기 때문에 결과가 어디에서나 잘못 형식화될 위험이 없습니다. 제시되며 영향을 미치지 않습니다. 대신 토너먼트 결과의 표현은 신중한 설계와 개발을 통해 각 매체에 반영됩니다. 물론 콘텐츠 작성자가 웹사이트에서 해당 결과 콘텐츠의 모양을 변경하려는 경우에는 변경할 수 없습니다. 프레젠테이션 유연성이 전혀 없습니다. 완전한 콘텐츠 구조. 이제 Headless CMS는 콘텐츠 구성 방식에 대해 의견이 없기 때문에 기존 2008 스타일 CMS처럼 작동하는 콘텐츠 모델을 절대적으로 개발할 수 있습니다. 약간의 추가 작업이 포함된 2008 스타일 CMS는 방정식에서 프레젠테이션 제어를 가져오기 위해 컨텐츠를 모델링할 수도 있습니다(이는 이전 레시피 예제의 경우였습니다). 따라서 이를 알면 하드코딩된 1998년 스타일 웹 사이트가 아닌 모든 프로젝트에는 항상 CMS가 콘텐츠를 구성하는 방법에 대한 계획이 필요합니다. CMS 디자인 작업은 아무도 그것에 대해 생각하지 않는다면 전적으로 개발자의 몫일 수 있지만 선택은 이루어져야 합니다. 적절한 균형을 맞추는 것은 어렵고 개발자가 잘 제작한 CMS는 프레젠테이션이 구조보다 더 중요한 콘텐츠 영역에서 유연한 프레젠테이션 제어와 콘텐츠가 가장 유용하기 위해 논리, 재사용 및 확장성이 필요한 엄격하게 구조화된 콘텐츠를 혼합할 가능성이 높습니다. 프리젠테이션 유연성과 콘텐츠 구조의 균형을 보여주기 위해 자주 묻는 질문이 포함된 웹 페이지를 구축하는 예를 살펴보겠습니다. 표현의 유연성을 염두에 두고 제작된 CMS에는 아코디언 구성 요소와 같이 작성자가 선택할 수 있는 다양한 구성 요소가 있을 수 있습니다. 웹의 아코디언 UI 패턴은 매우 일반적입니다. 제목을 탭하면 아래에 더 자세한 콘텐츠가 열립니다. 이 구성 요소는 웹 페이지에서 FAQ를 나타내는 데 사용될 수 있습니다. 아코디언 제목 필드는 FAQ의 질문으로 용도가 변경될 수 있으며 아코디언 기본 콘텐츠 필드는 답변이 될 수 있습니다. 이 구성 요소를 사용하면 이제 질문이 있는 만큼의 아코디언을 배치하여 FAQ 페이지를 만들 수 있습니다. 하지만 다른 페이지에서도 아코디언을 사용할 수 있으며, FAQ에 항상 그런 것은 아니지만 유용한 패턴이 될 수 있는 다른 유형의 콘텐츠일 수도 있습니다. 이 접근 방식을 통해 콘텐츠 작성자는 이제 전체 사이트에서 더 많은 레이아웃을 제어할 수 있습니다. 콘텐츠 작성자를 위한 프레젠테이션 유연성은 많지만 콘텐츠 구조는 거의 없습니다. 하지만 다양한 페이지에 FAQ를 표시 하고 웹 사이트의 모든 FAQ를 표시하는 필터링 가능한 중앙 페이지로 자동으로 이동하도록 하려고 한다고 가정해 보겠습니다 . 레이아웃 유연성을 허용하는 아코디언 구성 요소의 단점은 구성 요소 내의 콘텐츠가 FAQ인지 아니면 다른 것인지 실제로 알 수 없다는 것입니다. 법적 고지 사항을 숨기거나 계절별 판촉 행사를 진행하기 위해 웹 사이트에서 아코디언 구성 요소를 사용했을 수도 있습니다. 이는 개발자가 FAQ를 표시하기 위해 사이트 전체의 모든 아코디언 콘텐츠를 중앙 페이지로 자동으로 가져오는 페이지를 구축할 수 없다는 것을 의미합니다. 해당 페이지에 표시되는 내용이 FAQ인지 확인할 수 있는 방법이 없기 때문입니다. 그러나 프레젠테이션이 아닌 아코디언 구성 요소 대신 순전히 콘텐츠를 기반으로 FAQ를 작성한 CMS에서는 FAQ 질문 및 관련 FAQ 답변에 대한 필드가 명시적으로 있는 콘텐츠 유형을 갖게 됩니다. 콘텐츠 모델은 콘텐츠를 더욱 정확하게 반영하므로 이제 모든 FAQ를 한 페이지에 동적으로 가져오는 페이지를 가질 수 있습니다. 아코디언이나 다른 형식으로 표시될 수 있지만 이는 이제 콘텐츠 작성자가 프레젠테이션을 위해 선택한 것이 아니라 웹사이트용으로 개발된 형식에 따라 달라집니다. 콘텐츠 작성자에게는 프레젠테이션 유연성이 거의 없지만 콘텐츠 구조는 많습니다. 이는 콘텐츠를 정확하게 표현하는 데 집중하는 것과 CMS의 필드를 통해 프레젠테이션을 표현하는 것의 장단점입니다. 두 가지 유형의 콘텐츠 항목을 모두 원한다고 결정할 수도 있습니다 . 아코디언 구성 요소 및 FAQ 콘텐츠 유형. CMS 디자인이 왜 복잡한지 알 수 있습니다. 현재. 휴, 무사히 돌아왔습니다. 그리고 웹에 콘텐츠를 가져오는 과거의 세 가지 접근 방식이 오늘날에도 여전히 자주 사용되고 있다는 사실을 알면 놀랄 수도 있습니다. 그리고 세 가지 모두 훌륭한 접근 방식이 될 수 있습니다. 이를 검토해 보겠습니다. 프레젠테이션에 하드 코딩된 콘텐츠 완전한 표현 유연성… 그러나 실제로는 코드에 자신감이 있는 사람들에게만 해당됩니다. 콘텐츠 재사용 불가 확장이 어렵다 개발자가 사이트를 구축하고 모든 콘텐츠를 관리해야 함 프레젠테이션으로 구성된 콘텐츠 약간의 표현 유연성 일부 콘텐츠 재사용성 개발자는 CMS를 구축하고 필요에 따라 반복해야 하며, 콘텐츠 작성자는 개발자 없이 페이지 내에서 대부분의 콘텐츠를 관리하고 레이아웃을 일부 제어할 수 있습니다. 프리젠테이션에 구애받지 않는 콘텐츠 구조 표현 유연성 없음 모든 사용 사례 및 여러 디지털 채널에 완전히 재사용 가능한 콘텐츠 확장이 용이함 개발자는 CMS를 구축하고 필요에 따라 반복해야 하며 콘텐츠 작성자는 모든 콘텐츠를 관리할 수 있지만 개발자 없이는 레이아웃을 제어할 수 없습니다. 내 개인 웹사이트는 전적으로 1998년 빈티지 스타일로 만들어졌습니다. 웹사이트에서 사용하기 위해 콘텐츠를 CMS로 구조화하지 않고 대신 모든 콘텐츠와 스타일을 페이지에 직접 하드코딩했습니다. 단일 페이지 웹사이트를 만드는 외로운 웹 개발자를 위한 완벽한 솔루션이지만 마케팅 팀이 사이트를 대규모로 관리하는 것은 전혀 불가능합니다. 따라서 우리 모두에게 과제는 세 가지 접근 방식 모두의 균형을 유지하는 콘텐츠 관리 시스템을 만드는 것입니다. 즉, 작성자에게 유연성이 중요한 경우 프레젠테이션 제어 제공, 재사용 시 콘텐츠 구조화, 확장성 및 작성 용이성입니다. 강력한 테마와 시각적 요소를 위해 하드코딩된 요소를 혼합하여 작성자가 변경할 필요가 없습니다. 그리고 그 균형을 결정하는 것이 어느 시점에서는 CMS를 싫어하게 되는 이유입니다. 필요한 모든 방식으로 유연할 수는 없지만 동시에 필요한 모든 방식으로 구조화될 수는 없기 때문입니다. 그런데 왜? 왜 우리는 완벽한 균형을 이룰 수 없는 걸까요? 웹 사이트 요구 사항이 명확하고 개발자 팀이 웹 사이트에 맞게 CMS를 구성하고 사용하는 방법을 설계하고 개발하는 데 능숙하다면 CMS가 우리가 원하는 모든 기능을 수행할 수 없는 이유는 무엇입니까? 당신이 원하는 모든 것을 미리 알 수는 없습니다. 팀이 디지털 경험을 위해 제공해야 하는 가장 중요한 요구 사항을 식별하는 것은 충분히 어려운 작업일 수 있습니다. 귀하의 웹 사이트가 전자 상거래 비즈니스인 경우 요구 사항 수집에 초점을 맞춰야 콘텐츠 작성자가 Helvetica와 Helvetica 사이를 전환하는 도구를 가질 필요가 있는지 생각하기보다는 원활한 결제를 위해 최종 사용자에게 필요한 기능의 우선 순위를 정해야 합니다. 콘텐츠 제작에 있어서 Helvetica Nueue. 귀하의 요구 사항은 항상 변경됩니다. 콘텐츠 작성자를 방해하지 않기 위해 CMS에 필요한 모든 것을 문서화할 수 있다고 가정해 보겠습니다. 이처럼 예상치 못한 시나리오에서도 팀이 성공한다면 모든 것이 첫날에 예상했던 대로 정확하게 작동하게 될 것입니다. 하지만 둘째 날은 어떻습니까? 셋째 날? 귀하의 콘텐츠 요구 사항은 진화할 것이며, 그 다음 단계는 아무도 모릅니다. TikTok 소셜 캠페인을 시작하고 이제 이를 웹사이트에 삽입해야 할 수도 있습니다. 개발자의 참여 없이는 CMS가 지원하지 않는 계획할 수 없는 것들이 있습니다. 비용이 많이 듭니다. FAQ 예시로 돌아가 보겠습니다. 포괄적인 FAQ 시스템과 웹 사이트 전체에 배치할 수 있는 유연한 아코디언 구성 요소 등 모든 것을 가질 수 있습니다. 하지만 두 시스템을 모두 개발해야 합니다. 둘 다 필요합니까? 과연 어느 것이 우선순위일까요? 시간과 예산에 맞춰 프로젝트를 제공해야 한다는 제약으로 인해 앞서 언급한 옵션 중 하나가 필요할 수 있습니다. 하지만 이는 다른 옵션이 있었으면 좋겠다고 생각하는 때가 올 수도 있다는 의미이기도 합니다. 그리고 CMS를 구축하는 데 사용할 수 있는 시간과 돈이 있었음에도 불구하고 CMS가 책임이 있다고 생각할 수도 있습니다. 위험해요. 컨텐츠 작성자가 프레젠테이션과 다른 작업을 수행하기 위해 컨텐츠 구조에서 벗어나는 CMS의 권한이 많을수록 관리하기가 더 어려워집니다. 한 고객이 원했던 것처럼 CMS의 페이지 제목에 대한 색상 서식 지정 도구를 제공하는 것처럼 무해한 일이라도 작성자가 다른 색상을 필요로 할 경우를 대비해 문제가 발생합니다. 작성자는 좋아 보인다고 생각하는 색상으로 일부 텍스트를 처리할 수 있지만 접근성이 충분하지 않아 웹 사이트에 위험을 초래합니다. 이 문제를 완화하려면 전체 작성 팀이 CMS를 올바르게 사용하기 전에 접근성 검사기 사용에 대한 보다 강력한 교육이 필요합니다. 하지만 작성자가 접근성을 보장하는 데 능숙하더라도 브랜드가 발전하고 웹사이트의 색상을 변경해야 한다면 어떻게 될까요? 이제 기본값에서 색상이 변경된 모든 페이지 제목을 수동으로 찾아 업데이트해야 합니다. 한 자리도 놓치지 마세요! 웹은 너무 정교합니다 . 구조화된 콘텐츠를 허용할 뿐만 아니라 프레젠테이션의 제어 요소도 허용하는 2008 스타일 CMS(2018 스타일 헤드리스 대응과 달리)는 때때로 페이지 그리드 레이아웃 작성과 같은 개발자와 유사한 작업을 수행할 수 있도록 콘텐츠 작성자에게 복잡한 컨트롤을 확장하고 동적 보기를 만듭니다. 구조화된 콘텐츠를 만들거나 사용자 정의 스타일을 위한 CSS 코드 삽입을 허용합니다(위의 Drupal 이미지에는 HTML 코드 편집도 표시되어 있습니다). 매우 기술적이며 개발자와 유사한 콘텐츠 작성자는 잠재적으로 이러한 인터페이스를 사용하여 개발자의 개입 없이 CMS의 기능을 확장할 수 있습니다. 그리고 2008년 당시에는 그들의 노력이 받아들일만한 결과를 가져왔을 수도 있습니다. 하지만 당시에는 이것이 번거롭고 어려웠지만 오늘날에는 엄두도 못 낼 정도입니다. 다양한 장치 크기와 기능의 생태계, WCAG 2.1 AA 접근성 요구 사항이 보편화되고 기타 수많은 이유로 인해 이러한 도구는 허용 가능한 결과를 생성할 수 없습니다. 오늘날 사용자가 기대하는 경험을 제공하려면 적절한 설계, 개발 및 강력한 QA 테스트가 필요합니다. 따라서 귀하의 CMS는 형편 없습니다. 저작 능력과 유연성, 구조의 균형을 맞추기 위해 개발자가 전문적으로 사용자 정의한 현대적이고 유능한 CMS라도 때때로 여러분을 실망시키는 이유를 이제 이해하시기 바랍니다. 필연적으로 레이아웃을 다르게 보이도록 하거나, 색상을 변경하거나, 새로운 유형의 콘텐츠를 캡처하기를 원하지만 CMS 내 어느 곳에서도 해당 수준의 제어 권한이 부여되지 않는 시점이 있을 것입니다. 완벽한 세상에서는 필요할 때마다 제어할 수 있을 것이며 개발자 개입이나 품질 보증 테스트 없이도 모든 장치에 대해 반응적으로 작동하는 사이트의 새로운 레이아웃을 시작할 수 있을 것입니다. . 현실은 콘텐츠를 최신 웹으로 가져오는 것이 복잡하고 위에 나열된 실제적인 이유 중 하나로 인해 작성자가 현재 원하는 기능이 CMS에 없을 가능성이 높다는 것입니다. 그러나 CMS에 관계없이 작성자가 특정 콘텐츠의 색상을 변경하는 기능이 필요한 경우 개발자가 추가할 수 있습니다. 웹은 반복되도록 되어 있으며, 미래에 뭔가 필요할 것이라고 추측하기보다는 이러한 기능이 필요하다는 것을 알게 되면서 이러한 기능을 개발하는 것이 책임감 있는 접근 방식입니다. 아니면 CMS가 실제로 형편없을 수도 있습니다. 사이트가 발전함에 따라 쉽게 구현할 수 없는 CMS에 실제 문제가 있을 수 있습니다. CMS의 사용자 인터페이스는 작성자가 사용하기 어려울 수 있으며 개발자가 정밀 검사하는 것은 불가능하거나 비용이 많이 들 수 있습니다. CMS는 개발자가 콘텐츠 구조에 레이아웃 유연성을 허용하는 재사용 가능한 구성 요소 및 시스템을 생성하지 못하도록 콘텐츠를 구성하는 방법에 대한 특정 의견을 강요할 수 있습니다. CMS의 수명이 다해 업그레이드가 절실히 필요할 수 있습니다. CMS는 표시해야 하는 콘텐츠 유형에 비해 성능이 낮을 수 있습니다. CMS에는 개발자 커뮤니티가 축소되어 요구 사항이 발전함에 따라 성장할 수 있는 지원을 찾기 어려울 수 있습니다. 목록은 계속해서 이어집니다. 귀하의 CMS는 실제로 귀하의 요구에 적합하지 않을 수 있으며, 문제가 있는 경우 평가해야 할 사항입니다. 그러나 콘텐츠 작성자가 페이지 제목의 색상을 변경할 수 없다는 사실이 CMS가 나쁜 이유는 아닙니다. 그리고 이것이 제가 그 좌절된 사업에 대해 주고 싶었던 완전한 설명이었습니다.