software

Build in Public: 6주차. 더 많은 소셜 플랫폼 추가 시도

발행: (2025년 12월 19일 오전 12:05 GMT+9)
11 분 소요
원문: Dev.to

Source: Dev.to

번역을 진행하려면 실제 텍스트(본문 내용)를 제공해 주시겠어요?
본문을 알려주시면 요청하신 대로 한국어로 번역해 드리겠습니다.

소개

지난 주는 가시성에 관한 것이었습니다. 우리는 메트릭과 대시보드를 추가하여 직관에 의존하는 대신 시스템이 실제로 무엇을 하고 있는지 볼 수 있게 했습니다.

그래서 이번 주는 처음부터 무언가를 새로 발명하는 것이 아니었습니다. 이는 매우 실용적인 질문에 답하는 것이었습니다: 같은 아이디어를 다른 소셜 플랫폼에도 확장하면서 시스템 전체가 무너지지 않을 수 있을까?

짧은 답변: 부분적으로.

TikTok: 유사한 문제, 다른 형태

Quick reminder: Wykra는 아주 인간적인 질문에 답하도록 만들어졌습니다: “이와 같은 크리에이터를 찾아줄 수 있나요?” 필요로 하는 인플루언서를 설명하면 저희가 찾아드립니다. 우리는 이미 Instagram에 대해 이 서비스를 제공하고 있습니다. 이번 주에는 같은 패턴을 다른 플랫폼에도 적용해 보려고 했으며, 첫 번째 대상은 TikTok입니다.

높은 수준에서 보면 TikTok 검색은 Instagram과 동일한 스토리 흐름을 따릅니다:

  1. 자유 텍스트 요청을 보냅니다, 예를 들어
    Find up to 15 public TikTok creators from Portugal who post about baking or sourdough bread.
  2. API는 즉시 task ID를 반환하고, 실제 작업은 백그라운드에서 진행됩니다.
  3. 워커가 해당 작업을 받아 문장을 구조화된 검색 파라미터로 변환하고, Bright Data 데이터셋 스크래퍼를 실행한 뒤, 발견된 프로필을 LLM으로 점수 매기고, 쓸모없는 프로필을 필터링하고, 최종적으로 결과를 /tasks/:id에서 가져올 수 있도록 저장합니다.

Step 1 – “vibe in, JSON out”

원본 쿼리를 LLM에 보내고 작은 context object를 추출하도록 요청합니다:

  • 니치 / 주제
  • 위치 (정규화된 국가 코드 포함)
  • 선택적 목표 크리에이터 수
  • TikTok 검색창에 바로 넣을 수 있는 짧은 구문 몇 개

모델이 카테고리조차 합의하지 못하면, 검색할 내용을 알았다 가장하는 대신 여기서 멈춥니다. 컨텍스트가 준비되면 최대 세 개의 검색어를 만들고, 컨텍스트에 있는 국가를 사용하거나 기본값인 US를 선택한 뒤 다음 단계로 진행합니다.

Step 2 – Search diverges from Instagram

Instagram에서는 먼저 Perplexity를 사용해 프로필을 발견하고 그 후에 보강해야 했지만, TikTok은 데이터셋 내에 적절한 키워드 검색이 가능하기 때문에 그 추가 단계를 건너뛸 수 있습니다.

각 검색어에 대해 우리는:

  1. TikTok 검색 URL을 생성합니다.
  2. 해당 URL과 국가 정보를 사용해 Bright Data TikTok 데이터셋을 트리거합니다.
  3. 스냅샷이 준비될 때까지 폴링하고, JSON을 다운로드한 뒤 프로필 URL을 기준으로 모든 프로필을 병합·중복 제거합니다.

전체 과정은 시간이 걸릴 수 있으므로, 이미 다른 곳에서 사용 중인 일반 Task 시스템 안에서 장기 실행 비동기 작업으로 처리됩니다.

Step 3 – LLM scoring

원시 프로필을 확보하면 LLM이 다시 등장합니다. 각 프로필에서 기본 정보(핸들, 프로필 URL, 팔로워 수, 비공개 여부, 바이오)를 추출하고, 이를 원본 쿼리와 함께 모델에 전달해 다음을 요청합니다:

  • 짧은 요약
  • 품질 점수 (1 – 5)
  • 관련성 퍼센트

70 % 이하의 관련성을 보이는 항목은 제외하고, 그 이상은 요약과 점수를 함께 저장하고 작업에 연결합니다. 플랫폼은 다르지만 패턴은 동일합니다: 구조화된 컨텍스트 → Bright Data → LLM 스코어링.

실제 요청 및 응답 예시

(생략 – 원본 내용에는 구체적인 요청/응답 쌍이 포함되어 있었습니다)

작업, 메트릭, 그리고 약간의 규율

All of this runs as a long‑running background job attached to a single task ID. The task goes through a simple lifecycle:

pending → running → completed | failed

우리는 작업 레코드와 해당 작업에 연결된 모든 TikTok 프로필을 저장합니다. /tasks/:id 를 조회하면 원시 작업 상태와 분석된 프로필 목록을 모두 확인할 수 있습니다. 이는 디버깅에 놀라울 정도로 도움이 되었습니다: TikTok 데이터는 비어 있지만 작업이 완료된 경우, 문제는 큐가 아니라 크롤링 또는 분석 단계에 있을 가능성이 높습니다.

우리가 지난 주에 관측성을 추가했기 때문에, 거의 모든 단계가 메트릭으로도 래핑됩니다:

  • 생성, 완료 또는 실패한 TikTok 검색 작업 수
  • 큐 지연 시간 (작업이 큐에 머무는 시간)
  • Bright Data 호출 기간 및 오류율
  • LLM 호출 수와 그 비용

YouTube: 파멸의 반시간 스피너

TikTok이 이번 주의 성공 사례였습니다. YouTube는 설계가 아무리 깔끔해 보여도 모든 것이 Wykra에 바로 연결될 준비가 된 것은 아니라는 점을 상기시켜 주었습니다.

우리는 YouTube 데이터셋을 아주 부드러운 테스트로 연결해 보았습니다:

{
  "url": "https://www.youtube.com/results?search_query=sourdough+bread+new+york+",
  "country": "US",
  "transcription_language": ""
}

이론적으로는 TikTok과 거의 동일하게 동작해야 합니다: 크롤링을 트리거하고, 기다린 뒤 JSON을 다운로드하고, 일상으로 돌아가는 것이죠. 실제로는 약 30분 정도 회전시킨 뒤, 반환된 유일한 결과는 다음과 같습니다:

{
  "error": "Crawler error: Unexpected token '(', \"(function \"... is not valid JSON",
  "error_code": "crawl_error"
}

따라서 현재 YouTube는 아직 Wykra에 제대로 연결되지 않았습니다: 데이터셋이 계속 회전하고, 크롤러 JSON 오류를 발생시키며, 저장하거나 분석할 유용한 정보를 제공하지 못합니다. 우리는 Bright Data에 티켓을 열었으며, 문제가 해결될 때까지 YouTube 연결을 연기했습니다.

Threads: Parameter Present, Logic Absent

Threads도 자체 시도를 했습니다. 계획은 간단했습니다: 기본적인 키워드 기반 탐색을 실행하는 것이죠, 예를 들어:

{ "keyword": "technology" }

프로필 대신에 다음과 같은 응답을 받았습니다:

{
  "error": "Parse error: Cannot read properties of null (reading 'require')",
  "error_code": "parse_error"
}

키워드 파라미터는 존재하고, 데이터셋도 존재하지만, 이 둘을 연결해야 할 중간 로직이 명백히 작동하지 않습니다. 현재 우리는 Threads를 YouTube와 동일하게 취급하고 있으며, 문제를 기록하고 “proper Threads support” 를 나중 단계로 옮겼습니다.

LinkedIn: 같은 옛 이야기

LinkedIn은 Instagram과 유사한 제한이 있습니다: “X에 대해 이야기하는 사람을 Y 국가에서 찾기”와 같은 좋은 키워드 검색이 없습니다. You c

6주 요약

새로운 플랫폼—TikTok, YouTube, Threads, LinkedIn—은 Instagram에서 본 것과 다르게 동작합니다.

  • TikTok: 대부분 기존 패턴을 따릅니다.
  • YouTube & Threads: 패턴이 깨집니다.
  • LinkedIn: 데이터셋에만 의존하지 않고 자체 키워드 기반 검색 레이어(예: Perplexity/LLM 스타일 오버레이)가 필요합니다.

“적절한 키워드 기반 탐색을 원한다면, 데이터셋에만 의존하지 말고 LinkedIn 위에 Perplexity/LLM 스타일 검색 레이어를 추가해야 할 것입니다.”

이는 다음 주에 다룰 문제이지만, 이제는 명확히 정의된 문제입니다—“LinkedIn이 이상하다”는 막연한 느낌이 아닙니다.

Conclusion:
지금은 다섯 개의 반쯤 깨진 흐름보다 두 개의 견고한 흐름을 갖는 것이 더 좋습니다.

프로젝트를 지원하고 싶다면, ⭐️ star the repo와 X에서 저를 팔로우해 주세요—정말 도움이 됩니다.

  • Repo:
  • Twitter/X:
Back to Blog

관련 글

더 보기 »