# 상호/상표/도메인 중복 체크 SaaS MVP 구조 설계

이 문서는 베타 MVP를 하나의 흐름으로 보기 위한 단일 설계 파일입니다.  
핵심은 “데이터 업로드 도구”가 아니라, 사용자가 이름 후보를 넣으면 상표/도메인/네이밍 관점에서 바로 판단 신호를 받는 SaaS입니다.

## 1. 서비스 목적

사용자가 만들고 싶은 브랜드명, 상호명, 서비스명, 도메인 후보를 입력하면 다음을 한 화면에서 확인합니다.

- 기존 상표와의 동일/유사 가능성
- 동일 또는 인접 업종/Nice class 충돌 가능성
- 도메인 사용 가능성
- 위험도가 낮은 대체 네이밍 후보
- 최종 후보별 검토 리포트

법적 판단을 확정하는 서비스가 아니라, 베타 MVP에서는 “검토 우선순위와 위험 신호를 빠르게 보여주는 도구”로 정의합니다.

## 2. MVP 핵심 사용자 흐름

```mermaid
flowchart LR
  A["사용자: 이름 후보 입력"] --> B["상표 DB 검색"]
  B --> C["동일/유사 상표 매칭"]
  C --> D["업종/Nice class 비교"]
  D --> E["도메인 중복 체크"]
  E --> F["위험도 산출"]
  F --> G["네이밍 대안 생성"]
  G --> H["후보별 결과 리포트"]
```

사용자가 처음 만나는 화면은 데이터 업로드가 아니라 `Name Check Workspace`여야 합니다.

## 3. 화면 구성

### 3.1 Name Check Workspace

서비스의 첫 화면입니다.

주요 요소:

- 이름 후보 입력창
- 업종/비즈니스 카테고리 선택
- 원하는 도메인 확장자 선택
- 검색 실행 버튼
- 최근 검색 기록

사용자 목적:

- “이 이름 써도 될까?”를 바로 확인

표시 예:

```text
입력명: 모두페이
업종: 핀테크 / 결제 / SaaS
도메인: .com, .co.kr, .kr
```

### 3.2 Risk Results

검색 후 가장 먼저 보여주는 결과 화면입니다.

주요 요소:

- 종합 위험도: 높음 / 중간 / 낮음
- 동일 상표 발견 여부
- 유사 상표 목록
- 관련 Nice class
- 출원인/등록권자
- 등록/출원/소멸 등 법적 상태
- 결과 근거

중요:

데이터 업로드 상태보다 “결과 판단”이 화면 중심이어야 합니다.

### 3.3 Trademark Match Table

상표 매칭 결과를 상세히 보는 표입니다.

컬럼:

- 위험도
- 상표명
- 출원번호
- 등록번호
- 상태
- Nice class
- 지정상품/서비스
- 출원인
- 만료일

MVP에서는 현재 SQLite의 `trademark_search` view를 우선 사용합니다.

### 3.4 Domain Check Panel

도메인 중복 체크 영역입니다.

MVP 단계:

- 사용자가 입력한 후보명에서 공백/특수문자 제거
- `.com`, `.co.kr`, `.kr`, `.io`, `.ai` 등 조합 생성
- 실제 도메인 API 연동 전에는 mock 또는 수동 확인 상태로 표시

표시 예:

```text
modupay.com      확인 필요
modupay.co.kr    확인 필요
modupay.kr       확인 필요
```

### 3.5 Naming Suggestions

위험도가 높은 후보를 대체할 네이밍 제안 화면입니다.

입력:

- 원래 이름
- 업종
- 원하는 톤앤매너
- 피해야 할 단어

출력:

- 대체 이름 후보
- 발음 난이도
- 도메인 후보
- 상표 유사 위험도
- 짧은 설명

### 3.6 Data & API Settings

관리자/개발자용 화면입니다.  
이 화면은 첫 화면이 아니라 설정 화면이어야 합니다.

포함 요소:

- KIPRIS API key 입력
- `.env` 저장 상태
- TXT/DATA import 실행 상태
- 마지막 DB 갱신일
- 현재 DB 건수
- 수동 재수집 버튼

현재 구현된 테스트 UI의 API key 입력란은 이 화면의 초기 버전입니다.

## 4. 데이터 구조

현재 로컬 SQLite는 다음 구조입니다.

```mermaid
erDiagram
  trademarks ||--o{ trademark_goods : has
  trademarks ||--o{ trademark_applicants : has

  trademarks {
    string application_number
    string registration_number
    string name_ko
    string name_en
    string normalized_name_ko
    string normalized_name_en
    string legal_status
    string expiration_date
  }

  trademark_goods {
    string application_number
    string nice_class
    string goods_name_ko
    string goods_name_en
    string similar_group
  }

  trademark_applicants {
    string application_number
    string applicant_name
    string applicant_name_en
  }
```

검색 UI는 직접 테이블을 모두 조인하지 않고 `trademark_search` view를 우선 조회합니다.

## 5. 데이터 수집 워크플로우

### 5.1 현재 단계: TXT/DATA import

```text
C:\Users\ekidi\Downloads\datatrademarks\TXT\DATA
```

사용 파일:

- `TB_KT10.txt`: 상표 기본정보
- `TB_KT15.txt`: 지정상품/서비스
- `APPLICANT.txt`: 출원인

실행:

```powershell
& "C:\Users\ekidi\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe" scripts\import_kipris_trademarks.py
```

결과:

```text
data\kipris_trademarks.sqlite3
```

### 5.2 다음 단계: API 보강

API는 전체 DB 구축용이라기보다 최신분 보강과 수동 재수집에 사용합니다.

예상 흐름:

```mermaid
flowchart TD
  A[".env: KIPRIS_API_KEY"] --> B["fetch-trademarks script"]
  B --> C["keyword/date/class API call"]
  C --> D["normalize response"]
  D --> E["upsert SQLite"]
  E --> F["search UI reads SQLite only"]
```

원칙:

- API key는 `.env`에만 저장
- 프론트엔드 코드에는 API key를 넣지 않음
- 앱 검색은 API를 직접 호출하지 않고 SQLite만 조회
- API 호출은 수동 재수집 또는 배치 작업으로 제한

## 6. 현재 구현된 파일

```text
scripts/import_kipris_trademarks.py
scripts/serve_trademark_ui.py
data/kipris_trademarks.sqlite3
.env.example
.gitignore
```

### import 스크립트

역할:

- KIPRIS TXT/DATA 파일 읽기
- SQLite DB 생성
- 검색용 view 생성

### 테스트 UI 서버

역할:

- 로컬 검색 UI 제공
- SQLite 검색 API 제공
- KIPRIS API key 입력 후 `.env` 저장

실행:

```powershell
cd "C:\Users\ekidi\Documents\Codex\2026-05-27\1-saas-2-beta-mvp-api"
& "C:\Users\ekidi\.cache\codex-runtimes\codex-primary-runtime\dependencies\python\python.exe" scripts\serve_trademark_ui.py
```

브라우저:

```text
http://127.0.0.1:8765
```

## 7. UX/UI에서 보완해야 할 점

현재 테스트 UI가 너무 개발자 도구처럼 보이면, 다음 순서로 바꾸는 것이 좋습니다.

### 우선순위 1

- 첫 화면을 API key/data upload가 아니라 이름 검색 화면으로 고정
- API key 입력은 접힌 설정 패널 또는 Settings 화면으로 이동
- 결과 화면에 위험도 요약 카드 추가

### 우선순위 2

- 상표 결과, 도메인 결과, 네이밍 제안을 탭으로 분리
- 검색 결과 상세 패널 추가
- 결과마다 “왜 위험한지” 짧은 근거 표시

### 우선순위 3

- 네이밍 후보 비교표 추가
- 리포트 저장/내보내기
- 최근 검색 기록
- 프로젝트별 후보 관리

## 8. MVP 화면 정보 구조

```text
Name Check
  - 후보명 입력
  - 업종 선택
  - 도메인 확장자 선택
  - 검색 실행

Results
  - 종합 위험도
  - 상표 매칭
  - 도메인 상태
  - 네이밍 대안

Detail
  - 상표 상세
  - 지정상품/서비스
  - 출원인
  - 등록/만료 상태

Settings
  - API key
  - 데이터 import
  - DB 상태
  - 수동 재수집
```

## 9. 다음 구현 순서

1. 테스트 UI의 첫 화면을 `Name Check Workspace` 중심으로 재배치
2. API key 입력 영역은 Settings 패널로 축소
3. 검색 결과 상단에 위험도 요약 카드 추가
4. 도메인 체크 mock 패널 추가
5. 네이밍 제안 mock 패널 추가
6. 이후 실제 API fetch 스크립트 연결

## 10. MVP 포지셔닝 문구

서비스 내 문구는 다음 톤이 안전합니다.

좋은 표현:

```text
유사 상표 발견 가능성
검토 필요도
최근 출원 충돌 가능성
네이밍 리스크 신호
```

피해야 할 표현:

```text
상표 등록 가능
법적으로 사용 가능
침해 없음
100% 안전
```

## 11. 결론

이 SaaS의 중심 UX는 데이터 업로드가 아니라 다음 순서여야 합니다.

```text
이름 입력 -> 중복/위험 분석 -> 도메인 확인 -> 네이밍 대안 -> 후보 리포트
```

데이터 업로드와 API key는 운영/설정 기능으로 뒤에 두고, 사용자가 처음 보는 화면은 “내 이름 후보가 괜찮은지 바로 확인하는 작업 공간”으로 설계합니다.