빅테크 자원 없이 AI 매칭 엔진 구축

I’m ready to translate the article for you, but it looks like the body of the text wasn’t included in your message—only the source link is present. Could you please paste the article’s content (or the specific sections you’d like translated) here? Once I have the text, I’ll provide a Korean translation while preserving the original formatting, markdown, and code blocks.

매칭이 생각보다 어려운 이유

매칭은 겉으로 보기엔 간단해 보이지만, 실제 프로덕션 수준 매칭은 결과‑중심 시스템입니다.

LinkedIn – 데이터가 풍부한 사례

LinkedIn의 매칭이 작동하는 이유는 다음으로부터 학습하기 때문입니다:

다시 말해, LinkedIn은 “관련성을 추측”하지 않습니다. 결과로부터 관련성을 학습합니다.

시드 단계 현실

Pairfect는 다음과 같은 상황에서 시작했습니다:

• 라벨링된 데이터 없음
• 행동 데이터 없음
• 상호작용 없음
• 클릭‑스루 신호 없음
• 임베딩 그래프 없음
• GPU 없음
• PostgreSQL만 사용 가능한 인프라

완전히 다른 세계였습니다. 그러나 많은 초기 팀이 데이터 없이 빅테크 아키텍처를 그대로 복제하려고 하는데, 이는 전혀 통하지 않습니다.

진정한 시작: 모델이 아닌 제약조건

대부분의 팀은 매칭을 시작할 때 다음과 같이 묻습니다:

“어떤 ML 모델을 사용해야 할까요?”

우리는 다른 질문을 던졌습니다:

“어떤 제약조건이 특정 아키텍처를 불가능하게 만드는가?”

아래는 우리의 제약조건 표(아키텍처 자체)의 간소화된 버전입니다.

우리는 코드를 한 줄도 작성하기 전에, 우리가 구현할 수 없는 것들을 알았습니다. 아이러니하게도, 이것이 자체 자금으로 운영되는 스타트업인 Pairfect를 구해냈습니다.

“좋은 매치”가 의미하는 바 정의 (핵심 및 자주 놓치는 부분)

도메인에서 좋은 매치가 무엇인지 정의하기 전까지 매칭을 설계할 수 없습니다.

• LinkedIn: 채용 + 유지
• Pairfect:
  • 캠페인과 인플루언서 간 의미적 적합성
  • 청중 기대와 일치
  • 톤 호환성
  • 가격 호환성
  • 콘텐츠 형식 정렬
  • 세계관 정렬 (네, 크리에이터에게는 중요합니다)

팀이 “여기서 좋은 매치를 구성하는 요소가 무엇인가?” 라는 질문에 답할 수 없다면, 임베딩 vs. 규칙 vs. 트랜스포머에 대한 논의는 시기상조입니다.

Why We Didn’t Go Straight for SOTA Models

We evaluated the standard architectural options. Most didn’t survive the constraint filter:

That left one viable category:

Hybrid Matching

Not because it’s “cool”, but because it’s appropriate for the stage.

The Architecture: Hybrid Matching in Practice

우리의 하이브리드 파이프라인은 다음과 같습니다:

Hard Filters → One‑Hot Features → Embeddings → Fusion → Top‑K

1. Hard Filters

불가능한 경우를 사전에 제거합니다:

• 가격
• 언어
• 콘텐츠 형식
• 지역
• 캠페인 유형

SELECT *
FROM influencers
WHERE price BETWEEN 500 AND 1500
  AND language = 'en'
  AND region = 'eu'
  AND format @> ARRAY['video']::text[];

2. One‑Hot Signals

도메인 지식을 명시적으로 인코딩합니다 (톤, 니치, 수직, 채널, 크리에이티브 스타일). 이는 “의미 없는 매칭”(예: 금융 브랜드를 장난 채널에 매칭) 을 방지합니다.

SELECT influencer_id,
       (CASE WHEN tone = campaign.tone THEN 1 ELSE 0 END)      AS tone_match,
       (CASE WHEN vertical = campaign.vertical THEN 1 ELSE 0 END) AS vertical_match
FROM influencers;

3. Embeddings

다음 항목에 대해 임베딩을 생성했습니다:

• 바이오
• 캡션
• 설명
• LLM 요약

pgvector에 저장하고, 코사인 유사도로 비교합니다.

SELECT influencer_id,
       1 - (bio_embedding <=> campaign.bio_embedding) AS semantic_score
FROM influencers
ORDER BY semantic_score DESC
LIMIT 50;

4. Rank Fusion (RRF)

RRF(Reciprocal Rank Fusion)를 사용하면 여러 랭킹 신호를 학습 없이 하나의 안정적인 순위로 병합할 수 있습니다.

수식

[ \text{Score} = \sum_i \frac{1}{k + \text{rank}_i} ]

SQL/CTE 구현 (단순화 버전)

WITH ranked AS (
  SELECT influencer_id,
         ROW_NUMBER() OVER (ORDER BY semantic_score DESC) AS r1,
         ROW_NUMBER() OVER (ORDER BY tone_match DESC)    AS r2,
         ROW_NUMBER() OVER (ORDER BY vertical_match DESC) AS r3
  FROM candidates
)
SELECT influencer_id,
       (1.0 / (60 + r1)) +
       (1.0 / (60 + r2)) +
       (1.0 / (60 + r3)) AS final_score
FROM ranked
ORDER BY final_score DESC
LIMIT 10;

RRF 기반 융합의 장점

• 유지할 ML 파이프라인이 필요 없음
• 일관되고 결정론적인 동작
• 완전하게 설명 가능한 점수(각 구성 요소가 가시적)
• CPU에서 저비용으로 계산 가능
• 노이즈가 많은 임베딩에 강인함

요약

시드 단계에 있고 오늘 바로 매칭 엔진이 필요하다면, 위의 하이브리드 파이프라인부터 시작하세요. 후보 수가 수백 명에서 수만 명까지 확장 가능하고 비용도 저렴하며, 투자자들이 선호하는 설명 가능성을 제공합니다.

매칭을 즐기세요!

Top‑K 출력

무한 스크롤이 아니라 짧은 목록을 반환합니다.

Top 10 most compatible influencers
+ explanation layer

이는 아니라 개인화; 의사결정 지원입니다.

Why Everything Ran on PostgreSQL

우리 전체 매칭 시스템은 다음과 같이 실행되었습니다:

PostgreSQL + pgvector + CPU

Reasons

• Infra should reduce risk, not increase it → 인프라는 위험을 줄여야 하며, 늘려서는 안 된다
• One system > five micro‑services → 하나의 시스템 > 다섯 개의 마이크로서비스
• Fewer moving parts = fewer failures → 구성 요소가 적을수록 = 장애가 적다
• Debugging in SQL is fast & deterministic → SQL 디버깅은 빠르고 결정론적이다
• Product iteration > infra optimization → 제품 반복 > 인프라 최적화

Hot take: infra is not tooling; infra is liability—especially at the MVP stage. → 핵심 의견: 인프라는 도구가 아니라 부채이다—특히 MVP 단계에서는.

설명 가능성은 선택이 아닌 기능이었다

우리는 매칭 레이어에 완전한 설명 가능성을 구축했습니다:

• 왜 이 추천인가?
• 어떤 신호가 기여했나요?
• 융합이 어떻게 점수를 매겼나요?
• 무엇이 이를 실격 처리하게 할까요?
• 어떻게 오버라이드하나요?

신뢰는 초기 마켓플레이스에서 중요합니다. LinkedIn은 블랙 박스 뒤에 숨을 수 있지만, 스타트업은 그렇지 못합니다.

진화 경로 (핵심 CTO 작업)

창업자들은 종종 묻습니다:

“하이브리드가 영원히 확장될까요?”

아니오. 그리고 그럴 필요도 없습니다.

우리의 계획된 진화 경로:

Hybrid → Behavioral Signals → LTR → Two‑Tower → Graph → RL → Agents

각 단계는 다음을 열어줍니다:

이것이 실제 세계에서 마켓플레이스 인텔리전스가 실제로 성장하는 방식입니다.

최종 교훈

Pairfect를 구축하면서 세 가지 교훈이 도출되었습니다:

1. Lesson 1 – 매칭은 모델 문제가 아니라 비즈니스 제약 문제입니다.
2. Lesson 2 – 적절한 복잡성이 MVP 단계에서 승리합니다. 과도한 엔지니어링은 시장 진입 시간을 늘립니다.
3. Lesson 3 – 빅테크 데이터가 없으면 빅테크 아키텍처가 필요하지 않습니다.

목표는 LinkedIn을 복제하는 것이 아닙니다.
목표는 귀하의 단계에 대해 솔직한 시스템을 구축하고 진화할 준비가 된 시스템을 만드는 것입니다.

비슷한 것을 구축하고 있다면

논의 환영합니다:

• 마켓플레이스 매칭
• 랭킹 아키텍처
• 하이브리드 시스템
• pgvector 설정
• 진화 경로

DM 열려 있습니다.