URL ↔ 객체 ↔ 링크 구조

토큰이 건 링크가 유실되는 문제에 대한 구조. 이 문제와 무관한 필드(텍스트·지표·프로필 상세)는 전부 뺀 최소 모델입니다. · 관련 문서: 링크 도착점 모델 비교 (문제 정의와 후보안 비교) · available-queries.md (쿼리 경로 15개)

§1전제

1. URL 에 대응하는 매핑 객체는 관측 시점에 무조건 존재한다. unknown 도 객체로 저장한다.
2. 객체는 그 시점에 확인 가능한 모든 것을 확인한 상태로 만들어진다. fetch 가 가능하면 fetch 해서 platform_key 까지 풀어 기록하고, 불가능하면 URL 로 알 수 있는 데까지만 채운다.
3. 링크는 몽고 _id 로 연결한다. 어디에서(object) + 어떤 것(object_id).
4. 각 객체는 자신을 유래시킨 URL 목록을 관리한다.
5. 나중에 상세 분석으로 매핑이 바뀌면 재할당한다. 링크를 다시 끼운다.
6. _id 참조는 우리가 관측한 대상에만 쓴다. 관측하지 않은 언급(트윗의 mentions[] 등)은 _id 로 잇지 않고 값 그대로 저장한다. §5 약점 2 참조.

§2컬렉션

  _id  로 끝나면  →  항상 ObjectId. 우리가 발급하고, 우리 DB 안의 다른 행을 가리킨다
  _key 로 끝나면  →  항상 외부 문자열. 남이 발급하고, 우리가 만들지 않는다

  _id · creator_id · venue_id · parent_content_id · site_id · object_id     ObjectId
  platform_key   '2070140594496626759'   플랫폼 응답이 준 원 id
  url_key        'foo.com'               URL 에서 뽑은 식별자

{
  _id          ObjectId            // 정체성. 링크가 가리키는 값
  platform     enum     ●       // x · tt · ig · yt · rd · gh · tg
  subtype      enum     ●       // 컬렉션별 어휘 — 아래 표
  platform_key  string   ○       // 응답 유래 원 id. fetch 성공 시에만 채워진다
  source_urls  object[] ●       // 자신을 유래시킨 URL 목록
    ├ url         string  ●
    ├ status      enum    ●     // ok · skipped_paid · error · not_found · blocked · unsupported
    └ observed_at Date    ●
}

// 웹사이트를 어떻게 다룰지는 추가 분석이 필요해 보류한다. 지금까지 나온 것만 기록.
{
  _id          ObjectId
  url_key      string   ●       // 등록 도메인(apex)
  domain_created_at · domain_expiry_at · registrar   // RDAP 유래 — 도메인 단위
}

{
  _id           ObjectId
  token_address string   ●
  object        enum     ●      // contents · accounts · venues                ← 어디에서
  object_id     ObjectId ●      //                                            ← 어떤 걸
  source_url    string   ●      // 관측 시점에 실제로 본 URL. 재할당돼도 남는다
  platform      enum     ●      // 객체에서 복사(비정규화). 아래 설명
  subtype       enum     ●      // 객체에서 복사(비정규화)
  linked_at     Date     ●      // as-of 절단축
  observed_at   Date     ●
}

§3실제 데이터 — 토큰 하나가 소셜 5개를 걸었을 때

토큰 ABC…pump 의 소셜 필드가 아래와 같고, 관측 시점에 X 와 Telegram 은 fetch 에 성공했으며 Instagram 은 유료 게이트로 실패했다고 하겠습니다.

// 입력
website    = foo.com
twitter    = x.com/kolguy                    fetch ok  → platform_key 555
telegram   = t.me/abcchat                    fetch ok  → platform_key 777
discovered = tiktok.com/search?q=abc         비객체 — fetch 대상 아님
discovered = instagram.com/p/Bjnx75lFFQp     skipped_paid → platform_key 없음

객체 — 5개. fetch 실패한 것도 객체가 생긴다

accounts
  A1 { platform:x,   subtype:profile, platform_key:"555",
       source_urls:[{ url:"x.com/kolguy",                status:ok,           observed_at:t1 }] }

venues
  V1 { platform:tg,  subtype:channel, platform_key:"777",
       source_urls:[{ url:"t.me/abcchat",                status:ok,           observed_at:t1 }] }

contents
  C1 { platform:ig,  subtype:post,    platform_key:null,
       source_urls:[{ url:"instagram.com/p/Bjnx75lFFQp", status:skipped_paid, observed_at:t1 }] }
       ↑ 유료 게이트라 id 를 못 얻었다. 그래도 객체는 존재한다 (전제 1·2)

  C2 { platform:tt,  subtype:search,  url_key:"abc",
       source_urls:[{ url:"tiktok.com/search?q=abc",     status:unsupported,  observed_at:t1 }] }
       ↑ 검색도 contents 다 — TikTok 콘텐츠 공간의 좌표이므로 video 와 같은 컬렉션

sites  — 미결(§7 결정 1)
  S1 { url_key:"foo.com" }   웹을 페이지/도메인 2층으로 둘지 결론 안 남

token_links — 5행

token_links
  { token:ABC, object:accounts, object_id:A1, platform:x,  subtype:profile, source_url:"x.com/kolguy"                }
  { token:ABC, object:venues,   object_id:V1, platform:tg, subtype:channel, source_url:"t.me/abcchat"                }
  { token:ABC, object:contents, object_id:C2, platform:tt, subtype:search,  source_url:"tiktok.com/search?q=abc"     }
  { token:ABC, object:contents, object_id:C1, platform:ig, subtype:post,    source_url:"instagram.com/p/Bjnx75lFFQp" }
  { token:ABC, … foo.com … }  ← 웹 링크가 무엇을 가리킬지는 미결(§7 결정 1)

§4재할당 — 나중에 매핑이 바뀔 때 무엇을 고치나

전제 5 가 말하는 재할당은 실제로 세 가지 형태로 나타나고, 고쳐야 할 범위가 각각 다릅니다. 아래 세 케이스는 모두 audit 실측 또는 fetcher 계약에 근거가 있는 것들입니다.

t1  x.com/search?q=abc  → 파싱 실패
    contents N9 { platform:x, subtype:unknown, url_key:null }

t2  classifier 추가 → x 의 검색 URL 로 해석됨
    contents N9 { platform:x, subtype:search,  url_key:"abc" }   ← 컬럼만 갱신

token_links  subtype 복사본만 함께 갱신. object_id 는 그대로

t1  vm.tiktok.com/ZSABC123  → 해석 불가
    contents C7 { platform:tt, subtype:shortlink }
    token_links { object:contents, object_id:C7, source_url:"vm.tiktok.com/ZSABC123" }

t2  해석됨 — 영상 7412… 이었다

    ① 그 영상의 contents 행이 아직 없다면            범위 1군데
       C7 { subtype:video, platform_key:"7412…" }   ← 컬럼만 갱신
       token_links 는 손대지 않는다

    ② 이미 C9 로 존재한다면                          범위 3군데
       C9.source_urls 에 "vm.tiktok.com/ZSABC123" 추가
       token_links 재연결 { object_id:C9, subtype:video,
                            source_url:"vm.tiktok.com/ZSABC123" }  ← 그대로 남는다
       C7 삭제

t1  instagram.com/p/Bjnx75lFFQp            → contents C1 { platform_key:null }
t2  instagram.com/{handle}/reel/DZ8NYQ8xnRp → contents C2 { platform_key:null }
    둘 다 유료 게이트라 id 가 없어, 같은 게시물인지 알 수 없다

t3  유료 옵션을 켜고 재관측 → 둘 다 platform_key "17954…" 로 밝혀짐
    1. C2.source_urls 에 C1 의 URL 들을 합친다
    2. token_links 중 object_id=C1 인 것을 전부 C2 로 재연결
    3. C1 삭제

§5쿼리 적합성 평가

이 구조가 못 하는 쿼리가 무엇인지, 그 쿼리가 실제로 필요한지를 따졌습니다. 요구사항은 available-queries.md 의 탐색 경로 15개를 그대로 썼습니다. 다만 그 문서가 제안한 스키마는 다릅니다 — tokens.contentRefs[] · contents.linkedTokenAddresses[] 양방향 배열 구조인데, 판단 기록 3 에서 검토해 채택하지 않은 방식입니다. 그래서 경로 목록만 요구사항으로 사용했습니다.

약점 1 — 텍스트 검색이 여러 컬렉션으로 흩어진다 (C-1)

토큰 CA 나 키워드가 나오는 곳이 콘텐츠 본문만이 아닙니다. 설계 문서 §1.5 는 venues.description 에 대해 "토큰 CA 가 실제로 여기 노출됨(실측)" 이라고 적고 있고, accounts.bio 도 마찬가지입니다. 따라서 "CA 가 노출된 모든 곳"을 찾으려면 $unionWith 로 세 컬렉션을 합쳐야 하고, 텍스트 인덱스도 세 벌이 필요합니다.

가능성과 효용은 둘 다 높습니다. C-1 은 내러티브 클러스터링의 진입점입니다. 다만 이번 구조가 만든 문제가 아닙니다. contents/accounts/venues 분리는 원래부터 있었고 텍스트가 세 곳에 흩어진 것도 원래부터입니다. 비객체를 contents 에 합쳐도 그 행들에는 텍스트가 없어 대상이 늘지 않습니다.

약점 2 — mentions[] 를 _id 로 참조하면 안 된다 (E-3)

이건 이번 구조가 새로 만드는 문제라 전제 6 으로 올렸습니다. 전제 3(링크는 _id 로 연결)을 mentions[] 에도 적용하면, 트윗에 언급된 계정마다 accounts 에 빈 행을 만들어야 합니다. x_tweet 만 3,879건이고 트윗 하나에 멘션이 여럿이라 빈 행이 폭증합니다.

그런데 멘션은 관계가 아니라 관측된 텍스트 사실입니다. 우리가 그 계정을 fetch 한 적이 없고 존재 여부도 모릅니다. 그래서 값 그대로 저장하고, 나중에 그 계정을 실제로 관측하면 platform_key 로 이어지게 하는 것이 맞습니다. E-3 의 코-멘션 클러스터링은 platform_key 기준 group 으로 풀립니다.

mentions: [{ platform_key: "1534…", screen_name: "kolguy" }]   ← _id 참조 아님

쿼리 비용 — "이 토큰의 모든 소셜"

1. token_links.find({ token_address: ABC })                    → 1회
2. object 별로 묶어 각 컬렉션에 _id $in 조회                   → 최대 4회 (병렬)
                                                               ─────────
                                                               순차 5회 · 병렬 2 라운드트립

토큰 100개를 한 번에 뿌려도 쿼리 수는 그대로다 — $in 으로 묶이므로 N+1 이 생기지 않는다.
플랫폼·종류만 필요하면 token_links 1회로 끝난다 (비정규화 복사).

§6현행 스키마 대비 변경 폭

컬렉션 추가가 하나뿐이고 기존 마스터는 필드 두 개를 더하는 선에서 끝납니다. 아직 실데이터가 없어 마이그레이션 자체가 없습니다.

§7남은 결정 항목

1. 결정 1 · 웹사이트 — 별도 작업으로 이관. 조사 기간이 길고, 잠정 규칙을 두면 나중 결정이 전부 덧붙이기가 되어 구현을 막지 않는다. 잠정 규칙과 근거는 아래에.
2. subtype 어휘를 무엇으로 확정할 것인가. 특히 Telegram 의 portal·shell 은 URL 만으로는 판정할 수 없고 프리뷰를 받아야 갈립니다 (실측 24건: 포털 54% · 빈껍데기 25% · 활성 4%). 이것을 subtype 으로 볼지, 관측 결과 필드로 내릴지 정해야 합니다.
3. source_urls[] 항목에 구간을 넣을 것인가. TikTok 은 핸들을 한 달 주기로 회전시키고 옛 핸들을 재할당합니다. 같은 URL 이 시기별로 다른 계정을 가리킬 수 있으므로, 항목에 first_seen/last_seen 을 넣으면 as-of 로 풀 수 있습니다. accounts.handles[] 가 이미 같은 방식이라 새 개념은 아닙니다.
4. status 를 어디에 둘 것인가. 지금 source_urls[].status 와 링크 쪽 상태가 둘 다 존재할 수 있습니다. 링크는 append-only 라 상태 이력을 담고 객체 쪽은 최신값이 되는데, 둘의 역할 분담을 명시해야 합니다.
5. 텍스트 검색 대상 범위. contents.text 만 볼지, venues.description· accounts.bio 까지 $unionWith 로 묶을지 (§5 약점 1).
6. 재분류 배치의 트리거. classifier 를 추가할 때마다 돌릴지 주기적으로 돌릴지에 따라, 범위 1군데짜리 재할당이 언제 정리되는지가 달라집니다.

결정 1 상세 — 웹사이트 (별도 작업으로 이관)

1. 웹 URL 도 contents 에 넣는다.   platform='web' · subtype='site'
2. tokens.web{} · fingerprints[] 는 현행 그대로 둔다
3. contents(web) 에 도메인 층 필드를 만들지 않는다 (site_id 도 아직 없음)

웹은 지문의 출처부터 두 층으로 갈려 있습니다. 필드 인벤토리(sources/website-image.html)를 소스별로 정리하면 이렇습니다.

그리고 검증된 신호가 두 층에 갈려 있습니다. 도메인 층에는 도메인 나이 731일+(rug 85/84/91%)와 도메인 공유 카운트(knowyourmeme.com 22건 rug 100% · axiom.trade 21건 90% · orynth.dev 18건 0%)가 있고, 페이지 층에는 isNews = true(rug 80/89/100%)와 technologies 4개+(rug 83/87/98%)가 있습니다. 도메인으로만 접으면 페이지 층이 뭉개지고, 페이지로만 두면 도메인 지문이 페이지마다 복사됩니다.

contents  { platform:web, subtype:page|article, url_key:"정규화 URL",
             og_title · is_news · server · tech_count,   // 페이지 층
             site_id → sites._id }
sites     { url_key:"apex 도메인",
             domain_created_at · domain_expiry_at · registrar }   // 도메인 층

도메인 공유 카운트 = site_id 가 같은 contents 들의 링크 수
페이지 카운트     = url_key 별

웹 URL 정규화 규칙 초안 — 소셜과 달리 URL 자체가 키라서 명시가 필요합니다.

이 문서에 없는 것 — 텍스트·지표·프로필 등 상세 필드, 인덱스 설계, 그리고 draft 의 나머지 항목 (공통 필드 최소화, Creator 재정의, 최적화용/공용/개별 필드의 문서 표기 구분). 전부 위 결정들이 확정된 뒤에 붙습니다.