홈페이지 유지보수, 직접 수정할 일과 맡길 일

홈페이지를 완성했는데 담당자는 공지 하나를 바꾸는 방법을 모릅니다. 관리자 계정은 받았지만 어떤 메뉴를 건드려도 되는지 불안합니다. 반대로 모든 기능을 직접 수정할 수 있게 만들었다가, 관리할 항목이 너무 많아 아무도 쓰지 않는 경우도 생각해 볼 수 있습니다.

운영하기 좋은 홈페이지는 ‘모든 것을 수정할 수 있는 사이트’보다 ‘자주 하는 일을 안전하게 처리할 수 있는 사이트’에 가깝습니다. 납품 때는 관리자 계정의 유무뿐 아니라, 담당자가 실제로 할 수 있는 일과 문제가 생겼을 때 도움받을 경로를 확인해야 합니다.

이 글은 기술을 모르는 운영 담당자가 인수 미팅에서 해볼 작업, 수정과 추가 개발을 구분하는 방법, 문의가 누락됐을 때 확인할 순서를 설명합니다. 사이트마다 제공 기능이 다르므로 없는 기능을 약속받은 것으로 이해하지 말고, 필요한 운영 범위를 협의하는 기준으로 활용하세요.

1. ‘자주 바꿀 세 가지’를 먼저 정하세요

소개 문구가 1년에 한 번 바뀌는 기업과 매주 강좌를 올리는 기관은 다른 관리 기능이 필요합니다. 처음부터 모든 화면을 편집 가능하게 만들기보다, 실제 담당자가 반복할 일을 적어보세요.

예를 들어 한 교육기관은 과정명·일정 변경, 모집 상태 변경, 신청 내역 확인이 중요할 수 있습니다. 제품 회사라면 제품 사진·설명 갱신, 자료 다운로드 파일 교체, 문의 처리일 수 있습니다. 이 목록을 만드는 데 복잡한 개발 용어는 필요 없습니다.

각 작업에는 세 정보를 붙이면 좋습니다. 누가 하는지, 얼마나 자주 하는지, 잘못했을 때 어떤 영향이 있는지입니다. 직원 누구나 공지 초안을 작성하되 공개는 담당자가 하게 할지, 단순 오탈자는 즉시 고칠 수 있게 할지 판단하는 데 도움이 됩니다.

거의 바꾸지 않는 내용이라면 매번 관리 화면에서 직접 고치는 것보다 필요할 때 수정을 요청하는 방식이 합리적일 수 있습니다. 직접 수정 기능은 공짜가 아니라 설계·구현·설명·유지의 대상입니다. 수정 빈도와 내부 담당자의 시간을 함께 보세요.

2. 관리자 화면은 ‘구경’하지 말고 직접 써보세요

납품 미팅에서 제작자가 빠르게 시연하면 다 이해한 것처럼 느껴집니다. 하지만 직접 로그인해 보면 버튼 위치나 공개 절차가 기억나지 않을 수 있습니다. 아래 작업 중 계약에 포함된 기능을 담당자가 직접 해보고, 막힌 부분을 운영 안내에 남겨보세요.

문구와 이미지를 바꾸고 공개 결과 확인하기

공지나 소개 문구의 오탈자 하나를 고쳐 저장합니다. 저장이 곧 공개인지, 초안 저장과 공개가 분리돼 있는지 확인하세요. 다른 창이나 로그아웃 상태에서도 바뀐 내용이 보이는지 살펴봅니다. 편집 화면이 바뀐 것과 방문자 화면이 바뀐 것은 다를 수 있습니다.

이미지도 한 장 교체해 보세요. 권장 비율, 파일 크기, 설명을 넣을 위치를 확인하고 휴대전화에서도 중요한 부분이 잘리지 않는지 봅니다. 사진을 바꿀 수 있어도 제목이나 버튼이 사진에 붙어 읽기 어려워진다면 실무에서는 다시 도움을 요청해야 합니다.

문의 한 건을 찾아 처리하기

담당자와 협의한 테스트 문의를 남기고 관리자에서 찾습니다. 접수 시각·내용·회신 정보를 확인하고, 처리 상태나 메모 기능이 있다면 변경 후 새로고침해도 남는지 봅니다. 실제 고객인 것처럼 혼동되지 않도록 테스트임을 표시하고 정리 방법도 함께 정하세요.

잘못된 변경을 되돌리는 방법 확인하기

작성 중 취소, 이전 글 복원, 공개 중지, 서버 백업 복구는 서로 다른 기능입니다. 모두 있다는 전제로 조작하지 마세요. 어떤 변경을 담당자가 되돌릴 수 있고, 어떤 작업은 제작자의 지원이 필요한지 설명을 받는 것이 목적입니다.

이 세 작업이 어렵다면 긴 설명서보다 해당 화면을 따라가는 짧은 안내가 유용할 수 있습니다. 버튼 이름, 저장·공개 순서, 문제가 생겼을 때 연락할 곳이 담기면 됩니다. 관리자 계정 전달만으로 인수가 끝났다고 판단하지 않는 편이 좋습니다.

3. 수정 요청을 세 갈래로 나누면 대화가 쉬워집니다

콘텐츠 변경은 제공된 기능 안에서 문구, 사진, 공지, 일정 등을 바꾸는 일입니다. 담당자가 직접 할 수 있는 항목과 제작자에게 요청해야 하는 항목을 구분합니다.

오류 수정은 합의한 기능이 의도대로 작동하지 않는 상황을 확인하고 고치는 일입니다. 문의가 저장되지 않거나, 공개한 글이 보이지 않는 문제 등이 해당할 수 있습니다. 실제 원인과 계약의 지원 범위에 따라 처리 방법을 확인해야 합니다.

추가 개발은 없던 화면이나 기능을 만들고, 업무 규칙·권한·외부 연결을 바꾸는 일입니다. 공지의 문장 교체와 회원별 열람 권한 추가는 같은 수정 요청이 아닙니다. ‘작아 보인다’는 이유만으로 필요한 작업도 작다고 판단하기 어렵습니다.

예를 들어 ‘신청 마감으로 바꿔주세요’는 이미 제공된 상태 항목을 바꾸는 일일 수 있습니다. 반면 ‘마감되면 대기자를 받고 취소가 생겼을 때 자동으로 자리를 배정해 주세요’는 새로운 운영 규칙입니다. 요청을 구분하면 예상하지 못한 비용과 일정 논의를 줄일 수 있습니다.

4. ‘문의 메일이 안 왔다’면 저장과 알림을 나눠 확인하세요

문의가 들어왔다는 이메일과 사이트에 저장된 문의는 같은 것이 아닙니다. 저장은 됐지만 알림 메일이 지연되거나 스팸함으로 이동할 수 있고, 반대로 화면에서 성공처럼 보여도 실제 저장에 문제가 있을 수 있습니다.

운영자는 먼저 관리자 목록에서 해당 시각의 접수를 찾아보세요. 기록이 있다면 수신 주소와 스팸함을 확인하고, 제공되는 경우 알림 처리 상태를 살핍니다. 기록도 없다면 사용한 주소, 접수 시각, 어떤 화면에서 멈췄는지 알려주면 원인 확인에 도움이 됩니다. 고객에게 무조건 다시 제출하도록 안내하기 전에 중복 접수 가능성도 확인해야 합니다.

W3C의 입력 결과 안내 지침은 성공과 실패를 분명히 알리고, 오류를 어떻게 해결할지 이해할 수 있게 안내하도록 설명합니다. 운영자가 사이트를 점검할 때도 이 기준으로 화면을 볼 수 있습니다. ‘오류 발생’만 나오기보다 어떤 정보를 고치거나 다음에 무엇을 해야 하는지 알 수 있어야 합니다.

지원 요청에는 다음 다섯 가지를 적어보세요. 비밀번호나 실제 고객의 전체 개인정보를 이메일에 붙일 필요는 없습니다. 화면을 첨부할 때도 불필요한 개인정보는 가립니다.

1. 문제가 발생한 페이지 주소와 대략적인 시각.
2. 하려던 작업과 누른 버튼.
3. 기대한 결과와 실제로 나타난 결과.
4. 화면의 오류 문구 또는 필요한 부분만 남긴 캡처.
5. 다른 기기에서도 같은지, 현재 업무에 어떤 영향이 있는지.

5. 백업은 있다는 말보다 복구 방법이 중요합니다

사이트의 화면 코드, 고객·주문 데이터, 업로드한 이미지, 외부 서비스 설정은 서로 다른 곳에 저장될 수 있습니다. 코드만 받아두었다고 모든 자료를 복구할 수 있는 것은 아닙니다. 계약한 운영 방식에서 어떤 항목이 백업되는지부터 확인하세요.

뉴질랜드 NCSC는 데이터의 중요도와 변경 빈도를 파악하고, 필요한 복구 목표에 맞춰 백업을 정하며, 실제 복원 테스트를 하도록 권합니다. 작은 사이트도 ‘어느 시점 자료까지 되살릴 수 있는가’와 ‘복구를 누가 수행하는가’는 알아둘 만합니다. NCSC 백업과 복구 검증 안내

예를 들어 한 달에 한 번 문구를 바꾸는 소개 사이트와 매일 신청이 쌓이는 사이트는 잃었을 때 다시 만들 수 있는 데이터가 다릅니다. 동일한 백업 주기를 무조건 요구하기보다, 최근 신청이 사라졌을 때 재구성할 수 있는지부터 생각해 보세요.

실제 운영 데이터를 지우면서 복구를 연습하라는 뜻은 아닙니다. 제작·운영 담당자에게 별도 검증 환경이나 안전한 방법으로 복구 가능성을 확인해 달라고 요청하고, 확인 시점과 범위를 기록하는 방식이 좋습니다.

6. 계정과 비용도 함께 인수해야 합니다

관리자 로그인 외에 도메인, 호스팅, 데이터 저장소, 메일 발송 등 사이트 운영에 쓰는 계정이 있을 수 있습니다. 모두 고객이 직접 가입해야 하는 것은 아니지만, 관리형 운영과 고객 소유 계정 중 어느 방식인지, 나중에 이전할 수 있는 범위는 무엇인지 알아야 합니다.

담당자가 바뀌어도 접근할 수 있도록 계정의 관리 주체, 갱신 알림을 받는 주소, 지원 연락처를 남겨두세요. 비밀번호를 여러 사람이 평문 문서로 공유하기보다, 서비스가 지원하는 개인별 초대와 권한 구분을 활용하는 편이 관리하기 좋습니다.

비용은 외부 서비스 이용료와 사람의 작업비를 구분해 확인합니다. 초기 금액에 일정 기간 운영비가 포함됐다면 포함 기간·사용량·초과 시 협의 절차·갱신 조건을 적어두세요. 정기 관리가 필요한지는 사이트의 변경 빈도, 중단 영향, 내부 담당자의 대응 가능성을 보고 판단할 수 있습니다.

손댈 일이 드문 소개 사이트에 큰 관리 계약이 항상 필요한 것은 아닙니다. 반대로 데이터를 받는 사이트를 ‘화면이 안 바뀌니 관리할 일이 없다’고 판단해서도 안 됩니다. 화면 수정과 계정·운영환경 관리는 별개의 일입니다.

운영 인수 미팅에서 이 질문들을 남기세요

• 직접 바꿀 수 있는 항목과 지원을 요청할 항목은 무엇인가?
• 저장·공개·취소는 각각 어떻게 동작하는가?
• 문의나 주문이 들어오면 담당자는 어디서 확인하는가?
• 오류가 나면 어디에 어떤 정보를 보내는가?
• 계정의 관리 주체와 갱신 담당자는 누구인가?
• 백업 대상과 복구 담당자, 마지막 확인 시점은 무엇인가?
• 포함된 지원 기간이 끝난 뒤에는 어떤 방식으로 요청하고 비용을 확인하는가?

홈페이지를 잘 인수했다는 것은 모든 기술을 배웠다는 뜻이 아닙니다. 자주 하는 작업은 직접 처리하고, 낯선 변경은 함부로 시도하지 않으며, 문제가 생기면 필요한 정보를 모아 도움을 받을 수 있다는 뜻입니다. 납품 미팅에서 공지 하나와 문의 한 건을 직접 다뤄보는 것부터 시작해 보세요.