홈페이지 유지보수, 오픈 후 누가 무엇을 점검해야 할까요?

오픈 이후 유지보수는 공개와 함께 시작됩니다

홈페이지는 공개된 뒤에야 실제 운영이 시작됩니다. 제작 일정표의 마지막 칸을 채웠다고 점검이 끝나는 것은 아닙니다. 방문자가 보는 화면이 열려 있어도, 그 뒤에서 문구를 누가 고칠지, 서버 알림을 누가 받을지, 검색 콘솔 메일을 어디로 둘지가 비어 있으면 작은 수정도 서로 미루게 됩니다.

오픈 직후 흔한 장면은 이렇습니다. 오탈자는 운영이 고치고, 폼이 안 오면 제작에 묻고, 인증서 만료 메일은 예전에 만든 사람 함으로 들어갑니다. 각자 성실해도 책임 칸이 없으면 같은 문제가 공중에 뜹니다. 유지보수를 계약서의 항목 이름만으로 두지 마세요. 필요한 일은 누가 어떤 화면에 들어가 무엇을 확인하는지 쪼개는 것입니다.

이 글은 가격이나 처리 기간을 단정하지 않습니다. 문의 전에 맞춰 둘 책임 경계와 점검 항목만 다룹니다.

점검 주기보다 권한과 담당부터 나눕니다

점검 주기를 먼저 달력에 그려 넣으면 표는 완성돼 보여도, 권한이 흩어져 있으면 그 날짜에 실제로 들어갈 사람이 없습니다. 오픈 직후 가장 먼저 적어야 하는 것은 주기보다 계정입니다. 주기는 들어갈 수 있는 사람이 정해진 뒤에야 의미가 있습니다.

도메인, 호스팅 패널, CMS 관리자, 검색 콘솔, 백업 저장소, 알림 메일함이 서로 다른 사람에게 흩어져 있는지 한 장으로 펴 보세요. 운영 담당과 제작 담당을 나란히 두고, 각각이 들어갈 수 있는 화면과 들어갈 수 없는 화면을 구분합니다. 공유 계정만 있고 개인 추적이 안 되면, 나중에 누가 설정을 바꿨는지 찾기 어렵습니다.

백업 계정까지 한 사람에게만 있으면 그 사람이 자리를 비운 날에는 복원 자체가 멈춥니다. 퇴사나 대행 종료 때 회수할 계정도 같은 표에 남겨 두세요. 권한이 남아 있는 옛 담당자는, 화면이 멀쩡해 보여도 이미 점검 공백입니다. 새 담당자에게 읽기 권한만 먼저 주고 쓰기 권한은 인계가 끝난 뒤에 옮기는 식의 순서도 표에 적으면 혼선이 줄어듭니다.

운영과 제작이 각각 열어봐야 하는 화면

책임을 나눌 때는 직함보다 화면에 들어가는 손이 분명해야 합니다. 아래는 역할 예시이지, 모든 조직에 그대로 적용되는 고정 인원표는 아닙니다. 다만 비워 두면 요청이 한곳에 쌓이는 칸을 먼저 메우는 용도로 쓰세요. 한 사람이 모두 들고 있으면 그 사람이 쉬는 날이 곧 사이트의 공백이 됩니다.

운영 담당이 맡기 쉬운 일

• 공지, 소개, 채용처럼 자주 바뀌는 문구와 이미지
• 문의 폼이 실제로 도착하는지 확인
• 검색 콘솔과 사이트 모니터링 메일의 수신함
• 외부에 공유할 자료가 최신인지 확인
• 공개하면 안 되는 내부 자료가 메뉴에 올라왔는지 훑기

제작·기술 담당이 맡기 쉬운 일

• 서버, 도메인, 인증서, CMS 업데이트
• 플러그인·테마·외부 스크립트처럼 공급망에 해당하는 구성
• 백업이 파일과 데이터베이스를 함께 담고 있는지 확인
• 로그와 경보가 사람 앞으로 도착하는지 점검
• 주소 변경과 리다이렉트, 사이트맵 생성

둘 사이를 비워 두면 안 되는 일도 있습니다. 로그인 계정 회수, 퇴사자 권한 삭제, 대행 계정 만료는 운영이 요청하고 기술이 실행하는 순서를 정해 두는 편이 안전합니다. 화면이 예뻐 보여도 권한이 남아 있으면 점검을 한 것이 아닙니다.

보안과 백업은 화면이 멀쩡해도 미루지 않습니다

보안 점검은 보이는 페이지가 깨지지 않았다는 이유로 미룰 수 있는 일이 아닙니다. OWASP가 정리한 최근 위험에는 공급망, 설계 결함, 로깅과 경보 실패가 들어 있습니다. 홈페이지 운영으로 옮기면 질문은 이렇게 바뀝니다. 지금 쓰는 플러그인과 외부 스크립트를 누가 목록으로 갖고 있는가. 권한과 공개 범위를 설계 단계에서 나눠 두었는가. 오류가 나도 알림이 사람 앞으로 도착하는가.

경보가 꺼져 있으면 점검을 했다 해도 빈 점검입니다. 로그를 쌓기만 하고 읽는 사람이 없어도 같습니다. 설계 단계에서 관리자 화면과 공개 화면을 나누지 않으면, 이후 운영자가 실수로 내부 자료를 밖으로 밀어 넣기 쉽습니다. 로그인 뒤에만 보여야 할 파일, 테스트 문구, 내부 주소가 메뉴에 남는 일이 여기서 생깁니다.

공급망은 눈에 잘 띄지 않습니다. 테마, 플러그인, 분석 스크립트, 글꼴, 지도 위젯처럼 외부에서 불러오는 조각이 늘수록 누가 그 목록을 갱신하는지 정해 두지 않으면 업데이트 자체가 미뤄집니다. 새 기능을 얹기 전에 지금 불러오는 외부 조각부터 적어 두는 편이 안전합니다.

백업은 폴더 복사만으로 끝나지 않습니다. 공개된 관리 기준은 데이터베이스와 파일을 함께 담고, 업그레이드나 플러그인 갱신 전에 만들라고 말합니다. 이미지만 복사하고 글과 설정이 들어 있는 데이터베이스를 빼먹으면, 복원해도 빈 껍데기가 나옵니다. 오픈 후에 확인할 것은 백업 파일이 있다는 표시가 아니라, 복원에 필요한 두 덩어리가 실제로 들어 있는지, 그 위치에 운영 담당과 기술 담당이 모두 접근할 수 있는지입니다. 업데이트 일정이 정해지기 전에 백업 위치와 복원 담당자를 먼저 적으세요.

검색 구조와 콘텐츠는 올린 뒤에도 손봅니다

검색 작업도 오픈 당일 색인 요청으로 끝나지 않습니다. 구글 검색 기본 안내가 강조하는 것은 사이트 계층, 콘텐츠, 링크, 사이트맵, 검색 모니터링입니다. 메뉴를 바꿨는데 사이트맵이 옛 주소를 가리키거나, 중요한 페이지가 검색에서 빠졌는데 알림을 아무도 보지 않으면 콘텐츠를 잘 써도 바깥에는 옛 구조로 남습니다.

사이트 계층은 한 번 정하고 끝나는 그림이 아닙니다. 서비스를 합치거나 소개 페이지를 나누면 주소와 상위 메뉴가 함께 움직입니다. 그때 내부 링크가 막히거나 이동한 페이지를 옛 주소로 남기는 일은 디자인 수정과 별개입니다. 운영은 문구와 자료의 최신을, 기술은 주소·리다이렉트·사이트맵 생성을 맡는 식으로 나누면 책임이 겹치지 않습니다.

검색 콘솔 권한은 제작이 끝난 뒤에도 운영 쪽이 읽을 수 있어야 합니다. 모니터링 메일이 제작 담당 개인 함으로만 가면, 인계 이후에 검색 이상은 아무도 모릅니다. 새 글을 올리는 일과 검색 이상을 읽는 일을 한 사람에게만 몰아 두지 마세요. 콘텐츠가 늘수록 계층과 링크와 사이트맵을 같이 보지 않으면 공개된 정보와 검색에 남은 정보가 어긋납니다.

주기는 숫자로 단정하지 말고 이벤트와 증적으로 정합니다

점검 주기를 먼저 숫자로 정하면 표는 단정해도 현장에서 지켜지기 어렵습니다. 날짜보다 앞서는 것은 이벤트입니다. 플러그인을 올리기 전, 서버를 옮기기 전, 담당자가 바뀌기 전, 검색 알림이 왔을 때. 이런 시점에는 백업과 권한과 로그를 같은 순서로 봅니다. 이벤트를 건너뛴 채 달력만 채워 두면, 정작 위험한 날은 표 밖에 있습니다.

정기 점검은 그다음에, 양쪽이 실제로 열어볼 수 있는 간격으로 합의하면 됩니다. 그 간격은 이 글에서 단정하지 않습니다. 조직과 사이트 구성이 다른데 하나의 주기를 적으면 근거 없는 약속이 됩니다. 합의한 간격이 있다면 그 날짜보다 먼저, 누가 어떤 증적을 남기는지를 적으세요.

점검표에는 항목마다 담당자와 증적을 남깁니다. 백업이면 저장 위치와 파일·데이터베이스가 함께 들어 있는지, 보안이면 의존성 목록과 경보 수신함, 검색이면 사이트맵과 모니터링 수신함입니다. 증적이 있으면 주기를 나중에 바꿔도 빈칸이 드러납니다.

문의 전에 운영 목록만 맞춰도 범위가 분명해집니다

Studio OD 공개 사이트는 홈페이지 제작 범위와 문의 경로를 안내합니다. 유지보수 이야기를 시작하기 전에 아래만 메모해 와도 첫 대화의 범위가 분명해집니다.

• 도메인·호스팅·CMS·검색 콘솔의 실제 관리자
• 백업이 파일과 데이터베이스를 함께 담는지, 어디에 두는지
• 업데이트 전에 누가 백업을 실행하는지
• 공급망에 해당하는 플러그인·스크립트 목록의 위치
• 로그·경보·검색 모니터링 메일을 받는 사람

가격이나 처리 기간을 미리 단정할 필요는 없습니다. 권한과 점검 항목이 적혀 있으면, 오픈 이후의 유지보수는 서로 미루는 일이 아니라 순서가 있는 과정이 됩니다.