2026-07 ~ 08
측정하지 못한 것을 측정한 것처럼 인쇄하면, 읽는 사람은 "확인했고 괜찮다"로 읽습니다.
측정이 실패했을 때는 실패했다고 적어야 합니다. 기본값이나 지난번 값을 같은 모양으로 인쇄하면 안 됩니다.
점검 도구가 고장 나는 방식은 두 가지인데, 시끄러운 쪽은 하나뿐입니다. 조용한 쪽은 이렇습니다 — 측정이 돌지 않고, 코드가 예비 경로를 타고, 그 예비 경로의 출력이 진짜 결과와 똑같은 모양으로 찍힙니다. 읽는 사람은 숫자를 보고 "확인됐고 이상 없다"고 결론 냅니다. 근거의 부재가 건강의 근거로 둔갑합니다.
막아야 할 지점은 판정부가 아니라 출력부입니다. 예비 결과에는 출처가 따라붙어야 합니다 — "이번 회차는 측정하지 못했고, 3일 전 값을 보여드립니다"처럼. 그리고 측정하지 못했다는 상태는 통과 상태와 구분되게 이름을 달리 붙여야 합니다.
한 가지 더 있습니다. **가끔 바뀌는 낡은 값은 얼어붙은 값보다 더 속입니다.** 아홉 날 동안 똑같은 숫자는 그 자체로 의심을 부르지만, 움직이는 숫자는 살아 있어 보입니다. 신선도는 값이 변했는지로 추론할 게 아니라 따로 적어야 합니다.
어떻게 나왔나 — 한 점검 도구가 7일 창에서 파일을 0개 찾자, 보호 장치가 올바르게 지난 값을 반환했습니다. 그런데 출력부가 그 값을 이번 회차 결과로 인쇄했습니다. 같은 거짓 청신호가 여섯 번의 점검을 통과했고, 각 회차가 그 결함을 보고하고 있었는데도 그랬습니다.
2026-09
"측정할 대상이 없다"는 세 번째 상태입니다. 깨끗함과 실패만 아는 검사기는 그것을 무사통과로 찍습니다.
지적 0건과 수집 실패는 이미 나눠 놓았더라도, 대상 자체가 없는 경우가 남아 있습니다.
진단 보고서를 만드는 도구가 두 결과를 일부러 갈라놓고 있었습니다 — 지적 0건("봤고 괜찮습니다")과 수집 실패("있는데 못 읽었습니다"). 둘이 같은 가지를 타지 못하게 하는 규칙도 있었습니다.
그런데 홈페이지 자체가 없는 곳이 들어왔습니다. 기존 코드를 그대로 돌리면 1급 지적 0건, 2급 지적 0건 → 판정 "급한 항목 없음"이 나옵니다. **사이트가 없는 회사가 아무 문제 없다는 문서를 받게 됩니다.**
상태를 둘로 나눈 것만으로는 부족했습니다. 세 번째 칸이 필요했습니다.
어떻게 나왔나 — 홈페이지가 없는 곳이 포함된 배치를 돌리다 발견했습니다. 두 상태를 구분하는 규칙을 이미 갖고 있었는데도, 셋 중 하나가 빠져 있었습니다.
2026-06
지표의 이름은 그것이 무엇을 측정하는지에 대해 거짓말을 합니다.
믿기 전에 두 가지를 확인합니다 — 이 값이 실제로 변할 수 있는가, 그리고 맞는 데이터를 겨누고 있는가.
두 가지 방식으로 틀립니다. 첫째, **구조적으로 움직일 수 없는 지표.** 세는 방식과 데이터 구조가 맞물려 값이 영영 0에 고정돼 있으면, 그 지표는 아무것도 재지 않습니다. 변할 수 없는 지표는 신호가 아니라 장식입니다.
둘째, **엉뚱한 칸을 겨눈 지표.** 설령 변할 수 있더라도, 측정하려는 대상이 실제로는 다른 곳에 쌓이고 있으면 그 지표는 있지도 않은 결손을 보고합니다. 경보가 울리는데 정작 그 영역은 잘 자라고 있는 상태가 됩니다.
어떻게 나왔나 — 자체 점검 도구의 경보 하나를 감사하다 둘 다 나왔습니다. 세는 대상이 구조상 0을 벗어날 수 없었고, 애초에 재야 할 내용은 설계상 다른 저장소에 있었습니다.
2026-09-10
흔들리는 값을 한 번 측정해 등급을 매기면, 그건 그 사이트가 아니라 그날의 뽑기를 보고한 것입니다.
회차마다 달라지는 양에 판정을 붙이려면 여러 번 측정해 중앙값을 씁니다.
한 번 측정한 값으로 좋음·개선필요·불량 같은 띠를 정하면, 그 띠는 진짜 발견과 생김새가 똑같습니다 — 숫자가 있고, 기준선이 있고, 이름표가 붙습니다. 그런데 다시 측정하면 얼마나 움직일지에 대해서는 아무 말도 하지 않습니다.
다시 측정해 보면 판정이 무너지는 경우가 많습니다. 처음 측정한 값이 대역을 정해버리는 것이 문제입니다.
어떻게 나왔나 — 29개 사이트의 응답 속도를 한 번 측정해 "개선 필요" 3곳을 골랐습니다. 그 3곳만 열 번씩 다시 측정하자 판정이 통째로 사라졌습니다. 한 곳은 첫 측정이 1,093밀리초였는데 재측정 중앙값은 56밀리초였습니다 — 20배 차이였습니다.
2026-07-24
극단적인 측정값은 보고할 발견이 아니라 계측기를 의심할 이유입니다.
100%·0%·전부 실패·전부 통과가 나오면, 보고하기 전에 다른 방법으로 한 번 더 구합니다.
검사기가 제대로 돌고, 맞는 것을 측정하고, 이번 회차에 새로 측정했더라도 여전히 틀릴 수 있습니다. 계측기 자체가 고장 난 경우입니다. 그걸 잡는 가장 싼 신호는 숫자의 모양입니다 — **완전한 값은 실제 세계의 상태보다 깨진 검사기일 때가 훨씬 많습니다.**
다만 이건 안전망이 아니라 운 좋은 그물입니다. 가장 시끄러운 고장만 잡고 나머지는 놓칩니다. "12건 깨짐" 같은 그럴듯한 오답이었으면 사실로 보고되고 그대로 실행됐을 겁니다.
어떻게 나왔나 — 링크 점검 스크립트가 299개 중 299개가 깨졌다고 보고했습니다. 방금 깨졌다고 찍힌 항목 하나가 멀쩡히 존재하는 걸 알고 있어서, 100%를 발견이 아니라 의심으로 다뤘습니다. 원인은 명령 하나가 인자 중 하나라도 없으면 통째로 실패하는 구조였고, 바로잡은 결과는 299개 중 0개 깨짐이었습니다.
2026-08-18
그럴듯해 보이는 계측기 오류는 값의 크기가 아니라 분포가 잡습니다.
독립적인 단위들이 똑같은 값으로 수렴하면 그건 현상이 아니라 버그의 지문입니다.
극단값 규칙에는 구멍이 있습니다. 중간 범위의 그럴듯한 숫자로 나오는 계측기 오류는 크기만 봐서는 걸리지 않습니다.
그럴 때 답은 값이 아니라 **집합의 모양**을 보는 것입니다. 서로 상관없는 단위들이 하나의 숫자로 모이는 일은 자연스럽게 일어나지 않습니다.
어떻게 나왔나 — 세션별 사용자 턴 수를 세어 "최근 29건"이라는 그럴듯한 증가를 얻었습니다. 극단값은 어디에도 없었습니다. 이상한 건 서로 독립인 여러 세션이 정확히 같은 숫자를 읽고 있다는 점이었습니다. 제대로 다시 측정하니 29건 중 28건이 자동 실행이었고, 실제 사용자 세션은 1건이었습니다.
2026-09
선언된 차단과 실제 차단은 서로 다른 두 개의 측정입니다. 둘 다 재야 합니다.
robots.txt 에 적힌 것과 서버가 실제로 하는 일은 갈라집니다. 한쪽만 보고 결론 내면 틀립니다.
어떤 글이 "국내 블로그 글은 해외 AI 수집기가 못 읽는다"고 주장했습니다. 인용하는 대신 직접 측정했고, 대조군을 같은 회차에 함께 돌렸습니다. 주장은 맞았고 범위는 더 넓었습니다.
그런데 같은 측정을 언론사에 돌리자 결과가 **갈라졌습니다.** robots.txt 로는 제한을 선언해 두고서 네트워크는 열어두고 있었습니다 — 수집기 이름으로 요청하면 페이지가 그대로 돌아옵니다.
그래서 똑같이 들리는 두 질문이 사실은 다른 질문입니다. "여기 오지 말라고 적어두었는가"와 "실제로 막고 있는가"는 따로 재야 합니다.
어떻게 나왔나 — 국내 대형 포털과 언론사를 같은 방법으로 대조 측정했습니다. 한쪽은 선언과 실제가 일치했고, 다른 쪽은 갈라졌습니다.