// habix.ai · pmf signal radar

고객문의에서 제품 개선 신호를 찾아냅니다.

PMF Signal Radar — 4채널 CS 자동 분류 · hplan 개선 후보 연결.

Kakao 상담톡 Channel Talk hplan Loop Human Review hplan Gate
hplan 흐름 보기 → 제품 소개서 → 3 use case 영상 →
⏱ 15초 요약

카카오톡·채널톡으로 매일 들어오는 고객 문의를 자동으로 정리해서, "어떤 불만이 반복되는지"와 "무엇을 다음에 만들면 되는지" 를 한 화면에 보여주는 도구예요. 답변 초안 작성부터 제품 개선 백로그까지 한 흐름으로 이어집니다. AI PM 강의 실습 데모로도 동작합니다.

📖 알아두면 좋은 용어
PMF (Product-Market Fit)
제품이 시장에 진짜 필요한지 — 즉 "이걸 만들었더니 정말 사람들이 쓰는가" 여부예요. 고객 문의에서 PMF 신호를 잡아낸다는 게 이 도구의 핵심.
PII 마스킹 (Personal Information Masking)
이름·전화번호·주소 같은 개인정보를 분석 전에 자동으로 가려주는 작업이에요. 원본 메시지는 안전하게 보관됩니다.
Push / Anxiety / Workaround / Trigger
hplan 에서 가져온 4 가지 PMF 신호 분류. "고객이 무엇에 밀려서 / 무엇을 걱정해서 / 어떻게 임시방편으로 / 어떤 계기에" 우리 제품을 찾는지 자동으로 태깅합니다.
답변 분기 (Route)
들어온 문의를 FAQ 자동 응답으로 보낼지, 사람 검토로 보낼지 자동으로 나눠줘요. 운영자가 모든 메시지를 다 볼 필요가 없어집니다.
백로그 (Backlog)
"다음에 만들 것 / 인터뷰할 것 / 일단 보류할 것" 의 목록. radar 가 모은 신호가 그대로 hplan 의 Build / Interview / Hold 백로그로 연결됩니다.
01 INPUT4채널 문의 수집카카오 · 채널톡 · CSV · 수동
02 MASKPII 마스킹이름 · 전화 · 이메일 자동 가림
03 ROUTE답변 분기초안 또는 사람 검토
04 PLAN개선 후보 연결Radar → hplan Backlog

// hplan workflow

hplan이 문의를 evidence로 번역하고, 화면이 즉시 다시 그려지는 흐름.

문의가 들어오면 adapter가 한 형태로 정규화하고, 개인정보를 마스킹한 뒤 분석 엔진이 hplan evidence schema로 구조화합니다. 결과는 Radar, 답변 초안, 운영자 검토, hplan Backlog, Export에 같은 상태로 반영됩니다.

hplan 문의 분석 흐름

checking 분석 엔진 대기
01 input문의 모으기카카오, 채널톡, CSV/JSON, 수동 붙여넣기를 한곳에 모읍니다.
02 normalize같은 형식으로 정리출처, 고객군, 문의 내용, 중복 기준을 맞춥니다.
03 mask개인정보 가리기이메일, 전화번호, 주문번호를 분석 전에 마스킹합니다.
04 classifyhplan 신호 분류Push, Anxiety, Workaround, Trigger와 다음 판단을 구조화합니다.
05 reply / HITL답변 경로 분기FAQ는 답변 초안으로, 개인정보·환불은 사람 검토로 보냅니다.
06 backlog개선 후보 적재반복 불편을 Radar와 hplan Backlog에 쌓아 다음 개선으로 연결합니다.
실행 기록
현재 분석
방식로컬 기준 분석
문의0
시간-
판단evidence
01 문의 입력
Kakao설치 없이 먼저 체험 가능한가요?
Channel Talk개인정보 익명화 기준이 필요합니다.
Open Chat좋은 결과와 나쁜 결과 기준이 궁금해요.
CSV / JSON반복 문의를 우선순위로 보고 싶어요.
02 hplan 신호 분석
03 처리 경로
FAQ 답변 초안가벼운 반복 문의는 운영자가 확인할 답변 후보로 만듭니다.
운영자 검토 대기환불, 개인정보, 법무 이슈는 사람 검토로 분기합니다.
PMF Radar반복성, 위험도, 증거 강도를 좌표로 정리합니다.
제품 개선 백로그Build / Interview / Hold로 다음 개선 후보를 만듭니다.
06 backlog → 01 input Backlog에서 강의자료, FAQ, 데모, 개인정보 정책이 개선되고, 다음 문의가 다시 hplan evidence로 쌓입니다. ↺

Channel Talk live 연동

현재 로컬 receiver stub은 POST /api/webhooks/channel-talk까지 준비되어 있습니다. 실제 연동에는 Channel Talk 관리자 화면의 Webhook 설정, 공개 HTTPS URL, token 검증값이 필요합니다.

Kakao 상담톡 live 연동

현재 Kakao fixture와 POST /api/webhooks/kakao receiver stub이 있습니다. 실제 상담톡 메시지 수신은 비즈메시지/상담톡 파트너 접근권한과 공식 payload 확인 후 연결합니다.

// classroom demo

한국 상담 채널에서 바로 이해되는 PMF Radar.

카카오톡/채널톡에서 자주 보는 문의 흐름을 유지하되, 결과 화면은 테이블이 아니라 반복성·위험도·증거 강도를 한 번에 보는 지도 형태로 보여줍니다.

Evidence Map

filter: all x 반복성 · y 위험도
낮은 반복 높은 반복 높은 위험 낮은 위험
Build now Interview Guardrail Hold

Human Review Queue

0 pending

hplan Backlog

0 items

Markdown Export

What Not To Build

hplan guardrail
오픈채팅 메시지 직접 붙여넣기 → Push / Anxiety / Workaround / Trigger 분류 받기 (운영자 전용 · 수동 입력만) manual only · auto-collect blocked

오픈채팅 수동 입력 — 자동 수집 차단

manual only · auto-collect blocked
오픈채팅 메시지 붙여넣기
텍스트를 입력하면 클라이언트 측 PII 1차 가림 결과가 여기에 표시됩니다.
세그먼트
label_hint (분류 힌트)
수동입력 0건 (오늘 누적 0건)
정책 안내 수동 입력만 허용 — 자동 수집은 약관·법률 이슈로 차단됩니다.
클라이언트에서 이메일·전화번호를 1차 가림 후 서버에서 최종 마스킹합니다.
운영자가 직접 붙여넣기한 메시지만 분석됩니다.
결과: 붙여넣기 후 버튼을 클릭하면 PMF Radar에 결과가 표시됩니다.

// daily_messages → radar_routes

고객이 카카오톡에 보내는 말 ↔ radar 가 자동으로 하는 일

운영자 1인이 가장 자주 받는 4 종류의 메시지가 들어왔을 때, radar 가 어떤 경로로 보내고 무엇을 백로그에 적어두는지 — 한 줄로 본 시나리오예요.

"환불 가능한가요? 어제 결제했는데 마음이 바뀌었어요."
FAQ 자동 응답 후보 7 일 이내 환불 규정을 담은 답변 초안을 만들고, 환불 키워드라 사람 검토 큐로 동시 푸시. 운영자가 확인 후 1 클릭 발송.
"결제가 안 돼요. 카드 정보는 010-XXXX-XXXX 인데..."
사람 검토 강제 PII 자동 마스킹(전화·카드) 후 Push 신호 태깅. 같은 결제 실패가 3 건 누적되면 hplan Backlog 에 "결제 페이지 디버그" 카드로 자동 승급.
"엑셀로 한꺼번에 올릴 수 있나요? 지금은 100 번 복붙 중이에요."
Workaround 신호 감지 "복붙으로 우회 중" 발화 = Workaround 신호. radar 가 Evidence Map 우상단(반복성·위험도 모두 높음)에 점을 찍고 Build now 후보로 표시.
"개인정보 처리방침 어디서 보나요? 회사에 제출해야 해서요."
FAQ 자동 응답 정책 페이지 링크 + B2B 도입 안내 답변 초안. 동시에 "B2B 도입 검토 = Trigger 신호" 로 태깅되어 영업 백로그로 분기.

운영자는 메시지를 직접 분류하지 않습니다. radar 가 4 채널 인입 즉시 FAQ 답변 / 사람 검토 / 백로그 적재 중 한 경로로 자동 라우팅해요.

// pmf_signal_taxonomy

radar 가 찾는 PMF 신호 4 가지

"고객이 무엇에 밀려서 / 무엇을 걱정해서 / 어떻게 우회해서 / 어떤 계기에" 우리를 찾는지 — 4 가지 신호로 분류합니다. 실제 카카오톡 발화 예시로 어떤 모양인지 보세요.

SIGNAL 1
Push — 밀려서 우리에게 옴
기존 도구·프로세스의 고통이 너무 커서 새 도구를 찾는 상태
"엑셀로 100 번 복붙 중인데 이거 자동화 안 되나요?"
SIGNAL 2
Anxiety — 걱정해서 못 들어옴
관심은 있지만 보안·환불·품질 불안으로 결제·실행을 미루는 상태
"개인정보 익명화 기준 먼저 보고 결제하고 싶어요."
SIGNAL 3
Workaround — 임시방편으로 버팀
기능이 부족해서 다른 도구·수동 작업으로 우회 중인 상태. Build now 1 순위 신호.
"리포트는 따로 노션에 옮겨서 만들고 있어요."
SIGNAL 4
Trigger — 계기가 와서 들어옴
팀 도입·연말 정산·계약 갱신 같은 외부 이벤트로 도입 결정을 압축한 상태
"다음 주 팀 교육 전에 데모 가능한가요?"

이 4 신호는 그대로 hplan 의 Evidence Gate 입력값이 됩니다. "환불 가능?" 같은 단순 FAQ 가 아닌, 제품 방향을 바꿀 신호만 백로그로 승급해요.

근데 말이죠

radar 를 안 써도 되는 때도 있어요

  • 고객 문의가 주 5 건 이하인 단계 — 그 정도면 메시지를 직접 읽고 직감으로 패턴을 잡는 게 더 빠르고 정확해요.
  • 이미 CS 팀이 운영 중인 회사 — 사내 ticketing 도구(Zendesk·Intercom·채널톡 자체 분석)가 같은 역할을 하고 있다면 중복이에요.
  • "문의 분석" 자체가 인사이트의 핵심인 경우 — UX 리서치처럼 한 건 한 건을 깊이 보는 게 목적이라면 자동 정리가 손실이에요.
  • 강의 데모로만 보고 싶을 때 — 운영 중인 비즈니스가 없다면 LLM 분류 기능(/api/classify)은 로컬 server.py 만 띄워 보세요.