Procedures
판별 절차
제작을 맡기실 때 가장 알기 어려운 것은 「이 사람이 확인은 하고 넘기는가」입니다.그래서 제가 실제로 쓰는 절차를 그대로 적었습니다.
각 절차에 「이 절차가 못 잡는 것」을 함께 적었습니다. 한계를 안 적은 절차는 자랑이지 방법이 아닙니다.
400과 405로 경계를 만든다
언제 쓰나
문의 폼이 안 된다는 연락을 받았을 때. 화면만 보면 폼이 죽은 건지, 서버가 안 올라간 건지 구분이 안 됩니다.
절차
curl -s -o /dev/null -w "%{http_code}" \
-X POST https://example.com/api/lead이걸로 확정한 것
빈 본문으로 POST 를 보냈을 때 400 이 오면 서버 코드가 살아서 검증을 돌린 것이고, 405 가 오면 배포가 안 돼 정적 파일만 서빙되는 것입니다. 화면을 아무리 봐도 안 보이는 차이가 한 줄로 갈립니다.
이 절차가 못 잡는 것
- CDN 캐시가 주는 거짓 200 — 사용자 도메인이 아니라 배포 URL 로 재확인해야 합니다.
- 저장과 알림이 조용히 실패하는 경우. 200 이 와도 데이터가 안 들어갈 수 있습니다.
해시로 정본을 판정한다
언제 쓰나
같은 사이트의 사본이 여러 벌일 때. 백업 폴더, 빌드 산출물, 예전 저장소 중 어느 것이 실제로 지금 떠 있는 것인지 아무도 모르는 상태입니다.
절차
curl -s "https://example.com/?$(date +%s)" | shasum -a 256
for d in ./dist ./backup ./old; do
shasum -a 256 "$d/index.html"
done이걸로 확정한 것
라이브 응답의 해시와 후보들의 해시를 맞춰 봅니다. 한 번은 후보 8개 중 일치하는 것이 하나도 없었고, 그래서 「로컬 어딘가가 정본이다」라는 가정 자체가 틀렸다는 걸 알았습니다. 캐시를 피하려면 URL 에 매번 다른 값을 붙여야 합니다.
이 절차가 못 잡는 것
- 크롤한 사본에는 서버 코드와 빌드 설정이 빠져 있습니다. HTML 이 같아도 동작이 다를 수 있습니다.
- 응답에 시각이나 임의값이 섞이면 매번 해시가 달라집니다.
- 어느 사본을 정본으로 삼을지는 결국 사람이 정합니다. 이 절차는 「같다·다르다」까지만 말해 줍니다.
어절 쪼개짐을 센다
언제 쓰나
한글 페이지를 넘기기 전에 항상. 어절이 단어 중간에서 끊기면 보는 사람은 디자인을 보기 전에 「교정을 안 거쳤구나」부터 판단합니다.
절차
const seg = new Intl.Segmenter('ko', { granularity: 'word' });
// 어절마다 getClientRects() 가 두 줄에 걸치면 쪼개진 것
// 화면 밖 허니팟은 제외: r.right < 0 || r.width <= 1이걸로 확정한 것
눈으로 세지 않고 스크립트로 셉니다. 390·768·1280·1440px 네 폭에서 각각 0 이어야 넘깁니다. 원인은 거의 항상 하나입니다 — CSS 에 word-break: keep-all 이 없는 것. 있으면 0, 없으면 발생, 예외를 본 적이 없습니다.
이 절차가 못 잡는 것
- 화면 밖에 숨긴 봇 트랩 같은 요소가 오탐으로 잡힙니다. 폭과 좌표로 걸러야 합니다.
- 값이 data 속성에 들어 있으면 정적 스캔은 통과합니다. 렌더된 화면에서 재야 합니다.
- 제목 마지막 줄에 한 어절만 남는 고아는 이 절차로 안 잡힙니다. text-wrap: balance 가 따로 필요합니다.
세 절차에서 공통으로 배운 것
측정이 실패를 뱉으면 대상보다 도구를 먼저 의심합니다. 위 절차를 만들면서 제가 실제로 낸 오판이 있습니다 — 항목 여백을 빼먹고 간격을 재서 멀쩡한 화면을 불합격으로 판정했고, 가로로 놓인 카드를 세로 간격으로 쟀고, 부팅 직후에 응답 속도를 재서 정상인 서버를 느리다고 적을 뻔했습니다.
그래서 결과를 넘길 때는 측정값만이 아니라 무엇을 어떻게 쟀는지도 같이 드립니다. 숫자만 있으면 확인할 수가 없습니다.
가격과 범위 보기