고객이 카탈로그에서 자료 링크를 눌렀는데 "404 - Content not found"라는 문구가 나왔습니다. 그런데 저희 점검 기록에는 그 링크가 정상으로 남아 있었습니다.
거짓 기록이 아니었습니다. 그 주소는 실제로 정상 응답을 돌려주고 있었습니다. 페이지 내용만 없을 뿐입니다.
정상 응답과 정상 페이지는 다른 말입니다
일부 사이트는 존재하지 않는 주소를 요청받아도 "정상"이라는 응답과 안내 페이지를 함께 내려보냅니다. 기계가 보는 신호와 사람이 보는 화면이 어긋나는 구간입니다.
담당자 입장에서 이 차이는 비용으로 돌아옵니다. 가격표 링크가 빈 페이지로 연결되면 검토하던 고객이 그 자리에서 이탈합니다. 문의 폼으로 가는 버튼이 그렇게 되면 문의 자체가 기록에 남지 않습니다. 화면은 멀쩡해 보이고 점검 결과도 정상이니 몇 달을 모르고 지나갑니다.
저희가 링크를 네 단계로 나눠 확인합니다
첫 번째는 응답 종류를 봅니다. 대상이 없다는 응답이면 그 자리에서 실패입니다.
두 번째가 핵심입니다. 확인하려는 주소 뒤에 존재할 수 없는 경로를 덧붙여 한 번 더 요청합니다. 그것도 정상 응답이 돌아오면, 그 사이트에서 받은 정상 응답은 페이지가 있다는 뜻이 아닙니다. 이런 사이트는 실패로 처리하지 않고 경고로 분류해 사람이 직접 열어 봅니다.
세 번째는 본문에 404 안내 문구가 있는지 봅니다. 두 번째를 통과했더라도 개별 페이지가 안내문을 내려보낼 수 있습니다.
네 번째는 코드 저장소일 때 적용합니다. 저장소 조회용 기능으로 실제 존재 여부를 확인합니다. 화면은 열리는데 조회 결과가 없다고 답하면 대상이 사라진 것입니다.
같은 요청으로 보관 상태인지도 함께 받습니다. 보관된 저장소는 링크가 죽은 것이 아니라 멀쩡히 열립니다. 더 이상 유지되지 않을 뿐입니다. 저희는 이것을 링크 실패가 아니라 추천 목록에서 뺄지 말지의 판단 재료로 씁니다. 두 건이 그렇게 빠졌습니다.
"링크가 유효한가"와 "이 자료를 계속 추천할 것인가"는 다른 질문입니다. 같은 검사로 둘 다 확인할 수 있지만 결과를 한 칸에 담으면 안 됩니다.
점검이 과하게 울어도 고객이 손해를 봅니다
한 번은 검사 결과에 실패가 무더기로 찍혔습니다. 열어 보면 전부 정상인 저장소였는데 25건이 실패로 분류돼 있었습니다.
원인은 응답 해석이었습니다. 외부 조회 기능에는 인증 없이 쓸 수 있는 요청 수 제한이 있고, 그 한도를 넘기면 거부 응답이 돌아옵니다. 검사기가 그것을 "대상이 존재하지 않음"으로 처리하고 있었습니다.
둘은 다른 이야기입니다. 하나는 대상이 없는 것이고, 하나는 지금 물어볼 수 없는 것입니다. 한도를 넘긴 시점 이후의 모든 결과가 실패로 기록됐으니, 검사를 늦게 시작한 항목일수록 억울하게 걸린 셈입니다.
담당자가 겪는 실질적 손해는 여기서 나옵니다. 점검 보고서에 실패가 25건 찍혀 있으면 그것을 확인하는 데 사람의 시간이 들어갑니다. 몇 번 반복되면 보고서 자체를 안 열어 보게 됩니다. 그때부터는 진짜 끊어진 링크가 섞여 들어와도 걸러지지 않습니다.
인증을 붙여 한도를 늘리고, 한도 관련 응답은 실패가 아니라 판정 보류로 분리했습니다. 판정 보류는 사람이 확인할 목록으로 따로 남습니다.
막히는 방식은 네 가지로 나뉩니다
| 유형 | 증상 | 대응 |
|---|---|---|
| 봇 차단 | 브라우저로는 열리는데 자동 요청은 거부 | 해당 서비스의 조회용 기능으로 확인 |
| 단일 페이지 앱 | 모든 경로가 껍데기 문서를 정상 응답으로 반환 | 내용 조회 기능으로 확인 |
| 요청 한도 | 일정 횟수 이후 거부 응답 | 인증 추가, 거부는 판정 보류로 분리 |
| 안내 페이지 | 없는 경로에 정상 응답과 안내문 | 본문 문구 확인 |
네 가지 모두 "링크가 죽었다"와는 다른 상태입니다. 같은 실패로 묶으면 진짜 죽은 링크가 묻힙니다.
개발을 맡길 때 확인할 것
자동 점검을 갖춘다는 말만으로는 부족합니다. 저희는 담당자가 다음 네 가지를 물어보기를 권합니다.
- 상태 코드 외에 페이지 내용까지 확인하는 단계가 있는가
- 없는 경로를 붙였을 때도 정상 응답을 주는 사이트를 구분하는가
- 외부 서비스의 거부 응답과 부재 응답을 같게 처리하고 있지 않은가
- 확신하지 못한 항목이 실패나 통과 어느 한쪽으로 밀려나 있지 않은가
네 번째가 실무에서 제일 중요합니다. 자동 검사가 확신할 수 없는 상황은 실제로 자주 생깁니다. 그것을 실패로 몰면 정상인 항목이 걸려서 보고서 전체를 믿지 않게 되고, 통과로 몰면 죽은 링크가 그대로 남습니다.
보류 칸을 하나 더 두면 사람이 확인할 목록이 짧아집니다. 실제 검사에서도 전량 통과에 경고 몇 건만 남았고, 그 몇 건은 브라우저로 직접 열어 확인했습니다.
자동 점검의 목적은 사람의 확인을 없애는 것이 아니라 확인할 대상을 좁히는 것입니다.
외부 시스템과 연동하는 자동화에서도 같은 문제가 생깁니다. 응답이 왔다는 것과 원하는 결과를 받았다는 것은 다릅니다. 실패한 건만 골라 다시 처리하는 구조는 부동산 문서 발급, 실패한 문서만 다시 처리하는 법에서 다뤘습니다.
