웹사이트 개편 범위는 목표·페이지·콘텐츠·기능·운영 책임을 검수 기준으로 바꾸어 정해야 합니다. “전체 리뉴얼”이나 “세련된 디자인”처럼 넓은 표현만으로 시작하면 제안사마다 해석이 달라지고 계약 뒤 추가 업무가 늘어납니다. 관리 책임자는 화면 취향을 정하기 전에 왜 개편하는지, 어떤 정보를 옮길지, 누가 승인하고 운영할지를 문서로 고정해야 합니다.
이번 개편이 해결해야 할 문제는 무엇입니까?
오래돼 보인다는 판단만으로는 우선순위를 정하기 어렵습니다. 검색에서 회사가 나오지 않는지, 모바일에서 제품 정보를 찾기 힘든지, 문의가 담당 부서로 전달되지 않는지, 관리자가 내용을 수정할 수 없는지 문제를 구체적으로 적습니다. 문제마다 현재 화면과 데이터를 근거로 남기면 개편 뒤 같은 조건으로 확인할 수 있습니다.
목표는 “좋아진다”가 아니라 사용자의 행동과 운영 상태로 표현합니다. 핵심 서비스를 빠르게 찾고, 제품 조건을 비교하고, 적합한 문의를 보내며, 담당자가 승인된 콘텐츠를 수정할 수 있어야 합니다. 검색 색인과 AI 인용을 목표로 삼는다면 대표 주소, 메타 정보, 구조화 데이터, 질문형 콘텐츠와 측정 환경도 처음부터 범위에 포함합니다.
목표가 여러 개라면 충돌을 확인합니다. 화려한 첫 화면이 중요 정보를 늦게 보여줄 수 있고, 문의 항목을 지나치게 줄이면 영업 분류가 어려워질 수 있습니다. 경영진, 영업, 콘텐츠, 개발 담당자가 각자 원하는 결과를 적고 필수와 선택으로 구분해야 합니다. 무상 사전 진단으로 현재 상태를 먼저 확인하면 추상적인 요구를 실제 문제로 바꾸기 쉽습니다.
목표별 책임자와 판단 기한도 함께 정합니다. 서로 다른 부서의 요청이 충돌하면 최종 승인자가 어느 기준으로 결정하는지 기록하고, 보류한 요구는 삭제하지 말고 후속 단계 후보로 분리합니다. 이렇게 해야 착수 뒤 오래된 구두 요청이 필수 범위로 되돌아오는 일을 줄일 수 있습니다.
결정 기록에는 요청 부서, 근거 자료와 승인 결과를 함께 둡니다. 이후 같은 요구가 다시 제기돼도 처음부터 논의를 반복하지 않고 당시의 조건과 현재의 변화를 비교할 수 있습니다.
필수 페이지와 선택 페이지는 어떻게 구분합니까?
페이지 목록은 경쟁사 메뉴를 복사해 만들지 않습니다. 회사 소개, 서비스와 제품, 근거, 문의처럼 고객이 판단할 정보와 법적 고지, 운영에 필요한 콘텐츠 유형을 먼저 정합니다. 각 페이지에는 목적, 주요 독자, 답해야 할 질문, 연결할 다음 페이지를 적습니다. 목적이 같은 페이지가 여러 개라면 통합 가능성을 검토합니다.
고정 페이지와 반복 페이지를 구분합니다. 회사 소개처럼 구조가 한 번 정해지는 문서와 제품, 사례, 인사이트처럼 계속 추가되는 문서는 제작과 관리 방식이 다릅니다. 반복 페이지는 템플릿 필드와 목록, 상세 화면, 분류 기준, 대표 이미지 규격을 함께 정의해야 합니다. 화면 한 장만 승인하고 데이터 구조를 정하지 않으면 운영 단계에서 레이아웃이 쉽게 깨집니다.
다국어는 단순 번역 분량으로만 계산하지 않습니다. 언어별 제품 범위와 법적 정보, 연락처, 검색어가 같은지 판단하고 각 언어의 대표 주소와 전환 경로를 설계합니다. 준비되지 않은 언어 페이지를 빈 상태로 공개하지 않습니다. 실제 표준 구축 범위는 홈페이지 구축 범위에서 포함 기준과 함께 확인할 수 있습니다.
기존 콘텐츠는 무엇을 이관해야 합니까?
현재 사이트의 모든 주소와 파일을 목록으로 만듭니다. 유지, 수정, 통합, 삭제, 보관으로 분류하고 각 판단의 책임자를 정합니다. 방문이나 문의가 있는 페이지, 외부 링크를 받는 페이지, 법적 보관이 필요한 문서는 단순히 오래됐다는 이유로 삭제하지 않습니다. 새 주소로 바뀌면 이전 주소와의 대응표도 함께 준비합니다.
이관 대상에는 본문만 있는 것이 아닙니다. 제목과 검색 설명, 대표 이미지, 첨부파일, 제품 사양, 문의 연결, 작성일과 수정일, 구조화 데이터도 확인해야 합니다. 이미지 사용 권한과 원본 보유 여부를 검토하고 작은 해상도나 워터마크가 있는 파일은 대체 계획을 세웁니다. 다운로드 파일에만 있는 핵심 정보는 웹 본문에도 요약할지 판단합니다.
콘텐츠 정리는 현업 검수가 필요합니다. 제작사가 제품 조건과 회사 실적을 추측하도록 두지 않고 내부 책임자가 최신 값을 확인합니다. 서로 다른 문서에 같은 수치가 다르게 적혀 있다면 단일 원천을 정합니다. 이관 목록이 확정되기 전에 디자인부터 진행하면 화면은 완성됐지만 넣을 정보가 없는 상태가 생길 수 있습니다.
기능 요구사항은 어떤 문장으로 써야 합니까?
“문의 기능 필요”보다 누가 어떤 정보를 입력하고 어느 담당자가 어떤 방식으로 받는지 적습니다. 필수 항목, 개인정보 동의, 저장 위치, 알림 메일, 오류 처리, 스팸 방지, 완료 화면을 정의합니다. 외부 API와 데이터베이스를 사용한다면 장애가 났을 때 사용자에게 무엇을 보여주고 어떻게 복구할지도 범위에 포함합니다.
검색, 필터, 다운로드, 지도, 회원 기능도 입력과 결과를 구체적으로 적습니다. 필터 항목과 데이터가 실제로 준비돼 있는지, 모바일 조작이 가능한지, 결과가 없을 때 안내가 있는지 확인합니다. 관리자 기능은 수정 가능한 필드와 권한, 승인 절차, 변경 이력을 정의합니다. “관리자 제공”만으로는 운영 가능성을 판단할 수 없습니다.
분석 도구와 검색엔진 연동도 기능 요구사항입니다. 소유확인, 사이트맵, robots.txt, RSS, 이벤트 측정, UTM 분리 저장이 필요한지 적습니다. API 키와 비밀번호는 코드나 문서에 넣지 않고 배포 환경의 비밀 변수로 관리합니다. 기능 완료 조건은 버튼이 보이는 것이 아니라 실제 제출, 저장, 알림과 오류 상황이 검증되는 것입니다.
디자인 요구사항은 어떻게 전달합니까?
참고 사이트는 그대로 복제할 대상이 아니라 원하는 특성을 설명하는 자료로 사용합니다. 정보 밀도, 여백, 사진 비중, 타이포그래피, 움직임, 탐색 방식 중 무엇이 필요한지 적고 회사 주제와 다른 요소는 제외합니다. 경쟁사와 같은 구조를 그대로 따라가면 브랜드 구분이 약해지고 실제 콘텐츠 양과 맞지 않을 수 있습니다.
색상과 글꼴은 취향뿐 아니라 접근성과 운영성을 고려합니다. 본문 대비, 작은 화면의 글자 크기, 버튼 상태, 오류 메시지, 키보드 초점을 확인합니다. 이미지가 많다면 촬영과 생성 원칙, 화면 비율, 대체 텍스트, 파일 용량을 정합니다. 한 장의 대표 시안뿐 아니라 목록, 상세, 폼, 표와 긴 본문에서 같은 시스템이 유지되는지 봅니다.
반응형 기준도 명시합니다. 데스크톱을 줄인 화면이 아니라 모바일에서 중요한 정보와 행동이 어떤 순서로 나오는지 설계합니다. 메뉴가 열리고 닫히는지, 표가 읽히는지, 입력 중 키보드에 버튼이 가려지지 않는지 실제 기기 크기로 검수합니다. 디자인 승인은 정지 화면보다 구현된 페이지의 동작과 콘텐츠 상태를 기준으로 해야 합니다.
SEO·AEO·GEO 요구는 어디에 포함합니까?
검색과 AI 노출은 마지막에 메타 태그를 추가하는 별도 장식이 아닙니다. 페이지 역할과 주소 구조, 제목, 첫 문단, 질문형 소제목, 내부 링크, 회사 정보와 출처가 기획 단계부터 연결돼야 합니다. 대표 도메인은 환경 설정의 단일 값에서 생성하고 canonical, 오픈그래프, 사이트맵과 구조화 데이터가 같은 주소를 사용하게 합니다.
콘텐츠 유형마다 메타 필드와 스키마를 정의합니다. 조직과 웹사이트, 글의 식별자를 안정적으로 연결하고 화면에 없는 실적을 구조화 데이터에만 넣지 않습니다. 공개 글만 목록과 RSS, 사이트맵에 포함하며 예약일이 실제 공개일처럼 노출되지 않게 합니다. 검색로봇과 주요 AI 크롤러의 접근 정책도 robots.txt에서 명확히 확인합니다.
성과는 보장 문구 대신 측정 계획으로 정의합니다. 개편 전 색인 상태, 주요 검색어 노출, 페이지 속도, 구매 질문의 AI 인용을 기준선으로 남기고 같은 조건으로 반복합니다. 검색 결과는 외부 요인에 따라 달라지므로 제작 완료와 성과 변화의 책임 범위를 구분해야 합니다.
운영자는 무엇을 직접 수정해야 합니까?
개편 후 누가 어떤 주기로 내용을 갱신할지 정하지 않으면 새 사이트도 빠르게 오래됩니다. 운영자는 제품과 서비스 설명, 인사이트, 이미지, 문의 수신처와 법적 고지를 수정할 수 있어야 합니다. 다만 가격과 수량, 회사 실적처럼 여러 페이지에 영향을 주는 값은 한 곳에서 관리해 불일치를 막습니다.
편집 권한과 승인 절차를 구분합니다. 초안 작성자, 사실 확인자, 공개 승인자, 기술 관리자의 역할이 다를 수 있습니다. 자동 발행을 쓰더라도 원고와 이미지가 검수를 통과한 뒤 공개 상태만 바꾸도록 합니다. 실패한 검사를 우회하거나 기준을 낮추는 자동화는 운영 품질을 떨어뜨립니다.
교육과 인수인계도 범위입니다. 관리자 사용법, 이미지 규격, 제목 작성법, 오류 대응, 배포 절차와 복구 방법을 문서로 남깁니다. 제작사 계정에만 권한이 있거나 소유확인과 분석 계정이 개인에게 묶이지 않게 회사 소유와 담당 권한을 확인합니다.
검수 완료 기준은 어떻게 정합니까?
“정상 작동”을 페이지별 확인 항목으로 바꿉니다. 링크와 버튼, 폼 제출, 이메일 알림, 데이터 저장, 모바일 화면, 이미지 대체 텍스트, 대표 주소와 메타 정보를 검사합니다. 콘텐츠는 승인된 원문과 일치하고 미완성 표시나 임시 이미지가 없어야 합니다. 오류 상황에서도 사용자가 다음 행동을 이해할 수 있어야 합니다.
검색 품질 게이트에는 빌드, 타입 검사, 내부 링크, 본문 길이, 질문과 답, 중복률, 사이트맵, RSS, robots.txt를 포함합니다. 페이지 속도는 같은 환경에서 비교하고 큰 이미지와 레이아웃 이동을 우선 개선합니다. 브라우저 한 종류에서만 확인하지 않고 주요 화면 크기와 입력 방식을 점검합니다.
검수 결과는 담당자와 날짜, 재현 방법을 남깁니다. 수정 뒤 같은 항목을 다시 확인하고 다른 페이지에 영향이 없는지 회귀 검사합니다. 배포와 DNS 변경처럼 되돌리기 어려운 작업은 정확한 대상과 복구 절차를 먼저 확인합니다. 승인되지 않은 추가 요구는 기존 범위와 분리해 일정과 비용 영향을 판단합니다.
계약과 정산 범위는 어떻게 구분합니까?
제작 범위, 운영 범위, 외부 서비스 비용, 무상 제공물을 계약서에서 구분합니다. 정부지원사업을 이용한다면 지원금으로 정산하는 서비스와 공급사가 부담하는 제공물을 섞어 표현하지 않습니다. 홈페이지 구축이 무상 제공되는 상품이라면 정부가 구축비를 지원하는 것처럼 안내해서는 안 됩니다. 콘텐츠 발행과 최적화, 운영의 산출물을 기준으로 설명합니다.
제3자 비용과 계정 소유도 확인합니다. 도메인, 호스팅, 메일, 데이터베이스, 이미지 라이선스, 분석 도구에 별도 비용이나 사용 한도가 있는지 적습니다. 계약 종료 뒤 데이터와 계정을 누가 보유하고 어떤 형식으로 이관받는지 정합니다. 비밀키를 문서나 소스에 남기지 않고 환경 변수와 권한 관리로 전달합니다.
변경 요청 절차를 정하면 분쟁을 줄일 수 있습니다. 기존 요구의 보완인지 새 페이지와 기능의 추가인지 판단하고 일정, 검수, 운영 영향을 기록합니다. 구두 요청만 쌓지 않고 승인된 범위표를 최신 상태로 유지합니다. 포함되지 않은 일을 숨기기보다 먼저 알려주는 편이 실제 프로젝트 신뢰에 도움이 됩니다.
착수 전에 최종 확인할 것은 무엇입니까?
목표와 우선순위, 페이지 목록, 이관 자료, 기능 흐름, 디자인 기준, 검색 요구, 운영 책임, 검수 기준이 문서에 있는지 확인합니다. 각 항목에 담당자와 필요한 입력 자료, 완료 조건을 붙입니다. 결정되지 않은 내용은 확정된 것처럼 쓰지 않고 의사결정 날짜와 책임자를 둡니다.
실제 콘텐츠 샘플로 템플릿을 검증합니다. 가장 긴 제목과 설명, 복잡한 제품 정보, 이미지가 없는 상태, 오류 메시지를 넣어도 레이아웃이 유지되는지 봅니다. 빈 카드로 만든 시안만 승인하면 실제 자료를 넣었을 때 구조가 달라질 수 있습니다. 반복 페이지는 여러 유형의 실제 데이터를 사용해 검수합니다.
마지막으로 현재 사이트의 기준선을 보존하고 배포 순서와 복구 방법을 정합니다. 새 사이트가 열리면 대표 주소, 리디렉션, 사이트맵, 문의와 측정을 확인합니다. 콘텐츠 운영 기준과 연결해 공개 이후 갱신 계획까지 세워야 개편 결과가 지속됩니다. 요구사항 체크리스트는 계약용 목록이 아니라 기획부터 운영까지 같은 완료 상태를 공유하는 기준입니다.