시스템이 어떻게 작동하나 — 사용자가 알아야 할 "왜"

자연어 검색 → 결과 → "왜 이 회사 안 나왔지" 의문이 들 때 시스템이 어떻게 답을 만드는지 직관 잡는 가이드. 개발자/엔지니어 reference 는 별 문서 (docs/dev/architecture.md).

이 페이지는 다음 사람을 위해:

• 새 헤드헌터 — 시스템 정신모델 빠르게 잡기
• 운영팀 — partner / 헤드헌터에게 한계 설명할 때

§1 검색은 "도서관 사서" 가 아니라 "스터디 그룹" 입니다

일반 검색 = 색인 검색 (Google, ElasticSearch). 색인이 잘못되면 그 회사는 영구히 안 보입니다. 사용자가 고칠 길이 없어요.

SearchRight = 검색 + 헤드헌터가 직접 고치는 루프. 검색 결과를 보다가 "이 회사 빠졌네" 하면 그 자리에서 시스템이 왜 빠졌는지 알려주고, 고치는 방법 안내합니다. 고친 직후 다음 검색에 바로 반영됩니다.

→ 헤드헌터가 검색을 쓰는 만큼 시스템이 좋아지는 자기-강화 루프.

(자세한 철학·설계는 docs/context/north-star.md §0.)

§2 검색은 무엇을 보고 결과를 정렬하나

검색창에 자연어 (예: "광고 매출 메인 BM인 한국 디지털 스타트업") 입력하면 시스템이 3 가지 신호 를 동시에 봅니다:

(1) 구조화 신호 — 회사의 "객관적 속성"

각 회사는 6 가지 측면 (차원) 으로 표기되어 있어요:

검색창의 자연어를 시스템이 자동으로 읽어 "이 의뢰는 광고 모델 + 한국 + 디지털" 같은 식으로 6 측면 매칭을 시도합니다.

(2) 의미 신호 — 회사 설명의 "뜻"

각 회사는 자연어 설명 (프로필) 도 있어요 — "이 회사는 ~을 운영하는 스타트업으로 ~ 사업을 영위한다" 식. 시스템은 의뢰서의 뜻 과 회사 프로필의 뜻 이 얼마나 가까운지 비교합니다. 단순 단어 일치가 아니라 "광고 매출" 이라는 개념 자체를 봅니다.

(3) 단어 신호 — "정확한 단어 일치"

"29cm" 같은 회사 이름이나 "PACS" 같은 niche 기술 용어는 의미 신호 만으로는 잘 안 잡힐 수 있어요 — 너무 짧거나 너무 특수해서. 그래서 시스템은 단어 정확 일치도 따로 봅니다.

3 신호 합산 → 후보 회사 300~500 개 추림 → 다시 정렬 → 결과 100 건.

§3 결과 정렬은 어떻게 만들어지나

후보 300~500 개에서 "이 의뢰에 가장 잘 맞는 100 개" 골라 순서 매기는 과정:

1. 재정렬: 시스템이 의뢰서와 회사 프로필 한 쌍씩 다시 비교해서 "정말 맞는지" 판단. 첫 매칭이 100% 인지 아닌지 한 번 더 깊이 봅니다.
2. 부가 점수: 회사 규모 / 펀딩 / 직원 수 같은 객관 지표가 일정 가산점.
3. 피드백 반영: 누군가가 이전에 같은/비슷한 의뢰에서 "이 회사 누락" 또는 "이 회사 강등" 표시했으면 자동으로 그 신호 반영. 과거 헤드헌터들의 판단 이 다음 검색을 개선합니다.
4. 최종 점수 desc 정렬 → 상위 100건.

→ 헤드헌터가 알아야 할 것: "왜 이 회사가 N 위인가" 는 결정론적. 검색 결과 행의 진단 버튼이 그 결정 과정을 보여줍니다 (플라이휠 가이드 참조).

§4 헤드헌터가 데이터를 고치는 4 단계

1. 검색 → 결과 100건 정렬

2. 의문 → "이 회사 왜 안 나왔지" 행 우측 진단 클릭 (또는 결과 위 박스에 회사명 입력)

3. 진단 라벨 5종 중 하나:

   라벨	의미
   🟢 검색 풀 안 (rank N)	후보에 들어 있는데 점수가 낮음 — 회사 프로필 보강
   🟠 검색 풀 밖	의미 매칭 거리가 멀어 후보 못 들어감 — 프로필 핵심 개념 추가
   🟠 구조화 필터 제외	어떤 필터 (X) 가 잘랐음 — 6 측면 속성 교정
   🔵 enrich 안 됨	회사는 DB 에 있지만 프로필 정보 부족 — enrich-single 로 보강 요청
   ⚪ DB 부재	회사 자체가 DB 에 없음 — enrich-single 로 추가

4. 교정 — "교정 제안 받기" 클릭하면 시스템이 web 으로 회사 재조사해서 필드별 현재 vs 제안 diff 보여줍니다. 헤드헌터가 항목별 수락/기각/수정 → 적용 → 다음 검색에 즉시 반영.

자세한 흐름: flywheel.md.

§5 시스템의 한계 — 알아야 할 것

검색 알고리즘은 기반 이고 전부 가 아닙니다. 알고리즘 만으로 못 푸는 케이스:

테스트셋 11 query × 3 측면 측정 결과:

• 기본 검색 = 약 80% 의 expected 회사 잡음 (상위 200 위 안)
• 정밀 모드 (LLM rerank 옵션 켜기) = 약 82%
• 나머지 ~ 20% = 위 4 케이스 중 하나 → 진단으로 정확히 라벨링되고 교정 경로 있음.

Floor + 헤드헌터 교정 의 합이 SearchRight 의 진짜 성능입니다.

§6 외부 시스템 (partner) 도 같은 검색을 씁니다

소싱 파이프라인 / CRM / AI 에이전트 같은 외부 시스템도 같은 검색 엔진을 API 로 호출할 수 있어요 (/api/v1/search).

차이:

• 인증 (API key 발급 받음)
• 응답 단순화 (내부 점수 breakdown 등 숨김)
• 사용량 추적 (운영팀이 한 눈에)

중요: partner 가 검색 API 만 호출하더라도, "검색 결과 → 진단 → 교정 → 누적" 의 데이터 품질 루프는 SearchRight 운영팀 (헤드헌터) 이 계속 돕니다. partner 는 좋아진 검색 결과만 받습니다.

자세히: API 가이드.

§7 더 깊이 알고 싶다면

• 매일 흐름: flywheel.md — 검색/진단/교정 walkthrough
• 빠른 시작: quickstart.md — 5 분 가이드
• 운영자 관리: admin.md — 사용자 / 외부 API 클라이언트
• 개발자 reference: docs/dev/architecture.md — pipeline 11 module / SQL CTE 박제값 / 6 dim ontology DB 컬럼 / 측정 SSOT / stack (Next.js / pgvector / Cohere / OpenAI 등)