홈페이지 인수인계의 핵심은 완성된 화면을 확인하는 데 있지 않습니다. 기업이 제작사 도움 없이도 도메인을 유지하고, 콘텐츠를 고치고, 문의를 받고, 분석 데이터를 확인하며, 다음 개발사에게 필요한 자료를 전달할 수 있는 상태가 되어야 완료입니다. 화면은 정상인데 도메인 계정이 제작사 명의이거나 소스 저장소와 배포 권한을 받지 못했다면 운영권은 기업에 있다고 보기 어렵습니다.
착수 단계에서 인계 목록을 합의하면 종료 직전 누락을 줄일 수 있습니다. 도메인, DNS, 저장소, 호스팅, 디자인 원본, 이미지 권리, 관리자 계정, 검색·분석 도구, 문의 수신, 백업과 유지관리 항목을 담당자와 검수 방법까지 포함해 문서화합니다. 아래 내용은 기업 홈페이지 제작의 기술·운영 인계 체크리스트이며, 계정 비밀번호나 API 키 자체를 이메일과 문서에 평문으로 남기라는 의미가 아닙니다.
도메인 명의와 DNS 통제권은 기업에 있나요?
도메인은 주소 이상의 자산입니다. 등록기관 계정의 명의, 소유자 이메일, 갱신 결제수단, 만료일 알림 수신자를 확인합니다. 제작 담당자의 개인 계정이나 퇴사 가능한 직원 한 명의 계정에만 묶이면 갱신과 DNS 변경이 중단될 수 있습니다. 기업 공용 계정을 기본으로 두고 복구 이메일과 다중 인증 방법을 인계 문서에 적습니다.
DNS 목록에는 현재 사용 중인 A, CNAME, TXT, MX 레코드의 목적을 기록합니다. 홈페이지 연결만 보고 레코드를 정리하면 회사 메일이나 소유확인이 끊길 수 있으므로 삭제와 변경 전 영향 범위를 확인해야 합니다. 각 레코드의 호스트, 유형, 값, 사용 서비스, 마지막 변경일과 변경 요청자를 표로 남기면 이후 장애 대응이 빨라집니다.
도메인 갱신과 DNS 수정 절차를 실제로 한 번 확인하는 것도 중요합니다. 읽기 전용 화면만 보여주는 것이 아니라 기업 담당자가 로그인하고 설정 위치를 찾을 수 있어야 합니다. 다만 인증코드, 복구키와 비밀번호는 안전한 비밀 관리 수단으로 전달하고 인계 문서에는 보관 위치와 담당자만 기록합니다.
저장소와 배포 프로젝트를 기업이 관리할 수 있나요?
소스코드 저장소의 조직, 관리자, 기본 브랜치, 배포 브랜치와 자동화 권한을 확인합니다. 압축 파일 한 번을 받는 것만으로는 이후 변경 이력과 배포 과정을 이어가기 어렵습니다. 기업 계정이 저장소를 볼 수 있고 필요한 경우 담당자를 추가하거나 권한을 회수할 수 있는지 실제 화면에서 검수합니다.
배포 서비스에서는 프로젝트 소유 팀, 연결된 저장소, 운영 도메인, 빌드 명령, 출력 디렉터리와 런타임 버전을 기록합니다. 환경변수는 이름과 용도, 발급처, 교체 절차만 목록화하고 실제 값은 문서와 저장소에 쓰지 않습니다. 누가 Production 설정을 변경할 수 있는지, Preview 배포가 공개 검색에 노출되지 않는지도 확인합니다.
최종 소스에는 불필요한 테스트 키, 임시 도메인, 개인 이메일과 미사용 계정이 남지 않아야 합니다. 새 담당자가 깨끗한 환경에서 의존성을 설치하고 빌드할 수 있도록 실행 명령과 요구 버전을 적습니다. 홈페이지 제작 범위는 기업 홈페이지 제작에서 확인하고 실제 계약 산출물과 대조합니다.
디자인 원본과 콘텐츠 사용권은 정리됐나요?
개발 소스와 디자인 원본은 다른 결과물입니다. 화면에 사용된 레이아웃, 컴포넌트, 아이콘, 사진, 영상, 폰트와 문구 가운데 기업이 수정 가능한 범위를 목록으로 만듭니다. 디자인 도구의 편집 권한, 링크 접근 범위, 외부 라이브러리와 유료 템플릿의 계정 소유자도 확인해야 합니다.
이미지와 영상은 파일을 받았다고 해서 모든 채널에서 자유롭게 쓸 수 있는 것은 아닙니다. 촬영 동의, 모델과 장소, 스톡 이미지, 음원, 폰트의 사용 채널과 기간이 다를 수 있습니다. 자산대장에는 파일명, 출처, 허용 범위, 만료일, 원본 위치와 대체 필요 여부를 기록합니다. 라이선스 확인이 어려운 자료는 인계 전에 교체하거나 사용 범위를 제한합니다.
콘텐츠 원고도 최신 승인본을 구분합니다. 회사소개, 서비스, 프로젝트, 정책 정보, 개인정보처리방침처럼 수정 주기가 다른 페이지를 나누고 담당 부서를 적습니다. 공개 근거가 필요한 수치나 고객사 표기는 검증 자료와 연결하되, 내부 계약서나 개인정보가 공개 저장소에 들어가지 않도록 분리합니다.
관리자 기능과 수정 절차를 직접 확인했나요?
관리자 화면이 있다면 공지, 상품, 프로젝트, 인사이트, 이미지와 SEO 정보를 기업 담당자가 직접 수정해 봅니다. 저장 버튼이 작동하는지만 보지 말고 작성→미리보기→승인→공개의 전체 흐름을 따라갑니다. 잘못 게시했을 때 이전 버전으로 돌아가는 방법, 예약 공개와 비공개 전환, 이미지 용량 제한도 확인합니다.
관리자 기능이 없는 정적 사이트라면 어떤 파일을 수정하고 어떤 명령으로 검증·배포하는지 설명합니다. 단순 문구 변경과 개발 작업이 필요한 변경을 구분하고, 운영자가 건드리지 말아야 할 설정을 표시합니다. 업데이트 요청 양식에는 대상 URL, 현재 문구, 변경 문구, 적용 희망일, 이미지와 승인자를 넣으면 커뮤니케이션 오류가 줄어듭니다.
계정별 권한은 최소 범위로 나눕니다. 콘텐츠 작성자가 도메인이나 결제수단까지 변경할 필요는 없습니다. 퇴사자와 외부 제작자의 계정 회수 절차, 다중 인증, 공용 계정 사용 원칙과 정기 권한 점검일을 운영서에 포함합니다.
검색·분석 도구의 소유권과 측정이 이어지나요?
Google Analytics, Google Search Console, 네이버 서치어드바이저와 Bing 웹마스터 도구가 기업 계정에 연결됐는지 확인합니다. 단순히 태그가 소스에 있다는 것만으로는 완료가 아닙니다. 운영 도메인에서 본인 방문, 페이지 조회, 주요 CTA와 문의 완료 이벤트가 실제로 수신되는지 각 도구의 실시간 또는 디버그 화면에서 검수합니다.
검색 설정에는 canonical, robots.txt, sitemap, RSS, Open Graph, 구조화 데이터와 소유확인 방식을 기록합니다. 사이트맵 제출 주소와 마지막 확인일, 오류가 있을 때 볼 화면을 운영서에 넣습니다. 도메인 변경 시 수정할 위치와 검색 도구에서 다시 확인할 항목도 명시합니다.
광고 랜딩페이지를 별도로 운영한다면 캠페인 파라미터가 홈페이지 분석까지 유지되는지 확인합니다. 문의 데이터에 유입 페이지와 캠페인 정보가 필요한 경우 개인정보 최소 수집 원칙과 보관 기간도 함께 검토합니다. 검색 유입 구조를 보강할 때는 SEO·GEO 실행 서비스의 페이지·콘텐츠 범위를 참고할 수 있습니다.
문의 폼이 실제 담당자에게 도착하나요?
성공 메시지는 브라우저 화면의 결과일 뿐 메일 도착을 증명하지 않습니다. 운영 도메인에서 실제 문의를 제출하고 API 응답, 메일 서비스 수락, 담당자 수신함 도착과 회신 주소를 차례로 확인합니다. 필수 항목, 개인정보 동의, 이메일 형식, 너무 빠른 제출, 중복 제출과 외부 출처 요청이 의도대로 처리되는지도 시험합니다.
수신처는 운영 조직의 공식 주소 하나로 고정하고 개인 메일로 유형별 분기하지 않습니다. 담당자가 바뀌어도 주소를 유지할 수 있어야 하며, 실패 시 화면에는 대체 연락 방법을 명확히 보여줍니다. 메일 본문에는 회사명, 담당자, 회신 이메일, 문의 내용, 관심 서비스와 유입 정보를 읽기 쉬운 순서로 배치하되 비밀값이나 불필요한 개인정보를 넣지 않습니다.
스팸 대응은 허니팟, 요청 크기 제한, 속도 제한, 동일 요청 멱등성과 출처 확인을 조합합니다. 실패 로그에는 키와 문의 본문 전체를 남기지 않습니다. 테스트 문의의 제목과 발송 시각, 문의 ID, 실제 수신 여부를 인수인계 체크리스트에 증거로 남깁니다.
반응형·접근성·브라우저 검수가 끝났나요?
모바일, 태블릿, 노트북과 넓은 화면에서 메뉴, 표, 이미지, 폼, 고정 요소와 CTA를 확인합니다. 한 장의 전체 화면 캡처로 끝내지 않고 메뉴 열기, 필터, 링크 이동, 입력, 오류 표시와 성공 상태를 실제로 조작합니다. 가로 스크롤, 잘린 문구, 겹치는 버튼과 지나치게 작은 터치 영역을 기록합니다.
키보드만으로 주요 기능을 사용할 수 있는지, 포커스가 보이는지, 제목 순서와 이미지 대체 텍스트가 적절한지 확인합니다. 애니메이션은 움직임 감소 설정에서 완화돼야 하고, 명암과 글자 크기는 밝은 화면과 어두운 환경에서 모두 읽을 수 있어야 합니다. 오류 메시지는 색만으로 구분하지 않고 해당 입력과 연결합니다.
자동화 검사는 회귀를 빠르게 찾지만 사람의 읽기 경험을 대신하지 않습니다. 대표 페이지와 문의 흐름은 실제 기기에서 한 번 더 확인하고, 발견한 문제를 URL·화면 크기·재현 순서·예상 결과와 함께 기록합니다. 전환 중심 페이지를 별도로 만들 때는 광고 랜딩페이지 제작 범위와 홈페이지 역할을 구분합니다.
백업·유지관리·종료 조건을 문서화했나요?
운영 백업의 대상은 소스, 콘텐츠, 업로드 파일, 데이터베이스, 도메인과 주요 설정 목록입니다. 서비스마다 복구 방식이 다르므로 백업 주기뿐 아니라 실제 복원 절차와 책임자를 적습니다. 정적 사이트라도 저장소 삭제, 도메인 만료와 환경변수 분실에 대비한 복구 경로가 필요합니다.
유지관리 계약에서는 오류 수정, 콘텐츠 변경, 보안 업데이트, 외부 서비스 정책 변경, 신규 기능을 구분합니다. 무상 보증 기간이라는 표현만 두기보다 어떤 상태를 오류로 판단하고 어떤 자료로 요청하며 예상 응답을 어떻게 공유하는지 정합니다. 외부 API와 분석 도구가 변경될 때 누가 확인하고 비용을 승인하는지도 포함합니다.
최종 인계 회의에서는 기업 담당자가 운영서를 보며 도메인 로그인, 소스 확인, 테스트 배포, 콘텐츠 수정, 분석 확인과 문의 제출을 직접 수행합니다. 미완료 항목은 담당자와 목표일을 적고 닫힐 때까지 목록을 유지합니다. 새 홈페이지를 준비 중이라면 마케팅 수행 문의에 현재 도메인, 보유 콘텐츠, 필요한 기능과 희망 일정을 남겨 제작·인계 범위를 함께 정리할 수 있습니다.
인계 완료의 기준은 파일을 전달했다는 말이 아니라 기업이 운영 작업을 재현했다는 증거입니다. 계정과 권한, 소스와 자산, 검색·분석, 문의와 복구 절차를 각각 확인하면 제작 종료 후의 운영 공백을 크게 줄일 수 있습니다.