소셜 스키마 v3 — URL 구조 audit 반영

① v2 검증 결과 audit이 사후 확인해준 것

② 갭 3개와 확정 v2에 없던 것

③ 컬렉션 전체도 Tier 1 확정 반영

④ ERD 엔티티 · PK/FK · 카디널리티

카디널리티 요약

왜 배열이 아니라 엣지인가 토큰당 링크 3~8개인데도

토큰 하나에 소셜 링크가 여러 개 생긴다. tokens.socialLinks[] 배열로 임베딩하는 안과 엣지 컬렉션 안을 비교하면:

계보를 링크에 담는다 — lineage quote 가 주 경로이기 때문

elon 원본 트윗 X
   ↓ 배포자가 자기 계정으로 인용
배포자 트윗 Y  (quote of X)
   ↓ 토큰이 Y 를 소셜 필드에 걺
토큰 T

content_token_links {
  contentKey: "x_tweet:Y",        // 토큰이 실제로 건 것
  lineage:    ["x_tweet:Y",       // ← 자기 자신
               "x_tweet:X"],      // ← 조상 (깊이 2 제한이라 최대 2개)
  linkDepth: 0,                // 0=직접 · 1~2=인용 경유
  tokenAddress, linkedAt, status, tokenCreatedAt
}

왜 lineage 에 자기 자신을 넣나 — $or 를 없애려고

두 질문이 두 필드로 갈린다

토큰 A → X 직접           →  contentKey=X, lineage=[X]
토큰 B → Y(quote of X)    →  contentKey=Y, lineage=[Y, X]

{contentKey: X} → 1건   (직접)
{lineage:    X} → 2건   (실질)  ← 재사용 신호가 여기서 잡힘

두 숫자가 다르다는 것 자체가 정보다 — "직접 1, 실질 2"는 배포자가 원본을 우회 차용했다는 뜻이다.

contentKey 는 lineage[0] 과 항상 같아 중복 저장이지만, 두 질문을 인덱스로 분리하는 값이 그 비용보다 크다. contents.parentContentId 는 그대로 둔다 — 계보는 콘텐츠 자체의 속성이고(토큰 없는 콘텐츠도 계보가 있다), lineage 는 링크 조회 최적화용 비정규화다. 계보는 불변이라 동기화 문제가 없다.

네트워크 축 판정 — account_edges 는 만들지 않는다 star topology 가설

저시총 배포자 A ──quote/mention──▶ KOL·인플루언서 X
저시총 배포자 B ──quote/mention──▶ KOL·인플루언서 X
저시총 배포자 C ──quote/mention──▶ KOL·인플루언서 Y
                A · B · C 사이엔 엣지가 거의 없다

star 에서 네트워크 축이 어떻게 되나

남는 질문은 전부 기존 구조로 답한다

비정규화 원칙 — 불변만 복사한다

기준: linkedAt 시점에 확정된 불변 사실만 복사한다. 가변값 복사는 동기화 지옥이다.

⑤ 수집 흐름 언제 · 누가 · 어떤 순서로 쓰나

쓰기 방식이 갈린다 "이미 있으면 링크만"의 함정

왜 pull 인가 — 그리고 무엇을 포기하는가

첫 관측(linkedAt 근처) 스냅샷   →  t_c~t_0 요약   →  상대적으로 clean
그 이후 스냅샷의 증분          →  오염 구간       →  별도 취급

⑥ 3층 구조 소셜별 차이를 담는 규칙

핵심 질문은 "공통으로 올릴 것과 소셜 고유로 남길 것을 무엇으로 가르나"다. 기준은 하나 — 크로스플랫폼 쿼리가 그 필드를 필요로 하는가.

⑦ 공통 의미축 × 6소셜 매핑 L1 core

Content

참여 지표 — 이름을 통일하지 않는다

비교 가능한 것은 절대 카운트가 아니라 "소셜 내 상대 위치"다. 비교는 파생층에서 한다(§⑦ 하단).

소셜별 지표 인벤토리 저장은 원래 이름 그대로 · 아래는 참고용 분류

이 표는 어떤 소셜이 무슨 지표를 갖는지 보는 인벤토리이지 매핑 규칙이 아니다. GitHub의 open_issues_count(이슈)·forks_count(포크)는 "대화"·"재확산"과 행위 성격이 다르고, audit 결론상 GitHub은 모멘텀 채널이 아니라 러그 검증 채널이라 같은 축에 세울 이유가 없다.

Creator

⑧ 지표는 별도 컬렉션 contents에서 분리 · 단 time-series는 안 씀

MongoDB time-series 컬렉션은 쓰지 않는다 규모 미달 + 레포 제약

채택 — 일반 컬렉션 + 복합 인덱스

@index({ content_key: 1, observed_at: 1 })      // 콘텐츠 타임라인
@index({ platform: 1, observed_at: 1 })        // 소셜 코호트(백분위 계산)
export class ContentMetricSnapshot extends BaseModel {
  @prop({ required: true }) content_key: string;   // "x_tweet:2070..."
  @prop({ required: true }) platform: string;
  @prop({ required: true }) observed_at: Date;
  @prop({ type: Schema.Types.Mixed, required: true })
  metrics: Record<string, number>;               // polymorphic — 소셜 원래 이름
}

1개 컬렉션 vs 소셜별 분리 → 1개

소셜 차이를 아는 파일은 하나 METRIC_SPEC 레지스트리

metrics가 polymorphic이라 읽는 쪽에 소셜별 지식이 필요하다. 그게 호출부마다 흩어지면 if (platform === 'tt') … else if ('x') …가 코드베이스 전역에 복제되고, 지표가 하나 늘 때마다 전부 찾아 고쳐야 한다. 소셜별 지표 스펙을 한 곳에만 둔다.

// 이 파일 하나만 소셜 차이를 안다
const METRIC_SPEC = {
  x:  { reach: 'viewCount', engage: ['likeCount','replyCount'],
        spread: ['retweetCount','quoteCount'], save: 'bookmarkCount' },
  tt: { reach: 'playCount', engage: ['diggCount','commentCount'],
        spread: ['shareCount','repostCount'],  save: 'collectCount' },
  rd: { reach: null,        engage: ['upVotes','commentsCount'],
        spread: ['numCrossposts'],           save: null },
  gh: { reach: null, engage: null, spread: null, save: null },  // 모멘텀 채널 아님
  …
}

읽는 쪽은 spec(platform).reach로 역할을 물어보지 필드명을 직접 알지 않는다.

구조적으로 기존 레포 패턴과 같다 — SocialFetcherRouter.classify()가 소셜 분기를 한 곳에서 흡수하고 각 fetcher가 handles: SocialSourceType[]로 담당을 선언하는 것과 동일하게, 소셜 지식을 레지스트리 1곳에 가두고 나머지는 타입으로만 다룬다.

비교는 파생층에서 raw가 아니라 상대 위치

metricRanks: {                // 파생 — 언제든 버리고 재생성
  cohort: "platform:x · tokenAge 0~5m",
  reachPct: 0.92,            // 같은 소셜·같은 시간대 코호트 내 백분위
  computedAt, inputCutoff, ruleVersion
}

백분위는 0~1 스케일이라 크로스 소셜로 놓아도 오염이 없고, v2의 파생층 규칙(computedAt·inputCutoff 필수, 언제든 재생성)에 그대로 들어간다. raw 카운트는 소셜별로 두고, 비교는 정규화된 파생값으로 한다 — 이것이 "같은 소셜끼리만 비교 가능"에 대한 답이다.

⑨ ext 네임스페이스 L2 — 소셜 고유 keep 필드

⑩ venues 컬렉션 신규

// _id = platform:venueId
{
  _id: "x:1952999882635264271",     // reddit: "reddit:wallstreetbets"
  platform: "x",
  venueId: "1952999882635264271",
  name: "Sheep Wif Hat",
  createdAt: ISODate(...),          // 개설일 — 런칭 직전 급조 tell
  creatorId: "x:1283966981297680384",  // accounts 참조 (id로, handle 아님)
  description: "... CA: 21Xp...pump",   // 토큰 CA가 실제로 여기 노출됨(실측)
  metrics: { members: 4720, moderators: 11 },
  observedAt: ISODate(...),
  ext: { x: { adminHandle: ... } },   // L2 — platform(구분)과 키 충돌 방지
  // raw 는 여기 없다 → content_raw 컬렉션(_id = venueKey)
}

⑪ 관측 시각 규칙 v2 observedAt 보강

규칙: 중첩 임베딩된 스냅샷은 부모 문서의 observedAt을 상속하고, 그 사실을 sourceRef로 남긴다.

accounts/x:1534395199958306816
  observedAt: 2026-07-29T…      // 이 레코드가 관측된 시각
  sourceRef: {
    via: "x_tweet",             // 직접 프로필 조회가 아니라 트윗 응답에서 파생
    contentKey: "x_tweet:2070140594496626759",
    depth: 1                     // 0=최상위 author, 1=quoted_tweet.author
  }

• 왜 필요한가: 같은 계정의 followers가 여러 경로로 들어올 때 어느 값이 더 최신인지 판별해야 한다. observedAt 비교만으로 충분하되, 신뢰도가 다를 수 있어 출처를 남긴다
• Reddit·TikTok은 actor가 crawledAt을 직접 준다 → fetch 시각 대신 그 값을 쓴다(실제 스크랩 시각이 더 정확)
• 미fetch 엔트리(유료 게이트로 skip된 것)는 id가 없고 handle만 남는다 → resolved(실측) / inferred(handle 추정) 구분 필요

상태의 SoT — 이력은 links, contents 는 최신값 캐시 Tier 1 확정

캐시를 두는 이유는 "현재 살아있는 것만" 같은 목록 조회에서 조인을 없애기 위해서다. 덮어써도 원본이 links 에 남아 있어 되감기 손실이 없다 — metricsLatest 와 같은 성격이다.

handles: [
  { value: "knowyourmeme", firstSeen: …, lastSeen: … }
]

⑫ sourceType enum 최종 audit 확정분

⑬ 저장 매핑 Tier 1 확정 — 라우터 산출을 어디에 넣나

가장 까다로운 지점 — sourceKey ≠ 저장 키

audit 전체의 결론이 "조인키는 fetch 응답 안에 있다" 였다. 그래서 URL 에서 뽑은 sourceKey 와 실제 저장 키가 다르다.

그리고 1개 결과 → N개 레코드 (fan-out)

x_tweet 1건 fetch
 ├─ Content  : 트윗 자신           _id = data.id
 ├─ Creator  : 작성자              _id = data.authorId
 ├─ Content  : 인용 원본           _id = data.quoted.id          ← fan-out
 ├─ Creator  : 인용 원본 작성자     _id = data.quoted.authorId    ← fan-out
 └─ Venue 링크: data.communityInfo

즉 매핑은 sourceType → 컬렉션 1:1 이 아니라 "결과 → 레코드 목록"을 만드는 규칙이다.

어디에 두나 — 상수 맵 + ContentGenerator 채택

이름을 generator 로 한 이유 — 실제로 1 URL → N 객체 생성이라 "맵(1:1 대응)"보다 정확하다. METRIC_SPEC 과 같은 위치의 소셜별 지식이지만 역할이 변환이 아니라 생성이다.

기각한 대안 — 상수 맵 하나로 전부: fan-out 같은 구조를 표현할 수 없다. 각 fetcher 가 선언: fetcher 가 "가져오기 + 변환" 두 일을 하게 되고, 지표는 레지스트리로 모으면서 나머지는 흩뜨리는 비일관이 된다.

전체 매핑

⑭ 미해결 · 보류