B-Plan · 개발기획

스택·데이터 모델·파이프라인

이 문서에서

1. 기술 스택 — 회사 표준 자산 재사용1.5 Wiki-Driven Site 아키텍처 (2026-08-05 구축 완료 — 운영 중)1.6 AI 활용 지점 — 어디에 쓰고, 어디에 쓰지 않는가 (2026-08-05 신설)2. 데이터 모델 (Phase 1)3. 데이터 파이프라인4. Phase 1 기능 명세 (v1.0 — 상단 v2.0 정합 주석 참조: 정본 범위는 실행기획 v2.0 2절)5. 품질·운영 규칙
v1.0 · 2026-08-04 · 근거: 백서 4장 데이터 소스·5장 전략 · POC 단순성 원칙 적용(과설계 금지) v2.0 정합 주석 (2026-08-05, 문서 QA): 본 문서는 v1.0이다. Phase 1 범위의 정본은 실행기획 v2.0 2절(현행 트래커에 안전지수 v0 증축 — 판정 엔진·선정 방식 DB·T_lead 밴드·백테스트)이며, 아래 4절의 기능 명세는 그 기반 자산의 명세로 읽는다. 본 문서의 F1~F3 번호는 사업기획 v2.0 3절의 퍼널 F1~F3(지수 조회·계약 추적·확보 솔루션)과 별개 번호다. 데이터 모델에는 ev_subsidy_snap 외에 지자체 선정 방식(ev_subsidy_local 필드 확장)과 T_lead 밴드 테이블이 추가로 필요하다(백서 4장 (7)~(9)) — 스키마 확정은 Phase 1 작업에서.

1. 기술 스택 — 회사 표준 자산 재사용

층선택이유
웹PHP 8 서버 렌더링 + 바닐라 JSSEO/GEO에 유리한 SSR, 회사 검증 스택(TAP과 동일 계열), SPA 불필요
DBMariaDB(MySQL)회사 표준. 스키마는 db/schema_elecq.sql로 버전 관리
수집PHP CLI 컬렉터 + cron크론탭 수정 규칙 준수(백업 선행). 수집·검증·발행 분리
계측자체 경량 로그(페이지뷰·도구 사용·알림 등록)외부 도구 의존 최소화. 개인정보 최소 수집
인프라elecq.ai 라이브 운영 중(SSL·리다이렉트 — 실행기획 v2.0 0절)현행 서버 스택 유지. 이전은 스케일업 트리거 충족 시 컴포넌트 단위(실행기획 부록)

원칙: 프레임워크·빌드 도구 도입 없음(POC 최단순). 상대경로 완결 구조(폴더째 이동 가능). 이모지 금지. 파괴적 명령 규칙 준수.

1.5 Wiki-Driven Site 아키텍처 (2026-08-05 구축 완료 — 운영 중)

사이트는 콘텐츠(위키)와 렌더러(PHP)를 분리한 자동화 파이프라인으로 동작한다. HTML을 수정하지 않는다.

구성파일역할
변환기public/lib/markdown.php위키 마크다운 부분집합(제목·표·목록·체크·인용·코드) → HTML. 허용 태그
만
온톨로지 로더public/lib/site-content.phpwiki/site/*.md를 섹션 단위로 로드 — 산문(section)·구조 데이터(table)·필드(kv)
문서 렌더러public/whitepaper.php · public/bplan.phpwiki/whitepaper/·wiki/planning/ 전문 렌더(장 탭·목차·페이저). 내부 상대링크는 linkMap으로 사이트 URL 치환
공개 스위치public/config.php SHOW_PROJECT_DOCS구축 기간 문서 메뉴 공개, 이후 false로 비공개(위키 원본은 유지)
시연 데이터 계층public/lib/demo-data.php트래커 더미(지자체 12·차종 8·금융 옵션). 스키마는 ev_subsidy_* 설계와 정합 — 실데이터 전환 시 이 계층만 DB 산출로 교체

원칙: 캐시 없이 요청 시점 파일 읽기(트래픽 규모상 충분 — 병목 시 mtime 기반 캐시 추가). 규격 정본은 wiki/site/README.md, 운영 규칙은 wiki/_meta/maintenance-protocol.md.

1.6 AI 활용 지점 — 어디에 쓰고, 어디에 쓰지 않는가 (2026-08-05 신설)

배경: "예측 정확도를 높이려면 딥러닝을 써야 하지 않나"라는 질문에 대한 기술 판단을 명문화한다. 결론은 "AI는 예측 모델이 아니라 데이터 층에서 정확도를 만든다"이다.

현재 상태 (정직한 기술)

안전지수 v0의 소진 예측은 잔여 ÷ 최근 소진 속도(이동평균) 한 줄이다. 머신러닝·딥러닝을 쓰지 않는다. 의도된 선택이며(백서 5.3 "v0는 이동평균으로 시작 — 과설계 금지"), 대외 문구에서도 "AI 예측 엔진"으로 표방하지 않는다(백서 6.1: "검증된 모델" 서술 금지).

지금 딥러닝이 정확도를 올리지 못하는 이유 4가지

#이유근거
1학습 데이터가 0일별 스냅숏 시계열이 아직 없다(수급 절차 진행 중 — INC-20260805). 예측의 재료 자체가 미확보
2사건 수가 작다학습 대상은 "소진 사건"이고 101개 지자체 × 연 2회 이상 공고 = 연 200건 규모. 딥러닝 유효 구간과 두 자릿수 차이. 짧은 시계열·소수 사건에서는 고전 기법(이동평균·지수평활)이 통상 우위
3병목은 모델이 아니라 입력T_lead가 비공식 월간 집계라 오차 ±수 주(백서 6.2). 입력 오차가 수 주면 모델 정교화의 이득이 그 오차에 갇힌다
4결정 변수가 과거에 없다유가 급등발 폭증·특정 브랜드 물량 집중 같은 외생 충격은 과거 학습으로 예측 불가 — 모델이 아니라 급변 감지 + 보수적 등급 강등으로 다룬다(백서 6.1)

AI를 실제로 쓰는 곳 (정확도 기여가 큰 순서)

지점역할왜 여기가 효과적인가단계
지자체 공고문 파싱101곳 HWP/PDF에서 선정 방식·자격 조건·물량·일정 추출현재 최대 노동 병목이자 해자(백서 6.3). 사람 여러 명분의 정규화를 대체 — 다만 반영은 사람 확인 후(HIL)Phase 1
지침 개정 감지·차이 추출연 1회 대개정 + 수시 개정의 변경분을 룰셋 갱신 후보로룰셋 정확도가 곧 제품 정확도. 놓치면 전 지역 오판정Phase 1~
유저 제보 정규화자유 텍스트 제보 → 구조화된 T_lead 실측치위 이유 3(최대 병목)을 직접 해소하는 경로Phase 2
급변 감지소진 속도 이상 가속 탐지 → 등급 자동 강등이유 4의 대응 수단Phase 1~2
자연어 질의 응답"○○시 EV6 지금 계약해도 되나요"에 판정으로 답GEO 인용 지위(백서 5.5)Phase 2~

원칙: AI 출력은 언제나 검토 큐를 거친다. 보조금 룰셋·판정 파라미터를 AI가 자동 반영하지 않는다(3절 HIL 원칙과 동일).

예측 모델 고도화의 순서 (백서 5.3 승계)

이동평균(v0) → 스냅숏 시계열 축적 → 계절성·이벤트 가중 모델 백테스트
   → 이동평균 대비 개선이 실증될 때만 채택 (Phase 2 게이트 G2)

즉 "AI를 쓴다/안 쓴다"가 아니라 "백테스트로 측정해 이기는 쪽을 쓴다"이다. 데이터가 충분히 쌓이면 머신러닝이 유리해질 수 있고, 그 판단은 선언이 아니라 측정이 한다. 채택 시에도 등급·근거 공개 규율(확률 % 표기 금지 포함)은 그대로 유지한다.

2. 데이터 모델 (Phase 1)

핵심 설계 원칙: 화면이 아니라 API를 먼저 설계한다 — 훗날 B2B API·화이트라벨 전환이 가능한 구조(사업기획 v2.0 4·7절).

ev_vehicles        차량 마스터: 제조사·모델·트림, 배터리(용량·화학조성), 전비(인증), 주행거리(인증),
                   충전(AC/DC kW), 가격(출고가), 판매상태 · 출처·기준일 필드 필수
ev_subsidy_rules   보조금 룰셋: 연도·국비 산식·차종별 국비액·조건(전환지원금 등) — 지침의 룰셋화
ev_subsidy_local   지자체 테이블: 101개 지자체 × 지방비 금액·공고 URL·공고일·특이 조건
ev_subsidy_snap    잔여 스냅숏: 지자체 × 시각 × (공고/접수/출고잔여) — 시계열 보존이 곧 자산
ev_charge_fees     충전 요금: 사업자 × 출력 구간 × 회원/비회원/로밍 단가 × 시행일
ev_alerts          알림 등록: 이메일(최소 수집)·지역·차종·동의 일시
ev_sources         출처·라이선스 대장: 소스별 URL·라이선스·약관 확인일·갱신 주기
ev_metrics         자체 계측: 일자 × 지표 (페이지뷰·계산기 실행·알림 등록 등)

모든 사실 테이블에 source_id·as_of(기준시각) 필수 — "출처·기준일 전면 명시" 원칙(백서 4.4)의 스키마 강제.

3. 데이터 파이프라인

[수집 collectors]           [검증 verify]              [발행 publish]
충전소 API(5분~1시간)   →   스키마·이상치 검사     →   DB 반영 + 페이지 캐시 갱신
ev.or.kr 잔여(주기 미정) →   전회 대비 급변 감지    →   급변 시 사람 확인 큐
지침·공고(이벤트성)      →   사람이 룰셋 갱신(HIL)  →   룰셋 버전 커밋 + 변경 로그 공개
요금 고시(이벤트성)      →   사람 확인               →   시행일 기준 반영
  • Human-in-the-Loop이 기본값: 보조금 룰셋·요금은 자동 반영하지 않는다. 수집기는 "변경 감지 → 검토 큐"까지만, 반영은 사람(AI 세션) 확인 후(PlugStar 실증 구조).
  • ev.or.kr 수집은 약관 검토 결과에 따름(착수 전 필수 — 실행기획 v2.0 Phase 1-1). 불허 시 수기 큐레이션 모드(일 1회)로 강등 운영.
  • 지자체 HWP 공고 자동 파싱은 Phase 1 범위 외 — 표본 10곳 PoC로 실현성만 판정(백서 4.5·6.6).
  • 관리 화면: 검토 큐·룰셋 편집·수록 현황 대시보드(내부용 최소 구성).

4. Phase 1 기능 명세 (v1.0 — 상단 v2.0 정합 주석 참조: 정본 범위는 실행기획 v2.0 2절)

F1. 보조금 트래커 (핵심)

  • 입력: 지역(시군구) + 차종(트림) → 출력: 국비+지방비 합산 실구매가, 잔여 현황(기준시각 명시), 공고 원문 링크
  • 지자체별 페이지 101개(정적 생성 + 갱신) — 롱테일 SEO/GEO의 골격
  • 소진 임박 알림 등록(이메일 우선, 알림톡은 Phase 2)
  • 고지 의무: "정본은 지자체 공고" + 기준시각 + 정정 채널

F2. 차량 DB·비교

  • 국내 시판 EV 전 모델(수십 종) 스펙 페이지 + 2~4종 비교 뷰
  • 필터: 가격대·주행거리·배터리 화학조성·급속충전 성능·차급
  • 시드: OpenEV Data(CDLA 고지) + 인증 정보 수기 검수 — 모델당 출처·기준일 표기

F3. TCO·충전비 계산기

  • 입력: 차종·연간 주행거리·완속/급속 비율·거주 지역 → 출력: 월 충전비, 동급 내연기관 대비 3·5년 총비용
  • 2026-08-01 5단계 요금 개편 반영(시의성 훅). 모든 가정치(유가·잔가 등) 화면에 명시
  • 결과 공유 URL(커뮤니티 확산 장치)

F0. 기반

  • 반응형 웹(디자인기획), Schema.org 구조화 마크업·sitemap·기준일 메타(GEO 요건)
  • 개인정보처리방침·이용약관, 자체 계측, 관리 화면

범위 외(백로그): 충전 지도, 커뮤니티, 네이티브 앱, 중고 EV/SOH, 금융 비교, 지자체 공고 자동 파싱 전면화.

5. 품질·운영 규칙

  • 테스트: 룰셋 계산(보조금 산식·TCO)은 케이스 테이블 기반 단위 테스트 필수 — 숫자가 제품이다.
  • 데이터 사고(오류 수치 노출)는 wiki/incidents/ 의무 기록 + 정정 공지 프로세스.
  • 배포: dev → 운영 분리, 운영 반영은 Joseph 승인 게이트(회사 표준 준수).
  • 코드 변경 시 이 문서·데이터 모델 문서를 같은 작업에서 갱신(_meta 규칙). 개발 착수 시 development/ 폴더(backend-api·data-model)를 TAP 표준으로 개설한다.