# PRD — 상호/상표/도메인 중복 체크 SaaS (베타 MVP) > 이 PRD는 Claude Code에서 바로 구현 작업으로 들어가기 위한 문서입니다. > 상위 설계 맥락은 `README.md`를 참조하세요. 본 PRD는 **무엇을, 어떤 순서로, 어떤 합격 기준으로** 구현하는지에 집중합니다. --- ## 0. 가정 (Assumptions) — 확정 시 갱신 아래는 기획 질문에 대한 잠정 기본값입니다. 사용자가 다르게 답하면 해당 항목과 영향받는 요구사항을 갱신합니다. | # | 가정 | 영향 | | --- | ------------------------------------------------------------------------------------- | ----------------- | | A1 | 핵심 사용자 = 1인~초기 창업자 | UX 톤, CTA | | A2 | 포지션 = "참고용 위험 신호"(판정 아님) | 면책/문구(13장) | | A3 | 베타 1차 목표 = 사용 검증 + 판정 신뢰 피드백 | KPI(FR-9) | | A4 | 정확도 편향 = false negative 경계(위험 보수적 과대추정) | 위험도 규칙(FR-3) | | A5 | 데이터 = 기존 로컬 SQLite(전체 적재), 갱신은 수동 | 데이터 모델(7장) | | A6 | 네이밍 = 규칙·접미어 조합(LLM 선택) | FR-7 | | A7 | 도메인 = mock/수동 표시 | FR-6 | | A8 | 로그인 없음, 검색기록은 세션/로컬 | FR-1, FR-8 | | A9 | 스택 = Python + SQLite + 단일 웹 서버(기존 `serve_trademark_ui.py` 계승) | 8장 | | A10 | 베타 사용자 = 내부/소수. 외부 공개 전 면책·약관·KIPRIS 데이터 이용범위 법무 확인 선행 | 13장, 리스크 | --- ## 1. 목적 이름 후보를 입력하면 **상표 충돌 위험 신호 → 도메인 상태 → 대체 네이밍 → 후보 리포트**를 한 흐름에서 보여주는 베타 MVP를 구현한다. 핵심 가치는 화면이 아니라 **설명 가능한 위험도 엔진**이다. ## 2. 문제 / 타깃 - 문제: 창업자가 이름을 정할 때 상표 충돌·도메인 가용성을 확인하기 어렵고, 변리사 검토 전에 빠른 자가 점검 수단이 없다. - 타깃(A1): 1인~초기 창업자. 기술 지식이 적어도 한 화면에서 "이 이름 괜찮아?"를 확인할 수 있어야 한다. ## 3. 베타 목표 & 성공 지표 - 1차 목표(A3): (1) 사람들이 실제로 검색을 완료하는가, (2) 위험도 판정을 신뢰하는가. - 측정(FR-9에서 계측): - 첫 검색 완료율 - 검색 → 결과 도달률, 결과 → 상세/네이밍 진입률 - 위험도 판정 피드백(맞음/아님) 수집 건수 - 네이밍 대안 클릭/복사율 ## 4. 범위 ### In (베타) - Name Check Workspace (FR-1) - 유사 매칭 엔진 v0 (FR-2) - 위험도 산출 엔진 v0 (FR-3) - Risk Results + 사유 표시 (FR-4) - Trademark Match Table & Detail (FR-5) - Domain Check 패널 (mock) (FR-6) - Naming Suggestions (규칙 기반) (FR-7) - Settings (API key/import 상태) (FR-8) - KPI 계측 이벤트 (FR-9) ### Out (이후) - 실시간 도메인 API, 실시간 KIPRIS 동기화 - 로그인/계정, 팀/공유 - 리포트 PDF 내보내기, 프로젝트 관리 - 국제상표, 도형/관념 유사, ML 기반 점수 --- ## 5. 사용자 스토리 - US-1: 창업자로서, 이름 후보와 업종을 입력해 **종합 위험도(높음/중간/낮음)**를 한눈에 보고 싶다. - US-2: 위험도가 왜 그렇게 나왔는지 **사유 한 줄**을 보고 싶다. - US-3: 충돌하는 상표를 **표로 자세히** 보고 싶다(상표명/상태/류/출원인/유사도). - US-4: 입력한 이름의 **도메인 가용 후보**를 함께 보고 싶다. - US-5: 위험이 높으면 **대체 네이밍 후보**를 받고, 그 후보의 위험도도 보고 싶다. - US-6: 운영자로서, **API key/데이터 상태**는 별도 설정 화면에서만 다루고 싶다. --- ## 6. 기능 요구사항 ### FR-1. Name Check Workspace (첫 화면) - 입력: 이름 후보(1개 이상), 업종 카테고리, 도메인 확장자 선택. - 업종 카테고리는 내부적으로 **Nice class / 유사군 후보**로 매핑(매핑 테이블 보유). - "검색 실행" 시 FR-2→FR-3 파이프라인 호출 후 Results로 전환. - 최근 검색 기록(세션/로컬) 표시. - 합격: 첫 진입 화면이 검색 화면이며, API key/import UI가 첫 화면에 노출되지 않는다. ### FR-2. 유사 매칭 엔진 v0 - 정규화: 공백/특수문자 제거, 소문자화, 전각/반각 통일. - 호칭 비교: 한글 자모 분해(NFD 또는 동등 라이브러리) + 영문→한글 발음 간이 매핑 + 편집거리 기반 유사도. - 외관 비교: 정규화 문자열 편집거리. - 점수: `sim = w_visual*외관 + w_phonetic*호칭` (기본 0.4/0.6, 설정값). - 등급: 완전일치→동일 / `>=0.85`→유사(고) / `0.7~0.85`→약유사 / `<0.7`→제외. - 지정상품 유사: `similar_group` 교집합→동일 유사군, 같은 Nice class·다른 유사군→인접, 그 외→무관. - 성능: 후보 1차 필터(prefix/trigram 등) 후 정밀 비교. (전체 건수에 따라 인덱스 — Q15 확정 필요) - 합격: "모두페이" 입력 시 "모두페이먼츠", "모드페이"가 유사 후보로 검출된다(테스트 픽스처로 검증). ### FR-3. 위험도 산출 엔진 v0 - 매칭 1건 등급(생존 상표 기준): | 명칭 ＼ 상품 | 동일 유사군 | 인접 유사군 | 무관 | | ------------ | ----------- | ----------- | ---- | | 동일 | 높음 | 중간 | 낮음 | | 유사(고) | 중간 | 중간 | 낮음 | | 약유사 | 낮음 | 낮음 | 낮음 | - 상태 보정: 소멸/거절/포기/무효/만료는 한 단계 강등 + "참고 이력" 표시. - 종합 = 생존 매칭 중 최댓값(worst-case). 0건이면 "충돌 신호 없음(낮음)" + 안전 미보장 경고. - A4(보수적): 임계값/경계 케이스는 위험을 높게 잡는 쪽으로 기본 설정. - 사유 생성: 위험에 기여한 매칭마다 한 줄 사유 문자열 자동 생성. - 합격: 동일명+동일 유사군+등록 입력 → "높음" + 해당 사유 출력. 모두 소멸 → 강등 적용. ### FR-4. Risk Results - 종합 위험도 카드(높음/중간/낮음) + 한 줄 요약 사유. - 유사 상표 목록(위험도순 상위 N). - 화면 하단 고정 면책 문구(13장). - 위험도 피드백 버튼(맞음/아님) → FR-9 이벤트. - 합격: 카드·사유·면책이 모두 보이고 피드백이 기록된다. ### FR-5. Trademark Match Table & Detail - 컬럼: 위험도, 상표명, 출원/등록번호, 상태, Nice class, 지정상품, 출원인, 만료일, **유사도 점수**, **유사 유형**. - 행 클릭 시 상세 패널(지정상품/유사군, 출원인, 상태). - 데이터는 `trademark_search` view 우선. ### FR-6. Domain Check 패널 (mock) - 후보명 정규화 후 `.com/.co.kr/.kr/.io/.ai` 조합 생성. - 상태는 "확인 필요"(mock). 실제 API 연동 자리(인터페이스)만 비워둔다. ### FR-7. Naming Suggestions (규칙 기반) - 입력: 원래 이름/업종/톤/피할 단어. - 규칙: 접두/접미(랩, 허브, 페이 등) 조합·치환으로 후보 생성. (LLM은 선택 옵션, A6) - 각 후보를 **FR-2/FR-3에 재투입**해 위험도 표시. - 합격: 제안 후보마다 위험도가 함께 표시된다. ### FR-8. Settings - KIPRIS API key 입력 → `.env` 저장(프론트 코드에 키 미포함). - import 실행 상태, 마지막 갱신일, DB 건수, 수동 재수집 버튼. - 첫 화면이 아니라 설정 화면에서만 접근. ### FR-9. KPI 계측 - 이벤트: search_started, search_completed, result_viewed, detail_opened, naming_viewed, naming_copied, risk_feedback. - 베타에서는 로컬/간단 로그로도 가능. 합격: 위 이벤트가 기록·집계된다. --- ## 7. 데이터 모델 (SQLite) `README.md` 5장 기준. 매칭용 컬럼 포함: - `trademarks(application_number, registration_number, name_ko, name_en, normalized_name_ko, normalized_name_en, phonetic_key_ko, legal_status, expiration_date)` - `trademark_goods(application_number, nice_class, similar_group, goods_name_ko, goods_name_en)` - `trademark_applicants(application_number, applicant_name, applicant_name_en)` - view: `trademark_search` - import 시 `normalized_*`, `phonetic_key_ko` 사전 계산. --- ## 8. 기술 스택 & 아키텍처 (A9) - 언어/런타임: Python (기존 환경 계승). - 저장소: 로컬 SQLite (`data/kipris_trademarks.sqlite3`). - 서버: 기존 `serve_trademark_ui.py` 확장 — 정적 UI + 검색/위험도 API 엔드포인트. - 검색은 SQLite만 조회. KIPRIS API는 보강/배치 전용. - 프론트: 단일 페이지 UI(탭 구조). 외부 빌드 의존 최소화. 엔드포인트(제안): ```text POST /api/check -> {name, industry, tlds} 응답 {overall_risk, reasons, matches[], domains[]} POST /api/naming -> {name, industry, tone, avoid[]} 응답 {suggestions[]} GET /api/settings -> DB 상태 POST /api/settings/key -> .env 저장 POST /api/event -> KPI 이벤트 기록 ``` --- ## 9. 디렉터리 구조 (Claude Code 작업 기준) ```text scripts/ import_kipris_trademarks.py # 기존 + normalized/phonetic 계산 serve_trademark_ui.py # 기존 + API 엔드포인트 확장 src/ matching.py # FR-2 유사 매칭 risk.py # FR-3 위험도 산출 naming.py # FR-7 네이밍 제안 domains.py # FR-6 도메인 mock industry_map.py # 업종→Nice/유사군 매핑 web/ index.html # 탭 UI (Name Check / Results / Detail / Settings) tests/ test_matching.py test_risk.py data/ kipris_trademarks.sqlite3 .env.example ``` --- ## 10. 구현 마일스톤 (Claude Code 작업 단위) 각 마일스톤은 독립 PR/작업 단위. 합격 기준 충족 시 다음으로. - **M1 — 엔진 코어**: `matching.py`, `risk.py` 구현 + 단위 테스트. (UI 없이 함수만) - **M2 — 검색 API**: `serve_trademark_ui.py`에 `/api/check` 연결, SQLite 조회 + 엔진 호출. - **M3 — 첫 화면 재배치**: Name Check Workspace를 첫 화면으로, Settings 분리(FR-1, FR-8). - **M4 — Results/Detail UI**: 위험도 카드·사유·매칭 테이블·상세(FR-4, FR-5). - **M5 — 도메인 mock & 네이밍**: FR-6, FR-7 (+ 제안 후보 위험도 재계산). - **M6 — KPI 계측**: FR-9 이벤트. - **M7 — import 보강**: normalized/phonetic 사전 계산(FR-2 성능). --- ## 11. 수용 기준 (핵심) - AC-1 (M1): `test_matching.py`에서 동일/유사/약유사/비유사 분류가 픽스처대로 통과. - AC-2 (M1): `test_risk.py`에서 7장 매트릭스·상태 강등·worst-case·0건 경고가 통과. - AC-3 (M2): `/api/check`가 종합 위험도+사유+매칭 목록을 반환. - AC-4 (M3): 첫 진입 화면이 검색 화면이고, API key UI가 첫 화면에 없다. - AC-5 (M4): Results에 위험도 카드·사유·면책·피드백 버튼이 모두 표시. - AC-6 (M5): 네이밍 제안 후보마다 위험도가 함께 표시. - AC-7 (M6): 7개 KPI 이벤트가 기록·조회 가능. --- ## 12. 미결정 항목 (기획 답변 대기 — 0장과 연동) - Q3 경쟁 대비 차별점 한 줄 → 온보딩 카피에 반영 - Q5 결과 후 CTA(변리사 연결/도메인 구매/저장) → FR-4 버튼 - Q8 데이터 기준일/갱신 주기 → Results "DB 갱신일" 표기 - Q15 전체 상표 건수 → FR-2 인덱스 전략 - Q16 외부 공개 여부 → 배포·법무 선행 여부 --- ## 13. 면책 / 리스크 체크리스트 - [ ] Results 카드 하단·리포트 푸터 면책 문구 고정(README 13장 톤). - [ ] 금지 표현("등록 가능/법적 안전/침해 없음/100% 안전") 미사용 검수. - [ ] 0건 결과에 "안전 미보장" 경고 동반. - [ ] (외부 공개 시) 약관·면책 법무 검토. - [ ] KIPRIS 데이터 서비스 노출/재배포 이용범위 확인(A10). - [ ] API key는 `.env`에만, 프론트 번들 미포함 확인.