플러스프로젝트 배경
[문제점] 신규 사업자 연락처 수집 프로젝트는 두 갈래에서 어긋난다. 소스 쪽 — 국세청 공개 API는 신규 사업자 목록을 주지 않아(번호 선행 입력 필요) 파이프라인 전제부터 재설계가 필요하다. 검수 쪽 — "실제 연락처 매칭률"이 검수 기준인데 분모 정의가 없으면 분쟁이 되고, 신규 개업 직후는 지도 미등재가 많아 매칭률이 구조적으로 낮게 시작한다. [목표] 소스 역할 재배치(인허가 1차 수집 · 국세청
프로젝트 성과
단일 데이터소스에서 전량 파생
시드 상수 + 파생 함수 하나에서 전 화면·전 지표·전 표·엑셀까지 filter/derive로만 나옵니다. 화면별 독립 목데이터 0건, 가상 사업자 22건.
초기 배치(06:30 자동 실행분) 실측
매칭 로그 33행(카카오 22·네이버 11) · 전화 확보 11/22 = 50.0% · 429 백오프 2,000→4,000 ms · 일 쿼터 카카오 22/30·네이버 11/20.
[재조회 실행]이 퍼널을 실제로 바꿈
퍼널 22→20→14→11 이 22→22→18→15로, 전화 확보율 50.0% → 68.2%. 성공 전환 4건·재예약 3건 — 등재 시차를 재조회가 따라잡는 것을 상호작용으로 증명.
엑셀(.xlsx) 실파일 생성 — 의존성 0
외부 라이브러리 없이 ZIP(무압축)+CRC32+OOXML을 직접 생성합니다. 전체 22건 기준 23행(헤더 포함)×9열 · 15,185바이트 · 표준 파서로 유효성 확인.
자체 검증 147건 통과
데이터 엔진 불변식 45 + 렌더 경로 37 + 디자인 토큰 린트 17 + 헤드리스 실렌더 48. 360·768·1280 세 폭 × 4화면에서 가로 오버플로 0.
핵심 기능
수집 소스·파이프라인
국세청 API를 목록이 아닌 검증 단계에 재배치, 소스 4단 역할 분담·저장 정책 배지·일 쿼터 게이지·일 1회 스케줄 타임라인
진행 단계
기획
2026.07.
공고 요구 26건을 커버리지 매트릭스로 판정하고 4화면으로 수렴, 시그니처를 "매칭률의 분모가 화면에 보인다"로 확정
프로젝트 상세
본 프로젝트는 역량 증명을 위해 자체 기획·개발한 데모입니다. 클라이언트 수주·납품 실적이 아닙니다. 실제 네트워크 요청을 보내지 않는 결정론 시뮬레이션이며, 등장하는 상호·주소·전화번호는 전부 가상입니다(실측 수집 결과가 아닙니다 — 같은 고지를 데모 화면 상단에 상시 노출합니다). 본 데모는 정적 단일 페이지(HTML + 단일 데이터 모듈)로, 실제 구축 스택(수집 서버·스케줄러·DB)과 다릅니다 —
