website 종류 매핑 — 어떤 도메인이 어디로 가나

A. 후보 집합의 크기가 원리상 다르기 때문이다.

툴·소셜·디렉터리는 새 서비스가 생겨야 목록이 늘어난다. 거래소나 런치패드가 새로 나오는 일은 드물어서 46개가 거의 그대로 유지된다.

참조는 다르다. 발행자가 링크할 수 있는 뉴스·위키·브랜드 페이지는 세상의 모든 사이트가 후보다. 실측으로도 상위 30개 도메인이 website 전체의 30.1% 밖에 못 덮고, 상위 200개까지 가야 53.1% 다.

그래서 참조만 신호 기반이어야 한다. isNews · 도메인 나이 731일 이상 · hasTracking · techCount 4개 이상 넷이 세 시간분할에서 일관되게 이 구간을 잡는다는 실측이 sources/website-image.html §4 에 있다.

---

A. 디렉터리다. 다만 구조로는 못 가른다.

고유 URL 을 토큰 수로 나눈 비율이 0.78 인데, wikipedia.org 0.74 와 bitcointalk.org 0.77 이 바로 옆에 있다. 이 셋을 비율로 자르면 반드시 섞인다.

디렉터리로 보는 근거는 비율이 아니라 페이지의 주인이 누구냐다. coincommunities.org 의 각 페이지는 그 토큰에 대한 페이지이고, wikipedia.org 의 각 페이지는 그 밈에 대한 페이지다. 앞엣것은 토큰 이름과 CA 가 페이지에 있고 뒤엣것은 없다.

그래서 디렉터리는 목록으로만 관리한다. 7개뿐이라 목록이 더 싸다.

목록에 없는 참조는 전부 web_site 로 떨어진다. 실제로 thaipbs.or.th 13건이 그렇게 들어가 있다. 태국 공영방송인데, 13개 토큰이 같은 기사 하나를 걸어서 "토큰마다 다른 페이지" 규칙에 안 걸렸다.

규모를 재려면 web_site 657개 도메인을 훑어야 하는데 아직 안 했다.

A. 뽑을 수 있고, 상위 10% 로 제한할 이유가 없다. HTML 은 이미 받고 있어서 추가되는 것이 파싱뿐이기 때문이다. 다만 어디서 나오고 어디서 안 나오는지가 갈린다.

24건을 실제로 열어 확인했다.

• 뉴스와 위키밈은 완벽하다. nypost 3/3 과 knowyourmeme 3/3 이 og:title · og:description · article:published_time 을 전부 준다. knowyourmeme 의 og:description 은 밈 설명 전문이라 "이 토큰이 무슨 밈인가" 의 직접적인 답이 된다.
• wikipedia.org 는 <title> 만 준다. og:description 을 안 쓴다.
• tenor.com 은 GIF 제목을 준다.
• truthsocial.com 은 3/3 전부 실패다. og:title 이 Donald J. Trump (@realDonaldTrump) 로 계정명 고정이고 게시물 내용이 없다. 79건을 호출해도 얻는 것이 없다.
• facebook.com 은 절반이다. 로그인 벽에 안 걸린 건은 og:description 에 본문 전문이 왔고, 걸린 건은 제목이 Facebook 뿐이었다.
• linktr.ee 는 403 이다. 봇 차단이라 아예 못 연다.

그래서 방법을 종류별로 매핑한다.

🔴 부수적으로 더 큰 것이 나왔다. knowyourmeme 의 article:published_time 이 2009 · 2018 · 2023 으로 왔다. 밈이 토큰보다 몇 년 앞선 것인지가 그냥 나온다.

이 필드는 audit 이 *"isNews 에 완전히 흡수된다"* 며 제거 확정한 것이다. 그 판단은 tokens.web{} 관점에서는 맞았다. 참조를 Content 로 보내면 이것이 posted_at 이고, X trending 의 snowflake 시각과 같은 역할을 한다 — *"밈이 토큰보다 앞서는가"*. 되살려야 한다.

A. 된다. 실측 4/4 가 301 로 풀렸다.

t.co/ZE0NALoEfx → instagram.com/reels/DbLbraCOOwr/
t.co/B3PBdNIand → stockcat.lol
t.co/rmY6kBxVBW → catwifcap.fun
t.co/q1q66gv2gj → bootoshi.ai

목적지를 보면 t.co 35건은 소셜이 아니다. 대부분 토큰사이트이고 일부는 이미 fetcher 가 있는 소셜이다. 즉 §3 에서 단축링크를 web_social 에서 빼기로 한 것이 맞았고, 푸는 방법도 확인됐다.

이건 G-18(단축 해제)이 다룰 일이고 bit.ly 와 같은 맥락이다. G-18 이 세운 조건 두 개가 그대로 적용된다. 첫째, tokenInfo 경계에서 한 번 풀고 아래로는 canonical 만 흘린다. 둘째, SSRF 방어를 위해 maxRedirects: 0 으로 홉을 직접 돌며 사설 대역을 차단한다.

같이 확인된 것 — linktr.ee 2/2 가 403 이다. G-18 이 *"리다이렉트가 아니라 랜딩·스마트 링크라 따라가도 목적지가 안 나온다"* 고 적어둔 예외인데, 실제로는 그보다 나빠서 봇 차단으로 페이지 자체를 못 연다.

---

A. 종류가 틀린 게 아니라 도메인 키 계산이 틀린 것이기 때문이다.

나머지 넷(단축링크 · GIF 호스트 · google.com · archive.org)은 도메인이 하나로 정해져 있고 그 도메인을 어느 종류에 넣을지만 정하면 끝난다.

blog.jp 는 도메인 자체가 잘못 만들어졌다. *.blog.jp 는 일본 개인 블로그 호스팅이라 서브도메인마다 주인이 다른데, 이번 분류에 쓴 접미사 34개 목록에 blog.jp 가 없어서 30건이 한 도메인으로 합쳐졌다.

같은 종류의 오류가 그 34개 밖에 몇 개 더 있는지는 Public Suffix List 를 제대로 쓰기 전에는 알 수 없다.

G-4 는 검색 URL 을 외부 호출 없이 검색어 한 행으로 만든다. google.com 의 66건 중 검색 결과 URL 은 그 규칙에 그대로 들어갈 수 있어 보인다.

문제는 docs.google.com 과 sites.google.com 이다. 이 둘은 검색이 아니라 문서와 사이트 호스팅이고, 서브도메인마다 주인이 다르므로 blog.jp 와 같은 부류다. 66건의 내부 구성을 아직 안 봤다.

---

A. 뽑을 수 있다. 열린 도메인 기준 82% 에서 text 가 나온다. 다만 폴백 순서는 예상과 달랐다.

180개 도메인 308 URL 을 조사했고 124 도메인이 열렸다(69%). 못 연 56개는 403 봇 차단이 대부분이다. 수집은 결정적인 스크립트가 했고, "있다" 와 "쓸모 있다" 를 가르는 판정은 Sonnet 에이전트 9개가 나눠 맡았다.

폴백 체인은 실제 기여도로 정했다. 표준을 하나씩 더할 때 text 가 채워지는 도메인이 몇 개 늘어나는지를 잰 결과다.

🔴 JSON-LD 우선이라는 예상이 뒤집혔다. 구글 리치결과 때문에 유인이 가장 강할 것으로 봤는데, 실제로는 og 하나가 61.3% 를 혼자 덮고 JSON-LD 는 10 도메인만 더한다. 표준 <title> 이 JSON-LD 보다 앞선다.

필드마다 값어치가 다르다.

• published 는 참조에서만 나온다. article:published_time 이 참조 밖에서 사실상 0 인 것과 일치한다.
• tags 는 쓸 수 없다. 최고가 참조 40% 이고 툴·디렉터리는 0% 다. 에이전트가 *"site-wide category labels, not topics"* 라고 반복해 지적했다.
• JSON-LD articleBody 로 본문 전문이 오는 곳은 11개 도메인이고 전부 뉴스사다(cnn·foxnews·cbsnews·dexerto·vogue·mirror.co.uk 등).

도메인별 셀렉터는 만들지 않는다. 조사한 것은 표준 8종뿐이고, 그것만 보는 이유는 사이트가 그것을 유지할 유인이 따로 있기 때문이다. 검색 리치결과와 SNS 공유 미리보기가 깨지면 사이트 주인이 손해를 본다. CSS 셀렉터에는 그런 유인이 없어서 리뉴얼 한 번에 깨지고, 180개를 유지할 방법도 없다.

A. 두 부류로 갈리고, 한쪽은 그 자체가 신호다.

첫째는 로그인 벽과 템플릿 응답이다. 에이전트 note 가 그대로 짚었다 — LinkedIn 과 Instagram 은 og 세 개가 전부 로그인 안내문이었고, Twitch 는 채널 태그라인 고정, Myspace 는 사용자명만 끼워 넣은 사이트 공통 템플릿이었다. truthsocial 은 이미 확인한 대로 계정명 고정이다.

둘째가 흥미롭다. text 가 boilerplate 인 web_site 도메인이 이렇다.

longdog.lol · pumpga.fun · littlepoe.lol · crypto.grok.me · darkarena.app

소유권 조사에서 placeholder 로 나온 바로 그 도메인들이다. 에이전트도 독립적으로 같은 것을 짚었다 — *"description matches the homepage tagline verbatim, not specific to this token"*.

즉 템플릿을 깔고 내용을 안 채운 사이트는 CA 도 안 채우고 OG 도 안 채운다. 두 조사가 서로 모른 채 같은 집단을 가리켰다. text 결측을 "정보 없음" 으로 버리면 안 되고 placeholder 로 기록해야 하는 근거가 하나 더 생겼다.

A. 쓸 수 있다. 다만 전량이 아니라 결측 보정용이다.

처음에는 못 쓴다고 판단했다. 근거는 6주 지난 링크 42건 중 피드에 남아 있는 것이 6건(14.3%)뿐이었다는 것이다. 그 판단이 두 군데 틀렸다.

첫째, 시간창을 잘못 봤다. 내가 근거로 삼은 knowyourmeme 이 항목 4개짜리로 가장 짧은 축이었다. 실제로는 사이트마다 자릿수가 다르다.

trib.al          150항목  283일
dailymail.com    150항목   41일
knowyourmeme       4항목    3일    ← 이것만 보고 판단했다
foxnews.com       25항목    0일

둘째, 더 중요한 것 — OpenGraph 가 비는 사이트에서 RSS 가 유일한 출처다. dailymail.com 기사 하나를 실제로 열어 확인했다.

기사 페이지 899KB              RSS 항목
  og:title  없음                 title  Andy Burnham says high streets…
  og:desc   빈 문자열            desc   The Prime Minister has pledged…
  pub_time  없음                 date   Mon, 10 Aug 2026 22:09:40 GMT

dailymail.com 은 배정에서 P3 title-only 였다. OpenGraph 가 통째로 비어 jsonld:headline 으로 제목만 겨우 건졌기 때문이다. 피드를 보면 P1 으로 올라간다.

그리고 실시간이면 적중률이 다르다. 14.3% 는 링크를 받은 지 6주 지난 데이터로 잰 하한이다. 실제 파이프라인은 token.flow 를 실시간으로 받으므로 토큰이 방금 건 기사는 대개 피드 안에 있다. RSS 의 값어치는 수집 시점과 발행 시점의 간격이 정한다.

확인한 사실 — 태그가 있다고 피드인 것이 아니다. 34개 도메인에 rel=alternate rss 태그가 있었는데 실제로 파싱된 것은 24개, 요약까지 있는 것은 22개다. 나머지는 앱 껍데기이거나 404 다. truthsocial 에서 같은 함정을 먼저 봤다 — 존재하지 않는 계정의 .rss 도 200 과 함께 3.5KB 껍데기를 돌려준다.

그래서 규칙을 좁혔다.

① OG 폴백 체인을 먼저 돌린다
② text_body 또는 published 가 비었나?
     아니오 → 끝. RSS 를 부르지 않는다        (P1 · P2 는 여기서 끝난다)
     예   → ③
③ 그 도메인에 rel=alternate rss 링크가 있나?
④ 피드를 받아 항목 link 를 이 URL 과 대조하고 빈 칸만 메운다

이러면 "추가 호출 0회" 원칙이 P1·P2 에서는 유지되고, OpenGraph 가 약한 P3·P4 에서만 도메인당 1회가 든다. 피드는 도메인당 하나라 캐시가 잘 들어서, 같은 사이트 기사 100건이면 호출은 1회다.

⚠️ 실시간 조건의 적중률은 아직 못 쟀다. 지금 데이터로는 잴 수 없고 파이프라인에 붙여야 나온다.

A. Content.data{} 로 간다. tokens.web{} 는 폐기한다.

website 를 Content 로 다루기로 한 이상 지문도 거기 붙는 것이 맞다. 근거가 셋이다.

첫째, ContentDataInput 의 정의가 정확히 그것이다. 주석이 *"조회축이 아닌 값만 담는다 — 축이 되는 순간 최상위 필드로 승격한다"* 이고, 키 이름은 fetcher 반환 타입 그대로 쓴다(G-7). registrar · techCount · hasTracking · certIssuer 는 전부 배경정보라 이 정의에 맞는다.

둘째, 저장소가 하나로 준다. tokens.web{} 를 안 쓰면 updateWeb() 의 통째 교체 문제도 사라진다. 그 메서드는 부분 병합이 안 돼서 지문 일부만 갱신할 방법이 없었다.

셋째, 도메인 공유 카운트가 자연스러워진다. fingerprints[] 라는 별도 축을 만든 이유가 *"같은 도메인을 쓴 토큰이 또 있나"* 였는데, data.domain 집계로 끝난다. token_links.linked_at 이 as-of 절단축을 이미 갖고 있어 look-ahead 방어도 그대로 붙는다.

앞서 내가 우려한 “복제” 는 실은 이득이다. 같은 도메인을 30개 토큰이 쓰면 지문이 30번 복제된다고 걱정했는데, resolveContent 가 기존 행을 갱신하지 않으므로(G-6) 한 행에 모으면 첫 관측 시점이 영구 고착된다. techCount · hasTracking · server · ip 는 WEBSITE_VALUE_NATURE 가 mutable 로 찍은 값이라, 반년 뒤 토큰이 같은 도메인을 걸어도 반년 전 값을 보게 된다. 복제하면 각 행이 자기 시점의 지문을 갖는다. 그것이 tokens.web{} 의 유일한 장점이었고, 복제로 그대로 얻는다. 비용은 실측 66B/토큰이라 무시할 수준이다.

붙는 조건 — platformKey 는 정규화 URL 이다. 여기서 복제 여부와 페이지 뭉갬이 갈린다. apex 도메인으로 잡으면 지문은 안 복제되지만 coincommunities.org 112개 페이지가 한 행으로 눌린다. text 를 뽑기로 한 이상 URL 이어야 한다 — 경로 있는 링크가 최소 51.7% 이고, 공유 도메인 키의 33.3% 가 서로 다른 페이지를 담고 있었다.

따라오는 것 둘.

• fingerprints[] 에서 domain: 을 뺀다. image: 만 남는다. 앞서 *"툴·참조 도메인이 지문에 들어가면 같은 팀이 아니라 같은 거래소를 쓴다를 세게 된다"* 고 한 문제가 여기서 자동으로 해결된다.
• data.domain 과 data.domainCreatedAt 은 실제로 조회축이라 ContentDataInput 주석 규칙과 어긋난다. MongoDB 는 중첩 필드에도 인덱스를 걸 수 있어 기능상 문제는 없지만, 왜 축인데 data 에 두는지를 주석으로 남긴다. 나중에 누가 규칙만 보고 되돌리는 것을 막는다.