feat(raw_posts): WhatsOnTheStar adapter — celebrity outfit ground-truth source

[cocoyoon]

Summary

SourceAdapter 인터페이스에 WhatsOnTheStarAdapter(platform=whatsonthestar)를 추가한다. Pinterest/Instagram과 달리 이 소스는 이미 셀럽-아이템(브랜드/상품명/가격)이 구조화 라벨링된 데이터라서, vision auto-tag를 우회하거나 ground-truth로 활용할 수 있다.

cf. #214 PinterestAdapter / #259 InstagramAdapter — 같은 패턴으로 등록.

사이트 분석

• URL: https://whatsonthestar.com
• 타입: 셀럽 outfit 식별 + 쇼핑 링크 (Lil Yachty, Lil Baby 등 힙합/연예인 중심)
• 렌더링: Nuxt.js SSR — 모든 페이지에 `window.NUXT=(function(...){...})` 형태로 데이터 임베드
• 공식 API: 프론트엔드용 공개 엔드포인트는 노출되지 않음 (`api.whatsonthestar.com`/`/api/*` 모두 404). iOS 앱(id=1534214433) 전용 API는 별도 분석 필요
• robots.txt: `Disallow: //go/` 만 — affiliate redirect 경로만 차단, 콘텐츠 크롤 허용
• sitemap: `https://cdn.whatsonthestar.com/sitemaps/sitemap.xml\` (lastmod 2020 — 거의 갱신 안 됨, 페이지 인벤토리 부정확)

데이터 구조 (포스트 단위)

각 outfit 포스트에 다음 필드:

• celebrity: 이름 + 프로필 slug
• date worn: 착용 날짜
• outfit total: 전체 합계
• items[]: `{brand, product_title, price, sale_price, retailer_url(affiliate)}`
• photo URL

스크랩 전략 (제안)

1. 1순위: `window.NUXT` 페이로드 파싱 — Nuxt가 SSR로 직렬화해주는 JSON에서 outfit/items 추출. 헤드리스 없이 가능 (regex/AST로 추출 후 `eval(function(...))` 평가). `api-server`의 기존 `httpx` + `pyminify` 또는 `mini-racer` 한정 평가
2. fallback: BeautifulSoup으로 outfit 카드 / item 리스트 DOM 파싱
3. discovery:
   • 셀럽 인덱스(`/celebrities/`) → 셀럽 별 페이지(`/celebrities/{slug}`) → outfit 페이지
   • 또는 `/recent` / `/popular` 류 글로벌 피드(확인 필요)
4. rate limit: 1 req/sec 보수적, exponential backoff

RawMedia 매핑

```python
RawMedia(
external_id=outfit_id, # 사이트 내부 ID
external_url="https://whatsonthestar.com/outfits/{slug}",
image_url=outfit_photo_url,
caption=f"{celebrity} on {date_worn}",
author_name=celebrity_name,
platform_metadata={
"celebrity_slug": ...,
"date_worn": ...,
"outfit_total": ...,
"items": [
{"brand": ..., "title": ..., "price": ..., "sale_price": ..., "retailer_url": ...}
],
},
)
```

Ground-truth 활용 (#348 processor 연계)

기존 vision pipeline은 사진에서 아이템을 detect하지만, 이 소스는 이미 라벨이 있다. 옵션:

• A. 우회: `parse_status='parsed'`로 직접 INSERT, `parse_result`에 라벨 그대로 저장
• B. 검증용: vision 돌리고 사이트 라벨과 비교 → recall/precision 측정 데이터로 활용
• C. 하이브리드: bbox는 vision, brand/title은 site 라벨

Phase 1은 A 권장. B는 별도 evaluation 잡으로 분리.

Scope (this issue)

• `packages/ai-server/src/services/raw_posts/adapters/whatsonthestar.py` 신설
• `SourceAdapter` Protocol 구현 — `platform="whatsonthestar"`
• `source_type`: `outfit`(단일 포스트), `celebrity`(셀럽 페이지 페이지네이션)
• Nuxt 페이로드 추출기 (재사용 가능하게 helper 분리)
• `build_default_adapters` 등록 (`adapters/init.py`)
• 단위 테스트 (`tests/unit/services/raw_posts/test_whatsonthestar_adapter.py`) — fixture HTML, ≥3 outfit 케이스
• env vars: `WHATSONTHESTAR_INITIAL_LIMIT` / `WHATSONTHESTAR_INCREMENTAL_LIMIT`
• 어댑터 docstring + README 1-pager

Out of scope

• 벌크 백필/스케줄러 통합 (별도 이슈)
• iOS 앱 API 리버스 (시간되면 follow-up)
• 라벨 → 정식 `items`/`brands` 테이블 매핑 (feat(raw-posts): Nano Banana hero reframe + Gemini Vision 파싱 (assets 파이프라인 #344 후속) #348 processor 작업)

Acceptance

• 셀럽 페이지 1개로 `fetch()` → `List[RawMedia]` 반환 (≥10 items 페이지에서)
• 아이템 메타(brand/title/price)가 `platform_metadata.items`에 보존
• 테스트 그린, lint 통과

[cocoyoon]

✅ PoC 성공 — Nuxt IIFE 추출만으로 데이터 100% 확보

Scrapling/Playwright/헤드리스 불필요. `curl + node vm.runInNewContext` (또는 `py_mini_racer`) 한 번이면 끝.

검증 URL

`https://whatsonthestar.com/outfit/lil-yachty-43564\`

추출 결과 (요약)

`window.NUXT` IIFE 평가 → `data[0].outfit` 에 Apollo GraphQL 응답이 그대로:

```json
{
"outfit": {
"id": "43564",
"slug": "lil-yachty-43564",
"gender": "Male",
"images": [{"data": "/uploads/1754915183559.jpeg"}],
"likes": {"count": 552},
"artist": {
"id": "312",
"slug": "lil-yachty",
"name": "Lil Yachty",
"career": "Rapper",
"instagram": "lilyachty",
"avatar": {"data": "/uploads/..."}
},
"items": [
{
"id": "257865",
"name": "Less Faith Yellow Longsleeve Thermal",
"category": {"name": "Tops", "slug": "tops"},
"currency": "USD",
"price": "200",
"salePrice": null,
"releasedAt": "2025-08-11T12:28:28.000Z",
"image": {"data": "/uploads/1754915322528.webp"},
"brands": [
{"id":"2293","slug":"endless","name":"Endless Denim","instagram":"endless_denim"}
],
"urls": [
{"merchantName":"endlessdenim","url":".../go/356008","status":"SoldOut","price":"200"}
]
}
// + Louis Vuitton 벨트, Orange Cowhide Shorts, ...
]
}
}
```

의미

1. 데이터 품질 최상: `id`, `brand`, `category`, `price`, `currency`, `salePrice`, `status`, `releasedAt`, `merchantName`, `merchant URL` — vision 파이프라인이 추론으로 얻으려는 필드를 전부 라벨링
2. `__typename` / `apollo` 키 존재 → 백엔드가 Apollo GraphQL. GraphQL endpoint 발견 시 IIFE 추출도 우회 가능 (별도 R&D 이슈로 분리 가치 있음, 페이지네이션 + 필드 셀렉션이 명시적)
3. 추출기 ~30줄: `httpx` 로 HTML fetch → `window.NUXT=(` 시작점에서 paren-balanced extract → `node -e` subprocess 또는 `py_mini_racer` 로 평가

URL 패턴 (sitemap + 홈 크롤로 확인)

• `/outfit/{artist-slug}-{outfit_id}` — 단일 outfit
• `/artist/{slug}` — 아티스트별 페이지 (페이지네이션 포함)
• `/articles`, `/videos`, `/catalog`, `/brands`, `/sale` — 디스커버리

(주의: 공식 sitemap.xml 은 2020 lastmod 로 stale, discovery 는 `/artist/*` + 홈 피드 크롤로)

구현 스케치

```python
async def _fetch_outfit(self, slug_id: str) -> RawMedia:
html = await self._http.get(f"{ORIGIN}/outfit/{slug_id}").text
payload = extract_nuxt(html) # IIFE → dict
outfit = payload["data"][0]["outfit"]
return RawMedia(
external_id=outfit["id"],
external_url=f"{ORIGIN}/outfit/{outfit['slug']}",
image_url=f"{CDN}{outfit['images'][0]['data']}",
author_name=outfit["artist"]["name"],
caption=f"{outfit['artist']['name']} · {len(outfit['items'])} items",
platform_metadata={
"artist": outfit["artist"],
"items": outfit["items"], # brand/category/price/urls 보존
"likes": outfit["likes"]["count"],
"gender": outfit["gender"],
},
)
```

Scope 업데이트

• PoC: Nuxt IIFE 추출 가능성 확인
• `extract_nuxt()` helper — paren-balanced extractor + JS evaluator (node subprocess vs py_mini_racer 결정)
• (follow-up issue) Apollo GraphQL endpoint 발견 시 native API 우선 사용 검토
• 위 OP의 나머지 작업 항목 그대로 진행

starstyle (#466) 보다 데이터가 더 풍부 (price/currency/category/releasedAt/merchant 까지) — Phase 1 시작점으로 강력 후보.

[cocoyoon]

📊 데이터 규모 추정

GraphQL totalCount 필드가 Nuxt payload에 그대로 노출되어 있어 하드 숫자로 측정 가능.

총량

엔티티	총량	출처
Outfits (RawPost 단위)	22,138	홈 피드 outfits.totalCount
Artists (셀럽)	~1,400	/artists: popular 734 + recently-updated 1,443 (중복 포함)
Items (카탈로그 전체)	~200k+	/catalog 34개 카테고리 합산
Brands	수천 단위	/brands (totalCount 미노출, 추정)

카테고리별 item 분포 (top 10)

카테고리	totalCount
(전체/필터1)	207,021
65,131
40,622
29,267
27,938
23,978
17,117
15,714
8,628
8,475

(나머지 24개 카테고리는 1k–8k 분포)

관측 단서

• 우리가 본 outfit ID = 43564 인데 totalCount=22,138 ⇒ 삭제/비공개 outfit이 절반 정도 존재. 시퀀셜 ID 스캔보다는 pageInfo.cursor 기반 페이지네이션 권장
• Item ID = 257865 까지 관측 → 200k+ 추정과 일관
• 모든 GraphQL connection 이 hasNextPage/endCursor cursor pagination ⇒ 풀스캔 + resume 자연스러움

수집 비용 추산

• Outfit 22k개 풀 스크랩:
  • 페이지당 ~334KB, ~50ms IIFE eval, 1 req/sec rate limit (보수적)
  • 단일 워커: ~6시간 15분
  • 동시 4 워커: ~1.5시간
• Discovery 는 outfit 페이지 자체가 아닌 artist/home cursor 페이지네이션으로 ID 목록 먼저 수집 → outfit 본문 fetch 가 더 효율적
• 하루 안에 풀 백필 가능

인사이트

• 22k outfits × 평균 5–7 items = brand+price+merchant 라벨이 약 100k–150k row — 즉시 학습/검증 데이터로 풀어쓰기 충분한 규모
• Pinterest 와 달리 데이터셋 상한이 명확 — 일일 증가율은 recently-updated 페이지로 모니터 가능
• 페이지네이션이 cursor 기반 ⇒ incremental sync 도 깔끔하게 설계 가능 (마지막 처리 cursor 저장 → 다음 폴링에서 resume)

Scope 영향

• 초기 스크랩 잡(별도 이슈)은 단발 풀 백필 으로 설계 (continuous polling 대신)
• mode='initial' 시 limit 을 22k 까지 받을 수 있게 env 기본값 검토 필요