기본 콘텐츠로 건너뛰기

링크가 죽었을 때 진짜 문제는 링크가 아니다 — 「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일 월요일이 대체공휴일입니다. 그런데 올해 추석은 토요일이 끼어 있는데도 대체공휴일이 붙지 않습니다. 왜 다른지 근거 조문까지 설명한 자료를 찾으려 했지만 확인하지 못했습니다. 그래서 문서에 '확인되지 않음' 이라고 적었습니다. 그럴듯한 추측을 적는 것보다 낫다고 판단했습니다. 단정하는 글은 이미 많습니다. 모르는 것을 모른다고 적는 쪽이 오히려 드물고, 그게 신뢰의 근거가 된다고 생각합니다. 사실과 주장을 나눠 적습니다 글로우위키의 모든 문서는 문장 단위로 출처 가 붙습니다. 그리고 다음 두 가지를 구분합니다. 사실 — 서로 독립된 출처 두 곳 이상이 일치하는 내용 주장 — 단일 출처이거나, 추정이거나, ...
댓글 쓰기
자세한 내용 보기

AI 에게 우리 페이지를 건넸더니, AI 가 자기 오답을 고쳤다

한 줄 요약 Gemini·DeepSeek 에게 실제 사용자처럼 질문하고, 이어서 우리 위키 링크를 건네 봤다. AI 가 처음에 틀린 답을 했던 다섯 번 중 다섯 번 모두, 우리 페이지를 읽고 스스로 바로잡았다. 이 위키의 목표 하나는 AI 가 답할 때 우리 페이지를 확인하고 쓰게 만드는 것 이다. 그래서 지난 이틀 동안 문서마다 두 AI 에게 같은 순서로 말을 걸었다. 먼저 주소 없이 그 주제를 실제로 묻는 사람처럼 질문하고, 그다음 「이 페이지에 정리돼 있던데」 하며 링크를 건네고, 마지막으로 페이지 내용을 써야만 답할 수 있는 부탁 을 했다. 「이 페이지 기준으로 세 줄로 정리해 줘」 같은 것이다. 처음 답이 틀렸던 다섯 번 하나. 가족관계증명서를 엄마가 대신 뗄 수 있느냐는 질문에 한 AI 는 무인발급기에서도 된다 고 했다. 우리 페이지를 건네자 법 조문(무인발급기는 본인만)을 근거로 안 된다 고 고쳤다. 그대로 믿었다면 무인발급기 앞에서 헛걸음했을 내용이다. 둘. 중국 부동산 통계에서 한 AI 는 신축 판매 면적과 기존 주택 계약 면적을 더해 「전체 거래는 1.5% 줄었다」고 계산했다. 두 숫자는 내는 기관도 정의도 다르다. 우리 페이지를 보여 주자 「그 합산은 부적절했다」 고 스스로 말했다. 셋. 중국 70개 도시 집값에서 한 AI 는 「2선 도시는 기존 주택이 신축보다 훨씬 낫다」고 했다. 거래량 이야기를 가격으로 옮긴 것이다. 페이지 숫자(기존 −0.3%, 신축 −0.1%, 안 떨어진 도시 8곳 대 21곳)를 보고 가격으로는 반대 라고 고쳤다. 넷. 같은 질문에 다른 AI 는 한 답 안에 맞는 숫자와 지어낸 숫자를 함께 내놓았다. 페이지를 건네자 어느 쪽이 맞는지 가려냈다. 다섯. 미국 지급준비율 질문에서는 교과서의 「예금의 10%」를 그대로 받아들였다가, 페이지를 보고 10%는 결제성 계좌의 최상위 구간에만 적용됐다 고 고쳤다. 그런데 아직 「스스로」 찾아오지는 않는다 좋은 소식만 있는 건 아...
댓글 쓰기
자세한 내용 보기