elecq 사업계획 — 실행기획

v2.0 · 2026-08-05 · 근거: 백서 v2.0(안전지수·매칭 전략) + 개정 총괄 메모(revision-memo-v2.md) 원칙 두 가지: 1. 날짜 낙관 금지 — 게이트 기반. 각 Phase는 기간 약속이 아니라 "무엇이 증명되면 다음으로 가는가"(Gate)로 정의한다. 방향서의 14개월 WBS·마일스톤(MAU 10만 등)은 승계하지 않는다. 2. 스택 이원화 — 충돌 금지. 현행 스택(PHP, elecq.ai 라이브)이 Phase 1~2의 실행 스택이다. 통합 기획서의 Next.js/FastAPI/Airflow/AWS 스택은 "스케일업 목표 아키텍처"로 자리매김하며, 전환은 게이트 통과 후의 명시적 결정이다(부록).

0. 현재 상태와 선행 결정 (2026-08-05 기준)

완료된 것: https://elecq.ai 라이브(SSL·리다이렉트), Wiki-Driven Site 파이프라인, 보조금 트래커 시연(2모드)·충전비 계산기·차량 DB 골격, 디자인 시스템 v3.x, 백서 v2.0·사업기획 v2.0.

Joseph 승인 게이트 (결정 대기):

#	결정	상태
1	백서 v2.0 전략 전환 승인 — 판정+확보 중심, 기각·정정 목록(메모 2절) 포함	대기
2	스냅숏 수집 즉시 가동 승인 — 약관 검토·공공데이터 제공신청과 병행해 일별 잔여 적재 개시	대기
3	공공데이터 제공신청 명의(법인) 확인	대기 (v1.0 승계)
4	(후속) 안전지수 공개 승인 — 백테스트 결과 보고 동반	Phase 1 말
5	(후속) Phase 3 매칭 파일럿 착수 승인 — 법률 의견서 동반	Gate G2 후

1. Phase 지도 (요약)

Phase 1  안전지수 v0            게이트 G1: 판정이 성립하고, 수요가 있는가
   │                                (백테스트 오보율 + 지수 조회·알림 전환)
   ▼
Phase 2  예측 고도화·계약 추적    게이트 G2: 플라이휠 1회전 — 제보가 정확도를 올리는가
   │                                (T_lead 제보 발생 + 밴드 축소 실증 + 법률 관문)
   ▼
Phase 3  즉시출고 매칭 파일럿     게이트 G3: 트랜잭션이 성립하는가
   │                                (전환율 + 실측 리드 단가 + 딜러 재계약 의사)
   ▼
Phase 4  수익화 확장·금융·TCO    (B2B 데이터·B2G 화이트라벨·금소법 통과 시 금융)

2. Phase 1 — 제품 재정의: 트래커 → 안전지수 v0

현행 자산에서 출발한다. elecq.ai에는 보조금 트래커가 라이브 시연 중이다. Phase 1은 신규 구축이 아니라 트래커에 T_lead 축과 판정 로직을 얹는 증축이다.

작업 목록:

스냅숏 수집 — 정식 개방 경로로 전환 (최우선). ⚠️ 2026-08-05 적법성 판정으로 수단이 변경됐다(INC-20260805): ev.or.kr 지급현황 페이지에 기술적 보호조치(pnp4web 난독화)가 존재해 자동 수집은 빈도와 무관하게 금지 권고다("일 1회+출처표기+저부하"도 허용 근거가 되지 못한다 — 근거: research/briefs/brief-collect-legal.md).

1-a. 정공법 2건 발송(초안 완료 — ops/requests/): 공공데이터법 제27조 제공신청(10일+10일) + KECO 친환경모빌리티처 이용허락 공문. 둘 중 하나만 확보되면 일별 파이프라인이 전면 적법해진다. 거부 시 60일 내 분쟁조정(제17조 제외 사유 없음 — 승산 있음).
1-b. 회신 전까지 ev.or.kr 자동 수집 코드는 작성·실행하지 않는다(동결). 대신 개방 데이터셋(15118967 등 "이용허락범위 제한 없음")·지자체 공고문으로 스키마·적재 파이프라인·검증 로직을 선행 구축한다 — 데이터 소스만 교체 가능한 구조로 설계.
원칙: 허락을 받은 뒤에야 "일 1회+출처표기+저부하"가 지켜야 할 운영 매너가 된다. 순서를 바꾸지 않는다.

지자체 선정 방식 DB v0: 101곳 공고문에서 선정 방식(출고·등록순/추첨/접수순)·자격 조건을 수기 분류(Human-in-the-Loop). 상위 등록 지역부터.
T_lead 밴드 테이블 v0: 겟차·이어카·다나와 공개 집계를 교차해 주요 차종 밴드(예: "3~5개월") 수기 큐레이션 + 출처·수집일 표기. 전 차종 아닌 판매 상위 차종부터.
판정 엔진 v0: 소진 속도 = 스냅숏 이동평균(계절성 모델 금지 — POC 단순성). 방식별 3분기(ΔT / T_lead vs 60일 / 경쟁률 표시). 3등급 + 근거 공개 + "판정 불가" 상태 지원.
백테스트: 2024~2026 소진 이력을 복원 가능한 범위에서 수집해 판정 로직의 적중·오보율을 공개 전에 측정. 오보율이 수용 불가 수준이면 등급 경계를 보수화하거나 "주의" 구간을 확대해 재측정.
고지 체계: 예측 정보 고지·정본(지자체 공고) 안내·기준 시각 표기·약관 책임 한계(백서 6.5).
v1.0 승계 자산 유지: 차량 DB·TCO 계산기·GEO 구조화 마크업·알림 등록.

Gate G1 — Phase 2 진입 조건 (전부 충족):

백테스트 결과가 문서화되고, 오보(안전 판정 후 소진) 사례에 대한 등급 보수화가 반영됐다
지수가 라이브에 공개되고 30일 계측이 존재한다: 지수 조회 수요가 기존 잔여 조회 대비 유의미하게 발생하는가, 알림 등록 전환이 발생하는가
선정 방식 DB가 101곳 전수를 커버한다 (하반기 공고 갱신 포함)
일별 잔여 데이터의 적법한 수급 경로가 확보됐다 (제공신청 승인 또는 KECO 서면 이용허락) 후 스냅숏 시계열이 중단 없이 N주 이상 축적됐다 — 수급 경로가 열리지 않으면 G1은 통과하지 않는다(대체: 공고문 기반 저해상도 지표로 재설계 여부를 판단)

G1 실패 시: 판정 수요가 없으면 트래커+차량 DB+계산기(v1.0 자산)로 회귀하고 원인 분석 후 재기획 — 매몰 최소 구조.

3. Phase 2 — 예측 고도화·계약 추적 (플라이휠 시동)

계약 추적(F2): 유저가 자기 계약(차종·지자체·계약일)을 등록하면 내 기준 ΔT 추적 + 위험 전환 알림. 출고 완료 시 실제 소요 기간 제보 요청 — 제보 인센티브 = 자기 지수의 정확화.
T_lead 자체 DB 전환: 제보 축적 차종부터 공개 집계 의존 → 자체 실측 밴드로 교체, 밴드 폭 축소를 계측.
예측 모델 고도화 판정: 축적된 시계열로 계절성·이벤트 모델(방향서의 가중 합성식)을 백테스트하고, 이동평균 대비 개선이 실증될 때만 채택.
대안 경로 엔진 v1: 하반기 정례 공고 일정 DB + '26.9월 국비 단독 경로 시행 세부 추적·반영(9월 시행 — 이번 Phase의 시의성 이벤트) + 법인 렌트·리스 상품 정보(제휴 렌터카사 확보 시).
B2G 파일럿 실행: v1.0 계획 승계(제안서 발송·정보공개청구) — 제안물은 "잔여 조회 링크"가 아니라 "판정·예측 서비스"로 갱신.
법률 관문 착수 (Phase 3 선행 조건): §65-2 유권해석/법률 자문 + 통신판매중개 검토 발주.

Gate G2 — Phase 3 진입 조건:

T_lead 제보가 실제로 발생하고(가설 6.7-3 검증), 최소 1개 차종군에서 자체 밴드가 공개 집계보다 좁아졌다
라이브 판정의 사후 검증(예측 vs 실제 소진)이 1개 공고 사이클 이상 축적·공개됐다
위험 판정 노출 수가 파일럿을 정당화할 규모로 존재한다 (위험 판정 유저 풀 = Phase 3의 원료)
신차 리드 매칭의 법적 지위가 확정됐다 (유권해석 또는 자문 의견서)

4. Phase 3 — 즉시출고 매칭 파일럿 (트랜잭션 검증)

원칙: 자동화 이전에 수동. 매칭 시스템을 만들기 전에, 수동 컨시어지로 단위 경제를 실측한다 (POC는 가장 단순하게).

딜러 제휴 3~5곳 (수도권·판매 상위 브랜드 우선): 재고·취소분 정보의 수기 수급 채널 개설.
수동 매칭 파일럿: 위험 판정 화면에 "즉시출고 대안 확인" 신청 → 운영자가 제휴 딜러와 수동 연결 → 050 안심번호. 계측: 신청 전환율, 상담 성사율, 출고 성사 건, 딜러 지불 의사 단가.
표현 규율: 출고·등록순 지자체에는 "빠른 출고로 순번 도달", 접수순 지자체에는 "2개월 요건 충족" — "예산 선점" 표현 금지(백서 5.3).
이해상충 방어 가동: 판정 로그 감사 체계, 안전 판정 유저 무제안 원칙의 시스템화.
성사 데이터(실제 출고일)의 플라이휠 재유입 설계.

Gate G3 — Phase 4(수익화 확장) 진입 조건:

파일럿에서 위험 판정 → 매칭 신청 → 출고 성사의 퍼널이 실측됐고, 리드 단가·전환율 데이터가 존재한다
제휴 딜러가 유료 지속 의사를 확인했다 (재계약)
매칭 개입 건의 보조금 수령 성공률이 추적·문서화됐다 ("확보해 준다" 주장의 실증)
이 시점에서 최초의 재무 모델 작성 (실측 단가 기반 — 이전에는 작성 금지)

5. Phase 4 — 확장: 매칭 자동화·B2B·B2G·금융·TCO

G3 실측을 근거로 우선순위를 재결정한다. 후보(순서는 G3 데이터가 정한다):

매칭 자동화(재고 수급 파이프라인·LMS)와 딜러망 확대
B2B 데이터 상품(선정 방식 DB·소진 시계열·수요 분포 API)
B2G 화이트라벨(지자체 수요 예측 — 파일럿 성과 실증 시)
금융·TCO 결합(캐피탈 금리·카드 캐시백 → TCO 리포트): 금소법 자문 통과가 착수 조건 — 통과 전에는 계산기(정보 제공)까지만
중고 EV·SOH(Recurrent형)는 별도 기획으로 분리 유지(v1.0 승계)

6. 운영 리듬·역할·규율 (v1.0 승계)

주간 사이클: 월요일 지표 리뷰(사업기획 v2.0 6절 KPI 세트) → 주중 개선 배포 → 데이터 갱신 일 단위 상시. 모든 변경은 wiki 동반 갱신 + 커밋.
역할 분담(AI-Native TF): Joseph = 승인 게이트·MOU 서명·30일/게이트 리뷰 의사결정 / AI 세션 = 개발·데이터·운영·검수 / 룰셋 변경은 HIL(사람 확인 후 반영) / 대외 문서는 AI 작성 → Joseph 명의 발송.
범위 동결: 각 Phase 범위 밖 아이디어는 백로그로. 범위 추가는 게이트 앞당김이 아니라 명시적 결정으로만.
기록 규율: 장애·데이터 사고(특히 판정 오보)는 wiki/incidents/ 즉시 기록 + 공개 정정.

부록 — 스택 경로: 현행 PHP와 목표 아키텍처의 관계

구간	스택	근거
Phase 1~2 (검증기)	현행 PHP + 파일/DB 적재 + 크론 수집기 (elecq.ai 라이브 스택 그대로)	검증 대상은 기술이 아니라 가설(판정 수요·정확도·제보). 현행 스택으로 전부 실행 가능하며, 스냅숏·룰셋·제보 데이터는 스택과 독립적인 자산이다
Phase 3~4 (스케일업)	통합 기획서의 목표 아키텍처를 필요 컴포넌트부터 선별 도입: 수집 오케스트레이션(Airflow류)·실시간 처리(Redis)·ML 파이프라인·AWS 이전	전환 트리거(아래) 충족 시, 컴포넌트 단위로. 빅뱅 재작성 금지

전환 트리거 (어느 하나가 실제로 관측될 때 해당 컴포넌트만): ①수집 대상·주기 증가로 크론 체계의 실패율이 계측상 문제 될 때 ②매칭 자동화가 실시간 상태 관리를 요구할 때 ③B2B API 상품화로 SLA가 필요할 때 ④트래픽이 현행 서버 한계를 계측상 위협할 때.

방향서의 기술 스택 목록(Next.js·FastAPI·PostGIS·EKS 등)은 이 목표 아키텍처의 참조 사양으로 보존하되, Phase 1~2 실행 문서에는 등장시키지 않는다 — 두 스택을 충돌시키지 않는다.

게이트 기반 Phase 로드맵