아키텍쳐

자세한 데이터 사양 및 로딩 구현은 루트 디렉토리의 DATAS.md를 참조하세요.

개요

dure.one은 효율적인 데이터 전달을 위해 우편번호 기반 구성과 Progressive Loading 아키텍쳐를 사용합니다.

데이터 파이프라인

3단계 생성

1단계: 정적 분류 (빌드 타임)

• 사업자 카테고리: KSIC, 홈택스, 산재보험, 고용보험 (6개 체계)
• 상품 카테고리: Google 택소노미
• 우편번호 데이터: 34,363개 우편번호에 대한 UTM-K 좌표

2단계: 사업자 데이터 처리

• Google Sheets → Rust 검증 → JSONL 출력
• 우편번호 및 카테고리별로 구성
• 레코드에 샤드 메타데이터 포함

3단계: 집계

• 모든 출력을 public/data/로 복사
• 정적 배포 준비 완료

프론트엔드 아키텍쳐

Progressive Loading

설계 원칙:

• 우편번호 중심: 5자리 한국 우편번호로 구성
• 거리 기반: 가장 가까운 우편번호부터 로드
• 온디맨드: 필요할 때만 JSONL 페치
• 캐시: 로드된 데이터를 메모리에 보관

주요 컴포넌트

dataLoader.js - 메인 오케스트레이션

• 시작 시 인덱스 로드
• Progressive Loading 조정

postcodeLoader.js - 우편번호 기반 로딩

• /data/postcodes/{postcode}.jsonl 페치
• 로드된 우편번호 캐시
• bizno로 중복 제거

categoryLoader.js - 카테고리 필터링

• category_index를 사용한 관련성 파악
• postcodeLoader에 위임

postcodeDistance.js - 거리 계산

• 우편번호 간 Haversine 거리
• 캐시된 거리 매트릭스

내장 샤드 최적화

각 사업자 레코드에는 상세 보기 직접 로딩을 위한 _shard 메타데이터가 포함됩니다:

{
  "bizno": "1234567890",
  "name": "Example Business",
  "_shard": {
    "category": "HT11000",
    "shard_id": 18
  }
}

장점:

• 2.9MB search_index.json 제거
• 859KB coordinate_index.json 제거
• 레코드에서 O(1) 샤드 조회
• 더 빠른 상세 보기 렌더링

데이터 흐름

사용자가 우편번호 선택
  ↓
postcodeLoader가 /data/postcodes/{postcode}.jsonl 페치
  ↓
_shard 메타데이터와 함께 사업자 목록 렌더링
  ↓
사용자가 사업자 클릭
  ↓
직접 샤드 페치: /data/shards/biz/{category}/shard_{id}.jsonl
  ↓
상세 보기 렌더링

파일 구성

public/data/
├── KR_KSIC11TH.json          # 분류 메타데이터
├── KR_HTCODE26.json
├── KR_SJCODE.json
├── KR_GYCODE.json
├── KR_prdcat.json
├── postcode_index.json        # 드롭다운 데이터
├── index/
│   ├── postcode_index.json    # 우편번호 메타데이터
│   └── category_index.json    # 카테고리 분포
├── postcodes/
│   └── {postcode}.jsonl       # 우편번호별 사업자 레코드
└── shards/
    ├── biz/{category}/shard_*.jsonl
    └── prd/{category}/shard_*.jsonl

성능

번들 크기:

• JS: ~8KB (~3.4KB gzipped)
• CSS: ~10KB (~2.7KB gzipped)
• 합계: ~6KB gzipped

로딩 전략:

• 인덱스: 시작 시 ~8MB 로드
• 사업자 데이터: 우편번호별 온디맨드 로드
• 상세 데이터: 사업자별 클릭 시 로드

캐싱:

• 우편번호 데이터 메모리 캐시
• 거리 계산 캐시
• 중복 페치 없음