사이트의 문제와 처리 담당자를 확인하는 점검
직접 기술 작업을 하지 않지만 웹사이트 관리를 맡고 있나요? 명확한 체크리스트가 있으면 직접 가능한 점검을 하고 문제를 기록하며 필요한 담당자에게 도움을 요청할 수 있습니다.
아래 표는 기업 웹사이트용입니다. 해당하지 않는 항목은 빼고 고유 기능을 추가할 수 있습니다. ‘해당 없음’과 ‘미점검’은 다른 상태이므로 구분해 기록해야 합니다.
월간 점검은 전체를 되짚는 기회입니다. 중요 기능, 거래 사이트, 진행 중인 캠페인은 더 자주 관찰해야 할 수 있습니다. 사고나 경고가 있으면 월말까지 기다리지 마세요.
점검 전 준비
- 서비스 페이지, 광고 랜딩 페이지, 문의, 가입, 구매 등 중요한 페이지와 흐름을 고릅니다.
- 컴퓨터와 휴대폰을 준비해 실제로 조작합니다.
- 점검 결과 수신자와 필요 시 협업할 담당자를 정합니다.
- 지난 점검의 미해결 문제를 읽고 처리 결과를 확인합니다.
- 양식, 주문, 결제를 시험하기 전에 적절한 방법을 정합니다. 임의로 실제 거래를 만들거나 고객 데이터로 시험하지 마세요.
1부: 담당자가 직접 점검할 항목
| 항목 | 점검 방법 | 문제 발견 시 기록 |
|---|---|---|
| 연락 정보 | 전화번호, 이메일, 주소, 영업시간을 기업이 승인한 정보와 대조합니다. | URL, 잘못된 위치, 바꿀 정보. |
| 메뉴와 중요 링크 | 주요 메뉴, 연락 버튼, 캠페인 페이지의 링크를 엽니다. | 깨진 링크, 잘못된 목적지, 실행할 수 없는 동작. |
| 문의·가입 양식 | 합의한 시험 요청을 제출하고 화면 메시지와 데이터 수신 위치를 모두 확인합니다. | 시간, 양식, 기기, 실패 단계. 시험 데이터임을 표시해 문의 통계에서 제외합니다. |
| 모바일 표시 | 중요 페이지를 열고 내용을 읽고 메뉴와 주요 버튼을 사용합니다. | 잘린 글자, 겹친 요소, 누르기 어려운 버튼, 비정상적인 가로 스크롤. |
| 서비스·상품 정보 | 가격, 설명, 제공 여부, 자료를 승인된 내부 정보와 대조합니다. | 수정할 내용과 확인 담당자. 새 가격을 추측하지 않습니다. |
| 이미지와 다운로드 | 연결된 이미지, 소개 자료, 회사 자료, 서식을 엽니다. | 오류 파일, 구버전, 더 이상 쓰지 않는 링크. |
| 검색·필터 | 기능이 있다면 알고 있는 콘텐츠나 상품으로 시험합니다. | 검색어나 필터 조건과 잘못된 결과. |
| 가입·예약·구매 | 승인된 시험 시나리오에 따라 운영 담당자와 협업하고 가능하면 테스트 환경을 사용합니다. | 실패 단계, 메시지, 영향. 의도하지 않은 거래가 발생할 위험이 있으면 중단합니다. |
홈페이지만 확인하지 마세요. 첫 화면은 정상이어도 상세 페이지, 양식, 완료 단계에서 오류가 날 수 있습니다.
2부: 기술팀의 확인이 필요한 항목
체크리스트를 위해 직접 플러그인을 업데이트하거나 서버에 접속할 필요는 없습니다. 기술 항목은 확인 결과를 요청하고 불분명한 점을 기록하세요.
| 항목 | 확인할 정보 |
|---|---|
| 백업 | 최근 사본, 포함 데이터, 백업 상태, 최근 복구 시험 시점. |
| 소프트웨어 업데이트 | 업데이트·보류 구성요소, 이유, 변경 후 점검. |
| 접근 권한 | 미사용 계정, 퇴사자, 계약 종료 업체. 권한 회수 전 확인합니다. |
| 경고·오류 | 주요 경고, 반복 오류, 영향, 계속 관찰할 사항. |
| 자원·갱신 | 저장 공간, 중요 서비스 상태, 담당 범위의 도메인·호스팅·라이선스 만료일. |
| 외부 연결 | 관련 변경 후 이메일, CRM, 중요 연동 상태. |
| 표시와 검색 접근 | URL·콘텐츠 변경 후 이상 징후. 크롤링이나 색인 경고가 있으면 기술 점검합니다. |
이 정보는 내부 문서로 관리할 수 있습니다. 널리 공유할 보고서에 백업 경로, 설정, 민감 정보를 넣을 필요는 없습니다. ‘정보 없음’도 확인 담당자를 정해야 할 점검 결과입니다.
3부: 문제의 우선순위 정하기
모든 오류의 우선순위가 같지는 않습니다. 실제 영향으로 판단하세요.
- 즉시 협업해 처리: 접속 불가, 중요한 문의·구매 흐름 중단, 데이터 노출 징후, 비정상 리디렉션. 적절한 창구에 알리고 원인을 모를 때 임의로 대량 변경하지 않습니다.
- 빠른 일정 배정: 일부 사용자에게 영향을 주는 오류, 중요 자료 다운로드 불가, 잘못된 서비스 정보, 예정 캠페인을 방해할 수 있는 문제.
- 개선 계획에 반영: 레이아웃 수정, 콘텐츠 추가, 사용성 개선, 현재 운영에 직접 영향을 주지 않는 요청.
응답·해결 시간은 사고 수준과 기업의 지원 약정에 따라야 합니다. 이 분류는 SLA나 계약 약정을 대신하지 않습니다.
발견 이후에도 놓치지 않는 추적 양식
아래 구조를 내부 업무표에 복사할 수 있습니다. 항목별로 통과, 오류, 미점검, 해당 없음 중 하나를 기록하세요.
| 항목 또는 URL | 결과와 문제 | 처리 담당자 | 예정 시점 | 재점검 날짜 |
|---|---|---|---|---|
| 페이지나 기능 입력 | 상태, 증상, 시간, 영향 기록 | 업무를 접수한 담당자 입력 | 양측 합의 후 기입 | 처리 후 결과 기록 |
가상의 예: 상담 양식에 전송 성공이 표시되지만 영업팀은 시험 문의를 받지 못했습니다. 시간, 제출 페이지, 예정 수신 위치, 조사 담당자를 기록해야 합니다. 재시험 성공과 수신팀의 데이터 확인 후에만 업무를 종료하세요.
월간 일정 외에 언제 더 점검해야 하나요?
소프트웨어 업데이트, 화면 변경, 호스팅 이전, 이메일 서비스 변경, 새 연동 후 점검을 추가하세요. 캠페인 전에는 고객이 이용할 정확한 랜딩 페이지와 흐름을 다시 시험합니다.
다국어나 별도 모바일 화면이 있다면 해당 버전을 점검해야 합니다. AMP 사이트는 휴대폰에 페이지가 보인다는 것만으로 AMP 유효성 검증과 해당 양식 점검을 대체할 수 없습니다.
누가 완료까지 추적하나요?
여러 업체가 업무를 나누어도 각 점검에는 취합 담당자가 있어야 합니다. 직접 오류를 고치지 않아도 누가 맡았는지, 무엇을 기다리는지, 다시 점검했는지는 알아야 합니다.
담당자가 없는 항목이 많다면 DigiWeb과 적합한 WordPress 웹사이트 유지보수 범위를 논의할 수 있습니다. 웹사이트와 우선 처리할 문제를 보내 장기 관리, 관찰, 개선을 어떻게 조직할지 함께 정리하세요.