한 줄로
사람 추천에서 가장 비싼 실패는 “잘 맞을 줄 알았는데 대화가 안 통하는” 매칭입니다. Hint는 사진과 스와이프 대신, 대화에서 드러나는 관계 성향(‘결’) 으로 먼저 연결하고 그 다음에 사람을 만나게 하는 플랫폼입니다. 지금은 Phase 1을 만들고 있어 성과 지표보다 설계 판단 위주로 적습니다.
취향 신호를 어떻게 모으나
- 유입용 토이(hint-toy) — 카카오톡 대화 내역을 파싱해 관계 성향 프로파일을 만들어 주는 프로토타입(Python + FastAPI, Next.js UI). 본서비스로 들어오는 유입 경로 역할입니다.
- 결 타입 설문 — 대화 분석과 설문을 합쳐 4개 축의 관계 성향으로 해석하고, 응답이 쌓일수록 해석을 갱신하는 축적식 캐릭터 해석으로 설계했습니다.
측정부터 다시 설계했다
추천 품질은 입력 신호 품질을 넘지 못합니다. 그래서 설문 형식 자체를 두 번 뒤집었습니다.
- A/B 강제선택 → 4점 리커트로 전면 전환 — 강제선택은 A와 B 두 진술을 모두 이해해야 해서 인지 부하가 두 배였습니다.
- 긍정·부정 진술을 섞어 묵종 편향 상쇄 — “그렇다”로만 답하는 경향이 점수를 한쪽으로 미는 것을 막기 위해 진술문의 극을 섞었습니다.
- 설문 스펙을 코드가 아니라 DB에 — 문항·집계 로직·파라미터를 배포 없이 바꿀 수 있어야 실험 속도가 나온다고 보고, 별도 어드민 콘솔까지 분리했습니다.
관계 취향만으로는 부족하다 — 레이어 분리
관계 성향만 맞는다고 좋은 매칭은 아닙니다. 못 먹는 음식, 음주, 가치관처럼 생활에서 부딪히는 지점도 중요합니다. 다만 문항을 늘리면 이탈도 늘어납니다.
- 결 타입 4축은 그대로 두고, 생활 속성(traits) 과 선(boundaries) 을 별도 레이어로 분리해 칩 멀티셀렉트로 가볍게 수집합니다.
- 신념 관련 항목은 입장을 묻지 않고 “나에게 얼마나 중요한가” 한 문항만 받습니다. 개인정보보호법상 민감정보 수집을 피하면서도 매칭에 필요한 신호는 남기는 절충입니다.
매칭을 단계적으로
- Phase 1 — 결 타입 간 매칭: 유저-유저 유사도가 아니라 결 타입(카테고리) 사이의 매칭부터 시작합니다. 임베딩 기반 semantic 매칭은 이후 로드맵으로 분리했습니다.
- 콜드스타트를 가짜로 채우지 않는다: 대화방이 비어 보일 때 AI 봇으로 채우는 안은 검토 끝에 폐기했습니다. 참여자 수는 항상 실제 인원입니다.
- 관심 표현은 두 갈래로: 팔로우 요청을 없애고 ‘답변 작성’과 ‘DM 신청’ 두 경로로 나눴습니다.
- 안전장치는 Phase 1부터: 신고와 키워드 감지를 첫 범위에 넣었습니다.
구조
React Native(Expo) 단일 앱, FastAPI API, 배치 서비스, Supabase를 하나의 모노레포(npm + uv workspaces)로 묶고, 공통 도메인 로직(hint-core)·디자인·계약(contracts)을 패키지로 분리했습니다. 결정 사항은 ADR로 남깁니다.
한계와 다음 단계
- 아직 실사용자 데이터가 없어 매칭 성능 지표가 없습니다. Phase 1 출시 후 대화 지속률·DM 전환율 같은 지표로 결 타입 매칭의 효과를 검증하는 것이 다음 과제입니다.
- semantic 매칭(유저 단위 임베딩)은 결 타입 매칭의 베이스라인이 생긴 뒤에 붙일 계획입니다.