홈페이지 CMS로 어디까지 수정하게 할지 정하는 실무 설계

“개발사에 매번 연락하지 않고 고치고 싶은데, 어디까지 관리자 기능으로 만들어야 할까요?”

“전담 운영자도 없는데 모든 화면을 편집하게 해두면 오히려 관리가 어려워지지 않을까요?”

홈페이지 CMS의 범위는 담당자가 반복해서 바꾸고, 변경 결과까지 확인할 수 있는 작업을 중심으로 정하는 것이 좋습니다. 모든 화면을 자유롭게 편집하게 하기보다 직접 수정할 콘텐츠와 개발 검토가 필요한 구조 변경의 경계를 먼저 그어야 합니다.

CMS는 콘텐츠 관리 시스템입니다. 공지나 제품 소개를 작성하고 발행하는 데 쓰지만, 관리자 페이지에는 문의 배정이나 계정 관리처럼 콘텐츠 편집과 다른 업무도 들어갑니다. 두 범위를 한꺼번에 ‘관리자 기능 일체’라고 적으면 무엇을 납품받아야 하는지 흐려집니다.

저는 크로플에서 웹과 앱 수탁 개발의 개발 총괄과 프로젝트 관리를 맡고 있습니다. 50건 이상의 SI 수탁개발을 수행하며 유지해 온 설계 원칙은, 무엇을 만들지와 함께 무엇을 만들지 않을지도 명시하는 것입니다. 홈페이지 CMS에도 같은 원칙을 적용합니다.

홈페이지의 모든 영역을 직접 수정할 수 있어야 하나요?

반복해서 교체하는 콘텐츠는 직접 수정하게 하되, 화면 구조까지 자유롭게 바꾸는 기능은 실제 운영 필요가 있을 때 포함하는 편이 좋습니다. ‘직접 운영’과 ‘모든 것을 자유롭게 편집’은 요구 범위가 다릅니다.

회사 소개 문구를 고치는 일과 메인 화면에 새로운 구성을 추가하는 일은 다릅니다. 앞의 작업은 정해진 칸의 내용을 바꾸지만, 뒤의 작업은 배치와 모바일 표시 방식까지 다시 판단해야 합니다.

범위를 정할 때 저는 페이지 이름보다 변경 단위를 적습니다. ‘메인 페이지 관리’ 대신 ‘대표 문구 수정, 대표 이미지 교체, 연결할 페이지 선택’으로 나누는 식입니다.

이 표는 보편적인 정답이 아니라 초기 협의를 위한 예시입니다. 캠페인마다 화면을 새로 구성하는 팀이라면 편집 가능한 블록이 필요할 수 있고, 소개 내용만 가끔 바꾸는 기업이라면 정해진 입력 항목으로도 충분할 수 있습니다.

정해진 입력 항목과 재사용 가능한 콘텐츠 유형으로 편집 범위를 제한하는 방식은, 자유 편집에 비해 표시 형식의 일관성을 유지하도록 설계할 수 있습니다. 다만 실제 효과는 템플릿과 입력 검증 방식에 달려 있습니다.

페이지 전체를 관리 대상으로 적기보다, 담당자가 바꿀 값과 바꿀 수 없는 구조를 함께 적으세요.

CMS와 별도 관리자 기능은 어디에서 나누나요?

외부에 공개할 내용을 관리하는 일은 CMS로, 접수된 일을 처리하고 상태를 바꾸는 일은 업무 관리 기능으로 나누면 범위를 설명하기 쉽습니다. 두 기능이 같은 관리자 화면 안에 있어도 담당자와 처리 규칙은 별도로 정의해야 합니다.

예를 들어 제품 소개를 발행하는 기능에는 제목, 이미지, 설명, 공개 여부가 필요합니다. 반면 제품 문의를 처리하는 기능에는 접수 내역, 담당자, 처리 상태, 내부 메모가 필요할 수 있습니다. ‘제품 관련 관리’라는 이유로 묶으면 서로 다른 요구사항이 빠지기 쉽습니다.

이 구분은 프로그램을 반드시 두 개로 만들라는 뜻이 아닙니다. 하나의 관리자 안에서도 콘텐츠 메뉴와 업무 메뉴를 나누고, 같은 제품 정보를 연결해서 사용할 수 있습니다.

저는 시스템 설계에서 하나의 데이터 모델을 여러 화면이 함께 사용하도록 구성하는 원칙을 중시합니다. 제품명 하나를 홈페이지와 문의 관리 화면에서 각각 입력하게 만들기보다, 동일한 제품 정보를 참조할 수 있는지 먼저 살핍니다. CMS와 업무 관리의 경계가 데이터 중복으로 이어져서는 안 됩니다.

권한도 메뉴 이름만으로 끝내지 않아야 합니다. 조회, 수정, 발행, 삭제를 각각 누가 할 수 있는지 정하고, 서버에서도 요청마다 해당 권한을 검증해야 합니다. 화면에서 버튼을 숨기는 것만으로 접근 통제를 대신할 수는 없습니다.

따라서 견적 요청서에는 ‘CMS 포함’ 한 줄 대신 콘텐츠 편집 범위, 문의 처리 범위, 계정별 허용 작업을 나누어 적는 편이 명확합니다.

전담 운영자가 없으면 어느 정도까지 만들어야 하나요?

전담 운영자가 없다면 가능한 기능을 넓히기보다, 기존 담당자가 끝까지 수행할 수 있는 수정 작업부터 포함하세요. 기능을 만드는 것과 그 기능으로 운영이 이루어지는 것은 별개의 문제입니다.

범위 협의에서는 수정 빈도만 묻지 않습니다. 누가 원고를 준비하는지, 이미지가 없으면 어떻게 하는지, 발행 뒤 누가 확인하는지도 묻습니다. 매주 수정하는 콘텐츠라도 준비할 사람이 없다면 편집 화면만으로 해결되지 않습니다.

제조기업 홈페이지를 예로 들어보겠습니다. 다음은 범위를 설명하기 위한 가상 상황입니다. 담당자는 처음에 ‘제품 페이지를 자유롭게 꾸밀 수 있으면 좋겠다’고 요청합니다. 하지만 실제 작업은 제품 사진과 규격표를 바꾸는 일이 대부분이고, 디자인을 판단할 사람은 따로 없습니다.

제가 이 상황을 맡는다면 제품명, 소개, 사진, 규격, 첨부파일처럼 반복되는 항목부터 고정하겠습니다. 담당자는 정해진 위치에 내용을 넣고 결과를 확인합니다. 반대로 제품마다 소개 순서가 달라야 한다는 필요가 확인되면, 그때 재배치 가능한 블록의 범위를 협의합니다.

이렇게 범위를 좁히면 최초의 ‘자유 편집’ 요청은 ‘제품 정보를 혼자 교체하고 확인하는 작업’으로 바뀝니다. 중요한 변화는 기능 수가 아니라 담당자가 완료해야 할 일이 분명해지는 데 있습니다.

초기 범위를 결정할 때는 다음 질문에 답해보세요.

• 최근 실제로 바꾼 내용과 앞으로 반복해서 바꿀 내용은 무엇인가?
• 원고와 이미지는 누가 준비하며, 부재 시 누가 대신하는가?
• 수정 즉시 공개해도 되는가, 다른 사람의 확인이 필요한가?
• 잘못 발행했을 때 되돌릴 방법과 담당자가 있는가?

답이 없는 기능은 곧바로 삭제하기보다 ‘추후 결정’으로 남겨두는 편이 좋습니다. 지금 구현할 범위와 확장 가능성을 구분하면 됩니다.

개발 요청서에는 수정 범위를 어떻게 적어야 하나요?

기능 이름 옆에 정상 작업, 허용하지 않을 입력, 실수했을 때의 처리를 함께 적으세요. ‘배너 관리 가능’이라는 문구만으로는 개발사와 담당자가 같은 완료 상태를 떠올리기 어렵습니다.

제가 구현 브리프를 작성할 때는 무엇을 만들지 못지않게 완료 조건을 구체화합니다. 홈페이지 CMS라면 실제 운영자가 수행할 한 번의 수정 과정을 기준으로 삼을 수 있습니다.

예를 들어 ‘대표 배너 교체’는 다음처럼 적습니다.

1. 담당자는 대표 문구, 이미지, 연결할 페이지를 수정할 수 있다.
2. 문구 길이와 이미지 업로드 조건은 합의한 제한을 따른다.
3. 저장과 공개를 구분할지, 저장 즉시 반영할지 결정한다.
4. 발행 전 확인이 필요하면 실제 화면에 가까운 미리보기를 제공한다.
5. 잘못된 내용을 공개했을 때 이전 값 복원 또는 재수정 절차를 정한다.
6. 배너의 위치 변경이나 새로운 디자인 추가는 이번 범위에서 제외한다.

위 항목이 모든 프로젝트의 필수 기능은 아닙니다. 미리보기나 변경 이력을 제공하지 않는다면, 담당자가 무엇을 어떻게 확인하고 복구할지 대체 절차를 합의해야 한다는 의미입니다.

검수도 버튼의 존재보다 작업의 완료를 확인하는 방식으로 구성하는 것이 좋습니다. 실제 담당자가 콘텐츠를 입력하고 공개 결과를 확인하는 과업 기반 사용성 점검은, 기능 목록 확인만으로 드러나지 않는 사용상의 문제를 찾는 데 도움이 될 수 있습니다.

개발 완료 전에 담당자가 사용할 문구와 이미지로 이 과정을 직접 실행해보세요. 업로드는 되지만 결과를 확인할 수 없거나, 공개한 내용을 내릴 수 없다면 운영 범위에 빈칸이 있는 것입니다.

결론

홈페이지 CMS는 담당자가 반복할 수정 작업을 기준으로 범위를 정하고, 구조 변경과 업무 처리는 별도로 명시하는 것이 좋습니다. 관리자 메뉴가 많다는 이유만으로 직접 운영할 수 있는 홈페이지가 되는 것은 아닙니다.

먼저 최근 수정 요청 몇 가지를 꺼내 각각 ‘바꿀 값, 담당자, 공개 방법, 실수 시 처리’로 적어보세요. 이 내용이 분명한 작업부터 CMS에 포함하고, 화면 구조를 바꾸는 요청은 별도 개발 범위로 검토하면 됩니다.

관리자 기능의 완료 기준은 수정 버튼의 개수가 아니라, 담당자가 변경부터 확인까지 마칠 수 있는가입니다.

자주 묻는 질문

기존 CMS를 쓰면 별도 관리자 개발은 필요 없나요?

기존 CMS가 필요한 업무까지 지원하는지에 따라 달라집니다. 콘텐츠 작성은 지원하더라도 문의 배정이나 내부 처리 상태 관리는 별도 구현이 필요할 수 있습니다. 제품 이름보다 실제 운영 시나리오를 기준으로 확인하세요.

처음 제외한 수정 기능을 나중에 추가할 수 있나요?

추가할 수 있지만 기존 데이터와 화면 구조에 따라 변경 범위가 달라집니다. 추후 필요할 가능성이 있는 콘텐츠 유형은 초기 협의 때 알려두고, 확장 준비와 실제 기능 구현을 구분해서 요청하는 편이 좋습니다.

기존 게시물을 옮기는 작업도 CMS 개발에 포함되나요?

자동으로 포함되는 것은 아니므로 이전 범위를 따로 확인해야 합니다. 옮길 게시물, 이미지와 첨부파일, 분류 체계, 이전 후 확인 담당자를 적어두면 CMS 구축과 콘텐츠 이전 사이의 누락을 줄일 수 있습니다.

제 도움이 필요하시다면

수정하고 싶은 항목은 많지만 CMS와 별도 개발의 경계를 정하기 어렵다면, 실제 운영 작업부터 함께 정리할 수 있습니다. 크로플에서는 웹 수탁 개발과 프로젝트 관리 경험을 바탕으로 콘텐츠 편집 항목과 업무 관리 기능을 구분하고, 구현 브리프와 검수 시나리오로 구체화하는 일을 돕습니다.

기존 홈페이지에서 자주 요청했던 수정 내용, 현재 담당자의 역할, 새 홈페이지에서 직접 처리하고 싶은 작업을 준비해 주세요. 이를 바탕으로 이번에 만들 범위와 이후로 남길 기능을 나누어 검토할 수 있습니다.