웹사이트에 맞춤 CMS가 필요한 시점은 언제일까요?

기사 하나를 처음부터 끝까지 따라가 보세요

팀이 CMS에서 기사를 작성하지만 검토를 위해 이메일로 문서를 주고받거나, 나중에 사실을 정정해도 기본 웹사이트에만 반영되고 다른 언어에는 빠진다면 시스템을 바꾸기 전에 기사 하나를 전체 게시 과정에 넣어 보세요. 어디에서 작업이 끊기는지 보면 무엇을 바꿔야 할지 알 수 있습니다.

CMS(콘텐츠 관리 시스템)는 웹사이트에 사용할 콘텐츠를 준비하고 관리하는 곳입니다. 맞춤형 시스템이 필요한지는 게시 후의 작업까지 포함해 어떤 일을 지원해야 하는지에 달려 있습니다.

두 웹사이트에 두 언어로 기사를 준비하는 가상의 출판사를 생각해 보세요. 작성자가 기사를 만들고, 편집자가 검토한 뒤, 게시 편집자가 게시 시점을 정합니다. 이후 팀은 사실 하나를 정정하고 기사의 일부를 다른 콘텐츠에 재사용합니다. 가상의 기사 하나를 정해 실제 담당자들과 함께 전체 과정을 살펴보세요.

작성: 콘텐츠를 유용한 곳에 담기

작성자에게 제목, 본문, 이미지, 캡션, 출처 표시와 다른 페이지에서 필요할 수 있는 정보를 입력하게 하세요. 그런 다음 해당 항목을 찾아 수정하게 해 보세요. 출처 표시가 캡션 안에만 있다면 이미지를 재사용할 때 찾을 수 있을까요?

구조화된 콘텐츠란 작성자, 행사 날짜, 제품 사양처럼 정보를 각각의 필드에 저장해 시스템이 일관되게 활용하도록 하는 것입니다. 그런 필드가 필요하다고 해서 맞춤형 CMS가 꼭 필요한 것은 아닙니다. 예를 들어 WordPress는 콘텐츠 유형별로 사용할 수 있는 사용자 정의 글 유형을 문서로 안내합니다.

현재 CMS를 관리하는 사람에게 예시를 어떻게 처리하는지 보여 달라고 하세요. 필드 하나가 없는 문제와 동일한 원문 기사를 각 언어 버전에 연결할 수 없는 문제처럼 더 근본적인 문제를 구분하세요. 서로 다른 변경이 필요할 수 있습니다.

검토와 수정: 결정 과정을 명확히 하기

편집자가 수정 요청을 적어 초안을 돌려주게 하세요. 작성자가 수정한 뒤 다시 제출합니다. 두 사람 모두 지금 검토 중인 버전을 알 수 있나요? 게시 편집자는 작성자에게 게시 권한을 주지 않고도 해당 버전을 승인할 수 있나요?

기존 CMS 제품에는 이미 역할을 구분하는 기능이 있습니다. WordPress의 역할 및 권한 문서는 편집, 게시, 관리 권한이 서로 다름을 설명합니다. 따라서 편집자가 여러 명이라면 권한을 확인해야 하지만, 이것만으로 시스템을 다시 만들어야 한다고 볼 수는 없습니다.

역할만으로는 전체 승인 절차를 알 수 없습니다. 이 예시에서 승인 후 문단 하나를 바꾸고 어떤 일이 일어나는지 확인하세요. 변경 사항이 다시 검토되어야 하는지, 누가 예외를 허용할 수 있는지, 팀이 그 결정을 어떻게 확인할지 정하세요. 작성자와 편집자가 실제로 사용할 계정으로 공급업체의 시연을 요청하세요.

예약: 게시될 버전을 확인하기

게시 편집자가 승인된 기사의 게시 일정을 예약하게 하세요. 그런 다음 예정 시간 전에 마지막으로 수정합니다. 이제 어떤 버전이 예약되어 있나요? 해당 언어 버전도 준비되었나요? 한 웹사이트가 먼저 게시되고 다른 곳은 기다릴 수 있나요?

소프트웨어를 시험하기 전에 원하는 답을 적어 두세요. 출판사는 두 언어를 동시에 게시하도록 요구할 수도 있고 각각 다른 일정으로 올릴 수도 있습니다. 모두 편집상 타당한 선택입니다. CMS는 어떤 일이 일어날지 팀에 보여 주고 적절한 담당자가 일정을 바꿀 수 있게 해야 합니다.

제대로 된 시연에는 기사 게시를 연기하고 예정된 각 웹사이트의 공개 미리보기를 확인하는 과정이 포함되어야 합니다. 날짜 필드 하나만으로 전체 게시 절차가 작동한다고 볼 수 없습니다.

정정과 재사용: 게시 후에도 작업은 계속됩니다

이 예시에서 독자는 다음 날 사실 오류를 발견합니다. 게시된 기사는 계속 공개된 상태로 두고 편집자가 정정 내용을 준비하게 하세요. 누가 변경을 승인할 수 있는지, 이전 문구를 복원할 수 있는지, 정정 사유를 어떻게 기록하는지 확인하세요.

다음으로 정정 내용이 다른 언어와 웹사이트에도 반영되었는지 따라가 보세요. 팀은 어떤 버전을 처리해야 하고 담당자가 누구인지 알아야 합니다. 공통 날짜나 사양은 자동 변경이 적합할 수 있지만 번역 문장은 누군가 수정하고 승인해야 할 수 있습니다. 무엇을 공유하고 어떤 항목은 별도의 편집 판단이 필요한지 정하세요.

마지막으로 문단과 이미지를 새 기사에 재사용해 보세요. 문단이 원문에 계속 연결되어야 하나요, 아니면 독립적인 사본이 되어야 하나요? 원문이 다시 바뀌면 새 기사도 바뀌어야 할까요, 알림을 받아야 할까요, 그대로 두어야 할까요? 팀에 자료를 재사용할 권리가 있는지도 확인하세요. CMS 기능이 콘텐츠 사용 권한을 부여하지는 않습니다.

시연 결과를 격차 목록으로 정리하기

각 단계에서 실제로 일어난 일을 기록하세요. 항목별로 필요한 동작, 현재 설정에서 시연된 것, 부족한 점, 제안하는 변경 사항과 유지보수 담당자를 적으세요. 현재 작동하는 기능도 목록에 남겨 대체안이 이를 유지하도록 하세요. 가상의 출판사라면 다음과 같은 항목이 있을 수 있습니다.

현재 CMS, 확장 기능, 맞춤 개발 비교하기

먼저 현재 CMS로 격차 목록을 검토하세요. 설정 변경, 더 명확한 편집 화면, 기존 기능을 사용하는 방식의 조정으로 일부를 해결할 수 있습니다. 실제 운영 중인 버전과 설정에서 결과를 확인하세요.

남은 격차에 대해서는 지원되는 확장 기능이 무엇을 할 수 있는지 물어보세요. 승인 후 수정과 게시 후 정정까지 같은 기사 흐름을 공급업체가 시연하게 하세요. 확장 기능을 누가 유지보수하고, CMS 업데이트 후 누가 점검하며, 호환성 문제를 누가 해결하는지 확인하세요. 게시나 정정이 실패했을 때 누가 알아채고 처리할지도 정하세요. 기능을 추가하면 누군가 관리해야 할 일도 늘어납니다.

필수 규칙을 적절히 처리할 수 없거나 필요한 추가 기능 때문에 팀이 합리적으로 유지보수하기 어려워지는 경우 맞춤 개발을 진지하게 고려할 수 있습니다. 기존 CMS를 위한 전용 확장 기능이나 별도의 맞춤 시스템일 수 있습니다. 격차 목록은 어느 정도를 개발해야 할지 정하는 데 도움이 됩니다.

초기 비용뿐 아니라 업데이트, 권한, 백업과 복구, 편집 교육, 지원, 시스템을 떠날 때 콘텐츠를 내보내는 작업도 비교하세요. 샘플 내보내기를 받아 필요한 필드, 관계, 미디어, 언어 버전, 유용한 수정 이력이 포함되는지 살펴보세요. 기존 제품과 맞춤 개발안 모두에 이 절차를 적용하세요.

영국 정부의 기술 구매 지침은 요구 사항과 지속적인 공급업체 관리를 함께 고려하면서 기존 제품을 조정하거나 소프트웨어를 구축하는 방안을 다룹니다. 이런 폭넓은 질문을 하는 데 참고가 되지만 해당 출판사에 맞는 CMS를 정해 주지는 않습니다.

공개 웹사이트 개편은 별도로 판단하기

독자는 기사 페이지, 탐색 메뉴, 검색을 봅니다. 편집자는 필드, 검토 단계, 게시 제어를 사용합니다. 둘 다 중요하고 서로 연결될 수 있지만 공개 디자인이 오래되었다고 해서 편집 시스템도 바꿔야 하는 것은 아닙니다.

공개 화면의 변경 사항과 편집 과정의 격차를 따로 설명하세요. 어떤 작업을 독립적으로 진행할 수 있고 어디에서 서로 의존하는지 물어보세요. 그러면 새 기사 레이아웃을 논의하다가 이미 잘 작동하는 게시 절차 전체를 교체하는 일로 조용히 번지는 것을 막을 수 있습니다.

저희는 맞춤 CMS 개발을 제공합니다. 무엇을 바꿔야 할지 함께 살펴보고 싶다면 대표 기사 하나와 그 여정에서 발견한 격차 목록을 준비해 주세요. 범위, 라이선스, 인수인계, 지속적인 관리는 프로젝트별로 합의합니다.

CMS를 선택하기 전에 물어볼 질문