홈페이지 제작이나 리뉴얼 일정이 밀리는 원인을 기술 구현 단계에서만 찾으면 해결이 어렵습니다. 목표, 페이지 우선순위, 콘텐츠, 승인 권한처럼 착수 전에 정리해야 할 결정이 남아 있으면 제작 중에도 새로운 요청과 검토가 반복될 수 있기 때문입니다.
특히 프로젝트 목표가 불명확하면 새 요청이 목표 달성에 필요한지 판단하기 어려워집니다. 그 결과 요구사항이 계속 늘어나는 범위 확장으로 이어질 수 있습니다. 반대로 산출물, 마일스톤, 범위 밖 항목을 문서화하면 포함·제외 항목에 대한 오해와 무단 요구사항 추가를 줄이는 데 도움이 됩니다.
홈페이지 제작을 시작하기 전에 고객사와 제작사가 함께 결정해야 할 사항을 8가지로 정리했습니다.
1. 홈페이지를 왜 만드는지 한 문장으로 정합니다
첫 번째 결정은 프로젝트의 목표입니다. “홈페이지를 새롭게 만든다”거나 “디자인을 개선한다”는 표현만으로는 제작 과정에서 무엇을 우선해야 하는지 판단하기 어렵습니다.
목표는 새로운 요청을 검토하는 기준이 될 수 있어야 합니다. 요청이 들어왔을 때 “이 기능이나 페이지가 합의한 목표에 필요한가?”라고 물을 수 있어야 범위를 관리하기 쉬워집니다. 발견 단계에서 사용자가 이루려는 목표와 기술·법률 등의 제약 조건을 파악해야 하는 이유도 여기에 있습니다.
2. 사용자가 해야 할 핵심 행동을 결정합니다
프로젝트 목표를 정했다면 홈페이지에서 사용자가 최종적으로 어떤 행동을 해야 하는지 합의해야 합니다. 문의, 신청, 예약, 구매, 자료 확인처럼 사이트의 성격에 따라 핵심 행동은 달라질 수 있습니다.
이 결정은 메뉴 구조와 페이지 구성, 콘텐츠 순서를 검토하는 기준이 됩니다. 사용자가 이루려는 목표를 먼저 파악하고 그 목표를 지원하는 방향으로 서비스를 설계하면, 단순히 넣고 싶은 정보를 나열하는 방식에서 벗어날 수 있습니다.
3. 반드시 먼저 완성할 페이지를 고릅니다
모든 페이지를 같은 중요도로 다루면 의견 충돌이 생겼을 때 판단 기준이 흐려질 수 있습니다. 착수 전에는 핵심 페이지와 후순위 페이지를 구분하고, 각 단계에서 무엇을 완성할지 합의하는 편이 좋습니다.
제품 관리자는 조직의 우선순위와 서비스의 미래 목표를 정하고, 각 작업 주기에서 사용자 스토리의 우선순위를 정하는 역할을 맡습니다. 홈페이지 프로젝트에서도 이와 마찬가지로 우선순위를 정할 담당자가 필요합니다. 모든 요청을 동시에 반영하기보다 프로젝트 목표와 사용자 요구를 기준으로 순서를 결정해야 합니다.
4. 기존 자료의 사용 가능 여부를 확인합니다
리뉴얼이라고 해서 기존 홈페이지의 모든 콘텐츠를 그대로 옮겨야 하는 것은 아닙니다. 콘텐츠 인벤토리와 감사를 통해 현재 보유한 페이지와 자료를 파악하고, 무엇을 이전하며 무엇을 제외할지 결정할 수 있습니다.
기존 자료를 검토할 때는 단순히 파일이나 원고가 존재하는지만 확인해서는 부족합니다. 새 홈페이지에서도 사용할 콘텐츠인지, 수정이 필요한지, 제외할 것인지 구분하고 각 판단을 책임질 담당자를 정해야 합니다. 콘텐츠 감사에는 담당자, 즉 소유권을 명확히 두는 것이 권장됩니다.
5. 콘텐츠 담당자와 제출 시점을 정합니다
콘텐츠는 디자인이 끝난 뒤 채워 넣는 부속물이 아닙니다. 콘텐츠 디자이너의 역할에는 사용자 요구를 바탕으로 한 콘텐츠 계획과 전략 수립, 콘텐츠의 정확성·관련성·접근성 검토가 포함됩니다.
따라서 회사 소개, 서비스 설명, 이미지, 정책 문서 등 필요한 자료마다 담당자를 정하고 제출 시점을 합의해야 합니다. 원고 작성자와 검토자가 다르다면 역할도 구분하는 것이 좋습니다. 담당자나 제출 시점이 정해지지 않은 콘텐츠는 제작 과정에서 계속 미결정 상태로 남을 수 있습니다.
6. 최종 의사결정권자와 승인 방식을 정합니다
여러 부서가 참여하더라도 최종 결정을 내릴 권한은 명확해야 합니다. 서비스 오너는 프로젝트 전반을 수행할 의사결정 권한을 가지고, 필요한 프로젝트 절차와 승인 절차가 지켜지도록 책임지는 역할을 맡습니다.
착수 전에는 누가 의견을 취합하고 누가 최종 승인하는지, 어떤 산출물을 어느 시점에 검토할지 정해야 합니다. 개별 구성원이 서로 다른 의견을 제작사에 직접 전달하는 방식보다 내부 의견을 정리한 뒤 승인된 피드백을 전달할 수 있는 체계를 만드는 것이 중요합니다.
7. 필요한 기능·연동·전환 조건을 확인합니다
홈페이지가 다른 서비스와 연결되어야 한다면 해당 조건을 개발 전에 확인해야 합니다. 구축 단계에서는 새 서비스가 기존 서비스와 어떻게 연동하거나 기존 서비스를 어떻게 대체할지 함께 검토해야 하기 때문입니다.
착수 전에는 필요한 기능과 연동 대상, 기존 시스템을 유지할지 대체할지, 전환할 자료가 무엇인지 정리해야 합니다. 기술적 제약뿐 아니라 발견 단계에서 확인해야 할 법률 등의 제약 조건도 함께 검토 대상에 포함할 수 있습니다.
8. 범위 정의서와 변경 요청 절차를 합의합니다
앞의 일곱 가지를 결정했다면 산출물, 마일스톤, 포함 범위와 제외 범위를 문서로 남겨야 합니다. 범위 정의서는 고객사와 제작사가 같은 기준으로 프로젝트를 이해하도록 돕고, 제작 중 추가 요청이 발생했을 때 판단 근거가 됩니다.
추가 요청을 모두 거절해야 한다는 뜻은 아닙니다. 변경 요청은 일정·예산·자원에 미치는 영향을 평가한 뒤 승인, 거절, 연기 또는 기존 범위와의 교환 중 하나로 결정할 수 있습니다. 누가 언제 어떤 이유로 결정했는지도 기록하면 변경 이력을 관리하기 수월합니다.
착수 전 최종 체크리스트
목표와 우선순위
① 프로젝트 목표를 한 문장으로 설명할 수 있는가?
② 사용자가 홈페이지에서 해야 할 핵심 행동이 정해졌는가?
③ 먼저 완성할 핵심 페이지와 후순위 페이지가 구분되어 있는가?
콘텐츠와 담당자
④ 기존 콘텐츠 중 이전·수정·제외할 항목을 구분했는가?
⑤ 새 콘텐츠의 작성자, 검토자, 제출 시점을 정했는가?
승인과 개발 범위
⑥ 최종 의사결정권자와 승인 절차가 명확한가?
⑦ 필요한 기능, 외부 연동, 기존 서비스의 전환 조건을 확인했는가?
⑧ 포함·제외 범위와 변경 요청 처리 방식을 문서화했는가?
일정은 제작 전에 정한 기준에서 시작됩니다
홈페이지 제작 일정은 화면을 디자인하거나 기능을 개발하는 단계에서만 관리되는 것이 아닙니다. 목표와 우선순위, 콘텐츠 책임자, 승인 권한, 연동 조건과 변경 절차를 착수 전에 얼마나 분명하게 합의했는지가 프로젝트 운영의 기준이 됩니다.
모든 세부 사항을 처음부터 확정하기는 어렵더라도, 무엇이 결정되었고 무엇이 아직 미정인지 구분해 두는 것은 가능합니다. 미정 사항에는 담당자와 결정 시점을 정하고, 새로운 요청에는 합의된 목표와 범위를 적용해야 합니다. 이 준비가 갖춰져야 제작 과정의 판단도 일관성을 유지할 수 있습니다.
참고 자료
Atlassian: Scope creep
GOV.UK Service Manual: Content designer
Nielsen Norman Group: Content audits
Defra Digital: Working in discovery
Defra Digital: Working in beta