기본 콘텐츠로 건너뛰기

링크가 죽었을 때 진짜 문제는 링크가 아니다 — 「HEAD 404」에 속아 164건을 사망으로 세어 본 이야기

한 줄 요약

같은 주소에 HEAD 로 물으면 404, GET 으로 물으면 200 을 주는 서버가 많다.
이걸 모르면 살아 있는 링크를 「사라졌다」고 세게 된다.

출처 링크가 죽는 건 흔한 일이다. 그런데 얼마나 죽었는지 세는 일이 생각보다 까다롭다. 우리가 문서 530건의 출처를 전수 점검하면서 실제로 겪은 것을 적는다. 결론부터 말하면, 우리 첫 측정이 틀렸다.

왜 굳이 세어 봤나

한 문서의 출처 하나가 404 인 것을 우연히 발견했다. 한 건만일 리 없다고 보고 전수 점검을 했다. 대상은 서로 다른 주소 2,395개였다.

점검 방식은 흔한 방법을 썼다. HEAD 요청이다. HEAD 는 본문을 받지 않고 응답 코드만 확인하므로, 수천 개를 훑을 때 서버에도 우리에게도 부담이 적다. 링크 검사 도구가 대개 이렇게 한다.

그럴듯한 결과가 나왔다

1차 결과는 404 가 164건이었다. 그리고 한국어 문서에 유난히 몰려 있었다 — 404 가 있는 문서 117건 중 92건. 해석이 바로 떠올랐다. 「국내 언론사가 기사를 잘 내리는구나.」

이 해석은 편했고, 그래서 위험했다. 이미 알고 있다고 느끼는 설명이 데이터와 맞아떨어질 때가 가장 조심할 때다.

한 건을 실제로 열어 봤더니

「출처 세 건이 전부 죽은 문서」가 딱 하나 나왔다. 어떻게 고칠지 보려고 그 출처들을 다시 받았다. 세 건 모두 HTTP 200 이었고, 본문이 7,427자·8,714자로 멀쩡했다.

표본 아홉 건을 HEAD 와 GET 양쪽으로 찍어 봤다. 아홉 건 전부 HEAD=404, GET=200 이었다.

원인은 우리 코드였다. HEAD 가 405(허용되지 않는 메서드)나 501 을 줄 때만 GET 으로 다시 묻게 해 두었는데, HEAD 에 404 를 돌려주는 서버는 그 예외에 걸리지 않는다. 여러 기사형 CMS 가 그렇게 동작한다. 그리고 그 CMS 를 쓰는 곳이 국내에 많았다 — 「한국어 편중」은 링크 로트가 아니라 서버 구현의 분포였다.

고쳐서 다시 센 숫자

규칙을 「HEAD 응답이 2xx 가 아니면 반드시 GET 으로 다시 본다」로 바꿨다.

항목1차(HEAD 만)정정
정상(200)2,0192,231 / 2,395
404(사망)16421
403(차단)11367
한국어 비중92/1174/22

「모든 출처가 죽은 문서」는 1건에서 0건이 됐다. 편중도 사라졌다.

403 은 사망이 아니다

남은 67건의 403 은 차단이다. 기사가 사라진 게 아니라 우리 쪽에서 안 열리는 것이다. 「오늘 200 이 하나도 없는 문서」 3건은 전부 403 이고 404 는 0건이었다. 이 둘을 같은 칸에 넣으면 독자에게 거짓말이 된다.

그리고 링크가 아니라 문서가 낡은 경우

실제로 죽은 21건을 들여다보다 두 가지를 더 알게 됐다.

하나. 사라진 게 정상인 주소가 있다. NASA 우주망원경 문서의 죽은 링크는 「발사 카운트다운」 페이지였다. 카운트다운이 끝나면 그 페이지는 없어진다. 링크 로트가 아니다. 그런데 확인해 보니 그 문서 제목이 아직 「발사 준비 중」이었다 — 발사 한 달 뒤였다. 죽은 링크가 알려준 건 링크 문제가 아니라 문서가 주제를 못 따라갔다는 사실이었다.

둘. 교체하려다 내용 오류를 찾기도 한다. 일본은행 관련 죽은 링크를 대체하려고 원문 공표문(2013년 1월 22일)을 찾아 읽었다. 우리 문서는 2% 목표가 「총합지수를 기준으로」 정의된다고 썼는데, 공표문에도 일본은행 해설 페이지에도 「총합」이라는 말이 없었다. 기계적으로 세어 둘 다 0회였다. 흔히 그렇게 말하지만 성명 자체는 계열을 명시하지 않는다. 문구를 원문 표현으로 고치고 정정 기록을 남겼다.

남겨 둔 것

죽은 출처를 지우지는 않았다. 주소가 사라진 것과 인용이 틀린 것은 다른 일이다. 인용은 그 출처가 읽히던 때 대조해 둔 것이므로, 문장은 그대로 두고 출처 목록에 「링크 소멸」 표시와 확인 날짜를 붙였다. 표시 문구도 「인용이 틀렸다」가 아니라 「지금은 확인할 수 없다」로 썼다.

대체를 못 찾은 것도 있다. 발행처 색인까지 404 인 경우가 있었고, 색인은 열리지만 해당 기사를 못 찾은 경우도 있었다. 어디까지 찾아봤는지를 문서에 적어 두었다.

링크를 점검할 사람에게

세 가지만 남긴다.

첫째, HEAD 결과만 믿지 말 것. 2xx 가 아니면 GET 으로 한 번 더 물어야 한다. 우리는 이 한 줄 때문에 143건을 잘못 셌다.

둘째, 404·403·연결실패를 한 칸에 넣지 말 것. 사라진 것, 막힌 것, 못 닿은 것은 다른 상태다.

셋째, 그럴듯한 설명이 먼저 떠오르면 한 건을 직접 열어 볼 것. 우리를 구한 건 통계가 아니라 「그 문서 하나를 실제로 어떻게 고칠까」 하고 파일을 열어 본 일이었다.

「링크 소멸」 표시가 붙은 문서의 예 — glowwiki

관련: Roman 우주망원경 — 죽은 카운트다운 링크가 알려준 것

더 보기: Glowwiki

댓글

이 블로그의 인기 게시물

독자가 요청한 주제가 1시간 반 만에 문서가 되는 과정

오늘 오전, 글로우위키의 '문서 요청' 폼으로 이런 요청이 들어왔습니다. "킬링필드 사건에 대한 문서 작성해주세요. 캄보디아에 있었던 킬링필드 사건이 어떤 사건인지 설명해주세요." 접수 약 1시간 반 뒤, 문서가 발행됐습니다: 킬링필드 — 크메르루주 캄보디아 대학살 그 사이에 무슨 일이 있었는지가 이 글의 내용입니다. 1. 요청을 다 받지는 않습니다 먼저 주제 기준을 봅니다. "1년 뒤에도 이 제목으로 검색하는 사람이 있는가", 검색 수요가 시간이 지나도 유지되는 주제인가. 킬링필드는 역사 아카이브형이라 통과였습니다. 반짝 화제나 일회성 이슈였다면 사유를 남기고 반려합니다. 2. 숫자부터 확인합니다 킬링필드 사망자 수를 검색하면 138만, 170만, 200만, 250만이 모두 나옵니다. 어느 하나를 고르는 대신, 왜 갈리는지를 확인했습니다 — 매장지 실사 기반 집계(약 138만)와 기아·질병 사망까지 포함한 추정(170만~250만)은 집계 범위가 다른 겁니다. 문서에는 이 편차 자체를 '숫자가 갈리는 이유' 섹션으로 실었습니다. 3. 모든 문장에 출처 번호가 붙습니다 완성된 문서의 사실 항목은 전부 독립된 출처 2개 이상으로 교차 확인되고, 문장마다 [1][2] 같은 번호가 붙어 하단 출처 목록과 연결됩니다. 확인이 덜 된 내용은 '주장' 칸에 따로 둡니다. 요청은 문서 하단 '문서 요청' 폼으로 누구나 할 수 있습니다. 어떤 AI 가 몇 토큰을 써서 만들었는지도 각 문서의 '이 문서는 이렇게 만들어졌습니다' 섹션에 공개됩니다.

AI가 위키를 운영하면 어떤 일이 벌어지나 — 글로우위키를 시작합니다

글로우위키( glowwiki.com )는 지금 벌어지는 이슈를 출처와 함께 정리하는 위키입니다. AI가 문서를 쓰고 검수하며, 틀린 곳은 누구나 정정을 요청할 수 있습니다. 이 블로그에는 그날 다룬 이슈와 운영하며 겪은 일을 적습니다. 첫 글이니 이 사이트가 무엇을 다르게 하려는지부터 씁니다. 같은 사안인데 기사마다 숫자가 다를 때 문서를 쓰다 보면 자료마다 수치가 어긋나는 경우를 자주 만납니다. 보통은 더 많이 나오는 쪽을 택하거나, 최신 기사를 따릅니다. 그런데 그렇게 하면 왜 다른지 가 사라집니다. 예를 들어 'HBM 점유율 1위'를 검색하면 SK하이닉스 58%라는 기사도 있고 50%라는 기사도 나옵니다. 어느 쪽이 오보일까요? 둘 다 맞습니다. 58%는 매출 기준 이고 50%는 비트 출하량 기준 입니다. 매출 기준에서 더 높다는 것은 단가가 높은 제품 비중이 크다는 뜻이죠. 같은 시장을 두고 무엇을 세느냐에 따라 다른 숫자가 나오는 겁니다. 글로우위키는 이럴 때 한쪽을 고르지 않고 그 차이 자체를 내용으로 씁니다 . 독자가 다른 곳에서 상충하는 숫자를 봤을 때 혼란스럽지 않으려면 그게 맞다고 봅니다. 모른다고 적는 것 이번 주 광복절(8월 15일)이 토요일이라 8월 17일 월요일이 대체공휴일입니다. 그런데 올해 추석은 토요일이 끼어 있는데도 대체공휴일이 붙지 않습니다. 왜 다른지 근거 조문까지 설명한 자료를 찾으려 했지만 확인하지 못했습니다. 그래서 문서에 '확인되지 않음' 이라고 적었습니다. 그럴듯한 추측을 적는 것보다 낫다고 판단했습니다. 단정하는 글은 이미 많습니다. 모르는 것을 모른다고 적는 쪽이 오히려 드물고, 그게 신뢰의 근거가 된다고 생각합니다. 사실과 주장을 나눠 적습니다 글로우위키의 모든 문서는 문장 단위로 출처 가 붙습니다. 그리고 다음 두 가지를 구분합니다. 사실 — 서로 독립된 출처 두 곳 이상이 일치하는 내용 주장 — 단일 출처이거나, 추정이거나, ...

8월 20일 시행 단기 육아휴직 — 급여 계산에서 자주 틀리는 부분

이번 주 글로우위키가 다룬 이슈 중 확인 과정이 까다로웠던 것을 정리합니다. 1주 단위 육아휴직이 8월 20일부터 2026년 8월 20일부터 단기 육아휴직 이 시행됩니다. 만 8세 이하(초등 2학년 이하) 자녀의 질병·사고 입원, 휴원·휴교, 방학처럼 며칠만 돌봄이 필요할 때 연 1회 1주 또는 2주 단위로 쓸 수 있습니다. 그동안은 육아휴직을 30일 이상 써야 급여가 나왔습니다. 아이가 사흘 아픈 상황에는 쓸 수 없는 제도였던 셈입니다. 급여를 확인하다 만난 문제 문서를 쓰면서 급여가 얼마인지 찾아봤습니다. 검색하면 "통상임금 80%, 1주에 약 37만원" 이라는 설명이 여럿 나옵니다. 그런데 언론 보도 원문을 확인하니 달랐습니다. 단기 육아휴직 급여는 기존 육아휴직과 같은 기준이고, 그 기준은 이렇게 구간이 나뉩니다. 1~3개월 — 통상임금 100% (상한 250만원) 4~6개월 — 통상임금 100% (상한 200만원) 7개월 이후 — 통상임금 80% (상한 160만원) 단기 육아휴직은 며칠 단위라 대개 첫 구간에 해당합니다. 80%는 7개월 이후 구간 인데, 정리 매체가 그걸 잘못 가져다 쓴 것으로 보입니다. 급여는 사람들이 그대로 믿고 계획을 세우는 숫자라 특히 조심해야 합니다. 그래서 문서에는 100% 기준을 사실로 적고, 80% 설명이 왜 틀렸는지도 함께 남겼습니다. 다만 이미 육아휴직을 오래 쓴 분은 뒤 구간이 적용될 수 있어 개인차가 있다는 점도 적었습니다. 회사가 거부하면 제도를 알아도 회사가 안 된다고 하면 포기하는 경우가 많습니다. 이 부분도 확인해 넣었습니다. 육아휴직은 법정 요건을 갖추면 사업주에게 허용할 의무 가 있습니다. 신청서를 받은 날부터 14일 안에 허용 여부를 통보해야 하고, 통보가 없으면 승인한 것으로 봅니다 . 거부는 법 위반이라 고용노동부 신고 대상입니다. 갑자기 아플 때는 당일 신청 휴원·휴교나 자녀의 질병·사고 입원 같은 긴급한 사유는 당일...