Build in Public: 9주차. Wykra의 형태

발행: (2026년 1월 31일 오후 11:05 GMT+9)
14 min read
원문: Dev.to

Source: Dev.to

번역을 진행하려면 전체 텍스트를 제공해 주시겠어요? 텍스트를 주시면 원본 형식과 마크다운을 유지하면서 한국어로 번역해 드리겠습니다.

공개적으로 빌드하기 – 회고

Build in public 은 전반적으로 흥미로운 실험입니다. 새로운 독자를 얻게 되고—그 중 일부는 계속 머물기도 하며—다양한 커뮤니티에 초대받게 되고, 저장소에 여덟 개의 별을 자랑하게 되며, 어느 순간 무료 크레딧을 얻고 자신의 돈을 너무 빨리 소모하지 않기 위해 LLM‑관련 프로그램에 끼어들게 됩니다. 솔직히 말해서, 최소 한 번이라도 이런 경험을 해보는 것이 좋다고 생각합니다. 내부에서 실제로 어떤 느낌인지 이해하기 위해서라도 말이죠.

동시에 명백한 단점도 존재합니다. 풀타임 직장을 다니면서 매주 업데이트를 쓰는 것은 겉보기에 비해 유지하기 어려운 수준의 헌신을 요구합니다. 실제 생활은 언제든 방해가 되기 마련이니까요: 아픈 고양이, 업무 긴급 상황, 본인 자체의 병, 혹은 단순히 피곤해서 일관된 내용을 만들기 힘든 경우 등. 시간이 지나면 이것이 두 번째 직업처럼 불편하게 느껴지기 시작하고, 저는 처음 생각했던 것만큼 블로깅에 전념하지 못하고 있다는 사실을 인정하게 되었습니다. 솔직히 말해, build‑in‑public 시리즈를 몇 달 이상 지속하려면 부유한 삼촌이 있거나 대기업의 탄탄한 주식 플랜이 필요합니다.

작업 자체는 멈추지 않았습니다. 일은 계속 진행되고, 시스템은 계속 진화했으며, 어느 순간 우리는 잠시 멈추어 지금까지 실제로 무엇을 구축해 왔는지 제대로 정리할 필요가 있었습니다. 네, 주간 업데이트를 세 번 건너뛰었지만, 현재 프로젝트의 상태를 보면 결과가 꽤 괜찮게 나왔다고 말할 수 있습니다.

What Wykra Does, In One Paragraph

세부 사항에 들어가기 전에 이 프로젝트가 어떻게 시작됐는지 간단히 떠올려 보는 것이 좋습니다. Wykra는 대부분 재미로 만든 작은 사이드 프로젝트였으며, 챌린지의 일환으로 시작됐고, 큰 기대나 장기적인 계획 없이 진행되었습니다. 그러다 어느 순간 지금과 같은 형태로 발전했습니다.

실제로 하는 일: 예를 들어

“vegan cooking creators in Portugal with 10k–50k followers on Instagram/TikTok”

와 같이 입력하면 Instagram과 TikTok을 뒤져 해당 프로필을 스크랩하고, 언어 모델에 분석을 맡겨 점수와 간단한 설명이 포함된 순위 리스트를 반환합니다. 이미 특정 사용자를 염두에 두고 있다면 그 사용자명을 입력해 실제로 연락할 가치가 있는지 판단할 수도 있습니다.

원래 챌린지 포스트 이후 이 내용은 Dev.to에 9편의 연재 글로 확장되었습니다. 본격적으로 들어가기 전에, 그 글들이 실제로 어떻게 퍼포먼스를 보였는지 간단히 살펴보는 것이 좋습니다.

Dev.to 게시물 성과 차트

보시다시피 처음 두 글은 꽤 좋은 반응을 얻었고, 이후 점차 숫자가 감소했습니다. 현재 독자는 주로 자신이 무엇을 기대했는지 명확히 알고, 그럼에도 불구하고 남아 있는 사람들로 구성됩니다.

사용자가 실제로 보는 것

이 시점에서는 더 이상 설명을 이어가기보다는 실제 화면이 어떻게 생겼는지 보여주는 것이 더 의미가 있습니다.

첫 번째로 마주하게 되는 페이지는 wykra.io 의 랜딩 페이지이며, 약 5초 안에 이 서비스가 무엇인지 설명하려고 합니다. 우리는 랜딩 페이지 자체가 있다는 것에, 그리고 이메일용 도메인까지 가지고 있다는 것보다 더 자부심을 느낍니다. 또한, 이 아주 멋진 퍼플 색상 #422e63 을 잠시 감상해 주세요. 솔직히 꽤 훌륭합니다.

Wykra 랜딩 페이지 스크린샷

우리는 Google Nano Banana 가 만들어 준 로고도 가지고 있습니다; 연결된 프로필들을 그래프로 그린 형태이며, 바로 이 서비스가 다루는 내용과 일치합니다.

그 다음에는 GitHub을 통해 회원가입을 할 수 있습니다. 이는 누가 서비스를 이용하고 있는지 파악하고, 누군가가 한 번에 수백만 달러에 해당하는 데이터를 스크래핑하는 것을 방지하기 위해 필요합니다. 로그인하면 전체 대화 기록을 보관하고, 검색에 시간이 걸릴 수 있음을 명확히 알려주는 채팅 인터페이스로 이동합니다—경우에 따라 20분까지 소요될 수 있습니다. 안타깝게도 이 정도의 탐색이 5~6초 안에 끝나는 우주는 없습니다. 웹 검색, 스크래핑, LLM 호출을 연쇄적으로 수행하기 때문에 이렇게 작동합니다.

결국 시스템이 관련성이 있다고 판단한 프로필 목록과 각 프로필에 대한 점수, 그리고 왜 선택되었는지에 대한 간단한 설명을 받게 됩니다.

검색 결과 스크린샷

특정 프로필에 대한 분석을 요청할 수도 있습니다. 이를 통해 해당 인물이 실제로 유능한지 검증할 수 있습니다.

프로필 분석 스크린샷

이렇게 하면 해당 계정이 실제로 어떤 내용인지 빠르게 파악할 수 있습니다: 기본 정보, 대상 청중, 일반적인 콘텐츠 스타일, 그리고 연락을 취할지 결정하는 데 도움이 되는 짧은 “장점‑단점” 목록을 제공합니다.

ic stats, 인간적인 문구로 작성된 짧은 요약과 틈새, 참여도, 전반적인 품질에 대한 몇 가지 신호

누구에 대해서도 최종 판단을 내리려는 것이 아니라, 프로필이 신뢰할 만한지 확인하기 위해 수십 개의 탭을 열고 20분 동안 스크롤하는 수고를 덜어줍니다.

웹 버전이 마음에 들지 않으면 전체 기능을 텔레그램에서 직접 사용할 수도 있습니다. 동일한 인터페이스와 흐름을 그대로 유지하지만, 브라우저 대신 텔레그램 안에서 작동합니다.

Source:

그리고 이제, Nerd Stuff

실제로 어떻게 구성되어 있는지 궁금한 분들을 위해 스택을 간단히 정리했습니다.

백엔드

  • 프레임워크: NestJS + TypeScript
  • 데이터베이스: PostgreSQL
  • 캐시 / 작업 큐: Redis
  • 스크래핑: Bright Data (Instagram 및 TikTok 프로필 가져오기 담당)
  • LLM 호출: LangChain + OpenRouter
    • 기본 모델: Gemini
    • 탐색 모델: GPT (웹 플러그인 사용)
  • 관측성:

프론트엔드

  • 프레임워크: React 18 + TypeScript, Vite로 빌드
  • 상태 관리: 별도 라이브러리 없이 순수 React 훅 사용
  • 텔레그램 통합: Telegram Web App SDK를 사용해 동일 UI가 브라우저와 텔레그램 안에서 별도 앱을 유지하지 않고 동작합니다.

다이어그램을 좋아하는 사람들을 위해

문단보다 그림을 선호한다면, 현재 Wykra가 어떻게 연결되어 있는지 대략적인 다이어그램을 확인해 보세요. 보기 좋거나 최종 형태를 목표로 한 것이 아니라, 각 요소가 어디에 위치하고 데이터가 시스템을 통해 어떻게 흐르는지를 보여주기 위한 것입니다.

위에서 아래로 단일 요청을 추적하면, 사용자가 앱에 메시지를 입력했을 때 어떤 일이 일어나는지 확인할 수 있습니다: API가 요청을 받아들이고, 장시간 실행되는 작업이 큐에 푸시되며, 프로세서가 작업을 수행하고, 외부 서비스가 호출되며, 결과가 저장되고, 오류가 보고됩니다.

LLM 호출 흐름

All LLM calls → OpenRouter API
    ├─ Gemini 2.5 Flash (primary workhorse)
    │   ├─ Profile analysis
    │   ├─ Context extraction
    │   └─ Chat routing

    └─ GPT‑5.2 with web plugin
        └─ Instagram URL discovery

검색 흐름

인스타그램

크리에이터를 검색하는 것은 약간 복잡합니다. Bright Data는 프로필을 스크랩할 수 있지만 인스타그램을 직접 검색하게 해주지는 않기 때문입니다.

  1. GPT에게 (웹 검색을 통해) 관련 프로필 URL을 찾도록 요청합니다.
  2. Bright Data를 사용해 해당 프로필을 스크랩하고 분석합니다.

틱톡

틱톡은 더 간단합니다. Bright Data가 틱톡을 직접 검색하는 것을 지원하기 때문입니다.

  1. 검색 쿼리를 Bright Data에 보냅니다.
  2. 반환된 프로필을 스크랩하고 분석합니다.

어떻게 지내고 있나요?

솔직히? 검색이 아직 완벽하게 작동하지는 않아요. 어떤 결과는 훌륭하고, 어떤 결과는 의문스럽고, 시스템이 약간 странное한 일을 하는 경계 사례도 있습니다. 웹 탐색, 스크래핑, 그리고 LLM 분석을 하나의 파이프라인으로 엮을 때는 이런 일이 예상되는 부분이죠.

우리는 현재 다음 작업을 진행 중입니다:

  • 결과를 더 관련성 있게 만들기.
  • 운영 비용 절감 (크리에이터를 발견하는 것이 돈을 불에 태우는 느낌이 되지 않도록).

이 작업은 다음 주에 예정되어 있습니다.

Code: 모든 것이 여기 있습니다 –

Back to Blog

관련 글

더 보기 »